FR2999318A1 - Procede d'evaluation de la surete de fonctionnement d'un systeme complexe - Google Patents

Abstract

L'invention se rapporte à un procédé d'évaluation de la sûreté de fonctionnement d'un système formé de composants matériels et/ou logiciels. Le procédé comporte au moins les étapes suivantes : • Décomposer les composants du système sous forme de fonctions interconnectées, définir pour chaque fonction des défaillances fonctionnelles associées ; • Définir un évènement redouté du système sous forme d'une expression logique dont les termes sont des entrées et/ou des sorties des fonctions ; • Déterminer des coupes fonctionnelles minimales définissant chacune une combinaison minimale de défaillances de fonctions provoquant l'évènement redouté du système ; • Synthétiser les coupes fonctionnelles minimales déterminées en un ensemble plus réduit de coupes minimales composants matériels ; • Calculer pour chaque défaillance composant intervenant dans une coupe composant un taux de défaillance et un temps d'exposition ; • Calculer une probabilité d'occurrence de l'évènement redouté en fonction des taux de défaillance et des temps d'exposition.

Description

PROCEDE D'EVALUATION DE LA SURETE DE FONCTIONNEMENT D'UN SYSTEME COMPLEXE GENERALITES La présente invention concerne un procédé d'évaluation de la sûreté de fonctionnement d'un système complexe logiciel et/ou matériel comme par exemple un système d'affichage d'informations de vol sur une planche de bord d'un aéronef. Un système d'affichage d'informations de vol comporte notamment une partie logicielle de traitement de données et une partie matérielle comprenant un calculateur, réalisant le traitement de données, et un écran de visualisation par exemple. La sûreté de fonctionnement d'un système peut être définie 15 comme étant la propriété permettant à des utilisateurs du système de placer une confiance justifiée dans les services qu'il leur délivre. Un utilisateur du système peut être un individu tel qu'un opérateur ou un superviseur ou encore, un autre système matériel ou logiciel ayant des interactions avec le système considéré. Selon les applications auxquelles le système est destiné, 20 la sûreté de fonctionnement peut être caractérisée selon des propriétés différentes mais complémentaires comme : la fiabilité, la disponibilité, la sécurité-innocuité, la maintenabilité du système. La fiabilité correspond notamment à la continuité des services que le système doit fournir à ses utilisateurs, en l'absence de réparations. La 25 fiabilité peut également être définie comme l'aptitude d'un système à accomplir une fonction requise, dans des conditions données, pendant une durée donnée. Toutes les défaillances du système de nature accidentelle sont alors prises en compte sans aucune discrimination vis-à-vis de leur criticité. Un exemple de mesure de fiabilité est le taux de défaillances, 30 inverse du temps moyen de fonctionnement jusqu'à la première défaillance. La maintenabilité d'un système traduit son aptitude à supporter des réparations et des évolutions. La maintenance du système doit alors être accomplie dans des conditions données avec des procédures et des moyens prescrits. Un exemple de mesure de maintenabilité est par exemple le temps 35 moyen de réparation ou de restauration du système dans un état de bon fonctionnement.

La disponibilité d'un système est la faculté d'un système à délivrer correctement un service, en termes de délai et de qualité, au moment où l'utilisateur en a besoin. La disponibilité est une mesure sans unité, elle correspond notamment à une proportion du temps de bon fonctionnement sur le temps total de fonctionnement du système. La sécurité-innocuité vise notamment à se protéger des défaillances catastrophiques, c'est-à-dire des défaillances pour lesquelles des conséquences sont inacceptables vis-à-vis des utilisateurs du système ou de l'environnement, par exemple un accident pouvant mettre en jeu des 10 vies humaines. Il est important, voire vital, de maîtriser et de réduire ces défaillances. Afin de prendre en compte les contraintes de sécurité, il est donc nécessaire d'identifier les cas de dysfonctionnements critiques du système, 15 mettant potentiellement en danger le système et/ou les utilisateurs et/ou l'environnement. Un exemple de dysfonctionnement critique pour une macrofonction d'affichage de paramètres de vol peut être l'affichage d'une attitude fausse sur un écran du tableau de bord, sans alarme signalant qu'une telle défaillance s'est produite. Un tel dysfonctionnement peut entraîner une 20 collision avec le sol. Les dysfonctionnements critiques identifiés sont nommés des évènements redoutés. Les contraintes quantitatives de sécurité peuvent porter sur les évènements redoutés, par exemple imposer un objectif maximal de 10-9 pour la probabilité d'occurrence par heure de vol de l'évènement redouté ER. Une 25 autre contrainte de sûreté de fonctionnement qualitative peut être qu'une faute simple ne puisse pas produire à elle seule cet évènement redouté. Un moyen de traiter de telles contraintes, consiste à décomposer chaque évènement redouté ER jusqu'à ses causes racines au moyen d'un arbre de défaillances. Un arbre de défaillances peut se représenter sous la 30 forme d'une structure arborescente dont le sommet est l'évènement redouté ER, les feuilles (évènements de base) représentant des fautes (causes racines pour le matériel, comme par exemple une panne d'un composant électronique) ou des défauts (causes racines pour la conception matérielle ou logicielle, comme par exemple une erreur de codage).

A partir des probabilités d'occurrence des évènements de base, on peut, en remontant dans l'arbre de défaillances, calculer une probabilité d'occurrence de l'évènement redouté ER. Par ailleurs, le calcul des coupes minimales de l'arbre de défaillances peut être effectué. Une coupe minimale est une combinaison d'évènements de base (fautes pour le matériel lui-même, défauts pour la conception matérielle ou logicielle) conduisant à l'évènement redouté, telle que si l'on retire un évènement de cette combinaison, l'évènement redouté ER n'a plus lieu. Les coupes minimales étant par définition les combinaisons critiques conduisant à l'évènement redouté ER, on sait alors quels sont les éléments matériels et logiciels du système dont la ou les défaillances racines (fautes pour le matériel, défauts de conception pour les composants matériels ou logiciels) contribuent le plus, isolés en ou en combinaison, à la réalisation de l'évènement redouté ER.

