Modelbased Design of Embedded Software

1
Model-based Design of
Embedded Software
Tom Henzinger University of California,
Berkeley September 10, 2002
2
Requirements
Verification
Model
Environment
Implementation
Platform
3
Requirements
formal automatic (model
checking)
Verification
Model
Environment
Implementation
automatic (compilation)
Platform
4
Requirements
Verification
Model
Environment
property preserving
Implementation
Platform
5
Requirements
Verification
Composition
Model
Implementation
Platform
6
Requirements
Verification
Composition
Model
Deep compositionality
Implementation
Platform
7
Our Research Explores Four Principles
1. In modeling, smooth the "boolean edges" of a
system. 2. In composition, treat inputs and
outputs contra-variantly. 3. In verification,
abstract automatically and on-demand. 4. In
implementation, preserve fixed logical execution
times.
8
The FLET (Fixed Logical Execution Time) Assumption
Software Task
write actuator output at time td, for fixed d
read sensor input at time t
9
The FLET (Fixed Logical Execution Time) Assumption
Software Task
write actuator output at time td, for fixed d
dgt0 is the task's "logical execution time"
read sensor input at time t
10
High-level Embedded Programming
The programmer specifies d to solve the control
problem at hand. The compiler ensures that d is
met on a given platform (hardware resources and
performance) otherwise it rejects the program.
11
The FLET (Fixed Logical Execution Time) Assumption
time t
time td
possible physical execution on CPU
buffer output
12
Contrast the FLET with Standard Practice
output as soon as ready
13
Advantages of the FLET -predictable timing and
value behavior (environment determined programs
no race conditions, minimal
jitter) -portable, composable code (as long as
the platform offers sufficient
performance) Disadvantage of the FLET -tasks
don't always use latest available data (a small
price to pay, e.g. model helicopter)
14
The E(mbedded) Machine a virtual machine that
executes tasks in real time under the FLET
assumption. Giotto a structured, time-triggered
language that can be compiled into E machine
code. (The E machine is more general it supports
also event-triggered and asynchronous code.)
15
The Giotto Tool Chain
Simulink Model
S/G Translator
RTW Embedded Coder
Giotto Program for task timing and interaction
C Functions for tasks
Giotto Compiler
C Compiler
E Code
Platform Code
performance information
invokes
E Machine
Platform (minimal OS hardware)
16
The Giotto Tool Chain
S/G Simulator
Simulink Model
S/G Translator
RTW Embedded Coder
Giotto Program for task timing and interaction
C Functions for tasks
Giotto Compiler
C Compiler
E Code
Platform Code
performance information
invokes
E Machine
guaranteed conformance
Platform (minimal OS hardware)
17
Our Research Explores Four Principles
1. In modeling, smooth the "boolean edges" of a
system. 2. In composition, treat inputs and
outputs contra-variantly. 3. In verification,
abstract automatically and on-demand. 4. In
implementation, preserve fixed logical execution
times.
18
The Problem
Hybrid Model
Property
19
The Problem
Hybrid Model
Property
slightly perturbed model
20
The Problem
Hybrid Automaton
Safe
x 3
21
The Problem
Hybrid Automaton
Unsafe
x 3?
22
A Possible Solution Metric on
Traces
Model
Property
instead of
Yes or No
consider
?-Variation
23
A More Radical Solution
value(Model,Property) States ? Yes, No
value(Model,Property) States ? R
24
Discounting the Future
value(Model,Property) States ? Yes,
No value(m,?T) ?X. (T ? pre(X))
discountedValue(Model,Property) States ?
R discountedValue(m,?T) ?X. max(T, ??pre(X))
discount factor 0lt?lt1
25
Robustness Theorem If discountedBisimilarity(m1,m
2) gt 1 - ?,
then discountedValue(m1,p) - discountedValue(m2,p
) lt f(?).
26
Robustness Theorem If discountedBisimilarity(m1,m
2) gt 1 - ?,
then discountedValue(m1,p) - discountedValue(m2,p
) lt f(?).
Further Advantages of Discounting -approximabili
ty because of geometric convergence (avoids
non-termination) -applies also to probabilistic
systems and to games (enables control)
27
Our Research Explores Four Principles
1. In modeling, smooth the "boolean edges" of a
system. 2. In composition, treat inputs and
outputs contra-variantly. 3. In verification,
abstract automatically and on-demand. 4. In
implementation, preserve fixed logical execution
times.
28
In composition, treat inputs and outputs
contra-variantly.
This seems obvious The "type" of a component
should be Inputs ? Outputs not Inputs ?
Outputs. (These two are the same in set theory,
but not in type theory!)
29
In composition, treat inputs and outputs
contra-variantly.
Surprisingly, this is rather non-standard If
your notion of composition is intersection or
product, or your notion of refinement /
abstraction is simulation or language
containment, then you treat inputs and outputs
co-variantly (and are in good company).
30
y
z
x
Input constraint not xy1
Output constraint none
31
y
z
x
Input constraint not xy1
Output constraint none
Possible behaviors x y z 0 0 0 0 0 1
0 1 0 0 1 1 1 0 0 1 0 1
32
Compose with yz, forgetting what is input, what
output.
y
z
x
Input constraint not xy1
Output constraint none
Possible behaviors x y z 0 0 0 0 0 1
0 1 0 0 1 1 1 0 0 1 0 1
33
Compose with yz, constraining only output.
y
z
x
Input constraint not xy1
New output constraint zy
Possible behaviors x y z 0 0 0 0 0 1
0 1 0 0 1 1 1 0 0 1 0 1
34
Compose with yz, constraining only inputs.
y
z
x
Output constraint none
Possible behaviors x y z 0 0 0 0 0 1
0 1 0 0 1 1 1 0 0 1 0 1
Input constraint not xy1
35
Compose with yz, constraining only inputs.
y
z
x
New input constraint x0
Output constraint none
Possible behaviors x y z 0 0 0 0 0 1
0 1 0 0 1 1 1 0 0 1 0 1
36
Traditional Behavioral Refinement
Simulation or Language Containment
SpecInputs
SpecOutputs
?
?
ImpOutputs
ImpInputs
37
Compositional Refinement
Implementations can be substituted for
Specifications
SpecInputs
SpecOutputs
?
?
ImpOutputs
ImpInputs
produce only legal outputs
accept all legal inputs
38
We call a formalism with -input constraining
composition -compositional refinement an
interface theory. We have developed several
interface theories, e.g. for -message-passing
components ("interface automata")
-possibly recursive software modules (the
CHIC tool) -real-time components.

