Towards predictability in real-

time embedded system design

Lorentz-ARTIST Workshop Embedded Systems

November 22, 2005 Jeroen Voeten, Jinfeng Huang, Oana Florescu,

Bart Theelen and Henk CorporaalES Group, Eindhoven University of Technology

Embedded Systems Institute

2

RT Embedded Software: ”Integration Hell”

•Complexity • many hardware/software components

• verified and tested in isolation…

•Integration• system does not work

• difficult to locate cause of problem

• modifications introduce unexpected new problems

•Prediction• difficult to predict properties in advance

•Correctness/performance • can only be checked late in design cycle

• through extensive testing

3

A Toy Example: Railroad Crossing

•Trains run independently at different velocities

•Velocities are constant

•Avoid collisions

StationStation

Station

B

AA D

D

A

Critical zone

Crossingarea

Station

B CB

C

4

Current Practice: Objects and Threads

Train A(Active Object)

Crossing(Passive Object)

Train B(Active Object)

Start_Motor(“A”, “Right”);Wait(SensorA);Delay(DistanceToCrossing/Velocity);if (!Crossing.getAccess(no_block)) { Stop_Motor(“A”); Crossing.getAccess(block); Start_Motor(“A”);}Delay(CrossingSize/Velocity);}Crossing.Release();Wait(SensorD);Stop_Motor(“A”);

class Crossing{Semaphore Sem;

void Crossing(){ Sem=CreateSem(1)}

bool getAccess(bool block){ return Wait(Sem, block);}

void Release(){ Signal(Sem);}}

5

Timing Property

•Between D and D+ seconds after Train A has passed Sensor A, check the Crossing and if it is occupied stop the train (D=DistanceToCrossing/Velocity)

•Execution trace:

1+2 ?

SensorA signaled T

Delay D

T+DCheck Crossing

T+D+1Stop motor T+D+1+2

6

Timing Property - Add Components

•Add new active objects to the software system (e.g. to control another railroad crossing)

•Execution trace:

+1+2 BOOM !!!

SensorA signaled T

Delay D

T++DCheck Crossing

T++D+1

Stop motor T++D+1+2

other active object running

T+

7

A multithreaded code fragment

char x=0, y=0, z=0, w=0;thread 1: x=1; y=1; z=1 ;thread 2: w=1;

•Works fine … probably … until platform is changedWorks fine … probably … until platform is changed

•POSIX threads on Intel® Itanium®POSIX threads on Intel® Itanium®

•Any variable may be zero after both threads finish!

•Multicore and hyperthreading platforms will make such problems happen more often in future…

8

Property Prediction is Difficult!

•Execution semantics of component: All possible execution traces a component can be involved in

•A component satisfies a property if it is satisfied for each execution trace

•Execution semantics is context-dependent:• processor platform

• RTOS

• compiler

• other software components in the system

•Property prediction requires component context• properties cannot be predicted from component description

alone

• if context changes component properties change

• ‘prediction’ typically done through testing on target platform

9

Predictable Approach: Principles

Compositional Modeling Language• context-independent semantics: all possible traces the

component can be engaged in irrespective of context– compositionality: properties of composite deducible from

properties of constituent

– composability: properties of a component are preserved when context changes

• expressive (concurrency, time, succinct models, …)

• executable

Predictable Mapping• automatic mapping onto target hardware platform

• predict properties of the realization from model properties

10

Summary-Traditional versus Predictable

Bottom-up & Code-driven Top-down & Model-driven

“Here is the code – let’s see how it executes”

“This is the model – execute it according its semantics”

“Heisenberg Testing Principle” “Tests do not influence rest”

“Integration heaven”“Integration hell”

Model & implementation consistency? Prediction?

Model & implementation are consistent in case of feasible

mapping. Prediction!

11

Active Objects and Compositionality?

•Then for each (active) object we need to: •Assume potentially unbounded execution times

•Interpret Delay(T) as ‘delay at least T’

•Suspect interference with any other object at any time

•Result•Impossible to establish any real-time properties

•Difficult to establish other properties (such as invariants)

•Conclusion: active objects do not encourage a compositional way of working

12

Component-based Approaches

•Active objects cannot protect themselves well against unwanted interactions with environment• yielding a tremendous amount of non-determinism

• semaphores/monitors/locks help, but are difficult to work with …

•Component-based approaches address this by• strong encapsulation

• component interaction only via well-defined interfaces

• interaction often based on message passing

• component can decide at any time not to accepts message

•Examples:• Kahn Process Networks (not for control, untimed)

• SDL

• Rose-RT (ROOM)

• POOSL

13

SDL’96

•Tool: Cinderella

•Model has context-dependent timing semantics•simulation results depend on platform

