FR3006470A1 - Dispositif et procede informatises d'analyse de panne dans un systeme - Google Patents

Abstract

L'invention concerne un dispositif et un procédé informatisés d'analyse de panne dans un système, notamment pour l'analyse de la sûreté de fonctionnement d'un système dans le domaine aéronautique. Le dispositif 1 comprend : - des moyens pour créer un modèle 2 du comportement du système comprenant des composants Ci, Ci-j hiérarchiquement interconnectés pour rendre compte du comportement du système, - un générateur 3 pour générer, à partir du modèle, un arbre de défaillance global 4 représentatif de l'enchaînement logique d'évènements evp pouvant entraîner une défaillance du système, - un moteur d'analyse de défaillance 5 pour déterminer, à partir de l'arbre de défaillance global, une caractéristique P de la défaillance, comme sa probabilité P d'occurrence. Le générateur permet de générer, à partir du modèle, un arbre de défaillance local 6 représentatif de l'enchaînement logique d'évènements evp pouvant entraîner une défaillance locale d'un composant du modèle indépendamment de sa position dans ce modèle. Le moteur permet de déterminer, à partir de l'arbre de défaillance local, une caractéristique P de la défaillance locale, comme sa probabilité P d'occurrence.

Description

Dispositif et procédé informatisés d'analyse de panne dans un système La présente invention concerne un dispositif et un procédé informatisés d'analyse de panne dans un système. Elle trouve une application à l'analyse de la sûreté de fonctionnement d'un système, notamment dans le cadre de la conception d'un système et du choix d'une architecture pour ce système, par exemple dans le domaine aéronautique. Généralement, pour concevoir des systèmes, qu'ils soient simples ou complexes, on utilise un environnement de conception informatisé. Dans un tel environnement de conception, un modeleur graphique permet de définir une architecture comme un ensemble de boîtes hiérarchiques interconnectées.

Cette architecture est analysée sous différents angles de vue. Elle n'est pas redéfinie pour chaque type d'analyse. Pour chaque analyse, on peut associer à tout constituant de l'architecture un modèle statique (déclaratif sur les caractéristiques du constituant) ou dynamique (simulable par exécution du comportement décrit par le modèle). Un modèle peut décrire l'information circulant sur une connexion entre constituants. Cette description dépend du type d'analyse. Au niveau de l'architecture du système, la connexion entre deux constituants décrit une capacité d'échange. Elle peut caractériser la nature de la connexion (par exemple bus Ethernet, USB, câble électrique, tuyau...), mais l'échange lui-même est défini dans le modèle d'analyse. L'analyse de sûreté de fonctionnement est un élément important dans le choix d'architecture pour un système. Il est important de pouvoir évaluer ce critère, si possible à toutes les étapes de la définition de l'architecture d'un système. Une des techniques d'analyse de sûreté de fonctionnement les plus répandues, notamment dans le monde aéronautique, consiste dans l'utilisation d'arbres de défaillance (ou arbre des causes). L'objectif de cette technique déductive est de déterminer les diverses combinaisons possibles d'évènements qui entrainent la réalisation d'un évènement indésirable donné, ou évènement redouté. Ces combinaisons sont représentées par une structure arborescente dont le sommet est l'évènement redouté.

Chaque branche de l'arbre correspond à un enchaînement logique d'évènements, depuis des évènements élémentaires, en passant par des évènements intermédiaires, jusqu'à l'évènement redouté. Un arbre de défaillance permet ainsi d'évaluer la probabilité d'apparition d'un évènement redouté à partir de la probabilité d'apparition des événements élémentaires.

