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

 Introduction and Motivation  Logical Execution Time  Logical Reliability Constraint  Hierarchical Timing Language  Comparison and Conclusion Overview of the presentation Dissertation Talk201/22/2008

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 Talk301/22/2008

X-by-wire systems replace mechanical couplings Dissertation Talk BrakingShiftingSteering Shift-by-wireBrake-by-wireSteer-by-wire 401/22/2008

Design complexity is growing at an alarming rate Dissertation Talk 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 Estimated Cost200 % Number of ECUS150 % Software Size 9900% 1970s1990s2020s2000s2010s1980s1960s Mechanical 76 Electronics 13 Software 02 Others 09 Mechanical55 Electronics24 Software13 Others08 Growth of electronic control and software in automobiles Development effort for automotive related software (Japan / year): $903 million to $9.1 billion (by 2014 ) Source: General Motors and Nihon Keizai Shimbun 501/22/2008

Handling complexity by separation of concerns Dissertation Talk Common Semantics Domain (Platform) Application Space Architecture Space Sensors: Desired Steer/ Torque, Wheel Angle/ Speed, Motor Current/ Torque, Friction/ Pitch/ Yaw/ Roll Actuators: Wheel Motor Actuation, Steer Feedback, Warning Steering Functionality: Motor Current and Steer Feedback Computation, Supervisory Control, Fault Handling, Power Coordination Synthesis Performance Analysis System Behavior System Platform Mapping Function definitions with dependencies Communication and Computation Resources f1 f2 f3 h1 h2 h3 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. Steering Feedback MCU RL ECU1 ECU2 ECU3 ECU4 MCU FL MCU RR MCU FR 601/22/2008

 Introduction and Motivation  Logical Execution Time  Logical Reliability Constraint  Hierarchical Timing Language  Comparison and Conclusion Overview of the presentation Dissertation Talk701/22/2008

