Presentation is loading. Please wait.

Presentation is loading. Please wait.

Towards predictability in real-time embedded system design Lorentz-ARTIST Workshop Embedded Systems November 22, 2005 Jeroen Voeten, Jinfeng Huang, Oana.

Similar presentations


Presentation on theme: "Towards predictability in real-time embedded system design Lorentz-ARTIST Workshop Embedded Systems November 22, 2005 Jeroen Voeten, Jinfeng Huang, Oana."— Presentation transcript:

1 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 Corporaal ES Group, Eindhoven University of Technology Embedded Systems Institute

2 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 3 A Toy Example: Railroad Crossing Trains run independently at different velocities Velocities are constant Avoid collisions

4 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 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+D Check Crossing T+D+  1 Stop motor T+D+  1 +  2

6 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+  +D Check Crossing T+  +D+  1 Stop motor T+  +D+  1 +  2 other active object running T+ 

7 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 changed Works 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 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 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 10 Summary-Traditional versus Predictable Bottom-up & Code-drivenTop-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 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 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 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 14 SDL’96: Clock Example Expected: n-th tm:=tm+1 action to be issued at time n Reality: 31 st tm:=tm+1 issued around 52 nd second Reason: time in model is based on physical time

15 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 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 17 SDL’2000: Code Generation – Time Error Timing Error (seconds) Virtual Time (seconds) Cumulative Timing Error on Target Platform

18 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 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 20 POOSL: Semantics POOSL Model Formal Semantics Timed Probabilistic Labelled Transition System (Segala Model) Simulation Process Execution Trees Formal Verification Model Checking Performance Analysis Worst/Best-Case Average-Case based on Markov Chain Predictable Code Generation ε -hypothesis

21 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 22 Demo: The Railroad Crossing Velocity TrainA: 40 cm/s Velocity TrainB: 90 cm/s Analysis Model Synthesis Model Rapid analysis Realization

23 23

24 24 Comparison: the Java CubbyHole Sender CubbyHole (1-place buf) Receiver empty full(v) ?get(v) !put(v)

25 25 Readability: the Java CubbyHole public class CubbyHole { private int contents; privateboolean 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()() CubbyHole inout

26 26 Efficiency: the Java CubbyHole Sender CubbyHole (1-place buf) ReceiverLanguage/Toolcom/seccycles/com SHESim (full POOSL,  ) Java (  ) C (Pthreads,Cygwin,  ) Rotalumis (full POOSL,  ) C++ (POOSL fragment,  )

27 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


Download ppt "Towards predictability in real-time embedded system design Lorentz-ARTIST Workshop Embedded Systems November 22, 2005 Jeroen Voeten, Jinfeng Huang, Oana."

Similar presentations


Ads by Google