A Specification Language and a Verification Engine for Reliable Reactive System Development

1
A Specification Language and a Verification
Engine for Reliable Reactive System Development

• Tevfik Bultan
• Department of Computer Science
• University of California, Santa Barbara
• bultan_at_cs.ucsb.edu
• http//www.cs.ucsb.edu/bultan/
• http//www.cs.ucsb.edu/bultan/composite/

2
Towards Verifiable Specification Languages

• Tevfik Bultan
• Department of Computer Science
• University of California, Santa Barbara
• bultan_at_cs.ucsb.edu
• http//www.cs.ucsb.edu/bultan/
• http//www.cs.ucsb.edu/bultan/composite/

3
A Set of Tools for Specification and Verification
of Reactive Systems
Action Language specification
Action Language Parser
Omega Library
CUDD Package
Code Generator
Verified code
4
Applications

• Safety-critical system specifications
• SCR (tabular), Statecharts (hierarchical state
  machines) specifications Bultan, Gerber, League
  ISSTA98, TOSEM00
• Concurrent programs
• Synthesizing verified monitor classes from
  specifications Yavuz-Kahveci, Bultan
• Protocol verification
• Verification of parameterized cache coherence
  protocols using counting abstraction Delzanno,
  Bultan CP01
• Verification of workflow specifications
• Verification of acyclic decision flows Fu,
  Bultan, Hull, Su

5
Composite Model Checking

• Can model checking be extended to verification of
  specifications with arithmetic constraints?
• Bultan, Gerber, Pugh CAV97, TOPLAS99 Using
  Presburger (linear) arithmetic constraints for
  model checking infinite state systems
• Problem Most specifications have a combination
  of integer, boolean and enumerated variables
• Bultan, Gerber, League ISSTA98, TOSEM00
  Composite model checking
• Model checking with type-specific symbolic
  representations
• Uses Presburger arithmetic constraints and BDDs
  together

6
Composite Symbolic Library Yavuz-Kahveci,
Tuncer, Bultan TACAS01

• A symbolic manipulator that can handle boolean
  and integer variables (linear arithmetic
  constraints)
• Built on top of other symbolic manipulators
• Omega Library Pugh et al. a Presburger
  arithmetic formula manipulator (based on
  polyhedral representations)
• CUDD package Somenzi et al. a Boolean logic
  formula manipulator (a BDD package)
• Uses a disjunctive representation to combine
  arithmetic constraints with BDDs
• Uses an object oriented design
• Every symbolic representation is derived from an
  abstract class
• We wrote wrappers around Omega Library and CUDD
  package
• Can be extended to other variable types if a
  symbolic representation is provided for them

7
Action Language Bultan ICSE00 Bultan,
Yavuz-Kahveci ASE01

• Initial goal
• To develop an input specification language for
  our composite model checker
• Broader perspective
• Develop a low level specification language for
  model checking
• The language should be able to handle different
  high level specification languages

8
Outline

• Specification Language Action Language
• Synchronous vs. asynchronous composition
• Translating hierarchical and tabular
  specifications to Action Language
• Verification Engine
• Constraint-based verification
• Composite Symbolic Library
• Applications
• Synthesizing verified monitor classes
• Verification of parameterized cache coherence
  protocols
• Verification of workflow specifications
• Related, Current and Future Work

9
Model Checking View

• Every reactive system
• safety-critical software specification,
• cache coherence protocol,
• mutual exclusion algorithm, etc.
• is represented as a transition system
• S The set of states
• I ? S The set of initial states
• R ? S ? S The transition relation

10
Model Checking View

• Properties of reactive systems are expressed in
  temporal logics
• Invariant(p) is true in a state if property p
  is true in every state reachable from that state
• Also known as AG
• Eventually(p) is true in a state if property p
  is true at some state on every execution path
  from that state
• Also known as AF

11
Action Language

• A state based language
• Actions correspond to state changes
• States correspond to valuations of variables
• Integer (possibly unbounded), boolean and
  enumerated variables
• Parameterized constants (verified for every
  possible value of the constant)
