Model-Based Design and Verification of Embedded Systems Radu Grosu SUNY at Stony Brook grosu.

Model-Based Design and Verification of Embedded

Systems

Radu Grosu

SUNY at Stony Brookwww.cs.sunysb.edu/~grosu

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]

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

Hierarchic Reactive Modules

Characteristics

• Description is hierarchic.

• Well defined interfaces.

• Supports black-box view.

Model checking

• Compositional reasoning.

• Assume/guarantee reasoning.

• E.g. in SMV, jMocha.

Architecture (Telephone Exchange)

TelExchange

ti1 to1 tin ton

TelSw1

TelExchange

Bus

TelSwn

bo1 bi1 bon bin

ti1 to1 tin ton

…

Behavior (TelSw)

connecting

talking

ok

callgettingNo

ok

answ

onHook offHook

onH

call

answ rtB

ti=rtB/to=bsy

read ti : TelI;write to : TelO;local nr : (0..n)

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.

Hierarchic Behavior DiagramsSoftware 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:

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 mSM 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

ringing

rtBrtE

rtBoffH

onHook

answ

onH

idleoffH callini

ini

onH

read ti : TelI;write to : TelO;local nr : (0..n)

ringing

rtBrtE

rtBoffH

onHook

answ

onH

idleoffH call

ini

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)

~(offH|rtB|rtE)

dxde

~(offH|rtB)h=idle

h=ringing

(ini,s5) (idle,t6) (dx,s6)

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

answ

onHook

onH

call

ini

dxde

Refinement• inclusion of trace sets,

• modular w.r.t. mode encapsulation.

(ini,s5) (idle,t6) (dx,s6)

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)

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

Modular Reasoning

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.

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

N N’< M<

M’

N

M

N’

M<

Sub-mode refinement

N

M< N

M’

Super-mode refinement

Assume/Guarantee Reasoning

M M’

N’N’ <

N

M<

M’

N’

M’M’

N’N <

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’]

b1:B b2:B

Au2

u1 u3

d:A

B

v1

v2

v3 v4

v5

v6

v7

t1

t2

t4

t3

t5

t6

t7

t1

t2

t3

t4

t5

t6

bdd of t3(x,x’)

bdd of u1(x)

y. v7(y)




• Sets of paths associated to a control point are represented implicitly with BDDs.


Model checking

• Control-flow graph traversal.

b1:B b2:B

Au2

u1 u3

d:A

B

v1

v2

v3 v4

v5

v6

v7

t1

t2

t4

t3

t5

t6

t7

t1

t2

t3

t4

t5

t6

bdd of t3(x,x’)

bdd of u1(x,x’)

v4(x,x’) = (x’.t1(x,x’) & t3(x’,x’’))[x’/x’’]

b1:B b2:B

A

B

v1

v2

v3 v4

v5

v6

v7

t2 t5

t1

t2

t3

t4

t5

t6


u2

u1 u3t1 t4

t3t6

t7

d:A



• Sets of paths associated to a control point are represented implicitly with BDDs.


Complexity O(|A| * 2k+2d)

• |A| - # edges in interproc. CFG,• k - max # global/local vars,• d – max # of in/out variables.

b1:B b2:B

A

B

v1

v2

v3 v4

v5

v6

v7

t2 t5

t1

t2

t3

t4

t5

t6

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.

u2

u1 u3t1 t4

t3t6

t7

tg

d:A

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)

-m: Monitor; -inCS: boolean;

+acq():void throws MonExc

+rel():void throws MonExc

new MonExc! inCS e

+read():int throws MonExc v: int; e:MonExc

inCs m.res.read()v

e

v

choice point(nondeterminism)

objectcreation box

return variable

methodinvocation box

return expression

exceptionexit point

local variables

RdCap

Concurrent Class Machines (cont)

+main(): void r: Resource; c: Client

-m: Monitor

+run(): void

Client extends Thread

new Resourcer

new Monitor(r)m

new Client(m)

c.start

new Client(m)

c.start

c

threadstart box

threadrun method

c

Hierarchic Hybrid Machines (Charon)

• Agents describe concurrency• Modes describe sequential

behavior– Control flow between control

points– Group transitions describe

exceptions

Emergency

{t = 1} • local t, rate

global level, infusion

Agent Controller Agent Tank

infusion

global levelglobal infusion

{level = f(infusion)} •

{ level[2,10] } level

level[2,10]

level[4,8]Compute

Normal

e

dedx

xt=10t:=0

Maintain{t<10}

differential constraint

invariant

Hermes: Top Level

Hermes: Looking Inside Modes

Ongoing WorkMain 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

M2

i2

M1

i1

o2o1 p1 p2

Parallel composition ofreactive modules

Synchronous semantics

State

s = (i1, i2, o1, o2, p1, p2)

Execution

s1 s2 s3 s4 … sk …

syst syst syst

env env

M2M’1

sv rs

Translation with modes

Conjunctive Modes

read i1,i2;write o1,o2,p1,p2;local p’1;

p’1 := p1; p1 := p’1;

M2

i2

M1

i1

o2o1 p1 p2

Parallel composition ofreactive modules

b1:B b2:B

A

B

v1

v2

v3 v4

v5

v6

v7

t2 t5

t1

t2

t3

t4

t5

t6

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.

u2

u1 u3t1 t4

t3t6

t7

tg

d:A

Model-Based Design and Verification of Embedded Systems Radu Grosu SUNY at Stony Brook grosu.

Documents