Tools%20for%20Specification,%20Verification,%20and%20Synthesis%20of%20Reactive%20Systems

1
Tools for Specification, Verification, and
Synthesis of Reactive Systems

• 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
Tools for Specification, Verification, and
Synthesis of Reactive Systems
Action Language specification
Action Language Parser
Code Generator
Omega Library
CUDD Package
Verified code
3
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

4
Composite Symbolic Library Yavuz-Kahveci,
Tuncer, Bultan TACAS01, FROCOS02

• 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

5
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

6
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, 02
• 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 TACAS01

7
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
• Synthesizing Verified Monitors
• Airport Ground Traffic Control case study
• Related, Current and Future Work

8
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

9
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

10
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

11
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

12
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

13
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
14
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)

15
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

16
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

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

18
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

19
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

20
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
21
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

22
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 the
  transition relations of the tables

23
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
24
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
• Synthesizing Verified Monitors
• Airport Ground Traffic Control case study
• Related, Current and Future Work

25
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
• and generate a counter-example starting from that
  state

26
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
27
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

28
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

29
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

30
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

31
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

32
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
• Can be handled using divisibility constraints

33
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!

34
Arithmetic Constraints on Bounded Integer
Variables

• BDDs and constraint representations are both
  applicable
• Which one is better?
• A case study Verification of Workflow
  Specifications

35
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

36
Vortex Specifications

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

37
MIHU (May I Help yoU?)
? Runs behind Web Server ? Decides whether to
launch the customer representative service
38
MIHU (May I Help yoU?)
Source Attributes Customer ID, Shopping cart,
history logs Target Attribute offer_AWD Integer
variables 40 Source lines 800
39
Dependency Graph of MIHU
40
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

41
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

42
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
43
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

44
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

45
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

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

47
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

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

49
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

50
Composite Symbolic Library Class Diagram
Symbolic

• intersect()
• union()
• complement()
• isSatisfiable()
• isSubset()
• bacwardImage()
• forwardImage()

CUDD Library
OMEGA Library
51
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
52
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?
53
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
54
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
55
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

56
Simplification Example
(y ? z z 1)
(x ? z z 1)
((x ? y) ? z gt z)
?
?
?
?
((x ? y) ? z gt z )
?
57
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
58
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
59
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
60
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
• Synthesizing Verified Monitors
• Airport Ground Traffic Control case study
• Related, Current and Future Work

61
Synthesizing Verified Monitors Yavuz-Kahveci,
Bultan 02

• 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

62
Monitor Basics

• A monitor has
• A set of shared variables
• A set of procedures
• which provide access to the shared variables
• A lock
• To execute a monitor procedure a process has to
  grab the monitor lock
• Only one process can be active (i.e. executing a
  procedure) in the monitor at any given time

63
Monitor Basics

• What happens if a process needs to wait until a
  condition becomes true?
• Create a condition variable that corresponds to
  that condition
• Each condition variable has a wait queue
• A process waits for a condition in the wait queue
  of the corresponding condition variable
• When a process updates the shared variables that
  may cause a condition to become true
• ? it signals the processes in the wait
  queue of the corresponding condition variable

64
Monitors

• Challenges in monitor programming
• Condition variables
• Wait and signal operations
• Why not use a single wait queue?
• Inefficient, every waiting process has to wake up
  when any of the shared variables are updated
• Even with a few condition variables coordinating
  wait and signal operations can be difficult
• Avoid deadlock
• Avoid inefficiency due to unnecessary signaling

65
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

66
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

67
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

68
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()

69
Verification of Readers-Writers Monitor
Specification
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)
70
What about the Implementation?

• We can automatically generate code from the
  monitor specification
• Generate a Java class
• Make shared variables private variables
• Use synchronization to restrict access
• Is the generated code efficient
• Yes!
• We can synthesize the condition variables
  automatically
• There is no unnecessary thread notification

71
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 are generated automatically
72
Airport Ground Traffic Control

• Zhong 97 Modeling of airport operations using
  an object oriented approach
• A concurrent program simulating the airport
  ground traffic control
• multiple planes
• multiple runways and taxiways
• Can be used by controllers as advisory input

73
A simplified model of Seattle Tacoma
International Airport from Zhong 97
74
Control Logic

• An airplane can land using 16R only if no
  airplane is using 16R at the moment
• An airplane can takeoff using 16L only if no
  airplane is using 16L at the moment
• An airplane taxiing on one of the exits C3-C8 can
  cross runway 16L only if no airplane is taking
  off at the moment
• An airplane can start using 16L for taking off
  only if none of the crossing exits C3-C8 is
  occupied at the moment (arriving airplanes have
  higher priority)
• Only one airplane can use a taxiway at a time

75
Airport Ground Traffic Control Simulator

• Simulate behavior of each airplane with a thread
• Use a monitor which keeps track of number of
  airplanes on each runway and each taxiway
• Use guarded commands (which will become the
  procedures of the monitor) to enforce the control
  logic

76
Airport Ground Traffic Control Monitor

• Action Language specification
• Has 13 integer variables
• Has 4 Boolean variables per arriving airplane
  process to keep the local state of each airplane
• Has 2 Boolean variables per departing airplane
  process to keep the local state of each airplane
• Automatically generated monitor class
• Has 13 integer variables
• Has 20 condition variables
• Has 34 procedures

77
Experiments
Processes Construction Verify-P1 Verify-P2 Verify-P3
2 0.81 0.42 0.28 0.69
4 1.50 0.78 0.50 1.13
8 3.03 1.53 0.99 2.22
16 6.86 3.02 2.03 5.07
2A,PD 1.02 0.64 0.43 0.83
4A,PD 1.94 1.19 0.81 1.39
8A,PD 3.95 2.28 1.54 2.59
16A,PD 8.74 4.6 3.15 5.35
PA,2D 1.67 1.31 0.88 3.94
PA,4D 3.15 2.42 1.71 5.09
PA,8D 6.40 4.64 3.32 7.35
PA,16D 13.66 9.21 7.02 12.01
PA,PD 2.65 0.99 0.57 0.43
78
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

79
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

80
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

81
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

82
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

83
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

84
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

85
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

86
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
  Bartzis, Bultan

87
Current/Future Work To Abstract or not to
Abstract

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

88
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