tools for specification, verification, and synthesis of reactive systems tevfik bultan department of...

Tools for Specification, Verification, and Synthesis of Reactive Systems

Tevfik Bultan

Department of Computer Science

University of California, Santa Barbara

[email protected]

http://www.cs.ucsb.edu/~bultan/

http://www.cs.ucsb.edu/~bultan/composite/

Tools for Specification, Verification, and Synthesis of Reactive Systems

Action Language Action Language specificationspecification

Action LanguageAction LanguageParserParser

Action LanguageAction LanguageVerifierVerifier

Composite SymbolicComposite SymbolicLibraryLibrary

Code GeneratorCode Generator Omega Omega LibraryLibrary

CUDDCUDDPackagePackage

Verified codeVerified code

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

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

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

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]

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

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

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

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

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: <, >, >=, <=, +, * (by a constant)

An atomic action:!reading and !busy and nr’=nr+1 and reading’

An Action Language Specificationmodule main()

integer nr;boolean busy;restrict: nr>=0;initial: nr=0 and !busy;module Reader()boolean reading;initial: !reading;rEnter: !reading and !busy and nr’=nr+1 and reading’;rExit: reading and !reading’ and nr’=nr-1;Reader: rEnter | rExit;endmodulemodule Writer()boolean writing;initial: !writing;wEnter: !writing and nr=0 and !busy and busy’ and writing’;wExit: writing and !writing’ and !busy’;Writer: wEnter | wExit;endmodulemain: Reader() | Reader() | Writer() | Writer();spec: invariant([busy => nr=0])

endmodule

A Closer Lookmodule main()

integer nr;boolean busy;restrict: nr>=0;initial: nr=0 and !busy;

module Reader()boolean reading;initial: !reading;rEnter: !reading and !busy and nr’=nr+1 and reading’;rExit: reading and !reading’ and nr’=nr-1;Reader: rEnter | rExit;

endmodule

module Writer() ... endmodule

main: Reader() | Reader() | Writer() | Writer();spec: invariant([busy => nr=0])

endmodule

S S :: Cartesian product ofCartesian product of variable domains defines variable domains defines the set of statesthe set of states

I I : Predicates defining : Predicates defining the initial statesthe initial states

RR : Atomic actions of the : Atomic actions of the ReaderReader

RR : Transition relation of : Transition relation of Reader defined as Reader defined as asynchronous composition asynchronous composition of its atomic actionsof its atomic actions

RR : Transition relation of main defined as : Transition relation of main defined as asynchronous composition of two Reader and asynchronous composition of two Reader and two Writer processestwo Writer processes

Asynchronous Composition

Asynchronous composition is equivalent to disjunction if composed actions have the same next state variables

a1: i > 0 and i’ = i + 1;a2: i <= 0 and i’ = i – 1;a3: a1 | a2

is equivalent to

a3: (i > 0 and i’ = i + 1) or (i <= 0 and i’ = i – 1);

Asynchronous Composition

Asynchronous composition preserves values of variables which are not explicitly updated

a1 : i > j and i’ = j;a2 : i <= j and j’ = i;a3 : a1 | a2;

is equivalent to

a3 : (i > j and i’ = j) and j’ = j or (i <= j and j’ = i) and i’ = i

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;

Synchronous Composition

A disabled action does not block synchronous composition

a1: i < max and i’ = i + 1;a2: j < max and j’ = j + 1;a3: a1 & a2;

is equivalent to

a3: (i < max and i’ = i + 1 or i >= max & i’ = i) and (j < max & j’ = j + 1 or j >= max & j’ = j);

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

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

Statecharts to Action Languagemodule main() enumerated Alarm {Shut, Op}; enumerated Mode {On, Off}; enumerated Vol {1, 2}; initial: Alarm=Shut and

Mode=Off and Vol=1; t1: Alarm=Shut and Alarm’=Op

and Mode’=On and Vol’=1; t2: Alarm=Shut and Alarm’=Op

and Mode’=Off and Vol’=1; t3: Alarm=Op and Alarm’=Shut; t4: Alarm=Op and Mode=On and

Mode’=Off; t5: Alarm=Op and Mode=Off and

Mode’=On;... main: t1 | t2 | t3 | (t4 | t5) & (t6 | t7); endmodule

AlarmAlarm

ShutShut

OpOp

OnOn

OffOff

11

22

ModeMode VolVol

t1t1 t2t2 t3t3

t4t4 t5t5 t6t6 t7t7

