model-based design – what it is and what it still...

©20

08 T

he M

athW

orks

, Inc

.

591 /* Logic: '<S3>/either' */592 rtb_either = power_window_con_B.passenger_control_b 593 || power_window_con_B.passenger_control_a; 594 595 /* Logic: '<S13>/allow_action' incorporates:596 * Inport: '<Root>/driver_up'597 * Logic: '<S13>/overrule'598 */599 rtb_temp34 = power_window_con_U.driver_up 600 && (!(rtb_either));

Model-Based Design –What it is and what it still needs

Pieter J. [email protected]

Senior Research ScientistThe MathWorks

2

Introduction

Model-Based DesignExploit computational modelsIncreasingly adopted in industry

Underlying needsMany different modeling formalisms

SyntaxSemantics

Relate and combine modelsDifferent parts of a systemDifferent design stages of a system

Open research topics …

3

Agenda

Model-Based DesignComputer Automated Multiparadigm ModelingApplicationMulti-formalism modelingMixed-signal simulationHybrid Dynamic SystemsSummary

4

Generate prototype, hardware in the loop, and production code

Include power effects with a detailed plant model

Include continuous plant behavior

Executing hybrid dynamic system

Model fixed point implementation

Model discrete control algorithm

Model system effects

Model mechanism geometry

Power Window Demo Summary

5

Design?

Design of complex systems is a process of transaction

Requirements (what)Specification (how)

Platform-based designMeet in the middle

design space (what)

API

implementation space (how)

platform

6

Typical Document-Based Design

Results from each design stage are documentedSpecifications output of one stage are requirements input to the nextSimulation requires programming of specification (e.g., FORTRAN)

The window has to be fully opened and fully closed within 4 [s].

The force to detect when an object is present should be less than 100 [N].

28 /* Function prototypes for chart <S1>/control */ 29 static void exit_internal_c2_s2_safe(SFpower_window_con_rtw_c2InstanceStruct 30 *chartInstance); 3435 #define IN_NO_ACTIVE_CHILD (0) 36 #define IN_c2_s1_emergencyDown 1 39 #define IN_c2_s7_driverNeutral 2 591 /* Logic: '<S3>/either' */ 592 rtb_either = power_window_con_B.passenger_control_b 593 || power_window_con_B.passenger_control_a;

Design Exploration (FORTRAN Simulation)

[d river[3 ]]

driverD ow nen try : m oveD o w n = 1 ;ex it: m oveD ow n = 0 ;

a fte r(1 00 ,ticks )[d river[1 ]] 1

2

in iD riverD o w n

au toD riverD o w n D rive rD ow n

7

Model-Based Design

The window has to be fully opened and fully closed within 4 [s].

The force to detect when an object is present should be less than 100 [N].

28 /* Function prototypes for chart <S1>/control */ 29 static void exit_internal_c2_s2_safe(SFpower_window_con_rtw_c2InstanceStruct 30 *chartInstance); 3435 #define IN_NO_ACTIVE_CHILD (0) 36 #define IN_c2_s1_emergencyDown 1 39 #define IN_c2_s7_driverNeutral 2 591 /* Logic: '<S3>/either' */ 592 rtb_either = power_window_con_B.passenger_control_b 593 || power_window_con_B.passenger_control_a;

Design Exploration

Share in computationalform

[d river[3 ]]



2

in iD riverD o w n


8

Where are the models?

t_ in m _ m a inm _s up po rt

m _h olde r

v _w in dow

28 /* Function prototypes for chart <S1>/control */ 29 static void exit_internal_c2_s2_safe(SFpower_window_con_rtw_c2InstanceStruct 30 *chartInstance); 3435 #define IN_NO_ACTIVE_CHILD (0) 36 #define IN_c2_s1_emergencyDown 1 39 #define IN_c2_s7_driverNeutral 2 591 /* Logic: '<S3>/either' */ 592 rtb_either = power_window_con_B.passenger_control_b 593 || power_window_con_B.passenger_control_a; 28 /* Function prototypes for chart <S1>/control */

