FR 2977046 A1 20121228 FR 1255926 A 20120622 Diagnostic perfectionné pour aéronefs La présente invention concerne de façon générale des diagnostics perfectionnés pour aéronefs. Plus particulièrement, la présente invention concerne un système et un procédé pour recueillir et analyser des données spécifiques d'aéronefs afin d'améliorer le diagnostic de recherche de pannes et de maintenance dans des aéronefs. L'évolution de l'aéronautique a conduit à l'installation de systèmes de plus en plus complexes dans les aéronefs pour le diagnostic, la surveillance et la gestion de divers systèmes embarqués. Afin de mieux faire face à cette complexité accrue, divers systèmes de bord d'aéronefs contiennent aujourd'hui ou sont aptes à produire des copies, mémorisées par voie électronique, de divers manuels et modes opératoires de maintenance pour l'aéronef ou le type d'aéronef spécifique. Ces manuels peuvent être mémorisés, par exemple, dans un système de maintenance embarqué. Souvent, ceux-ci sont les équivalents de manuels imprimés créés avant les premiers vols de l'aéronef ou peu après un vol initial d'essai, puis homologués par un organisme public de certification (comme, par exemple, la Federal Aviation Authority (FAA) aux Etats-Unis ou la Civil Aviation Authority (CAA) au Royaume-Uni). Dans ces manuels de maintenance peuvent également être inclus divers modes opératoires de recherche de pannes et techniques de remise en état prédéterminés en fonction d'une analyse d'anomalies prévisibles et de leur propagation. Ces modes opératoires et techniques peuvent être élaborés par des ingénieurs concepteurs d'après leur expérience acquise ou au moyen de données simulées. Cependant, de tels modes opératoires prédéterminés "codés en dur" sont souvent imparfaits et risquent donc d'aboutir à un manque d'efficacité dans la recherche de pannes effectuée par le personnel de maintenance, par exemple en déposant et remplaçant des pièces non appropriées ou des équipements remplaçables en escale (les LRU), si bien qu'un ou plusieurs états de "fonctionnement normal" (NFF) sont obtenus avant que le problème ne soit finalement corrigé. Parmi les autres conséquences potentielles, on citera un allongement des temps d'immobilisation, des retards, d'éventuelles annulations de vols, etc. De plus, il se peut que des ingénieurs n'aient qu'une connaissance incomplète de divers problèmes de maintenance, en particulier en ce qui concerne les propriétés émergentes d'un système, par exemple des cas de pannes qui peuvent être tellement complexes que leurs propriétés ne peuvent pas être modélisées ni prédites avec précision au cours de la phase de mise au point. Dans cette optique, on sait que divers techniciens de maintenance conservent des archives non officielles de modes opératoires de recherche de pannes dont ils estiment, de par leur expérience, qu'ils fonctionnent mieux et plus rapidement que les versions officielles recommandées. Cependant, du fait de la nature non officielle de tels modes opératoires, cette expérience pratique n'est généralement ni soumise à un examen collégial ni largement divulguée, au détriment général de l'ensemble du monde de l'aéronautique. De la sorte, il serait très souhaitable de proposer des techniques de maintenance plus rapides et plus précises pour les aéronefs en réduisant de la sorte à la fois les coûts directs liés à la recherche de pannes et aux coûts secondaires dus à des retards provoqués par des vols ratés, des vols retardés, des états de fonctionnement normaux, etc. Cela offrirait également l'avantage que moins de modifications seraient à apporter à un aéronef en cours de maintenance, en réduisant de ce fait le risque qu'une pièce par ailleurs fiable devienne non fiable du fait de sa dépose et de ses manipulations. Par conséquent, la présente invention a été élaborée en tenant compte des inconvénients évoqués plus haut, associés aux techniques de maintenance connues. Selon un premier aspect de la présente invention, il est proposé un système pour analyser automatiquement des données de systèmes d'aéronef. Le système comporte un module d'acquisition de données servant à acquérir des données sur des systèmes d'aéronef, un module d'archivage de données servant à stocker des données sur les systèmes d'aéronef et un module d'analyse de données servant à analyser les données sur les systèmes d'aéronef afin d'identifier des procédures de recherche de pannes non prédéterminées pour corriger des anomalies. Selon un autre aspect de la présente invention, il est proposé un procédé pour analyser automatiquement des données sur des systèmes d'aéronef. Le procédé comprend les étapes d'acquisition de données sur les systèmes d'aéronef, de stockage de données sur les systèmes d'aéronef et d'analyse des données sur les systèmes d'aéronef afin d'identifier des procédures de recherche de pannes non prédéterminées pour corriger des anomalies. En permettant une analyse automatisée de données sur des systèmes d'aéronef afin d'identifier des procédures de recherche de pannes non prédéterminées pour la correction d'anomalies, il est possible de proposer un système et un procédé adaptatifs. De telles techniques peuvent également apporter des solutions pour remédier à des pannes rares que la plupart des techniciens ne sont pas susceptibles de rencontrer au cours de leur carrière, et permettre en outre l'identification d'éventuels défauts de conception inhérents à des types spécifiques d'aéronefs d'après une analyse globalisée de données, par exemple au niveau de la flotte. L'invention sera mieux comprise à l'étude détaillée de quelques modes de réalisation pris à titre d'exemples non limitatifs et illustrés par les dessins annexés sur lesquels : - la figure 1 représente un système pour analyser automatiquement des données sur des systèmes d'aéronef selon une forme de réalisation de la présente invention ; - la figure 2 représente un schéma d'architecture fonctionnelle de niveau élevé d'un système de maintenance embarqué selon diverses formes de réalisation de la présente invention ; - la figure 3 représente un système de maintenance embarqué selon une autre forme de réalisation de la présente invention ; et - la figure 4 représente un procédé pour analyser automatiquement des données sur des systèmes d'aéronef selon diverses formes de réalisation de la présente invention. La figure 1 représente un système 100 pour analyser automatiquement des données sur des systèmes d'aéronef selon une forme de réalisation de la présente invention. Le système 100 comporte un moniteur 130 de données servant à contrôler des données sur des systèmes d'aéronef transmises par l'intermédiaire d'un bus 150 de données de systèmes d'aéronef. Le moniteur 130 de données peut être un dispositif adressable en interface avec le bus, ou pourrait être constitué par un renifleur de données qui contrôle des paquets de données transmises par l'intermédiaire du bus 150 de données sur les systèmes d'aéronef de telle sorte qu'un contrôle non gênant puisse être réalisé sans qu'il ne soit nécessaire de procéder à un adressage séparé du moniteur 130 de données. Ainsi, l'utilisation d'un renifleur de données peut être préférable dans diverses formes de réalisation afin que des erreurs d'adressage dans le bus 150 de données sur les systèmes d'aéronef n'empêchent pas un déroulement continu de la fonction de contrôle. Par ailleurs, grâce à l'utilisation d'un renifleur de données, le moniteur 130 de données n'a pas besoin d'un codage dur ni d'une liaison par câblages avec le bus 150 de données sur les systèmes d'aéronef, ce qui facilite donc leur intégration et leur installation dans des systèmes d'aéronef existants. Un module de traitement 110 est inclus dans le système 100. Le module de traitement 110 comprend : un module d'archivage 104 de données couplé au moniteur 130 de données par l'intermédiaire d'une liaison 132 de données ; un module d'analyse 106 de données couplé au module d'archivage 104 de données par l'intermédiaire d'une liaison 114 de données ; et un module d'acquisition 102 de données couplé au module 106 de données par l'intermédiaire d'un liaison 112 de données. Divers modules peuvent être réalisés à l'aide d'un ou de plusieurs éléments parmi un microprogramme, un matériel et un logiciel. Une liaison extérieure118 de données facultative est prévue pour connecter le module d'acquisition 102 de données, par exemple, à une base de données centrale (non représentée) située hors de l'aéronef. En fonctionnement, le module d'acquisition 102 de données acquiert des données sur les systèmes d'aéronef concernant les modes opératoires de maintenance prédéterminés connus alors pour résoudre des problèmes spécifiques. Dans la présente forme de réalisation, ces modes opératoires peuvent être obtenus à partir d'une source située à l'extérieur de l'aéronef, via la liaison 118 de données, et/ou à partir d'un module interne 120 de stockage de manuel de maintenance, couplé au module d'acquisition 102 de données par l'intermédiaire d'une liaison 124 de données. Le module d'acquisition 102 de données peut ainsi servir en outre à acquérir les données sur les systèmes de l'aéronef provenant d'une pluralité d'aéronefs. De la sorte, une pluralité de systèmes 100 pourraient être connectés les uns aux autres (par exemple par un accès réseau à distance) afin d'analyser des données provenant d'aéronefs de types similaires ou différents (par exemple, les Airbus® A340, A380 qui utilisent des systèmes de données communs ou similaires). Par exemple, divers systèmes peuvent envoyer des données à un lieu central où elles sont analysées. Des mises à jour peuvent ensuite être communiquées en retour aux aéronefs respectifs à partir du lieu central. Le module d'archivage 104 de données coopère avec le moniteur 130 de données pour identifier des anomalies dans l'aéronef et les enregistrer en prévision de nouvelles actions, par exemple pour leur correction ultérieure par un technicien de maintenance. Par exemple, le moniteur 130 de données peut détecter divers signaux d'essais intégrés (BIT) faisant l'objet d'une assertion dans le bus 150 de données sur les systèmes de l'aéronef. La détection de tels signaux BIT peut avoir pour effet la production d'un enregistrement d'erreur et son enregistrement par le module d'archivage 104 de données, avec d'autres données concernant l'état du bus 150 de données sur les systèmes de l'aéronef au moment où le/les signaux BIT a/ont été détecté(s). Les signaux BIT peuvent servir ensuite soit individuellement soit sous la forme de diverses combinaisons pour identifier des anomalies spécifiques de l'aéronef qu'il convient de corriger ou d'étudier plus en détail. Le module d'analyse 106 de données sert à analyser les données sur les systèmes de l'aéronef afin d'identifier des modes opératoires de recherche de pannes non prédéterminés pour corriger les anomalies. Dans un algorithme, une mesure de corrélation sert à identifier une série prédéterminée, la plus proche, de modes opératoires de maintenance prédéterminés afin de résoudre un problème de maintenance particulier. Le problème spécifique, qui peut être désigné à l'aide d'un identifiant exclusif (UID), est ensuite défini comme point de départ avec une adaptation, sur la base de statistiques ou d'un modèle, d'actions prédéterminées aux mesures réelles prises qui sont mises en oeuvre pour trouver si les actions réelles prises sont connues ou constituent un mode opératoire potentiel de recherche de pannes non prédéterminé, éventuellement plus efficace pour résoudre le même problème. Le module d'analyse 106 de données coopère également avec un module d'interface d'entrée/sortie (E/S) 140 par l'intermédiaire d'une liaison bidirectionnelle 116 de données. Le module d'interface E/ 140 peut servir à présenter une interface utilisateur graphique (GUI) (non représentée) soit sur un écran d'affichage intégré (non représenté) soit en produisant une sortie graphique pour une connexion à un dispositif amovible ayant un écran, comme par exemple un ordinateur portatif, un assistant numérique personnel (PDA) ou analogue, lorsqu'il est connecté au module d'interface E/S 140. Le module d'interface E/S 140 comprend en outre un module de capture 142 de données de tâches de maintenance et est connecté à une liaison externe 144 de données. En fonctionnement, un utilisateur (non représenté) est en interaction avec le système 100 en réalisant une saisie de données à l'aide de la liaison 144 de données. Ces données saisies peuvent concerner des tâches spécifiques entreprises par l'utilisateur, par exemple lorsque celui-ci procède à une tâche de maintenance afin de supprimer une anomalie sur un aéronef dans lequel est présent le système 100. L'OMS peut également collecter et mémoriser la totalité des données de configuration pour l'aéronef. Cela permet au système de déterminer ce qui a changé et à quel moment, ce qui peut être essentiel pour créer un système de commande asservie. Le module de saisie 142 de données de tâches de maintenance peut saisir une liste de telles tâches détaillant les tâches dont il s'agissait et l'ordre chronologique dans lequel elles ont été effectuées. Une telle liste peut ensuite, par exemple, être mémorisée ou enregistrée localement ou à distance dans un moyen de stockage temporaire et/ou permanent tel qu'une mémoire électronique, sur un disque dur, etc. L'analyse d'une telle liste peut ensuite servir à actualiser des modes opératoires de maintenance. Le module de stockage 120 de manuels de maintenance coopère avec le bus 150 de données sur les systèmes de l'aéronef par l'intermédiaire de la liaison 122 de données de manière à fournir des informations de maintenance à un technicien lorsque l'aéronef est au sol et se trouve en mode maintenance. Eventuellement, ces informations peuvent être fournies au technicien par l'intermédiaire du module d'interface E/S 140 via une liaison 126 de données qui connecte le module de stockage 120 de manuels de maintenance au bus 150 de données sur les systèmes de l'aéronef. Selon une autre possibilité, les modes opératoires de recherche de pannes prédéterminés stockés dans le module de stockage 120 de manuels de maintenance peuvent être actualisés afin d'inclure des modes opératoires de recherche de pannes identifiés ultérieurement, ou non prédéterminés pour des corrections d'anomalies transmises au module de stockage 120 de manuels de maintenance par le module d'analyse 106 de données via l'éventuelle liaison 108 de données. De tels modes opératoires de recherche de pannes non prédéterminés pour la correction d'anomalies peuvent être stockés pour être ultérieurement consultés par le personnel compétent afin de vérifier leur efficacité et leur sûreté et/ou de contribuer à identifier des défauts systémiques dans l'aéronef ou le type d'aéronef. A titre d'exemple nullement limitatif, une erreur dans un module de détection d'amorçage d'arc peut amener le module d'analyse 106 de données à commencer à enregistrer un mode opératoire réel de maintenance en réponse à la communication d'un code d'anomalie (FAULT_CODE_ID) par le module d'archivage 104 de données au module d'analyse 106 de données. Ainsi, le code d'anomalie identifie le problème spécifique et peut être désigné par un identifiant exclusif UID (par exemple, FAULT_CODE_ID = AE7 peut indiquer une anomalie avec un module de détection spécifique d'amorçage d'arc situé à un emplacement connu dans l'aéronef). Les actions du mode opératoire spécifique réel de maintenance prises pour corriger l'anomalie peuvent alors être enregistrées en sollicitant un technicien de maintenance à l'aide du module d'interface E/S 140 afin qu'il choisisse diverses actions sur une liste déroulante. Ces actions peuvent, par exemple, être enregistrées sous la forme d'un tableau ou d'une liste. FAULT CODE ID = AE7 servant de référence ou d'indicateur, les actions du mode opératoire spécifique réel de maintenance prises peuvent être les suivantes : Tableau 1 UID Action Anomalie D'ACTION corrigée au terme de l'action ? 1 E Contrôler les NON pôles d'alimentation électrique 2A Contrôler les NON connexions des inductances 24 Remplacer le NON condensateur Cl 9B Remplacer le OUI condensateur C2 Un mode opératoire de maintenance prédéterminé pour le code d'anomalie AE7 peut alors être obtenu par le module d'acquisition 102 de données à partir du module de stockage 120 de manuels de maintenance. Ce mode opératoire de maintenance prédéterminé peut également se présenter sous la forme d'une liste ou encore d'un tableau et est fourni au module d'analyse 106 de données par l'intermédiaire de la liaison 112 de données. Le mode opératoire de maintenance prédéterminé peut, par exemple, être le suivant : Tableau 2 UID Action D'ACTION 1 E Contrôler les pôles d'alimentation électrique 2A Contrôler les connexions des inductances 9B Remplacer le condensateur C2 41 Remplacer l'inductance L2 24 Remplacer le condensateur C 1 Un test de corrélation peut alors être effectué par le module 15 d'analyse 106 de données afin d'identifier des modes opératoires de recherche de pannes non prédéterminés pour la correction d'anomalies. Par exemple, le module d'analyse 106 de données peut comparer ligne par ligne le contenu du tableau pour vérifier si les mêmes codes d'actions apparaissent vraiment ou apparaissent dans le même ordre, avec ou sans étapes intermédiaires. On peut également recourir à d'autres techniques de corrélation possibles, dont, par exemple, l'appariement statistique. Une telle actualisation peut également reposer sur les étapes qui règlent effectivement un problème spécifique. Cela peut être déterminé d'après une combinaison d'étapes figurant dans le manuel de maintenance, les données de configuration montrant ce qui a changé, à quel moment, et les données d'anomalies/de paramètres indiquant le moment où l'anomalie a réellement été résolue. Dans la présente forme de réalisation est utilisé un algorithme de comparaison de tableaux. Cet algorithme confirme que toutes les actions réellement effectuées (à savoir les UID 1E, 2A, 24 et 9B) figurent dans le mode opératoire de recherche de pannes prédéterminé stocké dans le module de stockage 120 de manuels de maintenance. Cependant, l'algorithme de comparaison de tableaux révèle que le mode opératoire de recherche de pannes prédéterminé implique davantage d'étapes que le mode opératoire de recherche de pannes réel utilisé, et que deux des étapes (à savoir les UID 24 et 9B) ont été utilisées dans un ordre différent par le technicien de maintenance. Ces deux identifiants indiquent qu'un mode opératoire de recherche de pannes non prédéterminé a été trouvé, puis le tableau de données correspondant aux actions réelles effectuées, ainsi que leurs UID de codes d'anomalies sont mémorisés. Dans la présente forme de réalisation, le module d'analyse 106 de données sert en outre à mettre automatiquement à jour le manuel de maintenance stocké dans le module de stockage 120 de manuels de maintenance. Une opération d'écriture de données est effectuée par le module d'analyse 106 de données avec un enregistrement des nouvelles données sous le format . FAULT_CODE_UID; ACTION_1_UID; ACTION_ _ 2UID; ACTION_lastnumber_UID; END_ RECORD. Par exemple, un enregistrement de nouvelles données "AE7; 1E; 2A; 24; 9B; END_RECORD" peut être inscrit par le module d'analyse 106 de données dans le module de stockage 120 de manuels de maintenance par l'intermédiaire de la liaison 108 de données afin que le module de stockage 120 de manuels de maintenance soit mis à jour afin d'inclure un nouveau mode opératoire de maintenance correspondant au mode opératoire de recherche de pannes non prédéterminé identifié. Ce nouveau mode opératoire de maintenance peut ensuite devenir un mode opératoire de recherche de pannes prédéterminé pour de futures analyses. Dans diverses formes de réalisation, des données peuvent être recueillies dans de nombreux aéronefs et à l'occasion de nombreux événements et une comparaison des solutions utilisées et des résultats obtenus peut être effectuée. Une telle combinaison de multiples sources et événements permet une analyse statistique. Une autre option consiste à étudier l'historique pour un aéronef donné afin de trouver quel ensemble particulier de modes opératoires de maintenance a résolu le problème, dont l'option consistant en un suivi de la configuration/des références des pièces remplacées. Diverses techniques de recherche de pannes peuvent être mises en oeuvre, par exemple, en recourant soit à une approche simple à arborescence logique/tableau dans laquelle la structure de l'arborescence/du tableau est actualisée, soit une approche à modélisation graphique probabiliste. Par exemple, dans diverses formes de réalisation, un raisonnement bayésien est employé et les pondérations des probabilités sont actualisées. La figure 2 représente un schéma 200 d'architecture fonctionnelle de niveau élevé d'un système de maintenance embarqué (OMS) selon diverses formes de réalisation de la présente invention. La limite 202 du système OMS est représentée par un contour pointillé. L'OMS comprend un concentrateur Wi-Fi 204 sous la forme d'un équipement remplaçable en escale (LRU) connecté à un réseau 206 de systèmes au sol. Le réseau 206 de systèmes au sol se présente sous la forme d'une interface homme machine (HMI). Le concentrateur Wi-Fi 204 est en outre connecté à un dispositif extérieur portatif de maintenance 280 et à un gestionnaire 208 de communications de maintenance. Le dispositif extérieur portatif de maintenance 280 peut également se présenter sous la forme d'une HMI. Dans diverses formes de réalisation, le gestionnaire 208 de communications de maintenance est assuré par un module logiciel reposant sur une unité de surveillance globale d'aéronef (AHMU). Le gestionnaire 208 de communications de maintenance coopère également avec une application extérieure 234 de gestion de communications. L'application 234 de gestion de communications peut être assurée par un module logiciel de plate-forme de systèmes électroniques avioniques (ESP). L'application 234 de gestion de communications gère la transmission de données sur diverses liaisons externes de données. Par exemple, des données peuvent être formatées pour utiliser un protocole de communications à système ACARS de communications codées entre un aéronef et une station au sol, ou un protocole de communications à système Iridium® lorsque la transmission de données s'effectue via des équipements radio de liaison de données 230 avec lesquels coopère l'application 234 de gestion de communications. Les équipements radio de liaison de données 230 peuvent également servir à fournir des informations au réseau 206 de systèmes au sol et à recevoir des informations de ce dernier et, dans diverses formes de réalisation, se présente de préférence sous la forme de LRU. Le gestionnaire 208 de communications de maintenance coopère avec un serveur 210 d'accès aux données, de manière à la fois directe et indirecte par l'intermédiaire d'une application html 214 d'affichage de maintenance. Le serveur 210 d'accès aux données et l'application html 214 d'affichage de maintenance peuvent l'un et l'autre être mis en oeuvre sous la forme de modules logiciels AHMU. L'application html 214 d'affichage de maintenance sert également à provoquer l'affichage d'informations concernant les manuels de maintenance de l'aéronef, par exemple sur le dispositif extérieur portatif de maintenance 280 lorsque celui-ci est connecté activement au concentrateur Wi-Fi 204. Le serveur 210 d'accès aux données coopère également avec un moyen de stockage 212 de données. Le moyen de stockage 212 de données peut être constitué à l'aide d'un module logiciel AHMU, par exemple en utilisant un moyen de stockage électronique de données à base de mémoire vive, de disque dur ou de mémoire flash. Le serveur 210 d'accès aux données est en outre connecté à une application 228 d'affichage de maintenance à norme ARINC® 661 d'interface de sous-système de visualisation (A661), qui est conçue pour fournir à divers écrans d'affichage 212 de l'aéronef des informations d'affichage de maintenance, dont celles extraites de manuels de maintenance. Le gestionnaire 210 d'accès aux données et le gestionnaire 208 de communications de maintenance coopèrent l'un et l'autre avec la fonction 216 de surveillance d'état de l'aéronef (ACMF). La fonction ACMF 216 peut être assurée à l'aide d'un module logiciel AHMU et peut comprendre un enregistreur à accès rapide (QAR). Ce module logiciel permet d'analyser des données paramétriques afin de déterminer l'état global de systèmes embarqués et est distinct du CMS qui permet d'analyser les données de test intégré BIT de l'aéronef. Le serveur 210 d'accès aux données coopère avec le gestionnaire 222 d'état global de l'aéronef assuré par un autre module logiciel AHMU. En outre, le serveur 210 d'accès aux données est connecté au gestionnaire 218 de configuration d'aéronef, au gestionnaire 220 de charge de données et au système central de maintenance CMS 224. Le CMS 224 sert à analyser les BIT (informations binaires logiques sur l'état global) fournies par les systèmes membres. Le gestionnaire 218 de configuration d'aéronef, le gestionnaire 220 de charge de données et le CMS 224 sont assurés par des modules logiciels avioniques respectifs d'ESP et le CMS 224 coopère avec le gestionnaire 222 d'état global de l'aéronef et présente en outre un gestionnaire MSHM d'état global des systèmes membres. Le système OMS comprend un module de répartition 226 de charge de données sous la forme d'un module logiciel avionique ESP. Le module de répartition 226 de charge de données connecte le gestionnaire 220 de charge de données à des applications 240 hébergées par l'ESP avionique et à des LRU 242 connectés à l'ESP avionique. Les applications 240 hébergées par l'ESP avionique et les LRU 242 connectés à l'ESP avionique sont en outre connectées au gestionnaire 218 de configuration d'aéronef par l'intermédiaire du gestionnaire 236 de configuration d'ESP qui est lui-même assuré par un autre module logiciel ESP avionique. Le CMS 224 et l'ACMF 216 sont en outre connectés à la fois à des écrans d'affichage 238 de l'aéronef et à un moniteur 244 d'état global d'ESP avionique. Le module de répartition 226 de charge de données connecte le gestionnaire 220 de charge de données aux applications 240 hébergées par l'ESP avionique et aux LRU connectés à l'ESP avionique. Les applications 240 hébergées dans l'ESP avionique et les LRU 242 connectés à l'ESP avionique sont en outre connectées au gestionnaire 218 de configuration d'aéronef par l'intermédiaire du gestionnaire de configuration 236 d'ESP qui est lui-même assuré par un autre module logiciel d'ESP avionique. Le CMS 224 et l'ACMF 216 sont en outre connectés à la fois aux écrans d'affichage 238 de l'aéronef et à un contrôleur 244 d'état global à ESP avionique. Les écrans d'affichage 238 de l'aéronef peuvent se présenter sous la forme de LRU (par exemple, un système de prévision d'effet sur le poste de pilotage/d'alerte d'équipage (FDE/CAS) pour indiquer le moment où une défaillance est suffisamment importante pour la préservation de la sécurité du vol pour qu'un avertissement/une alerte se déclenche dans le cockpit), et le contrôleur 244 d'état global à ESP avionique peut être assuré à l'aide d'un module logiciel d'ESP avionique supplémentaire. La figure 3 représente un système de maintenance embarqué 300 selon une autre forme de réalisation de la présente invention. L'OMS 300 peut, par exemple, servir à mettre en oeuvre diverses formes de réalisation qui utilisent l'architecture illustrée sur la figure 2. L'OMS 300 comprend des enregistreurs de vol perfectionnés embarqués (EAFR) 301 en double. Ceux-ci peuvent être conformes aux normes ARINC 767 et ED-112 et peuvent enregistrer des données de vol et des conversations et, éventuellement, des images. Une armoire 302 d'avionique modulaire intégrée (IMA) et une AHMU 303 sont également présentes. Les EAFR 301, l'armoire d'IMA 302 et l'AHMU 303 sont connectés par des réseaux doubles conformes à la norme ARINC® 664P7. Les EAFR 301 servent à enregistrer des signaux d'entrée générés par un utilisateur dans le cockpit. Les signaux d'entrée générés par l'utilisateur peuvent se présenter sous la forme de signaux vocaux grâce à des microphones d'équipage connectés aux EAFR 301 par l'intermédiaire de tableaux de commande audio 351 ou par l'intermédiaire d'un microphone d'ambiance 352 connecté par l'intermédiaire d'un pré-amplificateur 353. D'autres signaux générés par l'utilisateur comme, par exemple, des signaux générés par le commutateur de test audio (par exemple, le test en boucle IBIT) et des signaux générés par le commutateur d'effacement peuvent également être fournis par l'intermédiaire d'un tableau de commande 354 d'enregistreur de conversations dans le cockpit (CVR), connecté aux EAFR 301. Les EAFR 301 peuvent être connectés à un dispositif de maintenance portatif (PMD) 379 par l'intermédiaire d'une connexion Ethernet 306 et d'une prise femelle RJ45 classique 305. Le PMD 379 peut être utilisé dans le cockpit par un technicien de maintenance pour analyser des anomalies de l'aéronef et accéder à des informations concernant des étapes requises pour exécuter divers modes opératoires de maintenance prédéterminés. Ces données peuvent être extraites de la mémoire de l'OMS, par exemple en utilisant le PMD 379 connecté par voie radioélectrique aux écrans d'affichage de l'OMS et du cockpit. L'armoire 302 d'IMA présente un module de CMS, un module de mémoire rémanente (NVM) et un module de gestionnaire de charge de données. Un module d'affichage 317, un module 321 d'impression de données, un module 326 de gestionnaire de communications et un module 318 de données de réception/émission (RX/TX) sont également présents dans l'armoire 302 d'IMA. Les divers modules décrits ici peuvent, par exemple, être mis en oeuvre à l'aide d'un ou de plusieurs éléments matériels, logiciels et de microprogrammes selon diverses formes de réalisation de la présente invention. Le module de CMS sert à créer et envoyer une demande 311 de mode réglage tout en exécutant une opération de contrôle de dépassement de délai 312. Une opération 316 sur des résultats de BIT de cumul d'anomalies et de constat de manque est également exécutée par le module de CMS. En outre, le module de CMS procède à une adaptation 315 de calendrier et à une analyse 314 d'arborescence d'anomalies de CMS pour permettre que des demandes de lancement de tests intégrés (IBIT) soient créées et envoyées 313 par l'intermédiaire du module 318 de données de RX/TX. Cela permet au CMS d'envoyer une instruction à un système membre pour lancer un test. Le module NVM sert à fournir un ensemble de règles de communications 320 au module 326 de gestionnaire de communications. Le module NVM applique également un modèle de CMS 319 dont les résultats sont produits pour définir une arborescence d'anomalies de CMS servant lors de l'analyse 314 d'arborescence d'anomalies de CMS. Le module 318 de données de RX/TX présente une interface entre l'armoire 302 d'IMA et les réseaux doubles 349 conformes à la norme ARINC® 664P7. Les données de dépassement de délai peuvent être fournies via les réseaux 349 pour établir la durée des délais de l'opération 312 de contrôle de dépassement de délai. Une communication bidirectionnelle de données est assurée par le module 318 de données de RX/TX entre le module de CMS, le gestionnaire 326 de communications, le module de gestionnaire de charge de données et le module 321 d'impression de données. En outre, le module 318 de données de RX/TX est couplé au module de CMS et au module de gestionnaire de charge de données par l'intermédiaire du module d'affichage 317. Le module de gestionnaire de charge de données comprend un premier module 322 servant à recevoir, du module 318 de données de RX/TX, des données d'état de charge et de configuration. Un deuxième module 325 sert à demander, à un logiciel à charger en situation réelle (FLS), des données extraites d'une mémoire de données de FLS et à fournir ces données à un troisième module 323 qui sert à présenter ensuite des détails à un technicien de maintenance par l'intermédiaire du module d'affichage 317. Le FLS est un logiciel qui peut être installé dans l'aéronef puis chargé, par l'intermédiaire de la fonction de charge de données, sur les systèmes membres. Un quatrième module 324 connecte le module d'affichage 317 et le deuxième module 325 au module 318 de données de RX/TX. Le quatrième module 324 sert à envoyer des données du FLS à divers systèmes membres, notamment divers systèmes avioniques de l'aéronef comme l'OMS, les commandes de vol, le groupe auxiliaire, les moteurs, le système de conditionnement d'air, les écrans d'affichage dans le cockpit, etc. L'AHMU 303 se connecte au système de maintenance embarqué 300 par l'intermédiaire d'un module 348 de données de RX/TX qui coopère avec les doubles réseaux 349 conformes à la norme ARINC® 664P7. L'AHMU 303 comprend également un module 339 d'accès à la charge de données, un module d'ACMF, un module NVM, un module de serveur interne d'accès aux données, un module de stockage de données et un module de serveur externe d'accès aux données. Le module de serveur externe d'accès aux données est couplé à un module 327 de données Ethernet de RX/TX qui comprend une fonction de gestionnaire de communications. Le module de serveur externe d'accès aux données sert à exécuter un processus 330 de connexion d'utilisateur et à enregistrer des tentatives d'accès 331. Un module 332 de gestion de données de téléchargement est également assuré par le module de serveur externe d'accès aux données pour permettre la transmission de données du module de stockage de données au module 327 de données Ethernet de RX/TX. Le module de FLS 328 est prévu pour permettre que des données FLS reçues par le module de serveur externe d'accès aux données soient ajoutées dans une zone de stockage 334 de FLS présente dans le module de stockage de données. Le module de stockage de données comprend également une zone de stockage 335 de données QAR d'une carte mémoire SDCard, une zone 336 de données complètes stockées et une zone 337 de stockage de manuels de recherche de pannes (TS). Une telle zone de stockage de données peut permettre de ne pas avoir à stocker tous les manuels à bord de l'aéronef, mais uniquement ceux nécessaires à la recherche de pannes. Un module d'accès 338 à une mémoire de données crée une interface entre le module de stockage de données et le module 348 de données de RX/TX. Le module d'accès 338 à une mémoire de données, le module de stockage de données et le module de serveur externe d'accès aux données sont tous connectés à un module d'affichage 333 qui est en outre connecté au module 327 de données Ethernet de RX/TX. Le module d'affichage 333 peut fournir des données, par exemple, à l'aide d'un format html pour faciliter la consultation. Le module 339 d'accès à la charge de données sert à extraire des données FLS de la zone de stockage de FLS 334 du module de stockage de données et à les fournir au module 348 de données de RX/TX lorsque le module 348 de données de RX/TX le lui demande. Le module NVM est connecté au module 348 de données de RX/TX et produit une liste 342 de saisie de données analytiques d'ACMF. Le module NVM présente une zone de stockage permanent pour la liste 342. Le module NVM applique également un modèle AMH 343. La liste 342 de saisie de données analytiques d'ACMF est fournie au module d'ACMF qui sert à analyser 380 ces données. Le module d'ACMF peut recevoir une instruction du module 348 de données de RX/TX afin de déterminer quelles données il faut stocker 340 et quel module de stockage 341 doit être activé pour commencer le stockage des données analysées appropriées dans la zone de stockage 335 de données QAR de carte mémoire SDCard et dans la zone 336 de données complètes stockées du module de stockage de données. Un premier module de raisonnement 344 de gestionnaire d'état global d'aéronef (AHM), couplé au module 348 de données de RX/TX, analyse les données dans la zone 336 de données complètes stockées et la sortie du modèle AMH 343 et actualise la zone 336 de données complètes stockées avec ses constatations. Cela peut faire partie du CMS et permet de créer des capacités supplémentaires d'isolation d'anomalies en plus de celles de la logique d'anomalies pure dans le CMS. Le modèle 343 d'AMH peut être réalisé à l'aide d'une modélisation graphique probabiliste (par exemple à l'aide d'un raisonnement bayésien). Le gestionnaire de configuration 345 obtient, du module 348 de données de RX/TX, des données de configuration du système et fournit celles-ci au module de stockage de données pour qu'elles soient incluses dans la zone complète 336 de données stockées. Le serveur interne d'accès aux données est connecté au module de stockage de données et au module 348 de données de RX/TX et comprend un premier module 346 servant à extraire des données stockées de la zone 336 de données complètes stockées, et un deuxième module 347 servant à extraire des manuels de maintenance de la zone de stockage 337 de manuels de recherche de pannes TS. L'OMS 300 comprend un dispositif 355 de commande de curseur (CCD) connecté à un écran d'affichage multifonction 357 (MFD) par l'intermédiaire d'un réseau 356 conforme à ARINC® 664P7. Le MFD 357 est également connecté aux doubles réseaux 349 conformes à ARINC® 664P7, tout comme l'enceinte acoustique 358 du système d'alerte d'équipage (CAS), un serveur 307 d'imprimante et divers LRU 372 connectés suivant ARINC® 664P7. Une unité distante d'interface de données (RDIU) 308 connecte des radios 310 de liaison de données à bord de l'aéronef aux doubles réseaux 349 conformes à ARINC® 664P7 par l'intermédiaire d'un bus ARINC 429 309. Un émetteur/récepteur 377 au sol sert à recevoir les signaux émis par les radios de liaison de données 310 et à les transmettre au réseau d'appui au sol (GSM) 374 au moyen d'une liaison Internet. Le GSM 374 peut présenter un référentiel central pour données, dans lequel l'analyse peut être effectuée sur toute la flotte avec une mise à jour ultérieure des modes opératoires de recherche de pannes qui sont ensuite chargés dans un FLS et redistribués aux aéronefs. Une autre liaison Internet relie le GSM 374 à l'émetteur/récepteur 375 qui est couplé par voie radioélectrique à un émetteur/récepteur GSM Wi-Fi 376. L'émetteur/récepteur GSM Wi-Fi 376 peut se connecter par voie radioélectrique à un PMD 378 auquel accède un technicien de maintenance au sol. L'émetteur/récepteur GSM Wi-Fi 376 coopère en outre avec un réseau Ethernet 373 qui est lui-même en liaison en retour avec le module 327 de données Ethernet de RX/TX de l'AHMU 303. Eventuellement, le PMD 378 peut également être en liaison avec le réseau Ethernet 373. Divers éléments supplémentaires peuvent être connectés aux doubles réseaux 349 conformes à ARINC® 664P7. A titre d'exemple, deux de ces sous-systèmes sont représentés, sur la figure 3, connectés aux doubles réseaux 349 conformes à ARINC® 664P7, respectivement par l'intermédiaire de RDIU 361 et RDIU 367. RDIU 361 est en outre connecté à la touche 359 d'événements, à divers capteurs discrets et analogiques 360, à un bus 362 à norme ARINC® 825 et à un bus 363 à norme ARINC® 429. Divers LRU 364 à norme ARINC® 825 sont connectés au bus 362 et divers LRU 365 à norme ARINC® 429 sont connectés au bus 363. RDIU 367 est en outre connecté à divers capteurs discrets et analogiques 366, à un bus 368 à norme ARINC® 825 et à un bus 369 à norme ARINC® 429. Divers LRU 370 à norme ARINC® 825 sont connectés au bus 368 et divers LRU 371 à norme ARINC® 429 sont connectés au bus 369. Dans diverses formes de réalisation, une pluralité d'aéronefs peuvent se connecter à l'émetteur/récepteur 377 au sol, par exemple par l'intermédiaire de radios respectives de liaison de données et/ou de modules de données Ethernet de RX/TX. Les données de nombreux aéronefs peuvent ainsi être recueillies, analysées et interprétées afin d'identifier des modes opératoires de recherche de pannes non prédéterminés pour la correction d'anomalies. Cela peut se faire automatiquement, les résultats étant éventuellement diffusés aux divers aéronefs connectés à l'OMS 300, par exemple afin de permettre une mise à jour de manuels de maintenance embarqués respectifs. La figure 4 illustre un procédé 400 pour analyser automatiquement des données de systèmes d'aéronef selon diverses formes de réalisation de la présente invention. Le procédé 400 comprend les étapes d'acquisition 402 de données des systèmes d'aéronef, de stockage 404 des données des systèmes d'aéronef et d'analyse 406 des données des systèmes d'aéronef afin d'identifier des modes opératoires de recherche de pannes non prédéterminés pour la correction d'anomalies. Certaines des étapes 402, 404, 406 peuvent être réalisées par certains des modules évoqués plus haut. L'étape d'acquisition 402 de données des systèmes d'aéronef peut comprendre l'acquisition des données des systèmes d'aéronef à partir d'une pluralité d'aéronefs. Le procédé 400 peut comporter en outre une étape d'accès à un module de stockage de manuels de maintenance afin d'identifier des modes opératoires de recherche de pannes prédéterminés. Eventuellement, une mise à jour automatique d'un manuel de maintenance peut également être incluse de façon à comprendre des modes opératoires de maintenance correspondant aux modes opératoires de recherche de pannes non prédéterminés identifiés. Ainsi, les manuels et les modes opératoires de maintenance peuvent être mis à jour automatiquement au fil du temps. Le procédé 400 peut comporter en outre des étapes d'acquisition et/ou d'enregistrement et/ou d'identification d'au moins une étape de maintenance réelle entreprise pendant un mode opératoire de maintenance. Cette étape/ces étapes peut/peuvent être obtenue(s) successivement et les modes opératoires de recherche de pannes non prédéterminés pour la correction d'anomalies peuvent être identifiés en analysant la suite d'étapes saisie. Un programme informatique contenant des instructions machine pour configurer un dispositif de traitement de données afin de mettre en oeuvre une ou plusieurs étapes du procédé 400 peut également être prévu. Un tel programme peut servir à réaliser divers modules dans un ou plusieurs dispositifs de traitement de données afin d'exécuter diverses fonctions nécessaires pour mettre en oeuvre le procédé. Sans limitation, un tel programme informatique peut servir à améliorer un matériel ou un microprogramme existant (comme, par exemple, un système interne de gestion d'état global (IHMS) d'aéronef), de manière à doter un aéronef selon la technique antérieure d'outils diagnostiques et/ou de modes opératoires de maintenance améliorés. Les spécialistes de la technique comprendront que diverses techniques peuvent être utilisées pour analyser les données des systèmes d'aéronef afin d'identifier des modes opératoires de recherche de pannes non prédéterminés pour la correction d'anomalies. Par exemple, il est possible d'utiliser diverses techniques d'analyse statistique, d'heuristique automatisée, de filtrage et/ou de recherche, etc. Ces données peuvent être stockées d'une manière temporaire ou permanente, par exemple dans un module de stockage à bord d'un ou de plusieurs aéronefs et/ou dans une base de données centrale accessible à de nombreux systèmes embarqués. Dans certaines formes de réalisation, une analyse de données peut ainsi servir à l'exécution de diagnostics. Divers systèmes d'asservissement peuvent être présents, à la différence de systèmes antérieurs "à circuit ouvert" dans lesquels il n'y a ni analyse ni rétroaction. Ainsi, diverses formes de réalisation peuvent être utilisées pour simplifier le processus de maintenance, ce qui réduit donc la durée de la maintenance. Un avantage de diverses formes de réalisation est qu'elles peuvent également permettre l'identification de problèmes et la mise en oeuvre de solutions pour des problèmes qui, sinon, passeraient inaperçus. Par exemple, l'expérience technique globale peut être analysée pour identifier des événements éventuellement rares qu'un technicien individuel risquerait de ne pas pouvoir corriger/diagnostiquer en recourant à son expérience personnelle. Dans diverses formes de réalisation, des actions pourraient être pondérées pour divers types d'analyse de données des systèmes. Par exemple, une action indiquant qu'un technicien a remplacé un moteur entier pourrait faire l'objet d'une note de pondération basse, ce qui est relativement non souhaitable, tandis que le remplacement d'un joint d'étanchéité spécifique pourrait faire l'objet d'une note élevée, car l'identification de pièces spécifiques provoquant un problème spécifique est évidemment plus souhaitable que l'identification d'une solution globale. Ainsi, une pondération au niveau d'une pièce peut être élevée ; une pondération au niveau d'un module/de LRU peut être moyenne (ou faible si le problème spécifique est déjà connu comme étant lié à ce module, par exemple si une panne de module de détection d'amorçage d'arc peut donner une note de pondération relativement basse pour une action indiquant un remplacement du module de détection d'amorçage d'arc en comparaison, disons, du remplacement d'un détecteur de courant spécifique dans le module de détection d'amorçage d'arc) ; et une pondération au niveau d'un système peut être basse. Des séries respectives d'étapes peuvent être exécutées pour une analyse dans l'ordre, par exemple au moyen d'une analyse du type recherche "proche". Une modélisation de systèmes, par exemple à l'aide de techniques à base de règles, à moteur physique, à raisonnement neuronal, etc. peuvent être employées pour constituer un mécanisme de rétroaction afin de créer un système d'asservissement tel que des modes opératoires prédéterminés initiaux peuvent être complétés par des modes opératoires et/ou des processus de maintenance non prédéterminés, déterminés d'une manière automatique. En outre, une saisie de données peut être assurée dans diverses formes de réalisation du système à partir d'un module de compte rendu pour pilote (PDM) qui saisit les données d'anomalies techniques enregistrées par le/les pilotes. Divers aspects et formes de réalisation de la présente invention peuvent être mis en oeuvre à l'aide d'un outil ou de plusieurs outils à fonctionnement logiciel pour produire un ou plusieurs modules dans un ou plusieurs dispositifs de traitement de données. Cet outil, ou ces outils, peuvent être mis en réseau et peuvent en outre être en liaison avec un système de maintenance embarqué (OMS). Diverses formes de réalisation peuvent également être en liaison avec un ou plusieurs systèmes d'enregistrement de vol (FRS) connus, par exemple à l'aide d'une ou de plusieurs plates-formes de systèmes électroniques (ESP). Dans diverses formes de réalisation, un manuel est constitué sous la forme d'un ensemble d'étapes prédéterminées reposant sur des hypothèses de probabilités et de successions d'anomalies au moment de la construction d'un aéronef. Les manuels peuvent se présenter sous la forme d'un modèle actualisable, les étapes des modes opératoires pouvant être réordonnées et/ou les probabilités d'anomalies données et les coûts associés à leur identification étant actualisés d'après l'expérience pratique. Cette mise en oeuvre peut se faire à l'aide d'une démarche par arborescence/tableau d'anomalies pour des décisions binaires lorsque la structure de cette arborescence/ce tableau est mise à jour pour tenir compte de l'analyse statistique de l'expérience pratique. Selon une autre possibilité, un modèle probabiliste peut être construit lorsque la structure et les pondérations du modèle peuvent être actualisées. Cela permet donc le choix d'une solution optimale d'après l'expérience en cours. Ces probabilités et coûts peuvent être actualisés à partir d'une analyse statistique des données de la flotte dont, le cas échéant, des caractéristiques de fonctionnement, par exemple lorsqu'un aéronef spécifique effectue toujours de courts trajets ou vole dans un environnement chaud et sec. REVENDICATIONS1. Système (100) pour analyser automatiquement des données de systèmes d'aéronef, comportant : un module d'acquisition (102) de données servant à acquérir des données sur les systèmes d'aéronef ; un module d'archivage (104) de données servant à stocker des données sur les systèmes d'aéronef ; et un module d'analyse (106) de données servant à analyser les données sur les systèmes d'aéronef afin d'identifier des modes opératoires de recherche de pannes non prédéterminés pour la correction d'anomalies. 2. Système (100) selon la revendication 1, dans lequel le module d'acquisition (102) de données sert en outre à acquérir les données sur systèmes d'aéronef à partir d'une pluralité d'aéronefs. 3. Système (100) selon l'une quelconque des revendications précédentes, dans lequel le module d'archivage (104) de données sert en outre à accéder à un module de stockage (120) de manuels de maintenance afin d'identifier des modes opératoires de recherche de pannes prédéterminés. 4. Système (100) selon la revendication 3, dans lequel le module d'analyse (106) de données sert en outre à mettre automatiquement à jour un manuel de maintenance stocké dans le module de stockage (120) de manuels de maintenance afin qu'il comprenne des modes opératoires de maintenance correspondant aux modes opératoires de recherche de pannes non prédéterminés identifiés. 5. Système (100) selon l'une quelconque des revendications précédentes, comportant en outre un module de saisie (142) de données de tâches de maintenance servant à saisir au moins une étape réelle de maintenance entreprise dans le cadre d'un mode opératoire de maintenance. 6. Système (100) selon la revendication 5, dans lequel le module de saisie (142) de données de tâches de maintenance sert en outre à saisir les étapes dans un ordre. 7. Système (100) selon la revendication 6, dans lequel le module d'analyse (106) de données sert à identifier les modes opératoires de recherche de pannes non prédéterminés pour corriger des anomalies en analysant la suite d'étapes saisie. 8. Procédé (400) pour analyser automatiquement des données sur des systèmes d'aéronef, comportant les étapes de : acquisition (402) de données sur des systèmes d'aéronef ; stockage (404) des données sur les systèmes d'aéronef ; et analyse (406) des données sur les systèmes d'aéronef afin d'identifier des modes opératoires de recherche de pannes non prédéterminés pour corriger des anomalies. 9. Procédé (400) selon la revendication 8, dans lequel l'acquisition (402) de données sur des systèmes d'aéronef comprend l'acquisition des données sur des systèmes d'aéronef à partir d'une pluralité d'aéronefs. 10. Procédé (400) selon la revendication 8 ou la revendication 9, comportant en outre l'étape d'accès à un module de stockage (120) de manuels de maintenance afin d'identifier des modes opératoires de recherche de pannes prédéterminés. 11. Procédé (400) selon la revendication 10, comportant en outre la mise à jour automatique d'un manuel de maintenance stocké dans le module de stockage (120) de manuels de maintenance de façon qu'il comprenne des modes opératoires de maintenance correspondant aux modes opératoires de recherche de pannes non prédéterminés identifiés. 12. Procédé (400) selon l'une quelconque des revendications 8 à 11, comportant en outre l'enregistrement d'au moins une étape de maintenance réelle entreprise pendant un mode opératoire de maintenance. 13. Procédé (400) selon l'une quelconque des revendications 8 à 12, comportant l'identification d'une suite composée d'une pluralité d'étapes. 14. Procédé (400) selon l'une quelconque des revendications 8 à 13, comportant l'identification des modes opératoires de recherche de pannes non prédéterminés pour corriger des anomalies en analysant une suite d'étapes saisie ou enregistrée. 15. Programme informatique contenant des instructions machine pour configurer un dispositif de traitement de données afin de mettre en oeuvre le procédé (400) selon l'une quelconque des revendications 8 à 14. 16. Système (100) pour analyser automatiquement des données sur des systèmes d'aéronef sensiblement comme décrit précédemment en référence aux dessins annexés. 17. Procédé (400) pour analyser automatiquement des données sur des systèmes d'aéronef sensiblement comme décrit plus haut en référence aux dessins annexés.