Preserves the structure of thePreserves the structure of theStatecharts specificationStatecharts specification

SCR [Courtois and Parnas 93], [Heitmeyer et al. 96]

Tabular specifications– Mode transition tables– Condition tables– Event tables

Events– @T(c) = c c’ – In action language: !c and c’ – @T(c) WHEN d = c c’ d– In action language: !c and c’ and d

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

SCR to Action Language

module main() enumerated Heater {On, Off}; enumerated AC {On, Off}; integer temp; parameterized integer low,

high; initial: low<=temp<=high and Heater=AC=Off; r1: !(temp<low) and temp’<low and Heater=Off and Heater’=On; r2: !(temp>=low) and temp’>=low

and Heater=On and Heater’=Off;

t_heat: r1 | r2; ... main: t_heat & t_AC; endmodule

Old Mode Event New Mode

Off @T(temp < low) On

On @T(temp low) Off

Old Mode Event New Mode

Off @T(temp > high) On

On @T(temp high)

Off

Heater Heater

ACAC

Outline

Specification Language: Action Language– Synchronous vs. asynchronous composition– Translating hierarchical and tabular specifications to Action

Language




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

Temporal Properties Fixpoints

• • •• • •

Invariant(Invariant(pp))

ppInitialInitialstatesstates

initial states that initial states that violate Invariant(violate Invariant(pp))

BackwardBackwardfixpointfixpoint

ForwardForwardfixpointfixpoint

InitialInitialstatesstates

• • •• • •

states that can reach states that can reach pp i.e., states that violate Invariant(i.e., states that violate Invariant(pp))

reachable states reachable states of the systemof the system

pp

backwardImagebackwardImage of of pp

reachable states reachable states that violate that violate ppforward imageforward image

of initial statesof initial states

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

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

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

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 ccklkl is a linear equality or inequality is a linear equality or inequality

constraint and eachconstraint and each

is a polyhedronis a polyhedron

cF kllk

ckll

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

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

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!

Arithmetic Constraints on Bounded Integer Variables

BDDs and constraint representations are both applicable

Which one is better?

A case study: Verification of Workflow Specifications

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

Vortex Specifications

Fast changing business logicRule based logic changes frequently

New rules added into system at any time

Error prone process

Automated verification?

MIHU (May I Help yoU?)

Runs behind Web Server

Decides whether to launch

the customer representative service

MIHU (May I Help yoU?)

Source Attributes: Customer ID, Shopping cart, history logs

Target Attribute: offer_AWD

Integer variables: 40

Source lines: 800

Dependency Graph of MIHU

Experiments

SMV translation required several heuristics to get it runningSMV 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 SMV version does not converge in 30hrs when we increase the integer widths to 16 bitsinteger widths to 16 bits

There are properties for which Action Language Verifier did not There are properties for which Action Language Verifier did not converge but SMV converged for converge but SMV converged for 15 bits 15 bits

SMV gives a false negative for property P2 for 5 bitsSMV gives a false negative for property P2 for 5 bits Both SMV and Action Language Verifier found an error for Both SMV and Action Language Verifier found an error for

Property 3Property 3

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

SUN ULTRA 10 (768 Mbyte main memory)

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

Conservative Approximations

Compute a lower ( pp ) ) or an upper ( pp++ ) )

approximation to the truth set of the property ( p p )) Model checker can give three answers:

II pppp

“The property is satisfied”

II pppp

“I don’t know”

“The property is false and here is a counter-example”

II pp ppsates whichsates whichviolate the violate the propertyproperty

pp++

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

Is There a Better Way?

Each symbolic representation has its own deficiencies

BDD’s 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

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

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

aA ijt

j

n

i 11

Conjunctive Decomposition

Each composite atom is a conjunction Each conjunct corresponds to a different symbolic

representation– x: integer; y: boolean;– x>0 and x’=x+1 and y´y

• Conjunct x>0 and x´x+1 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).

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]

Composite Symbolic Library: Class Diagram

CUDD Library OMEGA Library

Symbolic

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

CompSym

–representation: list of comAtom

+intersect()+ union() • • •

BoolSym

–representation: BDD

+intersect()+union() • • •

IntSym

–representation: Polyhedra

+intersect()+union() • • •

compAtom

–atom: *Symbolic

Composite Symbolic Representation

b’

x: integer, y:boolean

(x>0 and x´x+1 and y´=true) or (x<=0 and x´x and y´y)

