Geen diatitel

Document Sample
Geen diatitel Powered By Docstoc
					Review of
Timed Automata:
Semantics, Algorithms and Tools
   Hermen Toersche (CS)



                                  1
     What are timed automata?
• Finite automata (as in Basismodellen)
• Extended with a set of “clocks”:
  – Initial value zero
  – All clocks increase synchronously
    and continuously (i.e. over R+)
  – Clock guards on transitions (edges)
  – Transitions may reset (a subset of) clocks


                                                 2
                               Example
                               • Locations: start, loop, end
Clock guard:
Transition label:
Clock reset:
                               • Clocks: x, y




                    • Which behaviours are accepted?
                                                       3
            Acceptance (1)
• Originally: Timed Büchi Automata
  – Mark a subset of locations as accepting
  – Only behaviours that visit accepting
    locations infinitely often are valid
  – Imposes clock conditions (“invariants”)
    on locations




                                              4
Acceptance (1) - continued
           • Location invariants
             due to Büchi
             acceptance condition:
             – start: y <= 20
             – loop: y <= 50
             – end: y <= 20




                                 5
             Acceptance (2)
• Alternative: Timed Safety Automata
  – Use location invariants instead of
    Büchi acceptance
  – Behaviours that satisfy all constraints
    are considered valid
• For the rest of the paper,
  this definition is used.


                                              6
    Acceptance (2) - continued
Büchi criterion:                   Location invariants:




                         
                      Same “language”




       Guard y<=50 is not necessary anymore!
                                                    7
                Premises
• Clock guards are of the forms:
  –x~n         (clock constraint)
  –x-y~n       (difference constraint)
• n  N (only discrete values)
• Allowed comparisons: ~  <, <=, ==, >=, >
• Verification tools: location invariants must
  be downward closed (i.e. only <, <=, ==)

                                           8
                 Formal syntax
• Timed automaton A: tuple N, l0, E, I
  – N is a finite set of locations (nodes)
  – lo is the initial location
  – E  N  B(C)    2C  N is the set of edges
      (from, constraint, action, resets, to)

  – I : N -> B(C) assigns invariants to locations
  – B(C) is the set of clock constraints


                                                9
        Operational semantics
• Two types of state transitions:
  – Delay transition:
     • increment all clocks by d  R+
  – Action transition ( E):
     • change the location
     • reset the clocks in “2C”
     • all clocks not in “2C” retain their value



                                                   10
                 Timed language
• Timed action: t, a
   – t  R+ is the time-stamp of action a  
• Timed trace : t1, a1 t2, a2…
   – Sequence of transitions (possibly infinite)
     with ti <= ti+1
• There are no additional limits (yet) on t and a!




                                                     11
    Timed language - continued
• A run of a timed automaton with initial
  state l0, u0 over a timed trace :

  satisfying ti = ti-1 + di for i >= 1

• Timed language L(A):
  all timed traces for which there exists a
  run of A over 
                                              12
        Reachability analysis
• l, u is reachable if in the language
  there exists a run which visits l, u
• Given a constraint   B(C), l,  is
  reachable if there exists a reachable
  state l, u with u satisfying .
• Very powerful!
  – Invariants (the opposite is not reachable)
  – Bounded liveness (something good must
    happen within n time units)
                                                 13
         Symbolic semantics
• Problems with the operational semantics:
  – There are infinitely many real delay steps
  – Clocks may be unbounded
• Solutions:
  – Equivalence classes
  – Clock ceiling



                                                 14
      Equivalence classes (1)
• Because clock guards and invariants
  only have constraints with n  N,
  regions of equivalence may be defined
• Region automaton: express transitions
  in terms of regions
• Number of classes exponential in the
  number of processes and maximal
  constants appearing in guards!
                                          15
Equivalence classes (1) - continued
• Regions: every corner, line segment and
  open area (in this small example: 60)




               x - y = 0, 0 < x < 1

                                       16
      Equivalence classes (2)
• More efficient:
  use zones instead of regions



             

                                 17
Equivalence classes (2) - continued
• Zones are (conjuncted) clock constraints
• Can be efficiently stored using
  Difference Bound Matrices
  (more on this later)
• B(C) denotes the set of zones




                                        18
             Clock ceiling
• Clocks may be unbounded
• Solution: the value of the clock
  assignment does not matter when it
  gets above the maximal clock constant
  of the automaton. It only matters that
  the clock assignment is above the
  maximal clock constant


                                           19
        Clock ceiling: regions
• Above k(y), stop creating regions for
  specific values of y
                              2<x<3^y>2




                                          20
       Clock ceiling: zones (1)
