1. Chap 7 1
Chapitre 4
Vérification de modèles:
Automates de Büchi et SPIN
(Holzmann Chap. 6)
http://w3.uqo.ca/luigi/INF6001/
2. INF6001 Chap 7 2
Proprié té s d’é tats et exé cutions
(chaî nes)
X=13 X=X/2+1 X>0
X=X/2
X≤0
s0
Nous pouvons affirmer des propriétés pour:
Des états: p.ex. à l’état s1, X=13 toujours (invariant)
pas besoin de logique temporelle ici
Des exécutions, p.ex. x≤0 ou x≤0, mais pas x≤0.
Observez que dans ce cas le contrôle est sur les transitions.
s1 s2 s3
X: entier et
/ a résultat
entier
.État d’acceptation
3. INF6001 Chap 7 3
Comment vérifier les proprié té s temporelles?
Nous avons une machine dont nous pouvons observer
certaines propriétés, p.ex.
qu’une variable a toujours une certaine valeur
ou une propriété temporelle
Solution:
exécuter la machine en parallèle avec une autre machine qui
observe et vérifie ces propriétés – composition synchrone
nous pouvons aussi vérifier une propriété négative, c.-à.-d.
que la machine ne satisfait pas une propriété
never automata
4. INF6001 Chap 7 4
Vé rification de modè le
Modèle à vérifier
Machine exprimant
des propriétés
à vérifier
Composition synchrone
5. INF6001 Chap 7 5
Exemple
s1
p
AB pour vérifier p
Cet AB synchronise avec un autre AB seulement si la propriété
p reste toujours vraie, à toutes les transitions
6. 6
Acceptation dans les automates de
Büchi
Un automate régulier accepte toutes les chaînes qui
conduisent à un état final
Un AB accepte toutes les chaînes infinies qui passent
un nombre infini de fois par un état final
Pour chaque expression de logique temporelle, il y a
un AB qui accepte les chaînes qui satisfont cette
expression
Il existe un algorithme pour effectuer cette construction, pas
discuté dans ce cours
7. INF6001 Chap 7 7
Incomplé tude des AB
L’AB de gauche ne considère pas le cas de recevoir un ¬ p
Ceci simplifie la compréhension et la vérification, car les
transitions qui ne conduisent pas au résultat désiré ne sont pas
prises en considération
s1
p
s1
p
s2
¬ p
8. INF6001 Chap 7 8
Exemple
s0 s1
¬ p
p
true
AB pour vérifierp
Cet AB est prêt à accepter des transitions où p est faux,
mais il est content seulement quand p devient vrai.
9. INF6001 Chap 7 10
Exemple
AB pour vérifier que p (enfin toujours p)
‘true’ accepte p et autres mais après un certain p, il
n’accepte que des p après
s0 s1
true
p
p
10. INF6001 Chap 7 11
Comparer avec AB dé terministe
s0 s1
¬p
p
p
L’AB ci-dessous n’est pas bon pour p
Car s’il y a un 1er p qui n’est pas suivi par p il rejette.
Il faut dans ce cas continuer à chercher un p futur après
lequel p
Cet AB montre aussi les limites de l’expressivité des opérateurs , car ce
qu’il exprime (après le 1er p, toujours p) n’est pas exprimable avec ces
opérateurs seulement.
faut utiliser U: ¬ p U p
11. INF6001 Chap 7 16
Autre exemple impliquant U (until fort)
s0 s1
p
q
true
p U q
12. INF6001 Chap 7 18
Exemple
s0 s1
true
p
p toujours finalement p
(infiniment souvent p)
true
Accepte seulement quand il continuera d’y avoir des p dans le futur
13. INF6001 Chap 7 20
Exemple: utiliser les notions
d’é quivalence
¬p = ¬ p
Un ¬ p doit être trouvé, après on peut trouver autre chose, mais
il faut retourner sur ¬ p
s0 s1
true
true
¬p
toujours finalement ¬ p
14. INF6001 Chap 7 21
Exemple (pas trè s intuitif, mais…)
(p → q) = (¬ p ∨ q)
Dorénavant, un p est suivi toujours par un q.
Utilisant la formule de droite, nous voyons que:
à cause du fait que faux → vrai = vrai, p n’a pas besoin de se produire afin
que q se produise et rende la formule vraie
15. INF6001 Chap 7 22
Exemple continuation
(p → q) = (¬ p ∨ q)
s0 s1
¬ p ∨ q
true
q
true
Accepte tant que ¬ p ∨ q est vrai, peut aussi
passer à un état où un q doit se produire plus tard
Dorénavant, un p
est suivi toujours
par un q
16. INF6001 Chap 7 24
Never claims: exigences né gatives
Nous verrons qu’en principe il est plus efficace de
contrôler l’absence de comportements défendus plutôt
que de contrôler que tous les comportements soient
permis
L’AB approprié est donc obtenu par négation d’une
formule de logique temporelle
17. INF6001 Chap 7 25
Né gation de la formule pré cé dente:
(p → q) = (¬ p ∨ q)
Dorénavant, un p est suivi toujours par un q
Donc cette formule est fausse s’il y aura un
p et puis aucun q
18. INF6001 Chap 7 26
Automate négation: never automata
Supposons que nous voulions qu’un comportement niant la
formule précédente soit détecté:
¬(p → q) = par définition de →
¬(¬ p ∨ q) = par loi de dualité
¬ (¬ p ∨ q) = par loi de De Morgan
(p ∧ ¬ q) = par dualité
(p ∧ ¬q)
s0 s1
true
p ∧ ¬q
¬q
Donc si un comportement tombe dans l’état s1,
il n’est pas conforme aux exigences
19. INF6001 Chap 7 27
Proprié té s d’un systè me
Pour prouver qu’ un système jouit des propriétés spécifiées par des
expression de logique temporelle, il faut montrer que tous les
comportements du système ont ces propriétés
Nous appelons ‘langage’ d’un automate l’ensemble de chaînes, l’ensemble
des comportements, qu’il accepte
Propriétés ou exigences positives
Toutes les exécutions du système satisfont aux propriétés
Pour prouver une exigence positive, nous devons prouver que le langage du
système est inclus dans le langage de l’AB qui exprime l’exigence
Propriétés ou exigences négatives
Aucune exécution du système ne satisfait aux propriétés
Le langage du système et le langage de l’exigence doivent avoir intersection
vide
Si l’intersection est non vide, les exécutions dans l’intersection sont des contre-
exemples, montrant dans quelles situations la propriété est violée
20. Deux maniè res de prouver ou refuser une proprié té
Prouver que tous les comportements du système
satisfont la propriété
Chercher un comportement du système qui satisfait la
négation de la propriété! (un contrexemple)
Clairement, cette deuxième stratégie pourrait aboutir plus
rapidement, car
dès qu’un contrexemple est trouvé, nous savons que la propriété
est fausse et nous n’avons pas besoin de continuer
INF6001 Chap 7 28
21. Never claims
Donc un model checker comme SPIN
systématiquement nie les propriétés qu’on veut vérifier
et cherche un contrexemple au lieu de chercher à
prouver que une propriété souhaitée est toujours vraie
Si un contrexemple est trouvé, on sait que la propriété est
fausse et on a sauvé du temps
Si un contrexemple n’est pas trouvé, on sait que la propriété
est vraie et on a fait le même travail que dans le cas où on
aurait cherché à prouver la propriété positive directement
Les propriétés niées s’appellent never claims
INF6001 Chap 7 29
22. INF6001 Chap 7 35
Preuve d’exigences né gatives
Étant donné un système S et une formule LTL f à
contrôler pour S
Construire un AB A¬f pour la négation de f
Il n’accepte que les chaînes qui satisfont ¬f, qui violent f
Calculer la composition synchrone des machines S et A¬f
Contrôler si le langage accepté par cet automate est vide
S’il est vide, toutes les exécutions de S satisfont f
S’il a des exécutions, il y a au moins une exécution dans S qui est
un contre-exemple pour f
En pratique, la composition synchrone souvent n’a pas
besoin d’être calculée dans sa totalité car dès qu’on trouve
un contre-exemple on a prouvé que l’exigence n’est pas
satisfaite
23. INF6001 Chap 7 47
Analyse de modè les, Model Checking
byte n;
proctype Aap() {
do
:: n++
:: noot!MIES
od
}
Modèle M
[] (n<3)
Propriété φ
Analyseur
Espace d’états
OUI
Propriété
satisfaite
NON,
+ contre_exemple
ϕ=|M
Explosion d’états.
24. INF6001 Chap 7 48
Dé finition[Clarke & Emerson
1981]
“Model checking is an automated
technique that, given a finite-state
model of a system and a logical
property, systematically checks
whether this property holds for (a given
initial state in) that model.”
25. INF6001 Chap 7 49
Promela et SPIN
Promela est un langage pour la spécification des
systèmes répartis
SPIN est l’analyseur (model checker) et son point de
départ est la théorie que nous venons de discuter
26. INF6001 Chap 7 50
Promela
Protocol/Process Meta Language
Influencé par le CSP de Hoare
Et par C
Mais il est un langage pour la spécification de modèles
Pas un langage d’implantation
De compréhension facile pour les implémenteurs
Admet la communication
Par variables globales partagées
Synchrone, directe
Asynchrone, par canaux
27. INF6001 Chap 7 51
Promela Model
A Promela model consist of:
type declarations
channel declarations
global variable declarations
process declarations
[init process]
behaviour of the processes:
local variables + statements
- simple vars
- structured vars
- vars can be accessed
by all processes
initialises variables and
starts processes
chan ch = [dim] of {type, …}
asynchronous: dim > 0
rendez-vous: dim == 0
mtype, constants,
typedefs (records)
28. INF6001 Chap 7 52
mtype = {REQ,ACK};
typedef Msg {
byte a[2];
mtype tp;
} ;
chan toR = [1] of {Msg};
bool flag;
proctype Sender() {
Msg m;
...
m.a[0]=2; m.a[1]=7; m.tp = REQ;
toR ! m;
}
proctype Receiver(byte n) {
Msg m;
...
toR ? m;
}
init {
run Sender();
run Receiver(2);
}
Promela Model
A Promela model corresponds to a (usually
very large, but) finite transition system, so
no unbounded data
no unbounded channels
no unbounded processes
no unbounded process creation
channel declaration
creates processes
global variable
local variable
message types (constants)
“record” declaration
Example of a Promela model
Inputs/outputs
29. INF6001 Chap 7 53
Processes (1)
A process type (proctype) consist of
a name
a list of formal parameters
local variable declarations
body
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
}
name
local variables
body
formal parameters
The body consist of a
sequence of statements.
Une sortie et puis ->
30. INF6001 Chap 7 54
Statements
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
executable/blocked
depends on the global
state of the system.
31. INF6001 Chap 7 55
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).
int x;
proctype Aap()
{
int y=1;
skip;
run Noot();
x=2;
x>2 && y==1;
skip;
}
Can only become executable if some
other process makes x greater than 2.
Executable if Noot can be created…
Statements are
separated by a
semi-colon: “;”.
or by the equivalent “->”
32. INF6001 Chap 7 56
Statements (3)
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 always valid in a state.
proctype monitor() {
assert(n <= 3);
}
proctype receiver() {
byte msg;
...
toReceiver ? msg;
assert(msg != ERROR);
...
}
33. INF6001 Chap 7 57
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.
= randomly
34. INF6001 Chap 7 58
Bit alterné en SPIN http://spinroot.com/spin/Man/Manual.html
1 #define MAX5
2
3 mtype = { mesg, ack, nak, err };
4
5 proctype sender(chan in, out)
6 { byte o, s, r;
7
8 o=MAX-1;
9 do
10 :: o = (o+1)%MAX; /* next msg */
11 again: if
12 :: out!mesg(o,s) /* send */
13 :: out!err(0,0) /* distort */
14 :: skip /* or lose */
15 fi;
16 if
17 :: timeout -> goto again
18 :: in?err(0,0) -> goto again
19 :: in?nak(r,0) -> goto again
20 :: in?ack(r,0) ->
21 if
22 :: (r == s) -> goto progress
23 :: (r != s) -> goto again
24 fi
25 fi;
26 progress: s = 1-s /* toggle seqno */
27 od
28 }
29
30 proctype receiver(chan in, out)
31 { byte i; /* actual input */
32 byte s; /* actual seqno */
33 byte es; /* expected seqno */
34 byte ei; /* expected input */
35
36 do
37 :: in?mesg(i, s) ->
38 if
39 :: (s == es) ->
40 assert(i == ei);
41 progress: es = 1 - es;
42 ei = (ei + 1)%MAX;
43 if
44 /* send, * :: out!ack(s,0)
45 /* distort */ :: out!err(0,0)
46 /* or lose :: skip
47 fi
48 :: (s != es) ->
49 if
50 /* send, */ :: out!nak(s,0)
51 /* distort */ :: out!err(0,0)
52 /* or lose */ :: skip
53 fi
54 fi
55 :: in?err ->
56 out!nak(s,0)
57 od
58 }
59
60 init {
61 chan s_r = [1] of { mtype,byte,byte };
62 chan r_s = [1] of { mtype,byte,byte };
63 atomic {
64 run sender(r_s, s_r);
65 run receiver(s_r, r_s)
66 }
67 }
We want to verify that data that is sent can only be delivered to the receiver without any deletions or reorderings,
despite the possibility of arbitrary message loss. The assertion on line 40 verifies precisely that.
Note that if it were ever possible for the protocol to fail to meet the above requirement, the assertion can be violated
(autres détails intéressants dans le site)
35. INF6001 Chap 7 59
Xspin in a nutshell
Xspin allows the user to
edit Promela models (+ syntax check)
simulate Promela models
random
interactive
guided
verify Promela models
exhaustive
bitstate hashing model
additional features
Xspin suggest abstractions to a Promela model (slicing)
Xspin can draw automata for each process
LTL property manager
Help system (with verification/simulation guidelines)
with dialog boxes to set
various options and directives
to tune the verification process
36. INF6001 Chap 7 60
Conclusions sur SPIN
Bases théoriques très solides
Logique temporelle linéaire et automates de Büchi
Outil très performant
L’outil de vérification le plus utilisé dans notre domaine
Excellent survol pratique sur SPIN et plusieurs des
concepts que nous avons vu:
http://plan9.bell-labs.com/sys/doc/spin.html