1

Model Driven Engineering

Jeroen VoetenEindhoven University of Technology

Embedded Systems Institute

Artist MeetingLinköping May 14, 2007

2

Ideals Project

Goal: Complexity reduction by separation of concerns • AOP – Separate cross-cutting concerns from basic

application logic• MDE – Separate technological concerns from

application logic

- September 2003 - February 2008- 10 fte/yr - 6 partners - 4 M Euro

3

Embedded System DesignState of Practice

• Embedded systems– Real-time– Concurrent– Hardware, embedded software, mechtronics, …

• Concurrent engineering with multiple disciplines• Engineering deliverables are integrated just

before shipment• Design problems turning up during integration

require rapid reengineering and release of upgrades in the field

4

Encountered Problems

• Integration– Too many design problems are detected too late– Unpredictable integration phase, both w.r.t. time and outcome

• Evolvability– Key performance parameters are tightened mutual

dependencies, increasing functionality, tighter performance requirements

– Calls for occasional system redesign – Considered to be too time consuming not done– Instead detailed, competency-driven design optimizations are

made– This is risky, inefficient and endangers future evolvability

5

Technical Problem Analysis

• Integration: Why do design problems turn up in the first place?– There is a lot of design documentation, but given in the form of

text and block diagrams– System behavior and the impact of design decisions cannot be

verified • Evolvability: Why is system redesign so difficult?

– Design documentation is low-level and discipline-dependent– To redesign one has to

1. Understand the essential system behavior. Is difficult since essential behavior is not represented explicitly

2. Change and/or extend design 3. Re-implement design. Is time consuming because of complexity

6

Embedded Design Flowconcept

SW HW

design

detaileddesign

#include<winsock.h> #define MAX_LINE 256 int main(int argc, char* argv[]) { struct sockaddr_in server_address; char buf[MAX_LINE]; …

n = strlen(buf); send(s,buf,n,0); n=recv(s, buf, sizeof(buf), 0); buf[n] = '\0'; inet_ntoa(server.sin_addr));

implementation

integrationrepair/debug/maintain

test

7

Implementation

DesignModel

analyze

analyze

DesignModel

DesignModel

refineunderpin

design decisions

abstractAnalysisModel

analyze

Goal: analysis and exploration

Goal: design representation and refinement

Implementation Implementation

Model Driven Engineering Dream

synthesize

: informal: formal

8

Analysis Models: Case Study

• Light Control Subsystem Twinscan Platform• “We expect timing problems with this system”• “We expect the problem to lie in the on-board

communication switch”• “Can you analyze the problem and derive a

solution?”

9

Light Control subsystem

ActionInterface

Wafer Control

Light Control

machine control

Reticle Control

…

HRT_Sync

Perform scan action Generate light pulses at the right time instances following a given light

intensity profile to expose one cell on wafer

light source

reticle

lens

wafer

slit

diemap patterns of electronic

circuits on wafer

10

Behavior Model

• Executable model (POOSL)– Concurrency, stochasticity, non-determinism, real-time– Synchronous message passing, object-oriented data– Choice, parallel composition, abort, interrupt, …

• Formal semantics– Real-time probabilistic labelled transition system

DesignLight Control

• Combined regular (data flow) and irregular (control)

• Dynamic process creation• Blocking behavior• Dependencies between

consumed and produced event• Data dependent behavior• …

11

Untimed System Behavior

Perform scanTakes x secsQueue scan Queue params Get params

Start scan

Trigger 1Generated engery

Generated energySetpoint

SetpointTrigger 2

Etcetera…

Setpoint

Scan queued

Scan Queued

Scan ready

Scan ready

Scan ready Params

Generated engery

Generated energy

Perform scanTakes x secsQueue scan Queue params Params

Setpoint

SetpointTrigger 3

12

Timing Constraints

Trigger i

Trigger i+1

166 s

250 sScan queued Get params

Start scan

13

Hardware PlatformLight Source

FPGA

PCI-bus, 32-bit, 33MHz

PLX bridge

CPU i64-bit, 133MHz

DDR SDRAM, (183MHz)

SDRAM i

100 Mbps Ethernet

Crossbar Fabric

Switch

ActionInterface

HRT_Sync

64-bit, 133MHz

MAC

PCI

Processor 733MHz512 kB on-chip L2 cache

14

Mapping

Light Source

FPGA

PCI-bus, 32-bit, 33MHz

PLX bridge

64-bit, 133MHz

DDR SDRAM,

Ethernet

Crossbar Fabric

Switch

ActionInterface

HRT_Sync

64-bit, 133MHz

Processor

VXWorks Possible timing problem caused

by priority assignment

No timing problem;

relative short and

predictable delays

15

Model Extension

• To analyze the impact of priority assignment, extend executable model with Processor/scheduler model and mapping

• VXWorks scheduling– FCFC per priority– higher priority can pre-empt lower priority

16

POOSL model of Processor/scheduler

start()()

prio1Busy:=false; prio2Busy:=false; par prio1()() and prio2()() and prio3()() rap.

prio1()() | cycles: Integer |

prio1?compute(cycles){prio1Busy:=true}; delay (cycles / 733); prio1!ready{prio1Busy:=false}; prio1()().

prio2()() | cycles: Real |

prio2?compute(cycles){prio2Busy:=true}; [prio1Busy not] delay (cycles / 733); prio2!ready{prio2Busy:=false}; prio2()().

ProcessorWithScheduler

prio1 prio2 prio3

prio3()() | cycles: Real |

prio3?compute(cycles); [prio1Busy not & prio2Busy not]

delay (cycles / 733); prio2!ready; prio2()().

17

Initial Mapping

Perform scan Get params

Start scan

Generated engerySetpoint

Scan queued

