1 / 41

Verification of Parameterized Hierarchical State Machines Using Action Language Verifier

Verification of Parameterized Hierarchical State Machines Using Action Language Verifier. Tuba Yavuz-Kahveci Tevfik Bultan University of Florida, Gainesville University of California, Santa Barbara

tobit
Télécharger la présentation

Verification of Parameterized Hierarchical State Machines Using Action Language Verifier

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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/

  2. 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

  3. Example: Airport Ground Traffic Control Taxiway t1 Taxiway t2 Gate g Runway r1 Runway r2

  4. 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

  5. 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

  6. Airport Ground Traffic Control Airplane[*] t1 r2 r1 empty empty empty land[in(r1.empty)]/taxii1E taxii1E [in(t1.empty)] /taxii2E land/ taxii1E flow landing occupied taxii1E[in(t1.empty)] /taxii2E occupied occupied fly takingoff taxiing1 t2 g empty empty parking taxiing2 occupied occupied

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

  8. 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

  9. 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

  10. 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 Readers Writers Example S :Cartesian product of variable domains defines the set of states 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

  11. 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

  12. 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 t1 t2 Op t3 Mode Vol On 1 t4 t5 t6 t7 Off 2 Preserves the structure of the Statecharts specification

  13. Action Language Verifier[Bultan, Yavuz-Kahveci ASE01],[Yavuz-Kahveci, Bar, Bultan CAV05] Action Language Specification Action Language Parser Composite Symbolic Library Model Checker Omega Library CUDD Package MONA Counter-example Verified Presburger Arithmetic Manipulator BDD Manipulator Automata Manipulator I don’t know

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

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

  16. 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 Which Symbolic Representation to Use? x  y  {(T,T), (T,F), (F,T)} x F a > 0  b = a+1 T y  {(1,2), (2,3), (3,4),...} F T F T

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

  18. Composite Representation composite atom symbolic rep. 1 symbolic rep. 2 symbolic rep. t Example: x: integer, y: boolean x>0 and x´x-1andy´orx<=0 and x´xandy´y arithmetic constraint representation arithmetic constraint representation BDD BDD

  19. 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]

  20. Composite Symbolic Library Class Diagram IntBoolSymAuto IntSymAuto BoolSym IntSym CompSym –representation: BDD –representation: automaton –representation: automaton –representation: list of Polyhedra –representation: list of comAtom +union() • • • +union() • • • +union() • • • +union() • • • + union() • • • compAtom –atom: *Symbolic Symbolic +union() +isSatisfiable() +isSubset() +forwardImage() MONA CUDD Library OMEGA Library

  21. Pre and Post-condition Computation Variables: x: integer, y: boolean Transition relation: R:x>0 and x´x-1andy´orx<=0 and x´xandy´y Set of states: s:x=2and!yorx=0and!y Compute post(s,R)

  22. Pre and Post-condition Distribute R:x>0 and x´x-1andy´orx<=0 and x´xandy´y s:x=2and!yorx=0andy 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´) falsey • post (x=0 , x<=0 and x´x)  post (y, y´y ) x=0y =x=1andy orx=0andy

  23. Polymorphic Verifier SymbolicTranSys::check(Nodef) { • • • Symbolics = check(f.child); switchf.op { caseEX: s.pre(transRelation); caseEF: 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

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

  25. 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

  26. 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 Readers-Writers After Counting Abstraction Parameterized constants introduced by the counting abstraction Variables introduced by the counting abstraction Denotes arbitrary number of instances

  27. Airport Ground Traffic Control Airplane[*] t1 r2 r1 empty empty empty land[in(r1.empty)]/taxii1E taxii1E [in(t1.empty)] /taxii2E land/ taxii1E flow landing occupied taxii1E[in(t1.empty)] /taxii2E occupied occupied fly takingoff taxiing1 t2 g empty empty parking taxiing2 occupied occupied

  28. 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

  29. Action Language Translation of Airport Ground Traffic Control 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

  30. 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

  31. Experiments

  32. 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'; Airplane[*] flow landing takingoff taxiing1 taxii2E[in(r1.empty) and in(t2.empty)] /park parking taxiing2 taxii2E[in(r1.empty) or in(t2.empty)] /park

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

  34. 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

  35. Time elapsed for transition system construction: 0.07 seconds Time elapsed for counter-example generation: 0.11 seconds Total heap memory used: 2314240 bytes

  36. 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

  37. 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

  38. 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

  39. 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

  40. 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

  41. 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

More Related