Model-Based Design and Verification of Embedded Systems

1
Model-Based Design and Verification of Embedded
Systems
Radu Grosu SUNY at Stony Brook www.cs.sunysb.edu/
grosu
2
Talk Outline

• Current trends in embedded software
• Hierarchic mode diagrams POPL00,TOPLAS03
• Modular reasoning POPL00,ASE01,TOPLAS03
• Efficient analysis CAV00,CAV03,ICSE01
• Extensions and tools ASE01,HSCC00-01,EW02
• Current research projects Career02,Reuters02

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

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

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

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

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

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

9
Architecture (Telephone Exchange)

• Characteristics
• Description is hierarchic.
• Well defined interfaces.
• Supports black-box view.
• Model checking
• Compositional reasoning.
• Assume/guarantee reasoning.
• E.g. in SMV, jMocha.

10
Behavior (TelSw)

• Characteristics
• Description is a hierarchic
• Kripke structure (EFSM).
• group transitions, history.
• Well defined interfaces.
• data control interfaces
• black-box view.
• Model checking
• Efficient analysis,
• Compositional reasoning,
• Assume/guarantee reasoning.

tirtB/tobsy
onH
call
onHook
offHook
answ
rtB
call
ok
connecting
gettingNo
ok
answ
talking
11
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.

12
Modes and Contexts
A mode (context) is a tuple (C,V,SM,T) consisting
of
Control points C E ? X Entry points E
finite set. Exit points X finite set
Variables V Vr ? Vw ? Vl Read variables Vr
finite set Write variables Vw finite set
Local variables Vl finite set Submodes m?SM
visible or not m.Vr ? Vr ? Vl, m.Vw ? Vw ?
Vl Transitions (e,?,x) e ? E ? SM.X, x ? X ?
SM.E ? ? ?Vr ? Vl ? ?Vw ? Vl
read ti TelI write to TelO local nr
(0..n)
13
Semantics of Modes

• Executions (game semantics)
• Environment round from exit points to entry
  points.
• Mode round from entry points to exit
  points.
• Example (ini,s0) ? (call,s1) ?
  (onH,s2) ? (answ,s3)

• Micro steps (ini,s0) ? (idle,t1) ?
  (call,s1)

onH
ini
call
offH
idle
rtB
rtE
ringing
rtB
answ
offH
onHook
14
Semantics of Modes

• Executions (game semantics)
• Environment round from exit points to entry
  points.
• Mode round from entry points to exit
  points.
• Example (ini,s0) ? (call,s1) ?
  (onH,s2) ? (answ,s3)

• Micro steps (ini,s0) ? (idle,t1) ?
  (call,s1)

onH
ini
(ini,s5) ? (idle,t6) ? (dx,s6)
call

• Traces (proj. on global vars)
• traces of the sub-modes
• the modes transitions.

dx
de

• Refinement
• inclusion of trace sets,
• modular w.r.t. mode encapsulation.

answ
onHook
15
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.

16
Compositional Reasoning
lt
M
M
17
Assume/Guarantee Reasoning
N
N
N
N
lt
lt
M
M
M
M
18
Efficient Reachability Analysis (SS)

• Mixed representation
• Control-flow graph has an explicit
  representation.
• Sets of states associated to a control point are
  represented implicitly with BDDs.
• 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

bdd of u1(x)
A
u2
t6
t3
u1
u3
t1
t4
b1B
b2B
t7
t2
t5
bdd of t3(x,x)
B
?y. v7(y)
v3
v4
v6
t1
t3
t5
v1
v5
v7
t2
t4
t6
dA
v2
19
Efficient Reachability Analysis (SS)

• Mixed representation
• Control-flow graph has an explicit
  representation.
• Sets of paths associated to a control point are
  represented implicitly with BDDs.
• Transitions between control points are
  represented implicitly with BDDs.
• Model checking
• Control-flow graph traversal.

bdd of u1(x,x)
A
u2
t6
t3
u1
u3
t1
t4
b1B
b2B
t7
t2
t5
bdd of t3(x,x)
B
v3
v4
v6
t1
t3
t5
v1
v5
v7
t2
t4
t6
dA
v2
v4(x,x) (?x.t1(x,x) t3(x,x))x/x
20
Efficient Reachability Analysis (SS)

• Mixed representation
• Control-flow graph has an explicit
  representation.
• 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 2k2d)
• A - edges in interproc. CFG,
• k - max global/local vars,
• d max of in/out variables.

A
u2
t6
t3
u1
u3
t1
t4
b1B
b2B
t7
t2
t5
B
v1
v6
v3
v4
t1
t3
t5
v5
v7
t2
t4
t6
v2
dA
21
Efficient Reachability Analysis (CS)
A

• Enabledness not guaranteed
• Default entry/exit points the border of a mode.
  
• Default entry/exit transitions save/restore
  current submode.
• Analysis savings
• Interrupts are essentially callbacks to the
  supermode.
• As before, local variables can be discarded at
  exit points.

u2
tg
t6
t3
u1
u3
t1
t4
b1B
b2B
t7
t2
t5
B
v1
v6
v3
v4
t1
t3
t5
v5
v2
v7
t2
t4
t6
dA
22
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.

23
Concurrent Class Machines
RdCap
local variables
return expression
choice point (nondeterminism)
return variable
method invocation box
object creation box
exception exit point
24
Concurrent Class Machines (cont)
Client extends Thread
-m Monitor
main() void r Resource c Client
new Resource
r
m
c.start
new Monitor(r)
run() void
thread start box
thread run method
25
Hierarchic Hybrid Machines (Charon)
differential constraint
local t, rate global level, infusion
global level global infusion
level
level?2,10
Emergency
Compute
level?4,8
infusion
e
x
t10
t0
level?2,10
de
dx
Maintain
tlt10
Agent Controller
Agent Tank
Normal
invariant

• Agents describe concurrency
• Modes describe sequential behavior
• Control flow between control points
• Group transitions describe exceptions

26
Hermes Top Level
27
Hermes Looking Inside Modes
28
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 lt500k),
• Trustworthy Web Agents (e.g. crisis management).

29
(No Transcript)
30
Conjunctive Modes
Parallel composition of reactive modules
31
Conjunctive Modes
Parallel composition of reactive modules
32
Efficient Reachability Analysis (CS)

• Enabledness not guaranteed
• Default entry/exit points the border of a mode.
  
• Default entry/exit transitions save/restore
  current submode.
• Analysis savings
• Interrupts are essentially callbacks to the
  supermode.
• As before, local variables can be discarded at
  exit points.

A
u2
tg
t6
t3
u1
u3
t1
t4
b1B
b2B
t7
t2
t5
B
v1
v6
v3
v4
t1
t3
t5
v5
v7
t2
t4
t6
v2
dA