Controlling the Generation of Multiple Counterexamples in LTL Model Checking

Abstract

The focus of traditional model checking has been on the verification problem where counterexamples play a secondary role. In many potential uses of model checkers, however, counterexamples play a primary role. For example, in safety analysis, achieving perfect safety in the system being analysed is often impossible or too expensive. In such a case, the analyst is interested in discovering all of the situations that can lead to unsafe conditions in order to assess their likelihood. These situations appear as counterexamples to a system safety property expressed as a temporal logic formula in model checking.This thesis proposes an approach to model checking when counterexample generation is the primary goal. Model checking is viewed as a search for counterexamples rather than simply ensuring that a specification is satisfied by a model. The temporal logic used is Linear Temporal Logic (LTL).Most existing model checkers stop after the first counterexample is found. The few that can generate multiple counterexample paths typically generate too many counterexample paths that are slight variations of each other. For LTL, a counterexample path is an infinite sequence of states, and the number of counterexample paths for a model checking problem can be infinite. Typically, the analyst is interested in a finite number of classes of counterexample, with each class represented by a single counterexample path.However, the classes of interest are often specific to the problem domain. An approach explored in this thesis is to control the generation of counterexample paths by allowing the analyst to direct the search for a counterexample path to rule in or rule out certain classes of counterexamples. The counterexample paths generated are of the so-called lasso form, each consisting of a prefix part (a possibly empty finite sequence of states) and a cycle part (a non-empty finite sequence of states that is repeated forever).The main technique proposed for controlled generation of counterexamples within a symbolic framework is called directed counterexample generation. The search for a counterexample path is directed using two kinds of constraints: a global constraint which is a state property that must be satisfied by all states in the counterexample path, and a cycle constraint which is a state property that must be satisfied by at least one state in the cycle part of a counterexample path. While global constraints can be easily integrated with existing techniques for counterexample path generation, cycle constraints entail a search technique different from the existing techniques. As well as controlling the generation of multiple counterexample paths, the use of constraints can greatly reduce the search space in generating individual counterexample paths. The framework together with directed counterexample generation provide an infrastructure for exploring the counterexample space in a model checking problem.ii Model checking, and thus counterexample generation, suffers from the state explosion problem. Although many...

Automatic Generation of Minimal Cut Sets

“…The core of BT Analyser works for a very general class of modelling languages, including asynchronous finite-state systems with interleaving semantics [13]. It does so by using a modelling framework based on typed multi-variable state transition systems in which the effect of each transition is deterministic (but the choice of transition is non-deterministic) and the truth value of each atomic proposition in a state is determinable.…”

“…Following model checking convention, let the negation of the system safety behaviour being analysed be denoted ϕ. During model checking, a tableau (decision graph) for ϕ is superimposed on the model producing an augmented model (see [13]). The image and preimage functions for the augmented model are denoted f b and r b for an elementary block b and f B and r B for the entire system.…”

“…This enables different strategies to be used for different problems. An example is provided in [13] where reachability analysis before model checking is a good strategy for a prioritised BT model (where internal system transitions are prioritised over external events) but is a bad strategy for a non-prioritised BT model.…”

“…The two strategies described in Section 4.3 were applied to the A320 hydraulics case study used in [3] and [17]. The BT model with the injected faults is included as an example for BT Analyser, which can be accessed using the DOI 10.14264/uql.2015.16 (it is part of the supplementary material for [13]). The experiments were performed on a notebook computer with a 2.7GHz i7 CPU and 16GB of RAM running Ubuntu.…”

“…(This is a stronger assumption than simply that failures are independent.) This paper describes a completely new approach to automation of CSA, using a new model checker called BT Analyser, in which search for counterexamples can be directed [13]. As well as avoiding the need for manual steps and the assumption about non-dependence of component failures, the checker is significantly more efficient than the one used in [17], with capabilities that go well beyond CSA.…”