Les évènements qui entrainent la réalisation d'un évènement indésirable ou redoutés sont donc les pannes des constituants du système, ou des évènements induits par l'environnement (pour un avion : choc à l'oiseau, rayonnement électromagnétique,...). La complexité d'un arbre de défaillance dépend de la complexité de l'architecture du système, en particulier du nombre de constituants et du réseau d'interconnexions. Toute modification d'architecture conduit à réétudier l'arbre de défaillance de tous les évènements indésirables ou évènements redoutés. On connaît des environnements informatisés de conception d'un système qui permettent de décrire une architecture de système par des boîtes hiérarchiques interconnectées. On associe aux boîtes feuilles (le plus bas niveau de décomposition) un modèle de comportement. Ce comportement est décrit dans un langage défini pour modéliser les comportements en cas de panne. Le langage est de type séquentiel, c'est-à-dire qu'il décrit des changements d'états provoqués par des successions de pannes. A chacun de ces états correspond la valeur des sorties de ce composant, cette valeur est définie par une affectation de variable. Les variables sont de type booléen, entier ou flottant. Le langage est exécutable. La simulation permet alors d'observer la propagation d'une panne dans l'architecture décrite. Pour convertir de façon correcte un tel modèle séquentiel en arbre de défaillance, ce modèle doit respecter la propriété dite de « confluence ». Cette propriété garantit que l'état atteint après une succession de panne ne dépend pas de l'ordre d'occurrence des pannes. A partir de la modélisation, on peut générer l'arbre de défaillance de l'architecture du système selon deux techniques.

La première technique consiste dans l'utilisation d'un algorithme de calcul d'accessibilité dans le graphe d'état. Cet algorithme suppose que la propriété de confluence ait été préalablement vérifiée, et que toutes les variables soient de types booléens. La seconde technique consiste dans la simulation exhaustive. Cette simulation ne présuppose pas la propriété de confluence mais identifie les séquences obtenues par simulation à un arbre (on ne tient plus compte de l'ordre d'apparition des pannes). Cette identification est justifiée par son caractère « conservatif » pour le calcul de probabilité (la probabilité ainsi obtenue est supérieure à la probabilité modélisée). Pour pouvoir visualiser et analyser les arbres de défaillance, il faut utiliser un environnement distinct du précédent, qui ignore l'architecture préalablement définie.

Dans cet autre environnement, l'analyse des arbres de défaillance est réalisée par un moteur de calcul, qui permet de calculer la probabilité d'occurrence d'un évènement. L'analyse d'arbre de défaillance et la modélisation de l'architecture du système sont donc réalisées dans deux environnements, et sont donc considérées comme deux problématiques disjointes. La simulation dans l'environnement de visualisation permet certes de visualiser la propagation d'une panne, mais ne donne pas d'information sur la probabilité de l'évènement redouté déclenché. Par ailleurs, dans l'environnement de modélisation, l'utilisation d'un langage de modélisation séquentiel induit des temps de calcul qui peuvent pénaliser l'analyse de modèles de grande taille. Le calcul du point d'initialisation peut entrainer un temps d'attente important au lancement d'une simulation. En outre, la génération de l'arbre de défaillance dans l'environnement de visualisation, selon les deux techniques mentionnées plus haut, présente des inconvénients. Ainsi, la technique algorithmique, avec utilisation d'un algorithme de calcul d'accessibilité dans un graphe d'état, est complexe et couteuse en temps de calcul. Pour simplifier l'algorithme, il faut limiter le domaine de modélisation à un domaine pouvant générer des arbres de défaillance, c'est-à-dire à un domaine modélisable par un modèle globalement confluent. Cela simplifie l'algorithme, mais pas nécessairement la vérification de la confluence globale. De plus, la taille des arbres générés les rend illisibles, et l'arbre généré à partir du modèle ne correspond pas à celui que l'on aurait écrit « à la main ». La technique de simulation exhaustive, quant à elle, engendre des temps d'exécution importants pour les modèles de grande taille, nécessitant de limiter l'ordre des séquences générées (nombre d'évènements de panne dans une séquence). On valide la transformation de séquences en arbre par le caractère conservatif de cette transformation, mais on est obligé de faire une approximation non conservative en limitant l'ordre des séquences (la probabilité obtenue à partir d'une séquence limitée est inférieure à celle obtenue lorsqu'on prend en compte tous les évènements).

