FR2966616A1 - Procede, dispositif et programme d'ordinateur d'aide au diagnostic d'un systeme d'un aeronef, utilisant des graphes d'evenements redoutes - Google Patents
Procede, dispositif et programme d'ordinateur d'aide au diagnostic d'un systeme d'un aeronef, utilisant des graphes d'evenements redoutes Download PDFInfo
- Publication number
- FR2966616A1 FR2966616A1 FR1004161A FR1004161A FR2966616A1 FR 2966616 A1 FR2966616 A1 FR 2966616A1 FR 1004161 A FR1004161 A FR 1004161A FR 1004161 A FR1004161 A FR 1004161A FR 2966616 A1 FR2966616 A1 FR 2966616A1
- Authority
- FR
- France
- Prior art keywords
- dreaded
- event
- events
- graph
- aircraft
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000003745 diagnosis Methods 0.000 title claims abstract description 31
- 238000000034 method Methods 0.000 title claims description 35
- 238000004590 computer program Methods 0.000 title claims description 5
- 230000014509 gene expression Effects 0.000 claims abstract description 26
- 238000012544 monitoring process Methods 0.000 claims abstract description 20
- 238000012423 maintenance Methods 0.000 claims description 39
- 230000010365 information processing Effects 0.000 claims description 6
- 230000001427 coherent effect Effects 0.000 abstract 1
- 238000004422 calculation algorithm Methods 0.000 description 17
- 238000004891 communication Methods 0.000 description 13
- 238000004458 analytical method Methods 0.000 description 9
- 238000007726 management method Methods 0.000 description 8
- 101000799969 Escherichia coli (strain K12) Alpha-2-macroglobulin Proteins 0.000 description 6
- 238000012360 testing method Methods 0.000 description 6
- 230000000694 effects Effects 0.000 description 5
- 230000008901 benefit Effects 0.000 description 4
- 238000011058 failure modes and effects analysis Methods 0.000 description 4
- 230000006870 function Effects 0.000 description 4
- 238000001514 detection method Methods 0.000 description 3
- 230000007257 malfunction Effects 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 230000008569 process Effects 0.000 description 3
- 230000001364 causal effect Effects 0.000 description 2
- 238000013461 design Methods 0.000 description 2
- 238000012774 diagnostic algorithm Methods 0.000 description 2
- 208000037265 diseases, disorders, signs and symptoms Diseases 0.000 description 2
- 238000012545 processing Methods 0.000 description 2
- 208000024891 symptom Diseases 0.000 description 2
- 238000013024 troubleshooting Methods 0.000 description 2
- 230000002159 abnormal effect Effects 0.000 description 1
- 230000004913 activation Effects 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 230000000295 complement effect Effects 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 230000003111 delayed effect Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 239000012530 fluid Substances 0.000 description 1
- 238000007429 general method Methods 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 230000008439 repair process Effects 0.000 description 1
- 230000035943 smell Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 238000010200 validation analysis Methods 0.000 description 1
- 238000009423 ventilation Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/079—Root cause analysis, i.e. error or fault diagnosis
-
- G—PHYSICS
- G05—CONTROLLING; REGULATING
- G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
- G05B23/00—Testing or monitoring of control systems or parts thereof
- G05B23/02—Electric testing or monitoring
- G05B23/0205—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults
- G05B23/0218—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults characterised by the fault detection method dealing with either existing or incipient faults
- G05B23/0243—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults characterised by the fault detection method dealing with either existing or incipient faults model based detection method, e.g. first-principles knowledge model
- G05B23/0245—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults characterised by the fault detection method dealing with either existing or incipient faults model based detection method, e.g. first-principles knowledge model based on a qualitative model, e.g. rule based; if-then decisions
- G05B23/0248—Causal models, e.g. fault tree; digraphs; qualitative physics
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
- G06F11/0736—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function
- G06F11/0739—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function in a data processing system embedded in automotive or aircraft systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
- G06F11/0748—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a remote unit communicating with a single-box computer node experiencing an error/fault
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Quality & Reliability (AREA)
- Computer Hardware Design (AREA)
- Health & Medical Sciences (AREA)
- Biomedical Technology (AREA)
- Automation & Control Theory (AREA)
- Testing And Monitoring For Control Systems (AREA)
Abstract
L'invention a notamment pour objet l'aide au diagnostic d'un système d'un aéronef, comprenant une pluralité de sous-systèmes dont au moins un comprend des moyens de surveillance et de notification d'au moins un événement détecté, utilisant des graphes d'événements redoutés. Après avoir reçu (500) un message de notification de réalisation dudit événement détecté, un ensemble d'événements redoutés liés à ce message est créé (510) à partir dudit graphe d'événements redoutés, et des expressions logiques - utilisant comme opérandes des éléments du système et cohérentes avec les événements redoutés dudit ensemble - sont construites (515) selon les liens logiques représentés dans ledit graphe d'événements redoutés. Un groupe d'événements redoutés est ensuite créé (520) selon des éléments desdites expressions logiques. Les vertex minimaux des expressions logiques associées aux événements redoutés dudit groupe sont calculés et forment un diagnostic dudit système.
Description
La présente invention concerne le diagnostic d'éléments de systèmes complexes, notamment d'aéronef, et plus particulièrement un procédé, des dispositifs et un programme d'ordinateur d'aide au diagnostic d'un système d'un aéronef, utilisant des graphes d'événements redoutés. Les derniers systèmes de diagnostic de pannes dans les aéronefs utilisent généralement des modèles de pannes élaborés par les constructeurs et leurs équipementiers lors du cycle de développement des aéronefs. Pour certains constructeurs, ces modèles sont principalement élaborés par les équipementiers qui développent des systèmes de surveillance de leurs équipements, comprenant des applications logicielles d'auto- diagnostic, aussi appelées "Built-In Test Equipment" (BITE) en terminologie anglo-saxonne, reportant des messages de maintenance visant les équipements suspectés de pannes dès que les systèmes de surveillance les détectent. Une application logicielle d'un système centralisé de maintenance, appelé CMS (sigle de Centralized Maintenance System en terminologie anglo- saxonne) recueille et consolide ces messages de maintenance pour identifier les messages de maintenance les plus pertinents permettant aux équipes de maintenance au sol de mener à bien les réparations à effectuer. De tels systèmes utilisent typiquement le standard ARINC 604 (standard visant la conception et l'implémentation des équipements de test intégrés).
Pour d'autres constructeurs, le système de diagnostic d'un aéronef est un système utilisant des modèles de pannes implémentés dans le système centralisé de maintenance. Ainsi, par exemple, dans l'article intitulé "Application of model-based diagnostique technology on the Boeing 777 Airplane", 1994, l'auteur, Tim Felke, indique que le système centralisé de maintenance utilise un algorithme de diagnostic abductif avec des relations de causes à effets implémentées dans le modèle.
Ces modèles peuvent utiliser des informations transférées par un réseau de communication reliant plusieurs systèmes d'un aéronef, appelées Inter-Communication Data (ICD) en terminologie anglo-saxonne. Ils comprennent une connaissance des signaux échangés entre les systèmes.
Il existe également des méthodes de modélisation plus larges qui ne sont pas uniquement basées sur des échanges de données via un réseau de communication. Par ailleurs, il est observé que sur les aéronefs modernes, les systèmes embarqués coopèrent de façon significative. Ils échangent des données via des bus de communication, par exemple des bus conformes aux standards ARINC 429 ou AFDX (sigle d'Avionics Full DupleX en terminologie anglo-saxonne), de l'énergie, notamment de l'énergie électrique, hydraulique et mécanique, ou d'autres services tels que la ventilation. La plupart de ces dépendances et les pannes qu'elles provoquent quand elles sont défaillantes ne sont généralement pas formalisées dans les systèmes de diagnostic des aéronefs actuels. A titre d'illustration, les systèmes de diagnostic de certains aéronefs modernes reposent sur l'utilisation de règles logiques qui ont pour objet de consolider des messages envoyés par différents systèmes avioniques au système centralisé de maintenance. Cependant, de telles règles logiques sont établies de façon empirique par des experts. II n'existe donc pas de moyen de validation formelle. En outre, une telle approche ne permet pas de calculer de façon formelle des performances de conception telles que la couverture de détection des pannes, la couverture de diagnostic des pannes critiques pour la sécurité ou la disponibilité opérationnelle de l'aéronef. Les systèmes de diagnostic mis en ceuvre sur d'autres aéronefs raisonnent à partir de modèles implémentés dans des bases de données relationnelles centralisées qui contiennent des relations de causes à effets entre des messages envoyés par des systèmes distincts. Cependant, la dépendance entre les systèmes du point de vue de leurs défaillances n'est ici pas formalisée, ce qui ne permet pas une compréhension de cascades d'événements physiques ou fonctionnels pouvant avoir lieu dans un aéronef.
C'est une des raisons pour lesquelles une étape de corrélation avec des effets cockpit, par exemple des messages EICAS (acronyme d'Engine Indicating and Crew Alerting System en terminologie anglo-saxonne), des algorithmes de diagnostic mis en ceuvre dans ces aéronefs est effectuée sur la base de règles logiques empiriques. Ainsi, au vu de ce qui précède, il existe des besoins pour des systèmes d'aide au diagnostic permettant d'établir une cohérence entre un modèle utilisé par le système de maintenance et un modèle utilisé pour mener des études de sécurité, pouvant également servir à justifier des besoins d'alertes dans un cockpit et à conduire des analyses de type MSG-3 (sigle de Maintenance Steering Group - 3 en terminologie anglo-saxonne) utilisées pour établir des Manuels de Maintenance Planifiée d'un aéronef. Il existe également des besoins pour des systèmes d'aide au diagnostic permettant d'établir une cohérence entre un modèle utilisé par un système de maintenance et un modèle utilisé pour l'élaboration de la documentation d'un aéronef, notamment des documents connus sous les noms de trouble-shooting manual et aircraft maintenance manual. D'autre part, il existe des besoins d'automatisme dans l'analyse d'impact lors d'évolution d'équipements d'un aéronef (fonctionnalités ou modes de pannes). De telles d'analyses peuvent être réalisées aujourd'hui manuellement mais la tâche est longue et le résultat peut être incomplet. Le raisonnement de l'algorithme d'aide au diagnostic doit, de préférence, être cohérent avec les coupes minimales identifiées par la FMEA (sigle de Failure Modes and Effects Analysis en terminologie anglo-saxonne) et le lien entre le résultat d'aide au diagnostic et la liste minimale des équipements connue sous le nom de MMEL (sigle de Master Minimum Equipment List en terminologie anglo-saxonne). En outre, le raisonnement de l'algorithme d'aide au diagnostic doit, de préférence, être cohérent, en temps réel, avec la procédure de gestion des problèmes effectuée au sol et le raisonnement doit être prouvé logiquement pour déterminer la relation entre les pannes et leurs effets sur l'aéronef (messages ECAM/EICAS, alertes sonores, odeurs suspectes, bruit suspect, etc.).
L'invention permet de résoudre au moins un des problèmes exposés précédemment. L'invention a ainsi pour objet un procédé pour ordinateur d'établissement d'une aide au diagnostic d'un système complexe d'un aéronef comprenant une pluralité de sous-systèmes, au moins un sous-système de ladite pluralité de sous-systèmes comprenant des moyens de surveillance et de notification d'au moins un événement détecté, ce procédé mettant en ceuvre un graphe d'événements redoutés modélisant au moins partiellement ledit système complexe, ledit graphe d'événements redoutés comprenant une pluralité de sommets, chaque sommet de ladite pluralité de sommets étant relié par une relation d'implication logique à au moins un autre sommet de ladite pluralité de sommets, ladite pluralité de sommets comprenant au moins, - un sommet représentant un événement redouté ; et, - un sommet représentant au moins un élément dudit système complexe, ledit au moins un élément étant susceptible de tomber en panne ; et le procédé comprenant les étapes suivantes, - réception d'au moins un message de notification de réalisation dudit au moins un événement détecté ; - création d'un ensemble d'événements redoutés, chaque événement redouté dudit ensemble d'événements redoutés étant associé à un sommet dudit graphe d'événements redoutés lié audit au moins un message de notification reçu ; - pour chaque événement redouté dudit ensemble d'événements redoutés, construction, à partir dudit graphe d'événements redoutés, d'au moins une expression logique conduisant audit événement redouté, ladite au moins une expression logique étant basée sur des éléments dudit système complexe ; - création d'au moins un groupe d'événements redoutés dudit ensemble d'événements redoutés, au moins un élément étant commun à deux expressions logiques liées à deux événements redoutés distincts dudit au moins un groupe, les expressions logiques associées auxdits événements redoutés dudit au moins un groupe représentant un diagnostic relatif audit au moins un événement détecté. Le procédé selon l'invention permet ainsi d'établir un diagnostic d'un système complexe d'un aéronef à partir de messages standards de notification d'événements détectés en utilisant une modélisation du système qui peut être utilisée par ailleurs pour effectuer des vérifications et conduire des analyses relatives au système complexe. De façon avantageuse, le procédé comprend en outre une étape de détermination des vertex minimaux des expressions logiques des événements redoutés dudit au moins un groupe, lesdits vertex minimaux formant des diagnostics minimaux dudit diagnostic relatif audit au moins un événement détecté. Le diagnostic obtenu est ainsi directement utilisable, notamment par un opérateur de maintenance.
Selon un mode de réalisation particulier, ledit graphe d'événements redoutés comprenant en outre au moins un sommet représentant un message associé audit au moins un événement détecté, le procédé comprenant en outre une étape d'identification, dans ledit graphe d'événements redoutés, d'au moins un sommet représentant un message selon ledit au moins un message reçu, chaque événement redouté dudit ensemble d'événements redoutés étant associé à un sommet dudit graphe d'événements redoutés lié audit au moins un message de notification via ledit au moins un sommet identifié. Le graphe d'événements redoutés forme ainsi une modélisation du système complexe pouvant être utilisée de façon autonome.
Le procédé comprend en outre, de préférence, une étape d'affichage, de mémorisation et/ou de transmission dudit diagnostic relatif audit au moins un événement détecté. Toujours selon un mode de réalisation particulier, ledit graphe d'événements redoutés comprend au moins un sous-graphe d'événements redoutés, ledit au moins un sous-graphe d'événements redoutés modélisant au moins partiellement un sous-système de ladite pluralité de sous-systèmes. La modélisation du système complexe peut ainsi être obtenue et maintenue facilement. De façon avantageuse, ledit graphe d'événements redoutés comprend en outre au moins un sommet représentant une opération logique, au moins une desdites expressions logiques comprenant une opération logique représentée par un sommet dudit graphe d'événements redoutés. Le procédé selon l'invention permet ainsi de traiter des défaillances multiples se combinant. L'invention a aussi pour objet un programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé décrit précédemment lorsque ledit programme est exécuté sur un ordinateur. Les avantages procurés par ce programme d'ordinateur sont similaires à ceux évoqués précédemment. L'invention a également pour objet un système de maintenance d'un aéronef comprenant un calculateur comprenant des moyens pour mettre en oeuvre chacune des étapes du procédé décrit précédemment, permettant d'établir directement un diagnostic dans l'aéronef, en temps réel. De façon avantageuse, le système de maintenance comprend en outre des moyens pour transmettre ledit diagnostic à un système distant. II est ainsi possible d'anticiper des actions à entreprendre, notamment des opérations de maintenance. L'invention a également pour objet un aéronef comprenant le système décrit précédemment. Les avantages procurés par cet aéronef sont similaires à ceux évoqués précédemment. L'invention a aussi pour objet un système de traitement de l'information comprenant des moyens pour recevoir des informations relatives à au moins un message de notification de réalisation d'au moins un événement détecté par des moyens de surveillance et de notification d'un sous-système d'un système complexe d'un aéronef comprenant une pluralité de sous-systèmes et un calculateur comprenant des moyens pour mettre en oeuvre chacune des étapes du procédé décrit précédemment. II est ainsi possible, au sol, d'établir un diagnostic d'un système complexe d'un aéronef distant, permettant d'anticiper des actions à entreprendre, notamment des opérations de maintenance. D'autres avantages, buts et caractéristiques de la présente invention ressortent de la description détaillée qui suit, faite à titre d'exemple non limitatif, 5 au regard des dessins annexés dans lesquels : - la figure 1 représente schématiquement certaines étapes du procédé selon l'invention pour établir une aide au diagnostic d'un système d'un aéronef ; - la figure 2 illustre un exemple de graphe d'événements 10 redoutés ; - la figure 3 illustre un exemple de graphe d'événements redoutés lié à deux systèmes chacun représenté par un sous-graphe distinct d'événements redoutés ; - la figure 4 représente le graphe d'événements 15 redoutés illustré sur la figure 2 comprenant en outre des sommets associés à des messages issus de systèmes de surveillance du système caractérisé par le graphe d'événements redoutés ; - la figure 5 illustre un exemple d'algorithme d'aide au diagnostic d'un système d'aéronef à partir de notifications reçues de 20 systèmes de surveillance et d'un graphe d'événements redoutés ; - la figure 6, comprenant les figures 6a et 6b, illustre certaines étapes de l'algorithme décrit en référence à la figure 5 ; - les figures 7 et 8 illustrent deux modes de réalisation de l'invention ; et, 25 - la figure 9 illustre un exemple d'architecture matérielle adaptée à mettre en ceuvre certaines étapes de l'invention. De façon générale, l'invention vise un système d'aide au diagnostic pour un système d'aéronef, utilisant des graphes d'événements redoutés (ou fallure condition graph en terminologie anglo-saxonne), construits ici à partir 30 d'arbres de pannes (appelés fauit tree en terminologie anglo-saxonne) développés lors d'études de sécurité. 2966616 s Comme illustré sur la figure 1, le procédé général est ici décomposé en quatre phases. Une première phase (phase 100) vise la modélisation d'un graphe d'événements redoutés. Un exemple d'une telle modélisation est décrit en référence aux figures 2 et 3. Une deuxième phase (phase 105) a pour objet l'attribution de codes de messages de pannes au graphe d'événements redoutés préalablement modélisé. Une troisième phase (phase 110) consiste à obtenir, en temps réel ou différé, des notifications de détections d'événements émises par des systèmes de surveillance de l'aéronef. Enfin, dans une quatrième phase (phase 115), un algorithme d'identification de pannes est exécuté par une machine, de préférence automatiquement, pour apporter une aide au diagnostic de l'aéronef à partir des événements détectés et du graphe d'événements redoutés modélisé. Comme illustré, les deux dernières phases sont, de préférence, répétées pour permettre l'analyse de tous les événements détectés, par exemple au fur et à mesure de leur détection.
Selon un mode de réalisation particulier, la modélisation du graphe d'événements redoutés est réalisée à partir de modélisations de graphes des événements redoutés de plusieurs systèmes d'un aéronef, de préférence tous. Le graphe d'événements redoutés peut être considéré comme l'extension des arbres de pannes mis au point lors des études de sécurité. II a ici les caractéristiques suivantes: - le graphe est orienté, il peut comporter des cycles ; le graphe comporte au moins trois types de sommets : o objets accusables désignant des équipements, de préférence remplaçables, notamment des calculateurs de type LRU (sigle de Line Replaceable Unit en terminologie anglo-saxonne), des applications logicielles, des câbles et des conditions de fonctionnement telles que des remises à zéro (reset) d'un équipement présentant un disfonctionnement ou des conditions de fonctionnement exceptionnelles d'un système (telles que, par exemple, un surrégime moteur, un dérapage au freinage ou un fonctionnement en présence de glace sur les bouches d'entrée d'air) ; 30 o événements redoutés, appelés failure condition en terminologie anglo-saxonne, désignant des conditions de défaillance du système modélisé par le graphe ; et, o portes logiques désignant des opérations logiques, par exemple les opérations logiques OU, ET, la négation (NEG) ou une porte de type "n PARMI" (où n est un entier naturel non nul représentant un seuil d'activation) ; - chaque arc du graphe est un arc orienté représentant une relation d'implication logique entre les deux sommets qu'il relie, l'origine de l'arc pouvant 10 être considéré comme une cause et la destination un effet ; - l'ensemble des sommets du graphe couvre l'ensemble des arbres de fautes de l'analyse AMDEC (acronyme d'Analyse des Modes de Défaillance, de leurs Effets et de leur Criticité) faite pour l'analyse de sécurité (system safety analysis ou system FMEA). En d'autres termes, tout arbre de faute représenté 15 dans la FMEA système est un sous-graphe du graphe d'événements redoutés ; - l'ensemble des sommets de type objets .accusables comprend l'ensemble des unités ou modules remplaçables (LRU et LRM, sigle de Une Replaceable Module en terminologie anglo-saxonne) considérés dans les manuels de maintenance connus sous les noms de TSM et AMM ; et, 20 - l'ensemble des défaillances fonctionnelles (Functional Failures) définies dans l'analyse de type MSG-3 du système considéré est inclus dans l'ensemble des sommets de type événement redouté du graphe. Le graphe d'événements redoutés peut comprendre plusieurs milliers de sommets et d'arcs. 25 Il est à noter qu'un graphe peut avoir un degré de complétude variable. Par exemple, les objets accusables liés au câblage peuvent ne pas figurer dans une version volontairement allégée du graphe d'un système. Néanmoins, ce graphe allégé rend possible un premier niveau de diagnostic intéressant pour la maintenance en ligne et permet un mode de réalisation où le 30 constructeur propose un service de diagnostic détaillé basé sur un graphe complet.
La figure 2 illustre un exemple d'un tel graphe d'événements redoutés 200. Les cercles représentent ici les sommets du graphe d'événements redoutés tandis que les flèches représentent les arcs du graphe. Les cercles 205 à 225, en trait continu, représentent des sommets de type événements redoutés, les cercles 230 à 240, en trait pointillé, représentent des sommets de type portes logiques et les cercles 245 et 250, en trait pointillé de longueur variable, représentent des sommets de type objets accusables. Ainsi, par exemple, une anomalie dans l'équipement S1 (245), ici une application logicielle, est susceptible de déclencher l'événement redouté E2 (210). De même, une anomalie dans l'équipement L1 (250), ici un LRU, est susceptible de déclencher l'événement redouté E3 (215). En outre, le déclenchement de l'événement redouté E2 (210) ou de l'événement redouté E3 (215) entraîne le déclenchement de l'événement redouté E1 (205) conformément à la porte logique OU (230) reliant les événements redoutés E2 et E3 à l'événement redouté E1. Chaque sous-système d'un système peut être représenté par un sous-graphe d'événements redoutés. Ainsi, lorsqu'un graphe d'événements redoutés est lié à un système comprenant plusieurs sous-systèmes, chaque sous-système étant lié à un sous-graphe d'événements redoutés, il existe, dans le graphe d'événements redoutés, des sommets de type événements redoutés qui jouent un rôle d'interface entre les sous-graphes d'événements redoutés, représentant des relations de causes à effets entre les sous-systèmes correspondants. De tels sommets sont, de préférence, identifiés avec un attribut particulier. La figure 3 illustre un exemple de graphe d'événements redoutés 300 lié à deux sous-systèmes, ici un sous-système de type actionneur et un sous-système de type alimentation électrique, chacun représenté par un sous-graphe distinct d'événements redoutés référencé 305-1 et 305-2, respectivement. A nouveau, les cercles représentent des sommets du graphe d'événements redoutés et les flèches représentent les arcs du graphe. Les cercles en trait continu représentent des sommets de type événements redoutés, les cercles en trait pointillé représentent des sommets de type portes logiques et les cercles en trait pointillé de longueur variable représentent des sommets de type objets accusables. Le cercle en double trait continu représente un sommet de type événement redouté jouant un rôle d'interface entre deux systèmes.
A titre d'illustration, la détection d'une anomalie dans l'interrupteur coupe-circuit 310 ou dans la barre d'alimentation 315 est une cause de l'événement redouté « perte d'alimentation électrique sur la barre » (320), conformément à la porte logique OU (325), dans le sous-graphe d'événements redoutés 305-2. L'événement redouté « perte d'alimentation électrique sur la barre » (320) étant un sommet jouant un rôle d'interface entre les sous-graphes 305-1 et 305-2, il est la cause de l'événement redouté « perte d'alimentation électrique de l'actionneur » (330) dans le sous-graphe d'événements redoutés 305-1 conformément à l'arc 335. Les avantages d'une telle représentation sous forme de graphe d'événements redoutés sont notamment liés à sa cohérence avec des modèles utilisés pour mener des analyses de sécurité, qui permet, avec un même formalisme, de représenter une connaissance d'un système, un événement redouté de haut niveau jusqu'à un événement redouté au niveau d'un composant du système et, ainsi, de regrouper dans une seule base de données les connaissances d'équipementiers et d'un constructeur. Elle permet également l'établissement d'une preuve formelle, en utilisant la théorie sur la couverture des graphes, que les événements redoutés sont, d'un point de vue sécurité, bien couverts par le graphe d'événements redoutés utilisé dans le système d'aide au diagnostic.
Après avoir modélisé un graphe d'événements redoutés, une phase suivante (phase 105 de la figure 1) vise à identifier des relations entre des événements redoutés représentés dans le graphe d'événements redoutés et des événements pouvant être détectés en temps réel par des systèmes de surveillance (BITE) de systèmes de l'aéronef auxquels le graphe d'événements redoutés est lié. Les événements détectés sont, par exemple, notifiés par des messages émis par les systèmes de surveillance correspondants.
Un message de maintenance, un rapport de faute, un paramètre de surveillance de la fonction ACMF (sigle d'Aircraft Condition Monitoring Function en terminologie anglo-saxonne), un message de type ECAM (sigle d'Electronic Centralised Aircraft Monitor en terminologie anglo-saxonne) ou une alerte du système d'alerte FWS (sigle de Flight Warning System en terminologie anglo-saxonne) sont notamment des notifications automatiques d'occurrence d'événements redoutés dans un aéronef. Ces messages ainsi que, le cas échéant, des messages similaires sont donc associés aux événements redoutés dans le graphe des événements redoutés. A ces fins, des sommets de type notification sont ajoutés au graphe d'événements redoutés et des liens orientés sont établis entre ces nouveaux sommets et des sommets de type événements redoutés. Une telle relation peut être établie à l'aide d'une logique simple du premier ordre. Ainsi, par exemple, comme illustré sur la figure 4 représentant un graphe d'événement redouté basé sur celui décrit en référence à la figure 2, un message EM1 (message de type ECAM), référencé ici 400, ayant pour objet d'avertir la réalisation d'un événement redouté E1 (205) peut être représenté sur le graphe d'événements redoutés par un sommet de type notification, ce dernier étant relié par un arc au sommet représentant l'événement redouté auquel il est associé, c'est-à-dire ici l'événement redouté E1 (205). De même, un message de maintenance MM1 (405), ayant pour objet d'avertir la réalisation d'un événement redouté E2 (210), est ici représenté sur le graphe d'événements redoutés par un sommet et relié au sommet représentant l'événement redouté correspondant.
Il est observé ici qu'un événement détecté, notifié par un message, correspond à une instanciation particulière, dans le temps, d'un événement redouté ou d'une conjonction d'événements redoutés. Ainsi, bien que, dans un souci de clarté, le graphe d'événements redoutés comprenne ici des sommets de type notification, des événements redoutés du graphe d'événements redoutés peuvent être directement obtenus à partir d'un message de notification sans qu'il soit nécessaire de mettre en oeuvre des sommets de type notification dans le graphe d'événements redoutés.
A titre d'illustration, une unité de surveillance (BITE) détectant qu'une valeur de pression de fluide hydraulique est inférieure à 345 bars et transmettant un message correspondant est un moyen de notifier l'occurrence de l'événement redouté de type "Pression hydraulique trop faible". Un lien peut ainsi être établi entre ce message et cet événement redouté. De même, une unité de surveillance détectant qu'une pression d'un accumulateur hydraulique pour un frein est inférieure à 8 bars est un autre moyen de notifier l'événement redouté de type "Pression hydraulique trop faible dans l'accumulateur pour la fonction de freinage".
En d'autres termes, cette phase permet d'introduire une connaissance liée aux messages des systèmes de surveillance dans le graphe d'événements redoutés préalablement modélisé. Cette phase permet notamment de regrouper, selon un même formalisme, en lien avec des événements redoutés correspondants, des messages de maintenance, des messages du FWS, notamment des messages de type ECAM et des alertes, des paramètres de surveillance ACMF ainsi que des résultats de tests effectués sur l'aéronef au sol. Elle permet également d'obtenir une représentation simple, sur la base de logique du premier ordre, d'événements détectés dans des systèmes de surveillances dans un graphe d'événements redoutés, compréhensible facilement pour des utilisateurs non experts du système considéré. En outre, elle permet d'effectuer des preuves formelles de la couverture et de la précision de diagnostic des logiciels des systèmes de surveillance (Built-ln-Test) de ces systèmes émettant les messages de maintenance, en calculant les sous- graphes d'événements redoutés engendrés par les sommets de notification et tous leurs prédécesseurs (c'est-à-dire tous les sommets de type objet accusable ayant un lien d'implication logique vers le sommet de type notification considéré). Ainsi, par exemple, le sous-graphe référencé 410 sur la figure 4 représente le sous-graphe engendré par le sommet correspondant à la notification du message MM1 (405). Un prédécesseur est ici un sommet de type objet accusable relié à un sommet de type notification, via au moins un sommet de type événement redouté, le prédécesseur pouvant être considéré comme une cause (déterminée par le sens de la liaison entre les deux sommets). L'indépendance entre les logiciels des systèmes de surveillance (Built-In Test) fournis par des équipementiers différents est assurée grâce à l'utilisation des noeuds événements redoutés de type interface dans le modèle. Ces noeuds facilitent et formalisent la spécification des interfaces entre systèmes. En outre, cette représentation permet une analyse automatique des conséquences, dans un même système où dans d'autres, d'une modification d'un équipement de l'aéronef, dans ses fonctionnalités ou ses modes de pannes. Une telle analyse peut être réalisée à l'aide d'un algorithme remontant automatiquement le graphe, de proche en proche, et listant les événements redoutés pouvant être engendrés par cette modification d'équipement. Cette phase permet également à un constructeur de définir des objectifs de couverture de la procédure de gestion de défaillance (aussi appelée trouble-shooting en terminologie anglo-saxonne) à réaliser avec chaque message de maintenance. Enfin, elle peut être utilisée comme modèle de raisonnement pour la gestion de défaillance au sol car elle représente toutes les branches de dysfonctionnements possibles pouvant mener à un événement redouté notifié en vol.
Lorsque des relations entre les messages liés à des événements détectés dans des systèmes de surveillance et des sommets du graphe d'événements redoutés de type événement redouté ont été établies, les messages liés à des événements détectés dans des systèmes de surveillance peuvent être obtenus (phase 110 de la figure 1), en temps réel ou en temps différé, pour être traités. Ces messages peuvent notamment être obtenus à bord d'un aéronef via un système centralisé de maintenance (CMS) ou au sol en recueillant des messages transmis régulièrement par l'aéronef, par exemple des messages de type ACARS (acronyme d'Aircraft Communication Addressing and Reporting System en terminologie anglo-saxonne).
Une phase suivante (phase 115 de la figure 1), avantageusement mise en oeuvre dans une machine automatique, consiste notamment à utiliser le graphe d'événements redoutés (connaissance statique et a priori) et des notifications des systèmes de surveillance (connaissance dynamique et recueillie en temps réel) pour réaliser une aide au diagnostic du système correspondant au graphe d'événements redoutés à un instant donné. A ces fins, le graphe d'événements redoutés permet d'établir des liens de causalité entre des événements redoutés dont des notifications correspondantes ont été reçues et d'isoler les événements redoutés à la source de la propagation des autres. Ce graphe permet en outre d'en déduire une aide au diagnostic par suspicion d'un nombre minimal d'objets accusables en calculant l'ensemble des vertex minimaux (ou hitting sets en terminologie anglo- saxonne), c'est-à-dire l'ensemble suffisant des configurations d'objets accusables ayant pu conduire à chaque événement redouté considéré. La figure 5 illustre un exemple d'algorithme d'aide au diagnostic à partir de notifications reçues de systèmes de surveillance et d'un graphe d'événements redoutés tel que décrit précédemment.
Après avoir reçu au moins une notification d'un système de surveillance (étape 500), le ou les sommets Ni de type notification correspondants sont identifiés (étape 505), dans le graphe d'événements redoutés, selon les liens préalablement établis (phase 105 de la figure 1). Dans une étape suivante (étape 510), les sommets Ni de type notification identifiés sont utilisés pour parcourir le graphe d'événements redoutés et sélectionner l'ensemble O des événements redoutés sources, c'est-à-dire des événements redoutés susceptibles de déclancher les événements redoutés directement liés aux sommets Ni de type notification identifiés. Chacun des événements redoutés sources de l'ensemble O est tel que : - il n'existe pas d'événement redouté directement lié aux sommets Ni de type notification identifiés dont il ne puisse pas être déduit ; et, - son intervalle temporel d'occurrence est inclus dans les intervalles d'occurrence des événements subséquents. Afin d'assurer une relation de causalité entre des événements, une condition d'inclusion entre les temps d'occurrence des messages liés aux notifications identifiées est, de préférence, mise en oeuvre lors de la création du groupe O. Selon cette condition, 0 est un sous-ensemble {E~ )de Ni tel que pour tout élément E' inclus dans Ni et tout élément Ej inclus dans O, soit E' n'implique pas Ej (,(E' Ei», soit l'intervalle d'occurrence de Ej n'est pas IE çr IE inclus dans l'intervalle d'occurrence de E' ( and ). IE IÉ Dans une étape suivante (étape 515), l'algorithme parcourt le sous- graphe des sommets antécédents de chaque événement redouté source de l'ensemble O. L'algorithme remonte le sous-graphe jusqu'aux objets accusables et, dans son parcours, applique les portes logiques du graphe d'événements redoutés pour construire l'expression logique simplifiée formée à partir d'objets accusables et d'opérateurs logiques ET, OU ou NEG. Cette expression constitue l'explication logique de l'événement redouté source considéré. A ces fins, le prédicat logique Abe) est introduit (Ab signifiant abnormal en terminologie anglo-saxonne). Il représente la fonction logique permettant de suspecter un objet accusable. Ainsi, par exemple, Ab(Actionneur) veut dire que l'actionneur est suspecté en panne. A titre d'illustration et comme illustré sur la figure 6a, - l'événement redouté E1 est expliqué par l'expression logique : Ab(AccObj5) OU Ab(AccObj7) - l'événement redouté E2 est expliqué par l'expression logique : Ab(AccOb.b) OU Ab(AccObh) - l'événement redouté E3 est expliqué par l'expression logique : Ab(AccObji) OU Ab(AccObj4) Dans une étape suivante (étape 520), les événements redoutés sources sont regroupés de la façon suivante : deux événements redoutés E; et Ek sont regroupés dans le même ensemble Pi si leurs explications logiques associées (déterminées précédemment) comportent au moins un opérande objet accusable commun. En reprenant l'exemple précédent basé sur la figure 6a, les événements E1, E2 et E3 (considérés comme des événements redoutés sources) sont regroupés dans un même ensemble P1 = {E1, E2, E3} car les expressions logiques expliquant les événements redoutés sources E1 et E2 comportent le même opérande Ab(AccObj7) et les expressions logiques expliquant les événements redoutés sources E2 et E3 comportent le même opérande Ab(AccObji). Ainsi, deux groupes Pi et Pk constituent deux groupes de sources distinctes et permettent d'isoler des ensembles d'objets accusables suspectés distincts : en considérant l'ensemble des objets accusables suspectés par P; et celui des objets accusables suspectés par Pk, ces ensembles sont disjoints. Chaque groupe Pk traduit la présence d'un trouble dont le diagnostic sera formulé à partir des objets accusables qui peuvent être déduits du groupe.
Dans une étape suivante (étape 525), les vertex minimaux (minimal hitting sets) d'objets accusables couvrant chaque événement redouté source E; de chaque ensemble Pk sont calculés. Un vertex de l'ensemble Fj d'objets accusables couvrant un événement redouté donné est ici défini comme une conjonction de prédicats sur ces objets accusables qui est cohérente avec l'expression logique associée à cet événement redouté E;. Ainsi, à titre d'illustration et en référence à la figure 3, l'expression logique Ab(Actionneur) ET Ab(Câble d'alimentation), associée à l'événement redouté « Dysfonctionnement de la régulation », est cohérente avec l'expression logique Ab(Actionneur) OU Ab(Câble d'alimentation) OU Ab (Interrupteur coupe-circuit) OU Ab(Barre d'alimentation). Un vertex minimal est ici défini de la façon suivante : dans un ensemble de vertex {Vn}, un vertex Vn, E {Vn} est dit minimal s'il n'existe pas d'autre vertex de {Vn} qui puisse être déduit logiquement de Vn,.
Ainsi, par exemple, le vertex Ab(Actionneur) se déduit du vertex Ab(Actionneur) ET Ab(Câble d'alimentation). En conséquence, le vertex Ab(Actionneur) ET Ab(Câble d'alimentation) n'est pas un vertex minimal d'un ensemble qui contiendrait ces deux vertex. Ces vertex minimaux représentent ici les diagnostics minimaux pour chaque trouble k lié à un groupe Pk. En d'autres termes, les vertex minimaux d'un groupe Pk sont les expressions logiques minimales d'objets accusables pouvant expliquer tous les événements redoutés du groupe Pk. Selon l'exemple donné précédemment en référence à la figure 6a et illustré sur la figure 6b, les vertex minimaux Vr sont, pour le groupe P, _ {E,,E2,E31, les expressions logiques d'objets accusables suivantes, V1 : Ab(AccObji) ET Ab(AccOb») V2 : Ab(AccObji) ET Ab(AccObj5) V3 : Ab(AccObf4) ET Ab(AccOb») A titre d'illustration, le vertex V4 (Ab(AccObji) ET Ab(Acc0b») ET Ab(AccObj4)) n'est pas un vertex minimal du groupe PI car il s'en déduit le vertex minimal V1 (Ab(AccObji) ET Ab(AccObj7)).
Les vertex minimaux d'objets accusables de chaque groupe Pk peuvent alors être regroupés pour représenter tous les objets accusables permettant d'expliquer tous les événements redoutés identifiés à travers les messages de notifications d'événements détectés. L'utilisation d'un graphe d'événements redoutés dans un système d'aide au diagnostic permet d'accroître le niveau de précision du diagnostic par la 'possibilité d'effectuer des recoupements par vertex minimaux (minimal hitting sets), ce qui permet d'optimiser, en termes de temps, les procédures de gestion de défaillance au sol et, par conséquent, de réduire les coûts de maintenance. De plus, le niveau de complétude du diagnostic final est accru. En effet, le diagnostic est exprimé à partir des objets accusables du graphe d'événements redoutés. De part sa construction, ceux-ci couvrent toutes les origines connues pouvant expliquer les défaillances subséquentes : équipements remplaçables (LRU), logiciels (Software), câbles ou des conditions de fonctionnement telles qu'une réinitialisation (reset) d'un équipement ou des conditions d'opération exceptionnelles. En outre, les relations établies entre un diagnostic et des messages ou alertes notifiés, pouvant être consultées sur le graphe d'événements redoutés, peuvent être utiles pendant des opérations de maintenance en ligne d'un aéronef en escale pour résoudre des causes liées à un symptôme particulier (messages de type ECAM, alertes, etc.) reporté par le pilote dans un rapport de vol appelé logbook en terminologie anglo-saxonne. En utilisant le graphe d'événements redoutés, le système d'aide au diagnostic ne fait pas de relation de corrélation entre des pannes et des symptômes mais établit des relations de causalité cohérentes avec les analyses de sûreté, pouvant notamment servir pour des enquêtes, en particulier dans le cadre d'accidents. En outre, associé à un résultat de diagnostic, le graphe d'événements redoutés peut être utilisé dans une procédure de gestion de défaillance. En effet, une telle procédure consiste typiquement à tester les branches inférieures du graphe, liées aux objets accusables, sur lesquelles il existe des doutes de pannes, car l'ensemble des informations notifiées n'a pas été suffisant pour lever ces doutes. Pour lever des ambiguïtés, la procédure de gestion de défaillance peut s'appuyer sur le graphe afin de circonscrire les zones de doute puis faire appel à des nouveaux types de notifications apportés par des paramètres ACMF ou des résultats de tests avioniques. Selon un premier mode de réalisation, le système d'aide au diagnostic est mis en ceuvre dans un système de maintenance embarqué d'un aéronef. Les notifications reçues par le système d'aide au diagnostic sont, de préférence, des rapports de pannes du type ARINC 624 envoyés par les systèmes de l'aéronef, des notifications de messages de type ECAM, des messages de disponibilité et/ou des alertes transmises par le FWS. L'algorithme décrit en référence à la figure 5 est alors exécuté périodiquement ou sur réception d'une nouvelle notification. Le graphe d'événements redoutés utilisé correspond, de préférence, à la concaténation des graphes d'événements redoutés des systèmes de l'aéronef selon sa configuration effective en tenant compte, notamment, des équipements optionnels installés. La version du graphe d'événements redoutés embarqué dans un aéronef peut être une version allégée dépourvue de certaines branches, qui permet néanmoins d'obtenir un premier résultat de diagnostic mettant l'opérateur de maintenance sur une bonne piste. Une version complète du graphe d'événements redoutés peut être utilisée, dans un deuxième mode de réalisation, pour permettre, par exemple, à un avionneur de vendre un service de diagnostic détaillé à une compagnie aérienne. Les résultats d'aide au diagnostic sont avantageusement stockés à bord de l'aéronef. Ils peuvent ensuite être visualisés via une interface homme- machine. Ils peuvent également être envoyés à un système de traitement de l'information au sol via un système de communication (par exemple le système ACARS). La figure 7 illustre un tel mode de réalisation mis en oeuvre dans un aéronef 700 comprenant un ensemble de systèmes, génériquement référencés 705, chacun pourvu d'un système de surveillance de type BITE et un système d'alerte FWS 710. Les systèmes de surveillance ainsi que le système d'alerte transmettent des messages de notification d'événements détectés à un système de maintenance embarqué 715. Le système de maintenance embarqué 715 comprend une base de connaissance 720 comprenant notamment au moins un graphe d'événements redoutés 725 lié à un système de l'aéronef. Ce graphe d'événements redoutés est utilisé en combinaison avec les messages de notification reçus pour établir une aide au diagnostic conformément à l'invention en mettant en oeuvre, par exemple, l'algorithme décrit en référence à la figure 5. Le résultat d'une telle aide au diagnostic, comprenant un ensemble de vertex minimaux représentant des diagnostics minimaux, est mémorisé sous forme de rapport dans une base de données 730 pour être transmis, via des moyens de communication 735, par exemple un système ACARS, à un système de traitement de l'information au sol (non représenté) et/ou pour être consulté via une interface homme-machine 735. Un tel système permet une faible latence entre les notifications des systèmes surveillés et l'exécution de l'algorithme d'aide au diagnostic. En outre, la disponibilité, en temps réel, des résultats d'aide au diagnostic à bord de l'aéronef lui confère une autonomie de diagnostic.
Selon un autre mode de réalisation, l'algorithme d'aide au diagnostic est exécuté par un système de traitement de l'information au sol à partir de données transmises par un aéronef. L'algorithme d'aide au diagnostic peut-être exécuté par le constructeur de l'aéronef qui, de préférence, centralise et valide les résultats d'aide au diagnostic de plusieurs aéronefs, ces résultats pouvant être validés par des experts. Les résultats, comprenant un ensemble de vertex minimaux représentant des diagnostics minimaux, peuvent ensuite être transmis aux compagnies aériennes exploitant les aéronefs via un réseau de communication tel qu'Internet. Alternativement ou de façon complémentaire, l'algorithme d'aide au diagnostic peut être mis en ceuvre au sein d'une compagnie aérienne exploitant des aéronefs, l'algorithme d'aide au diagnostic pouvant être fournit par le constructeur d'aéronefs sous forme d'applications logicielles. Ces dernières peuvent être réalisées avec une architecture aux interfaces ouvertes et modulaires, permettant leur intégration avec d'autres services de gestion d'une flotte d'aéronefs. La figure 8 illustre un tel mode de réalisation mis en oeuvre pour des données issues d'un aéronef 800 comprenant un ensemble de systèmes, génériquement référencés 805, chacun pourvu d'un système de surveillance de type BITE et un système d'alerte FWS 810. Les systèmes de surveillance ainsi que le système d'alerte transmettent des messages de notification d'événements détectés à un système de maintenance embarqué 815. Le système de maintenance embarqué 815 peut transmettre des messages de notification reçus des systèmes de surveillance 805 et du système d'alerte 810, traités ou non, combinés ou' non, à un système de traitement de l'information 820, au sol, via des moyens de communication 825, par exemple un système ACARS. Le système de traitement de l'information 820 comprend une base de connaissance 830 comprenant notamment au moins un graphe d'événements redoutés 835 lié à un système de l'aéronef considéré. Ce graphe d'événements redoutés est utilisé en combinaison avec les messages de notification reçus pour établir une aide diagnostic conformément à l'invention en mettant en oeuvre, par exemple, l'algorithme décrit en référence à la figure 5.
Un résultat d'une telle aide au diagnostic, comprenant un ensemble de vertex minimaux représentant des diagnostics minimaux, est mémorisé sous forme de rapport dans une base de données 845. Il peut être consulté via une interface homme-machine 850 après qu'il ait été produit ou après qu'il ait été stocké. Un tel mode de réalisation permet de mettre en oeuvre un système centralisé d'aide au diagnostic au sol pouvant être utilisé pour établir une aide au diagnostic de plusieurs aéronefs. En outre, le système d'aide au diagnostic peut être intégré, par exemple, à un autre système d'information de maintenance ayant pour objet de programmer des tâches de maintenance et de gérer la logistique des pièces de rechanges. L'utilisation d'un tel mode de réalisation permet de réduire considérablement le temps nécessaire à l'établissement d'un diagnostic. Ainsi, il a été observé qu'associé à une procédure de gestion de défaillance, le gain de temps peut atteindre un facteur 50. La figure 9 illustre un exemple d'architecture matérielle d'un dispositif 900 adapté à mettre en ceuvre certaines étapes de l'invention, en particulier les étapes décrites en référence à la figure 5. Le dispositif 900 est, par exemple, un calculateur ou un ordinateur. II comporte ici un bus de communication 905 auquel sont reliés : - une ou plusieurs unités centrales de traitement ou microprocesseurs 910 (CPU) ; - une mémoire morte 915 (ROM, acronyme de Read Only Memory 15 en terminologie anglo-saxonne) pouvant comporter des programmes (prog, prog1 et prog2) nécessaires à la mise en oeuvre de l'invention ; - une mémoire vive ou mémoire cache 920 (RAM, acronyme de Random Access Memory en terminologie anglo-saxonne) comportant des registres adaptés à enregistrer des variables et paramètres créés et modifiés au 20 cours de l'exécution des programmes précités ; et - une interface de communication 950 adaptée à transmettre et à recevoir des données. Le dispositif 900 dispose également, de préférence, d'un disque dur 935 pouvant comporter les programmes précités ainsi que des informations 25 traitées ou à traiter selon l'invention et d'un lecteur de cartes mémoires 940 adapté à recevoir une carte mémoire 945 et à y lire ou à y écrire des données traitées ou à traiter selon l'invention. Le bus de communication permet la communication et l'interopérabilité entre les différents éléments inclus dans le dispositif 900 ou 30 reliés à lui. La représentation du bus n'est pas limitative et, notamment, l'unité centrale est susceptible de communiquer des instructions à tout élément du dispositif 900 directement ou par l'intermédiaire d'un autre élément du dispositif 900. Le code exécutable de chaque programme permettant au dispositif programmable de mettre en oeuvre les processus selon l'invention, peut être stocké, par exemple, dans le disque dur 935 ou en mémoire morte 915. Selon une variante, la carte mémoire 945 peut contenir des informations, notamment des informations à traiter selon l'invention, ainsi que le code exécutable des programmes précités qui, une fois lu par le dispositif 900, est stocké dans le disque dur 935.
Selon une autre variante, le code exécutable des programmes et les informations à traiter selon l'invention pourront être reçus, au moins partiellement, par l'intermédiaire de l'interface 950, pour être stocké de façon identique à celle décrite précédemment. De manière plus générale, le ou les programmes ainsi que les 15 informations à traiter selon l'invention pourront être chargés dans un des moyens de stockage du dispositif 900 avant d'être exécutés. L'unité centrale 910 va commander et diriger l'exécution des instructions ou portions de code logiciel du ou des programmes selon l'invention, instructions qui sont stockées dans le disque dur 935 ou dans la 20 mémoire morte 915 ou bien dans les autres éléments de stockage précités. Lors de la mise sous tension, le ou les programmes qui sont stockés dans une mémoire non volatile, par exemple le disque dur 935 ou la mémoire morte 915, sont transférés dans la mémoire vive 920 qui contient alors le code exécutable du ou des programmes selon l'invention, ainsi que des registres pour 25 mémoriser les variables et paramètres nécessaires à la mise en oeuvre de l'invention. Naturellement, pour satisfaire des besoins spécifiques, une personne compétente dans le domaine de l'invention pourra appliquer des modifications dans la description précédente.
Claims (11)
- REVENDICATIONS1. Procédé pour ordinateur d'établissement d'une aide au diagnostic d'un système complexe d'un aéronef (700, 800) comprenant une pluralité de sous-systèmes (705, 805), au moins un sous-système de ladite pluralité de sous-systèmes comprenant des moyens de surveillance et de notification d'au moins un événement détecté, ce procédé étant caractérisé en ce que : il met en oeuvre un graphe d'événements redoutés (200, 300) modélisant au moins partiellement ledit système complexe, ledit graphe d'événements redoutés comprenant une pluralité de sommets (205-250), chaque sommet de ladite pluralité de sommets étant relié par une relation d'implication logique à au moins un autre sommet de ladite pluralité de sommets, ladite pluralité de sommets comprenant au moins, - un sommet représentant un événement redouté (205, 210) ; et, - un sommet représentant au moins un élément (245, 250) dudit système complexe, ledit au moins un élément étant susceptible de tomber en panne ; il comprend les étapes suivantes, - réception (500) d'au moins un message de notification de réalisation dudit au moins un événement détecté ; - création (510) d'un ensemble d'événements redoutés, chaque événement redouté dudit ensemble d'événements redoutés étant associé à un sommet dudit graphe d'événements redoutés lié audit au moins un message de notification reçu ; - pour chaque événement redouté dudit ensemble d'événements redoutés, construction (515), à partir dudit graphe d'événements redoutés, d'au moins une expression logiqueconduisant audit événement redouté, ladite au moins une expression logique étant basée sur des éléments dudit système complexe ; - création (520) d'au moins un groupe d'événements redoutés dudit ensemble d'événements redoutés, au moins un élément étant commun à deux expressions logiques liées à deux événements redoutés distincts dudit au moins un groupe, les expressions logiques associées auxdits événements redoutés dudit au moins un groupe représentant un diagnostic relatif audit au moins un événement détecté.
- 2. Procédé selon la revendication 1 comprenant en outre une étape de détermination (525) des vertex minimaux des expressions logiques des événements redoutés dudit au moins un groupe, lesdits vertex minimaux formant des diagnostics minimaux dudit diagnostic relatif audit au moins un événement détecté.
- 3. Procédé selon la revendication 1 ou la revendication 2, ledit graphe d'événements redoutés comprenant en outre au moins un sommet représentant un message (400, 405) associé audit au moins un événement détecté, le procédé comprenant en outre une étape d'identification (505), dans ledit graphe d'événements redoutés, d'au moins un sommet représentant un message selon ledit au moins un message reçu, chaque événement redouté dudit ensemble d'événements redoutés étant associé à un sommet dudit graphe d'événements redoutés lié audit au moins un message de notification via ledit au moins un sommet identifié.
- 4. Procédé selon l'une quelconque des revendications 1 à 3 comprenant en outre une étape d'affichage, de mémorisation et/ou de transmission dudit diagnostic relatif audit au moins un événement détecté.
- 5. Procédé selon l'une quelconque des revendications 1 à 4 selon lequel ledit graphe d'événements redoutés comprend au moins un sous-graphe d'événements redoutés, ledit au moins un sous-graphe d'événements redoutés modélisant au moins partiellement un sous-système de ladite pluralité de sous- systèmes.
- 6. Procédé selon l'une quelconque des revendications précédentes selon lequel ledit graphe d'événements redoutés comprend en outre au moins un sommet représentant une opération logique, au moins une desdites expressions logiques comprenant une opération logique représentée par un sommet dudit graphe d'événements redoutés.
- 7. Programme d'ordinateur comprenant des instructions adaptées à la mise en ceuvre de chacune des étapes du procédé selon l'une quelconque des revendications précédentes lorsque ledit programme est exécuté sur un ordinateur.
- 8. Système de maintenance (715) d'un aéronef comprenant un calculateur comprenant des moyens pour mettre en oeuvre chacune des étapes du procédé selon l'une quelconque des revendications 1 à 6.
- 9. Système de maintenance selon la revendication précédente comprenant en outre des moyens (735) pour transmettre ledit diagnostic à un 15 système distant.
- 10. Aéronef comprenant le système selon la revendication 8 ou la revendication 9.
- 11. Système de traitement de l'information (820) comprenant des moyens pour recevoir des informations relatives à au moins un message de 20 notification de réalisation d'au moins un événement détecté par des moyens de surveillance et de notification d'un sous-système d'un système complexe d'un aéronef (800) comprenant une pluralité de sous-systèmes (705, 805) et un calculateur comprenant des moyens pour mettre en oeuvre chacune des étapes du procédé selon l'une quelconque des revendications 1 à 6. 25
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1004161A FR2966616B1 (fr) | 2010-10-22 | 2010-10-22 | Procede, dispositif et programme d'ordinateur d'aide au diagnostic d'un systeme d'un aeronef, utilisant des graphes d'evenements redoutes |
| US13/276,632 US8996340B2 (en) | 2010-10-22 | 2011-10-19 | Method, devices and computer program for assisting in the diagnostic of an aircraft system, using failure condition graphs |
| CN201110321643.2A CN102455704B (zh) | 2010-10-22 | 2011-10-21 | 使用可疑事件图进行航空器系统诊断辅助的方法、装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1004161A FR2966616B1 (fr) | 2010-10-22 | 2010-10-22 | Procede, dispositif et programme d'ordinateur d'aide au diagnostic d'un systeme d'un aeronef, utilisant des graphes d'evenements redoutes |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR2966616A1 true FR2966616A1 (fr) | 2012-04-27 |
| FR2966616B1 FR2966616B1 (fr) | 2012-12-14 |
Family
ID=43508560
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR1004161A Active FR2966616B1 (fr) | 2010-10-22 | 2010-10-22 | Procede, dispositif et programme d'ordinateur d'aide au diagnostic d'un systeme d'un aeronef, utilisant des graphes d'evenements redoutes |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US8996340B2 (fr) |
| CN (1) | CN102455704B (fr) |
| FR (1) | FR2966616B1 (fr) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR3009396A1 (fr) * | 2013-07-31 | 2015-02-06 | Airbus Operations Sas | Procede et programme d'ordinateur d'aide a la maintenance d'equipements d'un aeronef |
| US9834317B2 (en) | 2013-09-20 | 2017-12-05 | Airbus Operations (S.A.S.) | Method for identifying a piece of defective equipment in an aircraft |
Families Citing this family (20)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20130066924A1 (en) * | 2008-12-23 | 2013-03-14 | Honeywell International Inc. | Method and apparatus for utilizing matlab functionality in java-enabled environment |
| DE102011079034A1 (de) | 2011-07-12 | 2013-01-17 | Siemens Aktiengesellschaft | Ansteuerung eines technischen Systems |
| US20130197739A1 (en) * | 2012-01-31 | 2013-08-01 | Gulfstream Aerospace Corporation | Methods and systems for aircraft health and trend monitoring |
| US8798817B2 (en) * | 2012-01-31 | 2014-08-05 | Gulfstream Aerospace Corporation | Methods and systems for requesting and retrieving aircraft data during flight of an aircraft |
| FR2989500B1 (fr) * | 2012-04-12 | 2014-05-23 | Airbus Operations Sas | Procede, dispositifs et programme d'ordinateur d'aide a l'analyse de la tolerance aux pannes d'un systeme d'un aeronef, utilisant des graphes d'evenements redoutes |
| US10539955B2 (en) * | 2012-06-15 | 2020-01-21 | The Boeing Company | Failure analysis validation and visualization |
| GB2513132B (en) * | 2013-04-16 | 2015-05-27 | Ge Aviat Systems Ltd | Method for predicting a bleed air system fault |
| GB2513133B (en) | 2013-04-16 | 2015-07-08 | Ge Aviat Systems Ltd | Methods for predicting a speed brake system fault |
| US20150149024A1 (en) * | 2013-11-22 | 2015-05-28 | Sikorsky Aircraft Corporation | Latency tolerant fault isolation |
| FR3018933A1 (fr) * | 2014-03-20 | 2015-09-25 | Airbus | Procede de determination de l'etat d'un equipement d'aeronef. |
| CN105281945B (zh) * | 2014-09-19 | 2020-04-07 | 中国人民解放军第二炮兵工程大学 | 基于数据流的确定性网络完整性故障检测方法 |
| US9547944B2 (en) | 2015-06-10 | 2017-01-17 | Honeywell International Inc. | Health monitoring system for diagnosing and reporting anomalies |
| EP3443474A1 (fr) * | 2016-04-11 | 2019-02-20 | KPIT Technologies Ltd. | Base de données de graphes de diagnostic et de surveillance d'intégrité d'un système |
| US10599421B2 (en) | 2017-07-14 | 2020-03-24 | Calamp Corp. | Systems and methods for failsafe firmware upgrades |
| FR3072647B1 (fr) * | 2017-10-24 | 2019-11-15 | Dassault Aviation | Systeme de controle d'une trajectoire laterale d'un aeronef incluant un palonnier |
| SE543122C2 (sv) * | 2019-02-05 | 2020-10-13 | Brokk Ab | Förfarande, anordning och användargränssnitt som beskriver ett operativt drifttillstånd hos en demoleringsrobot |
| US11615656B2 (en) | 2019-12-20 | 2023-03-28 | Pratt & Whitney Canada Corp. | Method and system for diagnosing an engine or an aircraft |
| CN111736568A (zh) * | 2020-05-20 | 2020-10-02 | 天津市天锻压力机有限公司 | 一种实时数据库的故障快速诊断方法及系统 |
| CN113268591B (zh) * | 2021-04-17 | 2022-11-01 | 中国人民解放军战略支援部队信息工程大学 | 基于事理图谱的空中目标意图判证方法及系统 |
| CN114154586B (zh) * | 2021-12-09 | 2022-08-26 | 中国民用航空飞行学院 | 一种航空器系统定量相似性分析方法、装置及介质 |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2003032249A1 (fr) * | 2001-10-09 | 2003-04-17 | University Of Maryland, College Park | Procede et appareil destines a un module de defaillances d'origine commune, utilises dans les outils d'evaluation probabiliste des risques |
| US20060195302A1 (en) * | 2005-02-11 | 2006-08-31 | Amir Fijany | System for solving diagnosis and hitting set problems |
| FR2927435A1 (fr) * | 2008-02-08 | 2009-08-14 | Airbus France Sas | Procede et dispositif ameliores pour les operations de diagnostic et de maintenance d'aeronefs |
Family Cites Families (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6223143B1 (en) * | 1998-08-31 | 2001-04-24 | The United States Government As Represented By The Administrator Of The National Aeronautics And Space Administration | Quantitative risk assessment system (QRAS) |
| US20050065753A1 (en) * | 2003-09-24 | 2005-03-24 | International Business Machines Corporation | Apparatus and method for monitoring system health based on fuzzy metric data ranges and fuzzy rules |
| US20070028220A1 (en) * | 2004-10-15 | 2007-02-01 | Xerox Corporation | Fault detection and root cause identification in complex systems |
| US7230527B2 (en) * | 2004-11-10 | 2007-06-12 | The Boeing Company | System, method, and computer program product for fault prediction in vehicle monitoring and reporting system |
| FR2891379B1 (fr) * | 2005-09-23 | 2007-11-30 | Thales Sa | Procede et systeme de diagnostic des pannes pour aerodynes |
| FR2905763B1 (fr) * | 2006-09-11 | 2008-12-12 | Eurocopter France | Procede et systeme de diagnostic d'un aeronef a partir de mesures effectuees sur l'aeronef. |
| CN101063643B (zh) * | 2007-02-02 | 2011-06-29 | 北京航空航天大学 | 飞机故障智能诊断方法及系统 |
| US8437904B2 (en) * | 2007-06-12 | 2013-05-07 | The Boeing Company | Systems and methods for health monitoring of complex systems |
| US8467913B2 (en) * | 2007-10-31 | 2013-06-18 | Airbus Operations Gmbh | Method and arrangement for providing a fault diagnosis for at least one system |
| FR2935186B1 (fr) * | 2008-08-20 | 2010-09-17 | Airbus France | Procede et dispositif d'aide au diagnostic et a la decision d'exploitation d'un aeronef |
| FR2949161B1 (fr) * | 2009-08-14 | 2011-09-09 | Thales Sa | Dispositif pour le diagnostic de systeme |
| CN102416821A (zh) * | 2011-07-27 | 2012-04-18 | 中国国际航空股份有限公司 | 飞机系统数据处理方法 |
-
2010
- 2010-10-22 FR FR1004161A patent/FR2966616B1/fr active Active
-
2011
- 2011-10-19 US US13/276,632 patent/US8996340B2/en active Active
- 2011-10-21 CN CN201110321643.2A patent/CN102455704B/zh active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2003032249A1 (fr) * | 2001-10-09 | 2003-04-17 | University Of Maryland, College Park | Procede et appareil destines a un module de defaillances d'origine commune, utilises dans les outils d'evaluation probabiliste des risques |
| US20060195302A1 (en) * | 2005-02-11 | 2006-08-31 | Amir Fijany | System for solving diagnosis and hitting set problems |
| FR2927435A1 (fr) * | 2008-02-08 | 2009-08-14 | Airbus France Sas | Procede et dispositif ameliores pour les operations de diagnostic et de maintenance d'aeronefs |
Non-Patent Citations (1)
| Title |
|---|
| DR. MICHAEL STAMATELATOS, DR WILLIAM VESELY: "Fault Tree Handbook with Aerospace Applications", NASA OFFICE OF SAFETY AND MISSION ASSURANCE, August 2002 (2002-08-01), Washington, DC, pages 1 - 205, XP002620316 * |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR3009396A1 (fr) * | 2013-07-31 | 2015-02-06 | Airbus Operations Sas | Procede et programme d'ordinateur d'aide a la maintenance d'equipements d'un aeronef |
| US9834317B2 (en) | 2013-09-20 | 2017-12-05 | Airbus Operations (S.A.S.) | Method for identifying a piece of defective equipment in an aircraft |
Also Published As
| Publication number | Publication date |
|---|---|
| US8996340B2 (en) | 2015-03-31 |
| FR2966616B1 (fr) | 2012-12-14 |
| US20120101793A1 (en) | 2012-04-26 |
| CN102455704A (zh) | 2012-05-16 |
| CN102455704B (zh) | 2016-08-03 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| FR2966616A1 (fr) | Procede, dispositif et programme d'ordinateur d'aide au diagnostic d'un systeme d'un aeronef, utilisant des graphes d'evenements redoutes | |
| FR2989500A1 (fr) | Procede, dispositifs et programme d'ordinateur d'aide a l'analyse de la tolerance aux pannes d'un systeme d'un aeronef, utilisant des graphes d'evenements redoutes | |
| FR2989499A1 (fr) | Procede, dispositifs et programme d'ordinateur d'aide au diagnostic preventif d'un systeme d'un aeronef, utilisant des graphes d'evenements redoutes | |
| US10616043B2 (en) | Real-time probabilistic root cause correlation of network failures | |
| US11126493B2 (en) | Methods and systems for autonomous cloud application operations | |
| EP3350660B1 (fr) | Système et procédé d'aide à la decision pour la maintenance d'une machine avec apprentissage d'un modèle de décision supervisé par avis d'experts | |
| FR2927435A1 (fr) | Procede et dispositif ameliores pour les operations de diagnostic et de maintenance d'aeronefs | |
| WO2010057846A1 (fr) | Procédé de reconnaissance de motifs séquentiels pour procédé de traitement des messages de pannes | |
| FR2914764A1 (fr) | Procede et dispositif de determination d'un diagnostic de panne d'une unite fonctionnelle dans un systeme avionique embarque | |
| EP1846824B1 (fr) | Systeme et procede de traitements embarques d'essais en vol | |
| FR2953954A1 (fr) | Dispositif d'elaboration des alertes d'un systeme d'aeronef | |
| US8457811B2 (en) | Device for system diagnosis | |
| FR2935818A1 (fr) | Systeme d'ordonnancement de taches pour controler l'execution de procedures d'alerte sur un aeronef | |
| FR3001556A1 (fr) | Procede, dispositif et programme d'ordinateur d'aide a la maintenance d'un systeme d'un aeronef utilisant un outil d'aide au diagnostic et des donnees de retour d'experience | |
| FR3007000A1 (fr) | Systeme de surveillance d'une plateforme avionique a architecture trois tiers | |
| EP2149823A1 (fr) | Système aéronautique embarqué à reconfiguration dynamique, procédé associé et aéronef embarquant un tel système | |
| EP2538376B1 (fr) | Système de prescription de maintenance d'un moteur d'hélicoptère | |
| EP2153326B1 (fr) | Procédé et dispositif de surveillance de systèmes avioniques reliés à un média partagé | |
| FR2990547A1 (fr) | Systeme de maintenance centralisee parametrable destine a un aeronef | |
| CN109460344B (zh) | 一种服务器的运维分析方法与系统 | |
| FR2950184A1 (fr) | Procede et dispositif de gestion centralisee d'alertes dans un aeronef comprenant plusieurs interfaces de presentation d'alertes | |
| EP3729302B1 (fr) | Procédé et système d'aide au dépannage d'un système complexe | |
| WO2007036452A1 (fr) | Procede et systeme de validation des defaillances pour aerodynes | |
| FR2923925A1 (fr) | Procede d'evaluation de la surete de fonctionnement d'un systeme | |
| EP3443425A1 (fr) | Procédé de contrôle d'intégrité de l'avionique d'un aéronef, dispositif et produit programme d'ordinateur associés |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 6 |
|
| PLFP | Fee payment |
Year of fee payment: 7 |
|
| PLFP | Fee payment |
Year of fee payment: 8 |
|
| PLFP | Fee payment |
Year of fee payment: 9 |
|
| PLFP | Fee payment |
Year of fee payment: 10 |
|
| PLFP | Fee payment |
Year of fee payment: 11 |
|
| PLFP | Fee payment |
Year of fee payment: 12 |
|
| PLFP | Fee payment |
Year of fee payment: 13 |
|
| PLFP | Fee payment |
Year of fee payment: 14 |