Transcript Presentazione di PowerPoint

The Model Checker SPIN
The model checker SPIN
1
SPIN & Promela
• SPIN(=Simple Promela Interpreter)
– tool for analyzing the logical consistency of concurrent
systems
– concurrent systems are described in the modeling
language called Promela
• Promela(=Protocol/Process Meta Language)
–
–
–
–
dynamic creation of concurrent processes
communication via message channels
specification language to model finite-state model
C like
The model checker SPIN
2
What is SPIN? (1)
• “Press on the button” model-checker, based
on automata theory
• A popular open-source software tool
that can be used for the formal
verification of asynchronous and
distributed asynchronous and
distributed software systems.
• Developed in Bell Laboratories.
The model checker SPIN
3
What is SPIN? (2)
• Spin can be used in 2 basic modes :
– as a simulator to get a quick impression of
the types of the behaviour captured by the
system model:
• guided simulation
• random and interactive simulation
– as a verifier generator: when a
counterexample is generated, it uses
simulation to step through the trace
The model checker SPIN
4
Promela
• Non-deterministic , guarded command
language for specifying the possible system
behaviours in a distributed system design
– Systems of interacting, asynchronous threads of
execution
• It brings ideas from:
– CSP process algebra by Hoare for input/output
– C language in some of the syntax and notational
conventions
– a non-deterministic guarded command language
(without msg passing primitives) by Dijkstra
The model checker SPIN
5
Promela Model
• Promela model consists of
–
–
–
–
–
type declaration
channel declarations
variable declarations
process declarations
[init process]
• A Promela model
corresponds with a FSM,
so:
–
–
–
–
no unbounded data
no unbounded channels
no unbounded processes
no unbounded process
creation
mytype = {MSG, ACK};
chan toS=…
chan toR=…
bool flag;
proctype Sender(){
… process body…
}
proctype Receiver(){
… process body…
}
init{
…
}
The model checker SPIN
6
Processes
• A process type consists of
–
–
–
–
a name
a list of formal parameters
local variable declarations
body
• A process executes concurrently with all other processes,
independent of speed of behaviour
• There may be several processes of the same type
• Each process has its own local state (process counter, local
variables)
The model checker SPIN
7
Process instantiation
• Processes are created using
the run statement (it
returns the process id) and
start executing after it
• Processes can be created at
any point in the execution
• Processes can also be
activate by adding in front
of the proctype declaration
The model checker SPIN
proctype Foo(byte x){
…
}
init{
int pid2=run Foo(2);
run Foo(22);
}
active [...] proctype Pippo(){
…
}
8
Example
proctype Sender(chan in; chan out){
bit sndB, rcvB;
do
:: out ! MSG, sndB ->
in ? ACK, rcvB;
if
:: sndB == rcvB -> sndB= 1-sndB
:: else -> skip
fi
od
}
The model checker SPIN
9
Variables and Types (1)
• Basic integer types: bit, bool, byte, short, int,
unsigned
• Arrays: fixed size
byte a[27];
bit flags[4];
• Records
typedef Record{
short f1;
byte f2;
}
The model checker SPIN
10
Variables and Types (2)
• Variables should be declared
int ii, bb;
• Variables can be given a value by
– assignment
bb=1;
Rercord f;
f.bb=1;
– argument passing
– message passing
The model checker SPIN
11
Variables and Types (3)
• mtype: a way to introduce symbolic constant
values
– mtype declaration (up to 255 names):
mtype = { msg0, ack0, msg1, ack1 }
• pid 0..255
• Communication channel
– chan 0…255
The model checker SPIN
12
Predefined Variables
• else
– value=true iff no statement in the current process is
executable
• timeout
– value=true iff no statement in the model is executable
• _
– write-only scratch variable, does not store a value
• _pid
– the current process’s instantiation number
• _nr_pr
– the number of active processes
• _last
– the pid of process that executed last
The model checker SPIN
13
Communication (1)
The model checker SPIN
14
Communication (2)
• Communication between processes is via channels:
– message passing
– rendez-vous synchronisation (handshake)
• Both are defined as channels:
chan <name> = [<dim>] of {<t1>,<t2>, … <tn>};
– t1…tn = type of the elements that will be transmitted over the
channel
– dim = number of elements in the channel [dim==0 is special
case: rendez-vous]
• Examples:
– chan c = [1] of {bit};
– chan toR = [2] of {mtype, bit};
– chan line[2] = [1] of {mtype, Record}; array of channels
The model checker SPIN
15
Communication (3)
• channel = FIFO-buffer (for dim>0)
• ! Sending - putting a message into a channel
ch ! <expr1>, <expr2>, … <exprn>;
– The values of <expri> should correspond with the types of the
channel declaration.
– A send-statement is executable if the channel is not full.
• ? Receiving - getting a message out of a channel
ch ? <var1>, <var2>, … <varn>;
message passing
– If the channel is not empty, the message is fetched from the
channel and the individual parts of the message are stored into the
<vari>s.
ch ? <const1>, <const2>, … <constn>; message testing
– If the channel is not empty and the message at the front of the
channel evaluates to the individual <consti>, the statement is
executable and the message is removed from the channel.
The model checker SPIN
16
Communication (4)
• Rendez-vous communication
<dim> == 0
The number of elements in the channel is now zero.
– If send ch! is enabled and if there is a corresponding receive ch?
that can be executed simultaneously and the constants match, then
both statements are enabled.
– Both statements will “handshake” and together take the transition.
• Example:
chan ch = [0] of {bit, byte};
– P wants to do ch ! 1, 3+7
– Q wants to do ch ? 1, x
– Then after the communication, x will have the value 10.
The model checker SPIN
17
Communication (5)
• len(q) : returns the number of
messages in q
• empty(q) : true when q is currently
empty
• full(q) : true when q is filled to capacity
• nempty(q) : added to support
optimization
• nfull(q) : added to support optimization
The model checker SPIN
18
Statements (1)
• The body of a process consists of a sequence of statements.
A statement is either
– executable: the statement can be executed immediately.
– blocked: the statement cannot be executed.
• An assignment is always executable.
• An expression is also a statement; it is executable if it
• evaluates to non-zero.
– 2 < 3 always executable
– x < 27 only executable if value of x is smaller 27
– 3 + x executable if x is not equal to –3
The model checker SPIN
19
Statements (2)
• The skip statement is always executable.
– “does nothing”, only changes process’ process counter
• A run statement is only executable if a new process can be
created (remember: the number of processes is bounded).
• A printf (printm) statement is always executable (but is not
evaluated during verification, of course).
• assert(<expr>);
– The assert-statement is always executable.
– If <expr> evaluates to zero, SPIN will exit with an error, as the
<expr> “has been violated”.
– The assert-statement is often used within Promela models, to check
whether certain properties are valid in a state.
The model checker SPIN
20
Interleaving Semantics
• Promela processes execute concurrently.
• Non-deterministic scheduling of the processes.
• Processes are interleaved (statements of different
processes do not occur at the same time).
– exception: rendez-vous communication.
• All statements are atomic; each statement is executed
without interleaving with other processes.
• Each process may have several different possible
actions enabled at each point of execution.
– only one choice is made, non-deterministically.
The model checker SPIN
21
if-statement
If
:: choice1 -> option1
:: choice2 -> option2
:: else -> option3
/* optional */
fi
• Cases need not be exhaustive or mutually
exclusive
• Non-deterministic selection
The model checker SPIN
22
do-statement
do
:: choice1 -> option1;
:: choice1 -> option1;
……….
:: choice1 -> option1;
od;
• With respect to the choices, a do-statement behaves in the
same way as an if-statement.
• However, instead of ending the statement at the end of the
choosen list of statements, a do-statement repeats the
choice selection.
• The (always executable) break statement exits a do-loop
statement and transfers control to the end of the loop.
The model checker SPIN
23
Example
proctype counter()
{
do
:: (count != 0) ->
if
:: count = count + 1
:: count = count – 1
fi
:: (count == 0) -> break
od
}
The model checker SPIN
24
Delimitors
• Semi-colon is used a statement separator
not a statement terminator
– Last statement does not need semi-colon
– Often replaced by -> to indicate causality
between two successive statements
– (a == b); c = c + 1
– (a == b) -> c = c + 1
The model checker SPIN
25
Variable scoping
• Similar to C
– globals, locals, parameters
byte foo, bar, baz;
proctype A(byte foo) {
byte bar;
baz = foo + bar;
}
The model checker SPIN
26
Send and Receive Executability
• Send is executable only when the channel is not
full
• Receive is executable only when the channel is not
empty
• Optionally some arguments of receive can be
constants
– qname?RECV,var,10
– Value of constant fields must match value of
corresponding fields of message at the head of channel
queue
The model checker SPIN
27
Composite conditions
• Invalid in Promela
– (qname?var == 0)
– (a > b && qname!123)
– Either send/receive or pure expression
• Can evaluate receives
– qname?[ack,var]
The model checker SPIN
28
Promela statements
•
•
•
•
•
skip
assert(<expr>)
expression
assignment
if
• do
• break
• send (ch!)
• receive (ch?)
always executable
always executable
executable if not zero
always executable
executable if at least one guard is
executable
executable if at least one guard is
executable
always executable (exits do-statement)
executable if channel ch is not full
executable if channel ch is not empty
The model checker SPIN
29
assert
• assert(any_boolean_condition)
– pure expression
• If condition holds -> no effect
• If condition does not hold -> error report
during verification with Spin
The model checker SPIN
30
atomic
atomic { stat1; stat2; ... statn }
• can be used to group statements into an atomic sequence; all
statements are executed in a single step (no interleaving with
statements of other processes)
• is executable if stat1 is executable
• if a stati (with i>1) is blocked, the “atomicity token” is
(temporarily) lost and other processes may do a step no pure
atomicity
The model checker SPIN
31
d_step
d_step { stat1; stat2; ... statn }
• more efficient version of atomic: no intermediate states are
generated and stored
• may only contain deterministic steps
• it is a run-time error if stati (i>1) blocks.
• d_step is especially useful to perform intermediate
computations in a single transition
The model checker SPIN
32
proctype P1(){t1a; t1b;t1c}
proctype P2(){t2a; t2b;t2c}
init{run P1(); run P2()}
0
0
t2a
t1a
1
1
t2b
t1b
2
2
t2c
t1c
3
No Atomicity
3
The model checker SPIN
33
proctype P1(){atomic{t1a; t1b;t1c}}
proctype P2(){t2a; t2b;t2c}
init{run P1(); run P2()}
Atomicity
It is as P1 has only one
transition, but if one P1’s
transitions blocks, these
transition may be executed
The model checker SPIN
34
proctype P1(){d_step{t1a; t1b;t1c}}
proctype P2(){t2a; t2b;t2c}
init{run P1(); run P2()}
The model checker SPIN
d_step
35
timeout
• Promela does not have real-time features.
– In Promela we can only specify functional behaviour.
– Most protocols, however, use timers or a timeout mechanism to
resend messages or acknowledgements.
• timeout
– SPIN’s timeout becomes executable if there is no other process in the
system which is executable
– so, timeout models a global timeout
– timeout provides an escape from deadlock states
– beware of statements that are always executable…
• timeout can be replaced by skip
The model checker SPIN
36
goto
goto label
• transfers execution to label
• each Promela statement might be labelled
• quite useful in modelling communication
protocols
wait_ack:
if
:: B?ACK -> ab=1-ab ; goto success
:: ChunkTimeout?SHAKE ->
if
:: (rc < MAX) -> rc++; F!(i==1),(i==n),ab,d[i];
goto wait_ack
:: (rc >= MAX) -> goto error
fi
fi;
The model checker SPIN
37
unless
{ <stats> } unless { guard; <stats> }
– Statements in <stats>are executed until the first
statement ( guard) in the escape sequence becomes
executable.
– resembles exception handling in languages like Java
• Example:
proctype MicroProcessor() {
{
...
/* execute normal instructions */
}
unless { port ? INTERRUPT; ... }
}
The model checker SPIN
38
never
never { stmnt1; stmnt2; … stmntn }
– used to specify behavior that should never
happen
– the claim is defined as a series of propositions, or
boolean expressions, on the system state that
must become true in the sequence specified for
the behavior of interest to be matched
– a never claim can be used to match either finite or
infinite behaviors (i.e., safety and liveness
properties, and LTL formulae)
– it can either be written by hand or they can be
generated mechanically from LTL formula
The model checker SPIN
39
LTL patterns
• Invariance
[] (p)
– Spin supports 7 ways to check for invariance
• Response
• Precedence
• Objective
[] ((p) -> (<> (q)))
[] ((p) -> ((q) U (r)))
[] ((p) -> <>((q) || (r)))
The model checker SPIN
40
Invariance
• Add the following monitor process to the Promela model:
active proctype monitor()
{
assert(P);
}
Two variations:
– monitor process is created first
– monitor process is created last (the –end- transition will be executable
after executing assert(P))
• SPIN translates the LTL formula to an accepting never claim.
never {
![]P
TO_init:
if
:: (!P) -> goto accept_all
:: (1) -> goto TO_init
fi;
accept_all:
skip
}
The model checker SPIN
41
SPIN Architecture

