Hierarchical Design and Analysis of Reactive Systems

1. Hierarchical Design and Analysis of Reactive Systems Radu Grosu Stony Brook University www.cs.sunysb.edu/~radu

2. Reactive Systems Commercial Aircraft Telecommunication Household devices Automobiles Nuclear Power Plants Medical devices Computer based reactive systems are becoming an integral part of nearly every engineered product. They control:

3. The Boeing 777 Has > 4Mlines of code > 1Kembedded processors in order to - controlsubsystems - aid pilotsin flight mngmnt. One of the greatest challenges in software engineering: • hardreal-timedeadlines, • mission and safety-critical, • complex and embedded within another complex system, • interacts with humans in a sophisticated way. Super Computers with Wings "Companies that exploit information technology most effectively will be the most likely to dominate the aerospace landscape in the 21st century" [Aviation Week, 12/98].

4. Talk Outline • Introduction • Modeling reactive systems • Mode diagrams • From statecharts to mode diagrams • Modular reasoning • Model checking • Wrap-up

5. Why Building Models? • To understand the problem better, • To communicate with customers, • To finderrors or omissions, • To plan out the design, • To generatecode. Modeling is a technique widely used in all engineering disciplines. In particular, for reactive systems it allows:

6. Modeling Reactive Systems • Software Engineering Methods (e.g. UML, UML-RT) • mixedvisual/textualnotations, • speedup thedevelopment cycle, • improvecustomer /developercommunication • restricted analysis by simulation and testing, • restrictedconfidencein the modeled system. • Formal Methods (e.g. Model Checkers) • mathematicalmodels of reactive systems, • speedup specification/prototyping, • allowa thoroughanalysisof the modeled system, • highconfidencein the modeled system. • Currently there aretwo main methods • for modelingreactive systems: • Software engineering methods, • Formal methods.

7. Software Engineering Methods • Successfully applied in • Automotive, aerospace and telecommunications • Logic design • Tools • SDL, ROOM, Statemate, Rhapsody, UML-RT • Cierto VC CoDesign, StateCAD/StateBench • Companies • Telelogic, Verilog, ObjecTime, iLogix, Rational • Cadence, Visual Software Solutions

8. model yes temporal property error trace Model Checkers Model Checker No longer an academic research only. "... model checking will be the second most important, if not the most important, tool in the verification tool suite.“ [Cadence Web] • Advantage • Fully automated formal verification, • Effective debugging tool • Standard approaches • Enumerative search with reduction heuristics • Symbolic search using BDDs

9. Model Checkers • Successfully applied in • Hardware design and analysis • Finding bugs in cache coherence protocols, video graphics image chips (>96 processors) • Tools • Spin, Murf, Mocha, LMC, XMC,… • FormalCheck, Cospan, VERDICT, SMV, VIS,… • Companies • Cadence, Lucent, Intel, IBM, Motorola, Siemens

10. Unfortunately  • There is aconsiderable gapbetween thesoftware engineeringandthe formalmethods. • Scalability is still a challenge for formal analysis tools.

11. Fortunately  Long Term Research Program • Close the gap between the software engineering and the formal methods, • Scale up the analysis tools by exploiting the software engineering artifacts.

12. Talk Outline • Introduction • Modeling reactive systems • Mode diagrams • From statecharts to mode diagrams • Modular reasoning • Model checking • Wrap-up

13. Mode Diagrams • Visual language for hierarchic reactive machines • hierarchic modes, mode sharing, • group transitions, history, • mixed and/or hierarchies. • 2.Observational trace semantics • mode refinement, • modular reasoning. • 3. Model checker • exploits the hierarchy information, • exploits the type information.

14. TelI = tk | onH | offH | dig(int) TelO = tk | dtB | dtE | rtB | rtE ti1,…,tin : TelI; to1,…,ton : TelO; ti1 to1 tin ton TelExchange ti1 tin to1 ton TelSw1 TelSwn … bon bo1 bi1 bin Bus TelExchange Telephone Exchange: Architecture • Characteristics • Description is hierarchic. • Well defined interfaces. • Supports black-box view. • Model checking • Modular reasoning. • E.g. in SMV, Mocha,…

15. Telephone Exchange: Behavior readti : TelI, bi : BusI; writeto : TelO,bo : BusO; localnr : (0..n) onH call onHook offHook TelSw1 TelSwn rtB … ti1 tin to1 ton answ bon bin Bus onH onH bo1 bi1 ti?onH ok offH TelExchange call gettingNo idle connecting call rtB rtB rtE ok rtB offH answ rtB ringing talking answ

16. Talk Outline • Introduction • Modeling reactive systems • Mode diagrams • From statecharts to mode diagrams • Modular reasoning • Model checking • Wrap-up

