# Infinite State Model Checking with Presburger Arithmetic Constraints - PowerPoint PPT Presentation

PPT – Infinite State Model Checking with Presburger Arithmetic Constraints PowerPoint presentation | free to download - id: 6d0846-YzY0M The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
Title:

## Infinite State Model Checking with Presburger Arithmetic Constraints

Description:

### Infinite State Model Checking with Presburger Arithmetic Constraints Tevfik Bultan Department of Computer Science University of California, Santa Barbara – PowerPoint PPT presentation

Number of Views:5
Avg rating:3.0/5.0
Slides: 102
Provided by: Valued236
Category:
Tags:
Transcript and Presenter's Notes

Title: Infinite State Model Checking with Presburger Arithmetic Constraints

1
Infinite State Model Checking with Presburger
Arithmetic Constraints
• Tevfik Bultan
• Department of Computer Science
• University of California, Santa Barbara

2
Joint Work with My Students
• Action Language Verifier
• Tuba Yavuz-Kahveci (PhD 2004)
• Constantinos Bartzis (PhD 2004)
• Design for verification
• Aysu Betin-Can (PhD 2005)

3
Infinite State Model Checking?
• Model checking started as a finite state
verification technique
• Advantages of finite state systems
• Exhaustive state enumeration is possible for
finite state systems
• Disadvantages of infinite state systems
• Verification problems that are computable for
finite state systems are uncomputable for
infinite state systems

4
• Computer systems do not have infinite memory or
infinite time
• So why care about infinity?
• Infinity is an abstraction
• Abstraction is at the core of computer science
• Computers are built with layers of abstractions
• Abstraction is necessary for design
• Abstraction is necessary for analysis

5
• Reason 1
• Enables us to check a specification with respect
to an arbitrarily large number of components or
memory
• For example, arbitrary number of threads
• Reason 2
• Rather than developing verification techniques
that rely on the bound of the state space to
terminate
• Enables us to develop infinite state verification
techniques that terminate independent of the
bound
• A technique which is guaranteed to terminate is
not helpful if it runs out of memory

6
An Example
• A simple example that demonstrates limitations of
(finite state) model checkers
• Property P can be verified with an infinite state
model checker that uses standard backward
fixpoint computations
• Fixpoint computation for some properties
• for example, AG(State1 ? x ?6)
• may not converge but we can use conservative
approximations

xx1
State0
State1
xx1
Initial x0 ? State0
P AG(State1 ? x is odd)
P AG(State1 ? (?? . x 2?1))
7
Outline
• Model checking with arithmetic constraints
• Conservative approximations
• Automata representation for arithmetic
constraints
• Composite representation
• Action Language Verifier (ALV)
• Checking synchronization in concurrent programs
with ALV

8
Symbolic Model Checking McMillan et al. LICS
1990
• Represent sets of states and the transition
relation as Boolean logic formulas
• Forward and backward fixpoints can be computed by
iteratively manipulating these formulas
• Forward, backward image Existential variable
elimination
• Conjunction (intersection), disjunction (union)
and negation (set difference), and equivalence
check
• Use an efficient data structure for manipulation
of Boolean logic formulas
• BDDs

9
Symbolic Model Checking
• What do you need to compute fixpoints?
• Symbolic Conjunction(Symbolic,Symbolic)
• Symbolic Disjunction(Symbolic,Symbolic)
• Symbolic Negation(Symbolic)
• Boolean EquivalenceCheck(Symbolic,Symbolic)
• Symbolic Precondition(Symbolic)
• Precondition (i.e., EX) computation is handled
by
• variable renaming, followed by conjunction,
followed by existential variable elimination
• Infinite state model checking Use a symbolic
representation that is capable of representing
infinite sets and supports the above functionality

10
Linear Arithmetic Constraints
• Linear arithmetic formulas can represent
(infinite) sets of valuations of unbounded
integers
• Linear integer arithmetic formulas on can be
stored as a set of polyhedra
• where each is a linear equality or
inequality constraint
• and each is a polyhedron
• xi integer variable, ai coefficient, c constant

