Verification of Parameterized Hierarchical State Machines Using Action Language Verifier Tuba...

Verification of Parameterized Hierarchical State Machines Using Action Language Verifier

Tuba Yavuz-Kahveci Tevfik Bultan

University of Florida, Gainesville University of California, Santa Barbara

download Action Language Verifier at: //www.cs.ucsb.edu/~bultan/composite/

Outline

• An Example: Airport Ground Traffic Control• Hierarchical State Machines• Action Language Verifier• Composite Symbolic Library• Infinite State Verification• Parameterized Verification• Experimental Results• Related work

Example: Airport Ground Traffic Control

Runway r1 Runway r2

Taxiway t1 Taxiway t2

Gate g

Control Logic

• An arriving airplane lands using runway r1, navigates to taxiway t1, crosses runway r2, navigates to taxiway t2 and parks at gate g

• A departing airplane starts at gate g, navigates to taxiway t2, and takes off using runway r2

• Only one airplane can use a runway at any given time • Only one airplane can use a taxiway at any given time• An airplane taxiing on taxiway t1 can cross runway r2 only

if no airplane is taking off at the moment

Hierarchical State Machines

In a Hierarchical State Machine (HSM) [Harel 87]• States can be combined to form superstates• OR decomposition of a superstate

– The system can be in only one of the substates at any given time

• AND decomposition of a superstate – The system has to be in all of the substates at the same

time• Transitions

– Transitions between states are labeled as

trigger-event [ guard-condition ] / generated-event

Airport Ground Traffic Control

flow landing

takingoff taxiing1

taxiing2parking

fly

land[in(r1.empty)]/taxii1E

taxii1E[in(t1.empty)]/taxii2E

Airplane[*]

empty

occupied

land/taxii1E

r1


empty

occupied

g

empty

occupied

empty

occupied

t1 r2

empty

occupied

t2

Parameterized Hierarchical State Machines

• We use “*” to denote arbitrary number of instantiations of a state– These instantiations are asynchronously composed

using interleaving semantics• We used Action Language Verifier to verify CTL properties

parameterized hierarchical state machines• In order to verify a specification for arbitrary instances of a

module we used counting abstraction technique

Action Language [Bultan, ICSE 00], [Bultan, Yavuz-Kahveci, ASE 01]

• A state based language– Actions correspond to state changes

• States correspond to valuations of variables– boolean– enumerated– integer (possibly unbounded)– there is an extension to heap variables (i.e., pointers) but

this is not included in the current version• Parameterized constants

– specifications are verified for every possible value of the constant

Action Language

• Transition relation is defined using actions– Atomic actions: Predicates on current and next state

variables– Action composition:

• asynchronous (|) or synchronous (&)• Modular

– Modules can have submodules– A modules is defined as asynchronous and/or

synchronous compositions of its actions and submodules

Readers Writers Example

module 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 asynchronous : Transition relation of main defined as asynchronous composition of two Reader and two Writer processescomposition of two Reader and two Writer processes

Translating HSMs to Action Language

• 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

Translating HSMs to Action Language

module 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

Action Language Verifier[Bultan, Yavuz-Kahveci ASE01], [Yavuz-Kahveci, Bar, Bultan CAV05]

Action LanguageAction LanguageParserParser

Model CheckerModel Checker

Omega Omega LibraryLibrary

CUDDCUDDPackagePackage MONAMONA

Composite Symbolic LibraryComposite Symbolic Library

PresburgerPresburgerArithmeticArithmeticManipulatorManipulator

BDDBDDManipulatorManipulator

AutomataAutomataManipulatorManipulator

Action LanguageAction LanguageSpecificationSpecification

Counter-exampleCounter-example VerifiedVerified

I don’t knowI don’t know

Temporal Properties Fixpoints [Emerson and Clarke 80]

• • •• • •ppInitialInitialstatesstates

initial states that satisfy EF(initial states that satisfy EF(pp))

initial states that violate AG(initial states that violate AG(pp))

EF(EF(pp)) states that can reach states that can reach p p p p Pre( Pre(pp)) Pre(Pre( Pre(Pre(pp)) )) ......

• • •• • • EG(EG(p)p) InitialInitialstatesstates

initial states that satisfy EG(initial states that satisfy EG(p)p) initial states that violate AF(initial states that violate AF(pp))

EG(EG(pp)) states that can avoid reaching states that can avoid reaching pp p p Pre( Pre(pp)) Pre(Pre( Pre(Pre(pp)))) ......

