Transcript Chapter 1 -- Introduction

CSE 522
UPPAAL – A Model Checking Tool
Computer Science & Engineering Department
Arizona State University
Tempe, AZ 85287
Dr. Yann-Hang Lee
[email protected]
(480) 727-7507
UPPAAL -- Introduction
 A tool for modeling, simulation and verification of real-
time systems.
 Appropriate for systems that can be modeled as
 a collection of non-deterministic processes with finite control
structure and real-valued clocks (i.e. timed automata)
 Networks of timed automata
 communicate through channels and shared data structures.
 Modeling language
 channels, and locations
 constants, data-variables (with bounded domains) and arrays
 guards and assignments
 templates with local clocks, data-variables, and constants
 C subset
2
Tool Overview
 System Editor
 Draw Automata: locations, edges, etc.
 Declare global and local constant, variables, and functions
 Create instances of system and processes
 Simulator
 Traces (state transitions): next, prev, replay, open, save,
random
 Message sequences
 Verifier
 A<> p : p will inevitable become true, the automaton is
guaranteed to eventually reach a state in which p is true.
3
Example: Fischer’s Protocol (1)
 A well-known mutual exclusion protocol
 a timed protocol where the concurrent processes check for both
a delay and their turn to enter the critical section using a shared
variable id.
 Protocol
 Starting from the initial location
 processes go to a request location, req, if id==0, which checks
that it is the turn for no process to enter the critical section.
 stay non-deterministically between 0 and k time units in req,
 go to the wait location and set id to their pid
 wait at least k time units, before entering the critical section CS if
it is its turn, i.e. id==pid.
4
Example: Fischer’s Protocol (2)
 id – shared variable, initialized 0
 each process has it’s own timer (for delaying)
Process i:
while (true) {
<noncritical section>;
while id != -1 do {}
id := i;
delay K;
if (id = i) {
<critical section>;
id := -1;
}
}
5
Example: Fischer’s Protocol
6
Locations
 Locations: to define the state of automaton.
 System state is defined by the locations of all automata, the clock
values, and the values of the discrete variables.
 Initial Locations
 The beginning of the process. Each template must have exactly
one initial location.
 Urgent Locations
 Urgent locations freeze time. This forces the actual process to
always make a transition without any delay.
 Committed Locations
 A committed state cannot delay and the next transition must
involve an outgoing edge of at least one of the committed
locations.
7
Locations and Edges
 Invariant, selection, guard, update, synchronization
n: int[0,5]
a!
8
Channels in Uppaal
 Used to synchronize two processes.
 binary synchronization and blocking
 an edge with synchronization label e! emits a signal on the
channel e and that the enabled edge with synchronization
label e? will synchronize with the emitting process.
 Urgent Channels
 synchronization via that channel has priority over normal
channels and the transition must be taken without delay.
 No clock guard allowed on edges using urgent channels.
 Broadcast channel
 allows 1-to-many synchronization.
 sender is not blocked if there is no receiver.
9
Declaration in Uppaal
 Integer
 int num1, num2;
// integer variables with default domain.
 int a[2][3];
// a multidimensional integer array.
 int[0,5] b=0;
// with the range 0 to 5 initialized to 0.
 Boolean
 bool yes = true;
//a boolean variable “yes initialize to true.
 bool b[8], c[4];
// two boolean arrays b and c, with 8 and 4 elements
 Const
 const int a = 1;
// constant “a” with value 1 of type integer.
 const bool No = false;
//constant “No” with value false
 Clock
 clock x, y; //two clocks x and y.
 Channel
 chan d;
// a channel.
 urgent chan a, b ,c; //urgent channel.
10
Verifying Properties (1)
 E<> p: there exists a path where p eventually holds.
 A[] p: for all paths p always holds.
 E[] p: there exists a path where p always holds.
 A<> p: for all paths p will eventually hold.
 p --> q: whenever p holds q will eventually hold.
Name
Possibly
Invariantly
Property
E<> p
A[] p
Equivalent to
Potentially always
E[] p
Eventually
A<> p
not E[] not p
Leads to
p --> q
A[] (p imply A<> q)
not E<> not p
p is reachable
p is always truth
p is inevitable
whenever p holds
eventually q will hold
11
Verifying Properties (2)
A[]
E<> 
A<> 
E[ ] 