11
A Linear Arithmetic Constraint Manipulator
• Omega Library Pugh et al.
• A tool for manipulating Presburger arithmetic
formulas First order theory of integers without
multiplication
• Equality and inequality constraints are not
enough
• Divisibility constraints are also needed
• which means is divisible by

12
Integers are Complicated
y
x 5 ? 2y
2y ? x 1
x ? 3y
3y ? x 7
29
3
x
13
Presburger Arithmetic Model Checking Bultan et
al. CAV97, TOPLAS99
• Use linear arithmetic constraints as a symbolic
representation
• Use a Presburger arithmetic manipulator as the
symbolic engine (Omega library)
• Compute fixpoints to verify or falsify CTL
properties
• Use conservative approximations to achieve
convergence

14
What About Using BDDs for Encoding Arithmetic
Constraints?
• Arithmetic constraints on bounded integer
variables can be represented using BDDs
• Use a binary encoding
• represent integer x as x0x1x2... xk
• where x0, x1, x2, ... , xk are binary variables
• You have to be careful about the variable
ordering!
• BDDs and constraint representations are both
applicable
• Which one is better?

15
Arithmetic Constraints vs. BDDs Bultan TACAS00
16
Arithmetic Constraints vs. BDDs
17
Arithmetic Constraints vs. BDDs
• Constraint based verification can be more
efficient than BDDs for integers with large
domains
• Constraint based verification can be used to
automatically verify infinite state systems
• cannot be done using BDDs
• However, BDD-based verification is more robust
and the arithmetic constraint representation has
two problems
• Problem 1 Constraint based verification does not
scale well when there are boolean or enumerated
variables in the specification
• Problem 2 Price of infinity
• CTL model checking becomes undecidable for
infinite domains

18
Outline
• Model checking with arithmetic constraints
• Conservative approximations
• Automata representation for arithmetic
constraints
• Composite representation
• Action Language Verifier (ALV)
• Checking synchronization in concurrent programs
with ALV

19
Conservative Approximations
• Compute a lower ( p? ) or an upper ( p )
approximation to the truth set of the property (
p )

20
Conservative Approximations
• Compute a lower ( p? ) or an upper ( p )
approximation to the truth set of the property (
p )
• There are three possible outcomes

p
p?
I
1) The property is satisfied
21
Conservative Approximations
• Compute a lower ( p? ) or an upper ( p )
approximation to the truth set of the property (
p )
• There are three possible outcomes

I
p
p?
p
I
p?
1) The property is satisfied
3) I dont know
sates which violate the property
I
p
? p?
p
2) The property is false and here is a
counter-example
22
Conservative Approximations
• Compute a lower ( p? ) or an upper ( p )
approximation to the truth set of the property (
p )
• There are three possible outcomes

I
p
p?
p
I
p?
1) The property is satisfied
3) I dont know
sates which violate the property
I
p
? p?
p
2) The property is false and here is a
counter-example
23
Conservative Approximations
• Truncated fixpoint computations
• To compute a lower bound for a least-fixpoint
computation
• Stop after a fixed number of iterations
• Widening
• To compute an upper bound for the least-fixpoint
computation
• We use a generalization of the polyhedra widening
operator by Cousot and Halbwachs POPL78

24
Polyhedra Widening
y
x ? y
y ? 5
1 ? y
x
x ? 4
Ai x ? y ? x ? 4 ? y ? 5 ? 1 ? y
25
Polyhedra Widening
x ? y
y
x ? y
y ? 5
y ? 5
1 ? y
1 ? y
x
x ? 5
x ? 4
Ai x ? y ? x ? 4 ? y ? 5 ? 1 ? y Ai1 x ? y ?
x ? 5 ? y ? 5 ? 1 ? y
26
Polyhedra Widening
y
x ? y
y ? 5
1 ? y
x
x ? 5
x ? 4
Ai x ? y ? x ? 4 ? y ? 5 ? 1 ? y Ai1 x ? y ?
x ? 5 ? y ? 5 ? 1 ? y Ai?Ai1 x ? y ? y ? 5 ?
1 ? y
27
Polyhedra Widening
x ? y
y
x ? y
y ? 5
y ? 5
1 ? y
1 ? y
x
x ? 5
x ? 4
Ai x ? y ? x ? 4 ? y ? 5 ? 1 ? y Ai1 x ? y ?
x ? 5 ? y ? 5 ? 1 ? y Ai?Ai1 x ? y ? y ? 5 ?
1 ? y
Ai ? Ai1 is defined as all the constraints in
Ai that are also satisfied by Ai1
28
Outline
• Model checking with arithmetic constraints
• Conservative approximations
• Automata representation for arithmetic
constraints
• Composite representation
• Action Language Verifier (ALV)
• Checking synchronization in concurrent programs
with ALV

