# the fixed logical execution time (flet) assumption tom henzinger university of california, berkeley

Post on 16-Dec-2015

212 views

Embed Size (px)

TRANSCRIPT

- Slide 1
- The Fixed Logical Execution Time (FLET) Assumption Tom Henzinger University of California, Berkeley
- Slide 2
- 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.
- Slide 3
- 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.
- Slide 4
- 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
- Slide 5
- Current Practice in Embedded Software Design Efficient code (scheduled by RTOS) Mathematical models (e.g. Simulink) Code verification difficult Code generation difficult
- Slide 6
- Advocated Practice in Embedded Software Design Efficient code (possibly schedule-carrying) Mathematical models (e.g. Simulink) The missing link: platform-independent programming model
- Slide 7
- 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
- Slide 8
- 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
- Slide 9
- 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
- Slide 10
- Platform P Requirement A Program A Advocated Practice in Embedded Software Design Requirement B Program B + + Compositionality
- Slide 11
- Platform P Requirement A Program A Advocated Practice in Embedded Software Design Requirement B' Program B' + + Compositionality
- Slide 12
- Requirement A Platform P Advocated Practice in Embedded Software Design Platform Q Portability Program A
- Slide 13
- 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
- Slide 14
- 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
- Slide 15
- 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
- Slide 16
- 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
- Slide 17
- 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?
- Slide 18
- Efficient code (scheduled by RTOS) Mathematical models (e.g. Simulink) The missing link: platform-independent programming model First Attempt Priorities
- Slide 19
- Efficient code (scheduled by RTOS) Mathematical models (e.g. Simulink) Programming model: Priorities First Attempt Not sufficiently abstract -not about environment time -not compositional
- Slide 20
- 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!
- Slide 21
- 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
- Slide 22
- 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
- Slide 23
- 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?
- Slide 24
- 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
- Slide 25
- 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
- Slide 26 0 is the task's "logical execution time" The FLET (Fixed Lo">
- Software Task read sensor input at time t write actuator output at time t+d, for fixed d d>0 is the task's "logical execution time" The FLET (Fixed Logical Execution Time) Assumption
- Slide 27
- 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
- Slide 28
- time ttime t+d possible physical execution on CPU buffer output The FLET (Fixed Logical Execution Time) Assumption
- Slide 29
- 50% CPU speedup Portability
- Slide 30
- Task 2 Task 1 Composability
- Slide 31
- -timing predictability: minimal jitter -function predictability: no race conditions Verifiability through Predictability (Internal Determinism)
- Slide 32
- output as soon as ready Contrast FLET with Standard Practice
- Slide 33
- Race Contrast FLET with Standard Practice
- Slide 34
- yes but, what about the sacrifice in performance ?!
- Slide 35
- Test Case: Flight Control Software UC Berkeley (Horowitz, Liebman, Ma, Koo, Sangiovanni-Vincentelli, Sastry). Two connected CPUs.
- Slide 36
- Flight Control Software Architecture
- Slide 37
- 200 Hz 400 Hz 200 Hz 1 kHz Flight Control Software Architecture
- Slide 38
- 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
- Slide 39
- 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
- Slide 40
- 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.
- Slide 41
- 1. The Giotto Programmers Model: Time-triggered FLET 2. The Giotto Compiler
- Slide 42
- The Giotto Programmers Model Programming in terms of