1

2-Valued and 3-Valued Abstraction-Refinement Frameworks for Model

Checking

Orna GrumbergTechnion

Haifa, Israel

Tutorials at ATVA, 2009

2

Outline

• 2-valued Abstraction– CounterExample-Guided Abstraction-

Refinement (CEGAR)

• 3-Valued Abstraction– Three-Valued abstraction-Refinement (TVAR)

3

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 for formal verification are needed

4

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 propertyno + Counterexample, otherwise

[EC81,QS82]

5

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 PathFinder and SPIN (NASA), BLAST (EPFL), CBMC (Oxford),…

6

Model of a system Kripke structure / transition system

a,b a

ab,c

c

a,c a,bb

7

Temporal Logics

• 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)

• Temporal Logics– Express properties of event orderings in time

8

Propositional temporal logic

In Negation Normal FormAP – a set of atomic propositions

Temporal operators:GpFpXppUq

Path quantifiers: A for all path E there exists a path

9

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

10

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

11

Solutions to the state explosion problem

Small models replace the full, concrete model:

• Abstraction• Compositional verification• Partial order reduction• Symmetry

12

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

13

• Manual abstraction requires – great creativity and – close familiarity with the checked system

• Goal: – Automatically construct an abstract model– Automatically refine it, if necessary

14

2-valued CounterExample-Guided Abstraction Refinement (CEGAR)

For ACTL*

[CGJLV00]

15

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

16

Existential Abstraction

MC

MA

Given an abstraction function h : S SA, the concrete states are grouped and mapped into abstract states :

h h h

MC MA

17

MC

MA

h h h

Existential Abstraction (cont.)

pp p p

pp AP =

{p}

pp pp

Given an abstraction function h : S SA, the concrete states are grouped and mapped into abstract states :

p

19

Widely used Abstractions (SA, h)

For Hardware:Localization reduction: each variable either keeps its concrete behavior or is fully abstracted (has free behavior) [Kurshan94]

For Software:Predicate abstraction: concrete states are grouped together according to the set of predicates they satisfy [GS97,SS99]

20

Logic preservation Theorem

Theorem MC MA, therefore for every ACTL* formula ,

MA |= MC |=

However, the reverse may not be valid.

21

Traffic Light Example

red

green

yellow

MC

Property: =AG AF ¬ (state=red)

Abstraction function h maps green, yellow to go.

red

go

MA

MA |= MC |=

22

Traffic Light Example (Cont)

If the abstract model invalidates a specification, the actual model may still satisfy the specification.

Property: =AG AF (state=red)

MC |= but MA |=

red

green

yellow

red

go

MCMA

Spurious Counterexample:

red,go,go, ...

23

The CEGAR Methodology

TA is not spuriouscheck spurious

counterexample

TA

stop

MA |=

generatecounterexample TA

MA |=

model check

MA

generate initialabstraction

M and

refinement

TAis spurious

24

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 then the unabstracted variables are those appearing in the predicates above

25

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

26

Path Counterexample

Assume that we have four abstract states {1,2,3} {4,5,6} {7,8,9} {10,11,12}

Abstract counterexample Th= , , ,

therefore, M |= Th is not spurious,

27

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

28

Spurious Path Counterexample

Th is spurious

failure state The concrete states mapped to the failure state are partitioned into 3 sets

dead-end bad irrelevantyes no nono yes no

statesreachableout edges

29

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.

30

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

31

Checking for Spurious Path Counterexample

• T = (a1,…an) - a path abstract counterexample

h-1(a) = { s | h(s) = a }

32

Checking for Spurious Path Counterexample (cont.)

The set of concrete counterexamples corresponding to T = (a1,…an) :

h-1(T) = { (s1,…sn) | i h(si)=ai I(s1)

iR(si,si+1) }

Is h-1(T) empty?

33

Checking for Spurious Path Counterexample

Th is spurious

dead-end

34

Refining the abstraction

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

38

Three-Valued Abstraction Refinement (TVAR)

for Full CTL*

[SG03,GLLS05] Thanks to Sharon Shoham for the slides on TVAR

39

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

40

Abstract Models for CTL*

• Two transition relations [LT88]

• Kripke Modal Transition System (KMTS)

• M = (S, S0, Rmust, Rmay, L)

– Rmust: an under-approximation– Rmay: an over-approximation– Rmust ⊆ Rmay

41

Abstract Models for CTL* (cont.)

Labeling function :

• L: S→ 2Literals

• Literals = AP ⋃ {p | pAP }

• 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).

43

MC

MA

Labeling of abstract states

Abstract Models for CTL* (cont.)

p

p

p

pp¬p

¬p¬p

¬p

¬p

44

MC

MA

must and may transitions:

Abstract Models for CTL* (cont.)

must: under approximation

()

may: over approximation

()

45

3-Valued Semantics

• Universal properties (A) : - Truth is examined along all may-successors- Falsity is shown by a single must-successor

• Existential properties (EE) :- Truth is shown by a single must-successor- Falsity is examined along all may-successors

46

3-Valued Framework

• 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

[BG99]

tt, ff are definite

47

The TVAR Methodology

stop

[MA |=3 ] = tt,ff

find and analyze failure node

[MA |= 3 ] =

model check

MA

generate initialabstraction

M and

refinement

48

3-Valued Model Checking:Example

= AXp EXq

M:

p, qs tp, q

49

MC graph

(s, AXpEXq)

(s, AXp)

(s, p) (t, q)

(s, EXq)

(s, q)(t, p)

= AXp EXq

M:

p, qs tp, q

50

Coloring the MC graph

(s, AXpEXq)

(s, AXp)

(s, p) (t, q)

(s, EXq)

(s, q)(t, p)

1 2 3 4

5 6

7 = AXp EXq

M:

p, qs tp, q

reason for unknown:may-son- not enough to verify - prevents refutation

fftt

⊥

51

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.

52

3-Valued Model Checking Results

• tt and ff are definite: hold in the concrete model as well.

•⊥ is indefinite

⇒ Refinement is needed.

53

MC

MA

• As for the case of 2-values, done by splitting abstract states

Refinement

54

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

55

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.

56

Example

(s, AXpEXq)

(s, AXp)

(s, p) (t, q)

failure(s, EXq)

(s, q)(t, p)

1 2 3 4

5 6

7 = AXp EXq

M:

p, qs tp, q

reason for failure:may-son- not enough to verify - prevents refutation

fftt

⊥

57

M s t

MC

concrete states that have a son corresponding to the may-edge are separated from the rest

(t, q)

(s, EXq)Example (cont.)

58

Example (cont.)

= AXp EXq

M:

p, qs tp, q

= AXp EXq

M’:

p, qs1tp, q

p, qs2(s1, AXpEXq)

(s1, AXp)

(s2, p) (t, q)

(s1, EXq)

(s2, q)(t, p)

1 2 3 4

5 6

7

59

(s1, AXpEXq)

(s1, AXp)

(s2, p) (t, q)

(s1, EXq)

(s2, q)(t, p)

1 2 3 4

5 6

7

fftt

⊥

= AXp EXq

M’:

p, qs1tp, q

p, qs2

Example (cont.)

60

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.

61

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.

62

Example

63

Example (cont.)

Refined MC-graph

64

Example (cont.)

65

Example (cont.)

Refined MC-graph

…

67

Conclusion

We presented two frameworks, CEGAR andTVAR, for abstraction-refinement in modelchecking:• Properties preserved:

– CEGAR: ACTL*– TVAR: Full CTL*

• Refinement eliminates – CEGAR: Counterexamples– TVAR: indefinite results ()

68

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

69

Thank You