Brevet FR2891379A1 — publié le 20070330

Procédé et système de diagnostic des pannes pour aérodynes La présente invention concerne un procédé et un système de diagnostic des pannes pour aérodynes. Elle s'applique notamment dans le domaine de l'avionique. La maintenance des avions est un processus continu qui ne se limite pas à quelques visites périodiques pour vérification complète. Tout au long de l'exploitation d'un appareil, celui-ci est sous surveillance constante. Dans un premier temps les mécaniciens de bord reçoivent en vol des alarmes qu'ils analysent instantanément et qu'ils reportent dans le carnet de route de l'avion. Dans un second temps les techniciens de maintenance au sol collectent après chaque vol les données de panne ou de dysfonctionnement générées pendant le vol. Ces données ont été générées soit de manière automatique par des équipements avioniques soit de manière manuelle par le personnel de pilotage. Après chaque atterrissage et avant tout nouveau décollage, même s'il s'agit d'une simple escale, l'avion subit une intervention de maintenance en aéroport. Toutes les traces d'évènements caractérisant une panne ou un fonctionnement anormal de l'un des équipements de l'avion pendant le dernier vol sont récupérées, analysées et interprétées en vue d'établir un diagnostic quant à la capacité de l'avion à décoller et à effectuer à nouveau un vol dans des conditions de sécurité satisfaisantes. Pour établir ce diagnostic, l'opérateur dispose de plusieurs sources d'information sur les pannes, ces sources étant de natures hétérogènes. Tout d'abord il prend connaissance du carnet de route rédigé par le pilote qui récapitule en particulier tous les évènements liés à un dysfonctionnement et ayant eu un effet cockpit, c'est-à-dire qui se sont traduits par une alarme, qu'elle soit sonore ou visuelle, à l'intention du poste de pilotage. Certains dysfonctionnements sont considérés comme superficiels car sans impact sur la sécurité, et par conséquent ils ne font pas l'objet d'une alarme au pilote. Le carnet de route est donc incomplet du point de vue des pannes. Ensuite l'opérateur prend connaissance d'un rapport couramment désigné par sa dénomination anglosaxonne de Post Flight Report (que l'on appellera PFR par la suite) qui fait la synthèse des messages de panne ou de fonctionnement anormal émis par des équipements avioniques. Le PFR est automatiquement généré par un module matériel et logiciel dédié que l'on désigne par l'expression anglo-saxonne de Centralized Maintenance System (que l'on appellera CMS par la suite). L'opérateur de maintenance peut éditer à l'écran ou imprimer le PFR selon ses besoins, il s'agit d'un document textuel lisible par l'homme du métier ayant une connaissance suffisante des opérations de maintenance et disposant du guide de maintenance de l'appareil. Le PFR incrimine des équipements que l'on désigne par l'expression anglo-saxonne de Line Replaceable Unit (que l'on appellera LRU par la suite) qui peuvent être des modules matériels et logiciels en tiroirs de type calculateurs ou bien des capteurs ou encore des actionneurs, que l'opérateur peut changer aisément si nécessaire. Ces LRU comportent une fonction de maintenance d'un type connu par sa désignation anglo-saxonne de Built-In Test Equipement (que l'on appellera fonction BITE par la suite). Cette fonction BITE permet aux LRU de faire des copies de segments de mémoire, de réaliser des diagnostics sur leur état interne de fonctionnement et d'émettre des comptes-rendus que l'on appelle par extension des messages BITE. Ces messages contiennent entre autres l'identifiant du LRU incriminé, un code panne et une heure d'apparition du défaut. Ce sont ces messages BITE qui ont été envoyés par les LRU au CMS, le CMS les ayant mémorisés et utilisés pour générer le PFR. Le PFR incrimine souvent un grand nombre de LRU, mais tous les LRU incriminés ne sont souvent pas défectueux. En effet on assiste à des pannes ou à des dysfonctionnements de LRU en cascade où c'est le comportement anormal d'un unique LRU qui provoque des messages anormaux de la part d'autres LRU fonctionnant normalement, ces derniers générant les mêmes messages que le LRU défectueux par exemple. Et c'est justement là que se pose l'essentiel du problème, car si l'opérateur suit le contenu du PFR à la lettre, il va envoyer en réparation des équipements sans défaut fonctionnant correctement. Une solution habituellement mise en oeuvre en vue d'isoler l'origine de la panne et d'établir un diagnostic plus précis est purement manuelle. Il s'agit pour l'opérateur de maintenance de lancer des tests successifs et de récupérer les résultats et les copies de segments de mémoire qui vont confirmer ou infirmer l'incrimination de chaque LRU dans le PFR. Tout d'abord pour déterminer les LRU à tester initialement, l'opérateur essaie d'imaginer les effets cockpit du dysfonctionnement de chaque LRU incriminé dans le PFR. Si cet effet est consigné à la même heure dans le carnet de route que la défaillance du LRU dans le PFR, alors il démarre la procédure de test attachée à ce LRU. L'opérateur s'appuie entièrement sur le guide de maintenance de l'appareil pour mener à bien cette procédure et surtout pour déterminer l'enchaînement des étapes de test de LRU en fonction des résultats obtenus. Ce guide lui indique, pas à pas, les tests à io lancer. Ainsi, à partir du PFR généré par le CMS, des effets cockpit rapportés par le pilote dans le carnet de route et du guide de maintenance de l'appareil, l'opérateur doit aboutir à une liste restreinte de LRU en état réel de panne ou de dysfonctionnement. En fonction du statut de chacun de ces LRU vis-à-vis de la sécurité de vol, statut couramment qualifié par les expressions anglo- saxonnes GO ou NO GO , en fonction des préconisations du guide de maintenance et également de l'expérience de l'opérateur, celui-ci procède au remplacement des LRU avant que l'avion ne décolle à nouveau. Dans certains cas cela peut conduire à l'immobilisation de l'appareil, notamment pour indisponibilité de LRU de remplacement ou sur préconisation du guide de maintenance. Un premier inconvénient majeur de cette solution est le délai nécessaire à son exécution. En effet le PFR est un compte-rendu exhaustif et du coup, il n'est pas de compréhension évidente. Le carnet de route qu'il faut mettre en relation avec le PFR est non seulement incomplet, mais il n'est non plus ni dédié ni même orienté maintenance et nécessite donc un certain temps pour être interprété correctement. Et enfin le guide de maintenance représente une quantité très importante d'information qu'il est difficile de manipuler. De plus, chaque étape de test et la récupération des copies de segment de mémoire nécessitent souvent plusieurs minutes. Or II faut prendre en compte le contexte de rentabilité économique dans lequel ces opérations sont mises en oeuvre. Par exemple les escales ne doivent pas dépasser une certaine durée pour rentabiliser au mieux l'appareil et les installations aéroportuaires. Par conséquent dans de nombreux cas, l'opérateur préfèrera changer des LRU s'il n'a pas le temps d'aller jusqu'au bout des tests et les services de réparation reçoivent alors des LRU sans défaut. Ainsi cette solution présente des inconvénients économiques majeurs, que ce soit du point de vue de la compagnie aérienne propriétaire de l'avion ou du point de vue de la société exploitant l'aéroport ou encore de celui de l'entreprise assurant les services de maintenance en atelier des équipements. Un autre inconvénient majeur de cette solution, c'est que la part d'appréciation laissée à l'opérateur dans ce contexte de pression économique est une source d'erreur potentielle qui fait que des avions risquent de repartir avec des LRU défectueux. Ainsi cette solution présente aussi un inconvénient du point de vue de la sécurité des voyageurs. L'une des raisons principales pour lesquelles le diagnostic des pannes est abandonné à l'expertise variable des opérateurs de maintenance, c'est que l'on ne dispose pas de relations pertinentes entre les symptômes potentiels de défaillance au moment de la conception de l'appareil. En effet celles-ci ne sont connues qu'au fur et à mesure de son exploitation, mais il est alors trop tard et surtout trop coûteux d'envisager de mettre à jour les fonctions avioniques de maintenance. L'invention a notamment pour but, en s'appuyant sur une connaissance approfondie du système avionique et sur toute l'expérience capitalisée dans la maintenance de l'appareil en question, d'indiquer à l'opérateur de maintenance au sol des opérations de dépannage appropriées aux dysfonctionnements détectés. A cet effet, l'invention a pour objet un procédé et un système de diagnostic des pannes pour aérodynes. Le procédé comporte au moins une phase de configuration définissant les corrélations possibles entre les défaillances détectables, associant à chacune de ces corrélations des données décrivant pertinemment les circonstances du dysfonctionnement et des opérations de dépannage adéquates. Il comporte également au moins une phase de corrélation des défaillances détectées, une phase de récupération des données décrivant les circonstances du dysfonctionnement et une phase de détermination d'opérations de dépannage. Avantageusement les relations définies pendant la phase de 35 configuration peuvent être modélisées sous la forme d'une matrice à i lignes et (m+n+p) colonnes, où i, m, n et p sont des entiers non nuls, i est le nombre de corrélations de défaillances distinctes, m est le nombre maximum de défaillances qui peuvent être corrélées, n est le nombre maximum de données décrivant pertinemment les circonstances d'un dysfonctionnement qui peuvent être récupérées et p est le nombre maximum d'opérations de dépannage qui peuvent être indiquées. Par exemple les défaillances détectables incluent des messages de maintenance BITE émis par des équipements avioniques ou des messages d'alarme envoyés au pilote. L'invention a encore pour principaux avantages qu'elle rend l'exploitation des données de maintenance beaucoup plus simple puisqu'elle réalise une synthèse finale, qui peut être incluse dans le PFR par exemple. Si elle est mise en oeuvre en vol, l'invention permet à l'opérateur de maintenance de prendre connaissance de cette synthèse avant l'atterrissage à distance et il peut donc préparer au mieux son intervention, en se procurant à l'avance les LRU réputés défaillants dans le PFR par exemple. L'invention est adaptable au degré d'expertise de chaque aéroport par mise à jour des données de configuration, éventuellement à distance, en ajustant le niveau de détail du PFR par exemple. Elle autorise une capitalisation efficace de l'expérience des opérateurs de maintenance par mise à jour des données de configuration sur retour d'expérience. Mise en place bien avant la mise en service de l'avion mais configurable même bien après, elle ne nécessitera pas de mise à jour logicielle lorsque la pertinence des différentes corrélations sera établie. Ainsi, en phase d'essai, ces corrélations entre données de panne, même si elles nécessitent des affinements, peuvent déjà être un outil précieux de mise au point. D'autres caractéristiques et avantages de l'invention apparaîtront 30 mieux à l'aide de la description qui suit faite en regard de dessins annexés qui représentent: la figure 1, par un synoptique les phases successives du procédé selon l'invention; - la figure 2, par un diagramme un exemple d'architecture matérielle 35 et logicielle implémentant un système selon l'invention. La figure 1 illustre par un synoptique les phases du procédé selon l'invention. Il comporte tout d'abord une phase 1 de configuration. Cette phase est une phase de définition des données utilisées par le procédé qui dépendent du système avionique. Elle est réalisée initialement avant exploitation du système avionique, avant qu'une panne ou qu'un dysfonctionnement puisse avoir lieu. Elle permet tout d'abord de définir des liens possibles entre les divers évènements caractéristiques d'un mauvais 1 o fonctionnement qui sont susceptibles d'intervenir pendant un vol. Par exemple ces liens peuvent traduire des relations de cause à effet déduites d'une connaissance approfondie de l'architecture du système avionique concerné. Cette phase permet également de définir des données décrivant pertinemment les circonstances d'un dysfonctionnement, comme par exemple la température de certains équipements, leur état de câblage ou l'état des équipements qui leur sont appairés, ou encore la vitesse et la pression, ainsi que le mode de récupération détaillé de ces données. Celles-ci sont associées à chaque groupe d'évènements liés. Enfin cette phase 1 permet de définir des opérations de dépannage au sol et de les associer là aussi à chaque groupe d'évènements liés. Toutes ces associations seront utiles aux phases ultérieures du procédé décrites dans ce qui suit. Elles sont stockées à cet effet. Puis une phase 2 de corrélation des défaillances est déclenchée après l'occurrence d'un évènement caractéristique d'un mauvais fonctionnement. Il est donc très probable que cette phase sera exécutée plusieurs fois par vol. Les corrélations possibles ont été définies lors de la phase de configuration comme des liens possibles entre les évènements, liens de cause à effet par exemple. Il est à noter qu'il n'est pas toujours possible de réaliser une corrélation d'évènements, soit parce-que aucun autre événement ne survient, soit parce-que les évènements survenus ne font pas l'objet d'un lien défini lors de la phase de configuration. Dans ce cas l'événement est considéré comme isolé mais cela n'empêche pas son traitement dans les phases suivantes. A la fin de cette phase, l'évènement isolé ou les évènements liés sont stockés à l'intention d'un opérateur de maintenance. 2891379 7 Le résultat de la phase de corrélation des défaillances est immédiatement utilisé par une phase 3 de récupération des données décrivant pertinemment les circonstances du dysfonctionnement. Dans ce qui suit, ces données seront appelées les données de contexte XXX. En fonction de l'événement isolé ou du groupe d'évènements liés et des données de contexte qui leur ont été associées lors de la phase de configuration, certains équipements bien particuliers sont interrogés concernant leur état au moment où le dysfonctionnement a été détecté. Toutes les données nécessaires à cette interrogation ciblée ont été définies lors de la phase de configuration. Cette phase se termine sur réception des réponses renvoyées par les équipements, réponses qui sont stockées à l'intention d'un opérateur de maintenance. Un point essentiel de l'invention est la prise en compte de ces données de contexte concernant n'importe quel équipement susceptible d'avoir un rapport avec la défaillance en vue d'établir un diagnostic de panne le plus pertinent possible. Enfin une phase 4 de détermination d'opérations de dépannage permet d'indiquer immédiatement des opérations de dépannage au sol adéquates en fonction de l'événement isolé ou du groupe d'évènements liés qui sont survenus et des données de contexte à ce moment là, ceci toujours à partir des associations définies lors de la phase de configuration. Cette indication d'opérations de dépannage est stockée à l'intention de l'opérateur de maintenance au sol, qui va changer les équipements incriminés. Eventuellement aucune indication n'est donnée par manque d'expérience vis-à-vis de certains types de défaillance. Et c'est justement la pratique acquise tout au long de l'exploitation du procédé qui permettra de le compléter grâce au retour d'expérience des opérateurs de maintenance. C'est un avantage essentiel de l'invention. La figure 2 illustre par un diagramme un exemple d'architecture matérielle et logicielle implémentant un système selon l'invention. Dans ce mode de réalisation une base de données 20 appelée base de données associations stocke avantageusement une matrice de configuration. Une base de données 21 appelée base de données avion stocke notament une modélisation de l'architecture matérielle et logicielle des équipements avioniques de l'appareil, les données de cette modélisation ayant été fournies lors de la phase de configuration du procédé selon l'invention. La matrice de configuration contient les relations possibles entre les divers évènements caractéristiques d'un mauvais fonctionnement, les données de contexte associées et les opérations de dépannage au sol adéquates. Par exemple c'est une matrice à i lignes et (m+n+p) colonnes avec i, m, n et p entiers positifs non nuls. Les i lignes permettent de représenter les i relations entre évènements caractéristiques de dysfonctionnement connues au moment de l'implémentation du système. Les m premières colonnes permettent d'associer au maximum m évènements caractéristiques de dysfonctionnement, les n colonnes suivantes permettent de leur associer au maximum n données de contexte et les p dernières colonnes permettent enfin de leur associer au maximum p opérations de dépannage. La base de données associations stocke cette matrice de configuration en phase d'initialisation du système avionique, avant chaque décollage par exemple, ceci pour adapter au mieux le système au niveau d'expertise du prochain aéroport dans lequel l'avion atterrira et où les opérations de dépannage seront effectuées. La base de données avion stocke les détails du mode de récupération des données de contexte, par exemple l'adresse des équipements sur le bus de données 25, en vue d'envoyer à ces équipements des requêtes concernant leur état en cas de détection d'un dysfonctionnement. Cette base de données est remplie une fois pour toutes à l'installation des équipements avioniques dans l'avion. Elle pourra éventuellement être mise à jour en cas de modifications du système avionique au cours de la vie de l'appareil. Les deux bases de données font partie d'un sous-système 26 de type CMS et ayant pour vocation, comme explicité précédemment, de fournir des PFR. Dans l'exemple illustré par la figure les données de configuration sont stockées dans des bases de données, mais elles peuvent tout de même être recopiées dans la mémoire vive d'un calculateur du CMS lors de leur utilisation, pour améliorer les temps d'accès aux données. Dans cet exemple, les équipements avioniques susceptibles de fournir des messages de panne ou de dysfonctionnement sont les trois LRU 22, 23 et 24. Ces LRU comportent par exemple une fonction BITE décrite précédemment qui permet aux LRU de réaliser des diagnostics sur leur état interne de fonctionnement et d'émettre des messages BITE contenant, entre autres, un identifiant de LRU incriminé, un code panne et une heure d'apparition du défaut. Dans l'exemple de la figure, les LRU sont connectés au même bus de données 25 auquel est également connecté le CMS 26. Sur réception par le CMS d'un message BITE émis par l'un des LRU, la phase de corrélation des défaillances du procédé selon l'invention est déclenchée par activation d'une fonction 27 de corrélation. Dans cet exemple la fonction de corrélation essaie avantageusement d'établir des relations entre les messages BITE reçus et les messages d'alarme envoyés au poste de pilotage par exploitation des m premières colonnes de la matrice de configuration. En effet la fonction de corrélation est aussi à l'écoute des sorties d'un sous-système 28 désigné par l'expression anglo-saxonne de Failure Warning System (qu'on appellera FWS par la suite) ayant pour fonction de filtrer des messages d'alarme émis par les LRU et d'en faire une synthèse exploitable par le pilote en fonction de leur pertinence vis-à- vis des conditions de sécurité. On peut envisager un mode de réalisation de la fonction de corrélation où les messages BITE ne sont pas associés entre eux et où chaque message BITE est associé de manière indépendante à des messages d'alarme cockpit. On peut également envisager un mode de réalisation de cette fonction où les messages BITE sont à la fois associés entre eux et à la fois avec des messages d'alarme cockpit. Une fois une relation entre les messages BITE et les alarmes établie conformément aux m premières colonnes d'une ligne j de la matrice de configuration, la fonction de corrélation complète cette relation par des données dites de surveillance qui sont en fait les données de contexte du dysfonctionnement, comme la température d'un équipement ou son état de câblage ou encore l'état de son équipement appairé. C'est la phase de récupération des données décrivant pertinemment les circonstances du dysfonctionnement du procédé selon l'invention. Pour cela, la fonction de corrélation exploite les n colonnes suivantes de la ligne j de la matrice de configuration. Elle utilise également les détails des modes d'interrogation des équipements décrits dans la base de données avion, comme leur adresse sur le bus de données, pour envoyer des requêtes de rapport de surveillance ciblant chacun des équipements potentiellement incriminés. Ces requêtes sont traitées par un sous-système centralisateur 29 désigné par l'expression anglo-saxonne de Flight Data Acquisition System (que l'on appellera FDAS par la suite) qui renvoie un rapport de surveillance en réponse à la fonction de corrélation. Ce sous-système a connaissance de l'ensemble des données de surveillance, par exemple grâce à une connexion directe au bus de données, qui est lui-même alimenté en données de surveillance par des mécanismes connus par ailleurs. Enfin la fonction 30 désignée par l'expression anglo-saxonne de Trouble Shooting Data (que l'on appellera fonction TSD par la suite) exploite les p dernières colonnes correspondant à la ligne j de la matrice de configuration pour déduire des opérations de dépannage adéquates. Elle io fournit le résultat final du procédé sous la forme d'un PFR dans ce mode de réalisation. Le PFR fait notamment la synthèse de toutes les associations effectuées entre des messages BITE, des messages d'alarme et des données de surveillance. Pour chacune de ces associations, le PFR indique surtout des opérations de dépannage adéquates. Il est à noter que les indications d'opérations de dépannage issues des p dernières colonnes de la ligne j de la matrice de configuration sont déduites non seulement d'une connaissance approfondie de l'architecture du système, mais qu'elles tiennent également compte des données de surveillance qui sont des données ciblées sur des équipements au moment même de la défaillance. La prise en compte de ces données de surveillance pour établir un diagnostic et indiquer des opérations de dépannage adéquate est un point essentiel de l'invention. Si la fonction de corrélation et la fonction TSD sont exécutées pendant le vol, il ne reste plus à l'opérateur de maintenance au sol après l'atterrissage qu'à consulter le PFR pour savoir éventuellement quels LRU remplacer. On peut même envisager que le PFR soit émis vers le sol et que l'opérateur en prenne connaissance avant l'atterrissage. Ainsi il peut se procurer les LRU défaillants avant de rejoindre l'avion sur le tarmac. REVENDICATIONS 1. Procédé de diagnostic des pannes pour aérodynes, caractérisé en ce qu'il comporte au moins: une phase de configuration (1) définissant les corrélations possibles entre les défaillances détectables, associant à chacune de ces corrélations des données décrivant pertinemment les circonstances du dysfonctionnement et des opérations de dépannage adéquates; une phase de corrélation des défaillances détectées (2) ; une phase de récupération des données décrivant les circonstances du dysfonctionnement (3) ; une phase de détermination d'opérations de dépannage (4). 2. Procédé de diagnostic des pannes pour aérodynes selon la revendication 1, caractérisé en ce que les relations définies pendant la phase de configuration sont modélisées sous la forme d'une matrice à i lignes et (m+n+p) colonnes, où i, m, n et p sont des entiers non nuls, i est le nombre de corrélations de défaillances distinctes, m est le nombre maximum de défaillances qui peuvent être corrélées, n est le nombre maximum de données décrivant pertinemment les circonstances d'un dysfonctionnement qui peuvent être récupérées et p est le nombre maximum d'opérations de dépannage qui peuvent être indiquées. 3. Procédé de diagnostic des pannes pour aérodynes selon la revendication 1 ou 2, caractérisé en ce que les défaillances détectables incluent des messages de maintenance BITE émis par des équipements avioniques. 4. Procédé de diagnostic des pannes pour aérodynes selon la revendication 1 ou 2, caractérisé en ce que les défaillances détectables incluent des messages d'alarme envoyés au pilote. 5. Système de diagnostic des pannes pour aérodynes, caractérisé en ce qu'il comporte au moins: un dispositif de stockage de données (20, 21) définissant les corrélations possibles entre les défaillances détectables, associant à chacune de ces corrélations des données décrivant pertinemment les circonstances du dysfonctionnement et des opérations de dépannage adéquates; un module de corrélation des défaillances détectées (27) ; io -un module de récupération des données décrivant les circonstances du dysfonctionnement (27) ; un module de détermination d'opérations de dépannage (30). 6. Système de diagnostic des pannes pour aérodynes selon la revendication 5, caractérisé en ce que la définition des corrélations possibles entre les défaillances détectables, l'association à chacune de ces corrélations des données décrivant pertinemment les circonstances du dysfonctionnement et les opérations de dépannage adéquates sont stockées sous la forme d'une matrice à i lignes et (m+n+p) colonnes, où i, m, n et p sont des entiers non nuls, i est le nombre de corrélations de défaillances distinctes, m est le nombre maximum de défaillances qui peuvent être corrélées, n est le nombre maximum de données décrivant pertinemment les circonstances d'un dysfonctionnement qui peuvent être récupérées et p est le nombre maximum d'opérations de dépannage qui peuvent être indiquées.