Time Safety Checking for Embedded Programs

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
Its 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
isRotorUpTakeOff
isStopMotor
isStopMotor
isStopMotor
Mode 4 TakeOff
Mode 5 ControlOff
Mode 6 ControlOn
isControlOn
ADFilter 200Hz
isEndTakeOff
ADFilter 200Hz
ADFilter 200Hz
NavTakeOff 100Hz
NavPilot1 100Hz
NavControl 100Hz
isControlOff
7
The Giotto Programming Model
3. Programming in terms of environment time
Programmers 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
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
8
The Giotto Programmers 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.

Task
Input ports
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
Driver
Sensor
d
Task
Driver execution in environment time 0.
Task execution in environment time d.
Input ports loaded.
Output ports read.
Sensor/output ports read.
Actuator/input ports loaded.
Time t
Time t
Time td
Time td
10
Platform Timeline (chosen by Giotto compiler)
Actuator
Driver
Sensor
d
Task
Task on CPU.
Input ports loaded.
Output ports read.
Time t
Time t
Time td
Time td
11
Helicopter Software
Control
10
Actuators
a
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
Schedule task
Call driver
schedule(T)
call(d)
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)
B
g
16
Flow of Control
Environment

• Control Flow Instructions
• sequencing
• if (pred, a1, a2)
• return

Software
17
Synchronous vs. Scheduled Computation
c
INACTIVE
b
g
activates
e
RUN
READY
c
g

• Scheduled computation
• User context

• Synchronous computation
• Kernel context
• Trigger related interrupts disabled

18
Synchronous vs. Scheduled Computation
Environment
call(a)
b
call(s)
t
a
s
s
a
schedule(t)
future(g,b)
Software
19
Embedded Machine State
20
Helicopter Software
Control
10
Actuators
a
i
Navigation
5
Sensors
s
Matlab Design
21
Code Generation Strategy I
Generate code up to the next interesting
event Trigger queue has at most one element
22
Code Generation Strategy I
0ms
5ms
10ms
b1 call(actuate) call(sense) call(input) sc
hedule(Control ) schedule(Navigation) future(n
ow5,b2)
a
i
a
Control
i
s
Navigation
Navigation
s
s
23
Code Generation Strategy I
0ms
5ms
10ms
b2 call(sense) schedule(Navigation) future(no
w5,b1)
a
i
a
Control
i
s
Navigation
Navigation
s
s
24
Code Generation Strategy II
Generate independent code for each task /
actuator Trigger queue can have several
elements More concurrency
25
Code Generation Strategy II
0ms
5ms
10ms
b1 call(actuate) future(now10,b1)
a
i
a
Control
i
b2 call(sense) future(now5,b2)
b3 call(input) future(now10,b3)
s
Navigation
Navigation
s
s
b4 schedule(Control ) future(now10,b4)
b5 schedule(Navigation) future(now5,b5)
26
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

27
Time Safety
Environment
t
a
s
s
a
Software
28
Time Safety
Environment
t
a
s
s
a
Software
29
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

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

31
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

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

• Have an address for each tapehead 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!
34
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

35
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

36
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?

37
From Giotto to E Code
Giotto Compiler
Giotto code
E code
Executable
Time Safe?
Platform Constraints (wcet)
YES
NO
38
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

39
Helicopter Software
Navigation
Control
10
5
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
40
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

41
http//www.eecs.berkeley.edu/fresco