Model checking

From Infogalactic: the planetary knowledge core
(Redirected from Model checker)
Jump to: navigation, search

<templatestyles src="Module:Hatnote/styles.css"></templatestyles>

In computer science, model checking or property checking refers to the following problem: Given a model of a system, exhaustively and automatically check whether this model meets a given specification. Typically, one has hardware or software systems in mind, whereas the specification contains safety requirements such as the absence of deadlocks and similar critical states that can cause the system to crash. Model checking is a technique for automatically verifying correctness properties of finite-state systems.

In order to solve such a problem algorithmically, both the model of the system and the specification are formulated in some precise mathematical language: To this end, it is formulated as a task in logic, namely to check whether a given structure satisfies a given logical formula. The concept is general and applies to all kinds of logics and suitable structures. A simple model-checking problem is verifying whether a given formula in the propositional logic is satisfied by a given structure.

Overview

Property checking is used for verification instead of equivalence checking when two descriptions are not functionally equivalent. Particularly, during refinement, the specification is complemented with the details that are unnecessary in the higher level specification. Yet, there is no need to verify the newly introduced properties against the original specification. It is not even possible. Therefore, the strict bi-directional equivalence check is relaxed to one-way property checking. The implementation or design is regarded a model of the circuit whereas the specifications are properties that the model must satisfy.[1]

An important class of model checking methods have been developed for checking models of hardware and software designs where the specification is given by a temporal logic formula. Pioneering work in temporal logic specification was done by Amir Pnueli, who received the 1996 Turing award for "[...] seminal work introducing temporal logic into computing science",.[2] Model checking began with the pioneering work by E. M. Clarke and E. A. Emerson[3][4][5] and by J. P. Queille and J. Sifakis.[6] Clarke, Emerson, and Sifakis shared the 2007 Turing Award for their seminal work founding and developing the field of model checking.[7][8]

Model checking is most often applied to hardware designs. For software, because of undecidability (see computability theory) the approach cannot be fully algorithmic; typically it may fail to prove or disprove a given property. In embedded systems hardware designs it is possible to validate (verify against some specified requirements) a specification delivered i.e. by means of UML activity diagrams[9] or control interpreted Petri nets.[10]

The structure is usually given as a source code description in an industrial hardware description language or a special-purpose language. Such a program corresponds to a finite state machine (FSM), i.e., a directed graph consisting of nodes (or vertices) and edges. A set of atomic propositions is associated with each node, typically stating which memory elements are one. The nodes represent states of a system, the edges represent possible transitions which may alter the state, while the atomic propositions represent the basic properties that hold at a point of execution.

Formally, the problem can be stated as follows: given a desired property, expressed as a temporal logic formula p, and a structure M with initial state s, decide if M,s \models p. If M is finite, as it is in hardware, model checking reduces to a graph search.

Algorithms

state space enumeration, symbolic state space enumeration, abstract interpretation, symbolic simulation, symbolic trajectory evaluation, symbolic execution

Explicit-state model checking

Lua error in package.lua at line 80: module 'strict' not found.

Symbolic model checking

Lua error in package.lua at line 80: module 'strict' not found.

Instead of enumerating reachable states one at a time, the state space can sometimes be traversed much more efficiently by considering large numbers of states at a single step. When such state space traversal is based on representations of states sets and transition relations as formulas, binary decision diagrams or other related data structures, the model-checking method is symbolic.

Historically, the first symbolic methods used BDDs. After the success of propositional satisfiability in solving the planning problem in artificial intelligence (see satplan) in 1996, the same approach was generalized to model checking for the Linear Temporal Logic LTL (the planning problem corresponds to model-checking for safety properties). This method is known as bounded model checking.[11] The success of Boolean satisfiability solvers in bounded model checking led to the widespread use of satisfiability solvers in symbolic model checking.[12]

Tools

<templatestyles src="Module:Hatnote/styles.css"></templatestyles>

Model checking tools face a combinatorial blow up of the state-space, commonly known as the state explosion problem, that must be addressed to solve most real-world problems. There are several approaches to combat this problem.

  1. Symbolic algorithms avoid ever building the graph for the FSM; instead, they represent the graph implicitly using a formula in quantified propositional logic. The use of binary decision diagrams (BDDs) was made popular by the work of Ken McMillan.[13]
  2. Bounded model checking algorithms unroll the FSM for a fixed number of steps k and check whether a property violation can occur in k or fewer steps. This typically involves encoding the restricted model as an instance of SAT. The process can be repeated with larger and larger values of k until all possible violations have been ruled out (cf. Iterative deepening depth-first search).
  3. Partial order reduction can be used (on explicitly represented graphs) to reduce the number of independent interleavings of concurrent processes that need to be considered. The basic idea is that if it does not matter, for the kind of things one intends to prove, whether A or B is executed first, then it is a waste of time to consider both the AB and the BA interleavings.
  4. Abstraction attempts to prove properties on a system by first simplifying it. The simplified system usually does not satisfy exactly the same properties as the original one so that a process of refinement may be necessary. Generally, one requires the abstraction to be sound (the properties proved on the abstraction are true of the original system); however, most often, the abstraction is not complete (not all true properties of the original system are true of the abstraction). An example of abstraction is, on a program, to ignore the values of non boolean variables and to only consider boolean variables and the control flow of the program; such an abstraction, though it may appear coarse, may in fact be sufficient to prove e.g. properties of mutual exclusion.
  5. Counterexample guided abstraction refinement (CEGAR) begins checking with a coarse (imprecise) abstraction and iteratively refines it. When a violation (counterexample) is found, the tool analyzes it for feasibility (i.e., is the violation genuine or the result of an incomplete abstraction?). If the violation is feasible, it is reported to the user; if it is not, the proof of infeasibility is used to refine the abstraction and checking begins again.[14]

