Model-Based Design and
Verification of Embedded Systems
Radu Grosu
SUNY at Stony Brook
www.cs.sunysb.edu/~grosu
Talk Outline
 Current trends in embedded software
 Hierarchic mode diagrams
 Modular reasoning
 Efficient analysis
[POPL00,TOPLAS03]
[POPL00,ASE01,TOPLAS03]
[CAV00,CAV03,ICSE01]
 Extensions and tools
[ASE01,HSCC00-01,EW02]
 Current research projects
[Career02,Reuters02]
A Quiet Computing Revolution
Most computation no longer occurs on PCs and
servers but rather in embedded devices like:
• automobiles, cell phones, insulin pumps and aircraft.
The extent of the embedded systems revolution
can be seen in a In-Stat/MDR report :
• 5.7 billion embedded microprocessors shipped in 2001
• 98% of all shipped microprocessors
• 11% forecasted annual growth through 2006.
Embedded Controllers
Control functionality of embedded processors:
• Traditionally it was application specific and with
minimal amount of software.
• Today it demands sophisticated services such as
networking capabilities and preemptive scheduling,
and is typically implemented in software (EOSs).
The cost of software-enabled control:
• Continental estimates it to 18% of the total cost
of a vehicle in 2010.
• For the automotive industry the cost was half of
Microsoft revenue in 2001.
Embedded Software Properties
Written in high level programming languages:
• Typically in C but increasingly in Java or C++.
Very stringent dependability requirements:
• human safety, consumer expectations, liability
and government regulation
• BMW recalled 15,000 7-series sedans in 2002
at an estimated cost of $50 million.
Very difficult to debug because of:
• concurrency, interrupts, exceptions, process
scheduling and hardware-in-the-loop.
Trends in Assuring Dependability
Maturity and convergence of various methods:
• Theorem provers, model checkers and compilers
use each other techniques,
• Run-time verification and testing tools use
formal models to derive monitors and tests.
Typical techniques to combat state explosion:
• Efficient data structures,
• Refinement and abstraction,
• Modular reasoning.
Integrative Model
Hierarchic state machines as common model:
• As properties: omega/tree automata,
• As designs: finite observation (Kripke) structures,
• As code: structured control-flow graphs.
Advantages of using this model:
• Support: CAV and compiler-based techniques,
• Abstraction: navigate between code and properties,
• Structure: modular reasoning and state exploration,
• Appeal: software engineers happy (UML, SDL).
Hierarchic Reactive Modules
Hierarchic state machine model featuring:
•
•
hierarchic states, state sharing,
group transitions, history.
Observational trace semantics:
•
•
state refinement,
compositional and assume/guarantee reasoning.
Efficient model checking
•
•
Symbolic as well as enumerative,
Heuristics to exploit the hierarchical structure.
Architecture (Telephone Exchange)
ti1 to1
tin ton
TelExchange
Characteristics
• Description is hierarchic.
ti1
to1 tin
ton
TelSw1 … TelSwn
bo1
bi1 bon
bin
Bus
TelExchange
• Well defined interfaces.
• Supports black-box view.
Model checking
• Compositional reasoning.
• Assume/guarantee reasoning.
• E.g. in SMV, jMocha.
Behavior (TelSw)
Characteristics
• Description is a hierarchic
read ti : TelI;
write to : TelO;
local nr : (0..n)
Kripke structure (EFSM).
onH
• group transitions, history.
ti=rtB/to=bsy
call
• Well defined interfaces.
onHook
• data & control interfaces
answ
offHook
rtB
• black-box view.
Model checking
call
• Efficient analysis,
• Compositional reasoning,
answ
• Assume/guarantee reasoning.
gettingNo
ok
connecting
ok
talking
Hierarchic Behavior Diagrams
Software engineering
• Statecharts: introduced in 1987 by David Harel,
• Key component in OO Methods: UML, ROOM, OMT, etc,
• Event based.
Formal methods
• Informal diagrams: for LTSs (CCS or CSP processes),
• Proof diagrams: for FTS (Pnueli, Manna)
• Event based and state-based respectively.
Compilers (program analysis)
• Structured control-flow graphs,
• State-based (variables), entry/exit points,
• Sequential programs: no trace semantics or refinement rules.
Modes and Contexts
A mode (context) is a tuple (C,V,SM,T) consisting of:
read ti : TelI;
write to : TelO;
local nr : (0..n)
ini
ini
offH
idle
rtE
rtB
onHook
call
Read variables Vr: finite set
Write variables Vw: finite set
Local variables Vl:
finite set
Submodes mSM visible or not:
rtB
ringing
Entry points E: finite set.
Exit points X:
finite set
Variables V = Vr  Vw  Vl:
onH
onH
Control points C = E  X:
m.Vr  Vr  Vl,
offH
answ
m.Vw  Vw  Vl
Transitions (e,,x):
e  E  SM.X, x  X  SM.E
   Vr  Vl   Vw  Vl