29 static void exit_internal_c2_s2_safe(SFpower_window_con_rtw_c2InstanceStruct 30 *chartInstance); 31 static void 32 exit_internal_c2_s7_driverNeutral(SFpower_window_con_rtw_c2InstanceStruct 33 *chartInstance);3435 #define IN_NO_ACTIVE_CHILD (0) 36 #define IN_c2_s1_emergencyDown 1 39 #define IN_c2_s7_driverNeutral 2 591 /* Logic: '<S3>/either' */ 592 rtb_either = power_window_con_B.passenger_control_b 593 || power_window_con_B.passenger_control_a; 594595 /* Logic: '<S13>/allow_action' incorporates:597 * Logic: '<S13>/overrule'598 */599 rtb_temp34 = power_window_con_U.driver_up 600 && (!(rtb_either));

[d river[3 ]]



2

in iD riverD o w n


2move_down

1move_up

neutral

up

down

reset

neutral_up_down

validate_passenger

neutral

up

down

reset

neutral_up_down

val idate_driver

[reset]

reset

[reset]

passenger_reset

[reset]

driver_reset

armature_current

mov e_up

reset

obstacle

endstop

detect_obstacle_endstop

endstop

obstacle

driv er

passenger

mov eUp

mov eDown

control

10 ms

7passenger_down

6passenger_up

5passenger_neutral

4driver_down

3driver_up

2driver_neutral

1armature_current

9

Benefits of a computational formSimulate a design immediately

Try out different ideas quicklyCombine with partially detailed designAllow sharing of design decisions across stagesDomain-specific languages can easily be developed

Automatic model processingStyle guideline enforcing (automatic fixing)Data type inference

Static checking of dynamicsTest bench generationDigital linking to other documentsModel transformation

Allows one reference modelChoose best representation for given analysisAutomate synthesisAutomate optimizationAutomate design?!

Combine semantics!

Coverage test suites; prover complexity!

Style specification; static semantics!

Consistency and inconsistency!Correctness!

Architecture modeling!

Performance evaluation!

10

Agenda


11

Computer Automated Multiparadigm Modeling

Computer Automated Multiparadigm Modeling (CAMPaM)

Annual McGill Bellairs workshopThree elements of CAMPaM

Multi-formalism modelingMetamodelingMultiple levels of abstraction

Model model transformationGraph grammars...

12

What is a model anyway?

Acknowledgment: picture, courtesy of Hans Vangheluwe

13

Nothing is a model

F0

SY SE

A system that represents a system

Representation in a formalismFormally define a formalism (Ogden-Richards triangle of semiotics)

Abstract syntaxSemantic domain

systemmodel

14

Syntax versus Semantics

Fasten seat belt syntax

Fasten semantics …

… or open semantics?

15

Defining a formalism

F0

SY SE

The syntax can be defined byEnumerationA model of the modeling formalism: a ‘meta’ model

For example, a grammar

F0

SY SE

16

A metamodel

State transition diagram

Automatically generate an editorAdd hierarchy and regenerate new editor

state transition0..n1..1

1..1 0..n

state transition0..n1..1

1..1 0..n

element

17

Defining semantics

Define semantics of a new formalism by mapping the abstract syntax onto defined formalismThe semantic domain to be defined needs to be subsumed by the semantic domain of the defining formalism

Model the transformations!Graph rewriting

F0

SY SE

FISE

SY

18

Model everything

Reasoning vs. efficiencyOperationallyDenotationally

Semantic anchoringAbstract state machinesDEVSHaskell

F0

SY SE

FISE

SY

FT

SY SE

TL R

IL R

IL R

I…⇒

LHSRHSc AddAdd = c BinaryOp (+)

f Sum = c AddAdd

y Sum out = f Sum (u Sum in1, u Sum in2)

Sum

in1

in2 out

19

Transformations in general

Defining semantics (Haskell)

Optimization (minimize number of blocks)

Code generationGain 1

2

Gain

3

Gain 1

6LHS RHS

/* Gain: '<Root>/Gain' */

ex_B.Gain_y = ex_P.Gain_Gain * ex_B.Gain_u;Gain

6

LHS RHSex_P.Gain_Gain = 6.0;

LHS RHSc AddAdd = c BinaryOp (+)

f Sum = c AddAdd

y Sum out = f Sum (u Sum in1, u Sum in2)Sum

