1 from simulink to lustre to tta: a layered approach for distributed embedded applications stavros...

1

From Simulink to Lustre to TTA: a layered approach for distributed embedded

applications

Stavros TripakisVERIMAG

Joint work with:Paul Caspi, Adrian Curic, Aude Maignan, Christos

Sofronis

2

Problem and approach

• How to develop embedded software ?– Safely: safety-critical applications– Efficiently: development cost, time-to-

market

• “Model-based” approach:– High-level design models– Analysis techniques: catch bugs early– Synthesis techniques: correct-by-

construction implementations

3

Execute

Design

Implement

Our view: a development process in three layers,

supported by:Models

Programminglanguages

OS, middleware,HW architecture

Automation is key!

Semantic preservation!

4

TTA

Simulink/Stateflow

Lustre

Our work

• European IST projects:– “NEXT TTA” (2002-2004) and “RISE” (2003-2005).

• Automotive applications: – Audi.

5

A Simulink model (parts)

6

Time Triggered Architecture (TTA)

• Picture of TTA

• Time-triggered:– Processors synchronize their clocks.– Static TDMA non-preemptive scheduling for tasks running

on processors and messages transmitted on the bus.• Fault-tolerance services

7

TTA

Simulink/Stateflow

Lustre

Why these choices?

De-facto standardin automotive

Formal semantics,analysis tools,C code generators

Close to synchronous semantics, Audi likes it

8

The development process

1. Design/simulate controller in Simulink/Stateflow.

2. Translate it to Lustre.3. Verify the Lustre

program (transparent).4. Distribute the Lustre

program on TTA.5. Generate C code,

compile and run.

TTA

Simulink/Stateflow

Lustre

9

Plan of talk

• Translating Simulink to Lustre.

• Distributing Lustre on TTA.

• Tool-chain and case studies.

10

Plan of talk




11

Translating Simulink to Lustre

• We only translate discrete-time Simulink: the controller to be implemented.

• Goal: preserve semantics of Simulink.What semantics?

12

Simulink semantics

• Informal: described in documentation.

• Defined by the simulator.

• Multiple different semantics: user options.

13

Translation goal

• input/output semantics of generated Lustre program

=• input/output behaviour of original

Simulink model given by Mathworks simulator,

• assuming a fixed set of user-defined options

14

From Simulink to Lustre

• A glance into Lustre

• Translation:– Type inference– Clock inference– Hierarchical block-by-block

translation

15

A glance into Lustre• A Lustre program models an I/O automaton:

• Implementing a Lustre program:– Read inputs;– Compute next state and outputs;– Write outputs;– Update state;

memory(state)

step function(transition)

inputs outputs

Repeat atevery “trigger”(external event).

16

A glance into Lustre

• A simple Lustre program:

• No inputs• Output: x• State: pre(x) (previous value of x)

node Counter() returns(x:int);let x = 0 -> pre(x) + 1;tel

17

A glance into Lustre• Multi-clocked (e.g., multi-periodic)

systems:x = 0 -> pre(x) + 2;b = true -> not pre(b);y = x when b;

time 0 1 2 3 4 …

x 0 2 4 6 8 …

b true false true false true …

y 0 4 8 …

clock(y) = b

clock(x) = basic

18

Simulink versus Lustre

• Both data-flow style.• Both hierarchical:

– Graphical versus textual.

• Different type mechanisms:– Mandatory/explicit in Lustre, not in Simulink.

• Different timing mechanisms:– Implicit logical clocks in Lustre.– Sample times and triggers in Simulink.

A B

C

xy

z wu

sv

19

Translation steps

1. Type inference

2. Clock inference

3. Hierarchical block-by-block translation

20

Translation steps

1. Type inference

2. Clock inference


21

Simulink types• Types are not mandatory in Simulink.• Available types: double, single, int32,

int16, int8, …, boolean.• By default signals are “double”.• Basic block type signatures:

Constant , SimNum

Adder … , SimNum

Relation boolean, SimNum

Logical Operator boolean … boolean boolean