Logical Execution Time (LET) Model Dissertation Talk active Logical Execution Time (LET) { Logical release eventtermination event releasestartpreemptionresumecompletiontermination running { Physical Time-safe LET tasks are time and value deterministic, portable and composable The LET model of task execution decouples the times when a task reads input and writes output from the time when the task executes input read output written 801/22/2008

LET and time-safety Dissertation Talk t Logical Execution Timerelease eventtermination event tt t2 t1 Logical Execution Timerelease eventtermination event t1 t2 t1 release eventtermination event t1 t2 release eventtermination event WCET(t) ≤ LET(t) WCET(t1) + WCET (t2) ≤ LET e.g. rate monotonic Aperiodic task scheduling 901/22/2008

Features of LET model Dissertation Talk Time determinismValue determinism PortabilityComposability 1001/22/2008

Comparison Dissertation Talk Priorities to specify the relative deadlines of software tasks Task evaluations are made available as soon as the execution is complete Logical Execution Model code efficiency mathematical expressiveness Supports efficient code generation based on scheduling theory Resulting run-time behavior is highly non-deterministic 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 code predictability computational realities 1101/22/2008

Schedulability-preserving refinement Dissertation Talk t1t2a13t2t3a13a2t3a13t1 abstract specification concrete specification oneconcrete specification two 1201/22/2008

 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 Checking refinement vs. checking schedulability Dissertation Talk t1 t2t1 t2 Parallel Composition Requires rescheduling (unless it is a refinement) Vertical Extension Refinement of Tasks (does not require rescheduling) 1301/22/2008

Communicators and LET tasks Dissertation Talk LET for task t1 t1 updates 4 th instance of c3 t1 reads 2 nd instance of c1 t1 reads 2 nd instance of c2 t1 updates 4 th instance of c2 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) c1 c2 c3 1401/22/2008

 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 Communicators and determinism Dissertation Talk ss t1 t1 writes c cc aa t2 t2 reads c sensor writes s (possibly through drivers) actuator reads a (possibly through drivers) 1501/22/2008

Schedulability of group of tasks Dissertation Talk c1 c2 LET for task t1 c3 c4 LET for task t2 LET for task t3 LET for task t4 1601/22/2008

Schedulability-preserving refinement Dissertation Talk LET for task t1 LET for task t2 LET for task t3 LET for task t4 LET for task t7 LET for task t6 LET for task t5 wcet (t5) <= wcet (t4); wcet (t6) <= wcet (t3); wcet (t7) <= wcet (t1) 1701/22/2008

 Introduction and Motivation  Logical Execution Time  Logical Reliability Constraint  Hierarchical Timing Language  Comparison and Conclusion Overview of the presentation Dissertation Talk1801/22/2008

 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 Reliability Dissertation Talk1901/22/2008

 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 Logical (long-term) Reliability Constraint (LRC) Dissertation Talk c1 24 ● 264 ● = 18/20 = /22/2008

 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 Singular (short-term) Reliability Guarantee (SRG) Dissertation Talk t sa LRC = 1LRC = 0.9 h specificationarchitecture1 h reliability = 0.8SRG =.96 reliability = 0.95SRG = 0.95 h architecture2 2101/22/2008

 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 Assumption on architecture and inputs Dissertation Talk2201/22/2008

Reliability-preserving refinement t1t2 Dissertation Talk c1 c2 LRC(c2) ≤ LRC(c1) If LRC(c1) is satisfied, then LRC(c2) will be satisfied 2301/22/2008

LET and WCET LRC and SRG Dissertation Talk  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 Comparison Analysis ensures that implementation matches the logical information against the physical data for schedulability and reliability 2401/22/2008

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 Talk2501/22/2008

 Introduction and Motivation  Logical Execution Time  Logical Reliability Constraint  Hierarchical Timing Language  Comparison and Conclusion Overview of the presentation Dissertation Talk2601/22/2008

 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 Hierarchical Timing Language (HTL) Dissertation Talk2701/22/2008

Mode Dissertation Talk c1 c2 c3 c4 task t1 t1 reads 2 nd instance of c1 t1 reads 2 nd instance of c2 task t3 t3 updates 5 th instance of c2 task t2 t2 reads 5 th instance of c1 t2 updates 6 h instance of c1 A group of tasks with identical frequencies and possibly direct communication t1 updates 5 th instance of c1 2801/22/2008

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

Refinement Dissertation Talk 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 3001/22/2008

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

 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 Refinement Dissertation Talk3201/22/2008

Steer-by-wire in HTL controlfault diagnosis steer feedback powersupervisor over steering under steering idle motion crawl average manual cruise manual cruise fault1 fault2 no fault1 fault2 no fault2 fault1 sensor [rr, rl, fl, fr] actuator [rr, rl, fl, fr] lohi lo hi startnml deg lohi lohilohi nml emg Thanks to Sri Kanajan and Claudio Pinello, General Motors Research 01/22/2008Dissertation Talk33

Three Tank Controller 01/22/2008Dissertation Talk34

Helicopter Control 01/22/2008Dissertation Talk35

Program Definition 01/22/2008Dissertation Talk36 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) Program = (communicators, modules) 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

 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 Constraints Dissertation Talk3701/22/2008

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

From specification to implementation Dissertation Talk3901/22/2008

 Introduction and Motivation  Logical Execution Time  Logical Reliability Constraint  Hierarchical Timing Language  Comparison and Conclusion Overview of the presentation Dissertation Talk4001/22/2008

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

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

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

 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 Timed Languages Dissertation Talk4401/22/2008

HTL and Timed languages Dissertation Talk t1 t2 t4 mode m1 (period 10) t1 t2 t1 t2 t5 mode m2 (period 10) t1 t2 mode m10 (period 10) t3 mode m5 (period 5) t4 mode m51 (period 5) t5 mode m52 (period 5) 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 Unit delay model, LET tied to period, flat structure Giotto, Timing Definition Language, xGiotto, Timed-Multitasking 4501/22/2008

 Event arrival handling in HTL is based on synchrony assumption  HTL program and causal synchronous programs are deterministic  Event arrival handling in HTL is based on synchrony assumption  HTL program and causal synchronous programs are deterministic HTL and Synchronous languages Dissertation Talk  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 scheduling and/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  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 scheduling and/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 4601/22/2008

 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 ? Future Work 01/22/2008Dissertation Talk47

 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 References 01/22/2008Dissertation Talk48  Ghosal. A hierarchical language for reliable real-time tasks. PHD Thesis  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

 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 and refinement of tasks  Incorporates schedulability-preserving refinement  Incorporates reliability-preserving refinement  Compiler, implementation and examples at Conclusion Dissertation Talk4901/22/2008

Acknowledgments 01/22/2008Dissertation Talk50 Alberto Sangiovanni-Vincentelli Thomas A. Henzinger Christoph M. Kirsch Claudio Pinello Krishnendu Chatterjee Daniel Iercan

Dissertation Talk5101/22/2008