model-based design of embedded systems
DESCRIPTION
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. - PowerPoint PPT PresentationTRANSCRIPT
1
Model-Based Design of Embedded Systems
MotoHawk Training
2
Why Model-Based Design? The MotoHawk™ System w/ Demonstration The Simulink® Model The MotoHawk™ Way Advanced Software & Hardware Issues Real Application Challenge
Course Outline
3
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
Why Model-Based Design?
4
sourcecode
Software Engineers
Sourcecode
CompilerLinker
ApplicationFile
Specification
Application Engineers
Models
Loader
Traditional Application Development
Application Engineers
Models
CodeGen
sourcecode
Sourcecode
CompilerLinker
ApplicationFile
Loader
Model Based Application Development
Interfaces
Development Process Comparison
5
Control Design
PCM
HUD
MotoTune
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
MotoHawk™ ECU-based Rapid Prototyping
6
Control Design
PCM
HUD
MotoTune
Define Requirements& Architecture
Define Algorithms
Production Code Generation
Hardware In LoopTesting
Environment In Loop Testing
Custom HW Prototype
MotoHawkTM
Prototype
Working Closer to Production
7MotoHawktm
ToolchainCompiler, Linker, Loader, Calibration
CompilerLinker
ApplicationFile
(srec,elf)
Loader
SimulinkBlock
Library(mdl)
CustomBlock
Libraries(mdl)
MotoHawkBlock
Libraries(mdl)
MotoHawkBlock
Code GenScripts
(tlc)
MotoHawkMaster
Code GenScript(tlc)
MotoHawkTemplateMakefile
(tmf)
ApplicationEngineers
Operating System andBoard Support
OSSource(.c,.h) Board
SupportSource(.c,.h)
Mathworks ToolsMatlab, Simulink, Stateflow, Realtime Workshop, Embedded Coder
RealtimeWorkshopCode Gen
sourcecode
sourcecode(c,h)
makefile(mk) make
MatlabLibrarySource(.c,.h)
model(mdl)
Code Generation Process Flow
8
Modeling with MotoHawk™
9
Blinking LED: MotoHawk™
10
Open the model in SimulinkGenerate CodeCompile and LinkDownload to ECURun!
MotoHawk™ Demonstration
11
Trigger
BlockSignal
Subsystem
Port
System
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
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
Modeling Software with Simulink®
14
“Model the elements of the whole system, including the processor, build environment, memory, and operating system.”
Elements of Simulink®:Modeling & Simulation EnvironmentCode Generation
Elements of MotoHawk™: Input & Output ModelOperating System Model Integrated Build Environment
The MotoHawk™ Way
15
Model blocks for ECU I/O and engine-specific peripherals
Examples:Digital Inputs & OutputsAnalog-to-Digital InputsPWM OutputsSerial Inputs & OutputsCAN Inputs & Outputs
Electronic Spark Timing OutputsEngine Knock InputsFuel Injector Control Outputs
Engine-specific peripherals
MotoHawk™ Input & Output Model:
16
MotoHawk™ Input & Output Model:
17
Model blocks for program flow and triggeringExamples:
Periodic Tasks InterruptsOperating System Events
MotoHawk™ Operating System Model
18
MotoHawk™ Input & Output Model:
19
Whole process, from pictures to working machine, in one environmentSimulationSystem VerificationCode GenerationMakefile GenerationCompile, Link, Locate, and Program Integration with Calibration ToolsDocumentation
MotoHawk™ Build Environment
20
Simulink® is excellent for modeling control lawsNative Simulink® is not very expressive for modeling
general software systemsMotoHawk™ adds real-time software elements to the
Simulink® environment
MotoHawk™ and Simulink® Together
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
The control law should be designed using discrete elements
We would like to allow a continuous plant modelWe would like to take advantage of Variable-Step
simulationWe need to simulate discrete sampling of the control
law
Problems with the diagram
25
Improved System Simulation
26
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
Designing a Control System
27
Sample InputsPassive Control Law
Update Outputs
MotoHawk™ Software Model
28
Sampling Inputs from the Hardware
29
Updating Outputs to the Hardware
30
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
Reuse & Abstraction
31
We try to separate the controller design from the H/W and S/W issues
Some systems are more complexProbes, calibrations, overriding signalsDistributed systems, with multiple controllersMulti-rate and asynchronous systemsTask preemption and long calculations
Hardware and Software Issues
32
Probes, Calibrations, and Overrides
33
MotoHawk™ seamlessly integrates with MotoTune™, a calibration tool allowing real-time observation and control.
Probes allow monitoring of valuesCalibrations allow adjustment of constantsOverrides allow signal modification for testingThis typical S/W issue has been abstracted into the
model
Probes, Calibrations, and Overrides
34
Calibratable Lookup Tables
35
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.
MotoTune® Development Tool
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
Distributed Systems, Multiple Controllers
39
Multi-Rate Controllers
40
System simulation uses same picture as the distributed system
Multiple tasks, each modeled as a unique controllerOnly one MotoHawk™ software model, using multiple
triggers, one for each taskThe processor only runs one task at a time, so we
must be aware of task priority and data coherency between tasks
Multi-Rate Controllers
41
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
BGND TDC CAN
CAN RxInterruptTDCBGND
HardwareInterrupts
Top-half Parsing
ForegroundTasks
BackgroundTasks
Foreground QueueBackground Queue
BG
ND FIFO
CA
N FIFO
Time
Prio
rity
Process BGND
TDC
Process TDC TDC Process CAN
Finish BGND
Task Preemption
43
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
Task Preemption
44
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.
MotoHawk™ Application Challenge
45
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
Conclusion
MotoTron Control SolutionsProduction Controls in a Flash