1 / 40

Time Safety Checking for Embedded Programs

Time Safety Checking for Embedded Programs. Thomas A. Henzinger, Christoph M. Kirsch, Rupak Majumdar and Slobodan Matic UC Berkeley. http://www.eecs.berkeley.edu/~fresco. It’s Tricky. Embedded Software. Environment. Environment Processes. Software Processes. Software.

ayame
Download Presentation

Time Safety Checking for Embedded Programs

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. Time Safety Checking for Embedded Programs Thomas A. Henzinger, Christoph M. Kirsch, Rupak Majumdar and Slobodan Matic UC Berkeley http://www.eecs.berkeley.edu/~fresco

  2. It’s Tricky

  3. Embedded Software Environment Environment Processes Software Processes Software

  4. Environment vs. Platform Time Environment Environment Time Reactivity Schedulability Platform Time Software

  5. Giotto: Platform-independent Real-Time Programming 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)

  6. Helicopter System Mode 3: Motor Mode 2: Idle isStartMotor Mode 1: Init isInitDone ADFilter 200Hz ADFilter 200Hz ADFilter 200Hz NavRotorUp 100Hz NavPilot0 100Hz NavInit 100Hz isStopMotor isRotorUp&TakeOff isStopMotor isStopMotor isStopMotor Mode 6: ControlOn Mode 5: ControlOff Mode 4: TakeOff isControlOn ADFilter 200Hz isEndTakeOff ADFilter 200Hz ADFilter 200Hz NavPilot1 100Hz NavTakeOff 100Hz NavControl 100Hz isControlOff

  7. The Giotto Programming Model 3. Programming in terms of environment time: Programmer’s fiction: -time-triggered task invocation -tasks are functions with a fixed duration -platform offers sufficient performance 4. 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

  8. The Giotto Programmer’s Model: The FLET Assumption Given: • 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 • 3. Real-time requirements and data flow between tasks. Input ports Task Output ports Task driver loads task input ports. Task Giotto: Glue code that calls 1. and 2. in order to realize 3.

  9. Fixed Logical Execution Time Assumption 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

  10. 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

  11. Helicopter Software Control 10 a Actuators i Navigation 5 Sensors s Matlab Design

  12. From Giotto to E Code Giotto Compiler E code Giotto code • Giotto compiler generates code for a virtual machine • The E Machine • This allows flexibility in code generation strategies • Of course, E code is much more general than Giotto • Allows triggering on arbitrary events (not just time triggered) • Can express complicated control flow (not just periodic tasks)

  13. The Embedded Machine Environment A virtual machine that mediates the interaction of physical processes (sensors and actuators) and software processes (tasks and drivers) in real time Software

  14. The Embedded Machine Environment Ports e.g. clock environment triggers sense actuate Driver Ports Embedded Machine call drivers task triggers read write schedule tasks Task Ports e.g. task completion

  15. The Embedded Machine: Three Instructions Call driver: Schedule task: call(d) schedule(T) T d Hand task t over to the system scheduler (RTOS). Execute driver d now. Enable trigger: Have code B executed as soon as trigger g becomes true. future(g,B:) g B:

  16. Flow of Control Environment • Control Flow Instructions • sequencing • if (pred, a1, a2) • return Software

  17. Synchronous vs. Scheduled Computation Environment call(a) b: call(s) t a s a s schedule(t) future(g,b) Software

  18. Environment Ports e.g. clock Environment Port States environment triggers sense actuate Task Port States Driver Ports Embedded Machine E code Address call drivers Task Set Trigger Queue task triggers read write schedule tasks Task Ports e.g. task completion Embedded Machine State

  19. Helicopter Software Control 10 a Actuators i Navigation 5 Sensors s Matlab Design

  20. 0ms 5ms 10ms a i Control a i s Navigation s Navigation s Code Generation Strategy I Generate code up to the next interesting event Trigger queue has at most one element

  21. Code Generation Strategy I 0ms 5ms 10ms b1: call(actuate) call(sense) call(input) schedule(Control) schedule(Navigation) future(now+5,b2) a i Control a i s Navigation s Navigation s

  22. Code Generation Strategy I 0ms 5ms 10ms b2: call(sense) schedule(Navigation) future(now+5,b1) a i Control a i s Navigation s Navigation s

  23. 0ms 5ms 10ms a i Control a i s Navigation s Navigation s Code Generation Strategy II Generate independent code for each task / actuator Trigger queue can have several elements More concurrency

  24. Code Generation Strategy II 0ms 5ms 10ms b1: call(actuate) future(now+10,b1) a i Control a i b2: call(sense) future(now+5,b2) b3: call(input) future(now+10,b3) s Navigation s Navigation s b4: schedule(Control) future(now+10,b4) b5: schedule(Navigation) future(now+5,b5)

  25. Platform Time is Platform Memory • Programming as if there is enough platform time • Implementation checks whether there is enough of it • For example, the helicopter code is correct if • wcet(Control) + 2 * wcet(Navigation) ·10 • Time-safe code: No driver/task accesses a scheduled task before completion. • Maintains logical atomicity of tasks • Depends on platform (worst case execution times) • An E machine state is time-unsafe if the current instruction accesses a driver or task that accesses some port of an active task

  26. Time Safety Environment t a s a s Software

  27. Time Safety Environment t a s a s Software

  28. Time Safety and Schedulability • Time safety is the property of an execution trace • A scheduling strategy (scheduler) is a function that maps every finite trace to some task in the ready queue. • The schedulability problem of E code is, • - Given an E program and WCETs for all tasks, • - Check that there is a scheduler so that all resulting • traces of the program are time safe. • Of course, WCETs may be wrong: • The E Machine has a runtime exception mechanism

  29. The Time Safety Game Formulate the schedulability problem as a game between the environment and the scheduler. • States: E Machine States hPortStates, Address, TaskState, TriggerQStatei • Initial state: h¢, a0, ;, ;i • Bad states: Any time-unsafe state is bad • The environment tries to force the game to a bad state • The scheduler maps time units to ready tasks to prevent it

  30. The Time Safety Game Formulate the schedulability problem as a game between the environment and the scheduler. • States: E Machine States hPortStates, Address, TaskState, TriggerQStatei • Initial state: h¢, a0, ;, ;i • Bad states: Any time-unsafe state is bad • The environment tries to force the game to a bad state • The scheduler maps time units to ready tasks to prevent it • Transitions: • The environment updates environment ports • This may cause E code to run, the state resulting from the E code execution is the next state • After the E machine has run (and no triggers are active) the Scheduler assigns the next CPU cycle to an active task • This may cause some task to finish and some triggers to become active, so the E machine runs again

  31. EXPTIME-Complete Theorem: The schedulability problem of propositional E code is EXPTIME-complete. EXPTIME: Can solve schedulability by solving a game on an exponential state space. Hardness: Can encode an alternating PSPACE Turing Machine.

  32. Choose Choice 1 Task1 Task1 Task2 Scheduler Choose Choice 2 Task2 Task1 Task2 Hardness • Have an address for each tape+head configuration • For existential moves, the environment chooses one of two options • Universal moves is trickier Trigger event on completion that writes task id to a port Finally, if TM accepts, go to an address that set up an unschedulable problem Note that this example also shows optimal schedulers may not Be EDF! Cannot define “deadlines” for tasks!

  33. What is the Source of the Complexity? • The scheduler “knows too much’’ • It is unreasonable for the scheduler to see all the program state, • and the definitions of the tasks and drivers • The path insensitive E code schedulability problem ignores actual • definitions of tasks/drivers and assumes all branches can be taken

  34. Path Insensitive Schedulability • Path insensitive schedulability is conservative • For the particular tasks and drivers, the program may be schedulable, but our analysis may reject • But the analysis is precise: there is some task/driver that causes a time safety violation • Path insensitive E code schedulability is PSPACE-hard for general E code

  35. Schedulability is Hard • Schedulability (even path insensitive schedulability) for general E code is hard • But what about E code generated from a structured language like Giotto?

  36. E code schedulability Problem for Giotto From Giotto to E Code Giotto Compiler Giotto code E code Executable Time Safe? Platform Constraints (wcet) YES NO

  37. Polynomial Time Schedulability • For Giotto, path insensitivity implies each syntactically reachable • mode is reachable • Schedulability Theorem for Giotto: • The path insensitive E code schedulability problem for E code derived from Giotto can be solved in polynomial time. • Need to check each syntactically reachable mode is schedulable • Check that the utilization test holds for the mode • Proof uses: Mode changes in Giotto are memoryless • This ensures that this test is sufficient

  38. Helicopter Software Navigation 5 Control 10 s i a WCET : 3 WCET : 3 Navigation Navigation Control 0 10 Utilization Test: In case of the helicopter: We check this for each mode, mode changes have no effect

  39. Conclusion • Platform independent models for embedded programming • Structured Giotto code at the high level • (Virtual) E code at the low level • Time safety implements logical atomicity of tasks • Checking time safety is • EXPTIME-complete for general E code • Polynomial time for Giotto if task and driver states are ignored • The polynomial time check indicates Giotto captures a structured fragment • The path insensitive time safety check is implemented in the Giotto compiler

  40. http://www.eecs.berkeley.edu/~fresco

More Related