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

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

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
HUD
5
Control Design
PCM
MotoTune

Working Closer to Production
6
Custom
HW Prototype
Define Requirements
& Architecture
Define Algorithms
Production Code
Generation
Environment In Loop
Testing
MotoHawk TM
Prototype
Hardware In Loop
Testing
HUD
Control Design
PCM
MotoTune

7
MotoHawk
Block
Libraries
(mdl)
MotoHawk
Block
Code Gen
Scripts
(tlc)
MotoHawk
Master
Code Gen
Script
(tlc)
MotoHawk
Template
Makefile
(tmf)
Code Generation Process Flow
Simulink
Block
Library
(mdl)
Custom
Block
Libraries
(mdl)
Application
Engineers
Mathworks Tools
Matlab, Simulink, Stateflow, Realtime Workshop, Embedded Coder model
(mdl)
Realtime
Workshop
Code Gen makefile
(mk) source code
(c,h)
Matlab
Library
Source
(.c,.h) make Toolchain
Compiler, Linker, Loader, Calibration
Compiler
Linker
Application
File
(srec,elf)
Loader
Operating System and
Board Support
OS
Source
(.c,.h)
Board
Support
Source
(.c,.h)
MotoHawk tm

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
Subsystem
Block
Signal
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
Engine-specific peripherals
 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 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

MotoHawk ™ Software Model
27
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 realtime.
 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

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.

Task Preemption
42
Hardware
Interrupts
Top-half Parsing
BGND
BGND
Foreground
Tasks
Background
Tasks
Process BGND
TDC
TDC
CAN Rx
Interrupt
Process TDC
CAN
TDC Process CAN
Finish BGND
Time
Background Queue
FIFO
Foreground Queue
FIFO

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
1.
Using Slider 1 as a throttle command, read the analog voltage and convert the output value (0-
1023) to a 0-5V signal.
2.
Read the throttle position from analog input AN4 and convert the output value (0-1023) to a 0-5V signal.
3.
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

MotoTron Control Solutions
Production Controls in a Flash