Model Checking

Model Checking

basic concepts and techniques

Sriram K. Rajamani

Sources:

My MSR Model checking crash course from Fall 99

Tom Henzinger’s slides from his OSQ course

Model checking, narrowly interpreted:

Decision procedures for checking if a given Kripke structure is a model for a given formula of a temporal logic.

Why is this of interest to us?

Because the dynamics of a discrete system can be captured by a Kripke structure.

Because some dynamic properties of a discrete system can be stated in temporal logics.

Model checking = System verification

Model checking, generously interpreted:

Algorithms for system verification which operate on a system model (semantics) rather than a system description (syntax).

Part I: Models and Specifications

Part II: State explosion

Agenda

S0

S1

S2 S3

Kripke StructureStates: valuations to a finite set

of variables

Initial states : subset of states

Arcs: transitions between states

Atomic Propositions: finite set of predicates over

variables

Observation (color):Valuation to all atomic

propositions at a state

Kripke StructureM = W, I, R, L,

W : set of states (possibly infinite) I W : set of initial states R W X W : set of arcs L : set of atomic propositions

W 2L : mapping from states to subset of atomic propostions (colors)

Three important decisions:

1 may vs. must: branching vs. linear time

2 prohibiting bad vs. desiring good behavior: safety vs. liveness

3 operational vs. declarative: automata vs. logic

Specification

S0

S1

S2 S3

S0 S1 S2

Run

Trace

S0

S1

S2 S3

S0

S1

S2 S3

Run-tree

Trace-tree

Linear temporal logics (eg LTL) view a model as a set of traces

Branching temporal logics (eg CTL) view a model as a set of trace-trees

Branching Vs Linear

S0

S3 S4

S1 S2

t2 t3

t1

t0

Same traces, different trace trees

Linear time is conceptually simpler than branching time (words vs. trees).

Branching time is often computationally more efficient.

Branching “refinement” implies linear “refinement”

Expressive powers are incomparable

Three important decisions:

1 may vs. must: branching vs. linear time

2 prohibiting bad vs. desiring good behavior: safety vs. liveness

3 operational vs. declarative: automata vs. logic

Specification

Safety vs. liveness

Safety: something “bad” will never happen

Liveness: something “good” will happen (but we don’t know when)

Example: Mutual exclusion

It cannot happen that both processes are in their critical sections simultaneously.

Example: Mutual exclusion

It cannot happen that both processes are in their critical sections simultaneously.

Safety

Example: Bounded overtaking

Whenever process P1 wants to enter the critical section, then process P2 gets to enter at most once before process P1 gets to enter.

Example: Bounded overtaking

Whenever process P1 wants to enter the critical section, then process P2 gets to enter at most once before process P1 gets to enter.

Safety

Whenever process P1 wants to enter the critical section, it enters it within 51 cycles

Whenever process P1 wants to enter the critical section, it enters it within 51 cycles

Whenever process P1 wants to enter the critical section, it is not the case that 51 cycles pass without P1 entering the critical section

Safety

Whenever process P1 wants to enter the critical section, it eventually enters it

Liveness

Sequential programs

Safety corresponds to partial correctness

Liveness corresponds to termination

The vast majority of properties to be verified are safety.

Safety Vs Liveness

While nobody will ever observe the violation of a true liveness property, fairness is a useful abstraction that turns complicated safety into simple liveness.

Why liveness?

“Eventually, we are all dead!”

The answer is: abstraction and fairness

Why liveness?

r1

r2

g1

g2

r1 r2

~r1~r2

F1 F2

G1 G2

If P1 requests and keeps requesting, it will be granted within 2 cycles

Abstract view

r2

r1

g2

g1

r2r1

F

G1 G2

r1

r2

g1

g2

r1 r2

~r1~r2

F1 F2

G1 G2

Safety: If P1 requests and keeps requesting, it will be granted within 2 cycles

Liveness: If P1 requests and keeps requesting it will be eventually granted (Does this hold?)

q1

q2

Fairness constraint:

the green transition cannot be ignored forever

q3

Without fairness: infRuns = q1 (q3 q1)* (q2) (q1 q3)

With fairness: infRuns = q1 (q3 q1)* (q2)

q1

q2 q3

Two important types of fairness

1 Weak (Buchi) fairness: a specified set of transitions cannot be enabled forever without being taken

2 Strong (Streett) fairness:a specified set of transitions cannot be enabled infinitely often without being