• Transition relation is defined using actions
• Atomic actions Predicates on current and next
  state variables
• Action composition
• synchronous () or asynchronous ()
• Modular
• Modules can have submodules
• Modules are defined as synchronous and
  asynchronous compositions of its actions and
  submodules

12
Actions in Action Language

• Atomic actions Predicates on current and next
  state variables
• Current state variables reading, nr, busy
• Next state variables reading, nr, busy
• Logical operators not (!) and () or ()
• Equality (for all variable types)
• Linear arithmetic lt, gt, gt, lt, , (by a
  constant)
• An atomic action
• !reading and !busy and nrnr1 and reading

13
An Action Language Specification

• module main()
• integer nr
• boolean busy
• restrict nrgt0
• initial nr0 and !busy
• module Reader()
• boolean reading
• initial !reading
• rEnter !reading and !busy and
• nrnr1 and reading
• rExit reading and !reading and nrnr-1
• Reader rEnter rExit
• endmodule
• module Writer()
• boolean writing
• initial !writing
• wEnter !writing and nr0 and !busy and
• busy and writing
• wExit writing and !writing and !busy

14
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
• module Reader()
• boolean reading
• initial !reading
• rEnter !reading and !busy and
• nrnr1 and reading
• rExit reading and !reading and nrnr-1
• Reader rEnter rExit
• 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
15
Asynchronous Composition

• Asynchronous composition is equivalent to
  disjunction if composed actions have the same
  next state variables
• a1 i gt 0 and i i 1
• a2 i lt 0 and i i 1
• a3 a1 a2
• is equivalent to
• a3 (i gt 0 and i i 1)
• or (i lt 0 and i i 1)

16
Asynchronous Composition

• Asynchronous composition preserves values of
  variables which are not explicitly updated
• a1 i gt j and i j
• a2 i lt j and j i
• a3 a1 a2
• is equivalent to
• a3 (i gt j and i j) and j j
• or (i lt j and j i) and i i

17
Synchronous Composition

• Synchronous composition is equivalent to
  conjunction if two actions do not disable each
  other
• a1 i i 1
• a2 j j 1
• a3 a1 a2
• is equivalent to
• a3 i i 1 and j j 1

18
Synchronous Composition

• A disabled action does not block synchronous
  composition
• a1 i lt max and i i 1
• a2 j lt max and j j 1
• a3 a1 a2
• is equivalent to
• a3 (i lt max and i i 1 or i gt max i i)
• and (j lt max j j 1 or j gt max j j)

19
Statecharts Harel 87

• Hierarchical state machines
• States can be combined to form superstates
• OR decomposition of a superstate
• The system can be in only one of the OR states at
  any given time
• AND decomposition of a superstate
• The system has to be in both AND states at the
  same time
• Transitions
• Transitions between states

20
Statecharts to Action Language

• Statecharts transitions (arcs) correspond to
  actions
• OR states correspond to enumerated variables and
  they define the state space
• Transitions (actions) of OR states are combined
  using asynchronous composition
• Transitions (actions) of AND states are combined
  using synchronous composition

21
Statecharts to Action Language

• module main()
• enumerated Alarm Shut, Op
• enumerated Mode On, Off
• enumerated Vol 1, 2
• initial AlarmShut and ModeOff and Vol1
• t1 AlarmShut and AlarmOp and ModeOn and
  Vol1
• t2 AlarmShut and AlarmOp and ModeOff and
  Vol1
• t3 AlarmOp and AlarmShut
• t4 AlarmOp and ModeOn and ModeOff
• t5 AlarmOp and ModeOff and ModeOn
• ...
• main t1 t2 t3
• (t4 t5) (t6 t7)
• endmodule

Alarm
Shut
t1
t2
Op
t3
Mode
Vol
On
1
t4
t5
t6
t7
Off
2
Preserves the structure of the Statecharts
specification
22
SCR Courtois and Parnas 93, Heitmeyer et al.
96

