Model-Based Design of Embedded Systems

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