EF(EF(pp))

Symbolic Model Checking[McMillan et al. LICS 90]

• Represent sets of states and the transition relation as Boolean logic formulas

• Fixpoint computation becomes formula manipulation– pre and post-condition computations: Existential variable

elimination– conjunction (intersection), disjunction (union) and

negation (set difference), and equivalence check• Use an efficient data structure

– Binary Decision Diagrams (BDDs)

Which Symbolic Representation to Use?

BDDs• canonical and efficient

representation for Boolean logic formulas

• can only encode finite sets

Linear Arithmetic Constraints• can encode infinite sets• two representations

– polyhedra– automata

• not efficient for encoding boolean domains

F

F

F

T

T

x y {(T,T), (T,F), (F,T)}

a > 0 b = a+1

{(1,2), (2,3), (3,4),...}

T

x

y

Composite Model Checking[Bultan, Gerber, League ISSTA 98, TOSEM 00]

• Map each variable type to a symbolic representation– Map boolean and enumerated types to BDD

representation– Map integer type to a linear arithmetic constraint

representation• Use a disjunctive representation to combine different

symbolic representations: composite representation• Each disjunct is a conjunction of formulas represented by

different symbolic representations– we call each disjunct a composite atom

Composite Representation

i tii

n

ipppP

...

211

symbolic rep. 1

symbolic rep. 2

symbolic rep. t

composite atom

Example:

x: integer, y: boolean

x>0 and x´x-1 and y´ or x<=0 and x´x and y´y

arithmetic constraintrepresentation

BDD arithmetic constraintrepresentation

BDD

Composite Symbolic Library [Yavuz-Kahveci, Tuncer, Bultan TACAS01], [Yavuz-Kahveci, Bultan STTT 03]

• Uses a common interface for each symbolic representation• Easy to extend with new symbolic representations• Enables polymorphic verification• Multiple symbolic representations:

– As a BDD library we use Colorado University Decision Diagram Package (CUDD) [Somenzi et al]

– For integers we use two representations• Polyhedral representation provided by the Omega

Library [Pugh et al]

• An automata representation we developed using the automata package of MONA [Klarlund et al]

Composite Symbolic Library Class Diagram

OMEGA Library

Symbolic+union()

+isSatisfiable()+isSubset()+forwardImage()

CompSym

–representation: list of comAtom

+ union() • • •

compAtom

–atom: *Symbolic

IntSymAuto

–representation: automaton

+union() • • •

IntSym

–representation: list of Polyhedra

+union() • • •

CUDD Library

BoolSym

–representation: BDD

+union() • • •

MONA

IntBoolSymAuto

–representation: automaton

+union() • • •

Pre and Post-condition Computation

Variables:x: integer, y: boolean

Transition relation:R: x>0 and x´x-1 and y´ or x<=0 and x´x and y´y

Set of states: s: x=2 and !y or x=0 and !y

Compute post(s,R)

Pre and Post-condition Distribute

R: x>0 and x´x-1 and y´ or x<=0 and x´x and yý

s: x=2 and !y or x=0 and y

post(s,R) = post(x=2 , x>0 and x´x-1) post(!y , y´) x=1 y

post(x=2 , x<=0 and x´x) post (!y , yý) false !y

post(x=0 , x>0 and x´x-1) post(y , y´) false y

post (x=0 , x<=0 and x´x) post (y, yý ) x=0 y

= x=1 and y or x=0 and y

Polymorphic Verifier

Symbolic TranSys::check(Node f) {

•

•

•

Symbolic s = check(f.child);

switch f.op {

case EX:

s.pre(transRelation);

case EF:

do

sold = s;

s.pre(transRelation);

s.union(sold);

while not sold.isEqual(s) •

•

•

}

}

Action Language Verifier is Action Language Verifier is polymorphicpolymorphic

It becomes a BDD based model It becomes a BDD based model checker when there or no integer checker when there or no integer variablesvariables

Undecidability Conservative Approximations

• Compute a lower ( p ) or an upper ( p+ ) approximation to the truth set of the property ( p ) using truncated fixpoints and widening

• Action Language Verifier can give three answers:

II pppp

1) “The property is satisfied”

II pp

3) “I don’t know”

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

II pp ppstates whichstates whichviolate the violate the propertyproperty

pp++

pp

Arbitrary Number of Instances of a Module

• We use counting abstraction to verify asynchronous composition of arbitrary number of instances of a module