• Tabular specifications
• Mode transition tables
• Condition tables
• Event tables
• Events
• _at_T(c) ?c ? c
• In action language !c and c
• _at_T(c) WHEN d ?c ? c ? d
• In action language !c and c and d

23
SCR to Action Language

• Each row in an SCR table corresponds to an action
• The transition relation of a table is defined by
  asynchronous composition of actions that
  correspond to its rows
• The transition relation of the whole system is
  defined by synchronous composition of transition
  relations of tables

24
SCR to Action Language

• module main()
• enumerated Heater On, Off
• enumerated AC On, Off
• integer temp
• parameterized integer low, high
• initial lowlttemplthigh
• and HeaterACOff
• r1 !(templtlow) and templtlow
• and HeaterOff and HeaterOn
• r2 !(tempgtlow) and tempgtlow and HeaterOn
  and HeaterOff
• t_heat r1 r2
• ...
• main t_heat t_AC
• endmodule

Heater
Old Mode Event New Mode
Off _at_T(temp lt low) On
On _at_T(temp ? low) Off
AC
Old Mode Event New Mode
Off _at_T(temp gt high) On
On _at_T(temp ? high) Off
25
Outline

• Model Checking
• Specification Language Action Language
• Synchronous vs. asynchronous composition
• Translating hierarchical and tabular
  specifications to Action Language
• Verification Engine
• Constraint-based verification
• Composite Symbolic Library
• Applications
• Synthesizing verified monitor classes
• Verification of parameterized cache coherence
  protocols
• Verification of workflow specifications
• Related, Current and Future Work

26
Model Checking

• Given a program and a temporal property p
• Either show that all the initial states satisfy
  the temporal property p
• set of initial states ? truth set of p
• Or find an initial state which does not satisfy
  the property p
• a state ? set of initial states ? truth set of ?p

27
Temporal Properties ? Fixpoints
backwardImage of ?p
Backward fixpoint
Initial states

?p
initial states that violate Invariant(p)
states that can reach ?p i.e., states that
violate Invariant(p)
Invariant(p)
Forward fixpoint
Initial states

?p
reachable states that violate p
reachable states of the system
forward image of initial states
28
Symbolic Model Checking

• 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

29
BDDs

• Efficient representation for boolean functions
• Disjunction, conjunction complexity at most
  quadratic
• Negation complexity constant
• Equivalence checking complexity constant or
  linear
• Image computation complexity can be exponential

30
Constraint-Based Verification

• Can we use linear arithmetic constraints as a
  symbolic representation?
• Required functionality
• Disjunction, conjunction, negation, equivalence
  checking, existential variable elimination
• Advantages
• Arithmetic constraints can represent infinite
  sets
• Heuristics based on arithmetic constraints can be
  used to accelerate fixpoint computations
• Widening, loop-closures

31
Linear Arithmetic Constraints

• Can be used to represent sets of valuations of
  unbounded integers
• Linear integer arithmetic formulas can be stored
  as a set of polyhedra
• where each ckl is a linear equality or
  inequality constraint and each
• is a polyhedron

32
Linear Arithmetic Constraints

• Disjunction complexity linear
• Conjunction complexity quadratic
• Negation complexity can be exponential
• Because of the disjunctive representation
• Equivalence checking complexity can be
  exponential
• Uses existential variable elimination
• Image computation complexity can be exponential
• Uses existential variable elimination

33
A Linear Arithmetic Constraint Manipulator

• Omega Library Pugh et al.
• Manipulates Presburger arithmetic formulas First
  order theory of integers without multiplication
• Equality and inequality constraints are not
  enough Divisibility constraints are also needed
• Existential variable elimination in Omega
  Library Extension of Fourier-Motzkin variable
  elimination to integers
• Eliminating one variable from a conjunction of
  constraints may double the number of constraints
• Integer variables complicate the problem even
  further

34
Fourier-Motzkin Variable Elimination

• Given two constraints ? ? bz and az ? ? we have
• a? ? abz ? b?
• We can eliminate z as
• ?z . a? ? abz ? b? if and only if a? ? b?
• Every upper and lower bound pair can generate a
  separate constraint, the number of constraints
  can double for each eliminated variable