LTL
Translator
Simulator
Promela
Model M
XSPIN
SPIN
Verifier
Generator
C Program
Counter
example
The model checker SPIN
Checker
|
42
Spin capabilities
• Interactive simulation
– For a particular path
– For a random path
• Exhaustive verification
– Generate C code for verifier
– Compile the verifier and execute
– Returns counter-example
• Lots of options for fine-tuning
The model checker SPIN
43
State vector
• A state vector is the information to uniquely identify a
system state; it contains:
– global variables
– contents of the channels
– for each process in the system:
• local variables
• process counter of the process
• SPIN provides several algorithms to compress the state
vector.
The model checker SPIN
44
The model checker SPIN
45
Reduction algorithms
• SPIN has several optimisation algorithms to make
verification runs more effective:
– partial order reduction: if in some global state, a process P can
execute only “local” statements, then all other processes may be deferred
until later
– bitstate hashing: instead of storing each state explicitly, only one
bit of memory are used to store a reachable state
– minimised automaton encoding of states (not in a hashtable): states
are stored in a dynamically changing, minimised DFA
• inserting/deleting a state changes the DFA
• close relationship with OBDDs
– state vector compression: instead of storing a state explicitly, a
compressed version of the state is stored in the state space
– dataflow analysis
– slicing algorithm: to get hints for possible reductions
The model checker SPIN
46
Leader Election Protocol
• N processes in a ring topology connected by unbounded
channels
• A process can only send messages in a clockwise manner
• Initially each process has a unique identifier assumed to be
a natural number
• The purpose of a leader election protocol is to make sure
that exactly one process will become the leader.
• The idea that the process with the highest identier should
be elected as a leader
The model checker SPIN
47
LEP Algorithm
Active:
d:=ident;
do forever
begin
send(d);
receive(e);
if e= d then stop; (*process d is the leader*);
send(e);
receive(f);
if e>=max(d,f) then d:=e else goto relay
end
relay:
do forever
begin
receive(d);
send(d);
end
The model checker SPIN
48
Promela code
The model checker SPIN
49
Global Variables
• #define N
• #define I
5 /*# of processes*/
3 /*process with the smallest
identifier*/
• #define L
10 /*size of buffer*/
• chan q[N] = [L] of {byte}
The model checker SPIN
50
Initialization
The model checker SPIN
51
Simulation run in Spin
The model checker SPIN
52
[] p
#define p (nr_leaders <=1)
Nr_leaders++;
The model checker SPIN
53
Automaton generated by Spin
The model checker SPIN
54
Property Verification
The model checker SPIN
55
Research trends
• Combine with theorem-proving (PVS).
• Parameterized verification.
–
–
–
–
Verify the n-component system for all n.
Pipelines with n stages.
Cache protocol with n memory units.
…..
• Infinite state systems
• Timed systems (TRIO Model Checker).
• Hybrid systems.
The model checker SPIN
56