De plus, un arbre généré par simulation est une fonction monotone (seule la présence d'un évènement intervient et jamais son absence). Or certains modèles, en particulier ceux pour lesquels la qualité d'une sortie du composant n'est pas définie par un simple booléen (bon/mauvais) mais par un ensemble fini de valeurs possibles (bon/moyen/mauvais), sont décrits par des arbres dits « non cohérent », c'est-à-dire des arbres qui comportent des portes « not ». Obtenir, par simulation, un arbre potentiellement non cohérent serait consommateur de temps de calcul.

On connaît également des environnements qui permettent d'importer une architecture définie dans un environnement externe, et d'associer aux constituants de cette architecture la description de leur mode de panne (identification des évènements de pannes internes et de leur conséquence sur les sorties du composant).

Le mode de panne est décrit par une équation booléenne qui affecte à la valeur d'une sortie du composant le résultat d'une seule porte logique (ET ou OU) dont les entrées sont les entrées du composant et/ou un état de panne. Les évènements redoutés sont les sorties non connectées des composants de l'architecture importée. Pour chacun des évènements redoutés un arbre de défaillance est généré. Un tel environnement n'est cependant pas couplé à un outil d'analyse de sûreté de fonctionnement. En outre, le couplage avec l'architecture importée est faible. En effet, une fois l'architecture importée, elle ne peut plus être raffinée. L'ensemble des interfaces nécessaires pour l'analyse de sûreté de fonctionnement doit donc avoir été défini en amont. Un tel outil ne permet pas de « redessiner » l'architecture, et ne permet donc pas de visualiser graphiquement la propagation des pannes. Un tel outil présente d'autres limitations, comme le fait que la connexion d'une entrée d'un constituant à la porte logique qui décrit un mode de panne utilise le nom de cette entrée. Si le constituant est modifié dans l'architecture, il faut réécrire le mode de panne après ré-import de la nouvelle architecture. De plus, la limitation de la description d'un mode de panne par une seule porte logique nécessite une définition très détaillée de l'architecture et ne permet pas d'associer un modèle à un composant structuré.

Egalement, le fait qu'un évènement redouté soit toujours une sortie d'un modèle ne permet pas d'analyser un système complexe dans lequel une sortie d'un sous-système est à la fois un évènement redouté et une entrée d'un autre sous-système. Un des buts de l'invention est donc de résoudre les problèmes précités. Ainsi, l'invention a notamment pour objectif de permettre d'analyser une architecture système en prenant en compte au plus tôt dans le processus de définition de l'architecture le critère de sûreté de fonctionnement. Ainsi, l'invention a pour objet, selon un premier aspect, un dispositif informatique d'analyse de panne dans un système comprenant des constituants. Le dispositif comprend : - des moyens de création d'un modèle de l'architecture du système, représentatif du comportement du système et comprenant des composants correspondants aux constituants du système et interconnectés de façon à rendre compte du comportement des constituants du système, certains des composants étant hiérarchiquement dépendants d'autres composants selon une relation de dépendance dite de composition, un générateur apte à générer, à partir du modèle, un arbre de défaillance global représentatif de l'enchaînement logique d'évènements susceptibles d'entraîner une défaillance du système, - un moteur d'analyse de défaillance apte à déterminer, à partir de l'arbre de défaillance global, au moins une caractéristique de la défaillance, notamment la probabilité de l'occurrence de cette défaillance. En outre, le générateur est apte à générer, à partir du modèle, un arbre de défaillance local représentatif de l'enchaînement logique d'évènements susceptibles d'entraîner une défaillance locale au niveau d'un composant quelconque du modèle, quelle que soir la position de ce composant dans le modèle.

Par ailleurs, le moteur est apte à déterminer, à partir de l'arbre de défaillance local, au moins une caractéristique de la défaillance locale, notamment la probabilité de l'occurrence de cette défaillance locale. Par arbre de défaillance global, on entend donc toutes les combinaisons possibles ou enchaînements logiques possibles d'évènements susceptibles d'entraîner une défaillance du système par la réalisation d'un évènement désirable ou redouté donné au niveau du système, et exprimés sous forme arborescente. Par ailleurs, on entend donc par arbre de défaillance local toutes les combinaisons possibles ou enchaînements logiques possibles d'évènements susceptibles d'entraîner une défaillance d'un composant du modèle par la réalisation d'un évènement désirable ou redouté donné au niveau de ce composant, et exprimés sous forme arborescente. Suivant certains modes de réalisation, le dispositif comprend en outre une ou plusieurs des caractéristiques suivantes, prise(s) isolément ou suivant toutes les combinaisons techniquement possibles : - le générateur est apte à générer l'arbre de défaillance global à partir des arbres de défaillances locaux représentatifs de l'enchaînement logique d'évènements susceptibles d'entraîner des défaillances locales au niveau des composants respectifs du modèle, - le générateur est apte à générer l'arbre de défaillance global à partir des arbres de défaillances locaux, de manière récursive en générant les arbres de défaillance globaux de sous-systèmes comprenant chacun des sous-ensembles de composants correspondants aux constituants du système, - les moyens de création du modèle et le générateur sont aptes respectivement à créer le modèle et à générer l'arbre de défaillance global et les arbres de défaillance locaux, à partir d'une bibliothèque d'objets commune et un langage de scripts commun. - le générateur est apte à générer l'arbre de défaillance global et les arbres de défaillance locaux sous la forme d'ensembles d'une ou plusieurs équations booléennes, - le dispositif comprend un module de représentation graphique d'arbre de défaillance apte à générer une représentation graphique de l'arbre de défaillance global et des arbres de défaillance locaux sous la forme de structures de donnée arborescentes dont les feuilles sont des évènements susceptibles d'entraîner une défaillance du système, respectivement du composant, et dont les noeuds sont des portes logiques auxquelles sont associés des défaillances, - le module de représentation graphique d'arbre de défaillance est apte à générer les structures arborescentes en sorte que les caractéristiques des défaillances soient représentées directement dans la représentation graphique de ces structures arborescentes, - le dispositif comprend un module de représentation graphique de modèle apte à générer une représentation graphique du modèle, et ce module de représentation graphique est apte à représenter la caractéristique d'une défaillance locale, déterminée par le moteur, directement dans la représentation graphique du modèle au niveau du composant correspondant, - le module de représentation graphique de modèle est apte à générer la représentation graphique du modèle en sorte que tout ou partie des évènements soient représentés directement dans cette représentation graphique, associés aux composants correspondants, - le générateur est apte à reconstruire automatiquement l'arbre de défaillance global et les arbres de défaillance locaux à partir de toute modification dans le modèle, - le dispositif comprend un moyen d'injection d'une panne dans le modèle, au niveau d'un composant quelconque de ce modèle, un moyen de propagation de cette panne dans le modèle, et un moyen de visualisation dans le modèle de la propagation de la panne injectée. L'invention a également pour objet, selon un deuxième aspect, un procédé d'analyse de panne dans un système comprenant des constituants. Le procédé comprenant : une étape de création d'un modèle de l'architecture du système, représentatif du comportement du système et comprenant des composants correspondants aux constituants du système et interconnectés de façon à rendre compte du comportement des constituants du système, certains des composants étant hiérarchiquement dépendants d'autres composants selon une relation de dépendance dite de composition, une étape de génération, à partir du modèle et au moyen d'un générateur, d'un arbre de défaillance global représentatif de l'enchaînement logique d'évènements susceptibles d'entraîner une défaillance du système, une étape d'analyse de défaillance, à partir dudit arbre de défaillance global et au moyen d'un moteur d'analyse de défaillance, pour déterminer au moins une caractéristique de la défaillance, notamment la probabilité de l'occurrence de cette défaillance, Le procédé comprend également : au moins une étape de génération, à partir du modèle et au moyen du générateur, d'un arbre de défaillance local représentatif de l'enchaînement logique d'évènements susceptibles d'entraîner une défaillance locale au niveau d'un composant quelconque du modèle, quelle que soir la position de ce composant dans le modèle, et au moins une étape d'analyse de défaillance, à partir de l'arbre de défaillance local et au moyen du moteur d'analyse de défaillance, pour déterminer au moins une caractéristique de la défaillance locale, notamment la probabilité de l'occurrence de cette dite défaillance locale.

Suivant certains modes de réalisation, le procédé comprend en outre une ou plusieurs des caractéristiques suivantes, prise(s) isolément ou suivant toutes les combinaisons techniquement possibles : - l'étape de génération de l'arbre de défaillance global génère cet à partir des arbres de défaillances locaux représentatifs de l'enchaînement logique d'évènements susceptibles d'entraîner des défaillances locales au niveau des composants respectifs du modèle, - l'étape de génération de l'arbre de défaillance global à partir des arbres de défaillances locaux, est une étape récursive qui génère les arbres de défaillance globaux de sous-systèmes comprenant chacun des sous-ensembles de composants correspondants aux constituants du système, - l'étape de création du modèle et l'étape de génération de l'arbre de défaillance global et des arbres de défaillance locaux, utilisent une bibliothèque d'objets commune et un langage de scripts commun, - l'étape de génération de l'arbre de défaillance global et l'étape de génération d'un arbre de défaillance local génèrent l'arbre de défaillance global et les arbres de défaillance locaux sous la forme d'ensembles d'une ou plusieurs équations booléennes, - le procédé comprend une étape de représentation, graphique, au moyen d'un module de représentation graphique d'arbre de défaillance, de l'arbre de défaillance global et des arbres de défaillance locaux sous la forme de structures de donnée arborescentes dont les feuilles sont les évènements susceptibles d'entraîner une défaillance du système, respectivement du composant, et dont les noeuds sont des portes logiques auxquelles sont associés des défaillances, - les caractéristiques des défaillances sont représentées directement dans la représentation graphique des structures arborescentes, - le procédé comprend une étape de représentation graphique, au moyen d'un module de représentation graphique de modèle, pour générer une représentation graphique du modèle, et la caractéristique d'une défaillance locale, déterminée par le moteur, est représentée directement dans la représentation graphique du modèle au niveau du composant correspondant, - tout ou partie des évènements sont représentés directement dans la représentation graphique du modèle, associés aux composants correspondants, - toute modification dans le modèle entraîne une reconstruction automatique, au moyen du générateur, de l'arbre de défaillance global et des arbres de défaillance locaux, - le procédé comprend une étape d'injection d'une panne dans le modèle, au niveau d'un composant quelconque de ce modèle, une étape de propagation de cette panne dans le modèle, et une étape de visualisation dans le modèle de la propagation de la panne injectée. L'invention a encore pour objet, selon un troisième aspect, un programme d'ordinateur comportant des instructions logicielles qui, lorsqu'il s'exécute sur une unité de traitement d'informations intégrée à un dispositif informatique, met en oeuvre le procédé tel que présenté ci-dessus. Ainsi, le dispositif et le procédé de l'invention permettent de construire un arbre de défaillance en cohérence avec une définition d'architecture du système. Les modifications de l'architecture du système entraînent automatiquement une reconstruction de l'arbre. Le dispositif et le procédé de l'invention reposent notamment sur le principe de l'association d'arbres de défaillance locaux aux constituants de l'architecture, quel que soit leur niveau de décomposition dans la hiérarchie des composants du modèle. Un arbre de défaillance local est une fonction qui donne la qualité de la sortie d'un composant du modèle, donc d'un constituant de l'architecture du système, en fonction de la qualité de ses entrées et de ses états de panne interne. La qualité est codée par une variable booléenne. L'arbre est ainsi une équation booléenne.

Un arbre de défaillance local peut être très simple, lorsqu'il est par exemple associé à un composant élémentaire, c'est-à-dire un composant qui n'a pas de fils dans la hiérarchie des composants du modèle (une feuille). Un arbre de défaillance local peut aussi être complexe, lorsqu'il est par exemple associé à un macro-composant, c'est-à-dire un composant qui est à un niveau intermédiaire élevé dans la hiérarchie des composants du modèle (un noeud). Le dispositif et le procédé de l'invention utilisent donc les connexions entre les composants du modèle pour générer l'arbre de défaillance de n'importe quel noeud du système.

La mauvaise qualité d'un noeud du système est un évènement redouté que l'on identifie dans une étude préalable à la modélisation. Un évènement redouté ne dépend pas forcément de tous les constituants du système. En particulier dans le cas d'une architecture globale d'un système constitué de sous-système faiblement couplés. On appelle cône d'influence d'un évènement redouté l'ensemble des constituants de l'architecture (ou composants du modèle) qui contribuent à sa qualité. L'arbre de défaillance d'un évènement redouté est une fonction de tous les états de panne des constituants du cône d'influence. Le dispositif et le procédé de l'invention permettent de visualiser ce cône d'influence par simulation de la propagation des pannes dans l'architecture.

Le modèle global constitué de tous les arbres élémentaires interconnectés, est couplé à un moteur d'analyse d'arbre de défaillance. Les résultats d'analyse fournis par ce moteur sont remontés dans le modèle, ce qui permet de visualiser par exemple la probabilité d'occurrence d'un évènement redouté, et ce en n'importe quel noeud du modèle.

Le dispositif et le procédé de l'invention permettent une analyse « par morceaux » de l'architecture du système. Les sous-systèmes peuvent être analysés indépendamment. Les arbres générés pour ces sous-systèmes sont réintégrés dans une architecture globale de façon à analyser les interdépendances entre sous-systèmes et analyser des évènements redoutés de niveau système global.

Le dispositif et le procédé de l'invention permettent de définir graphiquement les équations booléennes des arbres locaux, par interconnexion de portes logiques par exemple disponibles dans une bibliothèque, ou de définir ces équations textuellement. Les évènements redoutés sont spécifiés en connectant des objets de visualisation, qui peuvent par exemple être également disponibles dans une bibliothèque, ce qui permet d'afficher les caractéristiques telles que les probabilités d'occurrence de ces évènements.

La simplicité des modèles (équation booléennes) permet d'éviter les problèmes de performance connus dans l'état de la technique. La définition des interfaces des composants du modèle nécessaires à l'analyse est réalisée dans le modèle d'analyse lui-même, sans modifier l'architecture globale qui est définie pour tous les types d'analyse, alors que dans l'état de la technique, il est nécessaire de définir un modèle d'architecture dédié car toutes les interfaces nécessaires doivent avoir été définies en amont. L'affichage de caractéristiques telles que la probabilité d'occurrence des évènements redoutés directement dans la représentation graphique du modèle permet une comparaison rapide de plusieurs architectures candidates sous l'angle de la sûreté de fonctionnement. Or, l'analyse de sûreté de fonctionnement est un élément important dans le choix d'architecture. La représentation des arbres de défaillance comme des structures de données arborescentes compactes, permet une visualisation et une navigation aisée, même dans un arbre de grande taille. Les caractéristiques et avantages de l'invention apparaitront à la lecture de la description qui va suivre, donnée uniquement à titre d'exemple, et non limitative, en référence aux figures annexées suivantes : - La figure 1 est une représentation schématique d'un exemple de dispositif selon l'invention - La figure 2 est une représentation schématique de la représentation graphique d'un exemple de modèle avec visualisation de la probabilité d'occurrence d'un évènement redouté à un niveau local ; - La figure 3 est une représentation schématique de la représentation graphique de l'arbre de défaillance local correspondant au contexte de la figure 2; La figure 4a est une représentation schématique d'exemples de portes logiques avec leur signification logique ; - La figure 4b est une représentation schématique d'un exemple de représentation graphique d'une panne ; - La figure 4c est une représentation schématique d'un exemple de représentation graphique d'un arbre de défaillance local associé à un composant de type « Echangeur air ». Le dispositif 1 tel que représenté schématiquement à la figure 1 à titre d'exemple, comprend des moyens de création d'un modèle, qui permettent de créer un modèle 2 de l'architecture d'un système.

Ces moyens (non représentés sur la figure 1) comprennent par exemple, et notamment, une bibliothèque d'objets de modélisation. Ce modèle 2 comprend des composants Cl, C1-1, C2 et C3, qui correspondent à des constituants de l'architecture du système. Ces composants sont interconnectés, de façon à rendre compte du comportement des constituants du système. Certains de ces composants, comme Cl et C1-1, peuvent être liés par une relation hiérarchique de dépendance, de type relation de composition. Ainsi, dans l'exemple, C1-1 correspond à un composant élémentaire du macro-composant Cl. Un générateur 3 permet de générer, à partir du modèle 2, un arbre de défaillance global 4, qui est représentatif de l'enchaînement logique d'évènements de panne evp. De tels évènement de panne evp sont des évènements susceptibles d'entraîner une défaillance du système. Ce générateur 3 permet également de générer, toujours à partir du modèle 2, un arbre de défaillance local 6, représentatif de l'enchaînement logique d'évènements de panne evp susceptibles d'entraîner une défaillance locale au niveau d'un composant quelconque du modèle 2, quelle que soit la position de ce composant dans ce modèle 2. Dans l'exemple, il s'agit du composant C2. Ainsi, l'arbre de défaillance global 4 regroupe toutes les combinaisons possibles ou enchaînements logiques possibles d'évènements evp susceptibles d'entraîner une défaillance du système par la réalisation d'un évènement désirable ou redouté donné au niveau de ce système, ces combinaisons ou enchaînements logiques étant exprimés sous forme arborescente. De même, l'arbre de défaillance local 6 regroupe toutes les combinaisons possibles ou enchaînements logiques possibles d'évènements evp susceptibles d'entraîner une défaillance d'un composant local du modèle par la réalisation d'un évènement désirable ou redouté donné au niveau de ce composant, ces combinaisons ou enchaînements logiques étant exprimés sous forme arborescente. Un moteur d'analyse de défaillance 5 permet de déterminer, à partir de l'arbre de défaillance global 4, une caractéristique de la défaillance, telle que la probabilité d'occurrence de cette défaillance.

Ce moteur d'analyse 5 permet également de déterminer, à partir d'un arbre de défaillance locale tel que l'arbre 6, une caractéristique de la défaillance locale correspondante, par exemple la probabilité d'occurrence de cette défaillance. Les arbres de défaillance 4, 6, qui, rappelons-le, sont définis à la base par des équations booléennes, peuvent être définis par interconnexion de portes logiques 8, par exemple disponibles dans une bibliothèque, ou textuellement.

Le générateur 3 comprend notamment un compilateur dont la fonction est notamment de mettre en équations booléennes minimales le système décrit par des équations associées à des constituants interconnectés. Ainsi, le compilateur traduit les connexions entre composants Ci du modèle 2 par des égalités entre variables et élimine les variables inutiles. Ce travail est réalisé dans la première phase de compilation et le résultat est fourni dans un fichier qui donne toutes les équations permettant de calculer les sorties du modèles. Le cône d'influence de chaque sortie est calculé. La bibliothèque utilisée pour les portes logiques contient des portes logiques 8 10 définies de telles façon que la fonction réalisée par chaque porte se retrouve telle quelle dans le résultat de la mise en équation (pas d'algorithme requis). Pour obtenir le cône d'influence d'un évènement redouté evp (ou evr tel que représenté à la figure 3), il suffit de modéliser l'objet qui permet de désigner un noeud du système dans le modèle 2 comme évènement redouté par un connecteur de sortie. 15 Les évènements de panne evp sont modélisés par un objet que le compilateur va identifier comme une entrée externe pour lequel il ne va pas établir une équation. La probabilité de l'évènement evp est donnée par un paramètre. De préférence, le générateur 3 utilise un langage qui permet l'appel à des fonctions externes écrites dans un autre langage, ce qui facilite le couplage au moteur 20 d'analyse 3 des arbres de défaillance 4, 6. Dans la bibliothèque d'objets utilisés pour générer les arbres de défaillance 4, 6, les portes logiques 8 sont codées de façon à retrouver l'équation booléenne correspondante dans le fichier d'équation fourni par le compilateur. Le nombre d'entrée d'une porte logique 8 doit être variable pour obtenir un 25 schéma concis. L'observation d'arbres de défaillance réalisés «à la main » permet de fixer un nombre maximum d'entrée des portes logiques qui dépend du domaine dans lequel on réalise l'analyse (aéronautique par exemple). Cette limitation n'interdit cependant pas de définir une porte logique 8 avec un nombre d'entrées plus important, mais elle ne permet pas de le faire avec une seule instance. 30 Les portes logiques 8 fournies dans la bibliothèque sont par exemple des portes «AND », «OR, « NOT », « NAND », « NOR » et « PIN », telles que symbolisées dans le tableau représenté en figure 4a. Une panne dans le système est modélisée par un objet de type évènement. La représentation graphique de cette objet est celle normalisée par le standard graphique 35 des arbres de défaillance, tel que représenté en figure 4b.