• Counting abstraction– Creates an integer variable for each local state of a

module– Each variable counts the number of instances in a

particular state– Parameterized constants are used to denote the number

of instances of each module • Local variables of the module have to be finite domain

– Shared variables can be unbounded• Counting abstraction is automated

Readers-Writers 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

Variables introduced by the counting abstraction

Parameterized constants introduced by the counting abstraction

Denotes arbitrary number of instances

Airport Ground Traffic Control

flow landing

takingoff taxiing1

taxiing2parking

fly

land[in(r1.empty)]/taxii1E


Airplane[*]

empty

occupied

land/taxii1E

r1


empty

occupied

g

empty

occupied

empty

occupied

t1 r2

empty

occupied

t2

Action Language Translation of Airport Ground Traffic Control

module main()

enumerated sr1, sr2, st1, st2, sg {empty, occupied};

open boolean land, taxii1E, taxii2E, taxii2W, fly, park, takeoff;

enumerated state1, state2 {flow, landing, taxiing1, taxiing2, takingoff, parking};

initial: land and !taxii1E and !taxii2E and !taxii2W and !fly and !park and !takeoff;

module Airplane(state)

enumerated state {flow, landing, taxiing1, taxiing2, takingoff, parking};

initial: state=flow;

a1: state=flow and sr1=empty and land and state'=landing and !land' and taxii1E';

a2: state=landing and st1=empty and taxii1E and state'=taxiing1

and !taxii1E' and taxii2E';

a3: state=taxiing1 and sr2=empty and st2=empty and sg=empty and taxii2E and state'=taxiing2 and !taxii2E' and park';

. . .

Airplane: a1 | a2 | a3 | a4 | a5 | a6 | a7 ;

endmodule

module main() . . .

module Airplane(state)

. . .

endmodule

. . .

module r1()

initial: sr1=empty;

r11: sr1=empty and land and !land' and taxii1E' and sr1'=occupied;

r12: sr1=occupied and taxii1E and st1=empty and sr1'=empty and !taxii1E' and taxii2E';

r1: r11 | r12;

endmodule

. . .

main: ((Airplane(state1) | Airplane(state2)) & r1() & t1() & r2() & t2() & g() | EnvEvent()) & EventConstraint();

spec: AG(EX(true))

spec: AG(sr1=occupied and st1=occupied => AX(sr1=occupied))

spec: AG(state1=taxiing2 => state2!=taxiing2)

endmodule

Action Language Translation of Airport Ground Traffic Control

Parameterized Version of Airport Ground Traffic Control

module main()

. . .

integer taxiing2count;

restrict: taxiing2count >= 0;

initial: taxiing2count = 0;

initial: land and !taxii1E and !taxii2E and !taxii2W and !fly and !park and !takeoff;

module Airplane()

enumerated state {flow, landing, taxiing1, taxiing2, takingoff, parking};

. . .

Airplane: a1 | a2 | a3 | a4 | a5 | a6 | a7 ;

endmodule

. . .

main: (Airplane()* & r1() & t1() & r2() & t2() & g() | EnvEvent()) & EventConstraint();

spec: AG(EX(true))

spec: AG(sr1=occupied and st1=occupied => AX(sr1=occupied))

spec: AG(taxiing2count <= 1)

endmodule

Experiments

Number of Airplanes

Construction time (sec)

Verification time (sec)

Memory (MB)

2 0.08 0.02 1.68

4 0.21 0.16 4.63

8 0.56 1.08 15.75

16 1.34 3.24 39.80

32 3.25 9.69 64.45

64 10.25 26.21 124.35

P 41.32 13.85 15.15

What Happens If There Is An Error?

a3: state=taxiing1 and sr2=empty and st2=empty and sg=empty and taxii2E and state'=taxiing2 and !taxii2E' and park';

a3: state=taxiing1 and (sr2=empty or st2=empty) and sg=empty and taxii2E and state'=taxiing2 and !taxii2E' and park';

flow landing

takingoff taxiing1

taxiing2parking

taxii2E[in(r1.empty) and in(t2.empty)] /park

Airplane[*]

taxii2E[in(r1.empty) or in(t2.empty)] /park

Action Language Verifier Generates a Counter-Example

TEMPORAL PROPERTYAG(main.0.state1 = taxiing2 => main.0.state2 != taxiing2)

COUNTER-EXAMPLE

THE FORMULA

EF(!(main.0.state1 = taxiing2 => main.0.state2 != taxiing2))

