Lecture 11

You might also like

Download as pdf or txt
Download as pdf or txt
You are on page 1of 15

Lecture #12 : Model Checking II

Topics 1) Model Checking Example (ie. Mutual Exclusion) 2) Model Checking Algorithm 3) The SMV System 4) Examples of SMV Model Checking

Verification Properties
The following are two main kinds of properties that are usually verified. A safety property states that some bad thing never happens. Safety Properties represent requirements that should be continuously maintained by the system. They often express invariance properties. A liveness property states that some good thing eventually happens. Liveness properties represent requirements that need not hold continuously but whose eventual realization must be ensured.

Mutual Exclusion
When concurrent processes share a resource (such as a file on a disk or a database entry), it may be necessary to ensure that they do not have access to it at the same time. We therefore identify certain critical sections of each process code and arrange that only one process can be in its critical section at a time. The problem we are faced with is to find a protocol for determining which process is allowed to enter its critical section at a time. Once we have found one which we think works, we verify our solution by checking that it has some expected properties, such as the following ones: Safety: The protocol allows only one process to be in its critical section at any time. Liveness: Whenever any process wants to enter its critical section, it will eventually be permitted to do so. Non-blocking: A process can always request to enter its critical section. No strict sequencing: Processes need not enter their critical section in strict sequence

The First Attempt


We will model two processes, each of which is in its non-critical state (n), or trying to enter it critical state (t), or in its critical state (c). Each individual process undergoes transition in the cycle n t c

n , but the two processes interleave with each other.


The two processes start off in their non-critical section (global state s0) The figure 1 illustrates the model. Safety: AG(c1 c2) Clearly, AG(c1 c2) is satisfied in the initial state (indeed, in every state). Liveness: AG(t1 AFc1) which is not satisfied by the initial state due to the path s0, s1, s3, s7, s1, s3, s7, s1, Note that t1 is true in s1 but in s1, s3 and s7, c1 is false. Non-blocking: AG(n1 EX t1),which is satisfied, since every n1 state (i.e. s0 , s5 and s6) has an (immediate) t1 successor. Non-blocking makes sense since here state transition infers the change of states.

The First Attempt (cont.)


No strict sequencing: EF(c1 E[c1 U (c1 E[c2 U c1])]). This is satisfied by the path s5, s3, s4, s5, ... The reason liveness failed in our first attempt at modeling mutual exclusive is that non-determinism means it might continually favour one process over another. The problem is that the state s3 does not distinguish between which of the process first went into its trying state. We can solve this by splitting s3 into two states.

The Second Attempt


Consider the figure 2 where s3 and s9 there correspond to s3 in the previous attempt. They both record that both processes are in their trying states, but in s3 it is implicitly recorded that it is process 1s turn, whereas in s9 it is process 2s turn. Our transition system is still slightly over-simplified, because we are assuming that it will move to a different state on every tick of the clock (there are no transitions to the same state). We may wish to model that a process can stay in its critical state for several ticks, but if we include an arrow from s2, or s6, to itself, we will again violate liveness. This problem can be solved by specifying some fairness constraints.

A Model Checking Algorithm


Given a Kripke structure M = (S, R, L) that represents a finite-state concurrent system and a temporal logic formula f expressing some desired specification, find the set { s S | M, s |= f }. Some states of S are designated as initial states. The system satisfies specification provided that all of the initial states are in the set. M,s |= f for every s Init-State The following shows the algorithm for model checking used explicit representation of the Kripke structure. The algorithm labels each state s with the set label(s) of subformulae of f which are true in s. Initially, label(s) is just L(s), the set of all atomic propositions which are sub-formulae of f. The algorithm then goes through a series of stages. During the i-th stage, sub-formulae with i-1 nested CTL operators are processed. When a sub-formula is processed, it is added to the labeling of each state in which it is true.

Model Checking Algorithm (cont.)


Recall that any CTL formula can be expressed in terms of , , EX,

EU and EG.
Thus, for the intermediate stages, it is sufficient to be able to handle six cases : atomic, f, f1 f2, EX f, E[ f1 U f2] and EG f. For formulae of the form f, we label those states that are not labeled by f. For f1 f2, we label any state that is labeled either by f1 or by f2. For EX f, we label every state that has some successor state labeled by f. For formula E[ f1 U f2], we first find states that are labeled with f2. We then work backwards using the converse of the transition relation R and find all states that can be reached by a path in which each state is labeled with f1. All such states are labeled with E[ f1 U f2].