On peut définir une probabilité d'occurrence de cet objet panne, définie par une loi de distribution et les constantes associées à cette loi. Il peut s'agir par exemple d'une loi exponentielle. Il s'agit de la loi la plus utilisée dans les études de sûreté de fonctionnement.

Un seul paramètre est associé à cette loi : un taux de défaillance À constant dans le temps. Cette loi est définie par : Q(t) = 1 - Il peut aussi s'agir, dans un autre exemple, d'une loi de Poisson. Un composant est alors considéré comme étant constitué de m redondances identiques. La probabilité de défaillance de chaque redondance est définie par une loi exponentielle de coefficient À. La loi de probabilité d'un tel composant est donnée par : Q4(t) -= 1 - (ilt)k k=0 e Le modèle de panne fournit un paramètre booléen, modifiable par l'utilisateur, qui est utilisé pour injecter des pannes dans le modèle 2. Si le paramètre vaut « faux> la panne est absente, s'il vaut « vrai » la panne est présente. Ce paramètre peut être affecté en mode simulation pour observer la propagation d'une panne dans le modèle 2. En simulation, le paramètre peut être affecté textuellement dans l'arbre des variables, ou graphiquement en cliquant sur l'objet graphique qui modélise la panne, ou encore statiquement dans le modèle 2.