Disc. Transf. Func. double double

Data Type Conv

22

Simulink type inference• Fix-point computation on a lattice:• E.g.:

+xy

z

Fix-point equations:tx = sup(double, ty, tz)ty = sup(double, tx, tz)tz = sup(double, tx, ty)

Least fix-point:tx = ty = tz = double

error

boolean

int8single

double

…

_|

23


+xy

z

Fix-point equations:tx = int8

ty = sup(double, tx, tz)tz = sup(double, tx, ty)

Least fix-point:tx = ty = tz = int8

error

boolean

int8single

double

…

_|

int8

24


+xy

z

Fix-point equations:tx = sup(double, ty, tz)ty = sup(double, tx, tz)tz = sup(double, tx, ty, boolean, tw)tw = sup(boolean, tz)

notw

error

boolean

int8single

double

…

_|

25


+xy

z

Fix-point equations:tx = sup(double, ty, tz)ty = sup(double, tx, tz)tz = sup(double, tx, ty, boolean, tw)tw = sup(boolean, tz)

tz = error

notw

error

boolean

int8single

double

…

_|

26

The overall algorithm• Generate fix-point equations.

• Find least fix-point.

• If error, reject model.

• Otherwise, map Simulink types to Lustre types:– double, single: real– int32, int16, int8, … : int– boolean: bool

27

Translation steps

1. Type inference

2. Clock inference


28

Time in Lustre

• One mechanism (clocks) + one rule:– Cannot combine signals of different clocks:

x = 0 -> pre(x) + 2;b = true -> not pre(b);y = x when b;z = x + y;

time 0 1 2 3 4 …

x 0 2 4 6 8 …

b true false true false true …

y 0 4 8 …

Compiler error

29

Time in Simulink

• Simulink has two timing mechanisms:– sample times : (period,phase)

• Can be set in blocks: in-ports, UD, ZOH, DTF, …• Defines when output of block is updated.• Can be inherited from inputs or parent system.

– triggers :• Set in subsystems• Defines when subsystem is “active” (outputs

updated).• The sample times of all children blocks are

inherited.A

B

xy

z w

s trigger Simulink triggers=

Lustre clocks

30

Time in Simulink

• Greatest-common divisor (GCD) rule :– A block fed with inputs with different rates:

• Other timing rules, e.g.:– Insert a unit delay when passing from a

“slow” block to a “fast” block.

2 ms1 ms

xz

3 msy

31

Overview of clock inference algorithm

• Infer the sample time of every Simulink signal.

• Check Simulink’s timing rules.

• Create Lustre clocks for Simulink sample times and triggers.

– Basic clock: GCD of all sample times, e.g., 1ms.– Other clocks: multiples of basic clock, e.g.

true false true false = 2ms.

32

Sample time inference

• Basic idea: same as type inference.

– Poset with pairs (period, phase).– No error element.– p1 p2 if p1 is “multiple” of p2

• Complex definition of multiple because of phase.

– Sup is “GCD”.– Although poset is infinite, termination

guaranteed:• Can remain within a finite part of the poset (set of

all sample times in the Simulink model, closed by GCD).

33

Translation steps

1. Type inference

2. Clock inference


34

Hierarchical translation

• A Simulink model can be seen as a tree:– root system, subsystems, basic blocks (leaves).

• A simple block (+, gain, …) is translated to a basic Lustre operator (+, , …).

• Complex blocks (transfer functions, …) are translated into Lustre nodes.

• Subsystems are translated into Lustre nodes.

35

Bottom-up translation

node A(x,y) returns(s);…node B(s,u) returns(v);…node C(z) returns(u,w);…node Root(x,y,z) returns(v,w);var s, u;let s = A(x,y); v = B(s,u); (u,w) = C(z);tel

A B

C

xy

z wu

sv

Simulink model

Lustre program

36

Plan of talk




37

Distributing Lustre on TTA

• A resource allocation problem:– computation is not free– communication is not free

• First, a description problem:– express available/required resources– use annotations (“pragmas”) to do this

