FR2989499A1 - Procede, dispositifs et programme d'ordinateur d'aide au diagnostic preventif d'un systeme d'un aeronef, utilisant des graphes d'evenements redoutes - Google Patents
Procede, dispositifs et programme d'ordinateur d'aide au diagnostic preventif d'un systeme d'un aeronef, utilisant des graphes d'evenements redoutes Download PDFInfo
- Publication number
- FR2989499A1 FR2989499A1 FR1253383A FR1253383A FR2989499A1 FR 2989499 A1 FR2989499 A1 FR 2989499A1 FR 1253383 A FR1253383 A FR 1253383A FR 1253383 A FR1253383 A FR 1253383A FR 2989499 A1 FR2989499 A1 FR 2989499A1
- Authority
- FR
- France
- Prior art keywords
- dreaded
- graph
- minimal
- aircraft
- diagnostics
- 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
- 238000000034 method Methods 0.000 title claims description 83
- 238000004590 computer program Methods 0.000 title claims description 5
- 230000003449 preventive effect Effects 0.000 title abstract description 18
- 230000002829 reductive effect Effects 0.000 title description 2
- 238000012544 monitoring process Methods 0.000 claims abstract description 21
- 238000012423 maintenance Methods 0.000 claims description 56
- 230000002688 persistence Effects 0.000 claims description 43
- 230000000694 effects Effects 0.000 claims description 25
- 238000004364 calculation method Methods 0.000 claims description 11
- 238000003745 diagnosis Methods 0.000 abstract description 32
- 208000037265 diseases, disorders, signs and symptoms Diseases 0.000 description 51
- 208000035475 disorder Diseases 0.000 description 51
- 238000001514 detection method Methods 0.000 description 28
- 238000004458 analytical method Methods 0.000 description 26
- 238000004422 calculation algorithm Methods 0.000 description 26
- 230000014509 gene expression Effects 0.000 description 14
- 230000010006 flight Effects 0.000 description 12
- 238000012360 testing method Methods 0.000 description 12
- 238000013024 troubleshooting Methods 0.000 description 12
- 238000007726 management method Methods 0.000 description 11
- 101000799969 Escherichia coli (strain K12) Alpha-2-macroglobulin Proteins 0.000 description 10
- 230000006870 function Effects 0.000 description 10
- 230000008901 benefit Effects 0.000 description 9
- 238000004891 communication Methods 0.000 description 9
- 230000009471 action Effects 0.000 description 5
- 230000010365 information processing Effects 0.000 description 5
- 230000005764 inhibitory process Effects 0.000 description 5
- 230000007257 malfunction Effects 0.000 description 5
- 230000002085 persistent effect Effects 0.000 description 5
- 101100482999 Arabidopsis thaliana TSM1 gene Proteins 0.000 description 3
- 101100205899 Saccharomyces cerevisiae (strain ATCC 204508 / S288c) TAF2 gene Proteins 0.000 description 3
- 238000011058 failure modes and effects analysis Methods 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 230000001364 causal effect Effects 0.000 description 2
- 230000008859 change Effects 0.000 description 2
- 230000002950 deficient Effects 0.000 description 2
- 238000011156 evaluation Methods 0.000 description 2
- 230000000977 initiatory effect Effects 0.000 description 2
- 238000002955 isolation Methods 0.000 description 2
- 230000000670 limiting effect Effects 0.000 description 2
- 239000000463 material Substances 0.000 description 2
- 238000002360 preparation method Methods 0.000 description 2
- 230000008569 process Effects 0.000 description 2
- 238000012545 processing Methods 0.000 description 2
- 230000004083 survival effect Effects 0.000 description 2
- 208000024891 symptom Diseases 0.000 description 2
- 230000002159 abnormal effect Effects 0.000 description 1
- 230000004913 activation Effects 0.000 description 1
- 230000006978 adaptation Effects 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 230000033228 biological regulation Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 230000015556 catabolic process Effects 0.000 description 1
- 230000000295 complement effect Effects 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 230000009849 deactivation Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000004064 dysfunction Effects 0.000 description 1
- 238000002124 flame ionisation detection Methods 0.000 description 1
- 239000012530 fluid Substances 0.000 description 1
- 238000007429 general method Methods 0.000 description 1
- 230000036541 health Effects 0.000 description 1
- 230000003116 impacting effect Effects 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 230000002427 irreversible effect Effects 0.000 description 1
- 238000005457 optimization Methods 0.000 description 1
- 238000012805 post-processing Methods 0.000 description 1
- 238000012913 prioritisation Methods 0.000 description 1
- 230000009467 reduction Effects 0.000 description 1
- 230000008439 repair process Effects 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 238000007619 statistical method Methods 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
- 238000010200 validation analysis Methods 0.000 description 1
Classifications
-
- B—PERFORMING OPERATIONS; TRANSPORTING
- B64—AIRCRAFT; AVIATION; COSMONAUTICS
- B64F—GROUND OR AIRCRAFT-CARRIER-DECK INSTALLATIONS SPECIALLY ADAPTED FOR USE IN CONNECTION WITH AIRCRAFT; DESIGNING, MANUFACTURING, ASSEMBLING, CLEANING, MAINTAINING OR REPAIRING AIRCRAFT, NOT OTHERWISE PROVIDED FOR; HANDLING, TRANSPORTING, TESTING OR INSPECTING AIRCRAFT COMPONENTS, NOT OTHERWISE PROVIDED FOR
- B64F5/00—Designing, manufacturing, assembling, cleaning, maintaining or repairing aircraft, not otherwise provided for; Handling, transporting, testing or inspecting aircraft components, not otherwise provided for
- B64F5/40—Maintaining or repairing aircraft
-
- 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/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
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Health & Medical Sciences (AREA)
- Biomedical Technology (AREA)
- Manufacturing & Machinery (AREA)
- Transportation (AREA)
- Aviation & Aerospace Engineering (AREA)
- Testing And Monitoring For Control Systems (AREA)
Abstract
L'invention a notamment pour objet l'aide au diagnostic préventif 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'un événement détecté, utilisant des graphes d'événements redoutés. Après avoir reçu (110) un message de notification de réalisation dudit événement détecté, un ensemble de diagnostics minimaux relatifs audit au moins un événement détecté, comprenant une pluralité d'éléments chacun représenté par un sommet dudit graphe d'événements redoutés, est créé (115), chaque élément dudit ensemble de diagnostics minimaux étant déterminés selon au moins une relation d'implication logique dudit graphe d'événements redoutés avec un sommet représentant ledit au moins un message de notification reçu. Au moins une partie des éléments dudit ensemble de diagnostics minimaux est ensuite ordonnée (130), lesdits éléments ordonnancés appartenant audit rapport de diagnostic.
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 préventif 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. Ils peuvent être utilisés dans le but d'établir des diagnostics préventifs, à bord de l'aéronef considéré ou au sol via, par exemple, des services de type web services. Ces systèmes de diagnostic peuvent utiliser des messages issus de systèmes de surveillance d'é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. Ainsi, par exemple, les systèmes de diagnostic connus sous le nom d'OMS (sigle d'On-board Maintenance System en terminlogie anglo-saxonne), notamment mis en oeuvre dans les aéronefs A380 de la société Airbus (Airbus et A380 sont des marques) permettent de regrouper des messages reçus de systèmes de surveillance d'équipements et d'accéder à des rapports générés en cours de vol pour effectuer une analyse statistique permettant d'identifier des pannes potentielles à venir. Le regroupement de messages est ici effectué par une application logicielle d'un système centralisé de maintenance, appelé CMS (sigle de Centralized Maintenance System en terminologie anglo-saxonne) qui 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 messages indiquent des équipements en panne ainsi que des informations de pannes possibles basées sur des analyses statistiques tels que le MTBF (sigle de Mean Time Between Failures en terminologie anglo-saxonne, ou temps moyen entre pannes). L'accès à des rapports générés en cours de vol vise typiquement l'accès à des rapports connus sous le nom d'ACMS (sigle d'Aircraft Condition Monitoring System en terminologie anglo-saxonne) qui sont générés systématiquement à certaines phases de chaque vol ou lors de la détection d'événements particuliers, par exemple le dépassement d'un seuil prédéterminé par un paramètre donné de l'aéronef. De tels rapports représentent ainsi une vision de l'état d'un certain nombre de paramètres et d'équipements de l'aéronef. Concaténés, ces rapports ACMS permettent à la compagnie aérienne exploitant l'aéronef de suivre son état et d'intervenir quand cela lui paraît nécessaire. Certains constructeurs d'aéronefs offrent, dans un système au sol appelé AHM (sigle d'Airplane Health Management en terminologie anglo-saxonne) interfacé avec les rapports émis par un aéronef, la possibilité de prévenir des effets possibles de pannes à venir dans le cockpit (appelés FDE pour Flight Deck Effect en terminologie anglo-saxonne). A ces fins, l'AHM calcule et adapte un temps restant pour effectuer une maintenance (appelé TTF, sigle de Time To Failure en terminologie anglo-saxonne) pour les messages de maintenance reportés par une fonction CMCF (sigle de Centralised Maintenance Computing Function en terminologie anglo-saxonne) de l'aéronef et sur l'historique de ces messages. Afin de planifier des tâches de maintenance préventive, une compagnie aérienne a besoin de connaître à l'avance un dysfonctionnement qui va arriver. Mais cela ne suffit pas sur les aéronefs de dernière génération où les systèmes sont très interdépendants, incorporent des composants aux modes de défaillances complexes et présentent des architectures tolérantes aux pannes simples.
Une capacité de tolérance aux pannes permet à un aéronef de rester disponible même si un équipement est en panne. Une liste des équipements fonctionnels minimums (appelée MEL, acronyme de Minimum Equipement List en terminologie anglo-saxonne) fixe les conditions selon lesquelles un aéronef 5 dont au moins un équipement est en panne peut être exploité (une telle capacité étant appelée dispatch en terminologie anglo-saxonne). A titre d'illustration, une compagnie aérienne peut être autorisée à exploiter un aéronef pendant 10 jours avec certains équipements en panne. Ainsi, ces conditions d'exploitation sont encadrées par la MEL et s'accompagnent souvent d'actions 10 de maintenance obligatoires pour inspecter les équipements en état de marche liés aux équipements en panne et/ou assurer manuellement la désactivation sécurisée des équipements en pannes. Une capacité de tolérance aux pannes permet également à une compagnie aérienne d'exploiter un aéronef tout en préparant, de façon 15 parallèle, l'achat et l'approvisionnement des équipements de rechange ainsi que la maintenance associée. Dans ce contexte, non seulement il est nécessaire d'obtenir un état des pannes d'équipements dans un aéronef pour décider de son exploitation mais en outre, la compagnie aérienne exploitant cet aéronef souhaite connaître 20 exactement la marge de tolérance restante avant qu'un dysfonctionnement plus impactant ne survienne, par exemple une situation dite NO GO dans la MEL, qui n'autorise pas la compagnie aérienne à exploiter l'aéronef dans cet état ou une situation selon laquelle la prise en charge des passagers ne serait pas en adéquation avec l'image que veut se donner la compagnie aérienne (par 25 exemple si le système vidéo ne fonctionne plus en cabine). Il existe des besoins pour fournir des informations de maintenance prédictive et de tolérance aux pannes. L'invention permet de résoudre au moins un des problèmes exposés précédemment. 30 L'invention a ainsi pour objet un procédé pour ordinateur d'aide à l'établissement d'un rapport de 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é étant caractérisé en ce que : il met en oeuvre 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, - une pluralité de sommets représentant chacun un message de notification susceptible d'être reçu ; - au moins un sommet représentant un événement redouté ; et, - une pluralité de sommets représentant chacun un élément dudit système complexe, chaque élément représenté par un sommet étant susceptible de tomber en panne ; il comprend 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 de diagnostics minimaux relatifs audit au moins un événement détecté, comprenant une pluralité d'éléments chacun représenté par un sommet dudit graphe d'événements redoutés, chaque élément dudit ensemble de diagnostics minimaux étant déterminés selon au moins une relation d'implication logique dudit graphe d'événements redoutés avec un sommet représentant ledit au moins un message de notification reçu ; et - ordonnancement d'au moins une partie des éléments dudit ensemble de diagnostics minimaux, lesdits éléments ordonnancés appartenant audit rapport de diagnostic.
Le procédé selon l'invention permet notamment de faciliter la prise de décision au sol, par exemple par le centre de contrôle de maintenance de la compagnie exploitant l'aéronef car le résultat de diagnostic est classé par pertinence. En outre, ce procédé étant basé sur des connaissances physiques et topologiques du système, par exemple des connaissances physiques et topologiques de l'aéronef cohérentes avec les analyses AMDEC (acronyme d'Analyse des Modes de Défaillances, de leurs Effets et de leur Criticité, ou FMEA en terminologie anglo-saxonne) et la liste minimale des équipements (MEL), il permet notamment l'obtention d'information sur la marge de tolérance à la panne restante basée sur la connaissance de l'architecture des systèmes. Il permet également de connaître la liste des équipements restant encore en fonctionnement, se trouvant sur un chemin du dysfonctionnement impactant à venir. L'obtention de ces informations peut être réalisée en temps réel et transmis à un système distant, par exemple d'un aéronef en vol à un système au sol. Ledit graphe d'événements redoutés peut être au moins partiellement généré par instanciation d'au moins un sous-graphe générique pour en simplifier la création et la gestion. Selon un mode de réalisation particulier, le procédé comprend en outre une étape d'obtention de données représentatives d'un historique de diagnostics dudit système complexe, ladite étape d'ordonnancement étant au moins partiellement fondée sur lesdites données représentatives dudit historique de diagnostic Ainsi, en utilisant l'historique de diagnostic pour consolider un degré de certitude d'analyse en ordonnant des résultats de diagnostic sur lesquels peut se baser une analyse préventive, il est possible de favoriser la maintenance des objets accusables suspectés le plus souvent, ce qui évite de laisser trop longtemps un objet en panne non résolue. Ceci est particulièrement utile dans le cas de l'exploitation d'un aéronef ne revenant pas à sa base principale après une série de vols et sur lequel des équipes de maintenance différentes travaillent. En effet, dans ce cas, les opérateurs de maintenance ne sont pas les mêmes personnes d'un aéroport à l'autre, ils n'ont qu'un regard ponctuel sur l'aéronef dans un aéroport donné. Les résultats obtenus à l'aide des étapes décrites précédemment permettent de bénéficier de l'historique des diagnostics précédents. En outre, le procédé permet de faciliter la prise de décision au sol, par exemple par le centre de contrôle de maintenance de la compagnie exploitant l'aéronef car le résultat de diagnostic sera déjà classé en fonction de l'historique, évitant au personnel de ce centre de faire le travail manuellement de vol en vol.
Toujours selon un mode de réalisation particulier, ladite étape d'ordonnancement d'au moins une partie des éléments dudit ensemble de diagnostics minimaux comprend une étape d'ordonnancement d'au moins une partie desdits diagnostics minimaux. Le procédé comprend en outre, de préférence, une étape de calcul de poids de persistance de chaque élément d'une pluralité d'éléments dudit ensemble de diagnostics minimaux, ledit calcul de poids de persistance étant basé sur la présence de chaque élément de ladite pluralité d'éléments dudit ensemble de diagnostics minimaux dans un ensemble de diagnostics minimaux dudit historique de diagnostics, ledit ordonnancement d'au moins une partie desdits diagnostics minimaux étant au moins partiellement basé sur des résultats dudit calcul de poids de persistance. Toujours selon un mode de réalisation particulier, le procédé comprend en outre une étape de priorisation d'éléments dudit ensemble de diagnostics minimaux.
Ladite étape d'ordonnancement d'au moins une partie des éléments dudit ensemble de diagnostics minimaux comprend, de préférence, une étape d'ordonnancement de troubles résultants desdits diagnostics minimaux. Selon un mode de réalisation particulier, le procédé comprend en outre une étape de calcul de poids de persistance de chaque trouble d'une pluralité de troubles résultants desdits diagnostics minimaux, ledit ordonnancement de troubles étant au moins partiellement basé sur des résultats dudit calcul de poids de persistance. Toujours selon un mode de réalisation particulier, le procédé comprend en outre une étape de sélection d'au moins un message de notification susceptible d'être reçu représenté par un sommet dudit graphe d'événements redoutés et une étape d'identification des éléments dudit ensemble de diagnostics minimaux pouvant conduire à la génération dudit au moins un message de notification sélectionné, lesdits éléments identifiés appartenant audit rapport de diagnostic. Des attributs peuvent être obtenus et assignés auxdits éléments identifiés. Le procédé selon l'invention utilise ainsi des connaissances 5 physiques exhaustives pour indiquer des objets accusables non encore déclarés en panne mais dont une défaillance conduirait à un événement redouté. Cette information est très importante pour la prise de décision. En effet, une telle information permet par exemple d'éviter de laisser partir un aéronef si la marge de tolérance n'est due, par exemple, qu'à la survie d'un 10 LRU très cher à acheminer sur le lieu de destination de l'aéronef. Dans ce cas, le risque d'une longue immobilisation de l'aéronef, en attentant un LRU de rechange, est grand. En revanche, si la marge de tolérance est entamée mais que la logistique et la maintenance des pièces de rechange ne posent pas de problème en termes de coûts et d'opération, il est moins risqué de laisser partir 15 l'aéronef. De façon avantageuse, le procédé comprend en outre une étape de calcul de distance restante avant effet imminent pour au moins un desdits éléments identifiés, ladite distante restante étant calculée en fonction du nombre d'éléments n'appartenant pas audit ensemble de diagnostics minimaux 20 et dont une défaillance est nécessaire à la génération dudit au moins un message de notification sélectionné. Toujours selon un mode de réalisation particulier, le procédé comprend en outre une étape de sélection d'au moins une procédure de résolution de pannes visant au moins un élément dudit ensemble de 25 diagnostics minimaux. 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 ainsi qu'un système de maintenance d'un aéronef comprenant 30 un calculateur comprenant des moyens pour mettre en oeuvre chacune des étapes du procédé décrit précédemment. Les avantages procurés par ce programme d'ordinateur et ce système sont similaires à ceux évoqués précédemment. 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 d'un procédé 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 de génération de graphes d'événements redoutés selon des similarités ; 20 - la figure 6, comprenant les figures 6a et 6b, illustre un exemple de génération de graphe d'événements redoutés à partir d'un sous-graphe générique d'événements redoutés ; - la figure 7 illustre un exemple d'algorithme d'aide au diagnostic d'un système d'aéronef à partir de notifications reçues de 25 systèmes de surveillance et d'un graphe d'événements redoutés ; - la figure 8, comprenant les figures 8a et 8b, illustre certaines étapes de l'algorithme décrit en référence à la figure 7 ; - la figure 9 illustre un exemple d'algorithme d'analyse de tolérance aux pannes ; 30 - la figure 10 illustre un exemple de sous-graphe d'événements redoutés obtenu à partir du graphe d'événements redoutés présenté sur la figure 4 lorsque le message ECAM EM1 est sélectionné comme détection, que l'objet accusable S1 est un objet accusable suspecté à l'issu d'une étape d'identification de pannes et que le message MM1 a été notifié ; - la figure 11 illustre un exemple d'algorithme pour ordonnancer des suspects et des troubles les plus probables, à partir de vertex minimaux préalablement calculés, afin de faciliter des opérations de diagnostic préventif ; - la figure 12 illustre un exemple de graphe d'événements redoutés sur lequel est représentée une relation de couverture entre deux troubles ; - les figures 13 et 14 illustrent deux modes de réalisation de l'invention ; et, - la figure 15 illustre un exemple d'architecture matérielle adaptée à mettre en oeuvre certaines étapes de l'invention.
De façon générale, l'invention vise un système de diagnostic préventif et d'analyse de la tolérance aux pannes pour un système d'aéronef, utilisant des graphes d'événements redoutés (ou failure condition graph en terminologie anglo-saxonne), construits ici à partir d'arbres de pannes (appelés fault tree en terminologie anglo-saxonne) développés lors d'études de sécurité.
Comme illustré sur la figure 1, le procédé général d'établissement d'un rapport de diagnostic est ici décomposé en plusieurs 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. Dans une quatrième phase (phase 115), un algorithme d'identification de pannes est exécuté par une machine 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é. 2 9 894 9 9 10 Après avoir identifié des pannes, plusieurs étapes et/ou séquences d'étapes sont effectuées de façon indépendante pour sélectionner une procédure de résolution de pannes optimale pour chaque équipement potentiellement défaillant et dont la défaillance pourrait conduire à la 5 configuration actuelle du système (phase 120), analyser la tolérance aux pannes du système dans sa configuration actuelle (phase 125) et établir un diagnostic préventif de celui-ci (phase 130). Les résultats obtenus au cours de ces étapes permettent l'établissement d'un rapport de diagnostic (phase 135). Comme illustré par la flèche en trait pointillé, les dernières phases 10 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. 15 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é. Il a ici les caractéristiques suivantes: - le graphe est orienté, il peut comporter des cycles ; - le graphe comporte au moins trois types de sommets : 20 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 25 é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). Un attribut particulier est avantageusement renseigné pour 30 classer chaque sommet « objet accusable » suivant deux groupes, les objets accusables persistants et les objets accusables non persistants. Les objets accusables persistants sont tels qu'une fois en panne, leur panne est irréversible sans action de maintenance. Les objets accusables non persistants sont tous les autres ; o événements redoutés, appelés faiture 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 ê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é 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 20 l'ensemble des unités ou modules remplaçables (LRU et LRM, sigle de Line Replaceable Module en terminologie anglo-saxonne) considérés dans les manuels de maintenance connus sous les noms de TSM et AMM ; et, - 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 25 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. 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 30 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 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 Si (245), ici une application logicielle, est susceptible de déclencher l'événement redouté E2 (210). De même, une anomalie dans l'équipement Li (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é El (205) conformément à la porte logique OU (230) reliant les événements redoutés E2 et E3 à l'événement redouté El. 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, typiquement 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é, des membres d'équipage ou des opérateurs.
Les événements détectés sont, par exemple, notifiés par des messages émis par les systèmes de surveillance correspondants. Ils peuvent également résulter d'observations humaines notifiées. 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), une alerte du système d'alerte FWS (sigle de Flight Warning System en terminologie anglo-saxonne) ou des entrées du pilote dans le carnet de vol électronique (appelé Electronic Logbook 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é El (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é El (205). De même, un message de maintenance MM/ (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 15 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 20 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 25 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-In-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 30 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 MM/ (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 ou panne (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. Ces phases de modélisation de graphes d'événements redoutés et d'attribution de codes de messages de pannes (phases 100 et 105 de la figure 1) peuvent être améliorées pour simplifier la création et la gestion des graphes en utilisant des motifs de graphes (aussi appelés graph patterns en terminologie anglo-saxonne) et des tables d'instanciation. Un motif de graphe est ici un graphe générique dont les sommets représentant des événements redoutés et des objets accusables désignent des 30 événements et des objets génériques qui peuvent prendre autant de valeurs qu'il y a de similarités dans le système considéré.
A titre d'illustration, un aéronef dispose généralement de deux trains d'atterrissage ventraux symétriques et similaires. Il serait redondant de faire l'analyse et la modélisation de ces deux trains car les graphes d'événements redoutés obtenus auraient la même forme, seuls les noms des sommets seraient différents, le premier graphe faisant référence à des éléments du train d'atterrissage gauche et le deuxième à des éléments du train d'atterrissage droit. De même, pour l'attribution des codes de messages, si les techniques de surveillance du train gauche sont similaires à celles du train droit, il est inutile de refaire deux fois l'analyse.
Ainsi, les étapes 100 et 105 de la figure 1 peuvent être complétées par les étapes 500 à 515, comme représenté sur la figure 5 qui illustre un exemple d'algorithme de génération de graphes. Une première étape a pour objet d'identifier toutes les similarités du système à modéliser (étape 500), c'est-à-dire tous les groupes de sous- ensembles de ce système ayant des structures similaires. Elle peut être effectuée automatiquement par analyse du système selon des critères prédéterminés ou par un opérateur. Dans une étape suivante (étape 140), un graphe générique des événements redoutés est modélisé et des codes de messages de pannes lui sont attribués, comme décrit en référence aux étapes 100 et 105 de la figure 1. Comme représenté par la flèche en trait pointillé, cette étape de modélisation de graphes d'attribution de codes est effectuée pour chaque similarité identifiée, c'est-à-dire pour chaque groupe de sous-ensembles ayant des structures similaires.
Les graphes génériques ainsi modélisés sont alors analysés (étape 505) pour identifier, pour chaque sommet générique, le ou les paramètres qui, dans le nom du sommet considéré, changent d'une similarité à l'autre. Ainsi, par exemple, en considérant qu'un sommet d'un graphe générique ait le nom « Perte du signal de verrouillage automatique de porte envoyé par le calculateur de la porte Ix]» et qu'il y ait dix portes similaires dans l'aéronef, nommées P1 à P10, le paramètre dans le nom de ce sommet est /X], il prend les valeurs d'instanciations P1 à Plo.
Ensuite, pour chaque graphe générique, une table des instances de paramètres est créée selon les valeurs des paramètres du graphe dans les sous-ensembles correspondant (étape 510). Une telle table comprend par exemple les noms des paramètres génériques dans le graphe considéré et, 5 pour chaque sous-ensemble du groupe considéré, la valeur des paramètres. Une table des instances de paramètres est donnée en annexe à titre d'illustration (table 1). Chaque ligne représente ici un paramètre d'un modèle générique donné. La première colonne contient le nom du paramètre et les colonnes suivantes contiennent les valeurs possibles de ce paramètre pour 10 chaque instanciation, c'est-à-dire pour chaque sous-ensemble représenté par le graphe générique. A titre d'illustration, la table des instances de paramètres comprend ici les paramètres #Paraml#, #Param2#, #Param3# et #Objet accusable génériquel#, chacun pouvant être instancié selon trois valeurs. Cette table dérive du motif de graphe représenté sur la figure 6a et 15 d'une description du système à modéliser (non représentée). De retour à la figure 5, les graphes génériques sont ensuite instanciés selon toutes les instanciations possibles pour générer les graphes d'événements redoutés correspondants (étape 515). A titre d'illustration, il est considéré ici le graphe générique illustré sur 20 la figure 6a obtenu à partir d'un système à modéliser comme décrit en référence à la figure 5 ainsi que la table des instances de paramètres également obtenue à partir de ce système par analyse du graphe générique illustré sur la figure 6a. Comme dans les figures 2, 3 et 4, les cercles représentent les 25 sommets du graphe d'événements redoutés tandis que les flèches représentent les arcs du graphe. Les cercles 605 et 615, en trait continu, représentent des sommets de type événements redoutés, le cercle 610, en trait pointillé, représente un sommet de type portes logiques et le cercle 600, en trait pointillé de longueur variable, représente un sommet de type objets accusables. 30 Le losange 620 correspond à un message de maintenance de type ECAM ayant pour objet d'avertir la réalisation d'un événement redouté.
Une anomalie dans l'équipement générique représenté par la référence 600 est susceptible de déclencher l'événement redouté générique représenté par la référence 605 qui lui-même est susceptible de déclencher l'événement redouté générique représenté par la référence 615 ce dernier pouvant être déclenché par une autre cause. La réalisation de l'événement redouté générique représenté par la référence 615 déclenche le message de maintenance générique représenté par la référence 620. Les paramètres génériques visés dans le graphe générique illustré sur la figure 6a sont définis dans la table 1 de l'annexe. Comme décrit 10 précédemment, cette dernière comprend ici quatre colonnes dont une contient les noms des paramètres, chaque paramètre pouvant comprendre trois valeurs. A titre d'illustration, le paramètre #Param3# peut prendre les valeurs E11, E12 et E13, selon la première, seconde et troisième instanciation, respectivement. Toujours à titre d'illustration, la première instanciation vise les valeurs EM1, 15 E10, E11 et LRU L1 pour les paramètres #Param1#, #Param2#, #Param3# et #Objet accusable génériquel#, respectivement. L'instanciation du graphe générique représenté sur la figure 6a avec les valeurs d'instanciation définies dans la table 1 de l'annexe permet de générer le graphe d'événements redoutés représenté sur la figure 6b. 20 En raison des valeurs définies dans la table des instances de paramètres, le graphe d'événements redoutés comprend trois branches spécifiques propres à chaque instance (références 600'4 et 605'-i où i représente le numéro d'instanciation variant de 1 à 3) et une branche commune (références 610', 615' et 620'). 25 Les avantages procurés par les étapes décrites en référence à la figure 5 comparativement à celles décrites en référence à la figure 1, considérées isolément, sont notamment les suivants : - réduction de la charge de travail d'analyse et d'édition du graphe d'événements redoutés d'un facteur lié au nombre de similarités présentes 30 dans le système à modéliser. Ainsi, par exemple, en considérant un aéronef de type A380 (A380 est une marque), comprenant cinq portes de pont principal similaires, le travail de modélisation est divisé par un facteur de l'ordre de cinq pour générer le graphe d'événements redoutés du sous-système de gestion des portes ; - validation facilitée des graphes d'événements redoutés liée au fait que les instances possibles sont représentées sous forme de tables donnant 5 l'opportunité de valider la cohérence des données colonne par colonne ; - amélioration de l'homogénéité et de la qualité du graphe d'événements redoutés final du fait que seuls les paramètres variables changent. En outre, un tel algorithme permet d'appliquer des règles de nommage des sommets des graphes d'événements redoutés, réduisant les 10 erreurs possibles et simplifiant leur lecture ; et - possibilités de stockage des motifs de graphes génériques dans des bases de connaissances métiers pouvant être utilisées pour modéliser différents types d'aéronefs similaires. Cette approche permet un transfert de connaissances entre modèles d'aéronefs et une non régression (les leçons 15 apprises sur des motifs de graphes d'aéronefs de générations antérieures sont acquises pour des aéronefs de nouvelles générations). De retour à la figure 1, lorsque le graphe d'événements redoutés a été établi et que des relations entre les messages liés à des événements détectés dans des systèmes de surveillance et des sommets du graphe 20 d'événements redoutés de type événements redoutés ont été établies, les messages liés à des événements détectés dans des systèmes de surveillance peuvent être obtenus (phase 110), 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 25 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). Cette phase d'obtention de messages et d'informations a également pour objet de déterminer une liste minimale de paramètres utilisés dans les 30 expressions logiques mises en oeuvre dans le graphe d'événements redoutés, notamment de paramètres ACMS, pour permettre d'effectuer des opérations de diagnostic données et d'accéder aux valeurs de ces paramètres pour permettre d'évaluer ces expressions logiques. Une phase suivante (phase 115) consiste notamment à utiliser le graphe d'événements redoutés (connaissance statique et a priori), des valeurs de paramètres identifiés 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 7 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 700), le ou les sommets Ni de type notification correspondants sont identifiés (étape 705), 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 710), 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, O est un sous-ensemble },EJ de N, tel que pour tout élément E' inclus dans Ni et tout élément Ej inclus dans O, soit E' n'implique pas Ej E1)), soit l'intervalle d'occurrence de Ej n'est pas IE E. inclus dans l'intervalle d'occurrence de E' ( and ). E, # I L, Dans une étape suivante (étape 715), 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 Ab(-) 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 8a, - l'événement redouté El est expliqué par l'expression logique : Ab(AccObj5) OU Ab(AccObj7) - l'événement redouté E2 est expliqué par l'expression logique : Ab(AccObj7) OU Ab(AccObji) - l'événement redouté E3 est expliqué par l'expression logique : Ab(AccObji) OU Ab(AccObi4) Dans une étape suivante (étape 720), les événements redoutés sources sont regroupés de la façon suivante : deux événements redoutés Ei 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 8a, les 5 événements El, E2 et E3 (considérés comme des événements redoutés sources) sont regroupés dans un même ensemble P1 = E2, E3} car les expressions logiques expliquant les événements redoutés sources El 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 10 opérande Ab(AccObji). Ainsi, deux groupes P1 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 Pi et celui des objets accusables suspectés par Pk, ces ensembles sont disjoints. 15 Chaque groupe Pk traduit la présence d'un trouble Fk dont le diagnostic sera formulé à partir des objets accusables qui peuvent être déduits du groupe. Pour un groupe Pk, le trouble Fk est le sous-ensemble d'événements redoutés tel que : - le groupe Fk est inclus dans le groupe Pk ou est égal au groupe Pk; 20 - le groupe Fk est de cardinalité minimale ; et - tout élément de Pk\Fk possède au moins un ancêtre dans le groupe Fk. Ainsi, par exemple, si le groupe Pk est égal à {E1, E2, E3}, en utilisant le graphe illustré sur la figure 2, le trouble Fk est égal {E2, E3} car selon 25 le graphe représenté sur la figure 2, E2 et E3 sont des ancêtres de E1. Dans une étape suivante (étape 725), les vertex minimaux (minimal hitting sets) d'objets accusables couvrant chaque événement redouté source Ei de chaque ensemble Pk sont calculés. Un vertex de l'ensemble Pi d'objets accusables couvrant un 30 é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 {V,,}, un vertex Vm E {V,,} est dit minimal s'il n'existe pas d'autre vertex de {Vn} qui puisse être déduit logiquement de Vm. Ainsi, par exemple, le vertex Ab(Actionneur) se déduit du vertex 10 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 Fk lié à un groupe Pk. En d'autres termes, les vertex minimaux 15 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 8a et illustré sur la figure 8b, les vertex minimaux Vr sont, pour le groupe /3; = {E,,E2,E3}, les expressions logiques d'objets accusables suivantes, 20 V/ : Ab(AccObji) ET Ab(AccObj7) V2 : Ab(AccObji) ET Ab(AccObj5) V3 : Ab(AccObj4) ET Ab(AccObj7) A titre d'illustration, le vertex V4 (Ab(AccObji) ET Ab(AccObj7) ET Ab(AccObj4)) n'est pas un vertex minimal du groupe P1 car il s'en déduit le 25 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. 30 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 5 d'événements redoutés. De par 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. 10 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 15 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. 20 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 25 é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. De retour à la figure 1, les vertex minimaux identifiés au cours de la 30 phase 115 peuvent notamment être utilisés pour sélectionner des procédures de résolution de pannes (trouble-shooting).
Ainsi, l'étape référencée 120 sur la figure 1 a pour objet la sélection d'une procédure de trouble-shooting optimale, pour chaque vertex minimal calculé précédemment, dans un manuel de trouble-shooting (souvent appelé TSM, sigle de Trouble-Shooting Manual en terminologie anglo-saxonne, ou FIM, acronyme de Fault Isolation Manual en terminologie anglo-saxonne). Chaque procédure du manuel de trouble-shooting teste un ensemble d'objets accusables (le nombre d'objets accusables testés par une procédure donnée est appelé périmètre de procédure). Cette étape peut être décomposée en deux. parties.
Au cours d'une première partie de cette étape, les références des procédures ayant pour objet de tester tous les objets accusables de chaque vertex minimal précédemment calculé, dont le périmètre de procédure est minimal, sont recherchées dans le manuel de trouble-shooting. Cet ensemble de procédure forme, pour chaque vertex minimal, une liste optimale des procédures de trouble-shooting. Une seconde partie vise à identifier les procédures qui sont communes à plusieurs vertex. Les informations ainsi obtenues, liées à aux procédures de trouble- shooting, sont avantageusement associées au rapport de diagnostic pour permettre un test de panne optimal et efficace. Il est observé ici que la recherche de procédures dans le manuel de de trouble-shooting comme décrit ci-dessus peut être améliorée en assignant des priorités aux procédures, par exemple selon leur temps d'exécution, de la plus rapide à exécuter à la plus longue, ou selon leur mise en oeuvre en favorisant celles ne nécessitant aucun outil à celles nécessitant des outils spécifiques au sol (appelés GSE, sigle de Ground Specific Equipment en terminologie anglo-saxonne). A titre d'illustration, il est admis ici que le trouble F1 dont le groupe P1 traduit la présence est diagnostiqué par les vertex minimaux VI = {L1, L2} ou V2 = {L3} et que le trouble F2 dont le groupe P2 traduit la présence est diagnostiqué par le vertex minimal V3 = {L1, L4}. Il est également admis que le manuel de trouble-shooting comporte les procédures suivantes : TSMI : procédure ayant pour objet le test des LRU Ll, L2 et L4 TSM2 : procédure ayant pour objet le test des LRU L1 et L3 TSM3: procédure ayant pour objet le test du LRU L3 TSM4 : procédure ayant pour objet le test du LRU L3 Par conséquent, le résultat obtenu à l'issu de l'étape 120 de sélection de procédures est le suivant - pour le trouble Fi dont le groupe P1 traduit la présence, - le vertex minimal Vi est traité de manière optimale par la procédure TSM1 ; et - le vertex minimal V2 est traité de manière optimale par la procédure TSM3 ou la procédure TSM4 ; - pour le trouble F2 dont le groupe P2 traduit la présence, - le vertex minimal V3 est traité de manière optimale par la procédure TSM1 La procédure TSM1 est donc commune à la résolution des troubles Fi et F2 dont les groupes Pi et P2 traduisent la présence. Cette procédure est donc favorisée par rapport aux autres. Les avantages procurés par une telle étape de sélection des procédures de résolution de pannes sont notamment les suivantes : - sélection dynamique des procédures de trouble-shooting permettant une adaptation optimale à une combinaison de pannes présentes dans le système (les solutions actuelles ne permettent généralement pas l'obtention d'un tel résultat, ce sont les opérateurs de maintenance qui doivent traiter un à un les objets accusés, sans être certain formellement d'employer systématiquement la procédure la plus directe) ; - identification dynamique des procédures communes à la résolution de plusieurs troubles permettant la résolution de plusieurs troubles en appliquant un minimum de procédure. Ainsi, le nombre de fiches de tâches (ou job cards en terminologie anglo-saxonne) peut être optimisé par un centre de contrôle de maintenance de la compagnie exploitant l'aéronef considéré lors d'une préparation d'actions de maintenance ; - indépendance de la structure du manuel de trouble-shooting vis-à-vis de l'algorithme de sélection de procédures de résolution de pannes. En d'autres termes, la documentation TSM est indépendante du système de diagnostic. Néanmoins, les références des procédures TSM pourraient être cartographiées dans le graphe d'événements redoutés, comme sont cartographiés les moyens de détection, à des fins d'optimisation. De retour à la figure 1, les vertex minimaux identifiés au cours de la phase 115 peuvent également être utilisés pour effectuer une analyse de tolérance aux pannes et identifier des événements redoutés de haut niveau qui sont imminents. La figure 9 illustre un tel algorithme d'analyse de tolérance aux pannes. Une première étape (étape 900) a pour objet d'établir une liste de détections de notifications de pannes du graphe d'événements redoutés pour lesquelles une analyse de tolérance aux pannes doit être réalisée. En d'autres termes, l'étape 900 vise à sélectionner des notifications de pannes susceptibles d'être détectées et exploitées dans le graphe d'événements redoutés, pour lesquelles une analyse de tolérance aux pannes doit être réalisée. Une telle liste de détections sélectionnées peut être prédéterminée, établie par un opérateur ou établie de façon automatique selon des critères donnés. Des attributs sont avantageusement associés à chaque détection sélectionnée. De tels attributs comprennent, par exemple, les attributs suivants : - une référence à une famille associée à la détection, selon une 25 classification prédéterminée, pouvant notamment comprendre des éléments tels que effet aéronef, effet maintenance et effet exploitation ; et - une importance de l'impact opérationnel qui lui est lié, suivant une échelle prédéterminée, pouvant notamment comprendre trois niveaux (faible, moyen et élevé). 30 Ces attributs ne sont pas nécessairement utilisés lors des calculs de tolérance aux pannes mais sont utiles pour l'aide à la décision de lancer ou non une action de maintenance préventive.
A titre d'illustration, le message ECAM EM1 de la figure 4 peut être sélectionné lors de l'étape 900 et classé dans la famille effet aéronef avec un impact opérationnel élevé. Dans une étape suivante (étape 905), la détermination de la 5 tolérance aux pannes est effectuée. Elle vise notamment à déterminer, pour chacune des détections sélectionnées, si la tolérance aux pannes la concernant est entamée ou non et à identifier les chemins du graphe d'événements redoutés qui peuvent mener à la détection sélectionnée correspondante en partant des objets accusables suspectés par le diagnostic réalisé 10 précédemment (étape 115 de la figure 1). Cette analyse permet notamment d'identifier des objets accusables du graphe d'événements redoutés dont une défaillance aurait un effet immédiat vis-à-vis des détections sélectionnées. Il est observé que les détections sélectionnées au cours de l'étape 900 se situent en général dans le haut du graphe d'événements redoutés car 15 elles se réfèrent à des événements redoutés de haut niveau. A titre d'illustration, une telle détection peut être relative à un message ECAM qui rapporte une perte de fonction de l'aéronef au pilote qui doit appliquer une procédure de pilotage adaptée en conséquence (les procédures du FCOM, acronyme de Flight Crew Operating Manual en terminologie anglo-saxonne). 20 L'étape 905 vise ainsi à identifier la liste des détections préalablement sélectionnées qui sont telles qu'au moins un objet accusable est suspecté sur au moins une branche du graphe menant à cette détection. Seules ces détections sont avantageusement étudiées par la suite car ce sont les seules qui sont impactées par les pannes suspectées dans l'aéronef. En 25 fait, la distance qui les sépare d'une indisponibilité totale est réduite du fait des pannes. Il convient de noter ici que dans certaines circonstances, par exemple selon les phases de vol, des messages d'alerte ne sont pas affichés immédiatement pour ne pas perturber le pilote. Par conséquent, il peut exister 30 des pannes qui n'ont pas été indiquées au pilote. Il peut donc être utile de savoir préventivement qu'une alerte est imminente.
Comme représenté sur la figure 9, l'étape de détermination de la tolérance aux pannes peut être décomposée en plusieurs étapes 910 à 930. Le diagnostic réalisé au cours de l'étape 115 de la figure 1 permet d'identifier, le cas échéant, plusieurs groupes Pi traduisant la présence de troubles F. Chacun de ces groupes est diagnostiqué par des ensembles de vertex minimaux d'objets accusables E, pouvant être considérés comme des ensembles de suspects. Au cours de l'étape 910, des sous-graphes sont extraits du graphe d'événements redoutés précédemment établi (étape 100 de la figure 1). Plus précisément, pour chaque objet accusable suspecté de chaque ensemble de suspects E; de chaque groupe P; traduisant la présence d'un trouble Fi, le sous-graphe engendré par cet objet accusable et tous les arcs et sommets qui lui sont subséquents sont extraits du graphe d'événements redoutés. L'ensemble des sous-graphes ainsi générés est appelé SG ci-après.
Dans une étape suivante (étape 915), les détections de notifications d'événements de l'ensemble SG appartenant à la liste des détections sélectionnées établie à l'étape 900 sont identifiées. Cette étape permet d'obtenir une liste de détections sélectionnées (pour lesquelles une analyse de tolérance aux pannes doit être réalisée) qui peuvent être notifiées dans un futur proche du fait de leur lien avec des objets accusables suspects (du fait que ces détections appartiennent à l'ensemble SG). Cette liste de détections est appelée ci-après la liste d'effets imminents. Les vertex minimaux d'objets accusables sont ensuite calculés pour chaque détection I, de la liste d'effets imminents (étape 920). A ces fins, il est possible d'utiliser la méthode décrite précédemment en référence à la figure 7. Cette étape permet ainsi d'obtenir un ensemble V1 d'ensembles d'objets accusables pour chaque détection de la liste d'effets imminents pouvant s'exprimer sous la forme suivante : -> = {v1= {AccObj v {AccObjm}m, ...} - 2 = où {AccObjn}n représente un ensemble d'objet accusable (AccObj) défini par l'ensemble des valeurs (non nécessairement continues) de l'index n.
Une sélection des objets accusables de l'ensemble V, (ensemble des vertex minimaux) est ensuite opérée (étape 925), pour chaque détection de la liste d'effets imminents, pour ne retenir que les vertex (ensembles d'objets accusables) qui comprennent au moins un objet accusable suspecté par le diagnostic réalisé précédemment (au cours de l'étape 115 de la figure 1). Ces vertex représentent des diagnostics préventifs. Ainsi, pour chaque détection de la liste d'effets imminents, un sous-ensemble Wi de l'ensemble est obtenu : c V, IN; = {vv, = {AccObj0}0, w2 = { AccObjp}p, - -} Chacun des vertex wi contient donc au moins un objet accusable suspecté. Il est observé ici que, de façon alternative, la sélection des vertex qui comprennent au moins un objet accusable suspecté par le diagnostic réalisé précédemment peut être effectuée au sein des vertex minimaux de faibles longueurs, c'est-à-dire contenant un nombre limité d'objets accusables (et non parmi tous les vertex minimaux). La longueur maximale des vertex minimaux à prendre en compte peut être prédéterminée. Au cours d'une étape suivante, une distante restante avant effet 20 imminent est calculée pour chacun des vertex wi (étape 930). Une distance restante avant effet imminent est calculée comme étant égale au nombre d'objets accusables présents dans le vertex considéré et non suspectés au cours de l'étape 115 de la figure 1. Ainsi, la distance du vertex wi peut être définie de la façon suivante : 25 of; --> d,= Card {AccObj» tel que AccObh E IN; et AccObji n'est pas un objet accusable suspecté Les données ainsi obtenues sont utilisées pour former un rapport de tolérance aux pannes (étape 935). Plus précisément, le rapport de tolérance aux pannes peut notamment comprendre la liste des détections /, de la liste 30 d'effets imminents avec leurs attributs (par exemple la famille et une importante d'impact opérationnel), les diagnostics préventifs la concernant et la distance restante avant effet imminent pour chacun de ces diagnostics.
La figure 10 illustre un exemple de sous-graphe 1000 obtenu à partir du graphe d'événements redoutés présenté sur la figure 4 lorsque le message ECAM EM1 est sélectionné comme détection (étape 900 de la figure 9), que l'objet accusable S1 est un objet accusable suspecté à l'issu de l'identification des pannes (étape 115 de la figure 1) et que le message MM1 a été notifié. L'algorithme décrit en référence à la figure 9 permet de déduire du sous-graphe 1000 que le message EM1 est imminent et qu'une distance restante avant effet imminent égale à un (lié à l'objet accusable L1) lui est associée. La table 2 donnée en annexe représente un exemple de rapport de tolérance aux pannes généré par l'algorithme décrit en référence à la figure 9 au vu du sous-graphe 1000. L'élaboration de rapports de tolérance aux pannes à l'aide de l'algorithme décrit en référence à la figure 9 offre de nombreux avantages parmi lesquels : - l'utilisation de la connaissance physique exhaustive de la propagation des pannes dans le système, ne dépendant pas de statistiques ; - l'indication des objets accusables non encore déclarés en panne mais dont une défaillance conduirait à un événement redouté. Cette information est très importante pour la prise de décision. En effet, une telle information permet d'éviter de laisser partir un aéronef si la marge de tolérance n'est due, par exemple, qu'à la survie d'un LRU très cher à acheminer sur le lieu de destination de l'aéronef. Dans ce cas, le risque d'une longue immobilisation de l'aéronef, en attentant un LRU de rechange, est grand. En revanche, si la marge de tolérance est entamée mais que la logistique et la maintenance des pièces de rechange ne posent pas de problème en termes de coûts et d'opération, il est moins risqué de laisser partir l'aéronef. De retour à la figure 1, les vertex minimaux identifiés au cours de la phase 115 peuvent également être utilisés pour ordonnancer des suspects et/ou des troubles les plus probables afin de faciliter des opérations de diagnostic préventif (phase 130). Un tel ordonnancement peut notamment être basé sur un historique de diagnostic La figure 11 illustre un exemple d'algorithme pour ordonnancer des suspects et des troubles les plus probables, à partir de vertex minimaux préalablement calculés, afin de faciliter des opérations de diagnostic préventif. Comme illustré, une première étape (étape 1100) a pour objet 5 d'accéder à un historique de diagnostic, typiquement un historique de diagnostic des n vols précédents, par exemple des quatre vols précédents (n = 4) ou des quinze vols précédents (n = 15). Des listes d'objets accusables appartenant aux ensembles des objets accusables suspects préalablement identifiés (ensemble Ei) sont ensuite 10 établies (étape 1105). Selon un mode de réalisation particulier, plusieurs listes objets accusables suspects sont établies en fonction de la cardinalité des ensembles des objets accusables suspects E.1. Plus précisément, une liste LSrs est construite pour chaque cardinalité r des ensembles Ei (r variant de 1 à p) et 15 chaque précédent vol s (s variant de 1 à n). La valeur maximale p des cardinalités de tous les ensembles E1 à prendre en compte est de préférence prédéterminée, par exemple p = 4. En d'autres termes, p ensembles {LS,-,Jr=/..p sont définis pour chaque vol s. Au cours d'une étape suivante (étape 1110), des poids de 20 persistance de diagnostic sont calculés, pour chacun des vols de l'historique, pour chaque objet accusable suspecté dans le vol courant. Selon un mode de réalisation particulier, les poids de persistance de diagnostic sont calculés de la façon suivante : - seuls les poids de persistance de diagnostic des objets 25 accusables suspectés dans le vol courant sont calculés. Les objets accusables suspectés dans les vols précédents mais non dans le vol courant sont ignorés lors de ce calcul ; - si un objet accusable ObjAcc est suspecté dans un vol s son poids de persistance de diagnostic est nul (PobjAcc,s = 0), pour ce vol, s'il n'est plus 30 suspecté dans le vol suivant (s - 1) ; et - si un objet accusable est suspecté dans un vol s et qu'il l'est toujours dans le vol suivant (s - 1), son poids de persistance de diagnostic PObjAcc,s, pour ce vol (s), est défini comme étant le poids de persistance de diagnostic de cet objet accusable PObjAcc,s-1 au vol suivant (s - 1) incrémenté d'une valeur liée à l'ancienneté du vol (s) et à la cardinalité (r) de l'ensemble LS,,, auquel appartient l'objet accusable ou de zéro si l'objet accusable suspecté n'appartient à aucun ensemble LSr,s. Le poids de persistance de diagnostic de cet objet accusable au vol suivant (s) peut alors être définit par la relation suivante, PObjAcc,s = PObjAcc,s-1± PObjAcc,s-1 où f(s) est une fonction croissante de s permettant d'atténuer le poids des vols anciens afin de limiter l'influence d'un diagnostic ancien pour lequel des opérations de maintenance ont pu être effectuées. A titre d'illustration, la fonction f(s) peut être définie de la façon suivante : f(s) = s La table 3 en annexe donne un exemple de liste d'objets accusables suspects et de poids de persistance de diagnostic associés. Chaque ligne représente ici un vol identifié par la valeur de l'index donnée dans la première colonne. La seconde colonne indique le ou les troubles identifiés au cours du vol correspondant. Par exemple, le trouble FE,4 a été identifié au cours du vol en cour (vol s = 1). La troisième colonne donne les vertex minimaux obtenus en réponse à l'étape 115 de la figure 1 pour le vol correspondant. Ainsi, par exemple, à l'issu du vol s = 2, c'est-à-dire du vol précédent le vol en cours, les vertex minimaux étaient {S1}, {L2, L3} et {L4}. La quatrième colonne de la table indique la ou les cardinalités des vertex minimaux et la cinquième colonne présente le contenu des listes LSr,s construites à partir des vertex minimaux selon leur cardinalité. La sixième colonne comprend, pour chaque vol, la liste des objets accusables suspectés dans le vol en cours et la septième colonne indique les poids de persistance de diagnostic associés à ces objets accusables selon le calcul décrit précédemment. A titre d'illustration, le poids de persistance de diagnostic associé à l'objet accusable S1, pour le vol s = 3, est calculé de la -façon suivante : 1 si ObjAcc E LSrs X f(s) si ObjAcc e LS,,s 1 PS1,3 = P51,3-1 + 1 x 3 = 1,5 + 0,33 = 1,83 où i = 1, f(s) = s = 3. Dans une étape suivante (étape 1115), des poids de persistance historique de diagnostic sont calculés pour chaque objet accusable suspecté dans le vol courant. Le poids de persistance historique de diagnostic d'un objet accusable suspecté, appelé PHobiAcc est la valeur maximale de poids de persistance obtenu par cet objet accusable sur l'ensemble des vols. Un tel poids peut être défini par la relation suivante : ( PHobjAcc = maxs JjObjAcc,S) A titre d'illustration et en reprenant l'exemple donné en référence à la table 3 de l'annexe, l'objet accusable Si a un poids de persistance historique égal à 2,08 qui représente la valeur maximale du poids de persistance de diagnostic de cet objet qui évolue de 1 à 1,5 à 1,83 à 2,08 pour les vols s = 1, 2, 3 et 4, respectivement. De façon similaire, l'objet accusable L2 a un poids de persistance historique égal à 1,58 et l'objet accusable L5 a un poids de persistance historique égal à 1.
Dans une étape suivante (étape 1120), les poids de persistance historique sont utilisés pour ordonner les vertex minimaux dans le diagnostic d'un même trouble, du plus pertinent au moins pertinent. A ces fins, des règles peuvent être utilisées, notamment les règles suivantes : - lorsque deux vertex minimaux ont des cardinalités différentes, il est 20 considéré que c'est le vertex de cardinalité la plus petite qui est le plus pertinent ; - lorsque deux vertex minimaux ont des cardinalités égales, il est considéré que le vertex le plus pertinent est celui dont la somme des poids de persistance historique des objets accusables qui le composent est la plus 25 grande ; et - lorsque deux vertex minimaux ont des cardinalités égales et que les sommes des poids de persistance historique des objets accusables qui les composent sont égales, des caractéristiques des objets accusables telles que leur type et leur nature (matériel, logiciel, câblage,_ mode d'inhibition, ...) 30 peuvent être utilisées pour comparer les vertex minimaux. Ainsi, à titre d'illustration, il est considéré que des objets accusables matériels sont plus pertinents que des objets accusables logiciels qui sont eux-mêmes plus pertinents que des objets accusables de type câblages. Enfin, si l'égalité persiste, d'autres critères tels que l'ordre alphabétique peuvent être utilisés.
Une telle étape permet d'obtenir un diagnostic classé par pertinence. A titre d'illustration et en reprenant l'exemple donné en référence à la table 3 de l'annexe, trois vertex minimaux ({S1}, {L5}, {L2}) ont été identifié pour le vol courant. Ces trois vertex minimaux sont de même cardinalité (1). Cependant, en utilisant la somme des poids de persistance historique de 10 chaque objet accusable de chaque vertex minimal (2,08, 1,58 et 1, respectivement), il est possible de les classer : {Si}, {L2}, {L5}. Les poids de persistances historiques peuvent également être utilisés pour prioriser les objets accusables suspectés de manière absolue, par exemple en utilisant les règles suivantes : 15 - pour deux objets accusables donnés, c'est l'objet accusable impliqué dans un vertex minimal de cardinalité la plus petite et avec le poids de persistance historique le plus grand qui est le plus prioritaire ; - pour deux objets accusables impliqués dans des vertex de même cardinalité, c'est l'objet accusable impliqué dans le vertex le plus pertinent qui 20 est le plus prioritaire ; - pour deux objets accusables impliqués dans des vertex de même cardinalité ayant la même pertinence, des caractéristiques des objets accusables telles que leur type et leur nature (matériel, logiciel, câblage, mode d'inhibition, ...) peuvent être utilisées pour comparer ces objets accusables. 25 Ainsi, à titre d'illustration, il est considéré que des objets accusables matériels sont plus pertinents que des objets accusables logiciels qui sont eux-mêmes plus pertinents que des objets accusables de type câblages. Enfin, si l'égalité persiste, d'autres critères tels que l'ordre alphabétique peuvent être utilisés. A titre d'illustration, il est admis qu'un diagnostic courant comprenne 30 les vertex minimaux suivants, {L1, L2} ou {L3} ou {L4, L5} impliquant les objets accusables suivants dont les poids de pertinence historique ont été calculés et sont indiqués entre parenthèses : L1 (3), L2 (2), L3 (1), L4 (1), L5 (2) L'utilisation des règles données précédemment permet, à partir des cardinalités des vertex minimaux et des poids de pertinence historique, de prioriser les objets accusables dans l'ordre suivant : 1. L3 2. L1 3. L2 4. L5 5. L4 Cette priorisation résulte du fait que l'objet accusable L3 est impliqué dans un vertex de cardinalité un alors que tous les autres objets accusables sont impliqués dans des vertex de cardinalité supérieure à un. En outre, dans les vertex de cardinalité deux, le vertex {L1, L2} est plus pertinent que le vertex {L4, L5} du fait de la somme des poids de persistance historique correspondants (les objets accusables L1 et L2 sont donc plus importants que les objets accusables L4 et L5). Enfin, l'objet accusable L1 a un poids de persistance historique plus grand que celui de l'objet accusable L2 et l'objet accusable L5 a un poids de persistance historique plus grand que celui de l'objet accusable L4. L'historique de diagnostic des n vols précédents et le graphe d'événements redoutés peuvent être utilisés pour ordonnancer des troubles dans un diagnostic d'un vol donné.
A ces fins, une première étape (étape 1130) consiste à identifier l'ordre possible des troubles Fi diagnostiqués vol après vol en utilisant une relation d'ordre telle que la suivante : un trouble F, diagnostiqué sur un vol antécédent au vol présent couvre totalement un trouble h diagnostiqué au vol présent si est seulement si tous les vertex minimaux diagnostiquant le trouble F1 sont inclus dans la liste des vertex minimaux diagnostiquant le trouble h ou minimisent ces derniers. A titre d'illustration, il est rappelé que le groupe {A} minimise le groupe {A, B} et que le groupe {A} est inclus dans l'ensemble des groupes {{A}, {C, D}, {E, F}}. Une telle relation est notée Fj. Dans une étape suivante (étape 1135), des poids de persistance des troubles diagnostiqués durant le vol en cours sont calculés. Un tel calcul peut 5 notamment être effectué selon les étapes suivantes : - recherche de la suite de longueur maximale de trouble Fo, F-1, F_k diagnostiqués sur des vols consécutifs tels que Fo est détecté sur le vol en cours, El est détecté sur le vol précédent et ainsi de suite jusqu'au trouble k (diagnostiqué durant kième vol précédent le vol en cours) où k > 0 et 10 F_k F.yk_1).-+ E1--+ Fo - si une telle suite existe, le poids de persistance du trouble Fo est égal à k et, si elle n'existe pas, le poids de persistance du trouble Fo est égal à zéro. Les troubles F1 diagnostiqués durant le vol en cours sont ensuite 15 ordonnés par priorité selon leur poids de persistance, du plus grand au plus petit (étape 1140), de telle sorte qu'un trouble ayant un poids de persistance supérieur à celui d'un autre trouble soit prioritaire sur ce dernier. En cas d'égalité entre deux troubles, la composition de leurs diagnostics respectifs est avantageusement utilisée pour les départager. A ces 20 fins, les rangs des vertex minimaux diagnostiquant chaque trouble sont calculés. Le rang d'un vertex minimal est ici égal au nombre d'objets accusables le composant. A titre d'illustration, le vertex minimal {AccObjA, AccObjB} est de rang deux alors que le vertex minimal {AccObjc, AccObjo, AccObjE} est de rang trois. Les troubles sont alors classés en utilisant les rangs 25 des vertex minimaux de telle sorte qu'un trouble diagnostiqué par des vertex de rang inférieur soit prioritaire sur un trouble diagnostiqué par des vertex de rang supérieur. Ainsi, par exemple, si F1 et F2 sont des troubles ayant un même poids de persistance, le trouble F1, diagnostiqué par les vertex minimaux {AccObjA} et {AccObjB, AccObjc}, est prioritaire par rapport au trouble F2 30 diagnostiqué par le vertex minimal {AccObjo, AccObjE}. En cas d'égalité, les troubles peuvent être départagés en fonction du nombre de vertex minimaux, celui en présentant le moins étant le plus prioritaire.
La figure 12 illustre un exemple de graphe d'événements redoutés sur lequel est représentée une relation de couverture entre deux troubles. Il est admis ici que les messages MM1 et MM2 ont été notifiés au cours du vol précédent et que le message MM3 a été notifié durant le vol en cours. Le trouble F1 est diagnostiqué durant le vol précédent par le vertex minimal {S1}. Le trouble F2 est diagnostiqué durant le vol en cours par les vertex minimaux {S1}, {L1}, {L2}. Le trouble F1 couvre totalement le trouble F2 (F1-+ F2). Le trouble F1 est donc prioritaire sur le trouble F2.
Les étapes décrites en référence à la figure 11 offrent notamment les avantages suivants : - favoriser la maintenance des objets accusables suspectés le plus souvent, ce qui évite de laisser trop longtemps un objet en panne non résolue. C'est particulièrement utile dans le cas de l'exploitation d'un aéronef ne revenant pas à sa base principale après une série de vols et sur lequel des équipes de maintenance différentes travaillent. En effet, dans ce cas, les opérateurs de maintenance ne sont pas les mêmes personnes d'un aéroport à l'autre, ils n'ont qu'un regard ponctuel sur l'aéronef dans un aéroport donné. Les résultats obtenus à l'aide des étapes décrites précédemment permettent de bénéficier de l'historique des diagnostics précédents ; et - faciliter la prise de décision au sol, par exemple par le centre de contrôle de maintenance de la compagnie exploitant l'aéronef car le résultat de diagnostic sera déjà classé en fonction de l'historique, évitant au personnel de ce centre de faire le travail manuellement de vol en vol.
Enfin, revenant à la figure 1, un rapport complet de diagnostic est établi au cours d'une étape 135 durant laquelle les informations de diagnostic et d'évaluation de tolérance à la panne sont agrégées de manière ordonnée, par trouble, du plus prioritaire au moins prioritaire, et, pour chaque trouble, par vertex, du plus pertinent au moins pertinent. Le rapport contient en outre, de préférence, la liste des objets accusables suspectés dans leur ordre absolu de priorité.
Selon un mode de réalisation particulier, le système d'aide au diagnostic est mis en oeuvre 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 5 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 7 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 10 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 et ainsi 15 d'optimiser des opérations d'exploitation et de maintenance. 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 d'exploitation et de diagnostic détaillé à une compagnie aérienne. 20 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). 25 La figure 13 illustre un tel mode de réalisation mis en oeuvre dans un aéronef 1300 comprenant un ensemble de systèmes, génériquement référencés 1305, chacun pourvu d'un système de surveillance de type BITE et un système d'alerte FWS 1310. Les systèmes de surveillance ainsi que le système d'alerte transmettent des messages de notification d'événements 30 détectés à un système de maintenance embarqué 1315. Le système de maintenance embarqué 1315 comprend une base de connaissance 1320 comprenant notamment au moins un graphe d'événements redoutés 1325 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, les algorithmes décrits en référence aux figures 7, 9 et 11. Le résultat d'une telle aide au diagnostic, comprenant notamment un ensemble de vertex minimaux représentant des diagnostics minimaux ainsi que des résultats d'analyse de tolérance aux pannes et des diagnostics préventifs, est mémorisé sous forme de rapport dans une base de données 1330 pour être transmis, via des moyens de communication 1335, 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 1335. 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 oeuvre 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 14 illustre un tel mode de réalisation mis en oeuvre pour des données issues d'un aéronef 1,400 comprenant un ensemble de systèmes, génériquement référencés 1405, chacun pourvu d'un système de surveillance de type BITE et un système d'alerte FWS 1410. 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é 1415. Le système de maintenance embarqué 1415 peut transmettre des messages de notification reçus des systèmes de surveillance 1405 et du système d'alerte 1410, traités ou non, combinés ou non, à un système de traitement de l'information 1420, au sol, via des moyens de communication 1425, par exemple un système ACARS.
Le système de traitement de l'information 1420 comprend une base de connaissance 1430 comprenant notamment au moins un graphe d'événements redoutés 1435 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, les algorithmes décrits en référence aux figures 7, 9 et 11. Un résultat d'une telle aide au diagnostic, comprenant un ensemble de vertex minimaux représentant deS diagnostics minimaux ainsi que des résultats d'analyse de tolérance aux pannes et des diagnostics préventifs, est mémorisé sous forme de rapport dans une base de données 1445. Il peut être consulté via une interface homme-machine 1450 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'utilisati'on 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.
Il est observé ici que le procédé décrit précédemment peut également être utilisé en post-traitement de rapports établit en temps réel, généralement appelés CFR (sigle de Current Flight Report en terminologie anglo-saxonne) envoyés automatiquement par un aéronef alors qu'il est en vol.
Ce procédé permet une aide au diagnostic préventif sur l'aéronef qui permet à des experts au sol de recommander des actions de maintenance préventive afin d'éviter des effets imminents très pénalisant pour son exploitation. A titre d'illustration, ce procédé permet d'alerter d'une inhibition imminente du système de pressurisation de la cabine passagers par la faute d'une ou plusieurs portes dont l'état fermée/claquée/verrouillée (closed & latched & locked en terminologie anglo-saxonne) n'est pas confirmé. Cette inhibition de pressurisation de l'aéronef, si elle n'est pas prévenue, est très problématique pour la compagnie, car elle empêche tout décollage et les pilotes en sont alertés à la porte d'embarquement, alors que tous les passagers sont à bord. En étant informée à l'avance, la compagnie peut programmer les actions de maintenance sur les portes bien avant, et finalement éviter toute inhibition de pressurisation de la cabine. La figure 15 illustre un exemple d'architecture matérielle d'un dispositif 1500 adapté à mettre en oeuvre certaines étapes de l'invention, en particulier les étapes décrites en référence aux figures 7, 9 et 11. Le dispositif 1500 est, par exemple, un calculateur ou un ordinateur. Il comporte ici un bus de communication 1505 auquel sont reliés : - une ou plusieurs unités centrales de traitement ou 25 microprocesseurs 1510 (CPU) ; - une mémoire morte 1515 (ROM, acronyme de Read Only Memory 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 1520 (RAM, acronyme de 30 Random Access Memory en terminologie anglo-saxonne) comportant des registres adaptés à enregistrer des variables et paramètres créés et modifiés au cours de l'exécution des programmes précités ; et - une interface de communication 1550 adaptée à transmettre et à recevoir des données. Le dispositif 1500 dispose également, de préférence, d'un disque dur 1535 pouvant comporter les programmes précités ainsi que des informations traitées ou à traiter selon l'invention et d'un lecteur de cartes mémoires 1540 adapté à recevoir une carte mémoire 1545 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 1500 ou 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 1500 directement ou par l'intermédiaire d'un autre élément du dispositif 1500. 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 1535 ou en mémoire morte 1515. Selon une variante, la carte mémoire 1545 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 1500, est stocké dans le disque dur 1535. 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 1550, 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 informations à traiter selon l'invention pourront être chargés dans un des moyens de stockage du dispositif 1500 avant d'être exécutés. L'unité centrale 1510 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 1535 ou dans la mémoire morte 1515 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 1535 ou la mémoire morte 1515, sont transférés dans la mémoire vive 1520 qui contient alors le code exécutable du ou des programmes selon l'invention, ainsi que des registres pour 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.
ANNEXE Nom paramètre générique 1e" valeur 2eme valeur 3eme valeur d'instanciation d'instanciation d'instanciation #Paraml# EM1 EM1 EM1 #Param2# El0 El0 El0 #Param3# El 1 E12 E13 #Objet accusable_génériquel# LRU Ll LRU L2 LRU L3 Table 1 : exemple de table des instances de paramètres Rapport de tolérance aux pannes Effet imminent : EM1 effet aéronef, impact élevé Diagnostic préventif à distance 1 avec le suspect S-1 ET Ll Table 2 : rapport de tolérance aux pannes No. Vol Diagnostic Card LS' Poids de persistance (s) (r) trouble vertex min. ObjAcc poids cum.
1 FE.4 {Si}, {L5}, {L2} 1 LS1,1 = {S1, L2, L5} S1 1 (vol courant) L2 1 L5 1 2 FD,3 {S1}, {L2, L3}, {L4} 1, 2 LS1,2 = {S1, L4} S1 1,5 = 1 + 0,5 LS2,2 = {L2, L3} L2 1,25 = 1 + 0,25 3 FD,2 {Si}, {L2}, {L3} 1 L51,3 = {51, L2, L3} S1 1,83 = 1,5 + 0 ,33 L2 1,58 = 1,25 + 0,33 4 FA,1 {S1} 1 LS1.4 = {S1, L4} Si 2,08 = 1,83 + 0,25 FB1 {L4 } Table 3: liste d'objets accusables suspects et poids de persistance de diagnostic
Claims (15)
- REVENDICATIONS1. Procédé pour ordinateur d'aide à l'établissement d'un rapport de diagnostic d'un système complexe d'un aéronef (1300, 1400) comprenant une pluralité de sous-systèmes (1305, 1405), 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 10 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, 15 - une pluralité de sommets représentant chacun un message de notification (400, 405) susceptible d'être reçu ; - au moins un sommet représentant un événement redouté (205, 210) ; et, - une pluralité de sommets représentant chacun un 20 élément (245, 250) dudit système complexe, chaque élément représenté par un sommet étant susceptible de tomber en panne ; il comprend les étapes suivantes, - réception (110) d'au moins un message de notification de réalisation dudit au moins un événement détecté ; 25 - création (115) d'un ensemble de diagnostics minimaux relatifs audit au moins un événement détecté, comprenant une pluralité d'éléments chacun représenté par un sommet dudit graphe d'événements redoutés, chaque élément dudit ensemble de diagnostics minimaux étant déterminés selon au moins une relation 30 d'implication logique dudit graphe d'événements redoutés avec un sommet représentant ledit au moins un message de notification reçu ; et- ordonnancement (130) d'au moins une partie des éléments dudit ensemble de diagnostics minimaux, lesdits éléments ordonnancés appartenant audit rapport de diagnostic.
- 2. Procédé selon la revendication 1 comprenant en outre une étape d'obtention de données représentatives d'un historique de diagnostics dudit système complexe, ladite étape d'ordonnancement étant au moins partiellement fondée sur lesdites données représentatives dudit historique de diagnostic.
- 3. Procédé selon la revendication 1 ou la revendication 2 selon lequel ladite étape d'ordonnancement d'au moins une partie des éléments dudit 10 ensemble de diagnostics minimaux comprend une étape d'ordonnancement d'au moins une partie desdits diagnostics minimaux.
- 4. Procédé selon la revendication 3 comprenant en outre une étape de calcul de poids de persistance de chaque élément d'une pluralité d'éléments dudit ensemble de diagnostics minimaux, ledit calcul de poids de persistance 15 étant basé sur la présence de chaque élément de ladite pluralité d'éléments dudit ensemble de diagnostics minimaux dans un ensemble de diagnostics minimaux dudit historique de diagnostics, ledit ordonnancement d'au moins une partie desdits diagnostics minimaux étant au moins partiellement basé sur des résultats dudit calcul de poids de persistance. 20
- 5. Procédé selon la revendication 3 ou la revendication 4 comprenant en outre une étape de priorisation d'éléments dudit ensemble de diagnostics minimaux.
- 6. Procédé selon la revendication 1 ou la revendication 2 selon lequel ladite étape d'ordonnancement d'au moins une partie des éléments dudit 25 ensemble de diagnostics minimaux comprend une étape d'ordonnancement de troubles résultants desdits diagnostics minimaux.
- 7. Procédé selon la revendication 6 comprenant en outre une étape de calcul de poids de persistance de chaque trouble d'une pluralité de troubles résultants desdits diagnostics minimaux, ledit ordonnancement de troubles 30 étant au moins partiellement basé sur des résultats dudit calcul de poids de persistance.
- 8. Procédé selon l'une quelconque des revendications précédentes comprenant en outre une étape de sélection d'au moins un message de notification susceptible d'être reçu représenté par un sommet dudit graphe d'événements redoutés et une étape d'identification des éléments dudit ensemble de diagnostics minimaux pouvant conduire à la génération dudit au moins un message de notification sélectionné, lesdits éléments identifiés appartenant audit rapport de diagnostic.
- 9. Procédé selon la revendication 8 comprenant en outre une étape de calcul de distance restante avant effet imminent pour au moins un desdits éléments identifiés, ladite distante restante étant calculée en fonction du nombre d'éléments n'appartenant pas audit ensemble de diagnostics minimaux et dont une défaillance est nécessaire à la génération dudit au moins un message de notification sélectionné.
- 10. Procédé selon la revendication 8 ou la revendication 9 comprenant en outre une étape d'obtention et d'assignation d'attributs auxdits éléments identifiés.
- 11. Procédé selon l'une quelconque des revendications précédentes comprenant en outre une étape de sélection d'au moins une procédure de résolution de pannes visant au moins un élément dudit ensemble de diagnostics minimaux.
- 12. Procédé selon l'une quelconque des revendications précédentes selon lequel ledit graphe d'événements redoutés est au moins partiellement généré par instanciation d'au moins un sous-graphe générique.
- 13. Programme d'ordinateur comprenant des instructions adaptées à 25 la mise en oeuvre 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.
- 14. Système de maintenance d'un aéronef comprenant un calculateur comprenant des moyens pour mettre en oeuvre chacune des étapes 30 du procédé selon l'une quelconque des revendications 1 à 12.
- 15. Aéronef comprenant le système selon la revendication 14.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1253383A FR2989499B1 (fr) | 2012-04-12 | 2012-04-12 | Procede, dispositifs et programme d'ordinateur d'aide au diagnostic preventif d'un systeme d'un aeronef, utilisant des graphes d'evenements redoutes |
| US13/861,191 US9399526B2 (en) | 2012-04-12 | 2013-04-11 | Method, devices and program for computer-aided preventive diagnostics of an aircraft system, using critical event charts |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1253383A FR2989499B1 (fr) | 2012-04-12 | 2012-04-12 | Procede, dispositifs et programme d'ordinateur d'aide au diagnostic preventif d'un systeme d'un aeronef, utilisant des graphes d'evenements redoutes |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR2989499A1 true FR2989499A1 (fr) | 2013-10-18 |
| FR2989499B1 FR2989499B1 (fr) | 2014-05-16 |
Family
ID=46650650
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR1253383A Active FR2989499B1 (fr) | 2012-04-12 | 2012-04-12 | Procede, dispositifs et programme d'ordinateur d'aide au diagnostic preventif d'un systeme d'un aeronef, utilisant des graphes d'evenements redoutes |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US9399526B2 (fr) |
| FR (1) | FR2989499B1 (fr) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR3086083A1 (fr) * | 2018-09-18 | 2020-03-20 | Thales | Procede d'analyse des dysfonctionnements d'un systeme et dispositifs associes |
Families Citing this family (21)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2990725B1 (fr) * | 2012-05-16 | 2014-05-02 | Snecma | Procede de surveillance d'une degradation d'un dispositif embarque d'un aeronef avec determination automatique d'un seuil de decision |
| FR3010448B1 (fr) * | 2013-09-06 | 2015-08-21 | Snecma | Procede de surveillance d’une degradation d’un dispositif embarque d’un aeronef avec determination automatique d’un seuil de decision |
| US9284045B1 (en) * | 2014-03-28 | 2016-03-15 | Garmin International, Inc. | Connected cockpit system and method |
| KR20150112561A (ko) * | 2014-03-28 | 2015-10-07 | 한국전자통신연구원 | 항공 시스템에서의 헬스 모니터링 장치 및 방법 |
| US10063433B2 (en) * | 2014-08-11 | 2018-08-28 | Honeywell International Inc. | Remotely monitoring network diagnostics |
| US9550583B2 (en) * | 2015-03-03 | 2017-01-24 | Honeywell International Inc. | Aircraft LRU data collection and reliability prediction |
| US9643737B2 (en) * | 2015-08-19 | 2017-05-09 | The Boeing Company | Sound and scent search engine for mechanics |
| JP6443372B2 (ja) * | 2016-03-24 | 2018-12-26 | トヨタ自動車株式会社 | 車両用ソフトウェア割当てシステム |
| US10096178B2 (en) * | 2017-01-03 | 2018-10-09 | The Boeing Company | Reducing nuisance fault indications from a vehicle using physics based and data driven models |
| US11054342B2 (en) * | 2017-02-20 | 2021-07-06 | Lifewhere, Llc | System for abnormal condition detection using nearest neighbor |
| EP3629976A4 (fr) * | 2017-05-26 | 2021-03-10 | Covidien LP | Ensembles poignées pour systèmes chirurgicaux robotiques |
| US10643187B2 (en) * | 2017-06-09 | 2020-05-05 | Kidde Technologies, Inc. | Reporting and prioritizing faults for aircraft downtime reduction |
| US10776409B2 (en) | 2017-06-21 | 2020-09-15 | International Business Machines Corporation | Recommending responses to emergent conditions |
| US10650614B2 (en) | 2017-09-29 | 2020-05-12 | The Boeing Company | Aircraft maintenance event prediction using higher-level and lower-level system information |
| US10787278B2 (en) * | 2017-09-29 | 2020-09-29 | The Boeing Company | Aircraft maintenance message prediction |
| US11328610B2 (en) * | 2018-07-24 | 2022-05-10 | Honeywell International Inc. | Custom search queries for flight data |
| US10926888B2 (en) * | 2018-08-07 | 2021-02-23 | The Boeing Company | Methods and systems for identifying associated events in an aircraft |
| FR3107256A1 (fr) * | 2020-02-17 | 2021-08-20 | Dassault Aviation | Systeme de suivi d'etat operationnel d'aeronef entre des missions successives de l'aeronef, et procede associe |
| CN111736568A (zh) * | 2020-05-20 | 2020-10-02 | 天津市天锻压力机有限公司 | 一种实时数据库的故障快速诊断方法及系统 |
| CN112541008A (zh) * | 2020-12-09 | 2021-03-23 | 中国航空工业集团公司沈阳飞机设计研究所 | 一种飞机健康诊断判据方法 |
| CN114580842B (zh) * | 2022-01-25 | 2022-12-09 | 中国电子产品可靠性与环境试验研究所（（工业和信息化部电子第五研究所）（中国赛宝实验室）） | 交通工具的签派可靠度分析方法、装置和计算机设备 |
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 |
| US20060161819A1 (en) * | 2005-01-18 | 2006-07-20 | International Business Machines Corporation | History-based prioritizing of suspected components |
| FR2910986A1 (fr) * | 2007-01-03 | 2008-07-04 | Airbus France Sas | Methode de prediction de la fiabilite operationnelle d'un systeme avionique. |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20060095230A1 (en) * | 2004-11-02 | 2006-05-04 | Jeff Grier | Method and system for enhancing machine diagnostics aids using statistical feedback |
| US7681086B2 (en) * | 2007-09-20 | 2010-03-16 | Embraer- Empresa Brasileira De Aeronautica S.A. | Fault tree map generation |
-
2012
- 2012-04-12 FR FR1253383A patent/FR2989499B1/fr active Active
-
2013
- 2013-04-11 US US13/861,191 patent/US9399526B2/en 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 |
| US20060161819A1 (en) * | 2005-01-18 | 2006-07-20 | International Business Machines Corporation | History-based prioritizing of suspected components |
| FR2910986A1 (fr) * | 2007-01-03 | 2008-07-04 | Airbus France Sas | Methode de prediction de la fiabilite operationnelle d'un systeme avionique. |
Non-Patent Citations (2)
| Title |
|---|
| TAO YONGJIAN ET AL: "Notice of Violation of IEEE Publication Principles - Decision Trees Generation Based on Fault Trees Analysis", INFORMATION TECHNOLOGY AND APPLICATIONS, 2009. IFITA '09. INTERNATIONAL FORUM ON, IEEE, PISCATAWAY, NJ, USA, 15 May 2009 (2009-05-15), pages 178 - 180, XP031742427, ISBN: 978-0-7695-3600-2 * |
| ZHIHUA TANG ET AL: "Minimal cut set/sequence generation for dynamic fault trees", RELIABILITY AND MAINTAINABILITY, 2004 ANNUAL SYMPOSIUM - RAMS LOS ANGELES, CA, USA 26-29 JAN. 2004, PISCATAWAY, NJ, USA,IEEE, US, 26 January 2004 (2004-01-26), pages 207 - 213, XP010696025, ISBN: 978-0-7803-8215-2, DOI: 10.1109/RAMS.2004.1285449 * |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR3086083A1 (fr) * | 2018-09-18 | 2020-03-20 | Thales | Procede d'analyse des dysfonctionnements d'un systeme et dispositifs associes |
| WO2020058343A1 (fr) * | 2018-09-18 | 2020-03-26 | Thales | Procédé d'analyse des dysfonctionnements d'un système et dispositifs associés |
Also Published As
| Publication number | Publication date |
|---|---|
| US9399526B2 (en) | 2016-07-26 |
| FR2989499B1 (fr) | 2014-05-16 |
| US20130274992A1 (en) | 2013-10-17 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| 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 | |
| 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 | |
| FR2966616A1 (fr) | Procede, dispositif et programme d'ordinateur d'aide au diagnostic d'un systeme d'un aeronef, utilisant des graphes d'evenements redoutes | |
| EP2364467B1 (fr) | Procédé de reconnaissance de motifs séquentiels pour procédé de traitement des messages de pannes | |
| EP0629940B1 (fr) | Dispositif de détection d'intrusions et d'usagers suspects pour ensemble informatique et système de sécurité comportant un tel dispositif | |
| Esperon-Miguez et al. | A review of Integrated Vehicle Health Management tools for legacy platforms: Challenges and opportunities | |
| 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 | |
| EP1846824B1 (fr) | Systeme et procede de traitements embarques d'essais en vol | |
| WO2007036462A1 (fr) | Procede et systeme de diagnostic des pannes pour aerodynes | |
| Mack et al. | Learning bayesian network structures to augment aircraft diagnostic reference models | |
| FR2953954A1 (fr) | Dispositif d'elaboration des alertes d'un systeme d'aeronef | |
| FR2914764A1 (fr) | Procede et dispositif de determination d'un diagnostic de panne d'une unite fonctionnelle dans un systeme avionique embarque | |
| JP2013100083A (ja) | 輸送機健全性管理システムのモデルを統合するための方法 | |
| FR2949161A1 (fr) | Dispositif pour le diagnostic de systeme | |
| FR2927435A1 (fr) | Procede et dispositif ameliores pour les operations de diagnostic et de maintenance d'aeronefs | |
| FR3007000A1 (fr) | Systeme de surveillance d'une plateforme avionique a architecture trois tiers | |
| WO2017077247A1 (fr) | Système et procédé de surveillance d'une turbomachine avec fusion d'indicateurs pour la synthèse d'une confirmation d'alarme | |
| KR20140045367A (ko) | 헬리콥터 엔진의 정비 추천 시스템 | |
| Felke et al. | Architectures for integrated vehicle health management | |
| WO2007036452A1 (fr) | Procede et systeme de validation des defaillances pour aerodynes | |
| Bharadwaj et al. | Vehicle integrated prognostic reasoner (vipr) final report | |
| FR2999318A1 (fr) | Procede d'evaluation de la surete de fonctionnement d'un systeme complexe | |
| Bense | Prognosis and health monitoring systems for aircraft engines | |
| FR3110721A1 (fr) | Procédé et dispositif électronique de détermination d'une liste d'action(s) de maintenance, programme d'ordinateur associé | |
| CN116306934A (zh) | 基于知识图谱的卫星平台地面安全防护监测方法及系统 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 5 |
|
| 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 |