Towards predictability in realtime embedded system design LorentzARTIST

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

RT Embedded Software: ”Integration Hell” • Complexity • • many hardware/software components verified and tested in isolation… • • • system does not work difficult to locate cause of problem modifications introduce unexpected new problems • Integration • Prediction • difficult to predict properties in advance • • can only be checked late in design cycle through extensive testing • Correctness/performance 2

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

Current Practice: Objects and Threads Train A (Active Object) Crossing (Passive Object) Start_Motor(“A”, “Right”); Wait(Sensor. A); Delay(Distance. To. Crossing/Velocity); if (!Crossing. get. Access(no_block)) { Stop_Motor(“A”); Crossing. get. Access(block); Start_Motor(“A”); } Delay(Crossing. Size/Velocity); } Crossing. Release(); Wait(Sensor. D); Stop_Motor(“A”); Train B (Active Object) class Crossing{ Semaphore Sem; void Crossing(){ Sem=Create. Sem(1)} bool get. Access(bool block){ return Wait(Sem, block); } void Release(){ Signal(Sem); }} 4

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=Distance. To. Crossing/Velocity) • Execution trace: Sensor. A signaled T Delay D Check Crossing Stop motor T+D+ 1+ 2 ? 5

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

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 • 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… 7

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 • • • properties cannot be predicted from component description alone if context changes component properties change ‘prediction’ typically done through testing on target platform • Property prediction requires component context 8

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 • • automatic mapping onto target hardware platform predict properties of the realization from model properties Predictable Mapping 9

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” 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” 10

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 11

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 … • • 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 • • Kahn Process Networks (not for control, untimed) SDL Rose-RT (ROOM) POOSL • Component-based approaches address this by • Examples: 12

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 13

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 14

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 15

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 16

SDL’ 2000: Code Generation – Time Error 3. 0 2. 8 Timing Error (seconds) 2. 6 2. 4 la P et g ar T n o r r E ng i m 2. 2 2. 0 1. 8 1. 6 1. 4 1. 2 e iv t la 1. 0 mu u C 0. 8 0. 6 m r fo t Ti 0. 4 0. 2 0. 0 0 200 400 600 800 1000 1200 1400 1600 1800 Virtual Time (seconds) 17

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

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) 19

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

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 21

Demo: The Railroad Crossing • • Velocity Train. A: 40 cm/s Velocity Train. B: 90 cm/s Analysis Model Rapid analysis Synthesis Model Realization 22

23

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

Readability: the Java Cubby. Hole public class Cubby. Hole { public synchronized void put(int value) { private int contents; while (available == true) { private boolean available = false; try { public synchronized int get() { wait(); while (available == false) { } catch (Interrupted. Exception e) {} try { } wait(); contents = value; } catch available = true; (Interrupted. Exception e) {} notify. All(); } available = false; notify. All(); return contents; } } } Cubby. Hole in out empty()() in? get(v); full(v)() full(v: Object)() out!put(v); empty()() 25

Efficiency: the Java Cubby. Hole Sender Cubby. Hole (1 -place buf) Language/Tool SHESim (full POOSL, ) Java ( ) C (Pthreads, Cygwin, ) Rotalumis (full POOSL, ) C++ (POOSL fragment, ) Receiver com/sec cycles/com 2500 222000 32500000 6700000 1380000 8100 5500 3600 269 26

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 27