FR2936330A1 - Procedes et dispositifs de gestion des informations de maintenance dans un aeronef. - Google Patents

Abstract

L'invention a notamment pour objet un procédé et un dispositif de gestion des informations de maintenance dans un aéronef comprenant un système centralisé de maintenance. Après avoir reçu (300) un message de maintenance, la valeur d'un attribut d'impact associé audit message reçu est déterminée (305) selon des données de configuration prédéterminées. En réponse audit message reçu et à ladite valeur dudit attribut d'impact associé audit au moins un message reçu, ledit message reçu est traité (340). L'invention vise également la détermination de données de configuration pour la gestion des informations de maintenance dans un aéronef.

Description

La présente invention concerne les opérations de maintenance des aéronefs et plus particulièrement des procédés et des dispositifs de gestion des informations de maintenance adaptés à déterminer un niveau de priorité aux pannes ayant un impact économique sur l'exploitation de l'aéronef afin de transmettre certaines de ces informations durant les vols et de les indiquer de façon spécifique dans le rapport de maintenance des vols. Les critères principaux de gestion des pannes dans les aéronefs sont généralement liés à la sécurité de leur exploitation. Les pannes ayant un impact sur la sécurité d'exploitation d'un aéronef sont systématiquement présentées aux pilotes, de préférence via le système d'alerte du cockpit. Les pilotes rapportent alors ces alertes dans leur rapport de fin de vol, appelé logbook en terminologie anglo-saxonne, par la création d'une entrée dans ce rapport, aussi appelée entrée du logbook. Parallèlement, un ou plusieurs messages de maintenance sont automatiquement générés et mémorisés dans le rapport de maintenance du vol. De tels messages ont pour objet d'indiquer aussi précisément que possible l'origine des défaillances ayant conduit aux alertes présentées aux pilotes. Aux escales, une équipe de maintenance consulte les entrées du logbook auxquelles elle doit impérativement répondre de façon exhaustive avant le prochain décollage. A ces fins, elle s'appuie sur le rapport de maintenance du vol qui lui donne des indications sur les actions à effectuer pour réparer la ou les pannes. Cependant, lorsqu'une panne n'affecte pas la sécurité du vol, elle n'est généralement pas indiquée aux pilotes via le système d'alerte du cockpit et, dans ce cas, elle n'est pas reportée dans le logbook. Par conséquent, l'équipe de maintenance n'a pas d'obligation particulière de la traiter. Il se peut d'ailleurs que les mécaniciens n'en prennent pas connaissance si le rapport de maintenance n'est pas consulté en dehors de ce qui concerne strictement les pannes rapportées par l'équipage. Il existe également des mécanismes permettant d'anticiper les actions de maintenance. Selon ces mécanismes, les messages de maintenance sont transmis en temps réel pendant le vol. Cependant, ils se limitent en général aux problèmes pouvant affecter la sécurité afin de restreindre le volume et le coût des transmissions en vol. Par ailleurs, le marché du transport aérien devenant de plus en plus concurrentiel, un nombre croissant de compagnies aériennes souhaite optimiser leurs opérations de maintenance, non seulement en ce qui concerne les pannes affectant la sécurité, mais aussi les pannes pouvant avoir des impacts économiques significatifs. De telles pannes comprennent notamment les pannes suivantes, - les pannes liées aux systèmes de maintenance qui peuvent causer des retards significatifs entraînant des coûts directs tels que les compensations financières des passagers et les taxes aéroportuaires et une altération de l'image de marque de la compagnie aérienne. Par exemple, si le système centralisé de maintenance ne fonctionne pas, il est beaucoup plus long et difficile d'identifier l'origine des dysfonctionnements rapportés par l'équipage et d'y apporter une réponse permettant à l'aéronef d'effectuer sa ou ses prochaines missions. De même, si le système de téléchargement des données est inopérant, il est plus long de remplacer un calculateur tombé en panne car il est nécessaire de trouver un calculateur de rechange déjà chargé avec les modules logiciels requis ou d'effectuer son chargement en atelier ; et, - les pannes liées au confort des passagers. Ce type de pannes affecte notamment les compagnies aériennes dont la stratégie commerciale se base sur la qualité des services offerts aux clients. A titre d'illustration, l'indisponibilité du système appelé IFE (acronyme d'In Flight Entertainment en terminologie anglo-saxonne), destiné à offrir des activités de loisir pendant le vol telles que des films et des jeux ou l'indisponibilité des toilettes, notamment en classe supérieure, peut également se traduire par des compensations financières directes et affecter l'image de la compagnie aérienne. De plus, de telles pannes peuvent entraîner une désaffection plus ou moins durable de ses passagers. L'invention permet de résoudre au moins un des problèmes exposés précédemment.

L'invention a ainsi pour objet un procédé de gestion des informations de maintenance dans un aéronef comprenant un système centralisé de maintenance, ce procédé comprenant les étapes suivantes, - réception d'au moins un message de maintenance ; - détermination de la valeur d'un attribut d'impact associé audit au 10 moins un message reçu selon des données de configuration prédéterminées ; et, - en réponse audit au moins un message reçu et à ladite valeur dudit attribut d'impact associé audit au moins un message reçu, traitement dudit au moins un message reçu. 15 Le procédé selon l'invention permet ainsi d'assister un opérateur de maintenance dans le tri des informations en distinguant les informations relatives à l'exécution d'une prochaine mission d'un aéronef de celles qui ne relèvent pas de l'exécution d'une prochaine mission de l'aéronef. En outre, cette gestion des priorités génère un gain de temps significatif pour les 20 opérateurs de maintenance et/ou les mécaniciens en permettant notamment d'identifier rapidement les actions à effectuer. Le procédé selon l'invention permet également de diminuer le risque de retards des aéronefs, seules les actions essentielles étant entreprises lors des temps d'escale courts. De façon avantageuse, le procédé comprend en outre une étape 25 initiale de réception desdites données de configuration permettant de les préparer au sol avec les intervenants compétents du constructeur de l'aéronef et de la compagnie exploitant l'aéronef. Selon un mode de réalisation particulier, lesdites données de configuration prédéterminées comprennent au moins une information relative à 30 au moins un message prédéterminé, une valeur d'attribut d'impact étant associée à ladite au moins une information relative audit au moins un message prédéterminé, ladite étape de détermination de ladite valeur dudit attribut d'impact associé audit au moins un message reçu comprenant une étape d'identification de ladite au moins une valeur d'attribut d'impact associé à ladite au moins une information relative audit au moins un message prédéterminé, ladite au moins une information relative audit au moins un message prédéterminé étant similaire à ladite information représentative dudit au moins un message reçu. La valeur d'un attribut d'impact est ainsi déterminée par simple comparaison d'un paramètre relatif à un message tel qu'un identifiant ou un identifiant des effets fonctionnels associés à un message. De façon avantageuse, lesdites données de configuration prédéterminées comprennent au moins une combinaison, ladite au moins une combinaison comprenant une pluralité d'informations dont au moins une est relative à au moins un message prédéterminé, ladite étape de détermination de ladite valeur dudit attribut d'impact comprenant les étapes suivantes, - comparaison d'une information représentative dudit au moins un message reçu avec ladite au moins une information relative audit au moins un message prédéterminé ; et, - en réponse à ladite étape de comparaison, activation de ladite au moins une information relative audit au moins un message prédéterminé, ladite valeur dudit attribut d'impact associé audit au moins un message reçu étant déterminée selon l'état d'activation de chacune desdites informations de ladite au moins une combinaison. La valeur de l'attribut d'impact associé à un message peut ainsi être déterminée selon des messages préalablement reçus et/ou des effets fonctionnels préalablement identifiés.

Selon un mode de réalisation particulier ladite au moins une information relative à au moins un message prédéterminé est adaptée à identifier ledit au moins un message prédéterminé ou à identifier un effet fonctionnel, lié audit au moins un message prédéterminé, sur une partie dudit aéronef.

L'invention a également pour objet un procédé de détermination de données de configuration pour la gestion des informations de maintenance dans un aéronef selon le procédé décrit précédemment, ce procédé de détermination comprenant les étapes suivantes, - détermination d'un ensemble de messages de maintenance représentatifs de défaillances et d'effets fonctionnels associés auxdites défaillances ; - assignation d'une valeur d'attribut d'impact à au moins un message dudit ensemble de messages de maintenance selon l'effet fonctionnel associé audit au moins un message ; - sélection d'une pluralité de messages dans ledit ensemble de messages, ladite pluralité de messages comprenant ledit au moins un message ; - modification de la valeur d'un attribut d'impact d'au moins un message de ladite pluralité de messages ; et, - formatage de ladite pluralité de messages, ladite pluralité de 15 messages formatés comprenant au moins une information représentative d'au moins un message et une valeur d'attribut d'impact associé. L'invention permet ainsi de prédéterminer les valeurs des attributs d'impact selon les caractéristiques des messages de maintenance. Une telle détermination peut être réalisée en plusieurs étapes par des intervenants 20 distincts, notamment par des spécialistes de l'aéronef et par des spécialistes de l'exploitation de l'aéronef. Selon un mode de réalisation particulier, le procédé comprend en outre une étape de création d'une combinaison de messages et/ou d'effets fonctionnels pour permettre de définir la valeur d'attribut d'impact associée à un 25 message selon des messages reçus préalablement et/ou des effets fonctionnels préalablement identifiés. L'invention a également 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. 30 L'invention a aussi pour objet un dispositif comprenant des moyens adaptés à la mise en oeuvre de chacune des étapes du procédé décrit précédemment ainsi qu'un aéronef comprenant de tels moyens.

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, au regard des dessins annexés dans lesquels : - la figure 1 illustre schématiquement les différentes phases d'exploitation d'un aéronef ; - la figure 2 représente un exemple d'algorithme pouvant être utilisé pour associer un niveau de priorité aux messages de maintenance reçus ; - la figure 3 illustre un exemple d'algorithme mis en oeuvre dans le système centralisé de maintenance d'un aéronef pour gérer les informations de maintenance, conformément à l'invention ; et, - la figure 4 illustre un exemple d'architecture matérielle adaptée à mettre en oeuvre l'invention, notamment chacune des parties des algorithmes représentés sur les figures 2 et 3. L'invention vise notamment à déterminer un niveau de priorité pour chaque information relative aux pannes ayant impact sur l'exploitation d'un aéronef. Il convient tout d'abord de noter que l'intérêt d'un tel mécanisme est d'autant plus important que le volume d'information de maintenance produite par les aéronefs de nouvelle génération est en constante augmentation. Néanmoins, le problème technique d'identification de pannes ayant un impact économique sur l'exploitation des aéronefs est double. D'une part, il ne faut pas utiliser les moyens habituels d'alerte au pilote pour ne pas le perturber avec des informations ne concernant pas directement la conduite du vol. D'autre part, le mécanisme doit pouvoir s'adapter aux politiques commerciales de chaque compagnie aérienne.

Ainsi, conformément à l'invention, un mécanisme d'identification des informations relatives aux pannes ayant un impact économique significatif sur l'exploitation d'un aéronef est mis en oeuvre pour permettre à la compagnie aérienne exploitant l'aéronef de les traiter selon leur priorité. Ce mécanisme se base sur un niveau de priorité qui peut être, par exemple, un attribut d'impact ou de disponibilité associé à chaque message de maintenance. Selon un mode de réalisation particulier, l'attribut d'impact peut prendre deux états, un état normal et un état, appelé HDI (sigle d'high dispatch impact en terminologie anglo-saxonne), indiquant une anomalie ayant un impact économique significatif sur l'exploitation de l'aéronef. Cependant, l'invention peut également être mise en oeuvre avec plus de deux états. En particulier, la valeur de l'attribut d'impact peut être relative à l'importance de l'impact économique sur l'exploitation de l'aéronef. Un tel attribut peut être prédéfini, notamment par le constructeur de l'aéronef ou la compagnie aérienne l'exploitant. Le constructeur définit, de préférence, cet attribut pour les pannes relatives aux systèmes de maintenance eux-mêmes, tandis qu'avantageusement, la compagnie aérienne le définit pour les différentes pannes ayant des effets dans la cabine. Alternativement ou de façon complémentaire, cet attribut peut être calculé dynamiquement pour tenir compte, notamment, de l'effet cumulé de plusieurs pannes concomitantes. La valeur de cet attribut et/ou les règles de son calcul dynamique sont ici mémorisées dans une base de données embarquée dans l'aéronef, cette base de données étant consultée par le système centralisé de maintenance lorsqu'il reçoit un message de maintenance. Des traitements particuliers peuvent être effectués par le système de maintenance en fonction de la valeur de cet attribut pour permettre, en particulier, aux équipes de maintenance de la compagnie aérienne de prendre connaissance du problème et de le traiter selon sa priorité en complément des entrées du logbook reportés par les pilotes durant le vol. De façon avantageuse, ce mécanisme ne met pas en oeuvre les systèmes d'alarme de l'aéronef et, par conséquent, ne requiert aucune action spéciale de la part des pilotes. Dans un mode de réalisation simple, les messages de maintenance dont la valeur de l'attribut d'impact est égale à HDI, appelés messages HDI, sont signalés de manière particulière dans le rapport de maintenance. Durant l'exploitation de l'aéronef, à la réception de chaque message de maintenance généré par les systèmes de l'aéronef, le système centralisé de maintenance détermine la valeur de son attribut dans une base de données embarquée ou, le cas échéant, la calcule dynamiquement à l'aide des règles prédéfinies, de préférence en fonction des messages de panne préalablement reçus. Cette valeur est alors mémorisée avec les autres caractéristiques du message dans le rapport de maintenance du vol. De telles caractéristiques sont par exemple un code de défaillance, l'heure de détection de la défaillance et les codes des messages corrélés. Le rapport de maintenance du vol est avantageusement présenté à l'opérateur de maintenance après chaque mission de l'aéronef. Par ailleurs, le système centralisé de maintenance permet d'effectuer un tri des messages en fonction de l'attribut d'impact pour sélectionner tous les messages HDI. Les messages peuvent être sélectionnés qu'ils fassent partie ou non d'un ensemble de messages corrélés entre eux. Ce mécanisme de détermination de l'attribut et de tri des messages s'applique également, de préférence, aux messages émis en réponse à des opérations de tests lancés par un opérateur à l'aide du système centralisé de maintenance. Ainsi, une compagnie aérienne peut enrichir ses procédures de maintenance en demandant à ses mécaniciens de répondre aux entrées du logbook mais également d'adresser les pannes identifiées dans le rapport de maintenance dont la valeur de l'attribut d'impact est égale à HDI.

Selon une première variante, outre l'identification des messages HDI dans les rapports de maintenance et dans les résultats de tests consultés par le mécanicien à bord de l'aéronef, le système centralisé de maintenance de l'aéronef transmet également, en cours de mission, en temps réel, les messages HDI vers le sol. A ces fins, lorsque le système centralisé de maintenance reçoit un message de maintenance, il applique tout d'abord un algorithme de filtrage des messages intempestifs puis un algorithme de corrélation des messages avec les alarmes pour regrouper toutes les informations relatives à la même panne. Les messages HDI sont ensuite identifiés parmi les messages non corrélés et non filtrés. Lorsque l'attribut d'impact comprend plus de deux états, il est en outre possible de filtrer les messages en fonction de la valeur de cet attribut, par exemple par rapport à un seuil qui peut être prédéterminé ou dynamique.

Toutes les informations susceptibles d'avoir des conséquences sur l'exécution de la prochaine mission sont envoyées en temps réel, par exemple en utilisant un lien de communication de type ACARS (sigle d'Aircraft Communications Addressing and Reporting System en terminologie anglo- saxonne). Ces informations sont ici les entrées logbook validées par les pilotes, les ensembles de messages corrélés contenant au moins une alarme et les messages HDI non filtrés. Toutes les autres informations de maintenance sont transmises lorsque l'aéronef est au sol, c'est à dire lorsque des modes de communication performants et peu onéreux sont disponibles.

Ainsi, une compagnie aérienne peut enrichir ses procédures de maintenance en analysant les messages HDI reçus au sol par des techniciens spécialisés regroupés, par exemple, au sein du centre de maintenance appelé MCC (sigle de Maintenance Control Center en terminologie anglo-saxonne). Ces techniciens peuvent consulter des informations complémentaires telles que les paramètres relatifs au prochaines missions, le taux de remplissage passagers, la disponibilité des personnels compétents et des pièces de rechange à la prochaine escale afin de confirmer ou non la demande de réparation des pannes correspondant aux messages HDI et, le cas échéant, anticiper les actions de maintenance en acheminement, par exemple, des pièces ou en préparant les procédures. De façon avantageuse, le mécanisme selon l'invention permet en outre aux techniciens du MCC de créer à distance des entrées du logbook couvrant les demandes de réparation des pannes correspondant aux messages HDI. Ces entrées viennent par exemple s'ajouter à celles des pilotes lors d'une synchronisation des données sol/bord lorsque l'aéronef est au sol après avoir accompli une mission. Ainsi, l'équipe de maintenance peut concentrer son travail de façon classique sur la réponse aux entrées du logbook qui contient des informations relatives aux pannes pouvant avoir des effets sur la sécurité de l'aéronef, dont les références sont saisies par les pilotes, et les pannes ayant un impact économique significatif sur l'exploitation de l'aéronef, dont les références sont entrées à distance par le MCC.

Selon une autre variante, les mécanismes d'identification à bord des messages HDI et leur transmission au sol en temps réel sont complétés d'un système au sol permettant d'aider les techniciens du MCC à prendre la décision de réparation d'une panne n'affectant pas la sécurité avion. Ce système est de préférence relié aux centres de la compagnie aérienne, par exemple aux centres suivants : - centre opérationnel de gestion des missions en charge notamment du planning des prochains vols ; - centre commercial gérant les contraintes particulières relatives au 10 confort des passagers ; et, - centre de gestion de la maintenance en charge de la gestion des stocks de pièces de rechange et des activités de maintenance planifiées. Ce système comprend un ensemble de règles logiques qui permettent à la compagnie aérienne de formaliser sa politique de décision. De 15 telles règles sont par exemple les suivantes : - une panne d'IFE est acceptable en classe économique sur des vols de moins de deux heures ; - une panne d'IFE en première classe se traduit par un dédommagement d'un montant prédéterminé pour les passagers occupant les 20 sièges affectés ; et, - une panne du système de maintenance n'est pas acceptable pour un avion qui part pour une mission ayant plus d'une escale sans station locale de la compagnie aérienne. Ce système peut ainsi déterminer un niveau de recommandation 25 pour la réparation de chaque message HDI selon les critères suivants : - impact commercial vis-à-vis des passagers ; et, - risque de retard technique sur les prochaines missions. Lorsqu'un technicien du MCC a pris une décision concernant une réparation, le système au sol permet d'en répercuter l'information aux autres 30 réseaux de la compagnie aérienne. Par exemple, s'il n'est pas possible de réparer l'IFE d'une première classe, le réseau commercial sera averti de la compensation à verser au passager des sièges affectés. De même, si une réparation longue du système de maintenance doit intervenir, le centre opérationnel d'exploitation de l'aéronef est averti du retard potentiel et peut procéder à un changement de planning ou d'aéronef. La figure 1 illustre schématiquement les différentes phases d'exploitation d'un aéronef. La référence 100 vise la position verticale de l'aéronef 105, caractéristique de son exploitation, tandis que la référence 110 représente la ligne du temps. Les références O et ' indiquent l'instant auquel le pilote accepte d'effectuer la mission qui lui a été confiée, après avoir vérifié les fonctionnalités de l'aéronef. Les références e et e indiquent le décollage et l'atterrissage, respectivement. La référence indique la fin de la mission et la référence O indique le moment où les opérations de maintenance sont terminées, c'est-à-dire le moment où il a été répondu à toutes les entrées du logbook. La référence O vise la période comprise entre les instants O et durant laquelle l'aéronef effectue une mission tandis que la référence O vise la période comprise entre les instants et C Y, c'est-à-dire la période de maintenance de l'aéronef 105. Comme indiqué précédemment, l'invention a pour objet de réduire la période O. Durant l'exploitation de l'aéronef (période O), un attribut d'impact est déterminé pour chaque message de maintenance, par exemple pour chaque message de type BITE (acronyme Built-ln Test Equipment en terminologie anglo-saxonne). Une corrélation est déterminée entre les messages reçus et un filtrage des messages est effectué. Les messages de maintenance relatifs aux défaillances ayant un impact sur la sécurité de l'aéronef ainsi que les messages HDI sont avantageusement transmis en temps réel au MCC où ils sont analysés pour permettre l'organisation de la maintenance. Les autres messages de maintenance sont de préférence transmis au MCC entre les instants e et pour permettre leur prise en compte durant la phase de maintenance O.

Pour effectuer les opérations de maintenance (période O), les techniciens de maintenance ouvre le logbook établi par le pilote durant la mission ainsi que les documents préparés par le MCC en vue de la maintenance. Les actions de maintenance correspondantes sont alors effectuées et il est répondu à chaque entrée du logbook. La figure 2 représente un exemple d'algorithme pouvant être utilisé pour associer un niveau de priorité aux messages de maintenance, c'est-à-dire ici une valeur d'attribut d'impact. Les résultats de cet algorithme sont utilisés dans les aéronefs, conformément à l'invention, pour déterminer si un message doit être transmis au MCC ou non (en vol ou via le logbook). Selon cet exemple, l'attribut d'impact consiste en l'attribution ou non de l'état HDI à chaque message de type BITE. Une première attribution est ici réalisée par le constructeur de l'aéronef, cette attribution étant ensuite complétée et/ou modifiée par la compagnie aérienne exploitant l'aéronef. Une première étape (étape 200) a pour objet de définir l'état HDI de certains messages de type BITE en fonction de l'effet fonctionnel de la panne ayant provoqué l'émission du message considéré.

A ces fins, chaque message de type BITE, défini par les spécialistes système du constructeur de l'aéronef et mémorisé dans une base de données 205, éventuellement complété manuellement, est analysé. L'analyse consiste ici à identifier l'effet fonctionnel de la panne ayant provoqué l'émission du message considéré. Les effets fonctionnels sont, par exemple, mémorisés dans la base de données 210. Ils peuvent être caractérisés par une sévérité qui peut être obtenue à l'aide d'un lien automatique vers l'outil de génération de la MMEL (sigle de Master Minimum Equipment List en terminologie anglo-saxonne) ou de façon manuelle en ce qui concerne les effets fonctionnels relatifs aux fonctions de maintenance.

Un jeu de règles prédéterminées mémorisé ici dans la base de données 215 permet, sur la base de cette caractéristique de sévérité, d'associer ou non l'état HDI aux messages considérés. De telles règles sont par exemple les suivantes, - l'état de l'attribut d'impact d'un message est non HDI pour tous les 30 messages ayant des effets fonctionnels dans la cabine (l'impact économique ne peut être décidé par le constructeur de l'aéronef) ; - l'état de l'attribut d'impact d'un message est HDI pour tous les messages dont l'effet fonctionnel dans le cockpit n'est pas une alarme (afin de permettre leur transmission en vol sans alarme corrélée et ainsi forcer le traitement de ces messages par le MCC) ; et, - l'état de l'attribut d'impact d'un message est HDI pour tous les messages ayant un effet fonctionnel de sévérité haute sur les fonctions de maintenance. Les messages, ou les identifiants des messages, sont ici mémorisés dans la base de données 220 avec la valeur d'attribut d'impact associée.

Lorsque cette étape de prédéfinition est effectuée, une sélection des messages de maintenance est, de préférence, effectuée par les spécialistes du constructeur de l'aéronef (étape 225). Cette sélection comprend tous les messages HDI tels que déterminés à l'étape 200 ainsi que les messages dont l'impact économique peut, selon la politique des compagnies aériennes, être jugé significatif. En d'autres termes, cette étape vise à écarter tous les messages dont l'impact économique n'est jamais important, quel que soit le contexte opérationnel. Cette étape a pour objet de réduire le nombre de messages à traiter par les compagnies aériennes et, ainsi, simplifier la personnalisation pouvant être effectuée par celle-ci.

Cette sélection est réalisée en utilisant les informations contenues dans la base de données 220, contenant notamment les messages sélectionnés à l'étape 200, ainsi que leurs effets fonctionnels associés. Le résultat de cette sélection est ici mémorisé dans le fichier 230, par exemple sous forme de table où chaque identifiant de message est associé à une valeur d'attribut d'impact. Ce fichier est transmis aux compagnies aériennes ou est rendu accessible à celles-ci. Les compagnies aériennes disposent d'un outil de personnalisation spécifique pour accéder, présenter et modifier les données de ce fichier (étape 235). La modification des attributs d'impact est possible par une sélection manuelle ou par la définition et l'application de règles liées à la politique commerciale et/ou de maintenance de la compagnie aérienne mémorisées ici dans la base de données 240.

A titre d'illustration, une compagnie aérienne peut considérer une panne comme ayant un impact économique significatif si elle génère un effet fonctionnel de sévérité moyenne sur les fonctions de maintenance. Par ailleurs, il est possible de définir des combinaisons de messages de maintenance et/ou d'effets fonctionnels, notamment en ce qui concerne la cabine, pour permettre de déterminer dynamiquement les valeurs des attributs d'impact (étape 245). Ces combinaisons peuvent également être mémorisées dans le fichier 230. Ces combinaisons peuvent être déterminées avant l'étape de personnalisation, parallèlement à celle-ci ou après celle-ci.

Lorsque la personnalisation a été effectuée par la compagnie aérienne et que, le cas échéant, les combinaisons de messages et/ou d'effets fonctionnels ont été déterminées, le fichier 230 comprenant ces données des messages est formaté par un outil spécifique généralement appelé outils de préparation des loads avion (étape 250). Les données sont par exemple formatées conformément au standard ARINC 665. Les données formatées sont ensuite transmises au système centralisé de maintenance de l'aéronef en tant que fichier de configuration (étape 255). La figure 3 illustre un exemple d'algorithme mis en oeuvre dans le système centralisé de maintenance d'un aéronef pour gérer les informations de 20 maintenance, conformément à l'invention. Après avoir reçu un message de type BITE (étape 300), le système détermine la valeur de l'attribut d'impact devant être associée à ce message (étape 305) en consultant le fichier de configuration 310 préalablement mémorisé dans l'aéronef. Un test est alors effectué (étape 315) pour déterminer 25 si le message reçu est un message HDI. Si le message reçu n'est pas un message HDI, un autre test est effectué (étape 320) pour déterminer si le message reçu ou le ou les effets fonctionnels associés appartiennent à une combinaison de messages et/ou d'effets fonctionnels pouvant conduire à associer dynamiquement l'état HDI au 30 message reçu. Ce test est effectué, par exemple, en déterminant si le message reçu est identifié dans la liste des combinaisons contenues dans le fichier de configuration 310. Alternativement ou de façon complémentaire, ce test peut consister à déterminer si le ou les effets fonctionnels associés à ce message appartiennent au fichier de configuration 310. Si le message reçu ou le ou les effets fonctionnels associés n'appartiennent pas à une combinaison pouvant conduire à associer dynamiquement l'état HDI au message reçu, celui-ci est ignoré et l'algorithme se poursuit en retournant à l'étape 300 pour traiter d'éventuels nouveaux messages. Si le message reçu ou le ou les effets fonctionnels associés appartiennent à une combinaison pouvant conduire à associer dynamiquement l'état HDI au message reçu (étape 320), la donnée correspondante dans la combinaison est activée. L'activation d'un élément d'une combinaison peut consister, par exemple à mémoriser temporairement le message reçu dans une mémoire tampon (étape 325) qui est, de préférence, effacée à la fin de chaque mission. De la même façon, le ou les effets fonctionnels associés au message reçu peuvent être mémorisés dans cette mémoire tampon. Un autre test est alors effectué (étape 330) pour déterminer si la combinaison de messages et/ou d'effets fonctionnels à laquelle appartient le message reçu ou le ou les effets fonctionnels associés est complète, c'est-à-dire si tous ses éléments sont activés. Par exemple, une combinaison de messages est complète si tous les messages appartenant à cette combinaison ont été reçus. Ce test est effectué, par exemple, en comparant les identifiants des messages mémorisés dans la mémoire tampon avec les combinaisons contenues dans le fichier de configuration 310. Il convient de remarquer ici que des effets fonctionnels peuvent être identifiés indépendamment de la réception de messages de maintenance. Ces effets sont alors, de préférence, mémorisés dans la mémoire tampon pour être pris en compte lors du test des combinaisons. Si la combinaison de messages et/ou d'effets fonctionnels à laquelle appartient le message reçu n'est pas complète, l'algorithme se poursuit en retournant à l'étape 300 pour traiter d'éventuels nouveaux messages.

Au contraire, si la combinaison de messages et/ou d'effets fonctionnels à laquelle appartient le message reçu est complète, l'état HDI est associé à tous les messages de la combinaison (étape 335). Lorsque le message reçu est un message HDI, identifié comme HDI ou auquel l'état HDI a été dynamiquement assigné, le message reçu, ainsi que les éventuels autres messages auquel l'état HDI a été assigné durant l'étape 335, sont traités (étape 340). Parallèlement, l'algorithme se poursuit en retournant à l'étape 300 pour traiter d'éventuels nouveaux messages.

Comme indiqué précédemment, le traitement des messages HDI consiste, en particulier, à mémoriser l'état HDI avec les autres caractéristiques du message, notamment le code, l'heure d'arrivée et les messages corrélés pour permettre la corrélation et le filtrage des messages reçus ainsi que, le cas échéant, l'identification de ces messages dans les rapports de maintenance et les résultats de tests consultés par le mécanicien à bord de l'aéronef, la transmission en temps réel du message vers le sol et/ou le traitement d'aide à la décision au sol pour les techniciens du MCC. La figure 4 illustre un exemple d'architecture matérielle adaptée à mettre en oeuvre l'invention, notamment chacune des parties des algorithmes représentés sur les figures 2 et 3. Le dispositif 400 comporte ici un bus de communication 405 auquel sont reliés : - une unité centrale de traitement ou microprocesseur 410 (CPU, sigle de Central Processing Unit en terminologie anglo-saxonne) ; - une mémoire morte 415 (ROM, acronyme de Read Only Memory 25 en terminologie anglo-saxonne) pouvant comporter les programmes nécessaires à la mise en oeuvre de l'invention ; - une mémoire vive ou mémoire cache 420 (RAM, acronyme de Random Access Memory en terminologie anglo-saxonne) comportant des registres adaptés à enregistrer des variables et paramètres créés et modifiés au 30 cours de l'exécution des programmes précités ; et - une interface de communication 450 adaptée à transmettre et à recevoir des données, notamment vers et depuis les dispositifs commandés de l'aéronef pour les contrôler et connaître leur état. Le dispositif 400 dispose également, de préférence, des éléments suivants : - un écran 425 permettant de visualiser des données telles que des représentations des commandes et pouvant servir d'interface graphique avec l'utilisateur qui pourra interagir avec les programmes selon l'invention, à l'aide d'un clavier et d'une souris 430 ou d'un autre dispositif de pointage tel qu'un écran tactile ou une télécommande ; - d'un disque dur 435 pouvant comporter les programmes précités et des données traitées ou à traiter selon l'invention ; et - d'un lecteur de cartes mémoires 440 adapté à recevoir une carte mémoire 445 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 400 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 400 directement ou par l'intermédiaire d'un autre élément du dispositif 400. 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 435 ou en mémoire morte 415.

Selon une variante, la carte mémoire 445 peut contenir des données, notamment une table de correspondance entre les événements détectés et les commandes pouvant être sollicitées, ainsi que le code exécutable des programmes précités qui, une fois lu par le dispositif 400, est stocké dans le disque dur 435.

Selon une autre variante, le code exécutable des programmes pourra être reçu, au moins partiellement, par l'intermédiaire de l'interface 450, pour être stocké de façon identique à celle décrite précédemment.

De manière plus générale, le ou les programmes pourront être chargés dans un des moyens de stockage du dispositif 400 avant d'être exécutés. L'unité centrale 410 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 435 ou dans la mémoire morte 415 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 435 ou la mémoire morte 415, sont transférés dans la mémoire vive 420 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.

Claims (10)

1. REVENDICATIONS1. Procédé de gestion des informations de maintenance dans un aéronef comprenant un système centralisé de maintenance, ce procédé étant caractérisé en ce qu'il comprend les étapes suivantes, - réception (300) d'au moins un message de maintenance ; détermination (305) de la valeur d'un attribut d'impact associé 10 audit au moins un message reçu selon des données de configuration prédéterminées ; et, - en réponse audit au moins un message reçu et à ladite valeur dudit attribut d'impact associé audit au moins un message reçu, traitement (340) dudit au moins un message reçu. 15
2. 2. Procédé selon la revendication 1 comprenant en outre une étape initiale de réception desdites données de configuration.
3. 3. Procédé selon la revendication 1 ou la revendication 2 selon lequel lesdites données de configuration prédéterminées comprennent au moins une information relative à au moins un message prédéterminé, une 20 valeur d'attribut d'impact étant associée à ladite au moins une information relative audit au moins un message prédéterminé, ladite étape de détermination de ladite valeur dudit attribut d'impact associé audit au moins un message reçu comprenant une étape d'identification de ladite au moins une valeur d'attribut d'impact associé à ladite au moins une information relative audit au moins un 25 message prédéterminé, ladite au moins une information relative audit au moins un message prédéterminé étant similaire à ladite information représentative dudit au moins un message reçu.
4. 4. Procédé selon la revendication 1 ou la revendication 2 selon lequel lesdites données de configuration prédéterminées comprennent au 30 moins une combinaison, ladite au moins une combinaison comprenant une pluralité d'informations dont au moins une est relative à au moins un messageprédéterminé, ladite étape de détermination de ladite valeur dudit attribut d'impact comprenant les étapes suivantes, - comparaison (320) d'une information représentative dudit au moins un message reçu avec ladite au moins une information relative audit au 5 moins un message prédéterminé ; et, - en réponse à ladite étape de comparaison, activation (325) de ladite au moins une information relative audit au moins un message prédéterminé, ladite valeur dudit attribut d'impact associé audit au moins un message reçu 10 étant déterminée selon l'état d'activation de chacune desdites informations de ladite au moins une combinaison.
5. 5. Procédé selon la revendication 3 ou la revendication 4 selon lequel ladite au moins une information relative à au moins un message prédéterminé est adaptée à identifier ledit au moins un message prédéterminé 15 ou à identifier au moins un effet fonctionnel, lié audit au moins un message prédéterminé, sur une partie dudit aéronef.
6. 6. Procédé de détermination de données de configuration pour la gestion des informations de maintenance dans un aéronef selon le procédé de l'une quelconque des revendications précédentes, ce procédé de détermination 20 étant caractérisé en ce qu'il comprend les étapes suivantes, - détermination d'un ensemble de messages de maintenance représentatifs de défaillances et d'effets fonctionnels associés auxdites défaillances - assignation (200) d'une valeur d'attribut d'impact à au moins un 25 message dudit ensemble de messages de maintenance selon l'effet fonctionnel associé audit au moins un message ; - sélection d'une pluralité de messages dans ledit ensemble de messages, ladite pluralité de messages comprenant ledit au moins un message ; 30 - modification de la valeur d'un attribut d'impact d'au moins un message de ladite pluralité de messages ; et,- formatage (250) de ladite pluralité de messages, ladite pluralité de messages formatés comprenant au moins une information représentative d'au moins un message et une valeur d'attribut d'impact associé.
7. 7. Procédé selon la revendication précédente comprenant en outre une étape de création d'une combinaison de messages ou d'effets fonctionnels.
8. 8. Programme d'ordinateur comprenant des instructions adaptées à 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.
9. 9. Dispositif comprenant des moyens adaptés à la mise en oeuvre de chacune des étapes du procédé selon l'une quelconque des revendications 1 à 7.
10. 10. Aéronef comprenant le dispositif selon la revendication précédente dépendante des revendications 1 à 5.15