in1

in2 out

20

Research

Provably correct transformationsEfficiency

Programmed graph rewritingDomain-specific formalisms evolve constantlySemantic anchoring

What formalism to use?Is there a metaformalism?How do you deal with semantic nuances?

Approximative semantics?

21

Agenda


22

analog hardware

digital hardware

software

system

An EDA application

SoC platformHeterogeneousHighlights more common design challenges

ASIC CPU CPU

SW OS

SW

A/D D/A

RF MEMS

communication

z-1 |u|2-D FIRFilterI

Acknowledgment: picture redrawn from work by Jan Madsen

http://www.eece.ksu.edu/vlsi/bluetooth

23

A new frontier …

No clear HW/SW separationTraditionally different design paradigmsReconfigurable

Hardware and softwareAdapt to environment

NovelDesign paradigmsApplications

CPU

SW

SW

A/D D/A

RF MEMS

communication

z-1 |u|2-D FIRFilterI

software

hardware

OS

CPUFPGA

24

MATLAB® and Simulink®

algorithm and system design

HDL

Generate

Piecing it all together …

Compiler Combines

Functional designArchitecture

GeneratesHardware (HDL)Software (C/ASM)

Simulator toExplore design spaceVerify design choices

Hardware in the loopProcessor in the loopSilicon in the loop… CPU CPU

SW OS

SW

ASICFPGA

hardware architecture

software architecture

Ver

ify

Ver

ify

C/ASM

Generate

Real-Time WorkshopEmbedded Coder,

Targets, Links

Simulink HDL CoderEDA Simulator Link MQEDA Simulator Link IN

25

Implementation effects

• Application algorithm validation

• Task code validationDeadlock free execution

• Partitioning validation• Communication architecture

Number of exchanged bytes

• HdS Integration validation• Communication architecture

Number of exchanged bytesNumber of conflicts on busLevel of NoC congestion

• Final SW binary validation• Performance measurement• Memory mapping validation

Acknowledgment: picture redrawn from work by Katalin Popovici and Ahmed Amine Jerraya

CPU1 Sub

AbstractCPU1 SS

AbstractCPU2 SSMem

T1

T1

T1

T1

T1

T2

T2

T2

HdS API

HdS API

HdS API

HAL API

HAL API

HAL

Comm

Comm

OS

OS

HdS API

HdS API

HdS API

CPU2 Sub

Functionallink

HW/SW interfaceabstraction

Hardware Architecture

a) S

Ab)

VA

c) T

Ad)

VP

Software Architecture

AbstractCPU-SS

accessiblevia HdS API

AbstractCPU-SS

accessiblevia HAL API

~ TLM

ISSaccessiblevia ISA~ RTL

Abstract Communication Network

T2

T2

T3

T3

T3

T3

T3

HdS API

AbstractCPU1

CPU1ISS

Memory

Memory

Interface

Interface

Periph.

Periph.

MemSS

MemSS

Communication Network (Bus/NoC)

Communication Network (Bus/NoC)

AbstractCPU2

CPU2ISS

Memory

Memory

Interface

Interface

Periph.

Periph.

HAL API

HAL API

HAL

Comm

Comm

OS

OS

26

Research

Include performance metricsSystems of systems

CompositionalityComposability

How to deal with heterogeneity?Dieting philosophers

Can you prove abstractions are property preserving?

27

Agenda


28

Networked Embedded Control System

Continuous and discrete behavior– Plant; Continuous-time behavior with sporadic discrete events– Controller; Frequent periodic events– Network; Frequent aperiodic events

window

dc motor

currentmeasurement

window controllerlane change detectionlights controller

29

Modeling the plant physics

Domain-specific modelingDC motor and signal conditioning—Power SystemsWindow lift mechanism—Multibody Systems

CharacteristicsNoncausal, energy-based, modelingDifferential equation based

3q

BF

w o rm g ea r

C S 1C S 2

C S 3

w in do w

BF

ro ta te & slid e p o sit io n &ve lo c it y

m ea su rem e n t

C S 3

C GC S 1

m a ing e a r

C S 3

C GC S 1

d o o r

a ng lem e asu re m e n t

BFBF

1a c tiv e