• For zones, applying a clock ceiling k is
  called k-normalization:
  – Remove all constraints of the form
    x < m, x <= m where m >= k(x)
  – Replace all constraints of the form
    x > m, x >= m with x > k(x)
• This only works for diagonal-free
  automata (i.e. no difference bounds)

                                             21
       Clock ceiling: zones (2)
• In the presence of difference
  constraints,
  k-normalization may incorrectly
  conclude reachability of states
  – k,G-normalization which cuts the correct
    normalization out of a k-normalization
    using the set of difference constraints G



                                                22
      Reachability analysis (1)
• Model-checking for safety properties
  using reachability analysis:
  – Traverse the state space, and see if the
    property holds somewhere
  – State space may be computed beforehand
    or on-the-fly (latter is usually preferred)
  – Entire state space must be generated to
    prove invariants

                                              23
                       Reachability analysis (2)
        • In pseudocode:

                                           D is a zone ( B(C))

property check
if (!already visited)
mark as visited
for each possible transition




property does not hold

                                                            24
      Reachability analysis (3)
• The size of Passed (the reached states)
  puts a limit on the size of systems that
  can be verified. Increase limit with:
  – State compression
  – State-space reduction
  – Approximate techniques




                                         25
  Difference Bound Matrices (1)
• A way to represent zones
  (clock constraints):
  – Define a constant reference clock 0 = 0
  – Rewrite x ~ n to x - 0 ~ n
  – Rewrite DB(C) to x - y < n or x - y <= n
     • x - y > 10 becomes y - x < -10
     • x - 0 = 5 becomes x-0 <= 5 and 0-x <= -5
  – Store these in a a |C0|  |C0| matrix of
    (n, ~)-pairs              (C0 = C  {0})
                                                  26
Difference Bound Matrices (2)


         0     x      y    z

    0
    x
    y
    z



                                27
          Canonical DBM (1)
• For each zone family there is a unique
  constraint where no atomic constraint
  can be strengthened without losing
  solutions
  – Find these using a shortest path algorithm
    (e.g. Floyd-Warshall) => O(n3)
  – Calculating it is expensive, so common
    operations should retain canonicity
• Canonicity reduces the state space!
                                                 28
         Canonical DBM (2)
• Example:
  x - 0 < 20
  can be strengthened to
  x - 0 <= 10
  using
  y - 0 <= 20 and
  x - y <= -10


                             29
Property-checking DBM operations
• Consistency: are there any solutions?
  (valid clock assignments)
• Inclusion:    is zone D  D‟?
• Satisfaction: does a zone D satisfy ?
  – i.e. is D   consistent?


• These properties can be checked easily
  on canonical DBMs
                                           30
       DBM transformations
• up(D):
  – All clock assignments that can be
    reached by delay
• down(D):
  – All clock assignments that can
    reach D by delay
• and(D, xi-yj ~ b):
  – Add a constraint to D
• ..and so on. Canonicity should be retained!
                                        31
              Storing DBMs
• Memory organization: row-wise mapping
  unless clocks may be added dynamically
• Visited state table: store sparse states
  – Minimize the number of constraints
    (by removing redundant ones)
    and store them as (x, y : n, ~) instead of (n, ~)
    (i.e. with clock indices)
  – Only gain if at least half of the
    constraints is redundant
                                                 32
                 UPPAAL
• Tool for modeling, simulation and
  verification of (networks of) timed automata
• “Everything” + useful extensions
  – Shared integer variables, urgent channels,
    committed locations, composition




                                             33
   Networks of timed automata
• UPPAAL supports the CCS parallel
  composition operator:
  – Product automaton with handshake
    synchronization on channel? / channel!
    pairs (SPIN) or internal actions (FMSE)




                                              34
Networks of automata - continued




        ||        =
• Product automaton doesn‟t need to be
  constructed explicitly
                                         35
                                   Verification with UPPAAL
                      • Define properties in TCTL:
bounded liveness)




                                – A[]    invariantly 
                    most used
   (safety &




                                   •  holds everywhere in all runs
                                – E<> possibly 
                                   •  holds somewhere in some run
                                – A<> always eventually 
                                   •  holds everywhere in some run
                                – E[]    potentially always 
                                   •  holds somewhere in all runs : predicates on clock
                                                                        constraints, locations,
                                –  -->  A[] ( => A<>)               integer variables
                                                                                      36
           Application areas
• Where bounded liveness
  (instead of „eventually‟) is necessary:
  – Networking
     • Multimedia: QoS guarantees
     • Safety critical systems
  – Mutual exclusion protocols




                                            37
Questions?




             38

				
DOCUMENT INFO