Model checking tools were initially developed to reason about the logical correctness of discrete state systems, but have since been extended to deal with real-time and limited forms of hybrid systems.

See also

Tools

Lua error in package.lua at line 80: module 'strict' not found. For a categorized list of tools see here.

  • AlPiNA,[15] AlPiNA stands for Algebraic Petri Nets Analyzer and is a model checker for Algebraic Petri Nets.
  • BLAST
  • CADP (Construction and Analysis of Distributed Processes) a toolbox for the design of communication protocols and distributed systems
  • CHESS
  • CHIC
  • CPAchecker, an open-source software model checker for C programs, based on the CPA framework
  • CTML (Computation Tree Measurement Language), a quantitative evaluation tool that covers PCTL and some PLTL that can't be expressed in PCTL.
  • ECLAIR, a platform for the automatic analysis, verification, testing and transformation of C and C++ programs
  • FDR2, a model checker for verifying real-time systems modeled and specified as CSP Processes
  • ISP code level verifier for MPI programs
  • Java Pathfinder - open source model checker for Java programs
  • LTSA - Labelled Transition System Analyser
  • LTSmin - open source model checker for various specification languages (Promela, mCRL2, UPPAAL language)
  • Markov Reward Model Checker (MRMC)
  • McErlang, a model checker for Erlang programs which can be distributed and fault-tolerant.
  • mCRL2 Toolset, Boost Software License, Based on ACP
  • MoonWalker - open source model checker for .NET programs
  • NuSMV, a new symbolic model checker
  • ompca, an interactive symbolic simulator with API control for C/C++ programs with OpenMP directives. The tool is built as an application of REDLIB.
  • PAT - an enhanced simulator, model checker and refinement checker for concurrent and real-time systems
  • Prism, a probabilistic symbolic model checker
  • Rabbit, a model checker for timed and hybrid automata
  • REDLIB, library for the model-checking of communicating timed automatas with BDD-like diagrams. Applications include a TCTL model-checker with timed fairness quantifications, fair simulation checker, and interactive symbolic simulator for C/C++ programs with OpenMP directives. GUI for model editing and symbolic simulation are also available.
  • Roméo, an integrated tool environment for modeling, simulation and verification of real-time systems modeled as parametric, time and stopwatch Petri nets
  • SMART Model checker, Symbolic Model checking Analyzer for Reliability and Timing
  • SPIN a general tool for verifying the correctness of distributed software models in a rigorous and mostly automated fashion.
  • Spot a library to implement the automata-theoretic approach for model checking. Has good translation of LTL into Büchi automata and also support the linear fragment of PSL. Must be interfaced with custom code that develop the state-space on-the-fly.
  • TAPAs: tool for the analysis of process algebra.
  • TAPAAL, an integrated tool environment for modeling, validation and verification of Timed-Arc Petri Nets
  • TLA+ model checker by Leslie Lamport
  • UPPAAL, an integrated tool environment for modeling, validation and verification of real-time systems modeled as networks of timed automata
  • Vereofy,[16] a software model checker for component-based systems for operational correctness
  • μCRL, GPL, Based on ACP
Related techniques
History

References

  1. Lua error in package.lua at line 80: module 'strict' not found.
  2. http://amturing.acm.org/award_winners/pnueli_4725172.cfm/
  3. Lua error in package.lua at line 80: module 'strict' not found.
  4. Edmund M. Clarke, E. Allen Emerson: "Design and Synthesis of Synchronization Skeletons Using Branching-Time Temporal Logic". Logic of Programs 1981: 52-71.
  5. Lua error in package.lua at line 80: module 'strict' not found.
  6. Lua error in package.lua at line 80: module 'strict' not found.
  7. Press Release: ACM Turing Award Honors Founders of Automatic Verification Technology
  8. USACM: 2007 Turing Award Winners Announced
  9. I. Grobelna, M. Grobelny, M. Adamski, "Model Checking of UML Activity Diagrams in Logic Controllers Design", Proceedings of the Ninth International Conference on Dependability and Complex Systems DepCoS-RELCOMEX, Advances in Intelligent Systems and Computing Volume 286, Springer International Publishing Switzerland, pp. 233-242, 2014
  10. I. Grobelna, "Formal verification of embedded logic controller specification with computer deduction in temporal logic", Przeglad Elektrotechniczny, Vol.87, Issue 12a, pp.47-50, 2011
  11. Lua error in package.lua at line 80: module 'strict' not found.
  12. Lua error in package.lua at line 80: module 'strict' not found.
  13. * Symbolic Model Checking, Kenneth L. McMillan, Kluwer, ISBN 0-7923-9380-5, also online.
  14. Lua error in package.lua at line 80: module 'strict' not found.
  15. alpina.unige.ch
  16. Vereofy.de

Further reading

This article is based on material taken from the Free On-line Dictionary of Computing prior to 1 November 2008 and incorporated under the "relicensing" terms of the GFDL, version 1.3 or later.