2 -Valued and 3 -Valued Abstraction Refinement Frameworks

2 -Valued and 3 -Valued Abstraction. Refinement Frameworks for Model Checking Orna Grumberg Technion Haifa, Israel Tutorials at ATVA, 2009 1

Outline • 2 -valued Abstraction – Counter. Example-Guided Abstraction-Refinement (CEGAR) • 3 -Valued Abstraction – Three-Valued abstraction-Refinement (TVAR) 2

Why (formal) verification? • safety-critical applications: Bugs are unacceptable! – Air-traffic controllers – Medical equipment – Cars • Bugs found in later stages of design are expensive, e. g. Intel’s Pentium bug in floating-point division • Hardware and software systems grow in size and complexity: Subtle errors are hard to find by testing • Pressure to reduce time-to-market Automated tools formal verification are needed 3

Model Checking An efficient procedure that receives: § A finite-state model describing a system § A temporal logic formula describing a property It returns yes, if the system has the property no + Counterexample, otherwise [EC 81, QS 82] 4

Model Checking § Emerging as an industrial standard tool for verification of hardware designs: Intel, IBM, Cadence, … § Recently applied successfully also for software verification: SLAM (Microsoft), Java Path. Finder and SPIN (NASA), BLAST (EPFL), CBMC (Oxford), … 5

Model of a system Kripke structure / transition system a, b a a b, c b a, c a, b c 6

Temporal Logics • Temporal Logics – Express properties of event orderings in time • Linear Time – – – Every moment has a unique successor Infinite sequences (words) Linear Time Temporal Logic (LTL) • Branching Time – – – Every moment has several successors Infinite tree Computation Tree Logic (CTL) 7

Propositional temporal logic In Negation Normal Form AP – a set of atomic propositions Temporal operators: Gp Fp Xp p. Uq Path quantifiers: A for all path E there exists a path 8

Branching-time Temporal Logics CTL*, -calculus - powerful branching-time logics, containing both CTL and LTL ACTL / ACTL* / A -calculus The universal fragments of the logics, with only universal path quantifiers 9

Main limitation of Model Checking The state explosion problem: Model checking is efficient in time but suffers from high space requirements: The number of states in the system model grows exponentially with § the number of variables § the number of components in the system 10

Solutions to the state explosion problem Small models replace the full, concrete model: • Abstraction • Compositional verification • Partial order reduction • Symmetry 11

Abstraction-Refinement • Abstraction : removes or simplifies details that are irrelevant to the property under consideration, thus reducing the number of states • Refinement might be needed 12

• Manual abstraction requires – great creativity and – close familiarity with the checked system • Goal: – Automatically construct an abstract model – Automatically refine it, if necessary 13

2 -valued Counter. Example -Guided Abstraction Refinement (CEGAR) For ACTL* [CGJLV 00] 14

Abstraction preserving ACTL/ACTL* Existential Abstraction: The abstract model is an over-approximation of the concrete model: – The abstract model has more behaviors – But no concrete behavior is lost • Every ACTL/ACTL* property true in the abstract model is also true in the concrete model 15

Existential Abstraction Given an abstraction function h : S SA, the concrete states are grouped and mapped into abstract states : MA MC M A h h h MC 16

Existential Abstraction (cont. ) Given an abstraction function h : S SA, the concrete states are grouped and mapped into abstract states : p MA h MC p p p p h AP = {p} p h p p p 17

Widely used Abstractions (SA, h) § For Hardware: Localization reduction: each variable either keeps its concrete behavior or is fully abstracted (has free behavior) [Kurshan 94] § For Software: Predicate abstraction: concrete states are grouped together according to the set of predicates they satisfy [GS 97, SS 99] 19

Logic preservation Theorem § Theorem MC MA, therefore for every ACTL* formula , MA |= MC |= § However, the reverse may not be valid. 20

Traffic Light Example Property: =AG AF ¬ (state=red) Abstraction function h maps green, yellow to go. red green red MC |= MA |= go yellow MC MA 21

