1 / 84

The Fixed Logical Execution Time (FLET) Assumption

The Fixed Logical Execution Time (FLET) Assumption. Tom Henzinger University of California, Berkeley. The History of Computer Science: Lifting the Level of Abstraction.

Antony
Download Presentation

The Fixed Logical Execution Time (FLET) Assumption

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. The History of Computer Science: Lifting the Level of Abstraction High-level languages: Programming to the application Compilation: perhaps “the” success story of computer science It is feasible to abstract the platform. The “assembly age”: Programming to the platform

  3. The History of Computer Science: Lifting the Level of Abstraction Automatic program synthesis: No more programming Code generation from specifications: still mostly a dream It is not feasible to abstract algorithms and data structures. High-level languages: Programming to the application Compilation: perhaps “the” success story of computer science It is feasible to abstract the platform. The “assembly age”: Programming to the platform

  4. Current Practice in Embedded Software Design -often inefficient -often unpredictable -e.g. Real-Time Workshop Some automatic code generation from models -difficult to reuse -difficult to verify -requires systems experts Some manual programming to the platform

  5. Current Practice in Embedded Software Design Mathematical models (e.g. Simulink) Code generation difficult Code verification difficult Efficient code (scheduled by RTOS)

  6. Advocated Practice in Embedded Software Design Mathematical models (e.g. Simulink) The missing link: platform-independent programming model Efficient code (possibly schedule-carrying)

  7. Advocated Practice in Embedded Software Design Mathematical models (e.g. Simulink) Verification The missing link: platform-independent programming model Compilation Efficient code (possibly schedule-carrying)

  8. Advocated Practice in Embedded Software Design Mathematical models (e.g. Simulink) Verification -verifiable -reusable-efficiently implementable The missing link: platform-independent programming model Compilation Efficient code (possibly schedule-carrying)

  9. Advocated Practice in Embedded Software Design Mathematical models (e.g. Simulink) Verification -verifiable -reusable-efficiently implementable The missing link: platform-independent programming model Reusable = composable + portable Compilation Efficient code (possibly schedule-carrying)

  10. Advocated Practice in Embedded Software Design Requirement A Requirement B + Program A Program B + Compositionality Platform P

  11. Advocated Practice in Embedded Software Design Requirement A Requirement B' + Program A Program B' + Compositionality Platform P

  12. Advocated Practice in Embedded Software Design Requirement A Program A Portability Platform P Platform Q

  13. Advocated Practice in Embedded Software Design Mathematical models (e.g. Simulink) -concurrency -environment time Verification The missing link: platform-independent programming model Compilation Efficient code (possibly schedule-carrying) -distribution -platform (CPU) time

  14. Advocated Practice in Embedded Software Design Mathematical models (e.g. Simulink) -concurrency -environment time Verification -concurrency -environment time The missing link: platform-independent programming model Compilation Efficient code (possibly schedule-carrying) -distribution -platform (CPU) time

  15. Advocated Practice in Embedded Software Design Mathematical models (e.g. Simulink) -descriptive -mathematics / logic Verification -concurrency -environment time The missing link: platform-independent programming model Compilation Efficient code (possibly schedule-carrying) -prescriptive -algorithms + data structures

  16. Advocated Practice in Embedded Software Design Mathematical models (e.g. Simulink) -descriptive -mathematics Verification -concurrency -environment time-prescriptive -virtual machine The missing link: platform-independent programming model Compilation Efficient code (possibly schedule-carrying) -prescriptive -algorithms + data structures

  17. Advocated Practice in Embedded Software Design e.g. What is the control equation? What is the sampling rate? Mathematical models (e.g. Simulink) Verification e.g. Which procedure computes the control equation? Which event triggers the computation? The missing link: platform-independent programming model Compilation e.g. Which CPU executes the control procedure? What priority has the execution? Efficient code (possibly schedule-carrying)

  18. First Attempt Mathematical models (e.g. Simulink) The missing link: platform-independent programming model Priorities Efficient code (scheduled by RTOS)

  19. First Attempt Mathematical models (e.g. Simulink) Not sufficiently abstract -not about environment time -not compositional Programming model: Priorities Efficient code (scheduled by RTOS)

  20. First Attempt Mathematical models (e.g. Simulink) Correctness? Scheduling theory Not sufficiently abstract -not about environment time -not compositional Programming model: Priorities Efficient code (scheduled by RTOS) Efficiency!

  21. Second Attempt Mathematical models (e.g. Simulink) Synchrony assumption: platform time infinitely faster than environment time The missing link: platform-independent programming model Efficient code (scheduled by RTOS)

  22. Second Attempt Mathematical models (e.g. Simulink) Too abstract difficult to compile to resource-constrained, distributed platforms Synchronous programming languages (Esterel, Lustre, Signal, etc.) Efficient code (scheduled by RTOS)

  23. Second Attempt Mathematical models (e.g. Simulink) Correctness! Too abstract difficult to compile to resource-constrained, distributed platforms Synchronous programming languages (Esterel, Lustre, Signal, etc.) Efficient code (scheduled by RTOS) Efficiency?

  24. Our Attempt Mathematical models (e.g. Simulink) FLET assumption: -verifiable -efficiently implementable -composable -portable The missing link: platform-independent programming model Efficient code (possibly schedule-carrying)

  25. The FLET (Fixed Logical Execution Time) Assumption Software Task write actuator output at time t+d, for fixed d read sensor input at time t

  26. The FLET (Fixed Logical Execution Time) Assumption Software Task d>0 is the task's "logical execution time" write actuator output at time t+d, for fixed d read sensor input at time t

  27. The FLET Programming Model 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.

  28. The FLET (Fixed Logical Execution Time) Assumption time t time t+d possible physical execution on CPU buffer output

  29. Portability 50% CPU speedup

  30. Composability Task 1 Task 2

  31. Verifiability through Predictability (Internal Determinism) -timing predictability: minimal jitter -function predictability: no race conditions

  32. Contrast FLET with Standard Practice output as soon as ready

  33. Contrast FLET with Standard Practice Race

  34. … yes but, what about the sacrifice in performance ?!

  35. Test Case: Flight Control Software UC Berkeley (Horowitz, Liebman, Ma, Koo, Sangiovanni-Vincentelli, Sastry). Two connected CPUs.

  36. Flight Control Software Architecture

  37. Flight Control Software Architecture 200 Hz 400 Hz 1 kHz 200 Hz

  38. Platform-independent Software Model 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)

  39. Platform-independent Software Model Mode 1 Mode 2 Condition 1.2 Task S 400 Hz Task S 400 Hz Task C 200 Hz Task C 200 Hz Task A’ 1 kHz Task A 1 kHz Condition 2.1 Task A” 1 kHz Mode 3 Mode 4 Task S 400 Hz Task C’ 100 Hz Task C 200 Hz Task A 1 kHz Task A 2 kHz

  40. Platform-independent Software Model Functionality. Timing and interaction. Host code e.g. C Glue code e.g. Giotto -No time. -Sequential. -Environment time, not platform time. -Concurrency, not distribution. 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.

  41. 1. The Giotto Programmer’s Model: Time-triggered FLET 2. The Giotto Compiler

  42. The Giotto Programmer’s Model Programming in terms of environment time: Programmer’s 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 programmer’s 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

  43. Functional Components • 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 Input ports Task Output ports Task driver loads task input ports. Task

  44. Environment Timeline (defined by Giotto semantics) Task duration Actuator Sensor Driver d Task Driver execution in environment time 0. Task execution in environment time d. Sensor/output ports read. Input ports loaded. Output ports read. Actuator/input ports loaded. Time t Time t Time t+d Time t+d

  45. Platform Timeline (chosen by Giotto compiler) Actuator Sensor Driver d Task Task on CPU. Input ports loaded. Output ports read. Time t Time t Time t+d Time t+d

  46. Platform Independence ensures Predictability The Giotto compiler chooses for a given platform a platform timeline that is value equivalent to the environment timelinedefined 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).

  47. Simplified Helicopter Software Control 10 a Actuators i 5 Navigation Sensors s

  48. Simplified Helicopter Software Control 10 a Actuators i 5 Navigation Sensors s Simulink / legacy design

  49. Helicopter Software: Giotto Syntax … mode Flight ( )period10ms { actfreq 1 do Actuator( actuating ) ; taskfreq 1 doControl( input ); taskfreq 2 doNavigation ( sensing) ; } … Control 10 a i Navigation 5 s

  50. Helicopter Software: Environment Timeline Task a i Control a i s Navigation s Navigation s t+5ms t+5ms t+10ms t t t+10ms Block of synchronous code(nonpreemptable) Scheduled tasks (preemptable)

More Related