Références - Séminaire vérification de Toulouse

Transcription

Références - Séminaire vérification de Toulouse
pour l’adopter.
Le but ultime est de pouvoir en comparer les bénéfices ou les désavantages par rapport à la méthode sur
laquelle nous travaillons par ailleurs [GIR 96].
Références
[ARN 92]
A. Arnold. Systèmes de transitions finis et sémantique des processus communicants.
Etudes et recherches en informatique, Masson 1992.
[BDF 93]
D. Begay, J. Dormoy et P. Felix. An experiment in developping real-aime systèmes
Ujung Mec. Theories and Experiences for Real-time Development. Editors T. Rus et
C. Rattray, 1994
[BEG]
Didier Begay. Mec Hand Book. Rapport interne du LABRI, Université Bordeaux 1.
[BIU 93]
SRG - bus standard for SPECTRUM-X-Gamma mission Edition 4.1, mars 1992.
[CHA 92]
J.-P. Chabaud. Expérience Diogène - Définition du contexte d’initialisation. Rapport
interne du Centre d’Etude Spatiale du Rayonnement,1992
[GIR 93a]
Patricia Giron. Diogène - Caractéristiques matérielles du système. Rapport interne du
Centre d’Etude Spatiale du Rayonnement, octobre 1993.
[GIR 93b]
Patricia Giron. Spécification fonctionnelle de Diogène. Rapport interne du Centre
d’Etude Spatiale du Rayonnement, décembre 1993
[GIR 94a]
Patricia Giron. Règles d’interprétation de spécifications SA-RT par des systèmes de
transitions étiquetés. Rapport interne de l’IRIT - IRIT/95-06-R - Université Paul
Sabatier, Toulouse III.
[GIR 94b]
Patricia Giron. Construction automatique des systèmes de transitions MEC à partir
d’une représentation d’un diagramme SA-RT. Rapport interne de l’IRIT - IRIT/95-07R - Université Paul Sabatier, Toulouse III.
[GIR 96]
Patricia Giron. Formalisation de la sémantique de diagrammes SA-RT en termes de
systèmes de transitions étiquetés. Accepté au congrès AFCET “Modélisation des systèmes réactifs” - Brest, 28-29 mars 1996.
[HP 87]
D.J. Hatley et I.A. Pirbhai. Stratégies de spécification des systèmes temps réel (SART). MIPS, MASSON 1987.
46
dead:=*-src(*);
infloop:=(*-coreach(dead,*))-dead;
deadtra:=trace(dead,*);
dead :
2 états stables ; ce sont deux états de réussite, c’est-à-dire dans lesquels les réceptions de motX
et motY se terminent avec succès.
infloop : 0 états ; il n’y a donc pas de “livelock”, i.e. de séquences de transitions infinies n’amenant pas
dans un état stable.
deadtra : 7 ; c’est le nombre de transitions nécessaires pour mener à un état stable à partir de l’état initial ;
la réception d’un mot se fait donc en 7 transitions.
• Emission
Taille du produit : 18 états et 32 transitions.
Emit_X:=!state[9]=”0”;
Emit_Y:=!state[9]=”1”;
Il y a 5 manières différentes d’émettre un même mot.
résultat : 5 états.
résultat : 5 états.
1 seul état stable, car nous testons en l’occurrence la fin de la procédure d’émission ;
pas de livelock ;
5 transitions nécessaires pour réaliser l’émission d’un mot par le système.
4.6.3
Testeurs plus évolués
Taille du produit : 54 états et 58 transitions.
13 états stables, dont des états dans lesquels le système est bloqué sans avoir pu recevoir la totalité des mots
émis : cela est du au non déterminisme des testeurs que nous avons définis pour ces vérifications.
Pas de livelock.
Perte et duplication de messages :
recu2Y:=!state[1]=”5”;
résultat : 0 ;
recu0Y:=!state[1]=”8”;
résultat : 0.
Les états “5” et “8” du testeur Tm ne sont jamais atteints : on ne pourra jamais recevoir 2 motY, ni 0.
Nous sommes donc sûrs que notre système ne duplique ni ne perd aucun mot.
5 Conclusions, perspectives
Nous avons montré par l’exemple qu’il était possible d’utiliser les systèmes de transitions étiquetés et leur
produit synchronisé pour spécifier de manière formelle des parties d’applications spatiales embarquées. De
plus, l’outil Mec met à la disposition du développeur utilisant cette méthode un large éventail de vérifications de propriétés très utiles dans ce domaine : des propriétés générales comme deadlock et livelock, mais
aussi des propriétés ad-hoc, comme dans l’exemple présenté, de perte ou de duplication de message dans le
cas d’un protocole de communication.
L’aspect réactif des systèmes ciblés peut être étudié finement grâce aux testeurs qui modélisent des séquences d’événements pouvant se produire, et auxquels les systèmes sont sensés réagir de manière définie, mais
on regrettera que le formalisme des systèmes de transitions étiquetés ne permette pas de représenter une caractéristique souvent présente chez les systèmes critiques : l’aspect temps-réel.
D’autre part, notre souci étant d’apporter à la communauté industrielle des développeurs de logiciels critiques des méthodes performantes en matière de rigueur de développement et de vérifications, il nous reste à
leur soumettre cette méthode afin de déterminer si ses apports justifieraient un investissement de leur part
45
Pour cela, nous définissons les deux testeurs suivants, qui représentent :
- pour le coupleur l’émission d’un message de longueur quelconque dans lequel nous choisissons de distinguer un mot particulier : il s’agira d’une succession de motX au milieu desquels est émis un motY;
e
e
e
message
0
1
e
e
5
7
s_dw_v
s_motY
4
3
fin
8
e
s_motX
s_dw_v
s_dw_v
s_motX
s_dw_v
2
6
e
e
s_dw_v
- pour le microprocesseur les différentes possibilités de réception de ces mots, incluant les possibilités de
ne recevoir aucun motY, et d’en recevoir deux.
e
e
r_motY
0
r_motX
4.6
r_IT
5
3
r_motX
e
r_dw_v
r_motY
2
r_dw_v
e
e
r_dw_v
r_dw_v
6
r_IT
r_IT
1
8
4
7
e
e
e
e
Résultats
Pour vérifier les propriétés du système, il faut maintenant travailler sur les ensembles d’états ou de transitions des produits synchronisés que nous avons définis.
Nous pouvons vérifier, grâce aux différents testeurs que nous avons définis, plusieurs cas de figure en les
faisant participer aux produits synchronisés.
4.6.1
Système global
La taille du système de transitions étiqueté résultat de la synchronisation de l’ensemble des composantes du
système et des deux protocoles Pm et P16b (sans faire intervenir de testeurs) est de :
- 27 états et 60 transitions pour la partie émission,
- 225 états et 629 transitions pour la partie réception,
- 4635 états et 20460 transitions pour l’ensemble (émission et réception).
L’absence de testeurs dans ce produit synchronisé explique l’explosion des nombres d’états et de transitions :: dans ce système sont réunis tous les comportements du système, y compris ceux qui correspondent
à des séquences d’événements externes qu’il serait impossible de rencontrer en cours de fonctionnement
réel, et qu’il est donc légitime d’ignorer.
4.6.2 Réception et émission simples
• Réception :
Taille du produit : 33 états et 50 transitions.
FIFO_X:=!label[6]=”o_motX”;
résultat : 4 transitions.
FIFO_Y:=!label[6]=”o_motY”;
résultat : 4 transitions.
Ceci montre qu’il y a 4 façons différentes pour le système de transmettre le mot X ou le mot Y du coupleur
vers le microprocesseur.
44
4.5.1
Réception et émission simples
Pour tester la réception simple d’un message par Diogène, nous définissons deux testeurs qui modélisent
respectivement l’arrivée d’un message issu du BIUS dans le coupleur, et les données récupérées par le microprocesseur. Le testeur modélisant l’arrivée du message respecte la séquence des événements tels qu’ils
doivent se présenter en cas de fonctionnement normal, et le second testeur décrit la séquence d’arrivée des
données correspondantes telle qu’elle est sensée se produire du côté du microprocesseur.
Les systèmes de transitions étiquetés correspondants sont les suivants :
Testeur simple de réception d’un message par Diogène - côté coupleur
s_cw_v,
s_cw_e,
s_dw_v,
s_dw_e
s_motX, s_motY
message
ri_IT
0
1
2
3
4
e
e
e
e
e
Testeur simple de réception d’un message par Diogène - coté microprocesseur
r_cw_v,
r_cw-e,
r_dw-v,
r_dw_e
r_motX, r_motY
r_IT
0
1
2
3
e
e
e
e
A présent, pour tester l’émission d’un mot par Diogène, nous définissons deux nouveaux testeurs qui modélisent respectivement l’émission d’un mot par le microprocesseur, et les données reçues par le coupleur,
tels que ces séquences événements sont sensées se dérouler en fonctionnement normal.
Les systèmes de transitions étiquetés correspondants sont les suivants :
Testeur simple d’émission d’un mot par Diogène - côté microprocesseur
s_motX,s_motY
s_sw,s_dw
0
1
2
e
e
e
Testeur simple d’émission d’un mot par Diogène - coté coupleur
r_motX,r_motY
r_sw, r_dw
4.5.2
0
1
2
e
e
e
Testeurs plus évolués
Nous pouvons, après avoir pu vérifier grâce aux testeurs définis ci-dessus que les opérations de réception et
d’émission simples se déroulent correctement, nous tourner vers des propriétés plus évoluées du système :
par exemple, l’assurance que le protocole de communication que nous avons défini ne perd pas de mots, ou
encore ne duplique pas certains mots d’un message qui lui est envoyé.
43
4.4
Tm
Pm
IT
rIT
r_pty
FIFO
P_r
e_pty
P_e
P16b
Tc
e
e
e
e
e
e
e
e
e
o_motX
r_motX
e
e
e
e
e
e
e
e
e
o_motY
r_motY
Le protocole
Il s’agit maintenant de décrire le comportement du microprocesseur destiné à mettre en œuvre le protocole
de réception et d’émission de messages.
e
e
réception
e
s_sw, s_dw
in_IT
repos
e_mot
s_motX, s_motY
r_IT
plein
r_cw_v,
r_dw_v,
r_cw_e,
r_dw_e
r_motX,
r_motY
r_mot
e
Le comportement du microprocesseur se scinde en deux parties indépendantes, l’une pour la réception de
message (états réception et lecture), l’autre pour l’émission de mots (émission). Ces deux parties
ne doivent pas interférer, toute séquence de l’une ou l’autre devant être exécutée entièrement avant d’envisager une nouvelle émission ou réception.
La réception d’un message se fait en plusieurs étapes :
La transition in_IT signifie l’arrivée d’un message signalé par le coupleur ; le microprocesseur réagit alors
en passant dans l’état réception à partir duquel il pourra acquérir tous les mots du message.
L’acquisition d’un mot consiste en l’attente du non vide du FIFO (transition vide), puis acquisition du
mot (transitions r_motX, r_motY), et enfin acquisition des bits de contrôle associés au mot (transitions
r_cw_v, r_dw_v, r_cw_e, r_dw_e).
Le premier mot du message portant le nombre total de mots suivants, le microprocesseur met fin à la procédure d’acquisition par la transition r_IT qui correspond à la fin de la procédure d’interruption.
Partie émission d’un message :
Le microprocesseur reste dans l’état repos tant que le port d’émission d’un mot est plein (transition
plein), puis émet successivement un bit de contrôle (transitions s_sw, s_dw) et un mot (transitions
s_motX, s_motY).
4.5
Les testeurs
Maintenant que l’ensemble des entités du système et leurs interactions sont complètement décrites, nous
disposons, grâce à leur produit synchronisé, de la totalité des comportements possibles. Cela représente une
quantité trop importante d’informations, et nous introduisons des systèmes de transitions extérieurs au système, les testeurs, qui nous permettront de nous limiter aux seuls comportements utiles en ce qui concerne
les scenarii que nous voulons étudier. Nous travaillons ainsi sur un sous-ensemble de ce produit synchronisé.
La fonction des testeurs est de représenter des séquences typiques de requêtes venant de l’environnement
du système que nous avons défini, en l’occurrence du Bius, afin de permettre des vérifications dans une approche “Et si...?”.
42
L’ensemble de ces interactions sont regroupées dans le tableau de vecteurs de synchronisation ci-dessous :
4.3.2
Tm
Pm
IT
rIT
r_pty
FIFO
P_r
e_pty
P_e
P16b
Tc
e
e
activer
e
emplir
emplir
e
e
e
e
message
e
in_IT
présent
e
e
e
e
e
e
e
e
r_motX
r_motX
e
e
plein
o_motX
e
e
e
e
s_motX
r_motY
r_motY
e
e
plein
o_motY
e
e
e
e
s_motY
r_motX
r_motX
e
e
vider
o_motX
e
e
e
e
s_motX
r_motY
r_motY
e
e
vider
o_motY
e
e
e
e
s_motY
e
e
e
e
e
e
i_cw_v
e
e
e
s_cw_v
e
e
e
e
e
e
i_cw_e
e
e
e
s_cw_e
e
e
e
e
e
e
i_dw_v
e
e
e
s_dw_v
e
e
e
e
e
e
i_dw_e
e
e
e
s_dw_e
r_cw_v
r_cw_v
e
e
e
e
o_cw_v
e
e
e
e
r_cw_e
r_cw_e
e
e
e
e
o_cw_e
e
e
e
e
r_dw_v
r_dw_v
e
e
e
e
o_dw_v
e
e
e
e
r_dw_e
r_dw_e
e
e
e
e
o_dw_e
e
e
e
e
r_IT
r_IT
e
activer
e
e
e
e
e
e
fin
e
e
e
présent
e
reset
e
e
e
e
e
Séquence d’émission d’un message
L’émission d’un message de la part de Diogène vers le Bius se fait au mot-à-mot, tout message commençant
par un Status Word, mot identifiant Diogène comme expéditeur, et suivi de 0 à 1024 mots de données (Data
Words).
• Séquence d’émission d’un mot
- test de la disponibilité de l’émetteur : tant qu’il n’est pas libre, boucler en attente ;
- lorsque l’émetteur est disponible, émission du bit de contrôle associé ;
- émission du mot de 16 bits
Tm
Pm
IT
rIT
r_pty
FIFO
P_r
e_pty
P_e
P16b
Tc
e
plein
e
e
e
e
e
plein
e
e
e
e
e
e
e
e
e
e
vider
e
e
e
s_sw
s_sw
e
e
e
e
e
vide
i_sw
e
e
s_dw
s_dw
e
e
e
e
e
vide
i_dw
e
e
e
e
e
e
e
e
e
vide
o_sw
e
r_sw
e
e
e
e
e
e
e
vide
o_dw
e
r_dw
s_motX
s_motX
e
e
e
e
e
emplir
e
i_motX
e
s_motY
s_motY
e
e
e
e
e
emplir
e
i_motY
e
41
4.2.5
Le port d’émission d’un mot de 16 bits.
Le comportement du port d’émission diffère de celui du port d’émission du bit d’identification du mot en
ceci qu’un certain temps de latence est nécessaire avant qu’il soit vidé ; Diogène devra donc, on le verra par
la suite, vérifier par le biais du niveau empty correspondant, qu’il peut émettre un nouveau mot. Le système
de transitions étiqueté associé sera à nouveau la représentation générique du port d’émission définie ci-dessus.
Nous distinguons, à fin de vérifications, deux valeurs distinctes : motX et motY.
4.3
Troisième étape : description des interactions entre les entités du système par produit synchronisé
des systèmes de transitions étiquetés qui leur correspondent.
Pour définir entièrement les interactions des entités du système, il suffit de donner les vecteurs contenant
les étiquettes des transitions devant s’effectuer simultanément. Pour cela, nous utilisons un tableau dont la
première ligne décrit les différents composantes. Les noms des entités, abrégés, sont les suivants :
- composantes physiques : IT (IT receipt), rIT (reset IT), r_pty (empty de la partie réception),
e_pty (empty de la partie émission), FIFO, P_e (port d’émission du bit DW / SW), P_r (port de réception des bits de contrôle), P16b (port 16 bits).
- protocole physique : Pm (microprocesseur de Diogène).
- testeurs : Tm (microprocesseur), Tc (coupleur).
4.3.1
Séquence de réception d’un message
A l’arrivée d’un message dans le coupleur, le signal IT receipt est levé, et la totalité des mots du message est stockée dans le FIFO du coupleur de réception. Le signal IT receipt est transmis au contrôleur
d’interruptions qui provoque une interruption de niveau de priorité le plus élevé afin que le microprocesseur
la prenne immédiatement en compte (cela est dû au fait que la réponse à tout message dédié envoyé à Diogène doit survenir avec une forte contrainte temps-réel : au maximum 200 µs après réception). Cependant,
comme nous l’avons précisé précédemment, nous ne représenterons pas les interactions avec le contrôleur
d’interruptions, mais nous considérerons dans le souci de simplifier cet exemple que le signal IT receipt arrive directement au microprocesseur, et provoque ainsi le début de la procédure de récupération
du message.
Cette procédure consiste en une séquence de lectures successives jusqu’au vidage complet du FIFO de réception, quelle que soit la validité des mots.
Le microprocesseur doit enfin remettre à zéro le niveau d’interruption levé, ce qui provoque le master reset
du FIFO.
La composition d’un message est simple : un message commence toujours par un Command Word, ou mot
de commande indiquant à Diogène une directive à respecter, suivi de 0 à 10 Data Words, mots de données,
se rapportant au mot de commande.
• Séquence de lecture d’un mot
- test du empty : tant qu’il n’y a pas de mot, boucler en attente sur ce test ;
- quand empty n’est plus vrai, lire le FIFO ; cette lecture provoque la mise à disposition des
bits de contrôle dans le port associé ;
- lecture du port des bits de contrôle (cette lecture peut servir de test sur le empty pour le mot
suivant).
40
4.2.3
Le FIFO de réception
Son rôle est de stocker tous les mots d’un message provenant du Bius, et à destination de Diogène. Il contient un nombre de mots variable selon le message, mais ce nombre est limité (le Bius peut émettre au maximum 11 mots vers Diogène).
Nous représenterons le FIFO de réception par un système de transitions à deux états, l’un vide, l’autre plein,
considérant que toute lecture d’un mot dans l’état plein peut soit laisser le FIFO dans le même état, soit le
ramener à l’état vide. D’autre part, le cas de lecture du FIFO alors qu’il est vide ne doit pas se présenter en
théorie.
Nous distinguons, pour mettre en œuvre nos vérifications, deux valeurs distinctes : o_motX et o_motY.
Enfin, le signal de remise à zéro de l’interruption reset IT provoque un master reset du FIFO, ce qui le
force à passer à l’état vide.
o_motX,
o_motY
reset
emplir
0
1
e
o_motX,
o_motY,
reset
e
4.2.4 Les ports de réception ou d’émission des bits de contrôle
• Port d’émission du bit d’identification du mot émis par Diogène
Le rôle de ce port est d’accepter une donnée et de la retransmettre immédiatement. Bien que le comportement du port soit neutre vis-à-vis de la donnée qui lui est confiée, il est nécessaire de pouvoir distinguer la
réception et l’émission d’une même valeur ; c’est pourquoi nous ferons précéder le nom de la valeur par
“i_” pour input et “o_” pour output.
Nous distinguons l’émission des deux valeurs possibles, à savoir 0 ou 1, respectivement pour désigner une
donnée (DW) ou son statut (SW).
i_sw
i_dw
vide
1
o_dw
0
o_sw
e
e
e
Nous pouvons alors généraliser cette représentation exhaustive à un système de transitions étiqueté général
dans lequel on appellera α la donnée émise, représentant aussi bien DW que CW.
i_α
vide
α
o_α
e
e
• Port de réception des bits d’identification et de validité du mot reçu
Ce port porte les deux bits d’information concernant le mot reçu. C’est la lecture d’un mot du FIFO qui
rend ces données disponibles jusqu’à ce qu’elles soient recueillies par Diogène.
Nous lui associerons la représentation générique du port d’émission définie ci-dessus.
Les valeurs transportées sont au nombre de quatre :
- deux valeurs possibles du bit d’identification : CW ou DW ;
- deux valeurs possibles du bit de validation : valide (v) ou erroné (e) ;
soit : i_cw_v, i_cw_e, i_dw_v, i_dw_e, o_cw_v, o_cw_e, o_dw_v, o_dw_e.
39
4 Mise en oeuvre de la méthode
4.1
Première étape : Mise en évidence des différentes composantes du système.
Nous modéliserons les composantes suivantes :
- les signaux IT receipt, reset IT,
- les niveaux empty, partie réception et partie émission,
- le FIFO où sont stockés les mots reçus par le coupleur, qui les délivrera un à un aux lectures successives
du microprocesseur,
- le port dans lequel sont stockés les bits d’identification du mot reçu et le bit d’erreur de transmission,
- le port dans lequel Diogène positionne le bit indiquant si l’émission concerne un Status Word ou un Data
Word,
- le port d’émission d’un mot de 16 bits.
4.2
4.2.1
Seconde étape : Associer à chacune des entités issues de la première étape un système de transitions
étiqueté décrivant son comportement, en fonction des propriétés que nous souhaitons
vérifier.
Les signaux
Les signaux sont des informations de contrôle qui disparaissent une fois qu’ils ont été pris en compte par le
destinataire : typiquement, un signal d’interruption ne doit être pris en compte qu’une seule fois pour une
même émission, car les traitements qui lui sont associés ont souvent des répercussions qu’il serait erroné de
répéter de manière non justifiée. Il en est de même pour le signal reset IT.
Les signaux seront donc modélisés par des systèmes de transitions étiquetés à deux états, tels que l’émission
du signal provoque un changement d’état, de manière analogue à un buffer qui passerait dans l’état “plein”;
l’action de tester le signal le fait alors revenir dans l’état initial s’il est présent, ou rester dans l’état initial
s’il y est déjà (c’est-à-dire absent).
absent
activer
0
1
present
e
4.2.2
e
Les niveaux
Un niveau empty indique l’état du FIFO auquel il se rapporte. Il est initialement “empty”, et son état ne
change pas à la consultation.
Les deux niveaux seront donc modélisés par un système de transitions étiqueté à deux états pour lesquels la
consultation (transitions vide et plein) n’aura pas d’incidence sur les états.
plein
vide
emplir
0
1
vider
e
e
38
3 Un exemple issu de Diogène
Tentons d’utiliser l’approche bordelaise pour modéliser une partie de l’expérience Diogène (expérience satellitaire en spectrométrie γ développée au sein du CESR [BIU 93, CHA 92, GIR 93a, GIR 93b]) : la liaison
avec le Bius, ordinateur central du satellite chargé de gérer la bonne marche de l’ensemble des expériences
embarquées sur le satellite. Cette liaison s’opère via un bus standard MIL 1553B.
Diogène est connecté à deux des quatre canaux que possède le bus MIL 1553B, et par conséquent le boîtier
électronique de Diogène possède deux circuits de couplage, dont le schéma ci-dessous présente le synoptique.
Les deux circuits de couplage avec le Bius ont exactement les mêmes caractéristiques ; cependant, selon le
protocole de communication défini par les constructeurs du Bius, l’un d’eux est appelé coupleur “nominal”,
car c’est celui qui servira en temps normal pour les messages dédiés, et le second, le coupleur “redondant”,
ne fonctionnera qu’en cas de panne du premier ou de non-réponse de Diogène, et uniquement à l’initiative
du Bius.
empty
18 bits
reset IT
IT
Interface
d’émission
standard MIL1553B
Port parallèle
IT receipt
DIOGENE
FIFO
sérialisation
BIUS
Interface
de réception
standard MIL1553B
17 bits
empty
Remarque : Nous n’avons pas représenté dans la figure ci-dessus le contrôleur d’interruptions (82C59A
d’HARRIS) par lequel sont gérés les signaux de réception et de remise à zéro des niveaux d’interruption
correspondants.
Partie réception :
Le coupleur reçoit en entrée les signaux Manchester II, les décode et fournit en sortie :
• 18 bits d’information divisés en :
- 1 bit d’identification du mot reçu : CW (valeur 1) ou DW (valeur 0),
- 1 bit d’erreur de transmission,
- 16 bits du mot,
• un signal IT receipt branché sur une interruption du microprocesseur (une pour chaque coupleur).
• un niveau empty pour signaler que le FIFO du coupleur est vide.
Partie émission :
Le microprocesseur fournit sur un port parallèle:
• 17 bits d’information divisés en :
- 1 mot de 16 bits,
- 1 bit d’identification du mot envoyé : SW (valeur 1) ou DW (valeur 0),
• un niveau empty du port parallèle (indiquant que Diogène peut émettre un nouveau mot s’il le désire).
37
Dans une première étape, et pour limiter la complexité des représentations, nous avions choisi de ne prendre
en compte que les aspects exprimés dans les documents issus des étapes de développement SA-RT [GIR
96, GIR 94a, GIR 94b, HP 87]. Mais l’information exploitée est alors trop partielle et masque certains aspects importants pour le fonctionnement du système.
Dans ce qui suit, nous tentons une démarche différente qui consiste à reprendre la conception complète
d’une partie d’un logiciel embarqué en l’exprimant directement dans le formalisme des systèmes de transitions étiquetés, et ceci en reprenant la méthode développée au sein du Labri de Bordeaux. Cette tentative
vise à estimer la taille des systèmes de transitions qui correspondent à cette partie d’une application réelle,
à étudier l’étendue des propriétés que l’outil Mec nous permet de vérifier, et accessoirement à déterminer
si le formalisme en question est accessible à des experts familiarisés avec l’application, mais non avec le
formalisme. La réponse à la première question sera donnée plus tard, après étude en situation avec les personnes concernées. Nous n’apportons ici qu’une réponse aux deux premiers points : il est effectivement possible de développer une partie de notre logiciel embarqué en utilisant le formalisme des systèmes de transitions étiquetés pour spécifier l’interaction du logiciel et de son environnement, et de soumettre le modèle
obtenu à vérification. Les mesures de tailles seront données à la fin de l’article, et commentées en conclusion.
2 La méthode : systèmes de transitions étiquetés et Mec
Le souci de départ de l’équipe du Labri est le même que le notre : apporter au développement de logiciels
critiques plus de rigueur afin d’améliorer notablement les qualités indispensables de robustesse, justesse,
etc... [BDF 93] décrit comment leur méthode a permis le développement de logiciel fiable dans un environnement industriel (produits de mesures et de contrôle à distance dans le domaine de la distribution d’électricité, et plus précisément la programmation à distance de tables tarifaires).
Pour y parvenir, ils ont choisi de baser leurs études sur les systèmes de transitions étiquetés du modèle d’Arnold - Nivat [ARN 92] dans le but de valider le modèle du système qu’ils construiront grâce à l’outil Mec
[BEG].
La méthode consiste en plusieurs points :
- mettre en évidence les différentes parties du système ; cela consiste en une division du système en plusieurs
“entités” dont l’exécution se ferait en parallèle, avec seulement quelques interactions entre ces différentes
entités.
- associer à chacune des entités mises en évidence dans la première étape un système de transitions étiqueté
qui décrit exactement le comportement de l’entité en question dans le système, mais en ne gardant que les
aspects pertinents du comportement, c’est-à-dire en relation étroite avec les propriétés à valider.
- enfin, déterminer les contraintes de synchronisation qui décrivent les interactions des différentes entités
du système comme les synchronisations des systèmes de transitions étiquetés correspondants.
Le système de synchronisation ainsi défini, il suffit alors d’utiliser le système Mec pour mener à bien les
vérifications nécessaires.
Pour ce faire, l’équipe du Labri introduit des entités étrangères au système, appelées “testeurs”, qui seront
eux-mêmes des systèmes de transitions étiquetés, dont le rôle sera de fournir à l’ensemble des entités sous
observation des stimuli externes. Dans le modèle d’Arnold - Nivat, c’est un moyen de restreindre les graphes d’accessibilité aux comportements “utiles”.
36
Développement de systèmes critiques :
une approche par systèmes de transitions
étiquetés
Patricia GIRON
Institut de Recherche en Informatique de Toulouse
118, Route de Narbonne
31062 TOULOUSE Cedex - FRANCE
tel: 61 55 66 11 poste 73 90 / fax: 61 55 62 58
e-mail: [email protected]
résumé
Nous mettons en œuvre l’application d’une méthode de spécification formelle basée sur
l’utilisation des systèmes de transitions étiquetés et de leur produit synchronisé dans un
exemple tiré d’une application spatiale embarquée afin d’en déterminer la faisabilité. Les
vérifications de propriétés - dealock, livelock, etc..., sont réalisées grâce à l’outil Mec.
Mots-clés: méthodes de spécification formelle, systèmes embarqués, systèmes de transitions étiquetés, Mec.
1 Introduction
Les logiciels embarqués, et plus particulièrement les contrôleurs ou systèmes de mesures destinés aux
applications spatiales, doivent donner des garanties de bon fonctionnement plus élevées que de coutume
dans le domaine du développement de programmes. Les méthodes de spécification structurées, qui sont assez largement utilisées, sont certes conviviales et utiles à employer, mais elles n’apportent cependant que
très peu de possibilités de vérifications. L’emploi de méthodes formelles de spécification et de vérification
est alors pleinement justifié par le coût élevé des dysfonctionnements et l’impossibilité de réparer en vol les
erreurs constatées. Le caractère réactif de ces systèmes, c’est à dire leur capacité à maintenir une interaction
permanente avec leur environnement, impose de traiter explicitement en parallèle leur comportement et celui de leur environnement. C’est pourquoi nous avons choisi de les représenter en utilisant les systèmes de
transitions étiquetés. De plus, ce formalisme permet de reprendre bien des résultats développés à partir
d’autres modèles, en particulier celui de la logique temporelle [ARN 92], ce qui rend possible la vérification
des spécifications grâce à l’outil support MEC [BEG]. Les propriétés étudiées peuvent être très générales,
comme la présence de deadlocks ou de livelocks, ou très pointues, c’est-à-dire dépendantes du système.
Mais il est connu que la vérification de modèles est assez onéreuse en place et en temps. De plus, l’usage
de ce formalisme nécessite une bonne initiation.
35

Documents pareils