Scan Queued

Takes x secsQueue scan Queue

Forward Trigger

Generated engerySetpoint too late…

Setpoint too late…Trigger too late …

Control algorithm should

run at highest priority

18

Mapping: Swap Priorities

Perform scan

Start scan

Scan queued

Scan Queued

Takes x secsQueue scan Queue NO params !!

Parameter forwarding at

higher priority?

19

Forwarding: Robust Solution

Perform scanTakes x secsQueue scan QueueScan queuedScan queued

Forward

!

The deadline of 250 is no issue anymore;

forwarding can now run at user priority

20

Case Study: Conclusions• Modeling the system to analyze performance properties

was valuable– provided ‘insight’ in overall system behaviour– design document provide many details, but do not shed light

on ‘the big picture’ and are ‘dead’– executable model combines separate pieces into one unified

whole– feedback from model eases communication with design team– understand, verify and explore design alternatives before

implemented in HW/SW components– e.g. effect of priority assignments could be investigated– e.g. timing problem w.r.t. parameter forwarding was found

during model construction, provided inspiration and possibilities for verification

21

Analysis Models: Major Concerns

• Heterogeneity– specialized languages and tools for different aspects

(correctness, performance, exploration, …) – general-purpose modeling languages – what language to choose?

• Predictability– no (formal) relation between the different models and the

realization– unknown reliability/accuracy of predictions

• Refinement– analysis models are no suitable starting point for systematic

refinement / synthesis– do we have to make models just for analysis?

22

Design Models• Use models to derive implementation in a

systematic way model refinement and synthesis

Split QueueGenerate code

Light Source

FPGA

PCI-bus, 32-bit, 33MHz

PLX bridge

CPU i64-bit, 133MHz

DDR SDRAM, (183MHz)

SDRAM i

100 Mbps Ethernet

Crossbar Fabric

Switch

ActionInterface

HRT_Sync

64-bit, 133MHz

MAC

PCI

Processor 733MHz512 kB on-chip L2 cache

23

Challenge: Predictability

• Predictability– Make sure the refined model/realization behaves

as the model– Make sure that real-time model properties are

preserved• MDA/UML does not deal with these issues

(yet)– Most work on syntactic transformations key

problem is in semantics (behavior), not in syntax– No predictable commercial UML tool available

24

Predictability Problem: Example Tau G2

pwait

reply_signal ptimer

Process P

syn_signal

Charstring wout=“wrong” ;Charstring cout=“correct” ;Timer ptimer()

set(ptimer, now+3)

out_signal(cout) out_signal(wout)

reset(ptimer)

reply_signal

qwait

qtimer

qstart

syn_signal

qstart

Process QTimer qtimer()

set(qtimer, now+2.99)

Model execution semantics is not

respected by the code generators!

25

Predictable Approach• Formal Semantics: Timed Labeled Transition System • Generate timed trace from transition system

– virtual (model) time is kept– ordering of events is kept

• Run-time synchronization upto of virtual time with physical time– if an action happens at virtual time t in the model it must happen in

physical time interval (t-/2,t+/2) in implementation– every (MTL) formula in model is preserved upto in realization– epsilon can be determined by model simulation / exhaustive analysis

or by measurement– Huang, Voeten, Corporaal, Predictable real-time software synthesis,

Real-Time Systems journal (online), March 2007• Predictable method

– from abstract executable models to implementation– via property-preserving refinements– Huang, Voeten, Corporaal, A model-driven approach for mechatronic

systems, to be published in ACSD 2007

26

Example: A production cell

27

Top-level model

MoldingmachineContainer

Buffer

Sender

28

Top-level model: behavior

Input()() in? request; sel [empty=true] in! grant or [empty=false] in !

refuse; [empty=true] in ! grant les; in? finish; empty:=false; Input()().

Buffer

FeederBelt

Rotation

Output()() [empty=false]out ! request; sel out? grant or out ? refuse; out ? grant les; out ! finish; empty:=true;Output()().

Rotation

29

Top level model: properties

• Properties that can be checked:– At most one block in the buffer– The rotation player will not insert a block to the

feeder belt, if there is a block at the left end. – Nine blocks or more potential deadlock– Less than 9 blocks deadlock free– …

30

Refinement and synthesis

• Local property-preserving refinement• Separation of discrete-event and continuous

behaviour• Addition of feedback control loops (automatically

generated from 20-Sim)• Predictable code generation

31

Example: Light Control

• Starting point– Design documentation (a lot)– Performance model in POOSL

• Construct POOSL model– Powerful language constructs

• Facilitates problem domain mapping– Incremental modeling with immediate

behavioral feedback• simulation• dynamic model inspection• automatically generated MSCs

DesignLight Control

32

Model: Result

Environment (Laser)Embedded Subsystem

33

Model: Analysis

34

Model: Synthesis

1. Replace environment model with interface to environment

2. Predictable code-generation– successfully tested on platform

35

Case Studies: Conclusions

• Big picture is quickly obtained through executable model replace/supplement documentation with executable models in future

• Incremental modeling with behavioral feedback is very powerful• Expressive modeling languages narrow the gap between domain

concepts and implementation• Predictable automatic code generation is feasible• Step-wise property-preserving refinement approach works very

natural for production cell– still have to apply it to light control model– current model is too complex and detailed

• No clear relation with performance modeling – Performance prediction from top-level model e.g. is not possible

DesignDose Control

36

Future Challenges

• Code efficiency (performance, footprint)• Predictable refinement and synthesis for

multi-processor platforms• Heterogeneity

– control and data-flow– discrete-event and continuous-time– mixing hard and softly timed subsystems– hardware and software implementations

• Seamless integration of analysis and design models into Model-Driven Design Flows– for different application domains