29
Automata Representation for Arithmetic
Constraints Bartzis, Bultan CIAA02, IJFCS 02
• Given an atomic linear arithmetic constraint in
one of the following two forms
• we can construct an FA which accepts all the
solutions to the given constraint
• By combining such automata one can handle full
Presburger arithmetic

30
Basic Construction
• We first construct a basic state machine which
• Reads one bit of each variable at each step,
starting from the least significant bits
• and executes bitwise binary addition and stores
the carry in each step in its state

In my figures alphabet symbols are written
vertically!
0 1 0 0 / / 0 1
0 1 / 1
0 1 1 1 / / 0 1
1 0 / 0
Example x 2y
1 1 / 1
0 1 / 0
1 1 / 0
010 2 ? 001
0 1 0 0 / / 0 1
0 0 / 1
1
0
0
Number of states
31
Automaton Construction
• Equality With 0
• All transitions writing 1 go to a sink state
• State labeled 0 is the only accepting state
• For disequations (?), state labeled 0 is the only
rejecting state
• Inequality (lt0)
• States with negative carries are accepting
• No sink state
• Non-zero Constant Term c
• Same as before, but now -c is the initial state
• If there is no such state, create one (and
possibly some intermediate states which can
increase the size by c)

32
Conjunction and Disjunction
• Conjunction and disjunction is handled by
generating the product automaton

33
Other Extensions
• Existential quantification (necessary for pre and
post)
• Project the quantified variables away
• The resulting FA is non-deterministic
• Determinization may result in exponential blowup
of the FA size but we do not observe this in
practice
• For universal quantification use negation
• Constraints on all integers
• Use 2s complement arithmetic
• The basic construction is the same
• In the worst case the size doubles

34
Experiments
• We implemented these algorithms using MONA
Klarlund et al
• We integrated them to our infinite state model
checker
• We compared our automata representation against
• the polyhedral representation used in the Omega
library
• the automata representation used in LASH
Boigelot and Wolper
• we also integrated LASH to our model checker by
writing a wrapper around it

35
Experimental results
36
Experimental results
37
Experimental results
38
Efficient Pre- and Post-condition Computations
Bartzis, Bultan CAV03
• Pre and post condition computations can cause an
exponential blow-up in the size of the automaton
in the worst case
• We do not observe this blow-up in the experiments
• We proved that for a common class of systems this
blow up does not occur

39
• We assume that the transition relation of the
input system is a disjunction of formulas in the
following form
• guard(R) ? update(R)
• where
• guard(R) is a Presburger formula on current state
variables and
• update(R) is of the form
• xif(x1, , xv) ? ? xj xj
• In asynchronous concurrent systems the transition
relation is usually in the above form

j?i
40
• xi c
• xi xi c
• xi ?j1aj xj c
• We proved that
• Computation of pre is polynomial for all 3 cases
• Computation of post is polynomial for 2 and for
3, whenever ai is odd.

v
41
Other Results Related to Automata
Encoding Bartzis, Bultan TACAS03, STTT
• We developed efficient BDD construction
algorithms and proved bounds for the sizes of the
BDDs for bounded linear arithmetic constraints
• Given a linear arithmetic formula that contains n
atomic constraints on v bounded integer variables
represented with b-bits, the size of the BDD is
• These results explain why all three versions of
SMV (NuSMV, CMU SMV and Cadence SMV) are
inefficient in handling linear arithmetic
constraints
• In SMV the BDD size could be exponential in b

