Réduction par bisimulation

S R

C1 C2

Figure 10.3: Le circuit 10.2 oùIest remplacé par deux commutateursC1etC2.

Nous allons montrer que si l’on ne distingue pas les actions sur

C

1et

C

2alors le sous-système formé des deux commutateurs est en bisimulation avec l’interrupteur

I

(ce sous-système peut donc être remplacé par

I

dans la description du circuit).

10.3.2 M

ODÉLISATION

Nous ne nous interessons ici qu’à la modélisation de l’interrupteur, des commutateurs et du mécanisme de va-et-vient.

La description de l’interrupteur

I

est sans surprise. Elle utilise deux flux

f

1et

f

2 pour les tensions, un événement

Pression

modélisant une action sur le bouton de l’interrupteur et une variable d’état

ouvert

indiquant la position (ouvert ou fermé) du composant. Le système de transition de

I

est présenté sur la figure 10.4.

node Interrupteur

flow f1, f2: bool; event Pression; state ouvert: bool;

trans true |- Pression -> ouvert: = not ouvert; assert (not ouvert) => (f1=f2);

edon F,{FF,TT} T,tt ε ε Pression Pression

Figure 10.4: Système de transition d’un interrupteur simple.

Les commutateurs se modélisent de manière tout aussi simple. Pour ce type de composant, une variable d’état (posHaut) indique simplement quel fil est connecté; celui du haut ou celui du bas. Le système de transition d’un commutateur est représenté sur la figure 10.5.

node Commutateur

flow f, haut, bas: bool; event Pression;

state posHaut: bool;

trans true |- Pression -> posHaut: = not posHaut; assert posHaut => (f=haut);

(not posHaut) => (f=bas); edon

{FFF,TTT, TTF,FFT} T, F,{FFF,TTT, TFT,FTF} ε ε Pression Pression

Figure 10.5: STI d’un commutateur utilisé pour un système va-et-vient. Les configurations sont représentées par des affectations du vecteur (posHaut, f, haut, bas).

Afin de comparer le sous-système constitué par les deux commutateurs à l’inter-rupteur simple, nous modélisons un noeud VaEtVient qui intègre et connecte les deux commutateurs comme représenté sur la figure 10.6. Le modèle de ce sous-système ne comporte pas de difficulté particulière mais on notera toutefois que, puisque l’on ne distingue pas les actions sur

C

1et

C

2, le noeud VaEtVient ne possède qu’un événement Pression qui modélise, soit une pression sur

C

1soit une pression sur

C

2; d’où les deux vecteurs de synchronisation.

Le système de transition du système va-et-vient est représenté sur la figure 10.7. node VaEtVient

flow f1, f2: bool; event Pression;

trans true |- Pression -> ; sub B1, B2: Commutateur; sync <Pression,B1.Pression>;

<Pression,B2.Pression>; assert f1 = B1.f; B2.f = f2; B1.haut = B2.haut; B1.bas = B2.bas; edon C1 C2 VaEtVient f1 ^haut _f2 bas haut bas f f

Figure 10.6: Le sous-système va-et-vient

FTtt FF{TT,FF} {TT,FF} TT TFtt Pression Pression Pression Pression ε ε ε ε

Figure 10.7: STI du système va-et-vient. Les configurations sont représentées par des affectations du vecteur (B1.posHaut, B2.posHaut, f1, f2).

10.3. RÉDUCTION PAR BISIMULATION

Pour montrer que les STI du va-et-vient et de l’interrupteur (figure 10.4) sont en bisimulation il suffit de remarquer l’autobisimulation [22] pour le va-et-vient: elle nous fournit les classes d’équivalence d’états suivantes: f

FF;TT

getf

FT;TF

g. Lorsque l’on se ramène au graphe quotient par cette relation d’équivalence, on obtient le STI de la figure 10.8 qui isomorphe à celui de l’interrupteur.

FTtt TFtt TT{TT,FF} FF{TT,FF} Pression Pression ε ε

Figure 10.8: Le STI quotient du système va-et-vient par la relation d’équiva-lencefFF;TTgetfFT;TFg.

11

11

SIMULATION ET ANALYSES QUALITATIVES

11.1 LA SIMULATION DES MODÈLES ALTARICA

La simulation d’un modèle consiste à « jouer » de manière plus ou moins dirigée les règles d’évolution (données par la sémantique du modèle) du système modélisé. La simulation est employée lors de deux types d’activité:

La validation du modèle : avant même de se soucier du problème de la vérification de propriétés il est nécessaire de s’assurer que le modèle est valide par rapport aux comportements étudiés du système. Cette démarche consiste à se poser la question: le modèle réalisé est-il une vue abstraite du système? Pour répondre à cette question, les utilisateurs de MECprônent l’utilisation de l’outil de véri-fication. En effet, puisque le model-checker permet de vérifier des propriétés du modèle, il autorise en particulier la vérification de sa conformité par rapport au système. Bien qu’elle augmente la confiance que l’on peut avoir en son modèle, cette méthode a le facheux inconvénient de nécessiter (justement) un calcul de propriété qui peut prendre du temps et de l’espace mémoire (dans MEC, le prin-cipal problème est l’obtention du modèle global par le calcul du produit synchro-nisé).

