An Introduction to UPPAAL Purandar Bhaduri Dept. of CSE IIT Guwahati Email: pbhaduri@iitg.ernet.in
OUTLINE Introduction Timed Automata UPPAAL Example: Train Gate Example: Task Scheduling
Introduction UPPAAL: a toolbox for modelling, simulating and verifying real-time systems Appropriate for systems that cab be modelled as a network of timed automata Nondeterministic finite automata Real-valued clocks Communication through channels and shared variables Applications: where time is a critical resource Real-time controllers Communication protocols
Timed Automata Resource Idle Synchronization Reset use? x = 0 InUse done! x 4 Guard Invariant x 7 Location
Timed Automata Composition Resource use? x = 0 Idle InUse x B Synchronization use! done! B=6 x B Task Init Using Done Shared Variable done? [Alur & Dill 90]
Locations in UPPAAL Normal Location Time can pass as long as the invariant is satisfied When the invariant becomes false the location must be exited Urgent Location No delay Committed Location No delay In a composition the transition out of the committed location must be exited first if more than one transition is enabled
Urgent Location No delay P: X = 0 X == 0 a? b! l1 l2 l3 l1 Q: a? b! l2 l3 X <=0 P and Q have the same behaviour. Urgent
Committed Location No delay Next transition must involve an edge in one of the processes in a committed location. P: l1 x=k read! l2 l3 n1 Committed Location l2 is committed to ensure that no automaton can modify the x before automaton Q reads x. Enables accurate modelling of atomic behaviours. Q: read? t=x n2
Synchronization Semantics in UPPAAL Used to coordinate the action of two or more processes. Transitions with the same synchronization channel are activated simultaneously Guards must be true I 1 S 1 a! a? I 2 S 2
Urgent Channel urgent chan a; Specifies synchronization that must be taken when the transition is enabled, without delay No clock guard are allowed on the edges Guards on data-variables Encode urgent transition on a variable (e.g., busy waiting on a variable) P: l X > 0 read? m d read!
Analysis: Model Checking Can check for invariant and reachability properties Whether certain combinations of locations and constraints on variables (clock and integer) are reachable Bounded liveness Monitor automata Adding debugging information and checking reachability Generates diagnostic trace
Temporal Logic: TCTL E - exists a path ( E in UPPAAL). A - for all paths ( A in UPPAAL). G - all states in a path ( [] in UPPAAL). F - some state in a path ( <> in UPPAAL). Queries in UPPAAL A[]p, A<>p, E<>p, E[]p and p q AG p AF p EF p EG p p Validation Property Possibly: E<>p p Propositions p and q are local properties atomic clock/data constraints: integer bounds on clock variables Component location
TCTL Quantifiers in UPPAAL E - exists a path ( E in UPPAAL). A - for all paths ( A in UPPAAL). G - all states in a path ( [] in UPPAAL). F - some state in a path ( <> in UPPAAL). Queries in UPPAAL A[]p, A<>p, E<>p, E[]p and p q Safety Properties Invariant: A[]p Possibly Invariant: E[]p p p p AG p AF p EF p EG p p and q are local properties p p p p p
TCTL Quantifiers in UPPAAL E - exists a path ( E in UPPAAL). A - for all paths ( A in UPPAAL). G - all states in a path ( [] in UPPAAL). F - some state in a path ( <> in UPPAAL). Queries in UPPAAL A[]p, A<>p, E<>p, E[]p and p q Safety Properties Invariant: A[]p Possibly Invariant: E[]p p p AG p AF p EF p EG p p and q are local properties p p
TCTL Quantifiers in UPPAAL Liveness Properties E - exists a path ( E in UPPAAL). A - for all paths ( A in UPPAAL). G - all states in a path ( [] in UPPAAL). F - some state in a path ( <> in UPPAAL). Queries in UPPAAL A[]p, A<>p, E<>p, E[]p and p q Always Eventually: A<>p Always Leads to (p- ->q): A<>[p -> A<>q] AG p AF p EF p EG p p and q are local properties p p p p
TCTL Quantifiers in UPPAAL E - exists a path ( E in UPPAAL). A - for all paths ( A in UPPAAL). G - all states in a path ( [] in UPPAAL). F - some state in a path ( <> in UPPAAL). q Queries in UPPAAL A[]p, A<>p, E<>p, E[]p and p q Liveness Properties Eventually: A<>p Always Leads to (p- ->q): p A[][p -> A<>q] p AG p AF p EF p EG p q q q p and q are local properties q
TCTL Examples A deadlock never occurs A[] not deadlock An automaton A2 may never enter a location q E[] not A2.q There exists a reachable state from which φ always holds E<>A[] φ Infinitely often φ A[]A<> φ Always φ is possible A[]E<> φ
Example: Train Gate Two components: train, gate controller Trains running on separate tracks cross a common bridge Initially, trains are far enough from the bridge (location safe) When trains approach the bridge the gate controller is notified 20 time units before the train reaches the bridge(location approaching) A train can be stopped within 10 time units; otherwise it must cross the bridge. Gate controller can stop a train and restart it If train is stopped (location stop) then it will be eventually restarted (location start) again and it takes 7-15 time unit to reach the bridge. A train takes 3-5 time units to cross the bridge (location cross) After crossing, a train will go to its safe state again and notify the gate controller. Safety Property: Only one train at a time has access to the bridge. [Kim Larsen: ARTIST Summer School 2009 slides + Uppaal distribution]
Example: Train Gate Safe Approaching Crossing Safe Stoppable Area 7-5 Train is stoppable Train must proceed 0 10 20 3-5 Time
Example: Train Gate Global declaration const int N = 6; // no of trains typedef int [0,N-1] id_t; //used as argument for the template of trains Chan appr[n], stop[n], leave[n]; urgent chan go[n]; Local declaration (Train) clock x; Local declaration (Gate) typedef struct { id_t list[n]; int [0,N] len; } queue_t; queue_t q;
Example: Train Gate Safe leave[id]! x 3 Cross x 5 Free appr[id]! x = 0 x 10 x=0 x 7 x=0 q.len > 0 go[front()]! Occ e: id_t q.len == 0 appr[e]? enqueue(e) e: id_t e == front() leave[e]? dequeue() Appr x 20 x 10 stop[id]? go[id]? x=0 Start x 15 e: id_t appr[e]? enqueue(e) stop[tail]! Stop C Template for the trains The train template has the argument const id_t id that defines its identifier Template for the gate e: id_t to unfold the corresponding edge with e ranging over the type id_t
Example: Train Gate Verification E<>Train1.Cross E<> Train1.Cross and Train2.Stop Safety Properties A[] Train1.Cross+Train2.Cross +Train3.Cross +Train4.Cross<=1 Liveness Properties Train1.Appr --> Train1.Cross System is deadlock free A[] not deadlock
Example: Task Scheduling T 1 Ready Done Scheduler E[i] Earliest arrival for T i T 2 L[i] Latest arrival for T i 2 3 1 4 T 3 C[i] Execution time for T i T n Stop Run T 2 is running { T 3, T 1, T 4 } ready ordered according to some given priority (e.g. Fixed Priority, Earliest Deadlines, ) D[i] Deadline for T i Kim G. Larsen, Timing and Performance Analysis of Embedded Systems Using Model Checking, JTRES 2011
Modeling Task Idle T 1 T 2 T 3 Ready Done Scheduler 2 3 1 4 head()==id && ax == C[id] done! dequeue() Ready t <= L[id] t >= E[id] ready! t = 0, enqueue(id) t >= D[id] T n Stop Run Running C head()==id run? ax = 0 ax <= C[id] t >= D[id] Error
Modeling Scheduler T 1 T 2 Ready Done Scheduler 2 3 1 4!isEmpty() isempty() Init C initialize() C Free T 3 T n Stop Run ready? Select C run! done? Occu
References 1. UPPAAL. http://www.uppaal.com. 2. Timed Automata: Semantics, Algorithms and Tools, Bengtsson, Johan, and Wang Yi. Advanced Course on Petri Nets. Springer, Berlin, Heidelberg, 2003. 3. A Tutorial on Uppaal, Behrmann, Gerd, Alexandre David, and Kim Larsen. Formal methods for the design of real-time systems (2004): 33-35. 4. Uppaal in a Nutshell, Larsen, Kim G., Paul Pettersson, and Wang Yi. International Journal on Software Tools for Technology Transfer (STTT) 1.1 (1997): 134-152.