IS WITNESSED BY THE FOLLOWING PATH

PATH STATE 0

!main.0.takeoff && !main.0.park && !main.0.fly && !main.0.taxii2W && !main.0.taxii2E && !main.0.taxii1E && main.0.land && main.0.sg = empty && main.0.st2 = empty && main.0.st1 = empty && main.0.sr2 = empty && main.0.sr1 = empty && main.0.state2 = flow && main.0.state1 = flow

PATH STATE 1

!main.0.takeoff && !main.0.park && !main.0.fly && !main.0.taxii2W && !main.0.taxii2E && main.0.taxii1E && !main.0.land && main.0.sg = empty && main.0.st2 = empty && main.0.st1 = empty && main.0.sr2 = empty && main.0.sr1 = occupied && main.0.state2 = flow && main.0.state1 = landing

PATH STATE 2

!main.0.takeoff && !main.0.park && !main.0.fly && !main.0.taxii2W && main.0.taxii2E && !main.0.taxii1E && !main.0.land && main.0.sg = empty && main.0.st2 = empty && main.0.st1 = occupied && main.0.sr2 = empty && main.0.sr1 = empty && main.0.state2 = flow && main.0.state1 = taxiing1

PATH STATE 3!main.0.takeoff && main.0.park && !main.0.fly && !main.0.taxii2W && !main.0.taxii2E && !

main.0.taxii1E && !main.0.land && main.0.sg = empty && main.0.st2 = occupied && main.0.st1 = empty && main.0.sr2 = empty && main.0.sr1 = empty && main.0.state2 = flow && main.0.state1 = taxiing2

PATH STATE 4!main.0.takeoff && !main.0.park && !main.0.fly && !main.0.taxii2W && !main.0.taxii2E && !

main.0.taxii1E && main.0.land && main.0.sg = empty && main.0.st2 = occupied && main.0.st1 = empty && main.0.sr2 = empty && main.0.sr1 = empty && main.0.state2 = flow && main.0.state1 = taxiing2

PATH STATE 5!main.0.takeoff && !main.0.park && !main.0.fly && !main.0.taxii2W && !main.0.taxii2E &&

main.0.taxii1E && !main.0.land && main.0.sg = empty && main.0.st2 = occupied && main.0.st1 = empty && main.0.sr2 = empty && main.0.sr1 = occupied && main.0.state2 = landing && main.0.state1 = taxiing2

PATH STATE 6!main.0.takeoff && !main.0.park && !main.0.fly && !main.0.taxii2W && main.0.taxii2E && !

main.0.taxii1E && !main.0.land && main.0.sg = empty && main.0.st2 = occupied && main.0.st1 = occupied && main.0.sr2 = empty && main.0.sr1 = empty && main.0.state2 = taxiing1 && main.0.state1 = taxiing2

PATH STATE 7!main.0.takeoff && main.0.park && !main.0.fly && !main.0.taxii2W && !main.0.taxii2E && !


THE FORMULA!(main.0.state1 = taxiing2 => main.0.state2 != taxiing2) IS SATISFIED BY THE STATE!main.0.takeoff && main.0.park && !main.0.fly && !main.0.taxii2W && !main.0.taxii2E && !


Time elapsed for transition system construction: 0.07 seconds

Time elapsed for counter-example generation: 0.11 seconds

Total heap memory used: 2314240 bytes

Related Work: 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

SMV

• [Bharadwaj, Heitmeyer 99] – Translating SCR specifications to Promela, input

language of automata-theoretic explicit state model checker SPIN

Related Work: Constraint-Based Verification

• [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

Related Work: Constraint-Based Verification

• [Boigelot and Wolper 94] – Verification with periodic sets

• [Boigelot et al.] – Meta-transitions, accelerations

• [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

Related Work: Automata-Based Representations

• [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

Related Work: Combining 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

Related Work: Tools

• LASH [Boigelot et al]

– Automata based– Experiments show it is significantly slower than ALV

• BRAIN [Rybina et al]

– Uses Hilbert’s basis as a symbolic representation– Limited functionality

• FAST [Leroux et al]

– Also implemented on top of MONA– Supports acceleration and manual strategies

• TREX [Bouajjani et al]

– Reachability analysis, timed systems, multiple domains

Verification of Parameterized Hierarchical State Machines Using Action Language Verifier Tuba...

Documents

Transcript of Verification of Parameterized Hierarchical State Machines Using Action Language Verifier Tuba...