FR 3001556 A1 20140801 FR 1350675 A 20130125 La présente invention concerne les procédures de maintenance de calculateurs avioniques dans des aéronefs pour identifier les équipements à la source de pannes détectées en vol et plus particulièrement un procédé, un dispositif et un programme d'ordinateur d'aide à la maintenance d'un système d'un aéronef utilisant un outil d'aide au diagnostic et des données de retour d'expérience. Il est tout d'abord rappelé qu'il existe plusieurs types d'opérations de maintenance dans les aéronefs. Parmi ceux-ci, les opérations de maintenance non planifiée sont mises en oeuvre lorsque des pannes d'équipements sont détectées durant un vol. Outre la confirmation des pannes détectées, les opérations de maintenance non planifiée ont notamment pour objet de déterminer la cause de ces pannes afin d'effectuer une procédure de maintenance correspondante. De telles opérations de maintenance sont effectuées par des opérateurs de maintenance lorsque l'aéronef est au sol. Elles sont généralement basées sur des informations issues de rapports de vol (appelés logbook en terminologie anglo-saxonne), des alertes ECAM (acronyme d'Electronic Centralized Aircraft Monitoring en terminologie anglo-saxonne) et des messages BITE (acronyme de Built-In Test Equipment en terminologie anglo-saxonne). Il est également rappelé que de fortes contraintes, telles que des contraintes de temps (attente des passagers, coûts d'immobilisation de l'aéronef), de conditions de travail (climat, nuit/jour) et des contraintes liées au type d'aéronefs et à la complexité des procédures de maintenance, sont associées à ces procédures de maintenance. Il est donc nécessaire d'aider les opérateurs dans leur travail en évitant les procédures inutiles et en optimisant leur ordonnancement. Les aéronefs modernes disposent généralement d'un système de surveillance des équipements pour détecter, en vol, des défaillances et effectuer un premier niveau de diagnostic. A ces fins, un système central de maintenance, par exemple un système de type CMS (sigle de Centralized Maintenance System en terminologie anglo-saxonne) reçoit des messages et établit un diagnostic. Les messages reçus et analysés sont par exemple les suivants : - messages de type BITE en provenance d'équipements de l'aéronef ; - alerte ECAM du cockpit ; et - observations saisies par un membre d'équipage de l'aéronef dans le rapport de vol. Ces messages résultent de défaillances. Ils sont consolidés dans le système central de maintenance afin de produire une liste d'éléments accusables parmi lesquels se trouvent le ou les éléments défectueux à l'origine de la ou des défaillances détectées. Une telle liste est généralement adressée, par exemple sous forme de PFR (sigle de Post Flight Report en terminologie anglo-saxonne), à une équipe de support de maintenance au sol qui les analyse et définit, en fonction de procédures définies dans un manuel de résolution de problèmes (ou TSM, sigle de Trouble-Shooting Manual en terminologie anglo-saxonne), des procédures de maintenance devant être effectuées par des opérateurs. La fonction de diagnostic offerte par le système central de maintenance a notamment pour but de fournir une liste de défauts pouvant être réparés et fournir une explication (en termes d'éléments réparables ou non) de la ou des défaillances détectées. A titre d'illustration, le système décrit dans la demande de brevet FR 2 966 616 a pour objet un outil dynamique d'aide au diagnostic d'un système d'un aéronef, utilisant des graphes d'événements redoutés. Ce système permet d'établir un diagnostic d'un système complexe d'un aéronef à partir de messages standards de notification d'événements détectés en utilisant une modélisation du système qui peut être utilisée par ailleurs pour effectuer des vérifications et conduire des analyses relatives au système complexe. Les outils de diagnostic sont aujourd'hui de plus en plus fiables et permettent d'accuser tous les équipements qui peuvent être la cause d'une défaillance détectée. Cependant, avec la multiplication des composants et l'augmentation de la précision des outils de diagnostic, le nombre d'éléments pouvant être la cause d'une défaillance détectée augmente. Par conséquent, pour s'assurer de remplacer un équipement effectivement défaillant, un opérateur de maintenance doit souvent effectuer plusieurs tests différents afin de déterminer, dans la liste des équipements accusés, quel est celui ou ceux qui sont réellement à l'origine de la défaillance détectée. Cet ensemble de tests a une conséquence non négligeable en termes de temps de traitement pour l'opérateur et peut conduire à un impact sur l'autorisation donnée à un aéronef de décoller (appelée dispatch en terminologie anglo-saxonne). 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é pour ordinateur d'aide à la maintenance d'un système complexe d'un aéronef comprenant un ensemble d'éléments, des moyens de détection de défaillances d'éléments ou de fonctions mises en oeuvre par des éléments et des moyens d'établissement d'un premier niveau de diagnostic, ce procédé comprenant les étapes suivantes, - détection d'une défaillance ; - identification d'une pluralité d'éléments dudit ensemble d'éléments, chaque élément de ladite pluralité d'éléments étant susceptible d'être à l'origine de ladite défaillance détectée, seul ou en combinaison avec au moins un autre élément de ladite pluralité d'éléments ; et - pour chaque élément de ladite pluralité d'éléments, détermination d'une probabilité que l'élément considéré soit à l'origine de ladite défaillance détectée, lesdites étapes étant mises en oeuvre dans un système d'un aéronef. Le procédé selon l'invention permet ainsi d'optimiser des opérations de maintenance. Selon un mode de réalisation particulier, le procédé comprend en outre une étape d'identification d'au moins un élément réellement à l'origine de ladite défaillance détectée, des identifiants dudit au moins un élément identifié et de ladite défaillance détectée étant utilisés pour mettre à jour une base de données comprenant au moins une entrée associant un identifiant de défaillance à une liste d'éléments susceptibles d'être à l'origine de la défaillance identifiée et une probabilité, pour chaque élément de la liste d'éléments, que l'élément correspondant soit à l'origine de ladite défaillance identifiée. Le procédé selon l'invention permet ainsi d'optimiser des opérations de maintenance ultérieures. Toujours selon un mode de réalisation particulier, le procédé comprend en outre une étape de mise à jour d'une base de données temporaire, ladite base de données comprenant au moins une entrée associant un identifiant de défaillance à une liste d'éléments susceptibles d'être à l'origine de la défaillance identifiée et une probabilité, pour chaque élément de la liste d'éléments, que l'élément correspondant soit à l'origine de ladite défaillance identifiée, appelée base de données sol, étant mise à jour à partir du contenu de ladite base de données temporaire. Le procédé comprend en outre, de préférence, une étape de transmission de ladite base de données temporaire. Le procédé selon l'invention peut ainsi être mis en oeuvre facilement sans nécessiter de lien de communication permanent entre l'aéronef et un système au sol. Toujours selon un mode de réalisation particulier, ladite probabilité que l'élément considéré soit à l'origine de ladite défaillance détectée est 25 déterminée à partir d'une base de données aéronef, le procédé comprenant en outre une étape d'obtention de ladite base de données aéronef, ladite base de données aéronef correspondant à une partie de ladite base de données sol. Ladite étape de détermination d'une probabilité que l'élément considéré soit à l'origine de ladite défaillance détectée peut notamment être 30 réalisée au cours d'une étape de diagnostic ou au cours d'une étape de résolution dynamique de problème. 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 lorsque ledit programme est exécuté sur un ordinateur, un dispositif comprenant des moyens adaptés à la mise en oeuvre de chacune des étapes de ce procédé et un aéronef comprenant ce dispositif. Les avantages procurés par ce programme d'ordinateur, ce dispositif et cet aéronef sont similaires à ceux évoqués précédemment. D'autres avantages, buts et caractéristiques de la présente invention ressortent de la description détaillée qui suit, faite à titre d'exemple non limitatif, au regard des dessins annexés dans lesquels : - la figure 1 illustre un exemple d'environnement permettant la mise en oeuvre de l'invention selon un mode de réalisation particulier ; - la figure 2 illustre un exemple d'étapes mises en oeuvre pour 15 mettre à jour une base de données de type Temporary BITE history database, dans un aéronef, et une base de données de type Ground BITE history database, au sol, selon un mode de réalisation particulier ; - la figure 3 illustre un exemple d'étapes mises en oeuvre pour mettre à jour une base de données de type Flight BITE history database à partir 20 d'une base de données de type Ground BITE history database ; - la figure 4 illustre un premier exemple d'étapes mises en oeuvre dans un système avionique pour optimiser statistiquement des opérations de maintenance ; - la figure 5 illustre un second exemple d'étapes mises en oeuvre 25 dans un système avionique pour optimiser statistiquement des opérations de maintenance ; et - la figure 6 illustre un exemple d'architecture d'un dispositif adapté à mettre en oeuvre l'invention selon un mode de réalisation particulier. Selon un mode de réalisation particulier, l'invention a pour objet de 30 combiner à des éléments accusés par un outil de diagnostic, lorsque des défaillances sont détectées, des informations représentant, pour chaque élément accusé, une probabilité que cet élément soit réellement en cause. Ainsi, à l'aide d'une telle information, un opérateur peut privilégier une procédure de test à une autre pour déterminer, dans une liste d'éléments accusés, quel est celui ou ceux qui sont réellement à l'origine de la ou des défaillances détectées. L'opérateur peut ainsi éviter des tests et gagner du temps. En effet, non seulement plusieurs éléments peuvent être à l'origine de certaines défaillances, de façon alternative ou combinée, mais en outre, la plupart des outils de diagnostic permettent de déterminer une fonction défectueuse mais pas le ou les composants défectueux (typiquement le ou les LRU (sigle de Line Replaceable Unit en terminologie anglo-saxonne) mettant en oeuvre la fonction défectueuse). La figure 1 illustre un exemple d'environnement permettant la mise en oeuvre de l'invention selon un mode de réalisation particulier. Comme illustré, l'environnement 100 comprend un ensemble d'aéronefs référencés 105-1 à 105-n (seuls les aéronefs 105-1 et 105-n sont ici représentés) chacun pourvu d'un système avionique génériquement référencé 110, comprenant chacun deux bases de données génériquement référencées 115 et 120. Les systèmes avioniques 110 peuvent communiquer avec des systèmes de traitement de l'information au sol via un réseau de communication 125. Par ailleurs, le réseau de communication 125 est relié, via un portail d'accès 130, à un serveur 135 comprenant une base de données 140. Les systèmes avioniques 110 peuvent ainsi échanger des données avec le serveur 135 via le réseau de communication 125 et le portail d'accès 130. Il est observé ici que selon un mode de réalisation particulier, une seule base de données peut être utilisée dans le serveur 135, sans qu'il soit nécessaire de mettre en oeuvre les bases de données 115 et 120, lorsqu'une liaison de communication permanente et temps réel peut être établie entre les systèmes avioniques 110 et le serveur 135. La base de données 140, aussi appelée Ground BITE history database, contient, de préférence, tous les types d'accusation possible d'un ensemble d'aéronefs (c'est-à-dire de toutes les défaillances pouvant être détectées), de préférence de tous les aéronefs d'un même constructeur, exploités par toutes les compagnies aériennes, ainsi que, pour chaque élément accusable, des statistiques associées (par exemple la probabilité que l'élément soit réellement l'élément en cause vis-à-vis d'une défaillance donnée). Afin de bénéficier d'un retour d'expérience relatif à un grand nombre d'aéronefs, cette base de données est avantageusement gérée par le fournisseur ou le constructeur des aéronefs. Alternativement, cette base de données peut être gérée sous forme d'une ou plusieurs bases de données par des sociétés exploitant les aéronefs. Les bases de données 120, aussi appelées Flight BITE history database, sont synchronisées avec la base de données 140 et reprennent les informations propres au type d'aéronef dans lequel est hébergée la base de données. Les bases de données 115, aussi appelées Temporary BITE history database, sont utilisées pour collecter des informations de maintenance de l'aéronef l'hébergeant et les transmettre à la base de données 140. Les bases de données 120 ont notamment pour objet de fournir des informations devant être combinées à des informations de diagnostic obtenues, par exemple, par un système central de maintenance d'un aéronef. Comme indiqué précédemment, de telles informations sont typiquement des probabilités que des éléments accusables soient effectivement responsables de défaillances détectées. Ainsi, à titre d'illustration, dans le cas d'une défaillance détectée pour laquelle la liste d'éléments accusables est de type « A ou B ou C », où A représente, par exemple, une broche de CPIOM (sigle de Core Processing Input Output Module en terminologie anglo-saxonne), B représente un câble connecté à cette broche et C représente un équipement connecté au CPIOM via ce câble, les informations devant être combinées à des données de diagnostic permettent de définir la probabilité que chacun des éléments considérés soit réellement la cause de la défaillance détectée. Le résultat d'une telle combinaison peut être, par exemple, le suivant : « A: 12,5% ou B: 12,5% ou C: 75%» signifiant que la probabilité que l'élément A ou l'élément B soit en cause est, pour chacun de ces éléments, de 12,5 % et la probabilité que l'élément C soit en cause est de 75 °/0. Une telle information permet à un opérateur de maintenance de commencer les tests par l'élément C. Ainsi, statistiquement, le temps passé par l'opérateur à tester les éléments potentiellement en cause, suite à la détection d'une défaillance, est réduit. Comme indiqué précédemment, les bases de données 115 sont utilisées pour récolter des résultats d'opérations de maintenance effectuées. En fonction de chaque type d'accusation (défaillance détectée), la base des données mémorise, en fin de procédures de maintenance, le ou les éléments réellement en cause. La mémorisation de ces informations permet d'enrichir la connaissance du système par un retour d'expérience. Selon un mode de réalisation particulier, les informations mémorisées dans une base de données 115 sont automatiquement transmises à la base de données 140 dès qu'une connexion peut être établie entre le système avionique 110 hébergeant la base de données 115 et le serveur 135 hébergeant la base de données 140. Une telle communication peut-être une communication air-sol ou une communication sol-sol utilisant un protocole de communication standard, de préférence sécurisé. La base de données 140 est ainsi mise à jour avec des informations reçues des aéronefs. Naturellement, la base de données 140 peut également être mise à jour de façon manuelle, par exemple lorsqu'il a été observé à plusieurs reprises que les procédures de maintenance existantes ne sont pas adaptées. Réciproquement, les bases de données 120 sont régulièrement synchronisées avec la base de données 140, par exemple de façon périodique ou dès qu'un changement relatif à un aéronef concerné est constaté. Lors de la mise en service d'un nouvel aéronef, la base de données 140 est construite par retour d'expérience. Ainsi, à titre d'illustration et en reprenant l'exemple d'une défaillance pour laquelle la liste d'éléments accusables est de type « A ou B ou C », où A représente une broche de CPIOM, B représente un câble connecté à cette broche et C représente un équipement connecté au CPIOM via ce câble, le retour d'expérience lié à la détection de cette défaillance permet de calculer les probabilités définies précédemment (la probabilité selon laquelle l'élément A ou l'élément B est en cause est, pour chacun de ces éléments, de 12,5 % et la probabilité que l'élément C est en cause est de 75 °/0). De telles probabilités sont, de préférence, calculées pour chaque défaillance pouvant être détectée. Selon un mode de réalisation particulier, lorsque le retour d'expérience est insuffisant (inférieure à un seuil prédéterminé), un même niveau peut-être associé à chaque élément accusable (alors même que la base de données 140 contient des informations de retour d'expérience particulières). Les informations mémorisées dans la base de données 140 (et donc dans les bases de données 120), représentant typiquement des probabilités que des éléments accusables soient effectivement responsables de 15 défaillances détectées, peuvent être utilisées de différentes façons, par exemple lors de l'établissement d'un diagnostic ou après l'établissement d'un diagnostic. Toujours selon un mode de réalisation particulier, la base de données de type Ground BITE history database, utilisée pour mémoriser un 20 historique de maintenance d'un grand nombre d'aéronefs, de préférence de différents types, comprend deux parties distinctes : - une première partie comprenant des données associées à chaque défaillance d'un ensemble de défaillances susceptibles d'être détectées. De telles données sont, par exemple, les suivantes : 25 o un identifiant de la défaillance considérée, pouvant être identifiée dans un premier niveau de diagnostic à partir, notamment, de messages BITE, notifications ECAM et observations de membres d'équipage ; o un identifiant d'un type d'aéronef ; 30 o un nombre d'entrées seuil définissant le nombre d'entrées à partir duquel les données de retour d'expérience peuvent être utilisées (c'est-à-dire considérées comme suffisamment pertinentes pour être prises en compte dans des procédures de maintenance) ; o un nombre d'entrées correspondant au nombre de retour d'expérience (c'est-à-dire au nombre de fois où la défaillance considérée a été détectée et où le ou les éléments accusés et responsables de cette défaillance ont été identifiés). Lorsque ce nombre atteint le nombre d'entrées seuil, les données de retour d'expérience peuvent être utilisées dans des procédures de maintenance ; o un niveau de confiance du retour d'expérience concernant la défaillance identifiée. Il permet, par exemple, de préciser un niveau de confiance quant aux pourcentages d'accusation présentés en fonction du nombre d'entrées, du nombre d'éléments accusables, de taux de défaillance des éléments accusables, etc. ; et o un niveau d'accusation pour chaque élément accusable vis-à-vis de la défaillance considérée, c'est-à-dire, par exemple, une probabilité qu'un élément ayant un identifiant donné soit responsable de la défaillance considérée ; et - une seconde partie comprenant des données relatives à chaque élément susceptible d'être accusé lors de la détection d'une défaillance. De telles données sont, par exemple, les suivantes : o un identifiant de l'élément considéré ; o un identifiant d'un type d'aéronef ; o une liste de défaillances pouvant être détectées dont l'élément considéré est potentiellement la cause (en partie ou en totalité) ; et o des informations complémentaires telles que - un taux de défaillance (MTBF, sigle de mean time between failures en terminologie anglo-saxonne) ; - date de mise en circulation de l'élément ; et - nombre d'heures de vol. Naturellement, d'autres données peuvent être mémorisées dans la base de données. Ainsi, pour chaque couple formé d'un identifiant d'une défaillance pouvant être détectée et d'un type d'aéronef, la base de données de type Ground BITE history database permet de définir un ordre d'éléments accusés à tester afin de réduire statistiquement le nombre de tests à effectuer. Comme décrit ci-dessus, cette base de données est mise à jour régulièrement à partir de données de retour d'expérience. Chaque base de données de type Flight BITE history database est 10 extraite de la base de données de type Ground BITE history database. Elle ne reprend que des données de la première partie de données correspondant à un type d'aéronefs particulier. Chaque base de données de type Temporary BITE history database est utilisée pour mettre à jour la base de données de type Ground BITE history 15 database. Elle comprend des données du type de celles de la seconde partie de la base de données de type Ground BITE history database, pour un type d'aéronef donné. La figure 2 illustre un exemple d'étapes mises en oeuvre pour mettre à jour une base de données de type Temporary BITE history database, dans un 20 aéronef, et une base de données de type Ground BITE history database, au sol, selon un mode de réalisation particulier. Il est observé ici qu'un tel algorithme permet également de mettre à jour et optimiser des procédures de maintenance, par exemple les procédures de maintenance de type de DT-CT (sigle de Dynamic Tree for Contextualized 25 Troubleshooting en terminologie anglo-saxonne) décrites, en particulier, dans la demande de brevet FR 2 917 521, en utilisant un retour d'expérience et une analyse des procédures de maintenance ayant conduit à la remise en condition opérationnelle d'un aéronef. Les étapes représentées dans la partie gauche de la figure sont 30 mises en oeuvre dans un système avionique tandis que les étapes représentées dans la partie droite sont mises en oeuvre dans un serveur au sol. Après qu'une procédure de maintenance ait été réalisée dans un aéronef, suite à la détection d'une défaillance, un premier test est effectué (étape 200) pour déterminer si au moins un élément, typiquement un équipement, a été changé dans l'aéronef. Un élément est ici un composant matériel ou logiciel ayant un identifiant (S/N, sigle de Serial Number en terminologie anglo-saxonne) unique, chaque composant pouvant être changé dans un aéronef ayant un identifiant distinct. Si aucun élément n'a été changé, la procédure de maintenance qui a permis la remise en état opérationnel de l'aéronef est analysée (étape 205). Une telle analyse concerne, en particulier, la nature d'opérations effectuées sur les éléments sur lesquels a porté la procédure de maintenance. Ces opérations sont, par exemple, un redémarrage (power cycle), une réinitialisation (reset) ou un rechargement de paramètres/configuration (dataloading). La base de données de type Temporary BITE history database de l'aéronef concerné est ensuite mise à jour (étape 210). Une telle mise à jour peut notamment consister, si au moins un élément a été changé, à indiquer l'identifiant de cet élément et, si aucun élément n'a été changé, à indiquer l'identifiant du ou des éléments sur lesquels a porté la procédure de maintenance qui a permis de corriger la défaillance identifiée ainsi que la nature des opérations effectuées. Un test est alors effectué (étape 215) pour déterminer si une connexion peut être établie entre le système avionique de l'aéronef concerné, hébergeant la base de données de type Temporary BITE history database, et un serveur au sol hébergeant la base de données de type Ground BITE history database devant être mise à jour. Si une telle connexion peut être établie, elle l'est (il s'agit par exemple d'une connexion utilisant un protocole standard, de préférence sécurisé) et une requête de mise à jour est transmise par le serveur au sol hébergeant la base de données de type Ground BITE history database au système avionique de l'aéronef concerné hébergeant la base de données de type Temporary BITE history database (étape 220). En réponse à cette requête, la base de données de type Temporary BITE history database est téléchargée dans le serveur au sol (étape 225) et, le cas échéant, son contenu est consolidé avec celui de bases de données similaires téléchargées depuis d'autres aéronefs (étape 230). La base de données de type Ground BITE history database est alors mise à jour avec les données reçues et, le cas échéant, consolidées (étape 235). Comme indiqué précédemment, la base de données de type Temporary BITE history database comprend des données telles que celles figurant dans la seconde partie de la base de données de type Ground BITE history database. Ces données sont utilisées pour mettre à jour celles de la première partie de cette base de données. A titre d'illustration, la base de données de type Temporary BITE history database peut comprendre les données suivantes : o INPUT - S/N = xi - A/C type = y - Déf. = Ext FMEA/PFC . MTBF = zi . Date_circ =lii/mmi/aai - Nb H vol= hl o IN PUT . S/N = x2 - A/C type = y - Déf. = Ext FMEA/PFC - MTBF = z2 . Date_circ = j72/mm2/aa2 . Nb H vol= h2 où INPUT<> indique une entrée de la base de données, S/N représente un identifiant d'élément, A/C type représente un identifiant d'un type d'aéronef, Déf. représente un identifiant de défaillance, date_circ est une date de mise en circulation et Nb _ H _vol est un nombre d'heures de vol. Ainsi, selon cet exemple, la base de données de type Temporary BITE history database comprend deux entrées liées à la défaillance Ext FMEA/PFC dont l'une désigne l'élément x1 comme étant à l'origine de la défaillance et l'autre x2. Ces entrées sont utilisées pour mettre à jour la base de données de type Ground BITE history database. Par conséquent, si cette dernière contenait, dans la première partie de données, l'entrée suivante : o INPUT o Déf. = Ext FMEA/PFC o A/C type = y o Seuil = 0 o Nb_entrées = NbIN o Niv_conf = Ô o List_élém. - S/N = xi ; Prob(S/Ni) - Probi - SIN = X2; Prob(S/Ali) - pro b2 - SIN = x3 ; Prob(S/Ali) - pro b3 - SIN = x4 ; Prob(S/Ali) - pro b4 où INPUT<> indique une entrée de la base de données, Déf. représente un identifiant de défaillance, A/C type représente un identifiant d'un type d'aéronef, Seuil est le nombre d'entrées à partir duquel les données de retour d'expérience peuvent être utilisées, Nb_entrées est le nombre de retour d'expérience, Niv_conf est le niveau de confiance du retour d'expérience, List_élém. est la liste des éléments accusables pour la défaillance considérée, S/N représente un identifiant d'élément et Prob(S/N) représente le niveau d'accusation pour l'élément correspondant, cette entrée peut être, après mise à jour, la suivante : o INPUT o Déf. = Ext FMEA/PFC o A/C type = y o Seuil = 0 o Nb_entrées = NbIN + 2 o Niv_conf = + Ô, o List_élém. - S/N = x1 ; Prob(S/Ni) = (Probi / NbIN + 1) x (NbIN + 2) x - S/N = X2; Prob(S/Ni) = (Prob2/ NbIN + 1) x (NbIN +2) x - S/N = x3 ; Prob(S/Ni) = prob3/ NbIN x (NbIN +2) x - S/N = x4 ; Prob(S/Ni) = Prob4/ NbIN x (NbIN +2) x y étant un facteur de normalisation. Après que la base de données de type Ground BITE history database ait été mise à jour (étape 240), la base de données de type Temporary BITE history database de l'aéronef concerné est effacée (étape 245). Comme décrit précédemment, la gestion de la base de données de type Ground BITE history database peut être effectuée au niveau du fournisseur ou du constructeur des aéronefs ou au niveau d'une compagnie exploitant ces aéronefs. La gestion de cette base de données au niveau du fournisseur ou du constructeur des aéronefs permet d'avoir une base de données ayant un périmètre plus important et, par conséquent, d'avoir des statistiques d'accusation plus fiables que celles liées à une base de données gérer au niveau d'une compagnie exploitant des aéronefs (en particulier dans le cas de petites compagnies ne possédant que peu d'aéronefs). En outre, la gestion de cette base de données au niveau du fournisseur ou du constructeur d'aéronefs permet d'utiliser des données de retour d'expérience d'essais en vol. Elle permet également, pour de nouveaux types d'aéronefs, d'utiliser des données de retour d'expérience liées à des générations antérieures d'aéronefs pour construire une version initiale de la base de données, celle-ci étant ensuite consolidée par des données de retour d'expérience liées au type d'aéronefs concerné. Comme décrit précédemment, un système central de maintenance ne permet généralement pas d'identifier des éléments défectueux suite à la détection d'une défaillance. Généralement, le résultat de diagnostic fourni dans un PFR comprend une liste d'éléments accusables dont seulement certains sont effectivement à l'origine de la ou des défaillances détectées. L'utilisation de données de retour d'expérience permet de classer la liste d'éléments accusables, ou plus généralement d'affiner cette liste, et ainsi optimiser les procédures de maintenance. Cette utilisation peut être effectuée lors de la création du PFR ou ultérieurement, à partir de son contenu. A ces fins, le système central de maintenance ou tout autre système de l'aéronef en charge de corréler des données de retour d'expérience avec une liste d'éléments accusables doit comprendre ces données contenues, selon un mode de réalisation particulier, dans la base de données de type Flight BITE history database. La figure 3 illustre un exemple d'étapes mises en oeuvre pour mettre à jour une base de données de type Flight BITE history database à partir d'une base de données de type Ground BITE history database. La base de données de type Flight BITE history database peut être mise à jour de façon périodique ou selon des critères prédéfinis. A ces fins, une connexion est établie entre le système avionique hébergeant cette base de données et le serveur au sol hébergeant la base de données de type Ground BITE history database avec laquelle elle doit être synchronisée. Cette connexion est, par exemple, une connexion utilisant un protocole standard, de préférence sécurisé. Une requête de mise à jour est alors transmise par système avionique de l'aéronef concerné hébergeant la base de données de type Flight BITE history database au serveur au sol hébergeant la base de données de type Ground BITE history database (étape 300). Cette requête comprend, de préférence, un identifiant de l'aéronef (A/C S/N) à l'origine de la requête. Un test est ensuite effectué (étape 305) pour déterminer si la version de la base de données de type Flight BITE history database est identique à celle de la base de données de type Ground BITE history database. A ces fins, une référence de version est associée à la base de données de type Ground BITE history database, cette version étant incrémentée à chaque mise à jour de cette base de données. En outre, cette dernière peut comprendre une troisième partie de données associant à chaque identifiant d'aéronef une référence de version de base de données de type Flight BITE history database et le type d'aéronef (A/C type). Il est ainsi possible, à partir d'un identifiant de l'aéronef reçu dans la requête de mise à jour, de déterminer la référence de version de la base de données de type Flight BITE history database. Si la référence de version de la base de données de type Flight BITE history database est différente de celle de la base de données de type Ground BITE history database, une base de données de type Flight BITE history database, propre au type d'aéronef concerné est construite (étape 310). Selon un mode de réalisation particulier, la base de données de type Flight BITE history database est une extraction de la base de données de type Ground BITE history database selon un type d'aéronef particulier. Elle est stockée de façon temporaire dans le serveur au sol. La base de données construite est alors téléchargée dans le système avionique concerné (étape 315). Après le téléchargement (étape 320), la base de données construite est supprimée du serveur au sol (étape 325) et la référence de version de la base de données de type Flight BITE history database, pour l'aéronef concerné, est mise à jour, par exemple dans la base de données de type Ground BITE history database. Après avoir été téléchargée dans un système avionique, la base de 20 données de type Flight BITE history database peut être utilisée pour classer une liste d'éléments accusables, ou plus généralement affiner cette liste, et ainsi optimiser des procédures de maintenance. Comme décrit précédemment, lorsqu'il est possible de créer une connexion permanente entre un système avionique et un serveur au sol, il n'est pas nécessaire d'utiliser, dans chaque 25 aéronef, une base de données de type Flight BITE history database, une base de données de type Ground BITE history database pouvant être directement accédée et utilisée. La figure 4 illustre un premier exemple d'étapes mises en oeuvre dans un système avionique pour optimiser statistiquement des opérations de 30 maintenance. Comme illustré, une première étape a pour objet l'établissement d'un diagnostic relatif à une défaillance détectée (étape 400). Ce dernier peut être établi à l'aide d'un outil standard tel qu'un système central de type CMS. Un test est ensuite effectué pour déterminer si la défaillance détectée est présente dans la base de données de type Flight BITE history database (étape 405). Dans l'affirmative, le diagnostic est affiné (étape 410). Comme décrit précédemment, cette étape peut notamment consister à identifier la probabilité, pour chaque élément accusable du diagnostic, d'être à l'origine de la défaillance détectée. Les éléments accusables peuvent alors être classés par probabilités décroissantes de telle sorte que les éléments accusables ayant les probabilités les plus élevées d'être à l'origine de la défaillance détectée soient considérés en premier. Si la défaillance détectée n'est pas présente dans la base de données de type Flight BITE history database ou après avoir affiné le diagnostic, un rapport de vol (PFR) est calculé à partir du diagnostic qui est, le cas échéant, affiné (étape 415). Le rapport de vol est ensuite analysé pour définir des procédures de maintenance en fonction d'un manuel de résolution de problèmes. Les procédures de maintenance définies sont alors exécutées pour identifier le ou les éléments accusables à l'origine de la défaillance détectée (étapes 420 et 425). Lorsque le ou les éléments accusables à l'origine de la défaillance détectée ont été identifiés, la base de données de type Temporal BITE history database est mise à jour (étape 430), comme décrit en référence à la figure 2, et l'opération de maintenance proprement dite est effectuée (étape 435). Alternativement, l'opération de maintenance proprement dite peut être effectuée avant ou pendant la mise à jour de la base de données de type Temporal BITE history database. Alors qu'un système central de maintenance de type CMS permet 30 généralement d'obtenir un diagnostic sous forme de PFR, comprenant des éléments accusables relativement génériques, de nouveaux système de type ADA (acronyme d'Aircraft Diagnostic Agent en terminologie anglo-saxonne) apparaissent pour permettre d'établir des diagnostics comprenant des listes d'éléments accusables plus précises. De tels systèmes nécessitent l'utilisation de procédures dynamiques (procédures TSM dynamiques), la résolution de problème étant effectuée de façon dynamique en fonction des éléments accusés (DT-CT). Dans un tel contexte de procédures de maintenance statique (procédures TSM classiques), des données de retour d'expérience telles que celles contenues dans une base de données de type Flight BITE history database, peuvent être utilisées au niveau du diagnostic, comme décrit en référence à la figure 4, ou au niveau d'une procédure de résolution de problème (cette dernière étant dynamique, il est possible d'y intégrer des informations de retour d'expérience pour orienter la résolution du problème). Lorsque des données de retour d'expérience sont utilisées au niveau du diagnostic, le système central de maintenance de type ADA corrèle toutes les informations en provenance des différents systèmes de surveillance de l'aéronef tout en offrant, de préférence, un mode interactif permettant de confirmer une défaillance et confirmer qu'elle n'est plus présente après une opération de maintenance. Le système ADA calcule en outre un deuxième niveau d'accusation en prenant en compte des données issues de la base de données de type Flight BITE history database pour affiner la liste d'éléments accusables et ainsi fournir à un opérateur de maintenance des statistiques sur chacun des éléments accusés. Comme décrit précédemment, de telles informations permettent d'orienter l'opérateur de maintenance afin qu'il privilégie, dans un premier temps, les éléments qui sont le plus souvent à l'origine de défaillances détectées. A titre d'illustration, le système ADA fourni tout d'abord une liste d'éléments accusables telle que la liste suivante : « A ou B ou (C et D) ». Puis, en utilisant des données de la base de données de type Flight BITE history database, le système ADA peut affiner la liste des éléments accusables selon des statistiques d'accusation, cette liste pouvant alors s'exprimer de la façon suivante : « A(60%) ou B(35%) ou (C et D)(5%) ». Un opérateur de maintenance est ainsi incité à tester tout d'abord l'élément A. A nouveau, la base de données de type Ground BITE history database, à partir de laquelle sont dérivées des bases de données de type Flight BITE history database, utilise, de préférence, des données issues d'un nombre d'aéronefs exploités par un grand nombre de compagnies. La construction et la mise à jour de cette base de données sont avantageusement réalisées de façon automatique en utilisant des résultats d'opérations de maintenance, ces résultats étant par exemple mémorisés dans une base de 10 données de type Temporary BITE history database transmise à un serveur au sol hébergeant la base de donnée de type Ground BITE history database. Une telle solution permet à un opérateur de maintenance d'avoir une parfaite visibilité sur des équipements qui sont probablement à la source de défaillances détectées et de choisir lui-même, en tenant compte de cette 15 information et de la facilité et/ou des coûts de la procédure de maintenance associées pour choisir quel équipement essayer de remplacer en premier. Cependant, cette solution nécessite une intervention humaine pouvant être évitée en intégrant les données de retour d'expérience durant la phase de résolution de problème (trouble-shooting). 20 Alternativement, lorsque des données de retour d'expérience sont utilisées au niveau d'une procédure de résolution de problème, par exemple dans un système de procédures de maintenance dynamique de type DT-CT, c'est-à-dire au niveau des procédures de maintenance, elles sont utilisées pour proposer à un opérateur de maintenance, de façon dynamique, quelles 25 procédures il doit effectuer et dans quel ordre. Une telle solution intégrée permet à un opérateur de maintenance de voir directement quelle est la meilleure action de maintenance à effectuer (telle que déterminée par le système de maintenance). La figure 5 illustre un second exemple d'étapes mises en oeuvre 30 dans un système avionique pour optimiser statistiquement des opérations de maintenance. Comme illustré, une première étape a pour objet l'établissement d'un diagnostic relatif à une défaillance détectée (étape 500). Ce dernier peut être établi à l'aide d'un outil standard tel que celui décrit dans la demande de brevet FR 2 966 616. Un rapport de vol (PFR) est ensuite calculé à partir du diagnostic (étape 505) et une liste d'éléments accusables qui proviennent d'une défaillance est sélectionnée (étape 510). Un test est ensuite effectué pour déterminer si la défaillance détectée est présente dans la base de données de type Flight BITE history database (étape 515). Dans l'affirmative, le diagnostic est affiné (étape 520). Comme décrit précédemment, cette étape peut notamment consister à identifier la probabilité, pour chaque élément accusable du diagnostic, d'être à l'origine de la défaillance détectée. L'outil de résolution de problème guide alors l'opérateur pour identifier le ou les éléments à l'origine de la défaillance détectée en prenant en compte les éléments potentiellement en cause et les probabilités associées (étapes 525 et 530). Lorsque le ou les éléments accusables à l'origine de la défaillance détectée ont été identifiés, la base de données de type Temporal BITE history database est mise à jour (étape 535), comme décrit en référence à la figure 2, et l'opération de maintenance proprement dite est effectuée (étape 540). A nouveau, l'opération de maintenance proprement dite peut être effectuée avant ou pendant la mise à jour de la base de données de type Temporal BITE history database. Comme illustré par le trait pointillé, les étapes 515 à 535 sont ici mises en oeuvre dans l'outil de résolution de problème, par exemple le DT-CT. La figure 6 illustre un exemple d'architecture d'un dispositif adapté à mettre en oeuvre l'invention ou une partie de l'invention selon un mode de réalisation particulier, en particulier les algorithmes décrits en référence aux figures 2 à 5. Comme illustré, le dispositif comprend ici plusieurs microprocesseurs, des mémoires locales ainsi qu'une interface de communication. Plus précisément, le noeud 600 comporte ici un bus de communication 602 auquel sont reliés : - des unités centrales de traitement ou microprocesseurs 604 (ou CPU, sigle de Central Processing Unit en terminologie anglo-saxonne) ; - des composants de mémoire vive 606 (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 cours de l'exécution de programmes (comme illustré, chaque composant de mémoire vive peut être associé à un microprocesseur) ; et, - des interfaces de communication 608 adaptées à transmettre et à recevoir des données. Le dispositif 600 dispose en outre ici de moyens de stockage interne 610, tels que des disques durs, pouvant notamment comporter le code exécutable de programmes. Le bus de communication permet la communication et l'interopérabilité entre les différents éléments inclus dans le noeud 600 ou reliés à lui. Les microprocesseurs 604 commandent et dirigent l'exécution des instructions ou portions de code logiciel du ou des programmes. Lors de la mise sous tension, le ou les programmes qui sont stockés dans une mémoire non volatile, par exemple un disque dur, sont transférés dans la mémoire vive 606. 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. La présente invention ne se limite pas aux formes de réalisation décrites, d'autres variantes et combinaisons de caractéristiques sont possibles. La présente invention a été décrite et illustrée dans la présente description détaillée en référence aux figures jointes. Toutefois, la présente invention ne se limite pas aux formes de réalisation présentées. D'autres variantes et modes de réalisation peuvent être déduits et mis en oeuvre par la personne compétente dans le domaine de l'invention à la lecture de la présente description et des figures annexées. Dans les revendications, le terme « comporter » n'exclut pas d'autres éléments ou d'autres étapes. L'article indéfini « un » n'exclut pas le pluriel. Un seul processeur ou plusieurs autres unités peuvent être utilisées pour mettre en oeuvre l'invention. Les différentes caractéristiques présentées et/ou revendiquées peuvent être avantageusement combinées. Leur présence dans la description ou dans des revendications dépendantes différentes n'exclut pas, en effet, la possibilité de les combiner. Les signes de référence ne sauraient être compris comme limitant la portée de l'invention. REVENDICATIONS1. Procédé pour ordinateur d'aide à la maintenance d'un système complexe d'un aéronef comprenant un ensemble d'éléments, des moyens de détection de défaillances d'éléments ou de fonctions mises en oeuvre par des éléments et des moyens d'établissement d'un premier niveau de diagnostic, ce procédé étant caractérisé en ce qu'il comprend les étapes suivantes, - détection d'une défaillance ; - identification (400, 500) d'une pluralité d'éléments dudit ensemble d'éléments, chaque élément de ladite pluralité d'éléments étant susceptible d'être à l'origine de ladite défaillance détectée, seul ou en combinaison avec au moins un autre élément de ladite pluralité d'éléments ; et - pour chaque élément de ladite pluralité d'éléments, détermination (410, 520) d'une probabilité que l'élément considéré soit à l'origine de ladite défaillance détectée, lesdites étapes étant mises en oeuvre dans un système d'un aéronef. 2. Procédé selon la revendication 1 comprenant en outre une étape d'identification (200, 205) d'au moins un élément réellement à l'origine de ladite défaillance détectée, des identifiants dudit au moins un élément identifié et de ladite défaillance détectée étant utilisés pour mettre à jour (235) une base de données comprenant au moins une entrée associant un identifiant de défaillance à une liste d'éléments susceptibles d'être à l'origine de la défaillance identifiée et une probabilité, pour chaque élément de la liste d'éléments, que l'élément correspondant soit à l'origine de ladite défaillance identifiée. 3. Procédé selon la revendication 2 comprenant en outre une étape de mise à jour (210) d'une base de données temporaire, ladite base de données comprenant au moins une entrée associant un identifiant de défaillance à une liste d'éléments susceptibles d'être à l'origine de la défaillance identifiée et une probabilité, pour chaque élément de la liste d'éléments, que l'élément correspondant soit à l'origine de ladite défaillance identifiée, appeléebase de données sol, étant mise à jour à partir du contenu de ladite base de données temporaire. 4. Procédé selon la revendication 3 comprenant en outre une étape de transmission de ladite base de données temporaire. 5. Procédé selon la revendication 3 selon lequel ladite probabilité que l'élément considéré soit à l'origine de ladite défaillance détectée est déterminée à partir d'une base de données aéronef, le procédé comprenant en outre une étape d'obtention (315) de ladite base de données aéronef, ladite base de données aéronef correspondant à une partie de ladite base de données sol. 6. Procédé selon la revendication 1 selon lequel ladite étape de détermination d'une probabilité que l'élément considéré soit à l'origine de ladite défaillance détectée est réalisée au cours d'une étape de diagnostic. 7. Procédé selon la revendication 1 selon lequel ladite étape de détermination d'une probabilité que l'élément considéré soit à l'origine de ladite défaillance détectée est réalisée au cours d'une étape de résolution dynamique de problème. 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 1 à 7 lorsque ledit programme est exécuté sur un ordinateur. 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. Aéronef comprenant le dispositif selon la revendication 9.25