Verification of Parameterized Hierarchical State Machines Using Action Language Verifier - PowerPoint PPT Presentation

About This Presentation
Title:

Verification of Parameterized Hierarchical State Machines Using Action Language Verifier

Description:

... 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 ... – PowerPoint PPT presentation

Number of Views:55
Avg rating:3.0/5.0
Slides: 42
Provided by: ValuedSony
Category:

less

Transcript and Presenter's Notes

Title: Verification of Parameterized Hierarchical State Machines Using Action Language Verifier


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
landin(r1.empty)/taxii1E
taxii1E in(t1.empty) /taxii2E
land/ taxii1E
flow
landing
occupied
taxii1Ein(t1.empty) /taxii2E
occupied
occupied
fly
takingoff
taxiing1
g
t2
empty
empty
taxiing2
parking
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
Readers Writers Example
S Cartesian product of variable domains
defines the set of states
  • module main()
  • integer nr
  • boolean busy
  • restrict nrgt0
  • initial nr0 and !busy
  • module Reader()
  • boolean reading
  • initial !reading
  • rEnter !reading and !busy and
  • nrnr1 and reading
  • rExit reading and !reading and nrnr-1
  • Reader rEnter rExit
  • endmodule
  • module Writer()
  • ...
  • endmodule

I Predicates defining the initial states
R Atomic actions of the Reader
R Transition relation of Reader defined as
asynchronous composition of its atomic actions
R Transition relation of main defined as
asynchronous composition of two Reader and two
Writer processes
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 AlarmShut and ModeOff and Vol1
  • t1 AlarmShut and AlarmOp and ModeOn and
    Vol1
  • t2 AlarmShut and AlarmOp and ModeOff and
    Vol1
  • t3 AlarmOp and AlarmShut
  • t4 AlarmOp and ModeOn and ModeOff
  • t5 AlarmOp and ModeOff and ModeOn
  • ...
  • main t1 t2 t3
  • (t4 t5) (t6 t7)
  • endmodule

Alarm
Shut
t1
t2
Op
t3
Mode
Vol
On
1
t4
t5
t6
t7
Off
2
Preserves the structure of the Statecharts
specification
13
Action Language VerifierBultan, 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 dont 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 CheckingMcMillan 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
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

x ? y ? (T,T), (T,F), (F,T)
x
F
a gt 0 ? b a1

T
y
? (1,2), (2,3), (3,4),...
F
T
F
T
17
Composite Model CheckingBultan, 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 xgt0 and x?x-1
and y or xlt0 and x?x and y?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
Symbolic
  • union()
  • isSatisfiable()
  • isSubset()
  • forwardImage()

OMEGA Library
CUDD Library
MONA
21
Pre and Post-condition Computation
  • Variables
  • x integer, y boolean
  • Transition relation
  • R xgt0 and x?x-1 and y or xlt0 and x?x and
    y?y
  • Set of states
  • s x2 and !y or x0 and !y
  • Compute post(s,R)

22
Pre and Post-condition Distribute
  • R xgt0 and x?x-1 and y or xlt0 and x?x and
    y?y
  • s x2 and !y or x0 and y
  • post(s,R) post(x2 , xgt0 and x?x-1) ? post(!y
    , y)
  • x1 y
  • post(x2 , xlt0 and x?x) ? post (!y , y?y)
  • false
    !y
  • post(x0 , xgt0 and x?x-1) ? post(y , y)
  • false
    y
  • post (x0 , xlt0 and x?x) ? post (y, y?y )
  • x0
    y
  • x1 and y or x0 and y

23
Polymorphic Verifier
  • Symbolic TranSyscheck(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

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 dont 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
Readers-Writers After Counting Abstraction
Parameterized constants introduced by the
counting abstraction
  • module main()
  • integer nr
  • boolean busy
  • parameterized integer numReader, numWriter
  • restrict nrgt0 and numReadergt0 and
    numWritergt0
  • initial nr0 and !busy
  • module Reader()
  • integer readingF, readingT
  • initial readingFnumReader and readingT0
  • rEnter readingFgt0 and !busy and
  • nrnr1 and readingFreadingF-1 and
  • readingTreadingT1
  • rExit readingTgt0 and nrnr-1
    readingTreadingT-1 and
    readingFreadingF1
  • Reader rEnter rExit
  • endmodule
  • module Writer()
  • ...
  • endmodule
  • main Reader() Writer()

Variables introduced by the counting abstraction
Denotes arbitrary number of instances
27
Airport Ground Traffic Control
Airplane
t1
r2
r1
empty
empty
empty
landin(r1.empty)/taxii1E
taxii1E in(t1.empty) /taxii2E
land/ taxii1E
flow
landing
occupied
taxii1Ein(t1.empty) /taxii2E
occupied
occupied
fly
takingoff
taxiing1
g
t2
empty
empty
taxiing2
parking
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
stateflow a1 stateflow and sr1empty
and land and state'landing and !land' and
taxii1E' a2 statelanding and st1empty and
taxii1E and state'taxiing1 and !taxii1E'
and taxii2E' a3 statetaxiing1 and sr2empty
and st2empty and sgempty 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
sr1empty r11 sr1empty and land and !land'
and taxii1E' and sr1'occupied r12
sr1occupied and taxii1E and st1empty 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(sr1occupied and st1occupied gt
AX(sr1occupied)) spec AG(state1taxiing2 gt
state2!taxiing2) endmodule
30
Parameterized Version of Airport Ground Traffic
Control
module main() . . . integer taxiing2count
restrict taxiing2count gt 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(sr1occupied and
st1occupied gt AX(sr1occupied)) spec
AG(taxiing2count lt 1) endmodule
31
Experiments
32
What Happens If There Is An Error?
  • a3 statetaxiing1 and sr2empty and st2empty
    and sgempty and taxii2E and state'taxiing2
    and !taxii2E' and park'
  • a3 statetaxiing1 and (sr2empty or st2empty)
    and sgempty and taxii2E and state'taxiing2 and
    !taxii2E' and park'

Airplane
flow
landing
takingoff
taxiing1
taxii2Ein(r1.empty) and in(t2.empty) /park
taxiing2
parking
taxii2Ein(r1.empty) or in(t2.empty) /park
33
Action Language Verifier Generates a
Counter-Example
  • TEMPORAL PROPERTY
  • AG(main.0.state1 taxiing2 gt main.0.state2 !
    taxiing2)
  • COUNTER-EXAMPLE
  • THE FORMULA
  • EF(!(main.0.state1 taxiing2 gt 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 gt 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. CAV97
  • both linear and non-linear constraints are mapped
    to BDDs
  • Only data-memoryless and data-invariant
    transitions are supported
  • Bharadwaj and Sims TACAS00
  • Combines automata based representations (for
    linear arithmetic constraints) with BDDs
  • Specialized for inductive invariant checking
  • Bensalem et al. 00
  • Symbolic Analysis Laboratory
  • Designed a specification language that allows
    integration of different verification tools

41
Related Work Tools
  • LASH Boigelot et al
  • Automata based
  • Experiments show it is significantly slower than
    ALV
  • BRAIN Rybina et al
  • Uses Hilberts 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
Write a Comment
User Comments (0)
About PowerShow.com