Model Checking A Hands-On Introduction A. Cimatti, M. Pistore, and M. Roveri £ ¢ ¡ International Conference on Automated Planning & Scheduling June 10 2003 Trento (Italy) Model Checking: A Hands-On Introduction—- June 10 2003, Trento (Italy) – p. 1 Acknowledgement These slides are derived from courses on NuSMV and Symbolic Model Checking (see http://nusmv.irst.itc.it/courses/). The goals of the course are: to provide a practical introduction to symbolic model checking, to describe the basic feautures of the NuSMV symbolic model checker. Authors of the slides: Alessandro Cimatti (ITC-irst) Marco Pistore (ITC-irst and University of Trento) Marco Roveri (ITC-irst) Model Checking: A Hands-On Introduction—- June 10 2003, Trento (Italy) – p. 2 The course at a glance Introduction Introduction to Formal Methods and Model Checking Models for Reactive Systems: Kripke Structures Properties of Reactive Systems: CTL, LTL NuSMV model checker The NuSMV Open Source project The SMV language NuSMV demo Advanced Topics Symbolic Model Checking Techniques: BDD-based and SAT-based techniques The SMV language (advanced) Play with NuSMV Model Checking: A Hands-On Introduction—- June 10 2003, Trento (Italy) – p. 3 Part 1 - Course Overview – Model Checking– A Hands-On Introduction A. Cimatti, M. Pistore, and M. Roveri £ ¢ ¡ International Conference on Automated Planning & Scheduling, June 10 2003, Trento (Italy) Model Checking: A Hands-On Introduction—- June 10 2003, Trento (Italy) – p. 4 The Need for Formal Methods Development of Industrial Systems: System reliability depends on the “correct” functioning of hardware and software. Safety-critical, money-critical systems. Growing complexity of environment and required functionalities. Market issues: time-to-market, development costs. Model Checking: A Hands-On Introduction—- June 10 2003, Trento (Italy) – p. 5 The Need for Formal Methods (II) Difficulties with traditional methodologies: Ambiguities (in requirements, architecture, detailed design). Errors is specification/design refinements. The assurance provided by testing can be too limited. Testing came too late in development. Consequences: Expensive errors in the early design phases. Infeasibility of achieving high reliability requirements. Low software quality: limited modifiability. Model Checking: A Hands-On Introduction—- June 10 2003, Trento (Italy) – p. 6 Formal Methods: Solution and Benefits The problem: Certain (sub)systems can be too complicated/critical to design with traditional techniques. Formal Methods: Formal Specification: precise, unambiguous description. Formal Validation & Verification Tools: exhaustive analysis of the formal specification. Potential Benefits: Find design bugs in early design stages. Achieve higher quality standards. Shorten time-to-market reducing manual validation phases. Produce well documented, maintainable products. Highly recommended by ESA, NASA for the design of safety-critical systems. Model Checking: A Hands-On Introduction—- June 10 2003, Trento (Italy) – p. 7 Formal Methods: Potential Problems Main Issue: Effective use of Formal Methods debug/verify during the design process; without slowing down the design process; without increasing costs too much. Potential Problems of Formal Methods: formal methods can be too costly; formal methods can be not effective; training problems; the verification problem can be too difficult. How can we get benefits and avoid these problems? by adapting our technologies and tools to the specific problem at hand; using “automated” verification techniques (e.g. model checking). Model Checking: A Hands-On Introduction—- June 10 2003, Trento (Italy) – p. 8 Formal Verification Techniques Model-based simulation or testing method: test for by exploring possible behaviors. tools: test case generators. applicable if: the system defines an executable model. Deductive Methods method: provide a formal proof that holds. tool: theorem prover, proof assistant or proof checker. applicable if: systems can be described as a mathematical theory. Model Checking method: systematic check of in all states of the system. tools: model checkers. applicable if: system generates (finite) behavioral model. Model Checking: A Hands-On Introduction—- June 10 2003, Trento (Italy) – p. 9 Simulation and Testing Basic procedure: take a model (simulation) or a realization (testing). stimulate it with certain inputs, i.e. the test cases. observe produce behavior and check whether this is “desired”. Drawback: The number of possible behaviors can be too large (or even infinite). Unexplored behaviors may contain the fatal bug. Testing and simulation can show the presence of bugs, not their absence. Model Checking: A Hands-On Introduction—- June 10 2003, Trento (Italy) – p. 10 Theorem Proving Basic procedure: describe the system as a mathematical theory. express the property in the mathematical theory. prove that the property is a theorem in the mathematical theory. Drawback: Express the system as a mathematical theory can be difficult. Find a proof can require a big effort. Theorem proving can be used to prove absence of bugs. Model Checking: A Hands-On Introduction—- June 10 2003, Trento (Italy) – p. 11 Model Checking Basic procedure: describe the system as Finite State Model. express properties in Temporal Logic. formal V&V by automatic exhaustive search over the state space. Drawback: State space explosion. Expressivity – hard to deal with parametrized systems. Model checking can be used to prove absence of bugs. Model Checking: A Hands-On Introduction—- June 10 2003, Trento (Italy) – p. 12 Industrial success of Model Checking From academics to industry in a decade. Easier to integrate within industrial development cycle: input from practical design languages (e.g. VHDL, SDL, StateCharts); expressiveness limited but often sufficient in practice. Does not require deep training (“push-button” technology). Easy to explain as exhaustive simulation. Powerful debugging capabilities: detect costly problems in early developmemt stages (cfr. Pentium bug); exhaustive, thus effective (often bugs are also in scaled-down problems). provides counterexamples (directs the designer to the problem). Model Checking: A Hands-On Introduction—- June 10 2003, Trento (Italy) – p. 13 Model Checking in a nutshell Reactive systems represented as a finite state models (in this course, Kripke models). System behaviors represented as (possibly) infinite sequences of states. Requirements represented as formulae in temporal logics. “The system satisfies the requirement” represented as truth of the formula in the Kripke model. Efficient model checking algorithms based on exhaustive exploration of the Kripke model. Model Checking: A Hands-On Introduction—- June 10 2003, Trento (Italy) – p. 14 What is a Model Checker A model checker is a software tool that given a description of a Kripke model ... ... and a property ¡ , ¢¤£ decides whether ¡ , returns “yes” if the property is satisfied, otherwise returns “no”, and provides a counterexample. Model Checking: A Hands-On Introduction—- June 10 2003, Trento (Italy) – p. 15 What is a Model Checker temporal formula G(p -> Fq) yes! Model Checker q no! p p finite-state model q counterexample Model Checking: A Hands-On Introduction—- June 10 2003, Trento (Italy) – p. 16 What is not covered in this course A deep theoretical background. We will focus on practice. Advanced model checking techniques: abstraction; compositional, assume-guarantee reasoning; symmetry reduction; approximation techniques (e.g. directed to bug hunting); model transformation techniques (e.g. minimization wrt to bisimulation). Many other approaches and tools for model checking. Model checking for infinite-state (e.g. hybrid, timed) systems. Model Checking: A Hands-On Introduction—- June 10 2003, Trento (Italy) – p. 17 Part 2 - Symbolic Model Checking – Model Checking– A Hands-On Introduction A. Cimatti, M. Pistore, and M. Roveri £ ¢ ¡ International Conference on Automated Planning & Scheduling, June 10 2003, Trento (Italy) Model Checking: A Hands-On Introduction—- June 10 2003, Trento (Italy) – p. 18 A Kripke model for mutual exclusion N1, N2 turn=0 T1, N2 N1, T2 turn=1 turn=2 C1, N2 T1, T2 T1, T2 N1, C2 turn=1 turn=1 turn=2 turn=2 C1, T2 T1, C2 turn=1 turn=2 N = noncritical, T = trying, C = critical User 1 User 2 Model Checking: A Hands-On Introduction—- June 10 2003, Trento (Italy) – p. 19 Modeling the system: Kripke models Kripke models are used to describe reactive systems: nonterminating systems with infinite behaviors, e.g. communication protocols, operating systems, hardware circuits; represent dynamic evolution of modeled systems; values to state variables, program counters, content of communication channels. © ¦ ¡£¢ ¤ ¥ § ¨ Formally, a Kripke model ¢ ¢ ¢ consists of p a set of states ¡ ; 1 ¡ ¥ a set of initial states ; ¡ ¡ ¤ a set of transitions ; q ¦ § 4 2 a set of atomic propositions ; ¦ ¡ § ¨ a labeling . 3 p Model Checking: A Hands-On Introduction—- June 10 2003, Trento (Italy) – p. 20 Path in a Kripke Model A path in a Kripke model is an infinite sequence ¨ ¡ § ¡£¢ ¡£¤ ¡£¥ £ N1, N2 ¢ ¢ ¢¦ ¦ ¦ turn=0 © ¥ ¤ § § ¡£¢ ¡ © ¡ T1, N2 N1, T2 © ¤ such that and ¢ . turn=1 turn=2 C1, N2 T1, T2 T1, T2 N1, C2 turn=1 turn=1 turn=2 turn=2 N1, N2 C1, T2 T1, C2 turn=0 turn=1 turn=2 T1, N2 N1, T2 T1, N2 turn=1 turn=2 turn=1 C1, N2 T1, T2 T1, T2 N1, C2 C1, N2 T1, T2 turn=1 turn=1 turn=2 turn=2 turn=1 turn=1 C1, T2 T1, C2 C1, T2 turn=1 turn=2 turn=1 ¡ A state ¡ is reachable in if there is a path from the initial states to . Model Checking: A Hands-On Introduction—-