1

V inv+

-

m e as u re 1

R 2

R 1

30

Modeling the supervisory control

Discrete state basedDiscrete events cause transitions between statesConditions to guard the transitionUntimedControl centric, consume

[d river[3 ]]



2

in iD riverD o w n


31

Modeling the feedback control

Embedded processors at fixed sample rateSampled discrete timePeriodic, infinite read; data values are not ‘consumed’

2move_down

1move_up

neutral

up

down

reset

neutral_up_down

validate_passenger

neutral

up

down

reset

neutral_up_down

validate_driver

[reset]

reset

[reset]

passenger_reset

[reset]

driver_reset

armature_current

mov e_up

reset

obstacle

endstop


endstop

obstacle

driv er

passenger

mov eUp

mov eDown

control

10 ms

7passenger_down

6passenger_up

5passenger_neutral

4driver_down

3driver_up

2driver_neutral

1armature_current

32

Modeling network traffic

Packets moving from one point to anotherAttributes

Source, destination, service time, priorityPreemption

Server/Queue systemsEntities flowing through a graph, data centric, producer/consumerDiscrete events, aperiodic, often stochastic

2A rr iv e d E n tit ie s

1A v e ra ge W a it

1P a ck e tIN

O U T 1

O U T 2

Tra ns m it o r D rop

IN

A 1O U T

S e t Va lu eA ttr ib u te

IN O U T

S e t D e s tin a tio nA ttr ib u te

O U T

P a cke tG e n era to r

INO U T

w

F IFO Q u e u e

IN # a

D ro p pe d P a c ke t

1co m m a n d

33

All part of the networked embedded system

34

All part of the networked embedded system

2A r r iv e d E n tit ie s

1A v e ra ge W a it

1P a cke tIN

O U T 1

O U T 2

Tra ns m it o r D rop

IN

A 1O U T

S e t Va lu eA ttr ib u te

IN O U T

S e t D e s tin a t io nA ttr ib u te

O U T

P a cke tG e n era to r

INO U T

w

F IFO Q u e u e

IN # a

D ro p pe d P a ck e t

1co m m a n d

3q

BF

w o rm g ea r

C S 1C S 2

C S 3

w in do w

BF

ro ta te & slid e p o sit io n &ve lo c it y

m ea su rem e n t

C S 3

C GC S 1

m a ing e a r

C S 3

C GC S 1

d o o r

a ng lem e asu re m e n t

BFBF

2move_down

1move_up

neutral

up

down

reset

neutral_up_down

validate_passenger

neutral

up

down

reset

neutral_up_down

validate_driver

[reset]

reset

[reset]

passenger_reset

[reset]

driver_reset

armature_current

mov e_up

reset

obstacle

endstop


endstop

obstacle

driv er

passenger

mov eUp

mov eDown

control

10 ms

7passenger_down

6passenger_up

5passenger_neutral

4driver_down

3driver_up

2driver_neutral

1armature_current

[d river[3 ]]


afte r(1 00 ,ticks )[d river[1 ]] 1

2

in iD riverD o w n


35

Research

How to handle multiple formalismsRelateCombineIntegrate

Formalisms evolveForward and backward compatibility

36

Agenda


37

How to handle a discrete event

• Time-driven– Time integrated

• Integrate up till event time• Inefficient for time events

– Sampled time• Run scheduler at lowest rate• Inefficient for widely spaced

events

• Event-driven– Jump to event time

immediately– Does not apply to state events

38

Classes of behavior• Plant, time integrated (TI)

– Continuous time– Sporadic aperiodic state-events (zero

crossings)– Events occur during execution

• Controller, sampled time (ST)– Discrete time– Frequent periodic time-events– Events are known before execution

• Network/OS, event driven (ED)– Discrete time– Frequent aperiodic time-events– Events occur during execution

predict unknownperiodic ST -

aperiodic ED TI

Event classification

39

Dedicated Time-Driven Solver

• Numerical solver integrates time (step h)

• Sampled time event schedule (time up till which to integrate)

)(6336

),(

)2

,2

(

)2

,2