Traffic Light Example (Cont) If the abstract model invalidates a specification, the actual model may still satisfy the specification. red § Property: =AG AF (state=red) go red § MC |= but MA |= MA § Spurious Counterexample: green yellow MC red, go, . . . 22

The CEGAR Methodology M and generate initial abstraction MA MA |= model check MA |= refinement TA is spurious generate counterexample TA stop TA check spurious counterexample TA is not spurious 23

Generating the Initial Abstraction § If we use predicate abstraction then predicates are extracted from the program’s control flow and the checked property § If we use localization reduction the unabstracted variables are those appearing in the predicates above 24

Counterexamples • For AGp it is a finite path to a state satisfying p • For AFp it is an infinite path represented by a lasso (finite path+loop), where all states satisfy p 25

Path Counterexample Assume that we have four abstract states {1, 2, 3} {4, 5, 6} {7, 8, 9} {10, 11, 12} Abstract counterexample Th= , , , Th is not spurious, therefore, M |= 26

Remark: • and {10, 11, 12} are labeled the same – If satisfies p then 10, 11, 12 also satisfy p Therefore, (1, 4, 9, 12) is a concrete path counterexample 27

Spurious Path Counterexample failure state The concrete states mapped to the failure state are partitioned into 3 sets Th is spurious 28

Refining The Abstraction § Goal : refine h so that the dead-end states and bad states do not belong to the same abstract state. § For this example, two possible solutions. 29

Automatic Refinement If the counterexample is spurious • Find a splitting criterion that separates the bad states from the dead-end states in the failure state • Apply the splitting criterion to splitting either only the failure state or all states – Faster convergence of the CEGAR loop – Faster growing abstract models 30

Checking for Spurious Path Counterexample • T = (a 1, …an) - a path abstract counterexample h-1(a) = { s | h(s) = a } 31

Checking for Spurious Path Counterexample (cont. ) The set of concrete counterexamples corresponding to T = (a 1, …an) : h-1(T) = { (s 1, …sn) | i h(si)=ai I(s 1) i. R(si, si+1) } Is h-1(T) empty? 32

Checking for Spurious Path Counterexample dead-end Th is spurious 33

Refining the abstraction • Refinement separates dead-end states from bad states, thus, eliminates the spurious transition from ai-1 to ai 34

Three-Valued Abstraction Refinement (TVAR) for Full CTL* [SG 03, GLLS 05] Thanks to Sharon Shoham for the slides on TVAR 38

Goal: Logic preservation for CTL* Theorem If MA is an abstraction of MC then for every CTL* formula , MA |= MC |= MA | MC | • But sometimes [MA |= ] =don’t know 39

Abstract Models for CTL* • Two transition relations [LT 88] • Kripke Modal Transition System (KMTS) • M = (S, S 0, Rmust, Rmay, L) – Rmust: an under-approximation – Rmay: an over-approximation – Rmust ⊆ Rmay 40

Abstract Models for CTL* (cont. ) Labeling function : • L: S→ 2 Literals • Literals = AP ⋃ { p | p AP } • At most one of p and p is in L(s). – Concrete: exactly one of p and p is in L(s). – KMTS: possibly none of them is in L(s). 41

Abstract Models for CTL* (cont. ) Labeling of abstract states ¬p MA p MC ¬p ¬p ¬p p 43

Abstract Models for CTL* (cont. ) must: under may: over approximation ( ) must and may transitions: MA MC 44

3 -Valued Semantics • Universal properties (A ) : - Truth is examined along all may-successors - Falsity is shown by a single must-successor • Existential properties (E ) : - Truth is shown by a single must-successor - Falsity is examined along all may-successors 45

3 -Valued Framework tt, ff are definite • Additional truth value: (indefinite) • Abstraction preserves both truth and falsity • (abstract) sa represents (concrete) sc: – is true in sa⇒ is true in sc – is false in sa ⇒ is false in sc – is in sa ⇒ the value of in sc is unknown [BG 99] 46

