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: //

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 r1Runway r2 Taxiway t1Taxiway 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 flowlanding takingofftaxiing1 taxiing2parking fly land[in(r1.empty)]/taxii1E taxii1E[in(t1.empty)] /taxii2E Airplane[*] empty occupied land/ taxii1E r1 taxii1E [in(t1.empty)] /taxii2E empty occupied g empty occupied empty occupied t1r2 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 : Cartesian product of variable domains defines variable domains defines the set of states the set of states I : Predicates defining the initial states the initial states R : Atomic actions of the Reader 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

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 Alarm Shut Op On Off 1 2 ModeVol t1 t2 t3 t4 t5t6t7 Preserves the structure of the Statecharts specification

Action Language Verifier [Bultan, Yavuz-Kahveci ASE01], [Yavuz-Kahveci, Bar, Bultan CAV05] Action Language Parser Model Checker OmegaLibraryCUDDPackage MONA Composite Symbolic Library PresburgerArithmeticManipulatorBDDManipulatorAutomataManipulator Action Language Specification Counter-exampleVerified I don’t know

Temporal Properties  Fixpoints [Emerson and Clarke 80] pppp Initialstates initial states that satisfy EF(  p) initial states that violate AG(p)  initial states that violate AG(p) EF(  p)states that can reach  p  p Pre(  p) Pre(Pre(  p))... EF(  p)  states that can reach  p   p  Pre(  p)  Pre(Pre(  p)) ... EG(  p) Initialstates initial states that satisfy EG(  p) initial states that violate AF(p)  initial states that violate AF(p) EG(  p) states that can avoid reaching p  p Pre(  p) Pre(Pre(  p))... EG(  p)  states that can avoid reaching p   p  Pre(  p)  Pre(Pre(  p)) ... EF(  p)

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 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 constraint representation BDD arithmetic constraint representation 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´  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´  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´  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 polymorphic  It becomes a BDD based model checker when there or no integer variables

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: I p pppp 1) “The property is satisfied” I p 3) “I don’t know” 2) “The property is false and here is a counter-example” I p  p p p p states which violate the property p+p+p+p+ pppp

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; endmodule module Writer()... endmodule main: 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 flowlanding takingofftaxiing1 taxiing2parking fly land[in(r1.empty)]/taxii1E taxii1E[in(t1.empty)] /taxii2E Airplane[*] empty occupied land/ taxii1E r1 taxii1E [in(t1.empty)] /taxii2E empty occupied g empty occupied empty occupied t1r2 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) P

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'; flowlanding takingofftaxiing1 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 PROPERTY AG(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 && !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 = taxiing2 && main.0.state1 = taxiing2 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 && !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 = taxiing2 && main.0.state1 = taxiing2

Time elapsed for transition system construction: 0.07 seconds Time elapsed for counter-example generation: 0.11 seconds Total heap memory used: 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