real shadow
35
Integers are More Complicated

• If z is integer
• ?z . a? ? abz ? b? if a? (a - 1)(b - 1) ?
  b?
• Remaining solutions can be characterized using
  periodicity constraints in the following form
• ?z . ? i bz

dark shadow
36
Consider the constraints
?y . 0 ? 3y x ? 7 ? 1? x 2y ? 5
We get the following bounds for y
2x ? 6y
6y ? 2x 14
6y ? 3x - 3
3x - 15 ? 6y
When we combine 2 lower bounds with 2 upper
bounds we get four constraints
0 ? 14 , 3 ? x , x ? 29 , 0 ? 12
Result is 3 ? x ? 29
37
y
x 5 ? 2y
2y ? x 1
x ? 3y
3y ? x 7
29
3
x
dark shadow
real shadow
38
How 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!

39
Arithmetic Constraints on Bounded Integer
Variables

• BDDs and constraint representations are both
  applicable
• Which one is better?

40
smv SMV smvco SMV with William Chans
interleaved variable ordering omc Our model
checker built on Omega Library
AG(!(pc1cs pc2cs))
Intel Pentium PC (500MHz, 128MByte main memory)
41
(No Transcript)
42
AG(cinchairgtcleave bavailgtbbusygtbdone
cinchairltbavail bbusyltcinchair
cleaveltbdone)
43
AG(produced-consumed size-available
0ltavailableltsize)
44
(No Transcript)
45
Arithmetic Constraints vs. BDDs

• Constraint based verification can be more
  efficient than BDDs for integers with large
  domains
• BDD-based verification is more robust
• Constraint based approach does not scale well
  when there are boolean or enumerated variables in
  the specification
• Constraint based verification can be used to
  automatically verify infinite state systems
• cannot be done using BDDs
• Price of infinity
• CTL model checking becomes undecidable

46
Conservative Approximations

• Compute a lower ( p? ) or an upper ( p )
  approximation to the truth set of the property (
  p )
• Model checker can give three answers

p
p?
I
p
p?
I
The property is satisfied
I dont know
sates which violate the property
I
p
? p?
p
The property is false and here is a
counter-example
47
Computing Upper and Lower Bounds

• Approximate fixpoint computations
• Widening To compute upper bound for
  least-fixpoints
• We use a generalization of the polyhedra widening
  operator by Cousot and Halbwachs
• Collapsing (dual of widening) To compute lower
  bound for greatest-fixpoints
• Truncated fixpoints To compute lower bounds for
  least-fixpoints and upper bounds for greatest
  fixpoints
• Loop-closures
• Compute transitive closure of self-loops
• Can easily handle simple loops which increment or
  decrement a counter

48
Is There a Better Way?

• Each symbolic representation has its own
  deficiencies
• BDDs cannot represent infinite sets
• Linear arithmetic constraint representations are
  expensive to manipulate
• Mapping boolean variables to integers does not
  scale
• Eliminating boolean variables by partitioning the
  state-space does not scale

49
Composite Model Checking

• Each variable type is mapped to a symbolic
  representation type
• Map boolean and enumerated types to BDD
  representation
• Map integer type to arithmetic constraint
  representation
• Use a disjunctive representation to combine
  symbolic representations
• Each disjunct is a conjunction of formulas
  represented by different symbolic representations

50
Composite Formulas

• Composite formula (CF)
• CF CF ? CF CF ? CF ?CF BF IF
• Boolean Formula (BF)
• BF BF ? BF BF ? BF ?BF Termbool
• Termbool idbool true false
• Integer Formula (IF)
• IF IF ? IF IF ? IF ?IF Termint Rop
  Termint
• Termint Termint Aop Termint ?Termint
  idint constantint
• where
• Rop denotes relational operators (, ?, gt , lt,
  ?, ?),
• Aop denotes arithmetic operators (,-, and
  with a constant)

51
Composite Representation

