*** syntaxe
op []_ : Formula -> Formula [prec 11] . op <>_ : Formula -> Formula [prec 11].
op _U_ : Formula Formula -> Formula [prec 14] . op o_ : Formula -> Formula [prec 11] .
*** semantique
154 var E : Event . var T : Trace . eq <> false = false . eq <> true = true . eq o (X * Y) = o X * o Y . eq o (X + Y) = o X + o Y . eq X U (Y + Z) = (X U Y) + (X U Z) . eq false U X = X . eq X U false = false . eq true U X = <> X . eq E |= [] X = E |= X .
eq E,T |= [] X = E,T |= X and T |= [] X . eq E |= <> X = E |= X .
eq E,T |= <> X = E,T |= X or T |= <> X . eq E |= X U Y = E |= Y .
eq E,T |= X U Y =
E,T |= Y or E,T |= X and T |= X U Y . eq E |= o X = E |= X .
eq E,T |= o X = T |= X . vars X Y : Formula .
var E : Event . var T : Trace . eq ([] X){E} = [] X /\ X{E} . eq ([] X){E *} = X{E *} . eq (<> X){E} = <> X \/ X{E} . eq (<> X){E *} = X{E *} . eq (o X){E} = X . eq (o X){E *} = X{E *} . eq (X U Y){E *} = Y{E *} .
op _|-_ : Trace Formula -> Bool [strat (2 0)] . eq E |- X = [X{E *}] .
endfm
9.6 Expérimentation
Nous avons conduit plusieurs vérifications sur des systèmes dont nous avons pris le soin de formaliser et de spécifier ainsi que certaines de leurs propriétés. La table 9.12 récapitule à juste titre une partie de notre expérimentation.
Nous donnons tout de suite le texte descriptif de la spécification de certains de ses systèmes. Comme nous l’avons dit auparavant, les systèmes réactifs peuvent se présentés dans une forme « Hard »: un circuit ou équivalent et une forme « soft » : un logiciel, un programme ou équivalent.
9.6.1 Exemple de spécification d’un système Hardware: Muller-C circuit
155
Le circuit Muller-C est réalisé à partir de trois circuits majeurs selon le graphique de la figure 9.12. Comme nous pouvons le constater, la structure et le comportement d’un tel circuit peut être formalisé par la formule de la logique temporelle suivante :
[ ](e ↔ ((in1 ∧ in2) ∨ (in1 ∧ in3) ∨ (in2 ∧ in3))) avec un décalage d’un délai d’une unité selon :
[ ]( @out ↔ ((in1 ∧ in2) ∨ (in1 ∧ in3) ∨ (in2 ∧ in3)))
Lorsque l’on relie la sortie (out) avec l’une des trois entrées, disons In3 par exemple, nous obtenons l’expression du circuit Muller-C comme suit :
[ ](@out ↔ ((in1 ∧ in2) ∨ (in1 ∧ out) ∨ (in2 ∧ out)))
En suivant une telle description du circuit Muller-C, nous pouvons alors développer un outil très large formé par des spécifications pour décrire les comportements du circuit concerné, mais aussi d’autres circuits équivalents. Par exemple nous pouvons mettre en place les spécifications suivantes et démontrer par la même occasion leurs validités. Nous proposons trois spécifications qui se résument comme suit :
Spécification1. Deux signaux en entrée (par exemple In1 et In2) sont au niveau “high” conduit (implique) que la sortie soit à un niveau “low” jusqu’à ce qu’elle devienne (éventuellement) “high” (peut être bien immédiatement) et restera à ce niveau “low”, jusqu’à ce que In1 et In2 redeviennent en même temps au niveau “low” de nouveau, ou bien si cette dernière conditions ne surviendra jamais (restera pour toujours de mise). La spécification est écrite comme suit :
[ ]( (in1 ∧ in2 → ¬out U(out ∧ (out U (¬ in1 ∧ ¬ in2) ∨ [ ] out)))
De la même manière nous decrivons la deuxième et la troisième spécification selon ce qui suit : Specification 2.
[ ]( (¬in1 ∧ ¬in2 → ¬out U(¬ out ∧ (¬out U (in1 ∧ in2) ∨ [ ] ¬out))) Specification 3.
out U (in1 ↔ in2) ∨ out U(in1 ↔ in2) ∨ [ ] (@out ↔ out )
Notre outil permet de façon simple la verification du comportement circuit Muller-C qui se résume à la spécification globale suivante :
Muller-C → specification1 ∧ specification2 ∧ specification3
La solution d’un tel comportement est executé en 63 opérations de réécriture en moins d’ une millli-seconde.
9.6.2 Exemple de specification d’un “Software” : Peterson Algorithm’s
Pour mieux apprécier l’étendue de cet algorithme, j’ose le présenter dans sa version originale qui permet de garder son sens et sa porté. La traduction est aussi aisée que la version anglaise.
Le Problème :
A paradigmatic problem in concurrent programming is the mutual-exclusion problem, which asks for a programming solution to ensure that no two processes simultaneously access a common resource, such as an I/O devise or a write-shared variable.
156
In a practical way there is a finite numbers of algorithms modelling the problem of the mutual-exclusion control. Among such paradigm, Peterson’s algorithm is the simpler solution to the problem of mutual exclusion.
Peterson's Mutual Exclusion Algorithm for 2 processes each of which can adopt 4 states (non-critical section, request section, wait section and critical section). Such states are defined for each process using Boolean equations as follows :
We admit that the parameters c1, c2, d1 and d2 are used to control the accessibility of the critical section, and the unary operator ‘ ~ ‘ is the negation form.
**** Process P1
NCS1 = ~c1 /\ ~c2; # non-critical section TRY1 = c1 /\ ~c2; # request section WAIT1 = ~c1 /\ c2; # wait section
CS1 = c1 /\ c2; # critical section *** Process P2 NCS2 = ~d1 /\ ~d2; TRY2 = d1 /\ ~d2; WAIT2 = ~d1 /\ d2; CS2 = d1 /\ d2;
The processes are modeled using interleaving, which is represented by a program counter' bit (pc). If pc (true) then the first process is running, if ~pc (false) the second is so. There are other 'global' variables (bits), in1 (in2): process 1 (2) requests the critical resource. If in1 /\ in2 /\ t (t is the 'tie-breaker') then process 1 enters the critical section, if in1 /\ in2 /\ ~t then process 2 enters.
/* The complete system: */
peterson = start /\ []first /\ []second /\ fairness /* The specification to prove mutual exclusion
mut_exc = [] ~(CS1 /\ CS2);
/* To verify that the implementation (Peterson algorithm) meets its requirement (verify the specification), we write : peterson -> mut_exc
Start, first, second, fairness are defined as follows : ***** The behavior of the first process
first = pc -> (d1 <-> @ d1) /\ (d2 <-> @ d2) /\ (in2 <-> @ in2) /\ ( NCS1 /\ @ TRY1 /\ @ in1 /\ (t <-> @ t) \/ TRY1 /\ @ WAIT1 /\ @ ~t /\ (in1 <-> @ in1) \/ WAIT1 /\ @ WAIT1 /\ in2 /\ ~t /\ (t <-> @ t) /\ (in1 <-> @ in1) \/ WAIT1 /\ @ CS1 /\ (~in2 \/ t) /\(in1 <-> @ in1) /\ (t <-> @ t) \/ CS1 /\ @ NCS1 /\ @ ~in1 /\ (t <-> @ t) );
***** The behavior of the second process
second = ~pc -> (c1 <-> @ c1) /\ (c2 <-> @ c2) /\ (in1 <-> @ in1) /\ ( NCS2 /\ @ TRY2 /\ @ in2 /\ (t <-> @ t) \/ TRY2 /\ @ WAIT2 /\ @ t /\ (in2 <-> @ in2) \/ WAIT2 /\ @ WAIT2 /\ in1 /\ t /\ (t <-> @ t)/\ (in2 <-> @ in2) \/ WAIT2 /\ @ CS2 /\ (~in1 \/ ~t) /\ (in2 <-> @ in2) /\ (t <-> @ t) \/ CS2 /\ @ NCS2 /\ @ ~in2 /\ (t <-> @ t) );
**** The initial start
start = t /\ ~in1 /\ ~in2 /\ NCS1 /\ NCS2;
/* Infinitely often pc high and infinitely often pc low: */ fairness = []<> pc /\ []<> ~pc;
The solution of such formula is performed in 103 rewrites and at less than 160 ms.
La table suivante résume au mieux un certain nombre de circuits et logiciels. Dans la première colonne nous présentons le nom du système en question, dans la deuxième sa durée d’exécution utilisant un outil de vérification PTL-tool [PTL-Tool], dans la troisième colonne, le nombre de réécritures qui ont permis la vérification et finalement dans la quatrième colonne le temps d’exécution des spécifications.
157 Dénomination du model Temps d’exécution ( PTL-tool) Nombre de réécritures Temps d’exécution (ms)(VALID2) Muller_C 0.1 s 70 40 Lars1 3.0 s 124 0 adder 0.1 s 195 0 Mul4 158.7s 216 10 Dff1 0.0 53 20 Josko3 105.6 s 21 10 Josko4 18.0 s 20 10 Mutex1 1.3 s 91 30 Mutex2 19.1 s 93 20 Peterson - 103 160 Scc-event - 23 10 Josko5 - 20 10 Muller-C2 - 20 10 Mutex - 65 10 CallHear - 34 10 Hailpern - 70 20
Table 9.12 : Résultats d’expérimentations vérifiées par Notre Model-Checker
9.7 Conclusion
Cette partie de notre thèse concerne les résultats obtenus suite à un effort considérable pour la mise en pratique des idées développées pour la spécification et la vérification des systèmes réactifs. En effet nous avons écrit les programmes suivant :
− Une implémentation des diagrammes de décision binaire qui constitue en lui-même (le BDD) un choix incontournable pour la vérification des systèmes software/hardware décrits comme des réseaux booléens.
− Une implémentation d’un module mixte basé sur les algorithmes génétiques et la programmation linéaire bivalente. Ce module n’a pas été décrit dans cette thèse mais l’a été dans certaines de nos publications.
− L’extension du système VALID en VALID 2, plus certains outils de modélisation, de spécification, de simulation et de vérification.
− L’écriture d’un ensemble de modules exécutés dans le système MAUDE sur une plate-forme Linux.
Nous signalons aussi, que plusieurs expérimentations ont été réalisées à travers la spécification, la programmation et la vérification de plusieurs problèmes (circuits et algorithmes) mettant en œuvre les applications développées dans le cadre de nos recherches et des résultats très encourageants ont été obtenus.
158