taken

Fair Kripke Structure

M = W, I, R, L, , SF, WF

W : set of states (possibly infinite) I W : set of initial states R W X W : set of arcs L : set of atomic propositions

W 2L : labeling functionSF: set of strongly fair arcsWF: set of weakly fair arcs

Model-Checking Algorithms for finite state Kripke structures = Graph Algorithms

Automata theoretic approach to model checking

Does M satisfy property ?

Step 1: Build automaton A for negation of

Step 2: Construct product P = MxA

Step 3: Check if L(P) is empty

1 Safety:

-algorithm: reachability (linear)

2 Response under weak fairness:

-algorithm: strongly connected components (linear)

3 Liveness:

-algorithm: recursively nested SCCs (quadratic)

Logic Model checking complexity

Invariant |M|

CTL |M| * ||

LTL |M| * 2||

Modal -calculus ?

Refinement |M| * 2|S|

Example: State MachineFor Locking

Unlocked Locked Error

U

L L

U

Product Construction

…

Lock(&x);

If (x->foo) {

if (bar(x)) {

Unlock(&x);

return OK;

}

}

Unlock(&x)

…

Product Construction

…

Lock(&x);

If (x->foo) {

if (bar(x)) {

Unlock(&x);

// return OK;

}

}

Unlock(&x)

…

Part I: Models and Specifications

Part II: State explosion

Agenda

Problem

State explosion :|M| is exponential in the syntactic

description of M

Fighting state explosion

– Symbolic techniques (BDDs) - [SMV, VIS]– Symmetry reduction - [Murphi]– Partial-order reduction - [SPIN]

– Divide and Conquer - [MOCHA, new SMV]– Abstraction - [STeP, InVeSt,SLAM]

Binary Decision Diagrams [Bryant]

Ordered decision tree for f = a b c d

0 1 1 0 1 0 0 1 1 0 0 1 0 1 1 0

d d d d d d d d

c c c c

0 1

0 1 0 1

0 1 0 1 0 1 0 1

b b

a

OBDD reduction

a

b b

c c

d d

0 1

0

01

01

01

1

10

01

01

f = a b c d

OBDD properties

Variable order strongly affects size

Canonical representation for a given order

Efficient apply algorithm– boolean operations on BDD’s is

easy– Can build BDD’s for large circuits

f

g O(|f| |g|)

fg

Boolean quantification

• If v is a boolean variable, thenv.f = f |v =0 + f |v =1

Example: b,c). (ab +ce + b´d) = a + e d

• Complexity on BDD representation– worst case exponential– heuristically efficient

Characterizing sets

• Let M be a model with boolean variables (v1,v2,…,vn)

• Represent any P {0,1}n by its characteristic function P

P = {(v1,v2,…,vn) : P}

Example:Variables = (x,y,z)P = { (0,0,1) , (0,1,0), (1,0,0), (1,1,1) }P = x + y + z

Characterizing sets

• Represent characteristic function as BDD• Set operations can be now done as BDD

operations

= false S = true

PQ= P + Q PQ = P Q S\ P= P

Transition Relations• Transition relation R is a set of state pairs

for all the arcs in the state machine– R = {((v1,v2,…,vn), (v’1,v’2,…,v’n)) : R}

v1

v0

R = (v’0 = v0) (v’1 = v0 v1)

