Download Presentation
## Model Checking

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -

**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).**Agenda**Part I: Models and Specifications Part II: State explosion**Kripke Structure**States: 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 S0 S1 S2 S3**Kripke Structure**M = 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)**Specification**Three important decisions: • may vs. must: branching vs. linear time • prohibiting bad vs. desiring good behavior: safety vs. liveness • operational vs. declarative: automata vs. logic**S0**S1 S2 S0 Run S1 S2 S3 Trace**S0**Run-tree S1 S0 S2 S3 S1 S2 S3 Trace-tree**Branching Vs Linear**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**S0**t0 S1 S2 t1 S3 S4 t2 t3 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**Specification**Three important decisions: • may vs. must: branching vs. linear time • prohibiting bad vs. desiring good behavior: safety vs. liveness • operational vs. declarative: automata vs. logic**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**Safety Vs Liveness**The vast majority of properties to be verified are safety.**Why liveness?**“Eventually, we are all dead!” The answer is: abstraction and fairness 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?**r1 ~r1 g1 If P1 requests and keeps requesting, it will be granted within 2 cycles F1 F2 ~r2 r1 r2 g2 r2 G1 G2**r1**g1 F r1 r2 g2 r2 G1 G2 r1 ~r1 g1 F1 F2 ~r2 r1 r2 g2 r2 G1 G2 Abstract view 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 q3 Fairness constraint: the green transition cannot be ignored forever**q1**q2 q3 Without fairness: infRuns = q1 (q3 q1)* (q2) (q1 q3) With fairness: infRuns = q1 (q3 q1)* (q2)**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 function SF: set of strongly fair arcs WF: 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**Safety:**• -algorithm: reachability (linear) • Response under weak fairness: • -algorithm: strongly connected components (linear) • 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**U L L Unlocked Locked Error 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) …**Agenda**Part I: Models and Specifications Part II: State explosion**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]**0**1 1 0 1 0 0 1 1 0 0 1 0 1 1 0 Binary Decision Diagrams [Bryant] Ordered decision tree for f = a b c d a 0 1 b b 1 0 1 0 c c c c 1 0 1 0 1 0 1 0 d d d d d d d d**OBDD reduction**a f = a b c d 0 1 b b 1 1 0 0 c c 1 1 0 0 d d 1 1 0 0 0 1**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 fg g O(|f| |g|)**Boolean quantification**• If v is a boolean variable, then $v.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 Mbe a model with boolean variables (v1,v2,…,vn) • Represent any P Í{0,1}n by its characteristic function cP P = {(v1,v2,…,vn) : cP} Example: Variables = (x,y,z) P = { (0,0,1) , (0,1,0), (1,0,0), (1,1,1) } cP = x + y + z**Characterizing sets**• Represent characteristic function as BDD • Set operations can be now done as BDD operations • cÆ= false cS = true • cP È Q= P + Q cP Ç Q = P . Q • cS\ 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)) : Î cR} v0 v1 cR = (v’0 = Øv0) Ù (v’1 = v0Åv1)**Forward Image**Image(P,R) P R