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 wasapplication specific and with minimal amount of software. • Today itdemands 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. ti1 to1 tin ton TelExchange ti1 tin to1 ton TelSw1 TelSwn … bon bo1 bi1 bin Bus TelExchange 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) 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 • Efficientanalysis, • Compositional reasoning, • Assume/guarantee reasoning. ti=rtB/to=bsy onH call onHook offHook answ rtB call ok gettingNo connecting ok answ talking

11. Hierarchic Behavior Diagrams • Software engineering • Statecharts: introduced in 1987 byDavid 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 ini onH onH call ini offH idle rtE rtB ringing rtB answ offH onHook 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. (ini,s5)  (idle,t6)  (dx,s6) h=idle ~(offH|rtB) de dx h=ringing ~(offH|rtB|rtE) Semantics of Modes • Executions (game semantics) • Environment round:fromexit points to entry points. • Mode round:fromentry points to exit points. • Example:(ini,s0)  (call,s1)  (onH,s2)  (answ,s3) • Micro steps: (ini,s0)  (idle,t1)  (call,s1) ini onH call offH idle rtE rtB ringing rtB answ offH onHook

14. Semantics of Modes • Executions (game semantics) • Environment round:fromexit points to entry points. • Mode round:fromentry points to exit points. • Example:(ini,s0)  (call,s1)  (onH,s2)  (answ,s3) • Micro steps: (ini,s0)  (idle,t1)  (call,s1) ini • (ini,s5)  (idle,t6)  (dx,s6) onH call • Traces (proj. on global vars) • traces of the sub-modes • the mode’s transitions. de dx • Refinement • inclusion of trace sets, • modularw.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 • Validonly when the interaction of a module with its environment is non-blocking.

16. < N’ N < N’ N N < N M M M M’ Sub-mode refinement Super-mode refinement Compositional Reasoning < M M’

17. N’ N < M M’ Assume/Guarantee Reasoning N’ N’ N’ N < < 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. • Transitionsbetween 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 b1:B b2:B t7 t2 t5 bdd of t3(x,x’) B y. v7(y) v3 v4 t1 t3 t5 v6 v1 v5 t2 t4 t6 v7 v2 d:A

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. • Transitionsbetween 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 b1:B b2:B t7 t2 t5 bdd of t3(x,x’) B v3 v4 v6 t1 t3 t5 v1 v5 v7 t2 t4 t6 v2 d:A 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. • Transitionsbetween control points 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. A u2 t6 t3 u1 u3 t1 t4 b1:B b2:B t7 t2 t5 B v1 v6 t1 v3 v4 t3 t5 v5 v7 t2 t4 t6 v2 d:A

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 b1:B b2:B t7 t2 t5 B v1 v6 t1 v3 v4 t3 t5 v5 v2 v7 t2 t4 t6 d:A

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 -m: Monitor; -inCS: boolean; +RdCap(m:Monitor) +acq():void throws MonExc +rel():void throws MonExc new MonExc +read():int throws MonExc v: int;e:MonExc v inCs e ! inCS e v m.res.read() RdCap local variables return expression choice point (nondeterminism) return variable method invocation box object creation box exception exit point

24. Concurrent Class Machines (cont) c.start c c new Client(m) new Client(m) 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. • {t = 1} • {level = f(infusion)} Hierarchic Hybrid Machines (Charon) differential constraint local t, rate global level, infusion global level global infusion level { level[2,10] } Compute Emergency level[4,8] e x infusion t=10 t:=0 level[2,10] dx de Maintain {t<10} Normal Agent Controller Agent Tank 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: • Capturesanity 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 basedtest 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).

30. Synchronous semantics • State • s = (i1, i2, o1, o2, p1, p2) • Execution i1 i2 M1 M2 syst syst syst o1 p1 p2 o2 • s1 s2 s3 s4 … sk … env env Conjunctive Modes Parallel composition of reactive modules

31. read i1,i2; write o1,o2,p1,p2; local p’1; i1 i2 M’1 sv rs M1 M2 M2 p1 := p’1; o1 p1 p2 o2 p’1 := p1; Translation with modes 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 b1:B b2:B t7 t2 t5 B v1 v6 t1 v3 v4 t3 t5 v5 v7 t2 t4 t6 v2 d:A