A hierarchical coordination language for reliable real-time tasks

1. A hierarchical coordination language for reliable real-time tasks Arkadeb Ghosal University of California, Berkeley Dissertation Talk CHESS Seminar 22nd January, 2008

2. Overview of the presentation • Introduction and Motivation • Logical Execution Time • Logical Reliability Constraint • Hierarchical Timing Language • Comparison and Conclusion Dissertation Talk

3. The interdependence between functional and real-time semantics of real-time software makes its design, implementation and maintenance especially difficult. Providing a programming language that directly supports the characteristics of embedded real-time software can significantly ease these difficulties. In addition, embedded software systems are not portable as they depend on the particular underlying operating system and hardware architecture. Providing implementation-independent programming models also increases the portability. Chapter 25. Programming Languages for Real-Time Systems Embedded Systems Design The ARTIST Roadmap for Research and Development Dissertation Talk

4. X-by-wire systems replace mechanical couplings Braking Shifting Steering Brake-by-wire Shift-by-wire Steer-by-wire Dissertation Talk

5. Estimated Cost 200 % Number of ECUS 150 % Software Size 9900% Growth of electronic control and software in automobiles Mechanical 76 Electronics 13 Software 02 Others 09 Mechanical 55 Electronics 24 Software 13 Others 08 Development effort for automotive related software (Japan / year): $903 million to $9.1 billion (by 2014 ) 1960s 1970s 1980s 1990s 2000s 2010s 2020s Design complexity is growing at an alarming rate Concurrency, Composability, Time, Hierarchy, Heterogeneity, Verifiability Resource Constraints, Reliability, Platform Limitation, Distribution, Communication Faster Time to Market, OEM, Option Packaging, Extensibility, Interface Validation Standardization, Laws, Calibration Sets, Market, Safety, Validation Time Source: General Motors and Nihon Keizai Shimbun Dissertation Talk

6. Steering Feedback Common Semantics Domain (Platform) ECU1 ECU2 MCUFL MCURL Application Space Architecture Space ECU4 MCUFR ECU3 MCURR f2 f1 h1 h3 f3 h2 Handling complexity by separation of concerns Function definitions with dependencies Communication and Computation Resources Steering Functionality: Motor Current and Steer Feedback Computation, Supervisory Control, Fault Handling, Power Coordination System Behavior System Platform Mapping Sensors: Desired Steer/ Torque, Wheel Angle/ Speed, Motor Current/ Torque, Friction/ Pitch/ Yaw/ Roll Performance Analysis Actuators: Wheel Motor Actuation, Steer Feedback, Warning Synthesis The specific architecture used here is a simplified Steer-By-Wire model used by General Motors for their prototype hydrogen fuel-cell car FX-3. Dissertation Talk

7. Overview of the presentation • Introduction and Motivation • Logical Execution Time • Logical Reliability Constraint • Hierarchical Timing Language • Comparison and Conclusion Dissertation Talk