42
Other Results Related to Automata
Encoding CAV04
• We defined a widening operator for the automata
representation of arithmetic constraints
• The widening operator looks for similar states in
two consecutive iterations (Ai and Ai1) and
creates an equivalence relation
• then it merges the states in the same equivalence
class
• We can prove that for some cases this widening
operator computes the exact fixpoint
• for example for updates of the form xxc

43
Example
module incr_1 integer y parameterized
integer x initial yx incr_1 y'y1
spec AG(ygtx) endmodule
• The sequence yx, yx ? yx1, yx ? yx1 ?
yx2, does not converge
• However we know that a fixpoint exists (y?x) and
is representable as an arithmetic constraint

44
Widening
• Instead of computing a sequence A1, A2, where
• Ai1Ai?post(Ai)
• compute A1, A2, where
• Ai1Ai?(Ai?post(Ai))
• By definition A?B ? A?B
• The goal is to find a widening operator ? such
that
• The sequence A1, A2, converges
• It converges fast
• The computed fixpoint is as close as possible to
the exact set of reachable states

45
Widening Arithmetic Automata
• Given automata A and A we want to compute A?A
• We say that states k and k are equivalent (k?k)
if either
• k and k can be reached from either initial state
with the same string (unless k or k is a sink
state)
• or, the languages accepted from k and k are
equal
• or, for some state k, k?k and k?k
• The states of A?A are the equivalence classes of
?

46
Example
0 1 0,1
X X
yx
1 0 0,1

0
0
1
0
1
1
3
0 1 0,1
yx ? yx1
0
1 0 0,1
0 X 0,1
1
1
X X
0
3
0 1
2
1 0
2
0 1 0,1
3
1 0
47
Example
0 1 0,1
0 1 0,1
X X
1 0 0,1
0 X 0,1
1
X X
1 0 0,1
0
1
0
3
0 1
1 0
2
0 1 0,1
1 0
0 X 0,1
1 0
X X

1 0
0 1 0,1
0,1
2
3
0 1
48
Example
0 0,
1 0
X X
X 1
1 0
0 1 0,1

2
0
0
0
1
2
0 1
1
1
3
2
4
0 X 0,1
0
1 0
X X
X 1
1 0
0 0
2
1
0 1 0,1
0
3
4
0 1
0 1
2
3
1 0
1 0
1
4
X 0
49
Example
0 X 0,1
1 0
X X
0 0,
1 0
X X
X 1
X 1
1 0
0 0
2
0 1 0,1
1 0
0 1 0,1
0
1
2
0
3
4
0 1
0 1
0 1
1 0
1 0
1
X 0
0 X 0,1
X 1 0,0
1 0

Represents y?x
0,2
1,3
0 1
50
Outline
• Model checking with arithmetic constraints
• Conservative approximations
• Automata representation for arithmetic
constraints
• Composite representation
• Action Language Verifier (ALV)
• Checking synchronization in concurrent programs
with ALV

51
Composite Model Checking Bultan, Gerber, League
ISSTA 98, TOSEM 00
• Map each variable type to a symbolic
representation
• Map boolean and enumerated types to BDD
representation
• Map integer type to a linear arithmetic
constraint representation
• Use a disjunctive representation to combine
different symbolic representations composite
representation
• Each disjunct is a conjunction of formulas
represented by different symbolic representations
• we call each disjunct a composite atom

52
Composite Representation
composite atom
symbolic rep. 1
symbolic rep. 2
symbolic rep. t
Example x integer, y boolean xgt0 and x?x-1
and y or xlt0 and x?x and y?y
arithmetic constraint representation
arithmetic constraint representation
BDD
BDD
53
Composite Symbolic Library Yavuz-Kahveci,
Tuncer, Bultan TACAS01, Yavuz-Kahveci, Bultan
FroCos 02, STTT 03
• Uses a common interface for each symbolic
representation
• Easy to extend with new symbolic representations
• Enables polymorphic verification
• Multiple symbolic representations
• As a BDD library we use Colorado University
Decision Diagram Package (CUDD) Somenzi et al
• As an integer constraint manipulator we use Omega
Library Pugh et al

