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. Why Model-Based Design?
Hand-Coding
Model-Based Design
Specification
Modeling
S/W Implementation
S/W Design
S/W Debugging
S/W Verification
H/W Verification against Model
H/W Verification against Specification
Time
Extra Time & Money

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

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. Working Closer to Production
Custom HW Prototype
Define Requirements & Architecture
MotoHawkTM Prototype
Environment In Loop Testing
Define Algorithms
Hardware In Loop Testing
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. The Standard Simulink® Model
Trigger
Block
Signal
Subsystem
Port
System

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

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. 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
Engine-specific peripherals

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 System Example
Control Law
Design system simulation model
Design MotoHawk™ software model
Reuse control law

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. MotoHawk™ Software Model
Sample Inputs
Passive Control Law
Update Outputs

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 Solutions Production Controls in a Flash
MotoTron Control Solutions Production Controls in a Flash