The Fixed Logical Execution Time (FLET) Assumption Tom Henzinger University of California, Berkeley

Download The Fixed Logical Execution Time (FLET) Assumption Tom Henzinger University of California, Berkeley

Post on 16-Dec-2015

212 views

Category:

Documents

0 download

Embed Size (px)

TRANSCRIPT

<ul><li> Slide 1 </li> <li> The Fixed Logical Execution Time (FLET) Assumption Tom Henzinger University of California, Berkeley </li> <li> Slide 2 </li> <li> The History of Computer Science: Lifting the Level of Abstraction The assembly age: Programming to the platform High-level languages: Programming to the application Compilation: perhaps the success story of computer science It is feasible to abstract the platform. </li> <li> Slide 3 </li> <li> The History of Computer Science: Lifting the Level of Abstraction The assembly age: Programming to the platform High-level languages: Programming to the application Automatic program synthesis: No more programming Compilation: perhaps the success story of computer science Code generation from specifications: still mostly a dream It is feasible to abstract the platform. It is not feasible to abstract algorithms and data structures. </li> <li> Slide 4 </li> <li> Current Practice in Embedded Software Design Some manual programming to the platform Some automatic code generation from models -often inefficient -often unpredictable -e.g. Real-Time Workshop -difficult to reuse -difficult to verify -requires systems experts </li> <li> Slide 5 </li> <li> Current Practice in Embedded Software Design Efficient code (scheduled by RTOS) Mathematical models (e.g. Simulink) Code verification difficult Code generation difficult </li> <li> Slide 6 </li> <li> Advocated Practice in Embedded Software Design Efficient code (possibly schedule-carrying) Mathematical models (e.g. Simulink) The missing link: platform-independent programming model </li> <li> Slide 7 </li> <li> Efficient code (possibly schedule-carrying) Mathematical models (e.g. Simulink) The missing link: platform-independent programming model Verification Compilation Advocated Practice in Embedded Software Design </li> <li> Slide 8 </li> <li> Efficient code (possibly schedule-carrying) Mathematical models (e.g. Simulink) The missing link: platform-independent programming model Verification Compilation -verifiable -reusable -efficiently implementable Advocated Practice in Embedded Software Design </li> <li> Slide 9 </li> <li> Efficient code (possibly schedule-carrying) Mathematical models (e.g. Simulink) The missing link: platform-independent programming model Verification Compilation -verifiable -reusable -efficiently implementable Reusable = composable + portable Advocated Practice in Embedded Software Design </li> <li> Slide 10 </li> <li> Platform P Requirement A Program A Advocated Practice in Embedded Software Design Requirement B Program B + + Compositionality </li> <li> Slide 11 </li> <li> Platform P Requirement A Program A Advocated Practice in Embedded Software Design Requirement B' Program B' + + Compositionality </li> <li> Slide 12 </li> <li> Requirement A Platform P Advocated Practice in Embedded Software Design Platform Q Portability Program A </li> <li> Slide 13 </li> <li> Efficient code (possibly schedule-carrying) Mathematical models (e.g. Simulink) The missing link: platform-independent programming model Verification Compilation -concurrency -environment time -distribution -platform (CPU) time Advocated Practice in Embedded Software Design </li> <li> Slide 14 </li> <li> Efficient code (possibly schedule-carrying) Mathematical models (e.g. Simulink) The missing link: platform-independent programming model Verification Compilation -concurrency -environment time -distribution -platform (CPU) time -concurrency -environment time Advocated Practice in Embedded Software Design </li> <li> Slide 15 </li> <li> Efficient code (possibly schedule-carrying) Mathematical models (e.g. Simulink) The missing link: platform-independent programming model Verification Compilation -descriptive -mathematics / logic -prescriptive -algorithms + data structures -concurrency -environment time Advocated Practice in Embedded Software Design </li> <li> Slide 16 </li> <li> Efficient code (possibly schedule-carrying) Mathematical models (e.g. Simulink) The missing link: platform-independent programming model Verification Compilation -descriptive -mathematics -prescriptive -algorithms + data structures -concurrency -environment time -prescriptive -virtual machine Advocated Practice in Embedded Software Design </li> <li> Slide 17 </li> <li> Efficient code (possibly schedule-carrying) Mathematical models (e.g. Simulink) The missing link: platform-independent programming model Verification Compilation Advocated Practice in Embedded Software Design e.g. What is the control equation? What is the sampling rate? e.g. Which procedure computes the control equation? Which event triggers the computation? e.g. Which CPU executes the control procedure? What priority has the execution? </li> <li> Slide 18 </li> <li> Efficient code (scheduled by RTOS) Mathematical models (e.g. Simulink) The missing link: platform-independent programming model First Attempt Priorities </li> <li> Slide 19 </li> <li> Efficient code (scheduled by RTOS) Mathematical models (e.g. Simulink) Programming model: Priorities First Attempt Not sufficiently abstract -not about environment time -not compositional </li> <li> Slide 20 </li> <li> Efficient code (scheduled by RTOS) Mathematical models (e.g. Simulink) Programming model: Priorities First Attempt Not sufficiently abstract -not about environment time -not compositional Scheduling theory Correctness? Efficiency! </li> <li> Slide 21 </li> <li> Efficient code (scheduled by RTOS) Mathematical models (e.g. Simulink) The missing link: platform-independent programming model Second Attempt Synchrony assumption: platform time infinitely faster than environment time </li> <li> Slide 22 </li> <li> Efficient code (scheduled by RTOS) Mathematical models (e.g. Simulink) Synchronous programming languages (Esterel, Lustre, Signal, etc.) Second Attempt Too abstract difficult to compile to resource-constrained, distributed platforms </li> <li> Slide 23 </li> <li> Efficient code (scheduled by RTOS) Mathematical models (e.g. Simulink) Synchronous programming languages (Esterel, Lustre, Signal, etc.) Second Attempt Too abstract difficult to compile to resource-constrained, distributed platforms Correctness! Efficiency? </li> <li> Slide 24 </li> <li> Efficient code (possibly schedule-carrying) Mathematical models (e.g. Simulink) The missing link: platform-independent programming model Our Attempt FLET assumption: -verifiable -efficiently implementable -composable -portable </li> <li> Slide 25 </li> <li> The FLET (Fixed Logical Execution Time) Assumption Software Task read sensor input at time t write actuator output at time t+d, for fixed d </li> <li> Slide 26 0 is the task's "logical execution time" The FLET (Fixed Lo"&gt; </li><li> Software Task read sensor input at time t write actuator output at time t+d, for fixed d d&gt;0 is the task's "logical execution time" The FLET (Fixed Logical Execution Time) Assumption </li> <li> Slide 27 </li> <li> The programmer specifies d (could be any event) to solve the problem at hand. The compiler ensures that d is met on a given platform (hardware resources and performance); otherwise it rejects the program. The FLET Programming Model </li> <li> Slide 28 </li> <li> time ttime t+d possible physical execution on CPU buffer output The FLET (Fixed Logical Execution Time) Assumption </li> <li> Slide 29 </li> <li> 50% CPU speedup Portability </li> <li> Slide 30 </li> <li> Task 2 Task 1 Composability </li> <li> Slide 31 </li> <li> -timing predictability: minimal jitter -function predictability: no race conditions Verifiability through Predictability (Internal Determinism) </li> <li> Slide 32 </li> <li> output as soon as ready Contrast FLET with Standard Practice </li> <li> Slide 33 </li> <li> Race Contrast FLET with Standard Practice </li> <li> Slide 34 </li> <li> yes but, what about the sacrifice in performance ?! </li> <li> Slide 35 </li> <li> Test Case: Flight Control Software UC Berkeley (Horowitz, Liebman, Ma, Koo, Sangiovanni-Vincentelli, Sastry). Two connected CPUs. </li> <li> Slide 36 </li> <li> Flight Control Software Architecture </li> <li> Slide 37 </li> <li> 200 Hz 400 Hz 200 Hz 1 kHz Flight Control Software Architecture </li> <li> Slide 38 </li> <li> 1. Concurrent periodic tasks: -sensing -control law computation -actuating 2. Multiple modes of operation: -navigational modes (autopilot, manual, etc.) -maneuver modes (taxi, takeoff, cruise, etc.) -degraded modes (sensor, actuator, CPU failures) Platform-independent Software Model </li> <li> Slide 39 </li> <li> Mode 1 Mode 4Mode 3 Mode 2 Task S 400 Hz Task C 200 Hz Task A 1 kHz Task S 400 Hz Task C 200 Hz Task A 1 kHz Task C 100 Hz Task A 1 kHz Task S 400 Hz Task C 200 Hz Task A 2 kHz Task A 1 kHz Condition 1.2 Condition 2.1 Platform-independent Software Model </li> <li> Slide 40 </li> <li> Host code e.g. C Glue code e.g. Giotto Functionality. -Environment time, not platform time. -Concurrency, not distribution. Platform-independent Software Model Timing and interaction. This kind of software is understood: Host code may (sometimes) be generated automatically. The software complexity lies in the glue code (minimize jitter!): Giotto enables requirements-driven rather than platform-driven glue-code programming. -No time. -Sequential. </li> <li> Slide 41 </li> <li> 1. The Giotto Programmers Model: Time-triggered FLET 2. The Giotto Compiler </li> <li> Slide 42 </li> <li> The Giotto Programmers Model Programming in terms of environment time: Programmers fiction: -time-triggered task invocation -tasks are functions with a fixed duration -platform offers sufficient performance Implementation in terms of platform time: Compiler must maintain programmers fiction: -needs access to global time, no other platform requirements -tasks may finish early, but outputs cannot be observed early -tasks may be preempted and distributed </li> <li> Slide 43 </li> <li> 1. Units of scheduled host code (application-level tasks). e.g. control law computation 2. Units of synchronous host code (system-level drivers). e.g. device drivers Task Input portsOutput ports Task Task driver loads task input ports. Functional Components </li> <li> Slide 44 </li> <li> Task Driver Input ports loaded. Driver execution in environment time 0. Task execution in environment time d. Output ports read. Sensor/output ports read. Sensor Actuator Actuator/input ports loaded. Time t Time t+d d Task duration Environment Timeline (defined by Giotto semantics) </li> <li> Slide 45 </li> <li> Task Driver Input ports loaded. Output ports read. Sensor Time t Time t+d d Task on CPU. Actuator Platform Timeline (chosen by Giotto compiler) </li> <li> Slide 46 </li> <li> The Giotto compiler chooses for a given platform a platform timeline that is value equivalent to the environment timeline defined by the Giotto semantics. Internal Determinism: For a given sequence of sensor readings, the corresponding sequence of actuator settings is uniquely determined (i.e., there are no race conditions). Platform Independence ensures Predictability </li> <li> Slide 47 </li> <li> Navigation Control Simplified Helicopter Software Sensors Actuators i s a 10 5 </li> <li> Slide 48 </li> <li> Navigation Control Simplified Helicopter Software Sensors Actuators i s a 10 5 Simulink / legacy design </li> <li> Slide 49 </li> <li> mode Flight ( ) period 10ms { actfreq 1 do Actuator ( actuating ) ; taskfreq 1 do Control ( input ) ; taskfreq 2 do Navigation ( sensing ) ; } Helicopter Software: Giotto Syntax Navigation Control i s a 10 5 </li> <li> Slide 50 </li> <li> aia t+10ms s Task Navigation Control t+10ms tt t+5ms i ss Helicopter Software: Environment Timeline Block of synchronous code (nonpreemptable) Scheduled tasks (preemptable) </li> <li> Slide 51 </li> <li> t+10ms Task t+10ms tt t+5ms Single-CPU Helicopter: Platform Timeline (EDF) </li> <li> Slide 52 </li> <li> t+10ms ttt+5ms t+7ms HeliCtr HeliNav TDMA Slot HeliNet Two-CPU Helicopter: Platform Timeline (Time-triggered Communication) </li> <li> Slide 53 </li> <li> t+10mstt t+5ms HeliCtr HeliNav Message HeliNet Two-CPU Helicopter: Platform Timeline (Event-triggered Communication) t+10ms </li> <li> Slide 54 </li> <li> 1. The Giotto Programmers Model 2. The Giotto Compiler </li> <li> Slide 55 </li> <li> The Giotto Compiler Giotto Program Native Code Tasks and Drivers Giotto-P Platform Specification -topology (CPUs, networks) -performance (WCETs, latencies) -APIs (RTOSs, protocols) Executables Giotto Compiler Functionality Timing Interaction Platform Failure either Giotto-P overconstrained, or compiler not smart enough (distributed scheduling problem) or </li> <li> Slide 56 </li> <li> Closing the Gap: Annotated Giotto Giotto Program Native Code Tasks and Drivers Giotto-P -topology (CPUs, networks) -performance (WCETs, latencies) -APIs (RTOSs, protocols) Executables Giotto Compiler Functionality Timing Interaction Platform Failure either Giotto-PM overconstrained, or compiler not smart enough (global scheduling problem) or Giotto-PM -assign tasks to CPUs -assign connections to networks Map </li> <li> Slide 57 </li> <li> Closing the Gap: Annotated Giotto Giotto Program Native Code Tasks and Drivers Giotto-P Executables Giotto Compiler Functionality Timing Interaction Platform Failure Giotto-PMC overconstrained (local scheduling problems solvable) or Giotto-PM Map Giotto-PMC Communication -assign connections to TDMA slots (say) -topology (CPUs, networks) -performance (WCETs, latencies) -APIs (RTOSs, protocols) -assign tasks to CPUs -assign connections to networks </li> <li> Slide 58 </li> <li> Code Generation Giotto Program Native Code Tasks and Drivers Giotto-P Giotto Compiler Functionality Timing Interaction Platform Giotto-PM Map Giotto-PMC Communication -assign connections to TDMA slots (say) -topology (CPUs, networks) -performance (WCETs, latencies) -APIs (RTOSs, protocols) -assign tasks to CPUs -assign connections to networks or Failure VxWorksOSEK </li> <li> Slide 59 </li> <li> Code Generation: The Embedded Machine Giotto Program Native Code Tasks and Drivers Giotto-P Embedded Machine code Giotto Compiler Functionality Timing Interaction Platform or Giotto-PM Map Giotto-PMC Communication -assign connections to TDMA slots (say) -topology (CPUs, networks) -performance (WCETs, latencies) -APIs (RTOSs, protocols) -assign tasks to CPUs -assign connections to networks Failure Embedded Machine interpreter </li> <li> Slide 60 </li> <li> The Embedded Machine -a virtual machine that mediates the interaction of physical processes (sensors and actuators) and software processes (tasks and drivers) in real time -the Giotto compiler can be retargeted to a new platform by porting the Embedded Machine </li> <li> Slide 61 </li> <li> Environment Software Software Processes: platform time Environment Processes: environment time The Embedded Machine </li> <li> Slide 62 </li> <li> Environment Software Schedulability: time safety checking for platform time Reactivity: programming in environment time The Embedded Machine: Time is like Memory Embedded Machine </li> <li> Slide 63 </li>...</ul>