Le document traite de la vérification des modèles, en se concentrant sur les automates de Büchi et le modèle SPIN. Il explique comment observer et vérifier les propriétés temporelles des systèmes par l'exécution synchronisée de machines, en introduisant des concepts tels que les exigences négatives et les automates de négation. De plus, il présente Promela, un langage de spécification pour les systèmes distribués utilisé dans l'analyse des modèles avec SPIN.

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érifierp
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