17. Statecharts • Formalism • Introduced: 1987 byDavid Harel, • Related notations:Rsml, Modecharts, Roomcharts, • Key component in OO Methods: UML, ROOM, OMT, etc. • Software • ILogix, ObjecTime, Rational, etc. • Application Area • Automotive industry, avionics, telecommunications, etc. • Semantics • Many attempts (more than 24 semantics), • All operational: no trace semantics, no refinement rules.

18. From Statecharts to Modes • Regular transitions ->Entry/exit points(control interface) • Group transitions ->Default points(control interface) onH onH ini call onHook offHook call offH ok idle gettingNo connecting rtB rtE ok answ answ offH ringing talking rtB onHook offHook rtB rtB telSw Obstacles in achieving modularity • Regular transitions connect deep nested modes. • Group transitions implicitly connect deep nested modes. • Nested state references break encapsulation. • State reference -> Scoping of variables(data interface)

19. Talk Outline • Introduction • Modeling reactive systems • Mode diagrams • From statecharts to mode diagrams • Modular reasoning • Model checking • Wrap-up

20. Operational Semantics dx m t1 t3 t2 sm1 sm2 e1 x1 t4 t6 t5 sm3 e2 x2 de • Macro transitions (mT) • Form (e,s) -> (x,t) • Obtained:(e0,s0)-> (c1,s1)->… -> (en,sn) • Operational semantics • Control points, variables, macro transitions.

21. Denotational Semantics • Execution of m • (e0,s0)-> (x0,t0)-> (e1,s1)-> (x1,t1)->… -> (xn,tn) • For even i, (ei,si)-> (xi,ti) is in mT • For odd i, si[Vp] = si+1[Vp] • Set of Traces Lm of m • Projection of executions on global variables. • Denotational semantics • Control points, global vars, Lm. • Refinement m < n • Inclusion of the sets of tracesLm  Ln

22. Modular Reasoning <N M M’ N’ < N’ N < N N < N < < N M M’ M M N Sub-mode refinement Super-mode refinement N’ N’ N’ N M’ M’ M M’ N’ N < M M’ Assume/guarantee reasoning

23. Talk Outline • Introduction • Modeling reactive systems • Mode diagrams • From statecharts to mode diagrams • Modular reasoning • Model checking • Wrap-up

24. Symbolic Search R1 R2 Rk A R0 Ok+1 = Rk+1– Rk Rk+1 = Rk | (Ok&T)

25. Model Checking • Graphical editor and both an enumerativeandasymbolicmodel checker. • Reachability analysis exploits the structure: • Reached state space indexed by control points • Transition relation is indexed by control points • Transition type exploited • Mode definitions are shared among instances.

26. Example: Generic Hierarchic System localc : (0..2) localz : (0..n) c z skp inc inc w0 w1 z c=1 & z<n -> c:=0; z:=z+1; skp id v3 w1 (c=1 & w1=n) | c=2 -> skip; skp inc inc skp v2 v3 skp inc localw1 : (0..n) localv3 : (0..n)

27. The Reached Set z c skp R(c,z) skp inc w0 w1 z id inc R(c,z,w1,v3,hw1) R(c,z,w1,v3,hw1,hz) v3 w1 R(c,z,w1) skp inc inc skp v2 v3 skp inc R(c,z,w1,v3) R(c,z,w1,v3) • The reached set is indexed by control points: • Each reached control point has an associated • multi valued binary decision diagram (mdd), • The set of variables of an mdd depends on • the scope of the control point.

28. The Transition Relation z gcs hz = 2 skp skp inc w0 w1 z id inc c,v3.( R(c,z,w1,v3) & inc(c,c’,v3,v3’) )[c’,v3’:=c,v3] h’z = 1 w1.( R(c,z,w1) & skp(c,w1)) v3 w1 inc skp skp v2 v3 skp inc inc c=1 & v3<n & c’=0 & v3’=v3+1 (c=1 & w1=n) | c=2 • The transition relation is indexed by control • points (> conjunctively partitioned mdds): • Each transition has an associated mdd, • The set of variables of an mdd depends on • the scope of the transition, • Type information: no identity extension necessary, • Variablescoping enables early quantification.

29. Results • As expected,themodel checker for modes is superiorto currentmodel checkerswhen: • sequential behavior ishierarchical, • modes havelocal variables.

30. GHS Space Requirements

31. GHS Time Requirements

32. Wrap-Up • Hierarchic Reactive Machines • Compositional semantics [CSD’98, POPL’00] • Model checking [CAV’00] • Hybrid Systems • Compositional semantics [FTRTFT’98, WRTP’98], • Hybrid mode diagrams in CHARON [HSCC’00] • Message Sequence Charts • Semantics [CSI’98, OOPSLA’97] • Automatic translation to SM [DIPES’00, GP19837871], • Hybrid sequence charts [WORDS’99, ISORC’00] Bridging the gapbetweensoftwareengineeringandformal methodsprovides a wealth ofresearch opportunities:

33. Wrap-Up • Automating Modular Reasoning • Refinement check of asynchronous systems[FMCAD’00] • Modeling Mobile Systems • Dynamic reconfiguration [Amast’96, NWPT’96], • Mobility [HICSS’98] • Formal Foundation of OO Methods • UML [TAA’98, ECOOP’97] • UML-RT [JUCS’00, JOOP’00, OOPSLA’98, BSBS’99]

35. Mocha Tool • Mode diagrams will be integrated in Mocha. • Mocha itself is currently recoded in Java • for a better support for: • software engineering aspects, • modular reasoning.

36. Semantics of Modes • Game Semantics • Environment round:fromexit pointstoentry points. • Mode round:fromentry pointstoexit points. • The set of traces of a mode • Constructed solely fromthetraces of the sub-modesand the mode’s transitions. • Refinement • Defined as usual by inclusion of trace sets. • Iscompositionalw.r.t. mode encapsulation.

37. Wrap-up • Consideralternative state space representation for mode diagrams (e.g. indexing the mdds by modes), • Allow optional compilationof modes to their macro transition relation, • Automatemodular reasoning for mode diagrams, • Fully integrate mode diagrams with Mocha, • Consider abstraction mechanisms for modes, • Consider applications of and/or mode hierarchies, • Extension to hybrid mode diagrams, • Integration with sequence diagrams,

38. Structural View Implement View User View Behavioral View Environment View Modeling in UML • Class Diagrams • Object Diagrams • Component Diagrams Modeling in UML consists of building several models according to five views: • Use Case Diagrams • Sequence Diagrams • Collaboration Diagrams • Statechart Diagrams • Activity Diagrams • Deployment Diagrams

39. Structural View Implement View User View Behavioral View Environment View Modeling in UML • Class Diagrams • Object Diagrams • Component Diagrams • Use Case Diagrams • Sequence Diagrams • Collaboration Diagrams • Statechart Diagrams • Activity Diagrams • Deployment Diagrams

40. Motivation • Scalable analysis demands modular reasoning: • modeling language has to support syntactically and semantically modular constructs, • model checking has to exploitmodular design. • Close the gap between: • software design languages (UML, Statecharts, Rsml), • model checking languages (Spin, SMV, Mocha).

41. Talk Outline • Introduction • Modeling reactive systems • Mode diagrams • From statecharts to mode diagrams • Modular reasoning • Conjunctive modes • Implementation • Wrap-up

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

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

44. N’ N’ N’ N < < N N M’ M’ M M’ N’ N < N M M’ Assume/Guarantee Reasoning

45. Talk Outline • Introduction • Modeling reactive systems • Mode diagrams • From statecharts to mode diagrams • Modular reasoning • Conjunctive modes • Implementation • Wrap-up

46. read i1,i2 ,p1,p2; write o1,o2,p1,p2; i1 i2 M1 s1 s11 s2 M1 M2 M2 syst syst read i1,p2; write o1,p1; read i2,p1; write o2,p2; M1 M2 M1 M2 o1 p1 p2 o2 s1 s11 s2 sk sk1 sk+1 Parallel composition of reactive modules Translation with modes env env Conjunctive Modes • Synchronous semantics • State • s = (i1, i2, o1, o2, p1, p2) • Execution s0 …

47. explWNHO lookFGU headTT lookFS lookFHO found search approach sonarM motionC done pick transport Search&rescue headTKL lookFEC And/Or Hierarchies The ability to express conjunctive modes is important for the construction of arbitrary and/or hierarchies. Consider a hypothetical search and rescue robotoperating on abattle field:

48. TextEditor VisEditor TextEditor VisEditor TextEditor VisEditor Parser Parser Parser ArchModel BehModel Specification hRM DB ModelChecker Simulator Proofs DB Rules DB Specs DB Proof Manager Tacticals DB BDD Packs Reduction Algs Mocha Tool Architecture Integrated Development Environment Manager

49. Structural View • Class Diagrams • Object Diagrams Wrap-up Bridging the gap betweensoftware engineeringandformal methodsprovides a wealth of research opportunities: • Allow to express architectural design patterns: • add process arrays, • exploit symmetry, • addabstraction mechanisms, • automate modular reasoning, • add dynamic architectures, • architecture algebra.

50. Behavioral View Wrap-up • Popular in requirements capture and testing: • sequence diagrams for shared memory, • sequence diagrams for hybrid systems, • automatic translation to mode diagrams, • analysis of sequence diagrams, • consistency of sequence/mode diagrams, • interaction algebra. • Sequence Diagrams • Collaboration Diagrams