The TVAR Methodology M and generate initial abstraction MA refinement model check [MA |=3 ] = tt, ff [MA |= 3 ] = find analyze failure node stop 47

3 -Valued Model Checking: Example M: s p, q p, q t = AXp EXq 48

M: MC graph s p, q = AXp EXq (s, AXp EXq) (s, AXp) (s, p) (t, p) p, q t (s, EXq) (s, q) (t, q) 49

tt ff Coloring the MC graph ⊥ 7 5 (s, p) 1 (t, p) 2 3 p, q t 6 (s, EXq) (s, q) s p, q = AXp EXq (s, AXp EXq) (s, AXp) M: (t, q) 4 reason for unknown: may-son - not enough to verify - prevents refutation 50

Abstraction -Refinement • Traditional abstraction-refinement is designed for 2 -valued abstractions: – True holds in the concrete model. – False may be a false alarm. ⇒ Refinement is needed when the result is false and is based on a counterexample analysis. 51

3 -Valued Model Checking Results • tt and ff are definite: hold in the concrete model as well. • ⊥ is indefinite ⇒ Refinement is needed. 52

Refinement • As for the case of 2 -values, done by splitting abstract states MA MC 53

Refinement • Identify a failure state: a state sa for which some subformula is in sa – Done during model checking • Split sa so that – an indefinite atomic proposition becomes definite (true or false), or – A may transition becomes a must transition or disappears 54

Refinement (cont. ) • Uses the colored MC graph • Find a failure node nf: – a node colored whereas none of its sons was colored at the time it got colored. – the point where certainty was lost • purpose: change the color of nf. Refinement is reduced to separating subsets of the concrete states represented by nf. 55

Example tt ff M: s p, q ⊥ 7 p, q t = AXp EXq (s, AXp EXq) failure 5 (s, AXp) (s, p) 1 (t, p) 2 6 (s, EXq) (s, q) 3 (t, q) 4 reason for failure: may-son - not enough to verify - prevents refutation 56

Example (cont. ) (s, EXq) (t, q) concrete states that have a son corresponding to the may-edge are separated from the rest M MC s t 57

Example (cont. ) 7 5 M’: M: s 1 p, q =p, q EXq AXp s 2 (s 1, AXp EXq) (s 1, AXp) p, q tt p, q = AXp EXq 6 (s 1, EXq) (s 2, p) (t, p) (s 2, q) (t, q) 1 2 3 4 58

tt ff Example (cont. ) M’: s 1 p, q ⊥ 7 5 s 2 p, q (s 1, AXp EXq) (s 1, AXp) p, q t = AXp EXq 6 (s 1, EXq) (s 2, p) (t, p) (s 2, q) (t, q) 1 2 3 4 59

Completeness • Our methodology refines the abstraction until a definite result is received. • For finite concrete models iterating the abstraction-refinement process is guaranteed to terminate, given any CTL formula. 60

Incremental Abstraction -Refinement No reason to split states for which MC results are definite during refinement. • After each iteration remember the nodes colored by definite colors. • Prune the refined MC graph in sub-nodes of remembered nodes. [ (sa, ) is a sub-node of (sa’, ’) if = ’ and (sa)⊆ ’(sa’) ] • Color such nodes by their previous colors. 61

Example 62

Example (cont. ) Refined MC-graph 63

Example (cont. ) 64

Example (cont. ) Refined MC-graph … 65

Conclusion We presented two frameworks, CEGAR and TVAR, for abstraction-refinement in model checking: • Properties preserved: – CEGAR: ACTL* – TVAR: Full CTL* • Refinement eliminates – CEGAR: Counterexamples – TVAR: indefinite results ( ) 67

Conclusion (cont. ) The TVAR framework requires • Different abstract models (Rmust, Rmay) – Rmust is harder to compute • Adapted model checking • Gives benefits in preciseness and scalability 68

Thank You 69