Presentation is loading. Please wait.

Presentation is loading. Please wait.

Tools for Formal Modeling And Verification: MOCHA, HeRMes, CHARON Rajeev Alur Systems Design Research Lab University of Pennsylvania www.cis.upenn.edu/~alur/

Similar presentations


Presentation on theme: "Tools for Formal Modeling And Verification: MOCHA, HeRMes, CHARON Rajeev Alur Systems Design Research Lab University of Pennsylvania www.cis.upenn.edu/~alur/"— Presentation transcript:

1 Tools for Formal Modeling And Verification: MOCHA, HeRMes, CHARON Rajeev Alur Systems Design Research Lab University of Pennsylvania www.cis.upenn.edu/~alur/

2 Is Formal Verification Relevant to Developing Reliable Software?  Challenges: Model checking does not scale! There is a gap between model and code Model Code Model-Based Design Refinement Code generation Model Extraction Abstraction

3 Promise of Model-Based Design  Standard engineering practice in control applications  Growing acceptance of modeling tools such as RationalRose, Simulink But no formal semantics / analysis Ad-hoc features  Increasingly powerful verification tools  Formal modeling by itself is useful for modularity, reusability, rapid prototyping

4 Talk Outline  MOCHA: Exploiting architectural hierarchy for modular model checking  HeRMes  CHARON

5 MOCHA Team U Penn Rajeev Alur Minsu Kang Bow-yaw Wang SUNY Stony Brook Radu Grosu UC Berkeley Luca de Alfaro Tom Henzinger Christoph Kirsch Freddy Mang

6 Overview of MOCHA Goals Exploit design structure for scalable model checking Coherent integration of techniques Key features Compositional modeling language: Reactive Modules Refinement checking by assume-guarantee rules Game-theoretic requirements of open systems: ATL Hierarchical compression of internal transitions

7 Why Modular Reasoning? Behavior of a component can be computed from behaviors of its parts Components can be analyzed in isolation Assume-guarantee rules -> Scalable analysis Mocha Theme: Modular model checking!

8 Refinement Checking Problem Given modules Imp and Spec, check if every behavior of Imp is allowed by Spec: Imp < Spec Why relevant ? Writing Spec as another module may be easier than listing all temporal logic formulas of interest Promotes hierarchical design by successive refinements Examples Cache-coherent memory < Abstract serial memory Pipelined implementation < ISA spec Network protocol code < RFC spec

9 Refinement Verification Goal: Given two models Imp and Spec, verify that Imp refines Spec Methodology: Step 1: Using compositional rules, generate simpler subgoals Step 2: For each subgoal I < S, introduce a witness module W, and reduce the check to reachability analysis of I || W Step 3: Apply an efficient reachability check

10 Point-to-Point Protocol Popular networking protocol for establishing connections remotely Goal: To verify the actual implementation Specification: RFC 1661 (standard)  Specified in tabular format Implementation: ppp version 2.4.0  available in various Linux distributions  C code

11 PPP Verification Focus on option negotiation aspect of protocol Manually constructed module I from C-code Manually translated RFC spec to module S Goal: To verify I < S Result: Discovered an inconsistency in the code wrt specification

12 Assume Guarantee Reasoning GOAL: I0I1 < S0S1 LINK REDUCES TO I0S1 < S0 LINK Basis: formal compositional semantics of Reactive Modules

13 Classical Temporal Requirements Safety properties Mutual exclusion Deadlock freedom Liveness properties Every request is followed by response Every reachable state has a path to reset state Classical Temporal logic Linear-time (LTL) vs Branching-time (CTL) Sample formulas: [] (pc1=cs -> pc2!=cs) [] (req -> <> response)

14 Alternating Temporal Logic Suitable for requirements of open systems explicit distinction between choices of system vs env Sample game: system and env take turns EF pAG p F p

15 Alternating Temporal Logic In Mocha, multiple players that execute concurrently Sample property G p can agents A and B collaborate to maintain invariant p? existential over choices of A & B, universal over others Can specify games and controllability Recent application: Security protocols More expressive than CTL model checking via symbolic fixpoint computation

16 Talk Outline MOCHA  HeRMes: Exploiting behavior hierarchy for formal verification  CHARON

17 Hermes Team Rajeev Alur Radu Grosu Michael McDougall James Yang

18 Hierarchical State Machines Formalism  Introduced: 1987 by David Harel as Statecharts,  Related notations: RSML, Modecharts, Roomcharts,  Key component in OO Methods: UML, ROOM, OMT, etc. Software  ILogix, ObjecTime, Rational, etc. Application Area  Automotive industry, avionics, etc. Motivation for our work  Statecharts semantics unclear  Analysis cannot exploit hierarchical structure