On affecte à « vrai » le paramètre dans le modèle 2 lorsque l'on veut démarrer l'analyse de sûreté avec une panne présente. Cette fonctionnalité permet d'établir la « Minimum Equipment List » qui permet d'évaluer le risque lorsqu'une panne est présente dans le système avant le début de la mission. Un paramètre affecté dans le modèle 2 est pris en compte par le simulateur pour établir les équations du système. Les simplifications réalisées par le générateur 3, en particulier par son compilateur, font que toutes les pannes intervenant en disjonction de celle qui est forcée à vraie vont disparaître. Un nouveau cône d'influence (de taille plus petite) va être calculé. Le moteur d'analyse 5 prendra alors en compte les équations du nouveau cône d'influence pour calculer la probabilité P d'un évènement redouté evr, sachant qu'une panne evp existe dans le système. Un évènement redouté est désigné par un connecteur de sortie, comme on peut le voir à titre d'exemple au niveau du composant C2 dans la figure 2. Cet objet est un objet de la bibliothèque mentionnée précédemment.

Le compilateur du générateur 3 génère alors le cône d'influence correspondant à cette sortie. Pour définir un évènement redouté evr, on instancie l'objet de bibliothèque et on le connecte à un noeud du modèle 2. Cet objet évènement redouté evr possède une variable dans laquelle sera stocké le résultat P du calcul de probabilité par le moteur d'analyse 5. En simulation, on peut prévoir que la couleur de cet objet passe de vert à rouge lorsque l'évènement redouté evr est déclenché. A chaque constituant de l'architecture du système est associé un composant Cl dans le modèle 2, à un certain niveau de décomposition. L'ensemble des composants Ci interconnectés suivant les connexions de l'architecture générique constitue le modèle 2 du système. On peut associer aux composants Ci un graphisme, grâce à un module de représentation graphique, qui permet à chaque métier de travailler avec la schématique qui lui est propre.