•simulation results depend on other processes in system

•No automatic code generation

Compositional Modeling Language Predictable Mapping

14

SDL’96: Clock Example

•Expected: n-th tm:=tm+1 action to be issued at time n

•Reality: 31st tm:=tm+1 issued around 52nd second

•Reason: time in model is based on physical time

15

ROOM

•Tool: Rose-RT (IBM)

•Model has context-dependent timing semantics•simulation results depend on platform

•simulation results depend on other processes in system

•Automatic code generation

•Real-time properties of realization cannot be predicted from model

Compositional Modeling Language Predictable Mapping

16

SDL’2000

•Tool: Tau Generation 2 (Telelogic)

•Model has compositional (timing) semantics•established by virtual (model) time concept

•predictability support during modeling

•Automatic code generation

•Neither timing nor event ordering can be predicted from model

Compositional Modeling Language Predictable Mapping

17

SDL’2000: Code Generation – Time Error

0 200 400 600 800 1000 1200 1400 1600 18000.0

0.2

0.4

0.6

0.8

1.0

1.2

1.4

1.6

1.8

2.0

2.2

2.4

2.6

2.8

3.0

Tim

ing E

rror

(seco

nds)

Virtual Time (seconds)

Cumulative Tim

ing Error o

n Target

Platform

18

SDL’2000: Code Generation – Event Order Error

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 Q

Timer qtimer()

set(qtimer, now+2.99)

19

POOSL

•Parallel Object-Oriented Specification language

•Expressive and executable •asynchronous concurrency

•synchronous message passing

•object-oriented data

•real-time and stochasticity

•dynamic process creation

•Formal (compositional) semantics•two-phase execution model (X.Nicollin, J.Sifakis ‘91)

•Tools: SHESim and Rotalumis (RT)

Source: X.Nicollin, J.Sifakis ’91

20

POOSL: Semantics

POOSLModel

FormalSemanticsTimed ProbabilisticLabelled Transition

System(Segala Model)

SimulationProcess Execution Trees

Formal Verification

Model Checking

Performance Analysis

Worst/Best-CaseAverage-Case based on

Markov Chain

Predictable Code

Generation

ε-hypothesis

21

Code Generation: the -hypothesis

•Generate timed trace from transition system• Process Execution Trees, no RTOS, no threads

• ordering of events is kept

•Run-time synchronization upto of virtual time with physical time

•Epsilon-hypothesis• if an action happens at virtual time t in the model it must happen in

physical time interval (t-/2,t+/2) in implementation

•In case hypothesis is satisfied every (MTL) formula in model is preserved upto in realization

•Epsilon can be determined by modeling/analysis or measurement

Compositional Modeling Language Predictable Mapping

22

Demo: The Railroad Crossing

StationStation

Station

B

AA D

D

A

Critical zone

Crossingarea

Station

B CB

C

- 100 - 50 50 100 cm

- 100

50

100

•Velocity TrainA: 40 cm/s

•Velocity TrainB: 90 cm/s

Analysis Model

Synthesis Model

Rapid analysis

Realization

23

24

Comparison: the Java CubbyHole

Sender CubbyHole(1-place buf)

Receiver

empty full(v)

?get(v)

!put(v)

25

Readability: the Java CubbyHole

public class CubbyHole {

private int contents;

private boolean available = false;

public synchronized int get() {

while (available == false) {

try {

wait();

} catch

(InterruptedException e) {}

}

available = false;

notifyAll();

return contents;

}

public synchronized void put(int value) {

while (available == true) {

try {

wait();

} catch (InterruptedException e) {}

}

contents = value;

available = true;

notifyAll();

}

}

empty()() in?get(v);full(v)()

full(v:Object)() out!put(v);empty()()

CubbyHolein out

26

Efficiency: the Java CubbyHole

Sender CubbyHole(1-place buf)

Receiver

Language/ToolLanguage/Tool com/com/secsec

cycles/cycles/comcom

SHESim (full POOSL,SHESim (full POOSL,)) 25002500 13800001380000

Java (Java ()) 222000222000 81008100

C (Pthreads,Cygwin,C (Pthreads,Cygwin,)) 325000325000 55005500

Rotalumis (full POOSL,Rotalumis (full POOSL,)) 500000500000 36003600

C++ (POOSL fragment,C++ (POOSL fragment,)) 67000067000000

269269

27

Open Issues and Current Work

•Multi-processor platforms•Predictable mapping

•globally asynchronous time; different clocks with different clock drifts

•Efficiency•reduce run-time scheduling overhead (partial-order

reduction)

•reduce PET overhead (static unfolding of transition system)

•Streaming•dealing with time-intensive actions

•use of abstraction, factor out equivalence