• Each composite formula A is represented as
• where
• n is the number of composite atoms in A
• t is the number of basic symbolic representations
  
• Sets of states and transitions are represented
  using this disjunctive representation
• Set operations and image computations are
  performed on this disjunctive representation

52
Conjunctive Decomposition

• Each composite atom is a conjunction
• Each conjunct corresponds to a different symbolic
  representation
• x integer y boolean
• xgt0 and xx1 and y?y
• Conjunct xgt0 and x?x1 will be represented by
  arithmetic constraints
• Conjunct y?y will be represented by a BDD
• Advantage Image computations can be distributed
  over the conjunction (i.e., over different
  symbolic representations).

53
Composite Symbolic Library

• Our library implements this approach using an
  object-oriented design
• A common interface is used for each symbolic
  representation
• Easy to extend with new symbolic representations
• Enables polymorphic verification
• 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()
• bacwardImage()
• forwardImage()

CUDD Library
OMEGA Library
55
Composite Symbolic Representation
x integer, yboolean (xgt0 and x?x1 and
ytrue) or (xlt0 and x?x and y?y)
CompSym
representation ListltcompAtomgt
ListNodeltcompAtomgt
ListNodeltcompAtomgt
data compAtom
data compAtom
b
0
ytrue
0
yy
1
xgt0 and xx1
1
xlt0 and xx
next ListNodeltcompAtomgt
next ListNodeltcompAtomgt
56
Satisfiability Checking

• boolean isSatisfiable(CompSym A)
• for each compAtom b in A do
• if b is satisfiable then
• return true
• return false
• boolean isSatisfiable(compAtom a)
• for each symbolic representation t do
• if at is not satisfiable then
• return false
• return true

is
Satisfiable?
true
false
false
true
is
is
is
is
and
?
Satisfiable?
Satisfiable?
Satisfiable?
57
Backward Image Composite Representation
B
A

• CompSym backwardImage(Compsym A, CompSym B)
• CompSym C
• for each compAtom d in A do
• for each compAtom e in B do
• insert backwardImage(d,e) into C
• return C

C
58
Backward Image Composite Atom

• compAtom backwardImage(compAtom a, compAtom b)
• for each symbolic representation type t do
• replace at by backwardImage(at , bt )
• return a

b
a
59
Heuristics for Efficient Manipulation of
Composite Representation

• Masking
• Mask operations on integer arithmetic constraints
  with operations on BDDs
• Incremental subset check
• Exploit the disjunctive structure by computing
  subset checks incrementally
• Merge image computation with the subset check in
  least-fixpoint computations
• Simplification
• Reduce the number of disjuncts in the composite
  representation by iteratively merging matching
  disjuncts
• Cache expensive operations on arithmetic
  constraints

60
Simplification Example
(y ? z z 1)
(x ? z z 1)
((x ? y) ? z gt z)
?
?
?
?
((x ? y) ? z gt z )
?
61
Polymorphic Verifier

• Symbolic TranSyscheck(Node f)
• Symbolic s check(f.left)
• case EX
• s.backwardImage(transRelation)
• case EF
• do
• snew s
• sold s
• snew.backwardImage(transRelation)
• s.union(snew)
• while not sold.isEqual(s)

? Action Language Verifier is polymorphic ? When
there are no integer variable in the
specification it becomes a BDD based model
checker
62
Bounded-Buffer Producer Consumer
2
pstatei pstatei1 producedproduced
countcount
Producer
1
i
pstateN pstate1 countltsize
producedproduced1 countcount1
N
2
cstatei cstatei1 consumedconsumed
countcount
i
Consumer
1
N
cstateN cstate1 countgt0
consumedconsumed1 countcount-1
63
Experiment
SUN ULTRA 10 (768 Mbyte main memory)
CMC Our composite model checker OMC Our model
checker built on Omega-library Partitioned
Control states are eliminated by partitioning the
state space Mapped Control states are mapped
to integer variables
64
Outline

• Model Checking
• Specification Language Action Language
• Synchronous vs. asynchronous composition
• Translating hierarchical and tabular
  specifications to Action Language