C'est ce qui est représenté, à titre d'exemple, à la figure 2. Dans cette représentation graphique 9 du modèle 2, on retrouve des composants C, interconnectés de façon à rendre compte du comportement des constituants du système modélisé. On y a rajouté la représentation des évènements de type panne evp. Grâce au générateur 3, à chaque composant C, du modèle 2 est associé un arbre de défaillance local, tel que l'arbre de défaillance 6 associé au composant C2. A titre d'exemple, dans le cas d'un composant C, de type « Echangeur air », l'arbre associé pourrait graphiquement être représenté tel que représenté en figure 4c. Un tel arbre est très simple, mais on peut écrire des arbres complexes avec un grand nombre de portes logiques. Ici l'arbre est décrit graphiquement il pourrait également être décrit par l'équation textuelle : debit sortie = debit entree or fuite interne or fuite externe. A titre d'exemple, on peut utiliser un environnement de développement tel que Modelica, qui permet de créer le modèle 2 et de générer les arbres de défaillance à partir d'une même bibliothèque d'objets et du même langage de scripts.

Ceci permet notamment d'assurer une bonne continuité entre l'analyse de sûreté de fonctionnement et la modélisation fonctionnelle. En effet, les modèles fonctionnels à temps discret et/ou continu peuvent être enrichis par le comportement dysfonctionnel qui modélise la modification du comportement lorsqu'une panne survient. Ainsi, une véritable interaction entre le modèle 2 et l'arbre global 4 et/ou les arbres locaux 6, 7 est possible. Par exemple, on peut prévoir que toute modification dans le modèle 2 entraîne une reconstruction automatique, au moyen du générateur 3, de l'arbre de défaillance global 4 et des arbres de défaillance locaux 6, 7.Par ailleurs, la génération de l'arbre de défaillance global 4 est réalisée de préférence à partir des arbres de défaillances locaux 6, 7. Le système modélisé par le modèle 2 est en effet regardé comme un ensemble de sous-systèmes, chaque sous-système étant lui-même regardé éventuellement comme un ensemble de sous-systèmes. Chaque sous-système est modélisé par un sous-ensemble des composants (C' Cil) du système global. La génération de l'arbre de défaillance global correspondant au système, pour un évènement redouté evr donné, peut alors être réalisée de manière récursive par génération des arbres de défaillances globaux des sous-systèmes puis intégration de ces arbres dans l'architecture globale du système, et ainsi de suite lorsque certains des sous-systèmes sont eux-mêmes constitués de sous-systèmes. On peut simuler la propagation d'une panne, visualiser dans la représentation graphique 9 du modèle 2 des animations associées aux composants C,, afficher la valeur des variables, éventuellement sous forme de courbes, visualiser dans une structure arborescente les variables du modèle 2, affecter dans cette structure la valeur des paramètres. La panne est ainsi injectée dans le modèle 2 et sa propagation peut être visualisée directement dans la représentation graphique 9 de ce modèle 2. On désigne alors directement sur la représentation graphique 9 du modèle 2 l'évènement redouté à analyser, par exemple au niveau de C2, qui peut être le fait de ne pas avoir de débit en entrée du moteur C2. La probabilité P, déterminée par le moteur d'analyse 5, est alors visualisée directement dans la représentation graphique 9, dans un objet P dit de désignation prévu à cet effet. Tel que représenté à la figure 3, on peut visualiser l'arbre de défaillance local 6 de l'évènement redouté evr (tout comme l'arbre de défaillance global 4) sous la forme d'une représentation graphique 7 arborescente, grâce à un module de représentation graphique, dans laquelle on visualise les portes logiques 8, les noms des évènements de type panne evp et des évènements redoutés evr (dont l'évènement redouté cible evr au sommet de la structure arborescente), les probabilités P associées aux évènements panne evp et redoutés evr. On peut chercher à calculer et visualiser les coupes à l'ordre n, c'est-à-dire les coupes comprenant n évènements.

4 On peut également chercher à calculer et visualiser les coupes minimales (ou chemins critiques), c'est-à-dire les plus petites combinaisons d'évènements pouvant conduire à l'évènement redouté. Lorsque l'on a calculé les coupes minimales, on peut « jouer » toutes les coupes qui vérifient une consigne, par exemple toute les coupes à un ordre donné ou toutes celles dont la probabilité est supérieure à une valeur donnée.10

Claims (15)

1. REVENDICATIONS1.- Dispositif (1) informatique d'analyse de panne dans un système comprenant des constituants, ledit dispositif comprenant : des moyens de création d'un modèle (2) de l'architecture du système, représentatif du comportement du système et comprenant des composants (Ci, C,i) correspondants aux constituants du système et interconnectés de façon à rendre compte du comportement des constituants du système, certains des composants (C11) étant hiérarchiquement dépendants d'autres composants (C,) selon une relation de dépendance dite de composition, - un générateur (3) apte à générer, à partir du modèle (2), un arbre de défaillance global (4) représentatif de l'enchaînement logique d'évènements (evp, evr) susceptibles d'entraîner une défaillance du système, - un moteur (5) d'analyse de défaillance apte à déterminer, à partir dudit arbre de défaillance global (4), au moins une caractéristique (P) de ladite défaillance, notamment la probabilité (P) de l'occurrence de cette dite défaillance, caractérisé en ce que le générateur (3) est apte à générer, à partir dudit modèle (2), un arbre de défaillance local (6, 7) représentatif de l'enchaînement logique d'évènements (evp, evr) susceptibles d'entraîner une défaillance locale (evr) au niveau d'un composant (C,, quelconque du modèle (2), quelle que soit la position de ce composant (C,, C,) dans le modèle (2), et en ce que le moteur (5) est apte à déterminer, à partir dudit arbre de défaillance local (6, 7), au moins une caractéristique (P) de ladite défaillance locale (evr), notamment la probabilité (P) de l'occurrence de cette dite défaillance locale (evr).
2. 2.- Dispositif (1) selon la revendication 1, caractérisé en ce que le générateur (3) est apte à générer l'arbre de défaillance global (4) à partir des arbres de défaillances locaux (6, 7) représentatifs de l'enchaînement logique d'évènements (evp, evr) susceptibles d'entraîner des défaillances locales (evr) au niveau des composants respectifs (C,, C,..j) du modèle (2).
3. 3.- Dispositif (1) selon la revendication 2, caractérisé en ce que le générateur (3) est apte à générer l'arbre de défaillance global (4) à partir des arbres de défaillances locaux (6, 7), de manière récursive en générant les arbres de défaillance globaux de sous-systèmes comprenant chacun des sous-ensembles de composants (C' C11) correspondants aux constituants du système.
4. 4.- Dispositif (1) selon l'une quelconque des revendications 1 à 3, caractérisé en ce que les moyens de création du modèle (2) et le générateur (3) sont aptesrespectivement à créer le modèle (2) et à générer l'arbre de défaillance global (4) et les arbres de défaillance locaux (6, 7), à partir d'une bibliothèque d'objets commune et un langage de scripts commun.
5. 5.- Dispositif (1) selon l'une quelconque des revendications 1 à 4, caractérisé en ce que le générateur (3) est apte à reconstruire automatiquement l'arbre de défaillance global (4) et les arbres de défaillance locaux (6, 7) à partir de toute modification dans le modèle (2).
6. 6.- Dispositif (1) selon l'une quelconque des revendications 1 à 5, caractérisé en ce que le générateur (3) est apte à générer l'arbre de défaillance global (4) et les arbres de défaillance locaux (6,
7. 7) sous la forme d'ensembles d'une ou plusieurs équations booléennes. 7.- Dispositif (1) selon la revendication 6, caractérisé en ce qu'il comprend un module de représentation graphique d'arbre de défaillance apte à générer une représentation graphique de l'arbre de défaillance global (4) et des arbres de défaillance locaux (6, 7) sous la forme de structures de donnée arborescentes (4, 6, 7) dont les feuilles (evp) sont des évènements (evp) susceptibles d'entraîner une défaillance du système, respectivement du composant (C,, C,..j), et dont les noeuds (8) sont des portes logiques (8) auxquelles sont associés des défaillances (evr).
8. 8.- Procédé d'analyse de panne dans un système comprenant des constituants, comprenant : une étape de création d'un modèle (2) de l'architecture du système, représentatif du comportement du système et comprenant des composants (Ch C,1) correspondants aux constituants du système et interconnectés de façon à rendre compte du comportement des constituants du système, certains des composants (C,i) étant hiérarchiquement dépendants d'autres composants (C,) selon une relation de dépendance dite de composition, - une étape de génération, à partir dudit modèle (2) et au moyen d'un générateur (3), d'un arbre de défaillance global (4) représentatif de l'enchaînement logique d'évènements (evp, evr) susceptibles d'entraîner une défaillance du système, - une étape d'analyse de défaillance, à partir dudit arbre de défaillance global (4) et au moyen d'un moteur (5) d'analyse de défaillance, pour déterminer au moins une caractéristique (P) de ladite défaillance, notamment la probabilité (P) de l'occurrence de cette dite défaillance, caractérisé en ce qu'il comprend en outre : - au moins une étape de génération, à partir dudit modèle (2) et au moyen du générateur (3), d'un arbre de défaillance local (6, 7) représentatif de l'enchaînement logiqued'évènements (evp, evr) susceptibles d'entraîner une défaillance locale (evr) au niveau d'un composant (C,, C,..j) quelconque du modèle (2), quelle que soir la position de ce composant (CI, Cil) dans le modèle (2), - et au moins une étape d'analyse de défaillance, à partir dudit arbre de défaillance local (6, 7) et au moyen du moteur (5) d'analyse de défaillance, pour déterminer au moins une caractéristique (P) de ladite défaillance locale (evr), notamment la probabilité (P) de l'occurrence de cette dite défaillance locale (evr).
9. 9.- Procédé selon la revendication 8, caractérisé en ce que l'étape de génération de l'arbre de défaillance global (4), génère cet arbre de défaillance global (4) à partir des arbres de défaillances locaux (6, 7) représentatifs de l'enchaînement logique d'évènements (evp, evr) susceptibles d'entraîner des défaillances locales (evr) au niveau des composants respectifs (C' Cil) du modèle (2).
10. 10.- Procédé selon la revendication 9, caractérisé en ce que l'étape de génération de l'arbre de défaillance global (4) à partir des arbres de défaillances locaux (6, 7), est une étape récursive qui génère les arbres de défaillance globaux de sous-systèmes comprenant chacun des sous-ensembles de composants (C,, C,) correspondants aux constituants du système.
11. 11.- Procédé selon l'une quelconque des revendications 8 à 10, caractérisé en ce que l'étape de création du modèle (2) et l'étape de génération de l'arbre de défaillance global (4) et des arbres de défaillance locaux (6, 7), utilisent une bibliothèque d'objets commune et un langage de scripts commun.
12. 12.- Procédé selon l'une quelconque des revendications 8 à 11, caractérisé en ce que toute modification dans le modèle (2) entraîne une reconstruction automatique, au moyen du générateur (3), de l'arbre de défaillance global (4) et des arbres de défaillance locaux (6, 7).
13. 13.- Procédé selon l'une quelconque des revendications 8 à 12, caractérisé en ce que l'étape de génération de l'arbre de défaillance global (4) et l'étape de génération d'un arbre de défaillance local (6, 7) génèrent l'arbre de défaillance global (4) et les arbres de défaillance locaux (6, 7) sous la forme d'ensembles d'une ou plusieurs équations booléennes.
14. 14.- Procédé selon la revendication 13, caractérisé en ce qu'il comprend une étape de représentation, graphique, au moyen d'un module de représentation graphique d'arbre de défaillance, de l'arbre de défaillance global (4) et des arbres de défaillance locaux (6, 7) sous la forme de structures de donnée arborescentes (4, 6, 7) dont les feuilles (evp) sont les évènements (evp) susceptibles d'entraîner une défaillance dusystème, respectivement du composant (C,, Cm), et dont les noeuds sont des portes logiques (8) auxquelles sont associés des défaillances (evr).
15. 15.- Programme d'ordinateur comportant des instructions logicielles qui, lorsqu'il s'exécute sur une unité de traitement d'informations intégrée à un dispositif informatique, met en oeuvre le procédé selon l'une quelconque des revendications 8 à 14