Abstractions

Outline Informal intuition Why do we need abstraction? What is an abstraction and what is not an abstraction A framework for abstractions Commonly used abstractions

Limitations of model checking Finite state technique Cannot deal with general data integers, lists, etc. unbounded message queues Cannot deal with parameterized systems Suffers from state explosion Concurrency Data domains

Abstraction Represent the program using a smaller model. Pay attention to preserving the checked properties. Do not affect the flow of control.

Example Use smaller data objects. X:= f(m) Y:=g(n) if X*Y>0 then … else … X, Y never used again.

How to abstract? Assign values {-1, 0, 1} to X and Y. Based on the following connection: sgn(X) = 1 if X>0, 0 if X=0, and -1 if X<0. sgn(X)*sgn(Y)=sgn(X*Y). Change f and g to produce abstract values for X and Y

Abstraction vs. simplification Not every simplified system is an abstraction The key question is: If we prove or disprove a property of the simplified system, what have we learned about the original system?

Example False positive Can sender overwrite a value? True in the simplified system, false in original False negative Can receiver deadlock? False in the simplified system, true in the original

Precise abstractions Accept neither false positives nor false negatives Minimizations up to an equivalence Elimination of unreachable states Very restrictive!

Precise abstractions int i = 0 while i < 2 do i = i + 1 Replace integer type with enumerated type {0,1,2} Requires a deductive step With “on-the-fly” model construction, this abstraction is free – but may not terminate if you “miss”

Over-approximations Throw in more behaviors Also called conservative approximations Accept false positives but not false negatives If the property proved in the abstract system, it also holds in the concrete system If the property fails in the abstract system, may or may not fail in the concrete system

Abstraction w.r.t. properties A conservative approximation is always with respect to a set of properties If your set of properties is closed under negation, you have precise abstraction Why? Commonly used sets of properties: Reachability, safety ACTL

Abstract LTL verification Concrete correctness condition: L(ConcreteModel)  L(Spec) Over-approximation: L(ConcreteModel)  L(AbstractModel) Abstract correctness condition: L(AbstractModel)  L(Spec) Implies concrete correctness condition!

What is a good abstraction? We want an abstraction that is as compact as possible, but preserves the properties we are interested in An abstraction that is “too loose” is not useful: too many false alarms

Conservative analysis Iterative process of model checking and abstraction refinement Verification is now semi-decidable!

Under-approximations Is under-approximation a useful abstraction technique? Yes, but not as common Testing Abstract the set of executions to the (equivalence class of) tested executions Found a bug – it is real! There is always one more bug…

Abstract interpretation A framework for abstraction P. Cousot and R. Cousot ( ) NOT constructive Offers means of proving an abstraction Does not help finding an abstraction Mathematically captured as Galois connections

Galois connections A and C are partially ordered sets α is the abstraction function γ is the concretization function Always an over-approximation:

Classical example Abstract sets of integers as intervals C : Sets of integers ordered by inclusion A : Intervals with integer boundaries [i 1,i 2 ] (i 1 ≤i 2 ) ordered by “lies within” relation α : Set M  [min(M),max(M)] γ : [i 1,i 2 ]  {i 1,i 1 +1,…,i 2 } {1,4,5} {1,2,3,4,5} [1,5] C A α γ ∩

Fixpoint abstraction In behavioral models, concrete and abstract domains are often sets of states Most analysis algorithms involve fixpoint computation We want to compute abstract fixpoints and make concrete conclusions C and A are complete lattices F is a monotonic function on C Abstract fixpoint is an overapproximation

State-to-state abstraction Partition concrete states into disjoint sets Map sets of states to abstract states α : s  [s] Initial abstract states: an abstract state contains a concrete initial state Abstract transition: s  t implies [s]  [t]

go stop go stop Example Map “yellow” and “red” to “stop” Map “green” to “go” Transitions: go  stop stop  go stop  stop

What do we preserve? go stop go stop Every execution of the full model can be simulated by an execution of the reduced one. Every LTL property that holds in the reduced model hold in the full one.

Properties Preserved: [](go->O stop) Not preserved: []<>go go stop go stop

Predicate abstraction The concrete state space is partitioned according to a set of predicates. Example: Is the right state reachable? Predicates: x<5,x==5

Predicate abstraction Predicates define partitioning of the state space Add transitions according to predicates Property fails!

Predicate abstraction Counterexample is fake! Refine abstraction: add predicates New predicate: x is even Property is true!

Symmetry A permutation is a one-one and onto function p:A->A. For example, 1->3, 2->4, 3->1, 4->5, 5->2. One can combine permutations, e.g., p1: 1->3, 2->1, 3->2 p2: 1->2, 2->1, 3->3 1->3, 2->2, 3->1 A set of permutations is called a symmetry group.

Using symmetry in analysis Want to find some symmetry group such that for each permutation p in it, R(s,t) if and only if R(p(s), p(t)) and L(p(s))=L(s). Let K(s) be all the states that can be permuted to s. This is a set of states such that each one can be permuted to the other.

Turn=0 L0,L1 Turn=0 L0,NC1 Turn=0 NC0,L1 Turn=0 CR0,NC1 Turn=0 NC0,NC1 Turn=0 CR0,L1 Turn=1 L0,CR1 Turn=1 NC0,CR1 Turn=1 L0,NC1 Turn=1 NC0,NC1 Turn=1 NC0,L1 Turn=1 L0,L1 init

Turn=0 L0,L1 Turn=0 L0,NC1 Turn=0 NC0,L1 Turn=0 CR0,NC1 Turn=0 NC0,NC1 Turn=0 CR0,L1 init The quotient model

Partial order reduction With independent transitions, you do not have to explore all transitions to prove a property