Model Checking Algorithm (cont.)


The case for EG f is slightly more complicated. It is based on the decomposition of the graph into nontrivial strongly connected components. A strongly connected component C is a maximal sub-graph such that every node in C is reachable from every other node in C along a directed path entirely contained within C. C is nontrivial iff either it has more than one node or it contains one node with a self-loop, a link to the node itself. Let M be obtained from M be deleting from S all of those states at which f does not hold and restricting R and L accordingly. In other words, M is a sub-model of M such that M contains only states in M that satisfy f. Thus, M = (S, R, L) where S = {s S | M, s |= f }, R = R|SS, and L = L | S. M, s |= EG f iff 1) s S, ie. s |= f and 2) There exists a path in M that leads from s to some node t in a nontrivial strongly connected component C of the graph (S, R).

Model Checking Algorithm (cont.)


Condition 2 ensures us that 1) All states in the path from s to t satisfy f (due to s S), and 2) From t onwards, there exists a path which consists only states that satisfy f. The non-triviality for strongly connected components ensures that there exists an (infinite) path (generated from the graph (S, R) where all states in the path satisfy f). Note that the requirement on the number of nodes in non-triviality makes sense since by the definition of our Kripke structure, R is total.

10

Model Checking Algorithm (cont.)


Let consider the microwave oven example. We would like to check AG(start AF heat) which is equivalent to EF (start EG heat) which is equivalent to E(T U (start EG heat)) Define S(g) as the set of all states labeled by the sub-formula g. Clearly, the following are true. S(start) = { 2, 5, 6, 7} S(heat) = {1, 2, 3, 5, 6} To determine EGheat, we need to find the set of nontrivial strongly connected components in S = S(heat), and the set is {{1, 2, 3, 5}}. Thus, S(EGheat) = {1, 2, 3, 5}. Clearly, S(start EGheat) = {2, 5}. Thus, S(E(T U (start EG heat)) ) = { 1, 2, 3, 4, 5, 6, 7 }. So, S( E(T U (start EG heat)) ) = .

11

The State Explosion problem


Although the labeling algorithm is linear in the size of the model, unfortunately size of the model is itself exponential in the number of variables and the number of components of the system which execute in parallel. This means that, for example, adding a boolean variable to your program will double the complexity of verifying a property of it. The tendency of the state space to become very large is known as the state explosion problem. The following are ways to overcome this problem. 1) Efficient data structure, called ordered binary decision diagrams (OBDDs), which represents sets of states instead of individual states.

2) Abstraction: we abstract away variables in the model which are not relevant to the formula being checked.

3) Partial order reduction: for asynchronous systems, several interleavings of component traces may be equivalent as far as satisfaction of the formula to be checked is concerned.

4) Composition: break the verification problem down into several simpler verification problems.

12

The SMV system


We look at the best-known of the CTL model checkers, which is called SMV (symbolic model verifier) It provides a language for describing the model, the state transition system, and it directly checks the validity of CTL formulas on those models. SMV takes as input a text consisting of a program describing a model and some specifications (CTL formulae) It produces as output either the word true if the specifications hold for all initial states, or a trace showing why the specification is false for the model determined by our program. SMV programs consist of one or more modules. One of the modules must be called main. Modules can declare variables and assign to them. Assignments usually give the initial value of a variable and its next value as an expression in terms of the current values of variables.

13

The SMV system (cont.)


The following shows a program describing a model. MODULE main VAR Request : boolean; Status ASSIGN init(status) := ready; next(status) := case request : busy; 1 : {ready, busy}; esac; SPEC : {ready, busy}

AG(request -> AF status = busy)


The program has two variables, request of type boolean and status of type ready or busy: 0 denote F and 1 represents T. The variable request is not determined within this program; this mean it may be determined by the user, or by the environment. The variable status is partially determined: initially, it is ready; and it becomes busy whenever request is true. If request is false, the next value of status is not determined.

14

The SMV system (cont.)


Note that the case 1: signifies the default case and that case statements are evaluated from the top down: if several expressions to the left of : are true, then the command of the first true expression will be executed.

15

You might also like