(

),(

543211

34

23

12

1

hOkkkkyy

kyhxfhk

kyhxfhk

kyhxfhk

yxfhk

nn

nn

nn

nn

nn

+++++=

++⋅=

++⋅=

++⋅=

⋅=

+

40

Dedicated Event-Driven Solver

• Event-driven solver– Event calendar

– Efficient data structure

20 [ms] open_cover

2020 [ms] move_top_up_cmd

2150 [ms] move_down_window

2250 [ms] stop_moving_window

lead lead lead lead

0 1 2 3tail tail tail tail

0.1next

data

prev

3.3next

data

prev

1.5next

data

prev0.4 3.41.6

next nextnext

data datadata

prev prevprev0.5 19.55.1

next nextnext

data datadata

prev prevprev4.2 5.8

next next

data data

prev prev9.3

next

data

prev

41

Efficiency

• Two separate solvers– Time-driven solver

• Numerical solver integrates time (step h)• Sampled time event schedule

(time up to which to integrate)

– Event-driven solver• Event calendar

• Challenges– Combine the solvers– Integrate the solvers

42

Event-driven leads

Scheduled Events:

Processed Events:

Continuous Time:

state event

time event

This eventnever occurs,

but it is already

processed!

This sets atime-event

in thetime-driven

solver

This sets anevent in theevent-driven

solver

43

Time-driven leads

Scheduled Events:

Processed Events:

Continuous Time:

state event

time event

This sets anevent in theevent-driven

solver

This sets atime-event

in thetime-driven

solver

This eventnever occurs,

but it is already

processed!

44

QuestionsCan we restrict the modeling constructs that are allowed?

For example, no state events allowed to trigger events in the event-driven solver

What inaccuracy is acceptable?Not do zero-crossing detectionRun event-driven part at a quick base rate

What efficiency is necessary?Lock step approachUse one solver all together?

Do you lose the ability to handle a batch of discrete events independently?Other techniques?

Model differently

What is the preferred configuration?Time-driven leads, store continuous-time stateEvent-driven leads, store discrete event stateAlternatives?

45

Agenda


46

What is a hybrid dynamic system?

• Combines two types of behavior– Continuous-time

• Ordinary differential equations (ODEs)

• Differential and algebraic equations (DAEs)

– Discrete state changes• Inequalities

uBxAxEfiiii αααα +=&:

γαα

α αii

i iC x D u+ + ≥1 0:

uBxAxfiii ααα +=&:

47

Hybrid Dynamic Behavior

Geometric view– Modes of continuous, smooth, behavior– Patches of admissible state variable values

48

Generalized state space

• Dimensions of state space may collapse

• After switch closes– V1 = V2

– Instantaneous change in charge

dtdVCI

CqV

ii

i

ii

=

=

V1=V2

C1 C2

V2V1

49

Refined Hybrid Dynamic Behavior

Geometric view– Modes of continuous, smooth, behavior– Patches of admissible state variable values– Manifold of dynamic behavior

50

Sequences of mode changes

Mythical modePinnacle

3

3

3

3

3

51

Pathological behaviors

Divergence of time Chattering

Zeno

52

Ontology

Phase Space Transition Behavior ClassificationMythical (state invariant)Pinnacle (state projection aborted)Continuous

Interior (continuous behavior)Boundary (further transition after infinitesimal time advance)Sliding (repeated transitions after each infinitesimal time advance)

Combinations of Behavior ClassesOn Zeno

Chattering: infinitesimal time advanceDivergence of time: infinitely many switches without time advanceZeno: infinitely many switches never past a point in time

53

Research

How to efficiently generate behavior for combined time-driven and event-driven execution engines?How to deal with run-time index changes?Pathological behaviors

How to detect in industrial-size models?How to (re)solve?

54

Agenda


55

Summary

Model-Based DesignEfficient engineering system design

Important researchComputer Automated Multiparadigm ModelingHybrid Dynamic Systems...

Multi-domain researchElectrical engineeringComputer engineeringTheoretical physicsComputer science

56

Acknowledgments

Hans VangheluweBen DencklaKatalin PopoviciMirko ConradAll participants of the annual Computer Automated Multiparadigm Modeling (CAMPaM) workshop at the McGill University Bellairs Campus, Barbados…

model-based design – what it is and what it still...

Documents