• Verification Engine
• Constraint-based verification
• Composite Symbolic Library
• Applications
• Synthesizing verified monitor classes
• Verification of parameterized cache coherence
  protocols
• Verification of workflow specifications
• Related, Current and Future Work

65
Synthesizing Verified Monitors Yavuz-Kahveci,
Bultan 01

• Concurrent programming is difficult
• Exponential increase in the number of states by
  the number of concurrent components
• Monitors provide scoping rules for concurrency
• Variables of a monitor can only be accessed by
  monitors procedures
• No two processes can be active in a monitor at
  the same time
• Java made programming using monitors a common
  problem

66
Monitors

• Challenges in monitor programming
• Condition variables
• Wait and signal operations
• Even with a few condition variables coordinating
  wait and signal operations can be difficult
• Avoid deadlock
• Avoid inefficiency due to unnecessary signaling

67
Monitor Specifications in Action Language

• Monitors with boolean, enumerated and integer
  variables
• Condition variables are not necessary in Action
  Language
• Semantics of Action Language ensures that an
  action is executed when it is enabled
• We can automatically verify Action Language
  specifications
• We can automatically synthesize efficient monitor
  implementations from Action Language
  specifications

68
What About Arbitrary Number of Processes?

• Use counting abstraction Delzanno CAV00
• Create an integer variable for each local state
  of a process type
• Each variable will count the number of processes
  in a particular state
• Local states of the process types have to be
  finite
• Specify only the process behavior that relates to
  the correctness of the monitor
• Shared variables of the monitor can be unbounded
• Counting abstraction can be automated

69
Readers-Writers Monitor Specification

• module main()
• integer nr
• boolean busy
• restrict nrgt0
• initial nr0 and !busy
• module Reader()
• boolean reading
• initial !reading
• rEnter !reading and !busy and
• nrnr1 and reading
• rExit reading and !reading and nrnr-1
• Reader rEnter rExit
• endmodule
• module Writer()
• boolean writing
• initial !writing
• wEnter !writing and nr0 and !busy and
• busy and writing
• wExit writing and !writing and !busy

70
Readers-Writers Monitor Specification After
Counting Abstraction

• module main()
• integer nr
• boolean busy
• parameterized integer numReader, numWriter
• restrict nrgt0 and numReadergt0 and
  numWritergt0
• initial nr0 and !busy
• module Reader()
• integer readingF, readingT
• initial readingFnumReader and readingT0
• rEnter readingFgt0 and !busy and
• nrnr1 and readingFreadingF-1 and
• readingTreadingT1
• rExit readingTgt0 and nrnr-1
  readingTreadingT-1 and
  readingFreadingF1
• Reader rEnter rExit
• endmodule
• module Writer()
• ...
• endmodule
• main Reader() Writer()

71
Verification of Readers-Writers Monitor
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
SUN ULTRA 10 (768 Mbyte main memory)
72
Synthesized Monitor Class Uses Specific
Notification Pattern

• public class ReadersWriters
• private int nr
• private boolean busy
• private Object rEnterCond, wEnterCond
• private synchronized boolean Guard_rEnter()
• if (!busy)
• nr
• return true
• else return false
• public void rEnter()
• synchronized(rEnterCond)
• while(!Guard_rEnter())
• rEnterCond.wait()
• public void rExit()
• synchronized(this) nr--
• synchronized(wEnterCond) wEnterCond.notify()
  

All condition variables and wait and signal
operations can be generated automatically
73
Verification of Parameterized Cache-Coherence
Protocols Delzanno, Bultan CP01
!grantS
!inv ex ??ex
ServeS
GrantS
nonex?ex
?reqS
Idle
SERVER
!!invS
!invEex ??ex
ServeE
InvE
?reqE
GrantE
nonex?ex
!grantE ex
??invS
?grantS
WaitS
Shared
!reqS
?reqE
CLIENT
Null
?grantE
WaitE
Exclusive
!reqE
?invE
74
Parameterized Protocol in Action Language
5 integer, 4 boolean variables