Une analyse par arbre de défaillances telle que décrite ci-dessus, peut permettre en phase amont, c'est-à-dire lors de la conception de l'architecture du système, de privilégier une architecture matérielle ou logicielle parmi plusieurs architectures, au vu des probabilités d'occurrence d'évènements redoutés ER et de l'existence de coupes simples, pour l'une ou l'autre des architectures proposées. ETAT DE L'ART ANTERIEUR Les systèmes critiques en termes de sûreté de fonctionnement sont de plus en plus complexes, d'où des difficultés croissantes pour les tâches associées de conception et d'analyse. De nombreuses approches pour la sûreté de fonctionnement sont 30 apparues récemment, parmi lesquelles l'approche « modélisation de la logique des défaillances » des composants ou fonctions, laquelle est bien adaptée à la construction hiérarchique et modulaire du système. Les techniques de modélisation de la logique des défaillances comprennent notamment le langage de modélisation AltaRica, autour duquel 35 des outils ont été développés. Ce langage a été développé par le Laboratoire 2 9993 18 4 Bordelais de Recherche en Informatique situé en France 351, cours de la Libération 33405 Talence FRANCE. Elles comprennent également la notation FPTN « Failure Propagation and Transformation Notation », et la méthode HiP-HOPS 5 «Hierarchically Performed Hazard and Operability Studies ». La notation FPTN est par exemple décrite dans la publication de P. Fenelon, et al, : « Towards Integrated Safety Analysis and Design, In ACM Applied Computing Review », 2(1): 21-32, 1994, ACM Press. La méthode HiP-HOPS est par exemple décrite dans la publication de Y. Papadopoulos, 10 et al, « Analysis and Synthesis of the Behavior of Complex Programmable Electronic Systems in Conditions of Failure, Reliability Engineering and System Safety » 71(3): 229-247, 2001, Elsevier Science. La notation FPTN est restée un concept principalement académique, mais la méthode HiP-HOPS et le langage AltaRica ont attiré un 15 intérêt significatif de la part de l'industrie, notamment dans les domaines avionique et automobile. Ils ont été appliqués à de nombreux cas industriels, et ont donné lieu à des essais. Ces approches se heurtent cependant à des difficultés. Pendant 20 les phases amont de conception, les seules informations dysfonctionnelles disponibles pour les composants matériels sont d'ordinaire des estimations grossières du taux total de défaillance. D'autres sources d'imprécision apparaissent pendant la phase de conception détaillée. Les analyses de sûreté de fonctionnement sont souvent basées à ce stade sur les résultats 25 d'un processus de type AMDEC matérielle (Analyse des modes de défaillance, de leurs effets et de leur criticité), connu dans la littérature anglo-saxonne sous le nom de FMEA pour : « failure modes and effects analysis », incluant l'identification pour chaque constituant électronique élémentaire des modes de défaillances élémentaires (fautes) avec leurs taux associés, ainsi que de leurs effets aux niveaux composant et système. Néanmoins, le processus FMEA est très empirique et sujet à erreurs. D'une manière générale, les effets induits au niveau composant par les fautes matérielles identifiées lors d'une analyse FMEA ne correspondent de manière ni claire ni systématique avec l'information requise au niveau composant pour les besoins de la modélisation de la logique dysfonctionnelle. La construction de logiques de défaillance à partir des FMEA aboutit en effet bien souvent à des modèles arbitraires et peu représentatifs de la réalité.

En l'absence de connaissances précises du comportement dysfonctionnel des composants, un choix possible pour leur modélisation, faisant abstraction du processus FMEA, est la définition et l'utilisation, pour chaque composant matériel ou logiciel, de défaillances globales composants, notamment « la perte complète du composant », et la génération de données erronées ou « génération d'erronés ». « Perte complète du composant » signifie que toutes les données générées en sortie du composant sont absentes ou invalides, le taux de défaillances retenu (pour les composants matériels) étant le taux de défaillance complet A du composant. « Génération de données erronées » par le composant signifie que toutes les données générées en sortie sont corrompues, le taux de défaillance retenu étant, en l'absence d'autres précisions, par exemple estimé à 10% A pour les composants matériels. Bien que la modélisation de logique de défaillances composants soit faisable moyennant ces conventions, ainsi que la génération automatique d'arbres de défaillances et la quantification de l'évènement redouté ER, les résultats qualitatifs et quantitatifs obtenus sont peu fiables. Pire, ces résultats peuvent être inconsidérément optimistes, dans la mesure où des comportements dysfonctionnels composant contribuant aux évènements redoutés ER sont fréquemment ignorés, ceci étant dû au caractère simpliste des défaillances composant envisagées (perte complète, génération d'erronés sur toutes les sorties). RESUME DE L'INVENTION L'invention a pour but de proposer une nouvelle méthode pour la modélisation des logiques de défaillances composant accompagnée d'un processus d'analyse adéquat, qui réponde au moins partiellement aux difficultés mentionnées ci-dessus.

A cet effet, l'invention a pour objet un procédé d'évaluation de la sûreté de fonctionnement d'un système formé de composants matériels et/ou logiciels, caractérisé en ce qu'il comporte au moins les étapes suivantes : - Décomposer les composants du système sous forme de fonctions interconnectées, définir pour chaque fonction des défaillances fonctionnelles associées ; - Définir un évènement redouté du système sous forme d'une expression logique dont les termes sont des entrées et/ou des sorties des fonctions ; - Déterminer des coupes fonctionnelles minimales définissant chacune une combinaison minimale de défaillances de fonctions provoquant l'évènement redouté du système ; - Synthétiser les coupes fonctionnelles minimales déterminées en un ensemble plus réduit de coupes minimales composants matériels, chaque élément de coupe étant une défaillance composant ; - Calculer pour chaque défaillance composant intervenant dans une coupe composant un taux de défaillance et un temps d'exposition ; - Calculer une probabilité d'occurrence de l'évènement redouté en fonction des taux de défaillance et des temps d'exposition.

Le calcul de probabilité peut se faire pour l'événement redouté en multipliant pour chaque coupe composant les probabilités associées aux défaillances de la coupe concernée puis en additionnant les produits obtenus pour l'ensemble des coupes composants.

Avantageusement, on classe les défaillances fonctionnelles selon au moins un ensemble de types, un seul type par ensemble ne pouvant être retenu pour chaque défaillance fonctionnelle et en ce que dans un ensemble, un des types est qualifié de dominant, les autres de récessif.