• Then, the distribution problem:– map Lustre code to TTA tasks and messages– schedule the tasks on processors and

messages on the bus

38


• Extend Lustre with annotations.

• Decompose a Lustre program into tasks.

• Schedule the tasks.

39





40

Annotations: code distribution

• Meaning:– The execution of Lustre node A is done at

TTA processor P1.– The output y is produced at P1.– If the input x is produced elsewhere, it must

be transmitted to P1.

y = A(x); (location = P1)

41

Annotations: timing assumptions

• Meaning:– BCET(A)=10 and WCET(A)=20.– A is a Lustre node, execution time is given

for the C code generated from A (assumed to be executed atomically).

– Different execution times for A can be given in case A is run on different processors or call by different nodes (e.g., with different inputs).

exec-time(A) in [10,20]

Note: rely on external tools for ET analysis.

42

Annotations: timing requirements

• Meaning:– The delay from availability of x until availability

of y must be at most 10 time units (deadline).– Availability:– input variables are available when they are

read,– internal variables when they are computed,– output variables when they are written.

date(y) - date(x) 10

43





44

Decomposing Lustre into tasks

Call graph anddependenciesof a Lustre program:

Node B calls B1 and B2

B2 depends onresults from B1

45



Should theentire node Bbe one task?

46



Or should therebe two tasksB1 and B2 ?

47


• Two extremes:– One task per TTA processor: too coarse,

perhaps no feasible schedule (pre-emption not allowed).

– One task for every Lustre operator: too fine, scheduling too costly (too many tasks).

• Approach:– Start with coarse partition.– Split when necessary (no feasible schedule),

based on feedback from the scheduler.– Feedback: heuristics.

48





49

Scheduling• Schedule tasks on each processor.• Schedule messages on the bus.

• Static TDMA schedules (both for bus and processors).

• No pre-emption (problem known NP-hard).

• Algorithm:– Branch-and-bound to fix order of tasks/messages.– Solve a linear program on leaves to find start

times.– Ensures deadlines are met 8 possible exec. times.

50

Scheduling

T1 ! T4, T3 ! T5

T3 ! T4

T4 ! T3

T1 ! T2

LP

Infeasible(necessaryconditions)

total order

51

Plan of talk




52

Tool chain

Sim2Lus

Simulink/Stateflow model (.mdl file)

Lustre program (.lus file)

Lustre program + annotations

: currently manual

Decomposer

Scheduler Integrator

C code generator

C compiler

Tasks + constraints

Global schedule(bus + processors)

Lustre modules+ task mapping

Glue code

C code

OSEK executables

feed

back

: on-going work

53

Case studies

• Two case studies from Audi.– A warning-filtering system:

• 6 levels, 20 subsystems, 113 total blocks.• 800 lines of generated Lustre code.

– An autonomous steer-by-wire application:• 6 levels, 18 subsystems, 157 total blocks.• 387 lines of generated Lustre code.• Demo-ed in final NEXT TTA review (Jan ‘04).

54

Autonomous steer-by-wire

The industrial demonstrator

Equipment:Equipment:• cameras/imagingcameras/imaging• steering actuatorsteering actuator• TTA networkTTA network• MPC555 nodesMPC555 nodes

55

The industrial demonstrator

Autonomous steer-by-wire

56

Conclusions and on-going work

• End-to-end tool-chain:– from design to implementation– as automatic as possible– preserving semantics– should not have to repeat analysis twice

• On-going:– Stateflow.– Moving on to event-triggered applications on

asynchronous, pre-emptive platforms.– Trying heuristics for splitting nodes

(scheduler feedback).

57

Thank you !

Questions ?

58

Two papers

• “From Simulink to Lustre to TTA …”:– in “Languages, Compilers and Tools for

Embedded Systems” (LCTES’03).

• “Translating Discrete-time Simulink to Lustre”:– in “Embedded Software” (EMSOFT’03).

1 from simulink to lustre to tta: a layered approach for distributed embedded applications stavros...

Documents