19 Research Summary  Complexity bounds for model checking  Analysis possible without flattening  Succinctness of hierarchical constructs  Provably exponential  Formal compositional semantics  Assume-guarantee proof calculus for modes  Hermes tool for Model checking

20 Reachability Analysis What is the cost of concurrency and hierarchy ? FSM : NLogSpace Concurrent : PSPACEHierarchical: PTIME Concurrent Hierarchical: EXPSPACE Well structured: PSPACE CTL is PSPACE !

21 The HeRMes Language  Hierarchical Reactive Machines –Graphical language –Processes run concurrently –Communication using shared variables  HRM Modes –Similar to finite state machines –Input, output and local variables –May contain sub-modes –May be re-used in many locations

22 Language Structure Points: Transitions: Guard: x & y Action: y:=false Modes: Mode M1 Submode M2 Reads: x Writes: y Local: z

23 Exploiting Hierarchy in Enumerative Search  Local variables do not need to be stored when out of scope  Hierarchy gives efficient ways of storing state information  If a mode is used in two places it only needs to be searched once  Mode’s behavior only depends on readable variables - can ignore irrelevant variables

24 Exploiting Hierarchy in Symbolic Search  Transition relation is indexed by control points generalization of conjunctively partitioned bdds,  Transition type exploited for early quantification in the symbolic search,  Reached state space indexed by control points pool of variables is not global,  Mode definitions are shared among instances.

25 v2 inc skp v3 w1 incskp z id c incskp inc v3 w0 inc skp w1 z The Reached Set R(c,z,w1,v3,h w1,h z ) R(c,z,w1,v3) R(c,z,w1,v3,h w1 ) R(c,z) R(c,z,w1) 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.

26 Talk Outline MOCHA HeRMes  CHARON: Hierarchical Hybrid Systems

27 CHARON Team Rajeev Alur (CIS) Vijay Kumar (MEAM) Insup Lee (CIS) George Pappas (EE) Harvey Rubin (Med) Calin Belta Thao Dang Joel Esposito Rafael Fiero Radu Grosu (StonyBrook) Yerang Hur Franjo Ivancic Pradyumna Misra Oleg Sokolsky

28 What are Hybrid Systems? State machines off on + Dynamical systems dx=kx x<70 dx=-k’x x>60 x>68 x<63

29 Charon  Charon is a high-level modeling language and design environment reflecting state-of-the-art in formal as well as object oriented methods  Autonomous cooperating robots  Goal: Modular design, reusability, formal analysis

30 Research Summary  Language design Formal semantics Compositional refinement calculus  Analysis tools Modular simulation Accurate event detection Model checking by predicate abstraction Distributed simulation Testing …..

31 Language Summary  Individual components described as agents Composition, instantiation, and hiding  Individual behaviors described as modes Encapsulation, instantiation, and scoping  Support for concurrency Shared variables as well as message passing  Support for discrete and continuous behavior Differential as well as algebraic constraints Discrete transitions can call Java routines

32 Compositional Semantics Mode should have a precise interface spec Control interface: entry/exit points Data interface: shared (read/write, discrete/analog vars) Behaviors: traces over observables Which properties are preserved? Can we restrict reasoning to modified parts of design?

33 Modular Simulation x. y. z. 1.Hierarchical modes can be integrated at different time scales 2.Submodes viewed as black-boxes 3.Initial experimental results encouraging , x, inv1 ,x,y,inv2 Goal: To speed up simulation by exploiting The modular structure of specification

34 CHARON Applications  Multiagent robotics (DARPA MARS program) Collision avoidance, coordination, modular design  Automotive control (DARPA Mobies program) Verification/hierarchical design for Powertrain  Biological systems: Protein regulatory networks Modeling/simulation of luminiscence in Vibrio Fisheri  Graphics: animation Multiactor physics-based modeling and simulation

35 Vision-Based Control: Mode Switching

36 Motion Controller Modes in Vision Based Control Frame Grabber Actuators Avoid Obstacle Collision Recovery Edge Detector Collision Detector Color Blob Finder Robot Position Estimator Target Detector Range Mapper Wall- Following Control

37 Conclusions  Formal modeling and verification tools aimed at exploiting modularity and hierarchy, and automating compositional reasoning  Ongoing basic research Discrete abstractions of hybrid systems Compositionality for control systems Better heuristics for exploiting hierarchy

38 Promising Opportunities  Collaborations Bandera-style abstractions for hybrid systems Reachability tools for hybrid systems Integrating requirement languages (beyond temporal logics)  Case study: Programmable interface allowing formal/verified top-down design for an embedded device (e.g. a microwave oven)


Download ppt "Tools for Formal Modeling And Verification: MOCHA, HeRMes, CHARON Rajeev Alur Systems Design Research Lab University of Pennsylvania www.cis.upenn.edu/~alur/"

Similar presentations


Ads by Google