54
Composite Symbolic Library Class Diagram
Symbolic
• intersect()
• union()
• complement()
• isSatisfiable()
• isSubset()
• pre()
• post()

CUDD Library
OMEGA Library
55
Pre and Post-condition Computation
• Variables
• x integer, y boolean
• Transition relation
• R xgt0 and x?x-1 and y or xlt0 and x?x and
y?y
• Set of states
• s x2 and !y or x0 and !y
• Compute post(s,R)

56
Pre and Post-condition Distribute
• R xgt0 and x?x-1 and y or xlt0 and x?x and
y?y
• s x2 and !y or x0 and y
• post(s,R) post(x2 , xgt0 and x?x-1) ? post(!y
, y)
• x1 y
• post(x2 , xlt0 and x?x) ? post (!y , y?y)
• false
!y
• post(x0 , xgt0 and x?x-1) ? post(y , y)
• false
y
• post (x0 , xlt0 and x?x) ? post (y, y?y )
• x0
y
• x1 and y or x0 and y

57
Polymorphic Verifier
• Symbolic TranSyscheck(Node f)
• Symbolic s check(f.left)
• case EX
• s.pre(transRelation)
• case EF
• do
• sold s
• s.pre(transRelation)
• s.union(sold)
• while not sold.isEqual(s)

? Action Language Verifier is polymorphic ? It
becomes a BDD based model checker when there or
no integer variables
58
Composite Representation Shape
Graphs Yavuz-Kahveci, Bultan SAS 02
• Shape graphs represent the states of the heap
• Each node in the shape graph represents a
dynamically allocated memory location
• Heap variables point to nodes of the shape graph
• The edges between the nodes show the locations
pointed by the fields of the nodes

heap variables add and top point to node
n1 add.next is node n2 top.next is also node
top
next
n1
n2
next
59
Composite Symbolic Library Further Extended
Symbolic
• union()
• isSatisfiable()
• isSubset()
• forwardImage()

BoolSym
HeapSym
IntSym
representation BDD
representation list of ShapeGraph
representation list of Polyhedra
• union()
• union()
• union()

CUDD Library
OMEGA Library
60
Forward Fixpoint
arithmetic constraint representation
A set of shape graphs
BDD
top
?
?
pcl1 ? mutex
numItems2
61
Post-condition Computation Example
top
?
?
set of states
pcl4 ? ?mutex
numItems2
?
transition relation
pcl4 and mutex pcl1
?
numItemsnumItems1
?
pcl1 ? mutex
numItems3
62
Again Fixpoints Do Not Converge
• We have two reasons for non-termination
• integer variables can increase without a bound
• the number of nodes in the shape graphs can
increase without a bound
• As I mentioned earlier, we use widening on
integer variables to achieve convergence
• For heap variables we use the summarization
operation

63
Summarization Example
top
?
?
pcl1 ? mutex
numItems3
summarized nodes
After summarization, it becomes
top
?
?
pcl1 ? mutex
numItems3 ? summarycount2
a new integer variable representing the number of
concrete nodes encoded by the summary node
summary node
64
Simplification
top
numItems3 ? summaryCount2
?
?
pcl1 ? mutex
?
top
?
numItems4 ? summaryCount3
?

pcl1 ? mutex

top
?
• (numItems4
• summaryCount3
• numItems3
• ? summarycount2)

?

pcl1 ? mutex
65
Simplification On the Integer Part
• (numItems4
• summaryCount3
• numItems3
• ? summaryCount2)

top
?
?

pcl1 ? mutex

top
?
?
• numItemssummaryCount1
• 3 ? numItems
• numItems ? 4

pcl1 ? mutex

66
Then We Use Integer Widening
top
?
?
• numItemssummaryCount1
• 3 ? numItems
• numItems ? 4

pcl1 ? mutex
?
?
?
top
• numItemssummaryCount1
• 3 ? numItems
• numItems ? 5

pcl1 ? mutex

top
?
?
• numItemssummaryCount1
• 3 ? numItems

pcl1 ? mutex

