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

More documents

Recommendations

Info

3.7 Modélisation d’un sous-système logiciel 91 3.7.2 Caractérisation des comportements L’identification des évènements à propager utilise également la spécification fonctionnelle du composant ainsi que son analyse de panne. – Dans la spécification fonctionnelle, nous identifions les modes d’utilisation de la fonction (si celle-ci peut être utilisée dans plusieurs configurations par exemple) et les transitions entre ces modes. – Dans les analyses de pannes, nous identifions les modes de défaillance et les modes de dysfonctionnement de la fonction. Concernant ces analyses de pannes et dans l’optique d’obtenir un certain niveau d’abstraction dans notre modèle, différents modes de défaillance génériques peuvent être définis. De [20], nous tirons la liste non exhaustive présentée dans le tableau 3.6. Défaillances Effets des défaillances Défaillances externes traduites par la qualité des entrées • Une entrée est absente, le logiciel n’est pas • Les résultats des calculs dépendant de protégé cette entrée peuvent être incorrects • Une entrée est incorrecte, le logiciel n’est • Les résultats des calculs dépendant de pas protégé cette entrée peuvent être incorrects Défaillances induites par une erreur de mode • Le mode d’utilisation de la fonction n’est Les résultats des calculs dépendant du mode pas cohérent avec la phase opérationnelle peuvent être incorrects effective Défaillance de la fonction • La fonction est perdue, aucun calcul n’est • Aucune sortie n’est produite effectué • La partie « calcul de données » est erronée Défaillance de la détection • La détection est intempestive • La détection est inefficace ou perdue • Les sorties sont produites mais sont incorrectes quelle que soit la qualité des valeurs en entrée • Quelle que soit la situation, une erreur est signalée • Quelle que soit la situation, aucune erreur n’est signalée Tableau 3.6 – Défaillances d’une architecture logicielle et leurs effets [20] Ensuite, l’utilisation conjointe de la spécification fonctionnelle (celle-ci nous fournit la qualité des données observées par les dispositifs de détection de défaillance) et de l’analyse de panne (celle-ci nous fournit la qualité des données après défaillance), il nous est possible d’identifier une abstraction nous permettant de modéliser les propagations de panne au sein d’un système logiciel. En se référant au tableau 3.6, les valeurs abstraites d’une données sont par exemple {correcte, incorrecte, absente}. Une fois cette abstraction déterminée, [20] construit des tables de décisions pour décrire les calculs en tenant compte des modes de fonctionnement et de dysfonctionnement. Ces tables sont construites pour chaque flux de sortie du nœud AltaRica et sont de la forme « si le composant est dans le mode de (dys)fonctionnement X et si les valeurs des flux d’entrées satisfont la contraintes C, alors la valeur du flux de sortie est Y ». De telles règles peuvent facilement être implémentées sous la forme d’assertions AltaRica.
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.
Page 1 and 2:
THÈSE En vue de l'obtention du DOC
Page 4 and 5:
Table des matières Liste des abré
Page 6 and 7:
Table des figures 1.1 Indicateurs S
Page 8:
Liste des tableaux 1.1 Critère de
Page 12 and 13:
Remerciements Fin de l’étape. ..
Page 14 and 15:
3 que du jus de carotte, même si j
Page 16 and 17:
Introduction L’objectif de cette
Page 18 and 19:
7 l’efficacité de ces activités
Page 20:
Chapitre 1 Concepts généraux auto
Page 23 and 24:
12 Chapitre 1. Concepts généraux
Page 25 and 26:
Page 27 and 28:
Page 29 and 30:
Page 31 and 32:
Page 33 and 34:
Page 35 and 36:
Page 37 and 38:
Page 39 and 40:
Page 42 and 43:
Bien que les arbres de défaillance
Page 44 and 45:
2.2 Syntaxe du langage AltaRica OCA
Page 46 and 47:
Page 48 and 49:
Page 50 and 51:
Page 52 and 53: 2.3 Sémantique du langage AltaRica
Page 60 and 61: 2.4 Outils pour la construction et
Page 62 and 63: 2.5 Autres langages pour la réalis
Page 64 and 65: 2.5 Autres langages pour la réalis
Page 66: Chapitre 3 Vers une méthodologie u
Page 69 and 70: 58 Chapitre 3. Vers une méthodolog
Page 101: 90 Chapitre 3. Vers une méthodolog
Page 112: Chapitre 4 Processus pour la valida
Page 115 and 116: 104 Chapitre 4. Processus pour la v
Page 150 and 151: « Plutôt que de répéter sans ce
Page 152 and 153:
5.1 Bilan de l’activité de modé
Page 154 and 155:
5.1 Bilan de l’activité de modé
Page 156 and 157:
5.2 Bilan de l’activité de valid
Page 158 and 159:
5.2 Bilan de l’activité de valid
Page 160 and 161:
5.3 Accent sur quelques avantages d
Page 162 and 163:
5.4 Quelques bonnes pratiques recom
Page 164:
5.5 Retours sur quelques difficult
Page 167 and 168:
156 Conclusion Cette représentatio
Page 170:
Index AltaRica Assertion, 37 Évèn
Page 173 and 174:
162 Bibliographie [14] Matthias Bie
Page 175 and 176:
164 Bibliographie [47] Jeff Offutt,
Page 177:
Résumé Pour certifier un système
show all

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

Create successful ePaper yourself

Delete template?

Save as template?