Transcript MotoHawk_Training

MotoHawk Training
Model-Based Design of Embedded Systems
1
Course Outline
 Why Model-Based Design?
 The MotoHawk™ System w/ Demonstration
 The Simulink® Model
 The MotoHawk™ Way
 Advanced Software & Hardware Issues
 Real Application Challenge
2
Why Model-Based Design?
ModelBased
Design
HandCoding
H/W Verification
against Specification
Specification
Modeling
S/W Design
Extra
Time &
Money
S/W Implementation
S/W Verification
S/W Debugging
Time
3
H/W Verification
against Model
Development Process Comparison
Models
Traditional Application Development
Source
source
code
code
Specification
Application Engineers
Compiler
Linker
Application
File
Loader
Software Engineers
Model Based Application Development
Models
Interfaces
Application Engineers
4
Code
Gen
Source
source
code
code
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
MotoTune
Control Design
PCM
5
Working Closer to Production
Custom
HW Prototype
Environment In Loop
Testing
Define Requirements
& Architecture
MotoHawkTM
Prototype
Hardware In Loop
Testing
Define Algorithms
HUD
Production Code
Generation
MotoTune
Control Design
6
PCM
Code Generation Process Flow
Simulink
Block
Library
(mdl)
Mathworks Tools
Custom
Block
Libraries
(mdl)
MotoHawk
Block
Libraries
(mdl)
MotoHawk
Block
Code Gen
Scripts
(tlc)
MotoHawk
Master
Code Gen
Script
(tlc)
MotoHawk
Template
Makefile
(tmf)
7
Matlab, Simulink, Stateflow, Realtime Workshop, Embedded Coder
makefile
(mk)
model
(mdl)
Application
Engineers
Realtime
Workshop
Code Gen
make
source
source
code
code
(c,h)
Toolchain
Compiler, Linker, Loader, Calibration
Compiler
Linker
Application
File
(srec,elf)
Loader
Matlab
Library
Source
(.c,.h)
Operating System and
Board Support
OS
Source
(.c,.h)
Board
Support
Source
(.c,.h)
MotoHawktm
Modeling with MotoHawk™
8
Blinking LED: MotoHawk™
9
MotoHawk™ Demonstration
Open the model in Simulink
Generate Code
Compile and Link
Download to ECU
Run!
10
The Standard Simulink® Model
System
Trigger
Subsystem
Block
Signal
11
Port
Modeling Software with Simulink®
Simulink Elements
Systems, Blocks
Port
Signal
Trigger
Software Elements
Functions,
Encapsulation
Interfaces
Values, Variables
Function-calls, Events
12
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
13
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
14
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
15
Engine-specific peripherals
MotoHawk™ Input & Output Model:
16
MotoHawk™ Operating System Model
Model blocks for program flow and triggering
Examples:
 Periodic Tasks
 Interrupts
 Operating System Events
17
MotoHawk™ Input & Output Model:
18
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
19
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
20
Control System Example
Control Law
Design system simulation model
Design MotoHawk™ software model
Reuse control law
21
Control Law Example
22
Simulation with the Control Law
23
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
24
Improved System Simulation
25
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
26
MotoHawk™ Software Model
Sample Inputs
Update Outputs
Passive Control Law
27
Sampling Inputs from the Hardware
28
Updating Outputs to the Hardware
29
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
30
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
31
Probes, Calibrations, and Overrides
32
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
33
Calibratable Lookup Tables
34
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.
35
The MotoTune® Display
36
Distributed Systems, Multiple Controllers
37
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
38
Multi-Rate Controllers
39
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
40
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.
41
Task Preemption
BGND
Foreground
Tasks
Time
42
Process CAN
TDC
Process TDC
Process BGND
Finish BGND
BGND
Priority
Background
Tasks
CAN
TDC
Background Queue
FIFO
CAN
Top-half Parsing
TDC
Hardware
Interrupts
CAN Rx
Interrupt
TDC
BGND
Foreground Queue
FIFO
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
43
MotoHawk™ Application Challenge
1. Using Slider 1 as a throttle command, read the
analog voltage and convert the output value (01023) 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.
44
Conclusion
Why do model-based rapid-prototyping using
MotoHawk™
•
•
•
•
•
•
45
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