• module main()
• boolean ex
• enumerated state Idle, ServeE, InvE, GrantE,
  ServeS, GrantS
• integer xNull, xWaitS, xWaitE, xShared,
  xExclusive
• initial stateIdle and !ex and xNullgt1 and
  xShared0 and xExclusive0 and xWaitE0 and
  xWaitS0
• restrict xNullgt0 and xWaitSgt0 and xWaitEgt0
  and xSharedgt0 and xExclusivegt0 and ngt1
• reqS stateIdle xNullgt1
• state'ServeS xNull'xNull-1
  xWaitS'xWaitS1
• reqE1 stateIdle xNullgt1
• state'ServeE xNull'xNull-1
  xWaitE'xWaitE1
• reqE2 stateIdle xSharedgt1
• state'ServeE
  xShared'xShared-1 xWaitE'xWaitE1
• ...
• main reqS reqE1 reqE2 ...
• endmodule

75
Experiments

• Two versions of the protocol
• CCB with broadcast
• CCI with invalidation loop
• Properties
• P1-2 AG(?((xShared?1 ? xExclusive?1) ?
  xExclusive?2))
• P3 AG(xWaitS?1 ? AF(xShared?1))
• P4 ?n, n ?0, AG(xWaitS?n ? AF(xS?n)
• P5 AG(xWaitE?1 ? AF(xE?1))

76
Approx. Forward (iterations) Fixpoints (iterations) Time (secs.) Memory (Mbytes)
CCB-P1-2 EF(4) 0.60 10.2
CCB-P1-2 F(7) F(7),EF(1) 0.52 9.7
CCB-P3 EG(3),EF(5) 2.37 14.1
CCB-P3 F(7) EG(3),EF(1) 0.68 10.7
CCB-P4 EG(3),EF(8) 9.34 25.6
CCB-P4 F(7) EG(3),EF(1) 0.74 11.2
CCB-P5 Yes EG(4),EF(11) 3.01 14.1
CCB-P5 Yes F(7) EG(3),EF(1) 0.61 10.4
CCI-P1-2 EF(4) 0.59 10.4
CCI-P1-2 F(6) EF(1) 0.50 9.8
CCI-P3 Yes EG(3),EF(5) 2.01 11.9
CCI-P3 F(6) EG(3),EF(1) 0.65 10.6
CCI-P4 ?
CCI-P4 F(6) EG(3), EF(1) 0.81 11.6
CCI-P5 ?
CCI-P5 ?
SUN ULTRA 10 (768 Mbyte main memory)
77
Verification of Workflow Specifications Fu,
Bultan, Su, Hull 01

• Workflow Languages
• High-level languages for business applications
• Programming for non-programmers
• Vortex Language
• Module based
• Source attributes, target attributes
• Enabling conditions
• Rules, combining policies
• Declarative semantics
• Acyclic dependency graph

78
Vortex Specifications

• Fast changing business logic
• Rule based logic changes frequently
• New rules added into system at any time
• Error prone process
• Automated verification?

79
MIHU (May I Help yoU?)
? Runs behind Web Server ? Decides whether to
launch the customer representative service
80
MIHU (May I Help yoU?)
Source Attributes Customer ID, Shopping cart,
history logs Target Attribute offer_AWD Integer
variables 40 Source lines 800
81
Dependency Graph of MIHU
82
Experiments
SUN ULTRA 10 (768 Mbyte main memory)
SMV(5bits) SMV(10bits) SMV(15bits) Action
P1 12s 9MB 16min 67MB 2.6hrs 86MB 10min 93MB
P2 32s 12MB 15min 66MB 2.9hrs 86MB 10min 93MB
P3 19s 10MB 18min 67MB 2.3hrs 87MB 27.7hrs 1GB

• SMV translation required several heuristics to
  get it running
• Disjunctive transition BDD, variable pruning,
  initial image projection
• SMV version does not converge in 30hrs when we
  increase the integer widths to 16 bits
• There are properties for which Action Language
  Verifier did not converge but SMV converged for ?
  15 bits
• SMV gives a false negative for property P2 for 5
  bits
• Both SMV and Action Language Verifier found an
  error for Property 3

83
Model Checking Software Specifications

• Atlee, Gannon 93 Translating SCR mode
  transition tables to input language of explicit
  state model checker EMC Clarke, Emerson, Sistla
  86
• Chan et al. 98,00 Translating RSML
  specifications to input language of symbolic
  model checker SMV McMillan 93
• Bharadwaj, Heitmeyer 99 Translating SCR
  specifications to Promela, input language of
  automata-theoretic explicit state model checker
  SPIN Holzmann 97

84
Specification Languages for Reactive Systems

• Specification languages for verification
• Milner 80 CCS
• Chandy and Misra 88 Unity
• Lamport 94 Temporal Logic of Actions (TLA)
• Specification languages for model checking
• Holzmann 98 Promela
• McMillan 93 SMV
• Alur and Henzinger 96, 99 Reactive Modules

85
Action Language TLA Connection Lamport
TOPLAS94

• Similarities
• Transition relation is defined using predicates
  on current (unprimed) and next state (primed)
  variables
• Each predicate is defined using
• integer arithmetic, boolean logic, etc.
• Differences In Action Language
• Temporal operators are not used in defining the
  transition relation
• Dual language approach temporal properties (in
  CTL) are redundant, they are used to check
  correctness
• Synchronous and asynchronous composition
  operators are not equivalent to logical operators

86
Constraint-Based VerificationNot a New Idea

• Cooper 71 Used a decision procedure for
  Presburger arithmetic to verify sequential
  programs represented in a block form
• Cousot and Halbwachs 78 Used real arithmetic
  constraints to discover invariants of sequential
  programs

87
Constraint-Based Verification

• Halbwachs 93 Constraint based delay analysis in
  synchronous programs
• Halbwachs et al. 94 Verification of linear
  hybrid systems using constraint representations
• Alur et al. 96 HyTech, a model checker for
  hybrid systems

88
Constraint-Based Verification

• Boigelot and Wolper 94 Verification with
  periodic sets
• Boigelot et al. Meta-transitions
• Delzanno and Podelski 99 Built a model checker
  using constraint logic programming framework
• Boudet Comon, Wolper and Boigelot 00
  Translating linear arithmetic constraints to
  automata
• Kukula et al. 98 Comparison of automata and
  constraint-based verification
• no clear winner

89
Automata-Based Representations for Arithmetic
Constraints

• Klarlund et al. MONA, an automata manipulation
  tool for verification
• Boudet Comon Translating linear arithmetic
  constraints to automata
• Wolper and Boigelot 00 verification using
  automata as a symbolic representation
• Kukula et al. 98 application of automata based
  verification to hardware verification

90
Combining Different Symbolic Representations

• Chan et al. CAV97
• both linear and non-linear constraints are mapped
  to BDDs
• Only data-memoryless and data-invariant
  transitions are supported
• Bharadwaj and Sims TACAS00
• Combines automata based representations (for
  linear arithmetic constraints) with BDDs
• Specialized for inductive invariant checking
• Bensalem et al. 00 Symbolic Analysis Laboratory
• Designed a specification language that allows
  integration of different verification tools

91
Current Work New Symbolic Representations

• Integrating shape analysis to Composite Symbolic
  Library
• Sagiv et al. Shape analysis Used for verifying
  linked list implementations
• Analyze monitor specifications with linked lists
• Synthesizing concurrent data structures
• Integrating automata-based constraint
  representations to Composite Symbolic Library
• Kukula et al. 98 Comparison of automata and
  constraint-based verification

92
Future Work To Abstract or not to Abstract

• Abstraction techniques
• Restricting variable domains to finite sets
• Predicate abstraction Graf, Saidi 97, Saidi 00
• When should we use abstraction and when should we
  use constraint-based techniques?

93
Concluding Thought

• The fates of specification languages and
  automated verification techniques are tied to
  each other
• One will not succeed without the other
• Goal Developing verifiable specification
  languages