Méthodes pour la validation de modèles formels pour la ... - ISAE

92 Chapitre 3. Vers une méthodologie unifiée de modélisation AltaRica de systèmes physiques
Une fois la bibliothèque de fonctions logicielles implémentée, on construit le modèle du
système logiciel étudié par instanciation et interconnexion des nœuds de cette bibliothèque. Les
références [20] et [34] fournissent des exemples d’applications d’une telle méthodologie.
3.7.3 Bilan sur la modélisation d’un sous-système logiciel
Cette section a donc eu pour objectif de décrire le retour d’expérience concernant la modélisation
AltaRica d’un système logiciel tels que présentés dans [20] et [34]. Parmi les points majeurs
à retenir :
– la modélisation d’un système logiciel s’appuie sur des spécifications fonctionnelles des composants
(des fonctions) à modéliser ainsi que sur leurs analyses de pannes ;
– des modes de défaillance génériques peuvent être définis : perte d’une fonction, réalisation
erronée d’une fonction, réalisation intempestive d’une fonction... ;
– la propagation des évènements est monodirectionnelle;
– l’abstraction est relative à la qualité des données transmises - Par exemple, on prendra {correcte,
incorrecte, absente}. Si des tests de détection d’erreurs sont présents, on propagera
également l’information de détection, ou de non détection. On prendra dans ce cas et par
exemple {correcte, erronée non détectée, erronée détectée, absente}.
3.8 Formalisation des données extraites
L’approche proposée dans ce chapitre permet donc de « préparer » la modélisation AltaRica
de systèmes physiques. L’objectif est alors de faciliter le support des analyses de Sûreté de Fonctionnement
effectué sur le système. Or, dans le domaine industriel, il est relativement courant de
devoir gérer plusieurs configurations d’un même système. Par exemple :
– si un équipement du système est fourni par différents fournisseurs ;
– si des modifications ont eu lieu depuis la mise en service initiale du système, celui-ci aura
plusieurs versions en service.
Dans les deux exemples cités ici, nous avons à chaque fois plusieurs configurations d’un même
système et donc plusieurs analyses de Sûreté de Fonctionnement à faire vivre et à maintenir en
parallèle. Les résultats présentés au cours de ce chapitre restant à un stade informel (on parlera de
« spécification informelle » de nœud AltaRica), une attitude naturelle conduit à s’intéresser à la
formalisation des données récoltées à l’aide de notre méthodologie. Nous pourrons alors parler de
« spécification formelle » ou à défaut de « spécification semi-formelle » de nœud AltaRica. Dans
la suite, nous nous permettrons d’utiliser uniquement le terme « spécification ».
Remarque : Nous parlons ici de spécification de nœud AltaRica. Nous pourrions potentiellement
étendre la visée de la démarche et parler de « spécification de modèle de propagations
de pannes ». Le langage AltaRica ne sera que l’outil permettant d’implémenter
les informations recueillies grâce à l’approche proposée et formalisées dans la spécification
évoquée ici.
Plusieurs questions peuvent alors se poser. Comment présenter cette spécification ? Comment
la formaliser ? Que doit elle contenir ? Dans l’optique de répondre à de telles questions,
nous nous intéresserons à la présentation de différents formalismes que nous croyons propices à la
représentation de spécifications. Avant cela, nous nous permettons de fournir quelques arguments
justifiant le besoin de cette formalisation.