1 / 46

Model-Based Design of Embedded Systems

MotoHawk Training. Model-Based Design of Embedded Systems. Course Outline. Why Model-Based Design? The MotoHawk ™ System w/ Demonstration The Simulink ® Model The MotoHawk ™ Way Advanced Software & Hardware Issues Real Application Challenge. Model-Based Design. Hand-Coding.

linnea
Download Presentation

Model-Based Design of Embedded Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. MotoHawk Training Model-Based Design of Embedded Systems

  2. Course Outline • Why Model-Based Design? • The MotoHawk™ System w/ Demonstration • The Simulink® Model • The MotoHawk™ Way • Advanced Software & Hardware Issues • Real Application Challenge

  3. Model-Based Design Hand-Coding H/W Verification against Specification Specification H/W Verification against Model Extra Time & Money Modeling S/W Design S/W Verification S/W Implementation S/W Debugging Time Why Model-Based Design?

  4. Models Traditional Application Development Source code Application File Compiler Linker source Specification Loader code Application Engineers Software Engineers Model Based Application Development Models Source code Application File Code Gen Compiler Linker source Loader Interfaces code Application Engineers Development Process Comparison

  5. MotoHawk™ ECU-based Rapid Prototyping • Key Benefits • Better testing using real ECU hardware • Faster cycle time for adding new features and enhancing existing features • Improved documentation of system design via working models of the system • Better ability to control IP development • Key Features • ControlCore enabled • Development is completed on the production capable ECU and related software • Calibration using MotoTune • Optional HUD • ECU’s available for development, pilot, or production

  6. Custom HW Prototype MotoHawkTM Prototype Working Closer to Production Environment In Loop Testing Define Requirements& Architecture Hardware In LoopTesting Define Algorithms Production Code Generation

  7. Code Generation Process Flow

  8. Modeling with MotoHawk™

  9. Blinking LED: MotoHawk™

  10. MotoHawk™ Demonstration • Open the model in Simulink • Generate Code • Compile and Link • Download to ECU • Run!

  11. System Trigger Subsystem Block Port Signal The Standard Simulink® Model

  12. Simulink Elements Systems, Blocks Port Signal Trigger Software Elements Functions, Encapsulation Interfaces Values, Variables Function-calls, Events Modeling Software with Simulink®

  13. Modeling Software with Simulink® • Native Simulink block diagrams can represent signal processing very well • Blocks can represent H/W Input & Output • Function-call triggers can represent events • Library links can represent references and provide model reuse

  14. The MotoHawk™ Way “Model the elements of the whole system, including the processor, build environment, memory, and operating system.” Elements of Simulink®: • Modeling & Simulation Environment • Code Generation Elements of MotoHawk™: • Input & Output Model • Operating System Model • Integrated Build Environment

  15. Engine-specific peripherals MotoHawk™ Input & Output Model: • Model blocks for ECU I/O and engine-specific peripherals • Examples: • Digital Inputs & Outputs • Analog-to-Digital Inputs • PWM Outputs • Serial Inputs & Outputs • CAN Inputs & Outputs • Electronic Spark Timing Outputs • Engine Knock Inputs • Fuel Injector Control Outputs

  16. MotoHawk™ Input & Output Model:

  17. MotoHawk™ Operating System Model • Model blocks for program flow and triggering • Examples: • Periodic Tasks • Interrupts • Operating System Events

  18. MotoHawk™ Input & Output Model:

  19. MotoHawk™ Build Environment • Whole process, from pictures to working machine, in one environment • Simulation • System Verification • Code Generation • Makefile Generation • Compile, Link, Locate, and Program • Integration with Calibration Tools • Documentation

  20. MotoHawk™ and Simulink® Together • Simulink® is excellent for modeling control laws • Native Simulink® is not very expressive for modeling general software systems • MotoHawk™ adds real-time software elements to the Simulink® environment

  21. Control Law Design system simulation model Design MotoHawk™ software model Reuse control law Control System Example

  22. Control Law Example

  23. Simulation with the Control Law

  24. Problems with the diagram • The control law should be designed using discrete elements • We would like to allow a continuous plant model • We would like to take advantage of Variable-Step simulation • We need to simulate discrete sampling of the control law

  25. Improved System Simulation

  26. Designing a Control System • The control law example specifies ‘what’ to do in the controller, the ‘logic’ • To design a system, we need to also specify ‘when’ to execute the control logic • To test the control logic, we would like to simulate the controller with a continuous plant model

  27. Sample Inputs Update Outputs Passive Control Law MotoHawk™ Software Model

  28. Sampling Inputs from the Hardware

  29. Updating Outputs to the Hardware

  30. Reuse & Abstraction • We reused the control law block, which we place into a library • We convert H/W input values to standard units used by the control law • We convert from standard units used by the control law to H/W output values

  31. Hardware and Software Issues • We try to separate the controller design from the H/W and S/W issues • Some systems are more complex • Probes, calibrations, overriding signals • Distributed systems, with multiple controllers • Multi-rate and asynchronous systems • Task preemption and long calculations

  32. Probes, Calibrations, and Overrides

  33. Probes, Calibrations, and Overrides • MotoHawk™ seamlessly integrates with MotoTune™, a calibration tool allowing real-time observation and control. • Probes allow monitoring of values • Calibrations allow adjustment of constants • Overrides allow signal modification for testing • This typical S/W issue has been abstracted into the model

  34. Calibratable Lookup Tables

  35. MotoTune®Development Tool • Used to program the MotoTron ECU(s). • Used to interact with the application running on the ECU. • Capable of modifying calibration parameters real-time. • Capable of monitoring and overriding values throughout the application software. • Capable of real-time charting of development data.

  36. The MotoTune®Display

  37. Distributed Systems, Multiple Controllers

  38. Distributed Systems, Multiple Controllers • The system simulation model may use more than one controller, but still use one plant model • Each controller has its own sampling trigger, possibly at different rates • Each controller will have its own MotoHawk™ software model, for code generation • The controllers may use different target hardware

  39. Multi-Rate Controllers

  40. Multi-Rate Controllers • System simulation uses same picture as the distributed system • Multiple tasks, each modeled as a unique controller • Only one MotoHawk™ software model, using multiple triggers, one for each task • The processor only runs one task at a time, so we must be aware of task priority and data coherency between tasks

  41. Task Preemption • If we want to use multiple tasks, we must be very careful about the priority of tasks, and nesting of interrupts • MotoHawk uses ControlCore, MotoTron’s ECU-Based RTOS, with a foreground / background scheduler, and queued interrupt handlers.

  42. Task Preemption

  43. Task Preemption • Lower priority tasks may be delayed by higher priority tasks • The system must be designed to allow for these delays • When a task interruption occurs, all data movement between tasks must be coherent • MotoHawk™ provides Critical Region blocks to handle atomic data transfer between asynchronous tasks

  44. MotoHawk™ Application Challenge • Using Slider 1 as a throttle command, read the analog voltage and convert the output value (0-1023) to a 0-5V signal. • Read the throttle position from analog input AN4 and convert the output value (0-1023) to a 0-5V signal. • Determine the error and use a basic PI controller to provide PWM ETC A with a duty cycle command.

  45. Conclusion • Why do model-based rapid-prototyping using MotoHawk™ • Better testing using real ECU hardware • Faster cycle time • Improved documentation of system design • Better ability to control IP development • Calibration using MotoTune • ECU’s available for development, pilot, or production

  46. MotoTron Control SolutionsProduction Controls in a Flash

More Related