State Space Reduction in Model Checking for Large-Scale Software

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

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

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

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

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

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

38. vEEF NASA Robot Controller System

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

40. Class Information Model of the Robot Controller Systems

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

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

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

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

45. Integrated State Space Reduction Approach Methodological Approaches Algorithmic Approaches

46. 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*

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

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

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

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