Now, fixpoint converges
67
Verified Properties
Specification Verified Invariants
Stack topnull ? numItems0
top?null ? numItems?0
numItems2 ? top.next?null
Single Lock Queue headnull ? numItems0
Two Lock Queue numItemsgt1 ? head?tail
68
Verifying Linked Lists with Multiple Fields
• Pattern-based summarization
• User provides a graph grammar rule to describe
the summarization pattern
• L x next x y, prev y x, L y
• Represent any maximal sub-graph that matches the
pattern with a summary node
• no node in the sub-graph pointed by a heap
variable

69
Summarization Pattern Examples
...
n
n
n
L x ? x.n y, L y
...
n
n
n
L x ? x.n y, y.p x, L y
p
p
p
...
n
n
n
L x ? x.n y, x.d z, L y
d
d
d
70
Outline
• Model checking with arithmetic constraints
• Conservative approximations
• Automata representation for arithmetic
constraints
• Composite representation
• Action Language Verifier (ALV)
• Checking synchronization in concurrent programs
with ALV

71
Action Language Tool Set
Action Language Specification
Action Language Parser
Composite Symbolic Library
Omega Library
CUDD Package
MONA
Verified
Counter example
Presburger Arithmetic Manipulator
BDD Manipulator
Automata Manipulator
72
Action Language Bultan, ICSE 00, Bultan,
Yavuz-Kahveci, ASE 01
• Variables boolean, enumerated, integer
(unbounded)
• Parameterized constants
• specifications are verified for all possible
values
• Transition relation is defined using actions and
modules
• Atomic actions Predicates on current and next
state variables
• Action composition
• asynchronous () or synchronous ()
• A module is defined as asynchronous and/or
synchronous compositions of its actions and
submodules

73
Readers Writers Example A Closer Look
S Cartesian product of variable domains
defines the set of states
• module main()
• integer nr
• boolean busy
• restrict nrgt0
• initial nr0 and !busy
• rEnter !reading and !busy and
• endmodule
• module Writer()
• ...
• endmodule

I Predicates defining the initial states
R Atomic actions of the Reader
R Transition relation of Reader defined as
asynchronous composition of its atomic actions
R Transition relation of main defined as
asynchronous composition of two Reader and two
Writer processes
74
• Counting abstraction
• Create an integer variable for each local state
• Each variable will count the number of threads in
a particular state
• Local states of the threads have to be finite
• Specify only the thread behavior that relates to
the correctness of the controller
• Shared variables of the controller can be
unbounded
• Counting abstraction can be automated

75
Parameterized constants introduced by the
counting abstractions
• module main()
• integer nr
• boolean busy
• restrict nrgt0 and numReadergt0 and
numWritergt0
• initial nr0 and !busy
• rEnter readingFgt0 and !busy and
• endmodule
• module Writer()
• ...
• endmodule

Variables introduced by the counting abstractions
76
Integers Booleans Cons. Time (secs.) Ver. Time (secs.) Memory (Mbytes)
RW-4 1 5 0.04 0.01 6.6
RW-8 1 9 0.08 0.01 7
RW-16 1 17 0.19 0.02 8
RW-32 1 33 0.53 0.03 10.8
RW-64 1 65 1.71 0.06 20.6
RW-P 7 1 0.05 0.01 9.1
77
Outline
• Model checking with arithmetic constraints
• Conservative approximations
• Automata representation for arithmetic
constraints
• Composite representation
• Action Language Verifier (ALV)
• Checking synchronization in concurrent programs
with ALV

