Time Safety Checking for Embedded Programs
http://www.eecs.berkeley.edu/~fresco
Thomas A. Henzinger, Christoph M. Kirsch, Rupak Majumdar and Slobodan Matic
UC Berkeley
It’s Tricky
Mars, J uly 4, 1997Lost contact due to embedded sof tware f ailure
Embedded Software
Environment
Software
Software Processes
Environment Processes
Environment vs. Platform Time
Environment
Software
Environment Time
Platform Time
Reactivity
Schedulability
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)
Giotto: Platform-independent Real-Time Programming
isInitDone
Mode 4: TakeOff
ADFilter 200Hz
NavTakeOff 100Hz
Mode 3: Motor
ADFilter 200Hz
NavRotorUp 100Hz
isEndTakeOff
Mode 5: ControlOff
ADFilter 200Hz
NavPilot1 100Hz
isControlOn
isControlOff
isRotorUp&TakeOff
Mode 2: Idle
ADFilter 200Hz
NavPilot0 100Hz
Mode 1: Init
ADFilter 200Hz
NavInit 100Hz
isStopMotorisSto
pMoto
r
isStartMotor
isStopMotor
isStopMotor
Mode 6: ControlOn
ADFilter 200Hz
NavControl 100Hz
Helicopter System
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
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.
Giotto: Glue code that calls 1. and 2. in order to realize 3.
TaskInput ports Output ports
Task Task driver loads task input ports.
The Giotto Programmer’s Model: The FLET Assumption
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 Time t+d
Time t+d
d
Task duration
Fixed Logical Execution Time Assumption
Task
Driver
Input ports loaded.
Output ports read.
Sensor
Time t Time t Time t+d
Time t+d
d
Task on CPU.
Actuator
Platform Timeline (chosen by Giotto compiler)
Navigation
Control
Helicopter Software
Sensors
Actuators
i
s
a10
5
Matlab Design
From Giotto to E 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)
GiottoCompiler
Giotto code E code
A virtual machine that mediates the interaction of physical processes (sensors and actuators) and software processes (tasks and drivers)
in real time
Environment
Software
The Embedded Machine
Environment Ports
Task Ports
Driver PortsEmbedded Machine
task triggers
environment triggers
sense actuate
read write
call drivers
The Embedded Machine
schedule tasks
e.g. clock
e.g. task completion
Enable trigger:future(g,B:) B:
Schedule task:schedule(T)
T
Call driver:call(d)
d
g
The Embedded Machine: Three Instructions
Execute driver d now.Hand task t over to the system scheduler (RTOS).
Have code B executed as soon as trigger g becomes true.
Environment
Software
Flow of Control
Control Flow Instructions
• sequencing• if (pred, a1, a2)• return
Software
Environment
tcall(s)
schedule(t)
future(g,b)
call(a)b:
as sa
Synchronous vs. Scheduled Computation
environment triggers
Environment Ports
Task Ports
Driver PortsEmbedded Machine
task triggers
sense actuate
read write
call drivers
schedule tasks
e.g. clock
e.g. task completion
Embedded Machine State
Environment Port States
Task Port States
E code Address
Task Set
Trigger Queue
Navigation
Control
Helicopter Software
Sensors
Actuators
i
s
a10
5
Matlab Design
Code Generation Strategy I
a ia
sNavigation Navigation
Controli
s s
0ms 5ms 10ms
Generate code up to the next interesting eventTrigger queue has at most one element
a ia
sNavigation Navigation
Controli
s s
Code Generation Strategy I0ms 5ms 10ms
b1: call(actuate)call(sense)call(input)schedule(Control )schedule(Navigation)future(now+5,b2)
a ia
sNavigation Navigation
Controli
s s
Code Generation Strategy I0ms 5ms 10ms
b2: call(sense)schedule(Navigation)future(now+5,b1)
Code Generation Strategy II
a ia
sNavigation Navigation
Controli
s s
0ms 5ms 10ms
Generate independent code for each task / actuatorTrigger queue can have several elements
More concurrency
a ia
sNavigation Navigation
Controli
s s
Code Generation Strategy II0ms 5ms 10ms
b1: call(actuate)future(now+10,b1)
b2: call(sense)future(now+5,b2)
b3: call(input)future(now+10,b3)
b5: schedule(Navigation)future(now+5,b5)
b4: schedule(Control )future(now+10,b4)
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 ifwcet(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
Software
Environment
t as sa
Time Safety
Software
Environment
t as sa
Time Safety
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
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
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
EXPTIME-Complete
Theorem: The schedulability problem of propositional E code is EXPTIME-complete.
EXPTIME: Can solve schedulability by solving a game on anexponential state space.
Hardness: Can encode an alternating PSPACE Turing Machine.
Hardness• Have an address for each tape+head configuration• For existential moves, the environment chooses one of two
options• Universal moves is trickier
Task1
Task2
Scheduler
Trigger event on completionthat writes task id to a port
ChooseChoice 1
ChooseChoice 2
Task1
Task1
Task2
Task2
Finally, if TM accepts, go to an address that set up an unschedulable problem
Note that this example also shows optimal schedulers may notBe EDF! Cannot define “deadlines” for tasks!
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 actualdefinitions of tasks/drivers and assumes all branches can be taken
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
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?
E code schedulabilityProblem for Giotto
From Giotto to E Code
GiottoCompiler
Giotto code E code
TimeSafe?
YESPlatformConstraints
(wcet)NO
Executable
Polynomial Time Schedulability
For Giotto, path insensitivity implies each syntactically reachablemode 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
Navigation
Helicopter Software
i Control a105
s
WCET : 3 WCET : 3
Utilization Test:
110
3
10
3*2
12
2
1
1
period
wcet
period
wcet0 10
Navigation Navigation Control
In case of the helicopter:
We check this for each mode, mode changes have no effect
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
http://www.eecs.berkeley.edu/~fresco