On peut attacher à chaque défaillance composant intervenant dans une coupe composant le ou les mêmes ensembles de types que ceux associés aux défaillances fonctionnelles. Le type retenu pour chacune de ces défaillances composant et pour chaque ensemble sera le type dominant si l'une au moins des défaillances fonctionnelles sous-jacentes est du type dominant, le type retenu dans le cas contraire étant le type récessif.

On peut classer les défaillances selon un premier couple de types alternatifs : « erroné » qualifié de dominant ou « perte » qualifié de récessif, le type erroné étant défini lorsque la défaillance provoque la corruption d'une information, le type perte étant défini dans le cas contraire, notamment lorsque la défaillance provoque la perte d'une information.

On peut classer les défaillances selon un second couple de types alternatifs : « visible » qualifié de dominant ou « dormant » qualifié de récessif, le type visible étant défini lorsque la défaillance est détectable lors du fonctionnement nominal du système, le type dormant étant défini dans le cas contraire, notamment lorsque la défaillance n'est détectable que par les tests de maintenance ou pas détectable du tout. Les taux de défaillance et les temps d'exposition des différentes défaillances composant sont avantageusement définis en fonction des types retenus pour ces défaillances.

Lors de la synthèse, on peut générer pour chaque coupe minimale fonctionnelle une coupe composant dont les éléments sont des défaillances composants, chacune de ces défaillances composant étant obtenue par synthèse des défaillances fonctionnelles de cette coupe comprises dans le composant concerné. Avantageusement, on réduit l'ensemble des coupes composant en supprimant toutes les coupes composant non minimales, une coupe composant étant supprimée si elle est identique à, ou si elle comprend strictement, une autre coupe composant avec des types identiques pour chacune des défaillances composants qui leur sont communes. De plus, on peut effectuer une autre synthèse des coupes fonctionnelles minimales déterminées en un ensemble plus réduit de coupes 35 minimales de défauts de conception composants matériels et/ou logiciels.

Dans cette autre synthèse, on peut considérer des composants de conception similaire comme un seul et même composant.

DESCRIPTION DES FIGURES D'autres avantages de l'invention apparaîtront à la lecture de la description détaillée, description illustrée par le dessin joint dans lequel : la figure 1 représente de façon schématique un système avionique dont les sorties sont des réticules critiques affichés, auquel on peut appliquer le procédé de l'invention ; la figure 2 représente la structure interne des équipements du système de la figure 1 ; la figure 3 représente une décomposition d'un composant matériel 15 du système en fonctions interconnectées ; les figure 4a et 5a représentent sous forme de tableau le contenu de coupes minimales fonctionnelles en termes de défaillances fonctionnelles, avec des types associés ; la figure 4b permet d'illustrer une opération de traduction des 20 coupes minimales fonctionnelles en coupes composants matériels non minimales ; la figure 4c permet d'illustrer une opération complémentaire de compression des coupes composants en un ensemble de coupes minimales composants matériels ; 25 les figures 5b, 5c permettent également d'illustrer ces mêmes opérations de traduction, puis de compression, des coupes minimales fonctionnelles en coupes non minimales de défauts de conception, puis en coupes minimales de défauts de conception pour les composants matériels et/ou logiciels ; 30 la figure 6 représente sous forme de tableau un exemple de liste des coupes minimales composants matériels pour le système de la figure 1 servant d'exemple, ainsi que leurs probabilités associées ; les figures 7a et 7b représentent sous forme de tableaux deux exemples de coupes minimales de défauts. 35 DESCRIPTION DETAILLEE DE L'INVENTION Comme mentionné ci-dessus, la liste des fautes matérielles et de leurs effets, identifiés grâce à la FMEA (quand elle est disponible), est par nature incomplète et empirique, donc peu utilisable pour la modélisation de logiques de défaillances composants. Elle conduit en effet à des modèles manquant de cohérence et ne couvrant que très partiellement l'ensemble des comportements dysfonctionnels composant conduisant aux évènements redoutés ER. Par ailleurs, les notions pour les composants de « perte complète » et « génération d'erronés » qui permettent en principe d'éviter le processus FMEA sont des notions très restrictives, qui conduisent à des résultats grossiers en termes de coupes minimales avec parfois des erreurs sur l'ordre de grandeur de la probabilité de l'évènement redouté ER associé. L'invention permet des évaluations de la sûreté de fonctionnement sans recours au processus FMEA, ni aux notions de « perte complète » ou de « génération d'erronés ».

Décomposition en fonctions et défaillances fonctionnelles Le début de la démarche de l'invention consiste à briser la complexité en décomposant le système en un ensemble de fonctions interconnectées hébergées par des composants. Deux types de composants sont envisagés : les composants matériels et les composants logiciels hébergés par des composants matériels. Des défaillances fonctionnelles sont associées à ces fonctions, comme par exemple : « Perte de données sur une sortie », « Données erronées sur une sortie ». Les logiques dysfonctionnelles des états des sorties de chaque fonction (valide, erronée, absente...) produits par les états des entrées, sont ensuite définies sous forme d'expressions booléennes. Ces logiques prennent en compte l'ensemble des défaillances fonctionnelles associées à la fonction.

On peut classer les défaillances fonctionnelles selon au moins un ensemble de types, les défaillances fonctionnelles ne pouvant être classée que selon un type par ensemble. Habituellement, les ensembles sont des couples et on a donc deux types alternatifs dans un ensemble. Dans un couple de type, un est qualifié de dominant et l'autre de récessif. Il est possible de définir plus de deux types dans un ensemble, un seulement est alors dominant. Par exemple, on peut alors choisir de classer les défaillances fonctionnelles en un premier type « erroné » v.s. « perte », soit E v.s. L. On peut également choisir de les classer en un deuxième type « visible » v.s. dormant », soit V v.s. D. On peut aussi choisir de les classer selon ces deux types simultanément. Les quatre cas ainsi définis sont alors les suivants : « erroné visible » noté EV, « perte visible» noté LV, « erroné dormant » noté ED, « perte dormant » noté LD.