78
Design for Verification
Action Language Verifier
Design for Verification
enables
uses
Verification of Synchronization in
Concurrent Programs
79
How do we translate this to Action Language?
• class ReadWriteLock    private Object lockObj
new Object()     writeLockIssued  false
sWaitingForWriteLock ! 0))          try
lockObj.wait()          catch (InterruptedEx
sGiven           public void getWriteLock()
! 0)  (writeLockIssued))          try
lockObj.wait()          catch (InterruptedE
xception e)            //
ed  true           public void done()      sy
nchronized (lockObj)        //check for errors
Issued))          System.out.println(" Error Inv
alid call to release the lock")         return
if (writeLockIssued)         writeLoc
Given--       lockObj.notifyAll()

Action Language Verifier
Verification of Synchronization in Java Programs
80
Design for Verification
• Abstraction and modularity are key both for
successful designs and scalable verification
techniques
• The question is
• How can modularity and abstraction at the design
level be better integrated with the verification
techniques which depend on these principles?
• Our approach
• Structure software in ways that facilitate
verification
• Document the design decisions that can be useful
for verification
• Improve the applicability and scalability of
verification using this information

81
A Design for Verification Approach
• We have been investigating a design for
verification approach based on the following
principles
• Use of design patterns that facilitate automated
verification
• Use of stateful, behavioral interfaces which
isolate the behavior and enable modular
verification
• An assume-guarantee style modular verification
strategy that separates verification of the
behavior from the verification of the conformance
to the interface specifications
• A general model checking technique for interface
verification
• Domain specific and specialized verification
techniques for behavior verification
• Avoids usage of error-prone Java synchronization
primitives
• synchronize, wait, notify
• Separates controller behavior from the threads
that use the controller
• Supports a modular verification approach
which exploits this modularity
• for scalable verification

82
This helper class is provided. No need to rewrite
it!
• class Action
• protected final Object owner
• private boolean GuardedExecute()
• boolean resultfalse
• for(int i0 iltgcV.size() i) try
• if(((GuardedCommand)gcV.get(i)).guard())
• ((GuardedCommand)gcV.get(i)).update()
• resulttrue break
• catch(Exception e)
• return result
• public void blocking()
• synchronized(owner)
• while(!GuardedExecute())
• tryowner.wait()
• catch (Exception e)
• owner.notifyAll()
• public boolean nonblocking()
• class RWController implements RWInterface
• int nR boolean busy
• final Action act_r_enter, act_r_exit
• final Action act_w_enter, act_w_exit
• RWController()
• ...
• gcs new Vector()
• public boolean guard()
• return (nR 0 !busy)
• public void update()busy true
• )
• act_w_enter new Action(this,gcs)
• public void w_enter()
• act_w_enter.blocking()
• public boolean w_exit()
• return act_w_exit.nonblocking()
• public void r_enter()

83
Controller Interfaces
• A controller interface defines the acceptable
call sequences for the threads that use the
controller
• Interfaces are specified using finite state
machines
• public class RWStateMachine implements
RWInterface
• StateTable stateTable
• final static int idle0,reading1, writing2
• public RWStateMachine() ...
stateTable.insert("w_enter",idle,writing)
• public void w_enter()
• stateTable.transition("w_enter")
• ...

r_enter
r_exit
idle
w_exit
writing
w_enter
84
Verification Framework
Behavior Verification
Action Language Verifier
Controller Behavior Machine
Controller Classes
Counting Abstraction
Concurrent Program
Controller Interface Machine
Interface Verification
Java Path Finder
85
Modular Design / Modular Verification
Concurrent Program
Interface Machine
Interface Machine
Interface Machine
Interface
Controller
Modular Behavior Verification
Shared Data
Controller Behavior
86
Behavior Verification
• Analyzing properties (specified in CTL) of the
synchronization policy encapsulated with a
concurrency controller and its interface
• Verify the controller properties assuming that
interface
• Behavior verification with Action Language
Verifier
• We wrote a translator which translates controller
classes to Action Language
• Using counting abstraction we can check
concurrency controller classes for arbitrary

87
Interface Verification
• A thread is correct with respect to an interface
if all the call sequences generated by the thread
can also be generated by the interface machine
• Checks if all the threads invoke controller
methods in the order specified in the interfaces
• Checks if the threads access shared data only at
the correct interface states
• Interface verification with Java PathFinder
• Verify Java implementations of threads
• Correctness criteria are specified as assertions
• Look for assertion violations
• Assertions are in the StateMachine and SharedStub
• Performance improvement with thread Isolation

88
• Threads can interact with each other in only two
ways
• invoking controller actions
• invoking shared data methods
• Replace concurrency controllers with controller
interface state machines
• Replace shared data with shared stubs

