1 / 62

Model Checking Large-Scale Software

Model Checking Large-Scale Software. Natasha Sharygina Carnegie Mellon University Software Engineering Institute. Outline. Model Checking Software Integrated Design and Verification Approach Integrated State Space Reduction Approach Conclusions Directions for Future Work.

pdowdell
Download Presentation

Model Checking Large-Scale Software

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. Model Checking Large-Scale Software Natasha Sharygina Carnegie Mellon University Software Engineering Institute

  2. Outline • Model Checking Software • Integrated Design and Verification Approach • Integrated State Space Reduction Approach • Conclusions • Directions for Future Work

  3. Formal Verification by Model Checking • Continuously operating concurrent systems (e.g. operating systems, hardware • controllers and network protocols) • Ongoing, reactive semantics • Non-terminating, infinite computations • Manifest non-determinism • Temporal Logic Model checking [Clarke,Emerson 81][Queille,Sifakis 82]: • Formal model, M • (state transition system - finite state machines) • Specification, P • (temporal logic) • Algorithm to check if M satisfies P, M |= P • exhaustiveenumeration of all states reachable by the system • when the design fails to satisfy a desired property, a counterexample is generated

  4. State Space Explosion • Problem: Size of the state graph can be exponential in size of the program • text(both in the number of the program variablesand the number of • program components) • M = M1 || … || Mn • If each Mi has just 2 local states, potentially 2n global states • Research Directions: State space reduction • Principal Approaches: • Abstraction (elimination of details irrelevant to verification) • Compositional reasoning (reasoning about parts of the system)

  5. Application of Model Checking to Hardware Verification • Simple data structures are used • Systems are modular • Mostly finite-state systems • System components have well defined interfaces • Mostly synchronous execution

  6. Application of Model Checking to Software Verification • Complex data structures are used • Procedural or OO design • Non-finite state systems • System components do not have well defined interfaces • Complex coordination between SW components • Synchronous or asynchronous execution

  7. Model Checking Software (current practice) •  1. Design/Implementation/Testing •  2. Modeling/Property Specification • Finite-state model extraction • Simplifications • Restrictions •  3. Verification • Abstractions • Divide-and-conquer • techniques (when applicable) • Limitations • Final (expensive) stage in the program development • Consistencybetween code and model • Limited tosimplified systems

  8. Outline • Model Checking Software • Integrated Design and Verification Approach • Integrated State Space Reduction Approach • Conclusions • Directions for Future Work

  9. Model Checking Software (UT Austin – Bell Labs Project)  4. Code Generation (last stage) •  1. Executable Design Specifications • Abstraction from low-level to • high-level operations •  2. Modeling/Property Specification • Finite-state model extraction • 3. Verification • State space reduction techniques • Advantages: • Earlier bug detection • Direct translation of informal program into formal syntax (no simplifications) • Separationof concerns: abstraction of control from data • Domain-specific property specification

  10. xUML: An Executable OO Modeling Language • Executable dialect of UML • A system consists of interacting sequential programs (class instances) • System and class hierarchies • Class instances communicate mainly through asynchronous event passing with buffering • Behavior of class instances is defined as State Models • State Models are extended with state actions • Each action is run-to-completion • State transitions are enabled by events

  11. Executable OO Modeling Language (textual xUML) • An xUML system is a parallel composition of individual sequential program, • P = p1 || … || pn, Sample commands of xUML programs: Assignments: x: = exp | x := any{exp1 , …, expn} Communication: : Generate ei(ID,exp) - Event generation Receive ei(ID,x) - Event consumption Compounds: if then else, while do od, switch

  12. A Sample xUML State Model StateTransition StateAction MessageType State

  13. Model Checking xUML Programs(UT-Bell Labs Project) xUML Model xUML Query xUML Level Error Report xUML-to-S/R Translation Error Report Generation S/R Model S/R Query S/R Query COSPAN Error Track Model Checking with COSPAN Model Checker Legend: Input Output Data Process

  14. COSPAN Model Checker and S/R Automaton Language • COSPAN is an  - automata-based model checker and input models and queries are formulated in S/R • In S/R, a system is a synchronous parallel composition of processes

  15. xUML-to-S/R Model Translation • Maps xUML class instances to S/R processes • Models asynchrony with synchrony: • An S/R process as global execution scheduler • Message buffers by separate S/R processes • Simulates dynamic creation of class instances • Bounds infinite state spaces of xUML models • Reuses modules from SDLCheck [Kurshan, Levin’01], such as optimization modules that conduct Static Partial Order Reduction

  16. xUML Level Query Formulation Proposition SemanticConstructs of xUML Model • DECLARE Joint_2_in_Move_EE <<Joint 2>> $Move_EE; • DECLARE Recovery_Called <<Recovery 1>> recovery_status = 1; • NEVER (Joint_2_in_Move_EE AND Recovery_Called); Instantiation of Temporal Template

  17. Designer Property xUML Model Error Report S/R Query S/R Model Error Track Demonstration Property Specification Interface xUML IDE Error Visualizer xUML-to-S/R Translator Error Report Generator COSPAN Model Checker

  18. Step-by-Step Demonstration Designer Property Specification Interface xUML IDE Error Visualizer Property xUML Model Error Report xUML-to-S/R Translator Error Report Generator S/R Query S/R Model Error Track COSPAN Model Checker

  19. Step-by-Step Demonstration Designer Property Specification Interface xUML IDE Error Visualizer Property xUML Model Error Report xUML-to-S/R Translator Error Report Generator S/R Query S/R Model Error Track COSPAN Model Checker

  20. Step-by-Step Demonstration Designer Property Specification Interface xUML IDE Error Visualizer Property xUML Model Error Report xUML-to-S/R Translator Error Report Generator S/R Query S/R Model Error Track COSPAN Model Checker

  21. Step-by-Step Demonstration Designer Property Specification Interface xUML IDE Error Visualizer Property xUML Model Error Report xUML-to-S/R Translator Error Report Generator S/R Query S/R Model Error Track COSPAN Model Checker

  22. Step-by-Step Demonstration Designer Property Specification Interface xUML IDE Error Visualizer Property xUML Model Error Report xUML-to-S/R Translator Error Report Generator S/R Query S/R Model Error Track COSPAN Model Checker

  23. Step-by-Step Demonstration Designer Property Specification Interface xUML IDE Error Visualizer Property xUML Model Error Report xUML-to-S/R Translator Error Report Generator S/R Query S/R Model Error Track COSPAN Model Checker

  24. vEEF NASA Robot Controller System

  25. vEEF NASA Robot Controller System • Actual robot control system deployed in space (Canadian arm) • Complex functionality (kinematics control, obstacle avoidance, fault tolerance, performance evaluation, etc.) • Complex coordination (hand shaking) between functional units • Stringent reliability requirements • Distributed control • xUML framework for design and validation of robot control algorithms • Discrete real-time modeling • ~800K LOC of textual xUML • Abstract interfaces to the computational libraries • Computational libraries (C++) • ~300K LOC, 150+ classes, 500+ methods of C++ • 34 functional properties, 20 implementation properties • 6 logical errors were found and reported to NASA

  26. Class Information Model of the Robot Controller Systems

  27. xUML Modeling of the NASA Robot Controller System Arm xUML program || EndEffector xUMLprogram

  28. Examples of the Robot Control Properties • Control Termination: Eventually the robot control terminates • EventuallyAlways(abort_var=1) • Safety Operation: If the EndEffector reaches an undesired position than the program terminates prior to a new move of the EndEffector • AfterAlwaysUntil(undesired_position =1,ee_reference=1,abort_var=1) • Configuration Validity Check: If an instance of the EndEffector class is in the “FollowingDesiredTrajectory” state than the instance of the corresponding Arm class is in the ‘Valid” state • Always((ee_reference=1) ->(arm_status=1)) • Proper Program Termination: The program terminates when it either completes the task or reaches the state where there is no solution for the fault recovery • AlwaysUntil(abort_var=0,end_position=1 OR (recovery_status=1 AND number_joints=1))

  29. Outline • Model Checking Software • Integrated Design and Verification Approach • Integrated State Space Reduction Approach • Conclusions • Directions for Future Work

  30. Efficient Model Checking of xUML Programs • State Space Reduction Approach: • Exploit design modularity for modular verification • Reduce complexity of the program prior to generation of state graph (by syntactic analysis and program transformation) • Use domain specific knowledge to derive abstractions and other reduction techniques • Use existing state space reduction techniques

  31. Integrated State Space Reduction Approach Methodological Approaches Algorithmic Approaches

  32. Assume-Guarantee Compositional Reasoning • In the assume-guarantee paradigm: each component guarantees properties based on • assumptions about other components via proof rules • M1 || T2 |= T1 • M2 || T1 |= T2 • * Circularity during verification of different blocks is broken by induction over time • [AbadiLamport95][AlurHenzinger96][HenzingerQadeerRajamani99][Kurshan94][McMillan98][Stark85] • A trace is a sequence of states • Composition of FSM (||) is the intersection of traces • Consistency check (|=) is the trace containment check Constraining environment M1 || M2 |= T1 || T2*

  33. Scalability of Multi-Process Model Checking Limitation:Properties when used as constraints commonly do not give sufficient details about the verifiable processes Approach:Add abstraction constraints Abstraction constraints(cf. Kurshan 94, Henzinger 98)are added to the property specifications: M1 || T2 |= T1|| T1abs || …|| Tnabs T1abs , …, Tkabs– abstraction constraints Abstraction constraints specification: - temporal logic formulae constraining the external variables of the verifiable processes - translation of the formulae to processes

  34. Limitations • Observation: • Conventional software structure and behaviors preclude system decomposition and • applicability of assume/guarantee reasoning • Hardware (Spatial Modularity): • Natural division into components • System components have well defined interfaces • Precisely defined communication protocols • Software (Not Spatially Modular): • Monolithic designs (even for OO programs) • Difficulties in property decomposition • No clean interfaces • Complex interaction between SW elements • Difficulties in identifying environment assumptions • Inability to specify meaningful abstraction constraints

  35. Design for Verification • Approach Enforce software design discipline: • • apply design constraints analogous to the physical constraints of hardware designs • Principle 1: Perform encapsulation at thecomponentlevel (not an object) • Principle 2:Design software components to spatial modularity • What to do? • Make state spaces of components rigorously disjoint • Channel communication through precisely defined interfaces • Specify precise communication protocols

  36. Component 4: Design model Component 1: Design model Component 2: Design model Component 1: formal model T4 T2 |= ? T1 Property decomposition: Temporal logic specification M1 || T2 || T2 || T3 |= T1 T3 Environment constraints GATE Component 3: Design model Assume/Guarantee Reasoning of Software Spatial Designs

More Related