1 / 28

Efficient Reachability Analysis of Hierarchic Reactive Modules

Efficient Reachability Analysis of Hierarchic Reactive Modules. R. Alur, R.Grosu, M.McDougall University of Pennsylvania www.cis.upenn.edu/~alur,grosu,mmcdougall. Motivation. Scalable analysis demands modular reasoning:

rhaven
Download Presentation

Efficient Reachability Analysis of Hierarchic Reactive Modules

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. EfficientReachability Analysis of Hierarchic Reactive Modules R. Alur, R.Grosu, M.McDougall University of Pennsylvania www.cis.upenn.edu/~alur,grosu,mmcdougall

  2. 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 designlanguages (UML,Statecharts,Rsml,…), • model checkinglanguages (Spin, SMV, Mocha,…).

  3. Talk Outline • Motivation • Mode diagrams • From statecharts to mode diagrams • Model checking • Wrap-up

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

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

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

  7. Statecharts • Formalism • Introduced: 1987 byDavid Harel, • Related notations:Rsml, Modecharts, Roomcharts, • Key component in OO Methods: UML, ROOM, OMT, etc. • Difficulties • No denotational trace semantics (no refinement notion), • No scoping for variables. • Previous attempts compile statecharts to flat diagrams.

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

  9. 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 in mdd construction, • Mode definitions are shared among instances.

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

  11. c z c c z z z c c skp inc inc w1 w0 w0 w1 z skp id w0 = 0 w1 = 1 w0 = 0 w1 = 1 stored as z = 0 z = 0 z = 0 z = 0 c = 1 c = 1 c = 1 c = 1 Enumerative Model Checker • Transitions • Traversed in adepth first way, • Indexed by control points, • Shared among instances of the same definition. • States • States are stored as a stacks, • Stacks share common elements, • States (stacks) are entries of a hash table, • States are compressed as bitstrings.

  12. Symbolic MC: The Reached Set z c skp skp inc w0 w1 z id inc R(c,z,w1,v3,hw1) 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.

  13. Symbolic MC: 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 • 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.

  14. x u y z v w inc inc P(x,y)& (Q(u,v) | R(u,w)) Hierarchy and Concurrency

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

  16. GHS Space Requirements

  17. GHS Time Requirements

  18. Project HeRMes • Current status: • visual language for behavior hierarchy, • compositional semantics, • modular refinement rules, • model checking exploits hierarchic structure. • Future work: • improve heuristics exploiting hierarchy, • improve use of sharing, • integrate/automate modular reasoning, • collaboration with NEC on case studies, • connection to Rational Rose/ObjecTime.

  19. Demos at CAV • jMocha v2.0 (released soon): • joint project U.C. Berkeley & UPenn, • a new version written in java, • several new features: • MSC-like simulator, proof manager, script language. • HeRMes v1.0 (prototype): • developed at UPenn, • supports mode diagrams in this talk, • Demos: • Tuesday morning, • Wednesday afternoon.

  20. Modular Reasoning M M’ N’ < 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

  21. A Macro Step • A macro step is a breadth first traversal • of the hierarchic mode graph starting at: • the default entry point of the top level mode • and ending at: • the default exit point of the top level mode or • inside the mode if no new states are produced.

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

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

  24. readi1,i2 ,p1,p2; writeo1,o2,p1,p2; i1 i2 M1 s1 s11 s2 M1 M2 M2 syst syst readi1,p2; writeo1,p1; readi2,p1; writeo2,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 …

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

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

  27. Behavioral View Wrap-up • Consider differential equations for activities: • Hybrid hierarchic modes, • Avionics, robotics, automotive industry. • Global and modular symulation, • Exploit hierarchy in analysis, • Relate to hybrid sequence diagrams. • Activity Diagrams

More Related