Towards predictability in real-time embedded system design Lorentz-ARTIST Workshop Embedded Systems November 22, 2005

1. Towards predictability in real-time embedded system designLorentz-ARTIST Workshop Embedded SystemsNovember 22, 2005 Jeroen Voeten, Jinfeng Huang, Oana Florescu, Bart Theelen and Henk Corporaal ES Group, Eindhoven University of Technology Embedded Systems Institute

2. 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 RT Embedded Software: ”Integration Hell”

3. A Toy Example: Railroad Crossing • Trains run independently at different velocities • Velocities are constant • Avoid collisions

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. SensorA signaled T Delay D T+D Check Crossing T+D+1 Stop motor T+D+1+2 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  ?

6. other active object running SensorA signaled T T+ Delay D T++D Check Crossing T++D+1 Stop motor T++D+1+2 Timing Property - Add Components • Add new active objects to the software system (e.g. to control another railroad crossing) • Execution trace: +1+2  BOOM !!!

7. char x=0, y=0, z=0, w=0; thread 1: x=1; y=1; z=1 ; thread 2: w=1; A multithreaded code fragment • Works fine … probably … until platform is changed • 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. 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” Model & implementation consistency? Prediction? Model & implementation are consistent in case of feasible mapping. Prediction! “Heisenberg Testing Principle” “Tests do not influence rest” “Integration hell” “Integration heaven” Summary-Traditional versus Predictable

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. Cumulative Timing Error on Target Platform SDL’2000: Code Generation – Time Error 3.0 2.8 2.6 2.4 2.2 2.0 1.8 1.6 Timing Error (seconds) 1.4 1.2 1.0 0.8 0.6 0.4 0.2 0.0 0 200 400 600 800 1000 1200 1400 1600 1800 Virtual Time (seconds)

18. Process P Process Q Charstring wout=“wrong” ; Charstring cout=“correct” ; Timer ptimer() Timer qtimer() qstart syn_signal syn_signal set(ptimer, now+3) set(qtimer, now+2.99) pwait qwait ptimer reply_signal qtimer out_signal(cout) out_signal(wout) reply_signal reset(ptimer) qstart SDL’2000: Code Generation – Event Order Error

19. POOSL Source: X.Nicollin, J.Sifakis ’91 • 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)

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

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 • Velocity TrainA: 40 cm/s • Velocity TrainB: 90 cm/s Analysis Model Rapid analysis Synthesis Model Realization

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

25. CubbyHole in out empty()() in?get(v);full(v)() full(v:Object)() out!put(v);empty()() 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(); } }

26. Efficiency: the Java CubbyHole CubbyHole (1-place buf) Sender Receiver

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