89
• Interaction among a thread and its environment
• Modeling threads call to its environment with
stubs
• File I/O, updating GUI components, socket
operations, RMI call to another program
• Replace with pre-written or generated stubs
• Modeling the environments influence on threads
with drivers
• Thread initialization, RMI events, GUI events
• Enclose with drivers that generate all possible
events that influence controller access

90
Automated Airspace Concept
• Automated Airspace Concept by NASA researchers
automates the decision making in air traffic
control
• The most important challenge is achieving high
dependability
• Automated Airspace Concept includes a failsafe
short term conflict detection component called
Tactical Separation Assisted Flight Environment
(TSAFE)
• It is responsible for detecting conflicts in
flight plans of the aircraft within 1 minute from
the current time
• Dependability of this component is even more
important than the dependability of the rest of
the system
• It should be a smaller, isolated component
compared to the rest of the system so that it can
be verified

91
TSAFE
• TSAFE functionality
• Display aircraft position
• Display aircraft planned route
• Display aircraft future projected route
trajectory
• Show conformance problems

92
TSAFE Architecture
ltltTCP/IPgtgt
User
Server
Client
ltltRMIgtgt
21,057 lines of code with 87 classes
93
Behavior Verification Performance
Controller Time(sec) Memory (MB) P-Time (sec) P-Memory (MB)
RW 0.17 1.03
Mutex 0.01 0.23
Barrier 0.01 0.64
BB-RW 0.13 6.76
BB-Mutex 0.63 1.99
8.10 12.05
0.98 0.03
0.01 0.50
0.63 10.80
2.05 6.47
P denotes parameterized verification for
94
Interface Verification Performance
TServer-Main 67.72 17.08
TServer-RMI 91.79 20.31
TServer-Event 6.57 10.95
TServer-Feed 123.12 83.49
TClient-Main 2.00 2.32
TClient-RMI 17.06 40.96
TClient-Event 663.21 33.09
95
Fault Categories
• Concurrency controller faults
• initialization faults (2)
• guard faults (2)
• update faults (6)
• blocking/nonblocking faults (4)
• Interface faults
• modified-call faults (8)
• conditional-call faults
• conditions based on existing program variables
(13)
• conditions on new variables declared during fault
seeding (5)

96
Effectiveness in Finding Faults
• Created 40 faulty versions of TSAFE
• Each version had at most one interface fault and
at most one behavior fault
• 14 behavior and 26 interface faults
• Among 14 behavior faults ALV identified 12 of
them
• 2 uncaught faults were spurious
• Among 26 interface faults JPF identified 21 of
them
• 2 of the uncaught faults were spurious
• 3 of the uncaught faults were real faults that
were not caught by JPF

97
Falsification Performance
TServer-RMI 29.43 24.74
TServer-Event 6.88 9.56
TServer-Feed 18.51 94.72
TClient-RMI 10.12 42.64
TClient-Event 15.63 12.20
Concurrency Controller Time (sec) Memory (MB)
RW-8 0.34 3.26
RW-16 1.61 10.04
RW-P 1.51 5.03
Mutex-8 0.02 0.19
Mutex-16 0.04 0.54
Mutex-p 0.12 0.70
98
Conclusions
• Infinite state model checking is feasible
• Enables verification of specifications with
unbounded variables
• Enables verification of parameterized systems
• Infinite state verification techniques can help
us in identifying more efficient finite state
model checking techniques
• Building extensible tools is important!

99
Conclusions
• Application of automated verification techniques
to real-world systems leads to re-thinking the
design
• Design for verification can lead to more
effective verification
• Integrating verification tools lead to more
effective verification
• In our case ALV and JPF

100
Conclusions
• We were able to use our design for verification
approach based on design patterns and behavioral
interfaces in different domains
• Use of domain specific behavior verification
techniques has been very effective
• Interface verification was the bottleneck
• Model checking research resulted in various
verification techniques and tools which can be
customized for specific classes of software
systems
• Automated verification techniques can scale to
realistic software systems using design for
verification approach

101
THE END