Brevet FR2891380A1 — publié le 20070330

Procédé et système de validation des défaillances pour aérodynes La présente invention concerne un procédé et un système de validation des défaillances pour aérodynes. Elle s'applique par exemple 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. II 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 à 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 mais du même 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 vraiment 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 Il 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. Ce manque de fiabilité du diagnostic nuit gravement à la sécurité des vols. Ainsi cette solution présente aussi un inconvénient majeur du point de vue des voyageurs. L'invention a notamment pour but de faire gagner du temps à l'opérateur dans certaines tâches de maintenance, lui permettant ainsi de se consacrer davantage et plus sereinement aux opérations les plus délicates nécessitant une réelle expertise. A cet effet, l'invention a pour objet un procédé et un système de validation des défaillances pour aérodynes. Le procédé comporte au moins une étape de configuration associant à chaque défaillance détectable d'une part des équipements dont une copie de segments de mémoire est à réaliser et d'autre part des tests de vérification à effectuer, une étape de copie de segments de mémoire et une étape de vérification des équipements. Avantageusement les associations définies pendant la phase de configuration peuvent être modélisées sous la forme d'une matrice à i lignes et (m+n) colonnes, où i, m et n sont des entiers non nuls, i étant le nombre de défaillances distinctes connues, m étant le nombre maximum d'équipements dont on peut faire une copie mémoire, n étant le nombre maximum de tests de vérification que l'on peut réaliser. Par exemple les défaillances détectées sont des messages de 30 maintenance BITE émis par des équipements avioniques. L'invention a encore pour principaux avantages qu'elle peut être réalisée automatiquement dès l'atterrissage, libérant ainsi l'opérateur de maintenance au sol des manipulations de lancement de certains tests et de récupération des résultats. Le gain de temps qui en découle va dans le sens d'une meilleure rentabilité économique. De plus l'invention peut être implémentée sur les architectures avioniques les plus classiques sans aucune modification de la configuration matérielle. D'autres caractéristiques et avantages de l'invention apparaîtront 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 étapes successives du procédé selon l'invention; la figure 2, par un diagramme un exemple d'architecture matérielle et logicielle implémentant un système selon l'invention. La figure 1 illustre par un synoptique les étapes successives du procédé selon l'invention. II 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 d'associer à chaque événement caractéristique d'une défaillance, d'une part des équipements dont une copie de la mémoire est pertinente et d'autre part des tests de vérification pertinents. Toutes ces données d'association seront utiles aux phases ultérieures du procédé décrites dans ce qui suit. Elles sont stockées à cet effet. Une étape 2 de copie de segments de mémoire de certains équipements est déclenchée sur occurrence d'un événement caractéristique d'une défaillance, copie couramment désignée en informatique par l'expression anglo-saxonne dump . Les équipements en question sont ceux qui sont certainement ou potentiellement impliqués de manière directe ou indirecte dans la défaillance, ceci ayant été déduit d'une connaissance approfondie de l'architecture du système avionique. Par exemple un évènement caractéristique d'une défaillance peut être l'émission par un équipement avionique d'un message BITE. Les copies de segments de mémoire sont stockées à l'intention de l'opérateur de maintenance. Enfin une étape 3 de vérification des équipements est déclenchée. Il s'agit de confirmer ou infirmer le dysfonctionnement des équipements à l'origine des évènements caractéristiques d'une défaillance, ceci en lançant des procédures de test. En effet, comme on l'a précédemment explicité dans le cas ou les équipements sont des LRU, il peut s'agir d'un phénomène de dysfonctionnement en cascade et un équipement peut donner des signes de défaillance sans être réellement défaillant. Par exemple les tests peuvent être des tests autonomes des LRU mis à disposition par leur fonction BITE. A l'issue du test l'équipement est en mesure de fournir des détails quant à son état interne de fonctionnement. Les résultats des tests sont par exemple stockés à l'intention de l'opérateur de maintenance. 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 notament une matrice de configuration. La matrice de configuration contient les associations entre les défaillances, les équipements dont il faut faire une copie de mémoire et les tests de vérification à effectuer. Par exemple c'est une matrice à i lignes et (m+ n) colonnes avec i, m et n entiers positifs non nuls. Les i lignes permettent de représenter les i évènements caractéristiques de défaillance connus au moment de l'implémentation du système. Pour une ligne i donnée correspondant à un évènement caractéristique d'une défaillance, les m premières colonnes permettent de lui associer au maximum m équipements dont il faut réaliser une copie de la mémoire et les n colonnes suivantes permettent de lui associer au maximum n tests de vérification à réaliser. Les opérations sont à réaliser dans l'ordre croissant des indices de colonne, cet ordre traduisant par exemple la séquence chronologique décrite dans le guide de maintenance. Dans ce mode de réalisation une base de données 21 appelée base de données avion stocke une modélisation de l'architecture matérielle et logicielle des équipements avioniques de l'appareil. Elle stocke notamment les détails du mode d'interrogation des équipements, par exemple l'adresse des équipements sur le bus de données 25, qui va permettre de leur envoyer des requêtes concernant leur état en cas de détection d'une défaillance. Cette base de données avion est remplie une fois pour toutes à l'installation des équipements avioniques dans l'avion. Elle pourra éventuellement être mise à jour en cas de modification 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 2 les données de configuration sont stockées dans des bases de données, mais elles peuvent tout de même être chargées dans la mémoire vive d'un calculateur du CMS, ce qui améliore 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 une fonction BITE décrite précédemment qui permet aux LRU d'émettre des messages BITE contenant entre autres un identifiant de LRU incriminé, un code panne et une heure d'apparition du défaut. Les fonctions BITE des LRU de cet exemple comportent chacune un module matériel de stockage de segments de mémoire désigné par l'expression anglo-saxonne Non Volatile Memory (que l'on appellera NVM par la suite). Ce sont les NVM 28, 29 et 30 qui permettent aux LRU de faire des copies de leur mémoire sur détection d'un dysfonctionnement en même temps qu'ils émettent un message BITE. 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. Pour tout message BITE émis par l'un des LRU et reçu par le CMS, la phase de copie de la mémoire des équipements défaillants du procédé selon l'invention est déclenchée par activation d'une fonction 27 de lancement de copie. Dans ce mode de réalisation, la fonction de lancement de copie fait avantageusement l'association entre le message BITE reçu et les équipements dont il faut faire une copie de la mémoire par exploitation des m premières colonnes de la ligne j de la matrice de configuration correspondant au message BITE reçu. 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 copie de mémoire ciblant chacun des équipements potentiellement incriminés, à savoir les LRU. Les copies de segments de mémoire pertinents contenus dans les NVM sont envoyés en réponse aux requêtes de copie émises par la fonction de lancement de copie. Les copies de segments de mémoire ne sont pas lisibles par l'homme et ne sont donc pas inclues dans le PFR qui reste inchangé. Elles sont mises à disposition de l'opérateur de maintenance telle quelles par le CMS. Le CMS, qui est un système complètement orienté maintenance, fournit à l'opérateur de maintenance un mode de récupération des copies de segments de mémoire bien meilleur en terme de débit que celui fourni directement par l'équipement avionique. Ainsi l'opérateur de maintenance téléchargera les volumineuses copies de mémoire dans un délai considérablement réduit. Puis la fonction 31 de lancement des tests de vérification exploite les n dernières colonnes correspondant à la ligne j de la matrice de configuration pour connaître les équipements à tester. Elle aussi utilise 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 tests ciblant chacun des LRU potentiellement incriminé. Dans ce mode de réalisation les test lancés sont des tests autonomes mis à disposition par la fonction BITE des LRU. Les résultats renvoyés par la fonction BITE des LRU ne sont pas inclus dans le PFR qui reste inchangé mais sont mis à disposition de l'opérateur de maintenance à l'état brut et selon un mode de récupération habituel connu par ailleurs de l'opérateur. Mais on pourrait envisager que le CMS réalise une synthèse dans le PFR qu'il émet par ailleurs. En tout cas l'opérateur de maintenance téléchargera directement les résultats des tests, il n'aura plus à attendre leur temps d'exécution. Les LRU de cet exemple ne fonctionnant pas en mode mixte, c'est-à-dire à la fois en mode opérationnel et en mode maintenance, les fonctions de lancement de copie et de lancement des test ne sont pas exécutées en vol dès réception d'un message BITE. Elles ne sont exécutées que immédiatement après l'atterrissage et après passage des LRU en mode maintenance. Le passage des LRU en mode maintenance se fait automatiquement, par exemple en exploitant le statut communément désigné par l'expression anglo-saxonne de Weight On Wheels qui indique si l'une des roues de l'avion supporte du poids ou pas. Ainsi il ne restera plus à l'opérateur de maintenance au sol qu'à consulter le PFR sachant que les copies de mémoire et les resultats de test des LRU incriminés dans ce PFR seront déjà disponibles sans aucune intervention manuelle de sa part. C'est le point essentiel du procédé selon l'invention, à savoir l'automatisation de certaines tâches de maintenance en vue de gagner du temps d'exploitation de l'appareil et des installations aéroportuaires. On peut même envisager que le PFR, les copies de mémoire et les résultats de test soient émis vers l'opérateur de maintenance avant qu'il ne quitte son atelier. Ainsi il peut se procurer les LRU potentiellement défaillants avant de rejoindre l'avion sur le tarmac. REVENDICATIONS 1. Procédé de validation des défaillances pour aérodynes, caractérisé en ce qu'il comporte au moins: une étape de configuration (1) associant à chaque défaillance détectable d'une part des équipements dont une copie de segments de mémoire est à réaliser et d'autre part des tests de vérification à effectuer; une étape de copie de segments de mémoire (2) ; une étape de vérification des équipements (3). 2. Procédé de validation des défaillances pour aérodynes selon la revendication 1, caractérisé en ce que les associations définies pendant la phase de configuration sont modélisées sous la forme d'une matrice à i lignes et (m+n) colonnes, où i, m et n sont des entiers non nuls, i étant le nombre de défaillances distinctes connues, m étant le nombre maximum d'équipements dont on peut faire une copie mémoire, n étant le nombre maximum de tests de vérification que l'on peut réaliser. 3. Procédé de validation des défaillances pour aérodynes selon l'une quelconque des revendications précédentes, caractérisé en ce que les défaillances détectées sont des messages de maintenance BITE émis par des équipements avioniques. 4. Système de validation des défaillances pour aérodynes, caractérisé en ce qu'il comporte au moins: un dispositif de stockage de données (20, 21) associant à chaque défaillance détectable des équipements dont une copie de segments de mémoire et des tests de vérification sont à réaliser; - un module de copie de segments de mémoire (27) ; - un module de vérification des équipements (31). 5. Système de validation des défaillances pour aérodynes selon la revendication 4, caractérisé en ce que l'association à chaque défaillance détectable des équipements dont une copie de segments de mémoire et des tests de vérification sont à réaliser est stockée sous la forme d'une matrice à i lignes et (m+n) colonnes, où i, m et n sont des entiers non nuls, i étant le nombre de défaillances distinctes connues, m étant le nombre maximum d'équipements dont on peut faire une copie mémoire, n étant le nombre maximum de tests de vérification que l'on peut réaliser.