8. input read output written release event Logical Execution Time (LET) termination event { Logical active { running running Physical release start preemption resume completion termination Logical Execution Time (LET) Model The LET model of task execution decouples the times when a task reads input and writes output from the time when the task executes Time-safe LET tasks are time and value deterministic, portable and composable Dissertation Talk

9. release event release event release event release event Logical Execution Time Logical Execution Time termination event termination event termination event termination event t1 t2 t2 t t1 LET and time-safety WCET(t) ≤ LET(t) t t WCET(t1) + WCET (t2) ≤ LET e.g. rate monotonic t2 t1 t2 t1 Aperiodic task scheduling t2 t1 t2 t1 Dissertation Talk

10. Features of LET model Time determinism Value determinism Portability Composability Dissertation Talk

11. Comparison Priorities to specify the relative deadlines of software tasks Task evaluations are made available as soon as the execution is complete Supports efficient code generation based on scheduling theory Resulting run-time behavior is highly non-deterministic code efficiency code predictability Logical Execution Model mathematical expressiveness computational realities Synchrony assumption Execution is sufficiently fast to complete before the arrival of next event Ensures deterministic behavior and supports formal verification Non-trivial to compile for non-negligible execution times and distribution Dissertation Talk

12. t2 t2 a2 t1 a13 a13 t1 t3 t3 a13 Schedulability-preserving refinement abstract specification concrete specification one concrete specification two Dissertation Talk

13. t1 t2 t1 t2 Checking refinement vs. checking schedulability • If an abstract specification is time-safe (schedulable), then any concrete specification that refines the abstract specification is also time-safe (schedulable) • Sufficient condition • Price is over approximate of resource usage • Checking refinement is simpler than checking schedulability Parallel Composition Requires rescheduling (unless it is a refinement) Vertical Extension Refinement of Tasks (does not require rescheduling) Dissertation Talk

14. Communicators and LET tasks A communicator is a typed variable that can be accessed (read from or written to) only at specific time instances (specified through a communicator period) t1 reads 2nd instance of c1 t1 reads 2nd instance of c2 t1 updates 4th instance of c2 t1 updates 4th instance of c3 LET for task t1 c3 c3 c3 c3 c2 c2 c2 c2 c2 c1 c1 c1 c1 c1 c1 c1 0 1 2 3 4 5 6 7 8 9 10 11 12 Dissertation Talk

15. Communicators and determinism • Exhibit deterministic behavior • Given sufficient CPU speed for time-safety, the real-time behavior is determined by the input, independent of the CPU speed and utilization • Race free • Different tasks cannot write to the same instance of a communicator • Write precedes read • Every communicator instance is updated before it is read actuator reads a (possibly through drivers) sensor writes s (possibly through drivers) t1 writes c t1 c c a a s s t2 reads c t2 Dissertation Talk

16. Schedulability of group of tasks LET for task t4 LET for task t3 LET for task t2 LET for task t1 c4 c4 c4 c4 c4 c3 c3 c3 c3 c2 c2 c2 c2 c2 c1 c1 c1 c1 c1 c1 c1 0 1 2 3 4 5 6 7 8 9 10 11 12 Dissertation Talk

17. Schedulability-preserving refinement LET for task t4 LET for task t3 LET for task t2 LET for task t1 LET for task t5 LET for task t6 LET for task t7 wcet (t5) <= wcet (t4); wcet (t6) <= wcet (t3); wcet (t7) <= wcet (t1) Dissertation Talk

18. Overview of the presentation • Introduction and Motivation • Logical Execution Time • Logical Reliability Constraint • Hierarchical Timing Language • Comparison and Conclusion Dissertation Talk

19. Reliability • Separation of requirements from guarantees • Timing requirements through LETs • Performance guarantees through WCETs • Separation of application from architecture • Release and termination times are application dependent “logical” information • WCETs are architecture dependent “physical” data • Extending the approach for reliability • Separation of reliability requirement from performance guarantee • Separation of application dependent “logical” reliability from architecture dependent “physical” data Dissertation Talk

20. Logical (long-term) Reliability Constraint (LRC) • Each communicator has an LRC, a real number between 0 and 1 • LRC = 0.9 means in the long run, at least 0.9 fraction of all periodic writes to the communicator are required to be valid • A requirement on the specification • Similar to the concept of release times and termination times in LET 2 4 ● 2 3 1 5 4 6 4 8 4 3 4 ● 3 4 6 4 8 c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 1 + 1 + 0 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 0 + 1 + 1 + 1 + 1 + 1 = 18/20 = 0.9 Dissertation Talk

21. h h t h Singular (short-term) Reliability Guarantee (SRG) • Guarantee of updating a communicator with valid value in one step • A real number between 0 and 1 • SRG = 0.95 means that the probability that a communicator gets a reliable value at write instance is at least 0.95 • Similar to the concept of WCET in schedulability analysis specification architecture1 architecture2 s a reliability = 0.8 SRG = .96 LRC = 1 LRC = 0.9 reliability = 0.95 SRG = 0.95 Dissertation Talk

22. Assumption on architecture and inputs • Hosts are fail-silent • A host either works correctly or stops functioning (becomes silent) • Hosts are connected over a reliable broadcast network • Tasks algorithms are “correct” • If a task executes reliably, the output is correct • Input is reliable • Unreliability of inputs can be accounted through three models • If an input is unreliable, the task uses a pre-defined value • If any one of the inputs fails, the task fails to execute • If all inputs are unreliable, the task fails to execute; if a subset of the inputs fail then the task may execute Dissertation Talk

23. t2 t1 Reliability-preserving refinement c1 c2 LRC(c2) ≤ LRC(c1) If LRC(c1) is satisfied, then LRC(c2) will be satisfied Dissertation Talk

24. Comparison LET and WCET LRC and SRG • Separation of timing requirements (LETs) from performance guarantees (WCETs) • Release and termination times are application dependent “logical” information • WCETs are platform dependent “physical” data • Separation of reliability requirements (LRCs) from reliability guarantees (SRGs) • LRCs are application dependent “logical” information • SRGs are platform dependent “physical” data • Analysis ensures that implementation matches • the logical information against the physical data for schedulability and reliability Dissertation Talk

25. Schedulability analysis vs. reliability analysis • For all tasks, time safety is ensured • All replications of a task complete execution and transmission within task LET • For all communicator, long-run average of the number of reliable values observed at access points is at least LRC of the communicator • For race-free, memory-free specification, SRG of a communicator should be no less than the corresponding LRC • Refinement constraints ensure that if a specification is schedulable then refinement is schedulable for the matching implementation • Refinement constraints ensure that if a specification is schedulable then refinement if reliable for the matching implementation Dissertation Talk

26. Overview of the presentation • Introduction and Motivation • Logical Execution Time • Logical Reliability Constraint • Hierarchical Timing Language • Comparison and Conclusion Dissertation Talk

27. Hierarchical Timing Language (HTL) • A coordination language i.e. individual tasks for computation and communication are implemented in ‘foreign’ languages • Computational units are LET tasks • Communication model is centered around communicators • Allows sequential, conditional and parallel composition of tasks • Allows refinement of abstract tasks into concrete tasks • Schedulability-preserving refinement and reliability-preserving refinement Dissertation Talk

28. Mode A group of tasks with identical frequencies and possibly direct communication t2 reads 5th instance of c1 t2 updates 6h instance of c1 t1 reads 2nd instance of c1 t1 reads 2nd instance of c2 task t2 t1 updates 5th instance of c1 task t1 t3 updates 5th instance of c2 task t3 c4 c4 c4 c4 c4 c3 c3 c3 c3 c2 c2 c2 c2 c2 c1 c1 c1 c1 c1 c1 c1 0 1 2 3 4 5 6 7 8 9 10 11 12 Dissertation Talk

29. t7 t1 t4 t3 t8 t6 t5 t2 mode m2 t9 mode m1 mode m21 mode m31 mode m11 mode m22 mode m12 mode m32 mode m23 mode m13 module M1 module M2 module M3 program P Module and Program Modes may switch at the end of mode periods Module is a network of modes and mode switches: sequential and conditional composition Program is a set of modules: parallel composition Dissertation Talk

30. Refinement A mode in a program can be replaced by another HTL program A program with arbitrary levels of refinement can be translated into one with none Refinement allows structured and concise specification without overloading analysis Dissertation Talk

31. t7 t4 t8 t6 t9 t5 mode m t42 t83 t41 t62 t61 t93 t52 t51 m3 m2 m1 Refinement on precedence tasks A program refines one and only one mode program P refines mode m Every task in m1 maps to a task in m Placeholder in analysis Period of all modes in P is same as the period of m No unsafe termination Any two tasks in two modes of sibling modules of P maps to distinct tasks in m Unique placeholder for parallel tasks Timing and resource constraints same as earlier Dissertation Talk

32. Refinement • Allows choice and change in task functionality; refinement only constrains the timing behavior of the concrete task and not the functional behavior • Choice is expressed when an abstract task is refined by multiple concrete tasks each denoting different execution scenario • Change is expressed when a concrete task, refining an abstract task, reads from and writes to different communicators than the abstract task • Allows adding and replacing parts of program without overloading analyses • Refinements may be added later without repeating the schedulability analysis and/or modifying the timing interfaces of other tasks • A refinement can be replaced by another refinement without change in analyses Dissertation Talk

33. nml emg hi lo hi lo hi start lo nml lo hi lo hi deg idle motion manual fault1 manual cruise cruise fault2 crawl average under steering over steering no fault2 no fault1 fault1 fault2 Steer-by-wire in HTL sensor [rr, rl, fl, fr] actuator [rr, rl, fl, fr] control steer feedback power fault diagnosis supervisor http://htl.cs.uni-salzburg.at Thanks to Sri Kanajan and Claudio Pinello, General Motors Research Dissertation Talk

34. Three Tank Controller Dissertation Talk

35. Helicopter Control Dissertation Talk

36. Program Definition Program = (communicators, modules) Communicator = (type, initial value, period, lrc) Module = (ports, tasks, modes, start mode) Port = (type, initial value) Task = (set of input types, set of output types, function) Mode = (period, task invocations, mode switches, program) Task invocation = (input ports / communicators, output ports / communicators, task) Mode switches = (condition, destination mode) Architecture = set of hosts connected over broadcast network , set of sensors Performance guarantee = reliability of hosts/ sensors, WCET/WCTT of tasks Implementation = mapping of root modules to hosts Dissertation Talk

37. Constraints • Determinism • Structural and execution constraints • Schedulability-preserving refinement • Constraints on timing behavior of tasks • Constraints on performance guarantee of tasks • Reliability-preserving refinement • Constraints on input/output interface of tasks • Constraints on mode switches Dissertation Talk

38. Analysis Abstract Implementation of I (map of root modules of P to A) Abstract program of P (root program without refinement) Architecture (hosts connected over broadcast network) schedulability- and reliability- preserving refinement constraints Constraints (WCET/WCTT of tasks reliability of hosts and sensors) Implementation, I (map of root modules of P to A) HTL program, P (hierarchical program) If abstract implementation is schedulable and reliable, then implementation is reliable and schedulable Dissertation Talk

39. From specification to implementation Dissertation Talk

40. Overview of the presentation • Introduction and Motivation • Logical Execution Time • Logical Reliability Constraint • Hierarchical Timing Language • Comparison and Conclusion Dissertation Talk

41. communications avionics automotive applications dataflow Simulink synchronous reactive Giotto models Java C++ VHDL programs X86 programs FPGA configurations executables microprocessors MOSIS chips FPGAs silicon chips The design flow Actor-Oriented Design: A focus on domain-specific languages for embedded systems, MEMOCODE 2004 Prof Edward Lee. Dissertation Talk

42. design capture (MoC, action automaton) mapping (common semantics domain) abstraction levels communication property checking (schedulability, reliability, deadlock) static analysis of performance (power, quality) verification computation coordination design mapping, cache size, address map memory sizing, platform exploration design tasks SW code generation, SW/HW generation RTL generation, Implementation synthesis and HTL Design Environment for Electronic Systems (based on the principles of Platform Based Design) Dissertation Talk

43. Tagged Signal Model Process Network Semantics Kahn Process Network Firing Semantics TM Stateful Firing Semantics xGiotto Giotto TDL Discrete Event Synchronous/ Reactive Hybrid Systems Continuous Time Ptolemy and HTL Modeling, Simulation, and Design of concurrent, real-time, embedded systems (using well-defined models of computation) Dissertation Talk Thanks to Prof. Edward A. Lee

44. Timed Languages • Giotto: time periodic multi-modal Giotto: A time-triggered language for embedded programming. Henzinger, Horowitz, Kirsch • Timed-Multitasking: LET expressed through deadlines Timed multitasking for real-time embedded software.Liu, Lee • Timing Definition Language: time periodic multi-modal Transparent distribution of real-time components based on logical execution time. Farcas, Pree, Templ • xGiotto: event triggered language Event-driven programming with logical execution times. Ghosal, Henzinger, Kirsch, Sanvido • Timing Specification Language:Giotto with precedence Timed Input / Output Determinacy for Tasks with Precedence constraints. Iercan, Ghosal Dissertation Talk

45. mode m5 (period 5) mode m10 (period 10) mode m1 (period 10) mode m2 (period 10) t1 t3 t1 t1 t1 t1 t2 t2 t2 t2 t2 t5 t5 t5 t5 mode m51 (period 5) t4 t4 t4 t4 mode m52 (period 5) t4 t5 HTL and Timed languages Giotto, Timing Definition Language, xGiotto, Timed-Multitasking Unit delay model, LET tied to period, flat structure t1 t2 Reducing latency, LET flexibility, LET for Task Groups Logical reliability model Task refinement , schedulability- and reliability-preserving refinement Code generation that explicitly addresses hierarchy and replication Dissertation Talk

46. HTL and Synchronous languages • Event arrival handling in HTL is based on synchrony assumption • HTL program and causal synchronous programs are deterministic • HTL is a coordination language while synchronous languages are not • HTL offers an explicit program structure that supports refinement of tasks into task groups with precedence • Burden for well-definedness of program is shifted from logical fixed-point considerations to physical schedulingand/or replication • Preserving schedulability and reliability through refinement • Code generation technique differs in accounting for hierarchical structure and in generating code for a virtual machine Dissertation Talk

47. Future Work • Synthesis • Does an implementation exist for given program and an architecture ? • Imprecise computation • Is it OK even if the task do not complete by termination event ? • Power • How to account for power in an equivalent logical power model ? • Input failure pattern • Is it possible to account for complex input failure patterns ? • Redundancy • Instead of replication on multiple hosts, can the LET invoke multiple executions ? • Communication • How to account for point-to-point link instead of broadcast communication ? • Event triggers • How to include event triggered tasks in this framework ? • Cost • Is it possible to account for monetary cost of the implementation ? Dissertation Talk

48. References • Ghosal, Henzinger, Iercan, Kirsch, Sangiovanni-Vincentelli. A hierarchical coordination language for interacting real-time tasks. EMSOFT 2006 • Ghosal, Iercan, Kirsch, Henzinger, Sangiovanni-Vincentelli. Separate compilation of hierarchical real-time programs into linear-bounded embedded machine code. APGES 07 • Chatterjee, Ghosal, Iercan, Kirsch, Henzinger, Pinello, Sangiovanni-Vincentelli. Logical reliability of interacting real-time tasks. DATE 2008 • Ghosal. A hierarchical language for reliable real-time tasks. PHD Thesis • http://htl.cs.uni-salzburg.at HTL home page • Ghosal, Henzinger, Kirsch, Sanvido. Event-driven programming with logical execution times. HSCC 2004 • Ghosal, Zavala, Sanvido, Hedrick. Implementation of AFR controller in an event-driven real-time language. ACC 2005 • Iercan, Ghosal. Timed input/output determinacy for tasks with precedence constraints. CONTI 2006 • Ghosal, Kanajan, Urbance, Sangiovanni-Vincentelli. An initial study on monetary cost evaluation for the design of automotive electrical architectures. SAE 2007 • Ghosal, Kanajan, Sangiovanni-Vincentelli. A study on monetary cost analysis for product line architectures. SAE 2008 Dissertation Talk

49. Conclusion • A coordination language i.e. individual tasks for computation and communication are implemented in ‘foreign’ languages • Targeted for reliable real-time applications • Specification allows parallel composition andrefinementof tasks • Incorporatesschedulability-preserving refinement • Incorporatesreliability-preserving refinement • Compiler, implementation and examples at http://htl.cs.uni-salzburg.at Dissertation Talk

50. Acknowledgments Alberto Sangiovanni-Vincentelli Thomas A. Henzinger Christoph M. Kirsch Daniel Iercan Krishnendu Chatterjee Claudio Pinello Dissertation Talk