Forward Image

})',( and , somefor :'{),(Image RPRP vvvvv

))',()((.)'(),(Image vvvvv RPRP

PR

Image(P,R)

Reverse Image

})',( and ',' somefor :{),(Image-1 RPRP vvvvv

))',()'(('.)(),(Image vvvvv RPRP

PR

Image-1(P,R)

Symbolic invariant checkingS := BDD for initial states

V := BDD for negation of invariantR := BDD for transition relationLoop

If ( S V) then print “failed” and exitI := Image( S, R)S’ := S IIf ( S = S’) then print “passed” and exit

End

BDDs

Big breakthrough in hardware • McMillan’s thesis won the ACM thesis award• Intel, IBM, Motorola all have BDD based model

checkers, and large “formal verification” teams based on them.

BDDs compactly represent transition relations• Can prove that if the circuit has “bounded”

communication,then transition relation is small• Images and Reachable sets tend to blowup

BDDs

Images and reachable sets blow up often

Subject of intense investigation (PhD theses on how to compute images without BDDs

blowing up)

Alphabetical soup of variations: ADDs to ZDDs

Work upto ~100 variables , don’t really scale to thousands of variables

Provide good “bootstrap” for compositional methods

Infinite state model checking

S := constraint for initial statesV := constraint for negation of invariantR := constraint for transition relationLoop

If ( S V) then print “failed” and exitI := Image( S, R)S’ := S IIf ( S = S’) then print “passed” and exit

End




Symmetry Reductions

Idea: If state space is symmetric, explore only a symmetric “quotient” of the state space

Let us define “quotient” first… (also useful in abstractions)

Recall our modelM = W, I, R, L,

W : set of states I W : set of initial states R W X W : set of arcs L : set of atomic propositions

W 2L : mapping from states to colors

Usually we fix the colors and say: M = W, I, R,

Quotient M = W, I, R,

Let be an equivalence relation on W. Assume: s t (s) = (t)

s I iff t I Quotient: M’ = W’, I’, R’, ’

– W’ = W / I’ = I / – R’ ([s] ,[t]) whenever R(s,t) ’([s]) = (s)

Abstract search Suppose we want to check an invariant: Does M satisfy ? Instead check: Does M’ satisfy ?

This is sound but not complete. (Why?)

Stable equivalences Equivalence is called stable if:

R ( x, y) for every s in [x] there exists some t in [y] such that R (s,t)

Claim: Suppose is called stable, then:M satisifies iff M’ satisfy

Sound and complete! (Why?)

Automorphisms

0,0

1,1

0,1

1,0

A permutation function f : W W is an

automorphism if:

1. x f(x) for all x2. R( x, z) R( f(x), f(z))

Automorphisms

f: f(0,0) = 1,1 f(1,1) = 0,0

f(0,1) = 0,1 f(1,0) = 1,0

g: g(0,0) = 0,0 g(1,1) = 1,1 g(0,1) = 1,0 g(1,0) = 0,1

A = { f, g, f g, I}

The set of all automorphisms forms a group!

0,0

1,1

0,1

1,0

AutomorphismsLet x y

if there is some automorphism f such that f(x) = y

The equivalence classes of are called orbits

Claim 1: is an equivalence

Claim 2: is stable

Orbits

[ (0,0), (1,1) ] [ (0,1), (1,0) ]

0,0

1,1

0,1

1,0

Symmetry reduction

[ (0,0),(1,1) ]

[ (0,1), (1,0) ]

Map each state to its representative in the orbit

Symmetry reduction

Step 1: Analyze the system statically and come up with a function that maps each state to its representative

Step 2: When exploring the states, store and explore the representatives!

Symmetry reduction

Difficulty:Computing the function (which maps states to representatives) is hard!

Solutions:• Be satisfied with multiple

representatives for each orbit• Ask user to tell you where the symmetries

are

Symmetry reduction

• Implemented in Mur

• Similar ideas have also impacted Nitpick




Partial Order Methods

Protocols are usually modeled as an asynchronous composition of processes (interleaving model)

Partial order reduction explores only a portion of the state space

You can still prove properties about the entire state space

S0

S1

S2 S3

Actions • An action is a guarded

command• Nondeterminism arises

because any of the enabled actions could be scheduled next!

• Can label state machine transitions with action names

Independent Actions

S0

S1

S2 S3

Actions and are independent if:

1. Neither action enables or disables the other

2. If both and are enabled, then they commute


Key idea:

If actions {} are independent then:

Need to explore only one!But there are some caveats..

Parital Order Equivalence

Two action sequences A and B are partial-order-equivalent if:

A can be transformed to B by swapping adjacent independent actions

Need to explore only one representative in each equivalence class!


Offer good reductions in asynchronous protocols:• Exponential reductions in “artificial”

examples• 5-10 times faster in “real” examples

Implemented in SPIN

Also implemented in Verisoft (we will revisit this later!)

Example

integer x, y; boolean bomb;Init

true x := 0; y := 0; bomb := falseUpdate : ( x < 10) & ! bomb x := x+1

: ( y < 10) & ! bomb y := y+1 : ( x = 3) & ( y = 3) & ! bomb

bomb := true

0,0

1,0

2,0

3,0

4,0

0,1

1,1

2,1

3,1

4,1

0,2

1,2

2,2

3,2

4,2

0,3

1,3

2,3

3,3

4,3

Model Checking

Documents

cycleswhenever process

system model semantics

branching time

msr model

atomic propositions

osq course model checking

discrete system

finite set of predicates