Semantics of Modes
Executions (game semantics)
• Environment round: from exit points
to entry points.
• Mode round:
from entry points to exit points.
• Example:
• Micro steps:
ini
onH
offH
idle
h=idle
de
(ini,s0)  (call,s1)  (onH,s2)  (answ,s3)
(ini,s0)  (idle,t1)  (call,s1)
(ini,s5)  (idle,t6)  (dx,s6)
call
~(offH|rtB)
rtE
dx
rtB
h=ringing ~(offH|rtB|rtE)
rtB
ringing
onHook
offH
answ
Semantics of Modes
Executions (game semantics)
• Environment round: from exit points
to entry points.
• Mode round:
from entry points to exit points.
• Example:
• Micro steps:
ini
onH
(ini,s0)  (call,s1)  (onH,s2)  (answ,s3)
(ini,s0)  (idle,t1)  (call,s1)
(ini,s5)  (idle,t6)  (dx,s6)
call
de
dx
answ
onHook
Traces (proj. on global vars)
• traces of the sub-modes
• the mode’s transitions.
Refinement
• inclusion of trace sets,
• modular w.r.t. mode
encapsulation.
Modular Reasoning
Terminology
• Compositional and assume/guarantee reasoning based on
observable behaviors.
Application area
• Only recently is being automated by model checkers,
• Until now restricted to architecture hierarchies.
Compositional Reasoning
• Central to many formalisms: CCS, I/O Automata,TLA, etc.
Circular Assume/Guarantee Reasoning
• Valid only when the interaction of a module with its
environment is non-blocking.
Compositional Reasoning
N
N
M
<
<
N’
<
M
N’
M
Sub-mode refinement
N
M
<
M’
N
M’
Super-mode refinement
Assume/Guarantee Reasoning
N’
M
<
N
N’
M’
M’
N
M
<
N’
M’
<
N’
M’
Efficient Reachability Analysis (SS)
Mixed representation
• Control-flow graph has an
explicit representation.
bdd of u1(x)
• Sets of states associated to
a control point are represented
implicitly with BDDs.
u1
• Transitions between control
points are represented
implicitly with BDDs.
Model checking
• Control-flow graph traversal.
v4(x) = (x. v3(x) & t3(x,x’))[x/x’]
t1
A
u2
t3
b1:B
t4
t6
b2:B
t2
t5
bdd of t3(x,x’)
v1
t1
v2
t2
v3
d:A
t7
u3
t3
t 4 v5
B
v4
y.
v7(y)
t
v
5
t6
6
v7
Efficient Reachability Analysis (SS)
Mixed representation
• Control-flow graph has an
explicit representation.
bdd of u1(x,x’)
A
u2
u1 t1
• Sets of paths associated to
a control point are represented
implicitly with BDDs.
• Transitions between control
points are represented
implicitly with BDDs.
t3
b1:B
t4
t6
b2:B
t2
t5
bdd of t3(x,x’)
Model checking
v1
• Control-flow graph traversal.
v2
t1
t2
v4(x,x’) = (x’.t1(x,x’) & t3(x’,x’’))[x’/x’’]
v3
d:A
t7
u3
t3
t 4 v5
B
v4
t5
t6
v6
v7
Efficient Reachability Analysis (SS)
Mixed representation
A
• Control-flow graph has an
explicit representation.
u2
u1
• Sets of paths associated to
a control point are represented
implicitly with BDDs.
• Transitions between control
points are represented
implicitly with BDDs.
Complexity O(|A| * 2k+2d)
t1
b1:B
t4
t2
t6
b2:B
t7
u3
t5
B
v1
• |A| - # edges in interproc. CFG, v2
• k - max # global/local vars,
• d – max # of in/out variables.
t3
t1
t2
v3
d:A
t3
tv45
v4
t5
t6
v6
v7
Efficient Reachability Analysis (CS)
A
Enabledness not guaranteed
• Default entry/exit points –
the border of a mode.
u2
tg
u1
t1
t3
b1:B
• Default entry/exit transitions
save/restore current submode.
t4
t2
t6
b2:B
t5
Analysis savings
• Interrupts are essentially
callbacks to the supermode.
• As before, local variables can
be discarded at exit points.
t7
u3
B
v1
v2
t1
t2
v3
d:A
t3
tv45
v4
t5
t6
v6
v7
Other Techniques
Structured control-flow representation
opens the way to applying various other
CAV and compiler analysis techniques:
• control-flow & counterexample guided
abstraction-refinement,
• shape analysis, live variable analysis,
modification / reference sets,
• pattern-based model extraction.
Concurrent Class Machines
RdCap
-m: Monitor; -inCS: boolean;
+RdCap(m:Monitor)
+acq():void throws MonExc
+rel():void throws MonExc
choice point
+read():int throws MonExc
return
(nondeterminism)
variable
inCs
! inCS
new MonExc
object
creation box
local
variables
return
expression
v: int; e:MonExc
e
m.res.read()
method
invocation box
v
v
e
exception
exit point
Concurrent Class Machines (cont)
Client extends Thread
-m: Monitor
+main(): void
new Resource
r
new Monitor(r)
+run(): void
thread
run method
r: Resource; c: Client
m
new Client(m)
c
new Client(m)
c
c.start
c.start
thread
start box
Hierarchic Hybrid Machines (Charon)
differential
constraint
•
{t = 1}
{ level[2,10] }
Compute
t=10
e
local t, rate
global level, infusion
•
{level = f(infusion)}
level[4,8]
x
dx de
t:=0
level
global level
global infusion
level[2,10]
Emergency
infusion
Maintain
{t<10}
Normal
Agent Controller
invariant
• Agents describe concurrency
• Modes describe sequential behavior
– Control flow between control points
– Group transitions describe exceptions
Agent Tank
Hermes: Top Level
Hermes: Looking Inside Modes
Ongoing Work
Main emphasis on embedded software:
•
Capture sanity checks (deadlock, race conditions),
high-level specs (man pages), designs and code with
structured CFGs (CCMs).
•
Efficient analysis of consistency between different
CFGs (CCMs) and model based test generation.
•
Automated generation of efficient monitored code
from high level models.
•
Tool support building on previous experience with
jMocha, Hermes and Charon.
Main Applications:
•
•
Dependable Embedded Linux (PDA footprint <500k),
Trustworthy Web Agents (e.g. crisis management).
Conjunctive Modes
Synchronous semantics
i1
i2
M1
M2
State
s = (i1, i2, o1, o2, p1, p2)
Execution
syst
o1 p1
p2 o2
Parallel composition of
reactive modules
syst
syst
s1 s2 s3 s4 … sk …
env
env
Conjunctive Modes
i1
M1
o1 p1
i2
M2
p2 o2
Parallel composition of
reactive modules
read i1,i2;
write o1,o2,p1,p2;
local p’1;
sv
M’1
p’1 := p1;
M2
rs
p1 := p’1;
Translation with modes
Efficient Reachability Analysis (CS)
Enabledness not guaranteed
A
• Default entry/exit points –
the border of a mode.
• Default entry/exit transitions u1
save/restore current submode.
t1
• As before, local variables can
be discarded at exit points.
t3
b1:B
Analysis savings
• Interrupts are essentially
callbacks to the supermode.
u2
tg
t4
t2
t6
b2:B
t7
u3
t5
B
v1
v2
t1
t2
v3
d:A
t3
tv45
v4
t5
t6
v6
v7