: CompSym

representation : List<compAtom>

: ListNode<compAtom> : ListNode<compAtom>

next :*ListNode<compAtom> next: *ListNode<compAtom>

data : compAtom data : compAtom

01

y´=true x>0 and x´=x+1

01

y’=yx<=0 and x’=x

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?

isSatisfiable? isSatisfiable?isSatisfiable?

false false true

true

is

Satisfiable?

is

is

Satisfiable?

is

Satisfiable?

and

Backward Image: Composite Representation

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

A: B:

C:

• • •

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:

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

Simplification Example

(y z´ = z + 1) (x z´ = z + 1) ((x y) z´ > z)

((x y) z´ > z)((y x) z´ = z + 1)

((x y) (z´ = z + 1 z´ > z))

((x y) z´ > z )

Polymorphic Verifier

Symbolic TranSys::check(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 Action Language Verifier is polymorphicis polymorphic When there are no integerWhen there are no integervariable in the specification it variable in the specification it becomes a BDD based model becomes a BDD based model checkerchecker

Bounded-Buffer Producer Consumer

pstate=N && pstate´=1 && count<size && produced´=produced+1&& count´=count+1

cstate=N && cstate´=1 && count>0 && consumed´=consumed+1 && count´=count-1

1

N

i

2

Producer

N

i

2

1 Consumer

cstate=i && cstate´=i+1 && consumed´=consumed && count´=count

pstate=i && pstate´=i+1 && produced´=produced && count´=count

Experiment

Performance of Composite Model Checker

0

2

4

6

8

10

Number of control states

Exe

cuti

on t

ime

(sec

)

CMCOMC-PartitionedOMC-Mapped

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


Outline

Model Checking Specification Language: Action Language

– Synchronous vs. asynchronous composition– Translating hierarchical and tabular specifications to Action

Language




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 monitor’s

procedures– No two processes can be active in a monitor at the same

time

Java made programming using monitors a common problem

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

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

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

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

Readers-Writers Monitor Specificationmodule main()

integer nr;boolean busy;restrict: nr>=0;initial: nr=0 and !busy;module Reader()boolean reading;initial: !reading;rEnter: !reading and !busy and nr’=nr+1 and reading’;rExit: reading and !reading’ and nr’=nr-1;Reader: rEnter | rExit;endmodulemodule Writer()boolean writing;initial: !writing;wEnter: !writing and nr=0 and !busy and busy’ and writing’;wExit: writing and !writing’ and !busy’;Writer: wEnter | wExit;endmodulemain: Reader() | Reader() | Writer() | Writer();spec: invariant([busy => nr=0])

endmodule

What About Arbitrary Number of Processes?

Use counting abstraction [Delzanno CAV’00]

– 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

Readers-Writers Monitor Specification After Counting Abstraction

module main()integer nr;boolean busy;

parameterized integer numReader, numWriter;restrict: nr>=0 and numReader>=0 and numWriter>=0;initial: nr=0 and !busy;module Reader()

integer readingF, readingT;initial: readingF=numReader and readingT=0;rEnter: readingF>0 and !busy and nr’=nr+1 and readingF’=readingF-1 and

readingT’=readingT+1;rExit: readingT>0 and nr’=nr-1 readingT’=readingT-1

and readingF’=readingF+1;Reader: rEnter | rExit;

endmodulemodule Writer()

...endmodulemain: Reader() | Writer();spec: invariant([busy => nr=0])

endmodule

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


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

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 andAll condition variables andwait and signal operations are wait and signal operations are generated automaticallygenerated automatically

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

A simplified model of Seattle Tacoma International Airport from [Zhong 97]A simplified model of Seattle Tacoma International Airport from [Zhong 97]

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

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

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

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

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]

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

Action Language TLA Connection [Lamport TOPLAS’94]

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

Constraint-Based Verification:Not 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


[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


[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

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

Combining Different Symbolic Representations

[Chan et al. CAV’97] – both linear and non-linear constraints are mapped to BDDs– Only data-memoryless and data-invariant transitions are

supported [Bharadwaj and Sims TACAS’00]

– 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

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]

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 abstraction+constraint based verification [Fu,Bultan,Su]

When should we use abstraction and when should we use constraint-based techniques?

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

tools for specification, verification, and synthesis of reactive systems tevfik bultan department of...

Documents

verification of specifications

bultan tacas01

outline specification

input specification

code slide

model checking view

tabular specifications

action language synchronous