model-based design of embedded systems

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