39
CHIC ("Checking Interface Compatibility")
Specify input and output constraints as Java
class annotations -call graph constraints
(e.g., method Init_Obj does not cause indirectly
a recursive invocation of itself) -precondition
constraints (e.g., method Read_File is called
only after method Open_File) CHIC checks the
compatibility of constraints across class
definitions.
40
Compatibility
Interface
Interface
CHIC
Compliance BLAST
Code
Code
41
Our Research Explores Four Principles
1. In modeling, smooth the "boolean edges" of a
system. 2. In composition, treat inputs and
outputs contra-variantly. 3. In verification,
abstract automatically and on-demand. 4. In
implementation, preserve fixed logical execution
times.
42
BLAST (The Berkeley Lazy Abstraction Software
Verification Tool)
C code that specifies a safety monitor
C source code
BLAST
Counterexample trace or Correctness certificate
43
BLAST (The Berkeley Lazy Abstraction Software
Verification Tool)
Code
Build Predicate Abstraction
New Predicates of Interest
Model Check Abstraction
Concretize Counterexample
Abstract Counterexample
Correctness Certificate
Concrete Counterexample
44
BLAST (The Berkeley Lazy Abstraction Software
Verification Tool)
Code
Locally Refine
Build Predicate Abstraction
Refined Parts of the Abstraction
New Predicates of Interest
Model Check Abstraction
Concretize Counterexample
Abstract Counterexample
Correctness Certificate
Concrete Counterexample
45
BLAST (The Berkeley Lazy Abstraction Software
Verification Tool)
Currently 10s of 1000s lines of C code checked in
a few minutes.
Code
Locally Refine
Build Predicate Abstraction
Refined Parts of the Abstraction
New Predicates of Interest
Model Check Abstraction
Concretize Counterexample
Abstract Counterexample
Correctness Certificate
Concrete Counterexample
46
Credits
Giotto and E Machine Ben Horowitz, Christoph
Kirsch, Slobodan Matic, Wolfgang Pree, Marco
Sanvido. Interfaces Arindam Chakrabarti, Luca
de Alfaro, Marcin Jurdzinski, Freddy Mang,
Marielle Stoelinga. Lazy Abstraction Ranjit
Jhala, Rupak Majumdar, George Necula, Gregoire
Sutre, Wes Weimer. Robust Hybrid Systems Luca de
Alfaro, Arkadeb Ghosal, Vinayak Prabhu, Marcin
Jurdzinski, Rupak Majumdar.