12
Verifying Properties (3)
 Deadlock (state formula)
 A state is a deadlock state if there are no outgoing action transitions
neither from the state itself or any of its delay successors.
 Reachability
 whether there exists a path starting at the initial state, such that a
state formula is eventually satisfied (e.g. is it possible for a sender to
send a message?)
 Safety
 Something bad will never happen! (e.g. the temperature of the
engine is always (invariantly) under a certain threshold)
 (something good is invariantly true)
 Liveness
 Something good will eventually happen! (e.g. when pressing the on
button, then eventually the television should turn on)
13
System Model in Uppaal
 System:
 a list of processes to define a network of timed automata, i.e.
concurrent processes.
 global declaration
 Process:
 instantiated from a parameterized template.
 Template: definition of a timed automaton
 can be parameterized, e.g., automata for 4 tasks
 have local declarations of variables, channels, and constants
 templates without parameters are instantiated into exactly one
process
 At a given time-point, transitions are enabled in the order
of the process priorities.
14
Additional Features in Uppaal
 Priority
chan priority a < b, c;
system P < Q, R;
 At a given time-point, local and synchronization transitions are
enabled in the order of process and channel priorities.
 User defined functions
 C/C++/Java style
 no recursive call, evaluated atomically and must be deterministic
 compiled to byte-code, and executed at verification time on a
small embedded stack machine.
15
Example: Train Crossing (1)
Stopable
Area
[3,5]
[10,20]
Crossing
[7,15]
Queue
Gate
River
16
Example: Train Crossing (2)
 A railway control system which controls access to a bridge for
several trains.
 The bridge is a critical shared resource that may be accessed
only by one train at a time.
 A train can not be stopped instantly and restarting also takes
time.
 When approaching, a train sends an appr! signal. Thereafter, it has 10
time units to receive a stop signal. This allows it to stop safely before the
bridge.
 After these 10 time units, it takes further 10 time units to reach the
bridge if the train is not stopped.
 If a train is stopped, it resumes its course when the controller sends a
go! signal to it after a previous train has left the bridge and sent a leave!
signal.
17
Example: Train Crossing (3)
 channels for “appr”, “stop”, “go”, and “leave”
 Queries
 A[] forall (i : id_t) forall (j : id_t) trains(i).Cross && trains(j).Cross imply i == j
 trains(1).Appr --> trains(1).Cross
18
Example: Train Crossing (4)
Train automata
Gate automata
19
Labels in Edges (1)
 Edges are annotated with guards, updates, synchronizations
and selections
 A guard is an expression which uses the variables and clocks
of the model in order to indicate when the transition is enabled,
i.e. may be fired.
 Note that several edges may be enabled at an specific time but
only one of them will be fired
 An update is an expression that is evaluated as soon as the
corresponding edge is fired.
 Selections non-deterministically bind a given identifier to a
value in a given range.
 The other three labels of an edge are within the scope of this binding.
(http://dmi.uib.es/~jproenza/SistEncTR/TheUppaalModelCheckerNEW.pdf)
20
Labels in Edges (2)
 Synchronization: the basic mechanism used to coordinate the
action of two or more processes.
 models for instance the effect of messages causes two (or more)
processes to take a transition at the same time.
 Regular channel
 fired between the processes paired with c! and c? for a channel c
and when the guards of the edges are satisfied.
 if there are several possible ways to have a pair c! and c?, one of
them is non-deterministically chosen.
 The update expression on an edge synchronizing on c! is
executed first
21
Committed Locations
 Committed locations
 useful for creating atomic sequences
 a committed state cannot delay and the next transition must
involve an outgoing edge of at least one of the committed
locations
 if any process is in a committed location, the next transition must
involve an edge from one of the committed locations
 if several processes are in a committed location at the same
time, then they will interleave.
a! and b! are atomic
22
Delay Transition and Invariants (1)
 Delay transitions model the passing of time without changing
the current location.
 a delay transition (L, v) --(d)--> (L, v'), where d is a non-negative
real, if and only if:
 v' = v + d, where v+d is obtained by incrementing all clocks
with d.
 for all 0 <= d' <= d: v + d' satisfies Inv(L)
 L contains neither committed nor urgent locations
 no enabled edge with urgent synchronization
When will the reset synchronization happen?
23
Delay Transition and Invariants (2)
24
Delay Transition and Invariants (3)
25