La méthode la plus répandue pour valider un modèle est la simulation pas-à-pas. Elle est non exhaustive mais elle permet de s’assurer que pour les scénarios joués par l’utilisateur, le modèle se comporte comme le système. Les simulateurs de modèle sont souvent dotés d’une interface graphique afin de faciliter la visuali-sation des comportements du système (p. ex. UPPAAL[25] ou FIABEX[1]). L’étude du système : la simulation consistant à générer des comportements du

système à partir du modèle, elle peut être utilisée pour la construction du graphe des états du système. De nombreux algorithmes de vérification sont basés sur cette construction.

Bien que AltaRica soit un langage essentiellement textuel, il est mis en œuvre dans un atelier de saisie graphique (l’atelier AltaRica) qui ressemble à un logiciel de CAO. Les spécifications de cet atelier comprenait l’intégration d’un simulateur graphique de modèles.

Du fait de la mise en parallèle des tâches du projet, l’atelier AltaRica ne met pas tout à fait en œuvre la sémantique du langage telle que spécifiée au chapitre 9.

La mise en œuvre de la sémantique du langage est délicate car elle nécessite le développement d’un « solveur » de contraintes. Ce solveur est nécessaire pour le calcul

des valeurs de flux pour un état donné. À l’heure actuelle le solveur utilisé n’est pas très performant; ceci n’est pas surprenant dans la mesure où nous n’avons posé aucune restriction sur les contraintes acceptées par le langage.

AltaRica est un modèle hiérarchique. La simulation d’un modèle AltaRica repose sur sa mise « à plat » ; celle-ci est formellement définie par la sémantique symbo-lique du langage (section 9.4, page 9.4). Cette sémantique nous permet de considérer un système AltaRica comme un seul composant. Toutefois elle nécessite que le sol-veur soit capable de résoudre des contraintes quantifiées. Le développement d’un tel solveur est prévu à court terme afin, en particulier, d’intégrer dans l’atelier AltaRica la sémantique définitive du langage.

11.2 ANALYSE QUALITATIVE DE SÉQUENCES

Dans cette section nous nous intéressons à la génération et à l’analyse de séquences d’événements à partir de modèles AltaRica. Ces séquences ont la particularité de me-ner le système dans des états critiques non souhaités (p. ex. la perte du système). L’ob-tention de ces séquences permet une étude qualitative des scénarios de défaillance et la prise de décision sur l’amélioration des parties les moins fiables du système. Cette prise de décision ne peut se faire à partir d’une liste exhaustive des scénarios de panne. En effet, si l’on considère un système à

N

composants, chacun pouvant subir une dé-faillance, alors le nombre de scénarios potentiels est2

N

_{. Cette remarque justifie le fait}

que l’on ne s’intéresse qu’à un sous-ensemble de scénarios dits minimaux.

11.2.1 N

OTION DE SÉQUENCES MINIMALES

Dans la suite de cette section nous considérons une ensemble

E

d’événements. Nous notons

E?

_{l’ensemble des mots finis sur}

E

et



le mot vide. Étant donné un ordre

<

sur

E?

_{et un sous-ensemble}

L



E?

_{représentant l’ensemble des scénarios critiques, notre}

objectif est le calcul des mots minimaux de

L

pour

<

. En d’autres termes, nous nous intéressons au calcul de l’ensemble

min

(

L

)définit par :

min

(

L

)=f

w

2

L

j8

w

0

2

L;w

0

6

< w

g.

La pertinence du résultat du calcul des séquences est conditionnée par l’ordre

<

. Plusieurs critères de minimalité (l’ordre

<

) pourraient être utilisés.

La longueur : une séquence est minimale si sa longueur est minimale. Bien qu’il soit naturel de penser à ce critère il est bien trop restrictif pour être utilisé. En effet, si l’on suppose qu’il existe deux séquences menant à l’état non souhaité,

ab

et

c

alors, l’ensemble des séquences minimales estf

c

g. Un tel résultat cache l’impli-cation de

a

et de

b

dans la réalisation de l’événement redouté. De plus, d’un point de probabiliste, rien ne permet d’affirmer que

ab

se produise moins souvent que

c

(il suffit que

c

soit une défaillance d’un composant très fiable).

L’ordre préfixe : une séquence

s

est minimale si il n’existe pas dans

L

(l’ensemble des séquences critiques), une séquence

s

0

qui soit un préfixe de (c’est-à-dire qui commence)

s

. Ce critère n’est pas assez restrictif. En effet, l’ensemble de séquencesf

abc;bc

gne contient que des séquences minimales. Mais

a

ne joue qu’un rôle secondaire dans l’occurence de l’état redouté : il est nécessaire que

b

et

c

aient lieu. Une décision efficace pour diminuer le risque d’une situation critique serait d’agir en priorité sur

b

et

c

(ou du moins sur les composants qui leurs sont associés). Cette remarque est aussi valable pour l’ordre sur les facteurs

Dans le document AltaRica : Contribution à l'unification des méthodes formelles et de la sûreté de fonctionnement (Page 100-106)