Une défaillance fonctionnelle est du type erroné lorsqu'elle corrompt la valeur d'une information, autrement elle est du type perte (notamment, mais pas exclusivement, lorsque l'information est perdue). Par ailleurs, elle est du type visible lorsqu'elle est détectable via ses effets par un utilisateur ou par les tests mis en oeuvre lors du fonctionnement nominal du système, autrement elle est du type dormant. Ce type de test est connu dans la littérature anglo-saxonne sous le nom de CBIT pour : « Continuous Built In Test ». Une défaillance fonctionnelle est du type dormant lorsqu'elle n'est pas détectable visuellement ou par CBIT lors du fonctionnement nominal du système, mais uniquement par les tests de maintenance, ou encore quand elle n'est détectable par aucun test. Par exemple, « Perte d'une donnée » et « Corruption d'une donnée » sont d'habitude considérées comme visibles si la donnée est présentée en sortie primaire lors du fonctionnement nominal du système, alors que la « perte d'une alarme » pourra être considérée comme dormante, puisque l'alarme n'est pas déclenchée lors du fonctionnement nominal du système. Coupes fonctionnelles minimales L'évènement redouté ER en cours d'analyse est lui-même défini 35 comme combinaison booléenne d'états des entrées et/ou des sorties de certaines fonctions du système. La suite de la démarche consiste à déterminer les coupes fonctionnelles minimales définissant chacune une combinaison minimale d'évènements de base (défaillances fonctionnelles) provoquant l'évènement redouté ER.

Des exemples de coupes fonctionnelles minimales sont donnés dans le tableau de la figure 4a. Les lignes du tableau de cette figure sont des coupes fonctionnelles minimales. Les évènements de base (défaillances fonctionnelles), notés FFik, forment les colonnes du tableau. Chaque coupe minimale FMC; est exprimée par des croix placées dans le tableau à l'intersection de la ligne i et des colonnes. Les évènements de base sont contenus dans des composants matériels notés HCi. On a par exemple 4 évènements de base FFii, FF12, FF13, et FF14, contenus dans le composant HCi. Par ailleurs, l'une des quatre valeurs du type précédemment défini est associée à chaque évènement de base.

Synthèse des coupes fonctionnelles minimales en coupes minimales composants La suite de la démarche consiste à traduire chaque coupe minimale fonctionnelle en une coupe composant matériel. Chaque élément d'une telle coupe (défaillance composant) correspond à un composant et synthétise la ou les défaillances fonctionnelles comprises dans cette coupe, et également comprises dans le composant (coupe partielle). La coupe composant est donc la traduction de la combinaison de coupes partielles qui constitue la coupe minimale fonctionnelle, chaque coupe partielle étant associée à un composant. On peut choisir également d'associer l'un des quatre types de défaillance « erroné visible » (EV), « perte visible » (LV), « erroné dormant » (ED) et « perte dormant » (LD) à chaque défaillance composant. Le type d'une défaillance composant matériel dépendra des types des défaillances fonctionnelles qu'elle synthétise. Une défaillance composant matériel sera par exemple du type « erroné visible » si l'une au moins des défaillances fonctionnelles incluses dans cette défaillance composant est erronée, et si de plus l'une au moins de ces défaillances fonctionnelles est visible. A noter que la défaillance erronée peut être distincte de la défaillance visible. Une défaillance composant matériel sera par exemple du type « perte visible » si aucune des défaillances fonctionnelles incluses dans cette 5 défaillance composant n'est erronée, et si de plus l'une au moins de ces défaillances fonctionnelles est visible. Une défaillance composant matériel sera par exemple du type « erroné dormant » si l'une au moins des défaillances fonctionnelles incluses dans cette défaillance composant est erronée, et si de plus aucune de ces 10 défaillances fonctionnelles n'est visible. Une défaillance composant matériel sera du type « perte dormant » si aucune des défaillances fonctionnelles incluses dans cette défaillance composant n'est erronée et si de plus aucune de ces défaillances fonctionnelles n'est visible. 15 De façon plus générale, pour chaque défaillance composant intervenant dans une coupe composant, le type retenu pour chaque ensemble sera le type dominant si l'une au moins des défaillances fonctionnelles sous-jacentes est du type dominant, le type retenu dans le cas contraire étant le type récessif. 20 La figure 4b illustre pour l'exemple précédent, la traduction des coupes minimales fonctionnelles en coupes composant. La coupe composant CMCi traduite de FMCi comprend les types perte dormant pour le composant HC2 et erroné visible pour le composant HC4, conformément à 25 le règle énoncée ci-dessus. La coupe composant CMC2 traduite de FMC2est constituée du type erroné visible pour HCi. La coupe FMC2 est particulière dans le sens où elle est traduite en une coupe composant simple. La question se pose alors de générer, à partir de l'ensemble non 30 minimal des coupes composants matériels, l'ensemble des coupes minimales composant correspondant à l'évènement redouté ER. Une coupe minimale composant sera également constituée de défaillances composants matériels de l'un des quatre types EV, LV, ED, LD. Avantageusement, on réduit l'ensemble des coupes composant en 35 supprimant toutes les coupes composant non minimales. Autrement dit, on supprime toutes les coupes redondantes, ainsi que les coupes qui contiennent complètement d'autres coupes. Deux coupes composant sont considérées comme redondantes si elles ont les mêmes types de défaillance pour les mêmes composants. Cette opération de réduction est schématisée sur la figure 4c. Par exemple, la coupe CMC3 contient la coupe CMCi. CMC3 n'est donc pas minimale et peut être supprimée. Cet exemple est très simple (trois coupes fonctionnelles). Dans la pratique il peut y avoir plusieurs centaines, voire des milliers de coupes fonctionnelles minimales. La traduction en coupes composant et la synthèse en coupes composants minimales peut par exemple conduire à des ensembles de 10 à 60 coupes composant minimales. Quantification des coupes composant et de l'évènement redouté La suite de la démarche consiste à associer des probabilités d'occurrence aux défaillances composant. Ces probabilités d'occurrence seront les produits des taux de défaillance composant par les temps d'exposition associés à ces mêmes défaillances.

Le taux de défaillance associé à une défaillance composant des types LV ou LD est par exemple celui du composant matériel. Le taux de défaillance associé à une défaillance des types EV ou ED est par exemple une portion du taux de défaillance pour le composant matériel (par exemple 10%).

De façon plus générale, les taux de défaillance et les temps d'exposition des différentes défaillances composant sont définies en fonction des types retenus pour ces défaillances. La probabilité d'occurrence (poids) d'une défaillance composant est par exemple égale au taux de défaillance mentionné ci-dessus multiplié par la durée de la mission pour les défaillances de type visible EV ou LV, ou par la durée séparant deux tests de maintenance permettant de détecter cette défaillance composant, pour les types dormants ED et LD. Il est possible de calculer la probabilité d'occurrence différemment en fonction des types envisagés.

Les coupes minimales composant matériel sont alors aisément quantifiables. Le poids d'une telle coupe est égal au produit des poids des défaillances composant qui la constituent. En effectuant la somme des ces poids pour l'ensemble des défaillances minimales composant, on obtient au bout du compte une estimation pour la probabilité d'occurrence de l'évènement redouté ER. Synthèse des coupes fonctionnelles minimales en coupes de défauts composants On synthétise également les coupes fonctionnelles minimales en coupes minimales défauts de conception composant n'incluant que des défauts (un seul type noté DF, pour les composants matériels comme pour les composants logiciels), et tenant compte des similarités de conception entre composants. Chaque coupe minimale fonctionnelle est traduite en une coupe de défauts composant. Chaque élément d'une telle coupe (défaut composant) correspond à un composant (ou à un ensemble de composants de conception similaire) et synthétise la ou les défaillances fonctionnelles de la coupe fonctionnelle, également comprises dans ce composant ou cet ensemble (coupe partielle). La figure 5b illustre pour l'exemple précédent, la traduction des coupes minimales fonctionnelles en coupes de défauts composant. Les composants HCi et HC2 ont été déclarés de conception similaire et regroupés sous l'appellation HC12. Les composants HC3 et HC4 ont également été déclarés similaires et regroupés sous l'appellation HO34. La suite consiste à générer, à partir de l'ensemble non minimal des coupes défauts composants, l'ensemble des coupes minimales défauts composant correspondant à l'évènement redouté ER. L'algorithme réalisant cette tâche élimine les doublons parmi les coupes de défauts, puis réduit l'ensemble obtenu en supprimant toutes les coupes de défauts non minimales. La figure 5c illustre cette compression de coupes de défauts en coupes minimales. Le procédé de synthèse, c'est-à-dire de traduction/compression 35 des coupes fonctionnelles minimales en coupes minimales de défaut composants décrit ci-dessus, peut être mise en oeuvre sur deux ensembles distincts de composants. Le premier ensemble est constitué par les composants matériels modélisés. Le deuxième ensemble est constitué par les composants logiciels modélisés, auxquels s'ajoutent les composants matériels n'hébergeant pas de composants logiciels. Le procédé de synthèse appliquée à ces deux ensembles produira donc deux jeux distincts de coupes minimales de défauts composants. Conclusion L'approche décrite ci-dessus permet d'obtenir des estimations des probabilités d'occurrence des évènements redoutés ER dans le contexte de l'évaluation de la sûreté pour une projection donnée des fonctions considérées sur les composants. L'optimisation de cette projection correspond aux phases amont de conception du système. Elle s'effectue aisément moyennant des estimations comparatives sur différentes projections, puisque les coupes minimales fonctionnelles restent inchangées quand la projection varie, le réseau sous-jacent des fonctions interconnectées restant lui-même invariant. L'algorithme ci-dessus est donc réitéré sur le même ensemble de coupes fonctionnelles d'entrée, le paramètre d'ajustement étant la répartition pour une projection donnée des défaillances fonctionnelles dans les composants. La même méthode peut être appliquée pendant la phase de conception détaillée du système, fournissant des estimations des probabilités d'occurrence des évènements redoutés ER basés sur des taux de défaillances composant tels que décrits ci-dessus, plutôt que sur des taux de défaillances individuels issus d'une FMEA, ou des taux pour les défaillances composant « perte totale » ou « génération d'erronés ».

MODELISATION D'UN SYSTEME A L'AIDE DU LANGAGE ALTARICA Le langage Altarica a été développé pour modéliser les comportements fonctionnels et dysfonctionnels des systèmes. La 35 construction des modèles Altarica Dataflow (langage réduit, sous-ensemble d'Altarica général) est par exemple supportée par l'outil OCAS développé par Dassault Aviation dont le siège social est situé 9 Rpt Champs Elysées 75008 Paris (France) et par l'outil SD9 développé par Dassault Systèmes dont le siège social est situé rue Marcel Dassault 78140 Vélizy-Villacoublay (France). Ces outils fournissent les fonctionnalités d'édition graphique et de simulation et comprennent un générateur automatique d'arbres de défaillances, ainsi qu'un extracteur de coupes minimales. Un modèle complet Altarica Dataflow construit sous l'outil SD9 ou sous OCAS pour un système complexe, est constitué par un jeu de noeuds interconnectés comprenant des sous-noeuds également interconnectés. On définit un noeud « feuille » comme un noeud ne possédant pas de sous-noeud. Un noeud feuille pourra par exemple représenter une fonction, ou un composant logiciel ou matériel contenant un ensemble de fonctions décrites «à plat » en Altarica textuel. Les noeuds autres que les noeuds feuilles représenteront par exemple des composants d'un niveau hiérarchique supérieur. Les évènements redoutés ER sont saisis sous SD9 ou OCAS comme des expressions booléennes de certaines variables de flux présentes dans le modèle AltaRica. Une génération d'arbre de défaillances peut alors être lancée sur un évènement redouté ER, générant un arbre dont le sommet est l'évènement redouté ER lui-même, et les feuilles des évènements de base AltaRica. En d'autres termes, l'évènement redouté ER s'exprime comme une expression booléenne des évènements AltaRica considérés eux- mêmes comme booléens. Un tel arbre peut être compilé à l'aide d'outils spécialisés (Arbor, Simtree), afin de générer un ensemble de coupes minimales et éventuellement de calculer une probabilité d'occurrence pour l'évènement redouté ER.

MISE EN OEUVRE DE L'INVENTION SUR UN EXEMPLE A titre d'exemple, le procédé de l'invention est mis en oeuvre sur un système avionique comprenant deux écrans principaux de vol du poste de 35 pilotage. Ces écrans sont connus dans la littérature anglo-saxonne sous le nom de « Primary Flight Displays », le système avionique lui-même étant noté « système PFD ». Il est bien entendu que l'invention peut être mise en oeuvre en dehors du contexte aéronautique et pour tout autre système complexe.

L'affichage de paramètres critiques tels que la vitesse, l'attitude, les déviations angulaires de l'axe d'approche à l'atterrissage, etc. d'un avion équipé du système PFD est une tâche critique pour la sécurité de l'avion. Un évènement redouté classé comme catastrophique au niveau du système PFD sera par exemple « affichage erroné non signalé d'un réticule critique à la fois sur les deux écrans PFD du système ». Un évènement redouté classé comme dangereux sera par exemple « affichage erroné non signalé d'un réticule critique sur l'un des écrans PFD ». Description du système La figure 1 représente de manière simplifiée le niveau hiérarchique le plus haut du modèle SD9 pour le système PFD. Il se compose de plusieurs équipements interconnectés, chaque équipement étant modélisé par un noeud Altarica. Plus précisément, le système comprend deux écrans principaux F_PFD et P_PFD (noeuds de niveau supérieur) et deux capteurs F_GNSS et P_GNSS (composants matériels modélisés par des noeuds feuilles) générant chacun un paramètre critique en termes de sécurité (par exemple une déviation angulaire), respectivement F_Par et P_Par. Les deux paramètres sont traités par des processeurs de chaque écran et affichés sous forme de deux réticules graphiques, respectivement F_Ret et P_Ret. Dans les processeurs, des comparaisons sont effectuées entre les deux paramètres critiques d'entrée. En cas d'incohérence, des drapeaux d'alarme respectivement F_Disc et P_Disc sont affichés sur les écrans, par exemple sous forme de réticules spécifiques ou de messages. La figure 2 représente le niveau hiérarchique immédiatement inférieur du modèle, à savoir l'architecture interne d'un équipement PFD de la figure 1, constituée de composants matériels interconnectés. Chacun de 35 ces composants est modélisé par un noeud feuille Altarica. Un réseau de portes programmables ABAC sert d'aiguillage entre la carte d'entrée-sortie 10B, le processeur Proc, les composants mémoire (non représentés), et le processeur graphique GRPR. Les deux paramètres critiques P_Par et F_Par (figure 1), correspondent aux signaux Prim Par et Sec_Par (figure 2). Ces signaux traversent la carte d'entrée-sortie 10B, puis le réseau de portes programmables ABAC, avant d'être présentés en entrée au processeur Proc. Ils sont ensuite traités par le processeur Proc pour générer une commande graphique Cmd_Par, renvoyée vers le processeur graphique GRPR à travers le réseau de portes programmables ABAC. Un module de signature Sign reçoit des images prédéfinies (pixels) générées par le processeur graphique GRPR, en réalise une signature, qui est ensuite retransmise au processeur Proc par l'intermédiaire du réseau de portes programmables ABAC. Le processeur graphique GRPR produit des pixels et pilote l'écran proprement dit, qui est par exemple un écran LCD rétro-éclairé. Le composant matériel de rétro-éclairage porte ici le repère Disp. Un composant matériel de surveillance MDLM surveille l'affichage et notamment son rafraîchissement. Il transmet son constat directement au processeur Proc. Par ailleurs, une surveillance est effectuée en temps réel par le 20 processeur Proc lui-même sur son propre calcul de commande graphique. En cas de traitement erroné, la valeur « actif » est attribuée au drapeau Inv_Flag généré par le processeur Proc. Le drapeau Inv_Flag est traité par le réseau de portes programmables ABAC qui génère, dans le cas où la valeur de Inv_Flag est « actif », un signal Reset en sortie, i.e. une remise à zéro du 25 PFD. Les paramètres Prim_Par et Sec_Par sont également comparés en entrée par le processeur Proc, produisant un drapeau de sortie Disc_Flag de valeur « actif » en cas d'incohérence. Le drapeau Disc_Flag est envoyé vers le processeur graphique GRPR à travers le réseau de portes programmables ABAC. 30 Une définition plus précise pour les évènements redoutés mentionnés ci-dessus tient compte des moyens de surveillance et des sanctions associées. L'évènement redouté classé comme dangereux sera alors par exemple « affichage erroné d'un réticule critique sur l'un des deux écrans PFD sans drapeau d'alarme actif et aucune prise de sanction de remise à zéro ». Décomposition en fonctions et défaillances fonctionnelles Les composants du système sont d'abord décomposés en fonctions. La figure 3 représente par exemple la décomposition du composant matériel Proc en fonctions interconnectées, également comprises dans des composants logiciels FDSA, FDSB, PA. Le composant logiciel FDSA contient les fonctions « Calcul du drapeau de divergence », « Calcul inverse du paramètre capteur à partir de la commande graphique », « Calcul du drapeau inverse ». Le composant logiciel FDSB contient la fonction « Calcul du paramètre image à partir du paramètre capteur », et le composant logiciel PA la fonction « Calcul de la commande graphique ».

Le paramètre Prim_Par est traité par FDSB pour générer un paramètre image Img_Par. Il est ensuite traité par PA pour générer la commande graphique Cmd_Par, elle-même destinée au composant matériel GRPR. Le composant FDSA permet de générer d'une part le drapeau d'alarme Disc_Flag par comparaison des paramètres Prim_Par et Sec_Par en entrée, d'autre part le drapeau d'alarme Inv_Flag par comparaison de Prim_Par et d'un signal Inv_Par obtenu à partir de Cmd_Par par calcul inverse des traitements effectués par PA et FDSB. Disc_Flag signale une éventuelle divergence entre les signaux Prim_Par et Sec_Par issus des deux capteurs. Inv_Flag signale une éventuelle erreur dans le calcul de la commande graphique Cmd_Par. Des défaillances fonctionnelles sont définies pour chacune des fonctions comprises dans les composants, notamment celles listées ci-dessus. Pour la fonction « Calcul de la commande graphique », on considère par exemple les deux défaillances « Perte de la commande graphique » et « Corruption de la commande graphique ». Pour la fonction « Calcul du drapeau de divergence », on considère les deux défaillances « Perte du drapeau de divergence » et « Forçage à inactif du drapeau de divergence ».

Les logiques dysfonctionnelles reliant les états des sorties de chaque fonction à leurs défaillances et aux états des entrées qui les produisent, sont ensuite exprimées sous forme d'expressions booléennes.

L'un des types EV, LV, ED, LD est ensuite attribué à chacune des défaillances fonctionnelles précédemment définies. Par exemple, « Perte de la commande graphique » est classée comme « perte visible » LV. « Corruption de la commande graphique est classée comme « erroné visible » EV. Ces deux défaillances sont visibles car elles sont détectables par le pilote lors du fonctionnement nominal du système (elles impactent l'affichage). Par contre, « Forçage à inactif du drapeau Disc_Flag » est classé comme « perte dormant » LD, puisqu'il est sans impact lors du fonctionnement nominal du système.

Modélisation en langage Altarica du système Les défaillances fonctionnelles sont modélisées en Altarica sous forme d'évènements. « Perte de la commande graphique » est par exemple modélisé par l'évènement Cmd_Par_LO. De même, « Corruption de la commande graphique » est modélisé par l'évènement Cmd_Par_EO. « Perte du drapeau de divergence » est modélisé par Disc_Flag_LO, et « Forçage à inactif du drapeau de divergence » par Disc_Flag_STF. Aux évènements _LO, _EO, _STF, etc. sont respectivement associés des variables d'état Altarica _Loss, _Err, _StuckF. Les variables Cmd_Loss, Cmd_Err, Disc_Flag_StuckF sont par exemple associées aux évènements Cmd_Par_LO, Cmd_Par EO et Disc_Flag_STF. L'activation des évènements _LO et _EO fait passer de faux à vrai la valeur des variables d'état _Loss et _Err. L'activation de Cmd_Par_LO fait par exemple passer de faux à vrai la valeur de Cmd_Par_Loss. De même, l'activation de Cmd_Par_E0 fait par exemple passer de faux à vrai la valeur de Cmd_Par_Err. L'activation de Disc_Flag_LO ou de Disc_Flag_STF fait passer de faux à vrai les valeur de Disc_Flag_Loss ou de Disc_Flag_StuckF respectivement. Par ailleurs, les informations Sec_Par, Prim_Par, Inv_Par, 35 Img_Par, Cmd_Par, Pix_Par, Micrimg, Ret, Img_Sign des figures 2 et 3 sont modélisées en Altarica à l'aide de deux booléens ^PR et _ARL. Le booléen Cmd_ParAPR indique par exemple si l'information Cmd_Par est présente (vrai) ou absente (faux). Par ailleurs, le booléen Cmd_ParARL indique par exemple si l'information Cmd_Par, considérée quand elle est présente, a une valeur intègre (vrai) ou corrompue (faux). Les drapeaux Disc_Flag, Inv_Flag, Disc des figures 2 et 3 sont également modélisés à l'aide de deux booléens "PR et ^ST. Le booléen Disc_FlagAPR indique par exemple si le drapeau Disc_Flag est présent (vrai) ou absent (faux). Le booléen Disc_FlagAST indique par exemple si le drapeau Disc_Flag, considéré quand il est présent, est actif (vrai) ou inactif (faux). Les expressions booléennes exprimant les logiques dysfonctionnelles des fonctions sont modélisées en Altarica par des assertions. A titre d'exemple, le code Altarica correspondant à la fonction 15 « Calcul de la commande graphique » est le suivant : trans -Cmd Par Loss I- Cmd Par LO -> Cmd Par Loss := truc; -Cmd Par Err I- Cmd Par EO -> Cmd Par Err := truc; 20 assert Cmd ParAPR = (!mg ParAPR and -Cmd Par Loss) ; Cmd ParARL = (Img ParARL and -Cmd Par Err) ; 25 La section trans modélise l'activation des deux évènements. La section assert modélise les logiques dysfonctionnelles. Les booléens Img_ParAPR et Img_ParARL sont des expressions logiques des booléens Prim_ParAPR et Prim_ParARL d'entrée, ainsi que des valeurs des deux variables d'état Cmd_Par_Loss et Cmd_Par. Err. 30 Coupes fonctionnelles minimales La suite de la démarche consiste à spécifier l'évènement redouté ER considéré sous forme d'une assertion Altarica. Pour le système PFD, cette 35 assertion est par exemple : ER = ((F RetAPR and -F RetARL and -F Disc and -F Reset) or (P RetAPR and -P RetARL and -P Disc and -P Reset)); Les coupes minimales fonctionnelles sont ensuite générées sous l'outil SD9 ou OCAS pour cet évènement redouté. Pour l'exemple étudié il y en a plusieurs centaines, d'ordre 2, 3 et 4. Synthèse des coupes fonctionnelles minimales en coupes minimales composants La suite de la méthode consiste à synthétiser automatiquement l'ensemble des coupes fonctionnelles minimales en coupes composants matériels minimales. La synthèse tient compte des types « erroné visible » (EV), « perte visible » (LV), « erroné dormant » (ED) et « perte dormant » (LD) associés précédemment à chaque défaillance fonctionnelle. La figure 6 montre les coupes composants ainsi obtenues. Les différents composants sont portés en colonne du tableau et les coupes minimales composant sont portées en lignes du tableau. Les types des défaillances composant sont reportés à l'intersection des lignes et des colonnes comme résultat de la synthèse. Des essais ont montré que par rapport à l'art antérieur où la modélisation et le calcul des coupes composants est réalisé à l'aide des deux défaillances composant « perte complète » et « génération d'erronés sur toutes les sorties », les coupes composants déterminées par synthèse sont plus nombreuses. La nouvelle méthode améliore donc l'exhaustivité de l'évaluation de la sûreté de fonctionnement en mettant en lumière un plus grand nombre de causes d'évènements redoutés.

Quantification des coupes composant et de l'évènement redouté La suite de la démarche consiste à associer des probabilités d'occurrence aux défaillances composant. Ces probabilités d'occurrence sont les produits des taux de défaillance composant par la durée séparant deux 35 tests (CBIT ou maintenance) permettant de détecter les défaillances.

Le taux de défaillance associé à une défaillance composant des types LV ou LD est par exemple 1/MTBF, celui du composant matériel. Le taux de défaillance associé à une défaillance des types EV ou ED est par exemple une portion du taux de défaillance pour le composant matériel, par exemple 10% (1/MTBF). Les probabilités d'occurrence (poids) d'une défaillance composant pour les type EV et LV sont respectivement égales à 10% (1/MTBF) et à 1/MTBF, le temps d'exposition étant de 1 heure (durée de mission). Les probabilités d'occurrence d'une défaillance composant pour les type ED et LD sont respectivement égales à 10% (1/MTBF)*12 et à (1/MTBF)*12, la durée séparant deux tests de maintenance permettant de détecter cette défaillance composant étant de 12 heures. Le poids des coupes minimales est égal au produit des poids des défaillances composant qui la constituent. En effectuant la somme des ces poids pour l'ensemble des défaillances minimales composant, on obtient au bout du compte une estimation pour la probabilité d'occurrence de l'évènement redouté ER. Les chiffres obtenus sont montrés sur la figure 6. Synthèse des coupes fonctionnelles minimales en coupes de défauts composants Il reste à synthétiser automatiquement les coupes fonctionnelles minimales en coupes minimales défauts de conception composant, compte tenu des similarités de conception. Dans l'exemple présenté, les composants des sous-systèmes F_PFD et P_PFD, ainsi que les capteurs F GNSS et P GNSS, sont tous de conception similaire. La synthèse est mise en oeuvre sur deux ensembles distincts de composants. Le premier ensemble est constitué par les composants matériels. Le deuxième ensemble est constitué par les composants logiciels FDSA, FDSB et PA, auxquels s'ajoutent les composants matériels autres que Proc. La figure 7 montre les deux tables obtenues.

Claims (11)

1. REVENDICATIONS1. Procédé d'évaluation de la sûreté de fonctionnement d'un système formé de composants matériels et/ou logiciels, caractérisé en ce qu'il comporte au moins les étapes suivantes : - Décomposer les composants du système sous forme de fonctions interconnectées, définir pour chaque fonction des défaillances fonctionnelles associées ; - Définir un évènement redouté (ER) du système sous forme d'une expression logique dont les termes sont des entrées et/ou des sorties des fonctions ; - Déterminer des coupes fonctionnelles minimales (FMC;) définissant chacune une combinaison minimale de défaillances de fonctions (FF;) provoquant l'évènement redouté (ER) du système ; - Synthétiser les coupes fonctionnelles minimales (FMC;) déterminées en un ensemble plus réduit de coupes minimales composants matériels, chaque élément de coupe étant une défaillance composant ; - Calculer pour chaque défaillance composant intervenant dans une coupe composant un taux de défaillance et un temps d'exposition ; - Calculer une probabilité d'occurrence de l'évènement redouté (ER) en fonction des taux de défaillance et des temps d'exposition.
2. 2. Procédé selon la revendication 1, caractérisé en ce que le calcul de probabilité se fait pour l'événement redouté en multipliant pour chaque coupe composant, les probabilités associées aux défaillances de la coupe concernée puis en additionnant les produits obtenus pour l'ensemble des coupes composants.
3. 3. Procédé selon l'une des revendications précédentes, caractérisé en ce qu'on classe les défaillances fonctionnelles selon au moins un ensemble de types, un seul type par ensemble ne pouvant être retenu pour chaque défaillance fonctionnelle, et en ce que dans un ensemble, un des types est qualifié de dominant, les autres de récessif
4. 4. Procédé selon la revendication 3, caractérisé en ce qu'on attache à chaque défaillance composant intervenant dans une coupe composant le ou les mêmes ensembles de types que ceux associés aux défaillances fonctionnelles et en ce que pour chacune de ces défaillances composant et pour chaque ensemble, le type retenu sera le type dominant si l'une au moins des défaillances fonctionnelles sous-jacentes est du type dominant, le type retenu dans le cas contraire étant le type récessif.
5. 5. Procédé selon l'une des revendications 3 ou 4, caractérisé en ce qu'on classe les défaillances selon un premier couple de types alternatifs : « erroné » (E) qualifié de dominant ou « perte » (L) qualifié de récessif, le type erroné (E) étant défini lorsque la défaillance provoque la corruption d'une information, le type perte (L) étant défini dans le cas contraire, notamment lorsque la défaillance provoque la perte d'une information.
6. 6. Procédé selon l'une des revendications 3 à 5, caractérisé en ce qu'on peut classer les défaillances selon un second couple de types alternatifs : « visible » (V) qualifié de dominant ou « dormant » (D) qualifié de récessif, le type visible (V) étant défini lorsque la défaillance est détectable lors du fonctionnement nominal du système, le type dormant (D) étant défini dans le cas contraire, notamment lorsque la défaillance n'est détectable que par les tests de maintenance ou pas détectable du tout.
7. 7. Procédé selon l'une des revendications 3 à 6, caractérisé en ce 25 que les taux de défaillance et les temps d'exposition des différentes défaillances composant sont définis en fonction des types retenus pour ces défaillances.
8. 8. Procédé selon l'une des revendications précédentes, 30 caractérisé en ce que lors de la synthèse, on génère pour chaque coupe minimale fonctionnelle une coupe composant dont les éléments sont des défaillances composants, chacune de ces défaillances composant étant obtenue par synthèse des défaillances fonctionnelles de cette coupe comprises dans le composant concerné. 35
9. 9. Procédé selon l'une des revendications précédentes, caractérisé en ce qu'on réduit l'ensemble des coupes composant en supprimant toutes les coupes composant non minimales, une coupe composant étant supprimée si elle est identique à, ou si elle comprend strictement, une autre coupe composant avec des types identiques pour chacune des défaillances composants qui leur sont communes.
10. 10. Procédé selon l'une des revendications précédentes, caractérisé en ce qu'on effectue une autre synthèse des coupes fonctionnelles minimales (FMC;) déterminées en un ensemble plus réduit de coupes minimales de défauts de conception composants matériels et/ou logiciels.
11. 11. Procédé selon la revendication 10, caractérisé en ce qu'on 15 considère des composants de conception similaire comme un seul et même composant.