Brevet FR3102756A1 — publié le 20210507

L’invention concerne un système de recherche de pannes dans un aéronef, comportant: - des unités de stockages (7) configurées pour stocker une base de données contextuelle (13) modélisant des objets de procédure de recherche de pannes, ladite base de données contextuelle (13) étant une dématérialisation d’un manuel de recherche de pannes générée par une technique d’ingénierie de modélisation de systèmes complexes, - un microprocesseur (5) configuré pour implémenter lesdits objets de procédure de recherche de pannes en les structurant selon une représentation fonctionnelle et logique, et - une interface de sortie (9) configurée pour afficher ladite structure fonctionnelle et logique des objets de procédure de recherche de pannes. Fig. 1 RECHERCHE INTERACTIVE DE PANNES DANS UN AÉRONEF La présente invention se rapporte au domaine de recherche de pannes dans un aéronef. En particulier, l’invention concerne un procédé et un système de recherche de pannes numérisé. Etat de la technique antérieure Aujourd’hui, la majorité des aéronefs sont équipés d’un système de détection de pannes centralisé et certains calculateurs peuvent être testés par une fonction d’auto-diagnostique BITE (Built-in Test Equipement). A titre d’exemple, les commandes de vols critiques sont surveillées par un système de surveillance FWS (Flight Warning System) qui signale toute panne ou anomalie à l’équipage. Par ailleurs, des messages d’alertes ou d’anomalies sont également affichés sur une interface de bord via des unités de contrôle et d’affichage. Une fois qu’un message de panne est annoncé et l’aéronef est au sol, le technicien de maintenance utilise des documentations comportant un manuel de recherche de pannes TSM (Trouble Shooting Manual) et un manuel de maintenance AMM (Aircraft Maintenance Manual) pour rechercher, isoler, confirmer et rectifier la panne en suivant les instructions et les procédures décrites dans ces manuels. Plus particulièrement, ces manuels comportent des procédures de recherche de pannes et des listes prédéfinies de tâches qui sont données indépendamment du cas spécifique et dans lesquelles, le technicien de maintenance doit trouver le chemin optimal à suivre pour identifier comprendre et résoudre le problème. Ainsi, l’utilisation de ces manuels nécessite un long travail souvent fastidieux et précis, ainsi qu’une très grande expérience de la part des techniciens de maintenance pour aller à l’essentiel. L’objet de la présente invention est de proposer un procédé ou un système facilitant la recherche de panne, en guidant le technicien et en diminuant la charge de travail tout en automatisant et optimisant l’efficacité de la recherche de la panne. Présentation de l’invention La présente invention concerne un système de recherche de pannes dans un aéronef, comportant : -des unités de stockages configurées pour stocker une base de données contextuelle modélisant des objets de procédure de recherche de panne, ladite base de données contextuelle étant une dématérialisation d’un manuel de recherche de panne générée par une technique d’ingénierie de modélisation de systèmes complexes, -un microprocesseur configuré pour implémenter lesdits objets de procédure de recherche de panne en les structurant selon une représentation fonctionnelle et logique, et -une interface de sortie configurée pour afficher ladite structure fonctionnelle et logique des objets de procédure de recherche de pannes dans un ordre chronologique. Ceci permet de recréer le manuel de recherche de pannes en déroulant une application facile à utiliser permettant d’extraire à tout moment et en temps réel toute la documentation (PDF, page web, etc.) pouvant être utile pour le technicien de maintenance. En outre, il permet l’enchaînement des procédures sous une forme d’affichage graphique tout en optimisant les procédures complexes (par exemple, en parallélisant ou en structurant les tâches). Il permet également d’harmoniser les procédures entre les différents aéronefs et d’anticiper et prévoir les opérations et les ressources nécessaires (outils, pièces de rechange, nombre de techniciens, installations, etc.). Selon un mode de réalisation préféré du système de recherche de pannes : -les unités de stockage sont configurées en outre pour stocker une base de données technique comprenant un classement de probabilités de pannes attribuées à des composants remplaçables ‘en ligne’ de l’aéronef, -le microprocesseur est configuré en outre pour créer un module de gestion interactive en couplant la base de données technique et la base de données contextuelle, ledit module de gestion étant adapté à gérer en temps réel un flux interactif de tâches, et -l’interface de sortie est configurée en outre pour afficher en temps réel ledit flux interactif de tâches à réaliser pour la recherche de panne. Ceci permet de simplifier la flexibilité globale du système en proposant un produit entièrement numérisé, en facilitant le transfert de connaissances entre équipes ainsi que l’apprentissage lié au cas rencontrés précédemment. Selon un premier mode de réalisation particulier, ledit module de gestion est configuré pour générer un document numérique comportant un séquencement de tâches à réaliser pour la recherche de panne. Ainsi, l’ordonnancement d’un ensemble d’actions et de tests à réaliser permet au technicien de maintenance de se dispenser des documentations lourdes et complexes pour la recherche de panne. Selon un deuxième mode de réalisation particulier, ledit module de gestion est configuré pour générer étape par étape des tâches en forme d’instructions et/ou de dialogues destinés à guider l’utilisateur dans la recherche de panne. Ainsi, le technicien de maintenance peut rechercher la panne de manière interactive et optimale lui permettant de rapidement et aisément isoler le composant défectueux. Ceci permet de réduire le temps écoulé pour le remplacement des composants et les coûts en conséquence. Selon une particularité, les valeurs des probabilités de pannes dans la base de données technique sont initialement attribuées par des experts. Ces valeurs sont attribuées sur la base des modèles numériques des composants et/ou des tests sur bancs d’essais. Avantageusement, le système comporte une unité d’acquisition de données configurée pour acquérir de manière continue des données relatives au fonctionnement des composants de l’aéronef depuis des modèles de comportements intrinsèques desdits composants, et/ou depuis une flotte d’aéronefs en service, et/ou depuis un système de surveillance de l’aéronef, lesdites données relatives aux fonctionnement des composants étant utilisées pour mettre à jour les valeurs des probabilités de pannes. L’actualisation en continue des probabilités permet une gestion dynamique et plus précise de la recherche de pannes. L’enrichissement et les mises à jour régulières de la base de données techniques permettent de tirer des leçons à partir des problèmes rencontrés en service. Avantageusement, la base de données technique est enrichie par des modifications apportées aux composants de l’aéronef et par une mise à jour des valeurs de probabilités de pannes correspondantes. Ceci permet d’avoir une traçabilité des modifications appliquées (services bulletins) sur l’aéronef et de personnaliser la recherche de pannes tout au long de la vie de l’aéronef en tenant compte de l’évolution de l’aéronef et des modifications apportées. En outre, ceci permet de réduire la charge de travail encore davantage en guidant l’utilisateur à travers un flux de tâches personnalisé. Avantageusement, le microprocesseur est configuré pour générer un rapport de recherche de pannes à partir des entrées de l’utilisateur et des actions entreprises. Ceci permet d’avoir un rapport très précis des opérations réalisées et de renseigner le registre de maintenance en toute simplicité. En outre, ceci permet d’assurer la traçabilité des travaux effectués comme requis par les réglementations. Avantageusement, le système comporte une unité de transmission configurée pour transmettre ledit rapport des opérations au constructeur de l’aéronef. Cet apprentissage en continu permet au constructeur d’améliorer ses connaissances techniques concernant le comportement des systèmes complexes. L’invention vise également un procédé de recherche de pannes dans un aéronef, comportant les étapes suivantes : -construction d’une base de données contextuelle en dématérialisant un manuel de recherche de panne par une technique d’ingénierie de systèmes complexes, ladite base de données contextuelle modélisant des objets de procédure de recherche de pannes, et -structurer lesdits objets de procédure de recherche de pannes selon une représentation fonctionnelle et logique. Avantageusement, le procédé comporte en outre les étapes suivantes : -construction d’une base de données technique comprenant un classement de probabilités de pannes attribuées à des composants remplaçables de l’aéronef, et -coupler la base de données technique et la base de données contextuelle pour gérer en temps réel un flux interactif de tâches à réaliser pour la recherche de panne. Ainsi, en réponse à une requête faite par un technicien de maintenance, le procédé permet de générer de manière automatique et en temps réel un flux interactif de tâches. Brève description des figures D'autres particularités et avantages du dispositif et du procédé selon l'invention ressortiront mieux à la lecture de la description faite ci-après, à titre indicatif mais non limitatif, en référence aux dessins annexés sur lesquels : illustre de manière schématique un système de recherche de pannes dans un aéronef, selon un mode de réalisation de l’invention ; est un organigramme illustrant de manière schématique une décomposition suivant plusieurs couches d’un ensemble de tâches de recherche de pannes, selon le mode de réalisation de la Fig. 1 ; est un schéma fonctionnel illustrant un procédé de recherche de pannes en relation avec le système de la Fig. 1, selon un mode de réalisation préféré de l’invention ; est un organigramme illustrant de manière schématique une première variante de la recherche de pannes, selon le mode de réalisation de la Fig. 3 ; est un organigramme illustrant de manière schématique une deuxième variante de la recherche de pannes, selon le mode de réalisation de la Fig. 3 ; et ; et ; illustrent un exemple d’une recherche de pannes, selon le mode de réalisation de la Fig. 5. Le principe de l’invention consiste à numériser et modéliser les manuels de recherche de panne et à créer une interface interactive générant un flux de tâches dynamique pour guider l’utilisateur en temps réel dans sa recherche de la panne. La Fig. 1 illustre de manière schématique un système de recherche de pannes dans un aéronef, selon un mode de réalisation de l’invention. Le système de recherche 1 de pannes comporte une unité d’acquisition de données 3, un processeur ou microprocesseur 5, des unités de stockage 7, des interfaces d’entrée et de sortie 9 (clavier, écran, souris, etc.) et des unités de réception et de transmission de données 11. Les unités de stockage 7 comportent une base de données contextuelle 13 modélisant des objets de procédure de recherche de pannes. Ces objets peuvent comporter des éléments, des fonctions, des opérations, des instructions, des mises en garde, des avertissements, des notifications, des notes, etc. En outre, les objets peuvent être représentés sous forme de graphes, de textes, de numéros, de symboles, ou de dessins et peuvent être structurés de manière logique et/ou hiérarchique. La base de données contextuelle 13 est une dématérialisation d’un manuel de recherche de panne. Cette dématérialisation est créée selon une technique d’ingénierie de modélisation de systèmes complexes MBSE (Model Based System Engineering). On notera que la technique MBSE est une méthodologie connue qui est généralement utilisée pour modéliser des systèmes complexes. La présente invention détourne astucieusement l’emploi habituel de la technique MBSE et l’utilise pour contrôler la construction des objets de procédures de recherche de pannes. Cette construction est réalisée de la même manière que celle utilisée dans les systèmes complexes et plus particulièrement, en formalisant les procédures de recherche de pannes et en tenant compte de toutes leurs interdépendances. Ainsi, les objets de procédures peuvent être édifiés selon une architecture fonctionnelle représentant de manière logique des liens hiérarchiques entre ces fonctions. En effet, la technique MBSE offre la possibilité de détailler des tâches sur plusieurs couches en fonction de la granularité attendue. Le microprocesseur 5 est configuré pour implémenter les objets de procédure de recherche de pannes en les structurant selon une représentation fonctionnelle et logique. En outre, l’interface de sortie 9 est configurée pour afficher (ou imprimer) la structure 14 fonctionnelle et logique des objets de procédure de recherche de pannes dans un ordre chronologique sur un écran 10 (ou une imprimante). Selon un premier mode de réalisation, le système 1 de recherche de pannes est un dispositif portable de type tablette, ordinateur portable, ou téléphone. Dans ce cas, la base de données contextuelle 13 est stockée dans les unités de stockage 9 du dispositif portable. Selon un deuxième mode de réalisation, la base de données contextuelle 13 est stockée dans des unités de stockage comprises dans un serveur placé dans un centre de maintenance. Dans ce deuxième cas, le dispositif portable est adapté pour se connecter au serveur du centre de maintenance via ses unités de réception et transmission 11 pour accéder à la base de données contextuelle 13. La Fig. 2 est un organigramme illustrant de manière schématique une décomposition suivant plusieurs couches d’un ensemble de tâches de recherche de pannes, selon le mode de réalisation de la Fig. 1. A l’étape E1 un message d’alerte est signalé. Par message d’alerte on entend un message qui peut être produit automatiquement sur une interface de bord de l’aéronef ou un symptôme de panne qui peut par exemple être constaté suite à une inspection visuelle ou manuelle de l’aéronef ou d’une partie de l’aéronef. L’étape E2 est un test pour vérifier si le message n’est pas une fausse alerte. Si c’est une fausse alerte, on passe à l’étape E5 pour fermer proprement la procédure de recherche de pannes en validant la navigabilité de l’aéronef. Sinon, c’est-à-dire, si la panne est confirmée, on passe à l’étape E3. A l’étape E3 le microprocesseur 5 est configuré pour déployer la procédure d’isolation de la panne et pour l’afficher sur l’interface de sortie 9. Cette étape comporte une sous-étape E301 définissant les différents points d’entrées pour la recherche de pannes. Ces points d’entrées sont représentés sur l’interface de sortie 9 par des petits rectangles référencés par des codes alphanumériques indiquant l’équipement incriminé et les tâches spécifiques à réaliser. A la sous-étape E302, les différents points d’entrées de la sous-étape E301 engendrent une explosion combinatoire dans laquelle chaque point d’entrée est associé à une procédure de tâches spécifiques qui doivent être réalisées en détail pour rechercher et isoler la panne en identifiant le composant remplaçable ‘en ligne’ LRU (Line Replaceable Unit) défectueux. En effet, chaque procédure de tâches comporte des instructions et/ou des tests à l’issue desquels le composant défectueux peut être identifié. Le déroulement des étapes E301 et E302 permettent d’extraire à tout moment et en temps réel toute la documentation (en PDF, en page web, etc.) pouvant être utile pour le technicien de maintenance. Une fois que le composant défectueux a été isolé, on passe à l’étape E4 pour réparer ou remplacer ce composant. A l’étape E5 après la réparation de la panne (étape E4) ou après la vérification qu’il n’y avait pas vraiment de panne (étape E2), le technicien de maintenance réalise toute une batterie de tests prédéterminés pour valider que tout est fonctionnel et que l’aéronef est navigable. Ainsi, le mode de réalisation des Figs. 1 et 2 permet de récréer le manuel de recherche de pannes et d’afficher l’enchaînement des différentes procédures permettant au technicien de maintenance d’anticiper et de prévoir les opérations et les ressources nécessaires (outils, pièces de rechange, nombre de techniciens nécessaires, installations, etc.). En outre, ce système 1 de recherche de pannes permet de paralléliser les tâches ou de les structurer de manière optimale. La Fig. 3 est un schéma fonctionnel illustrant un procédé de recherche de pannes en relation avec le système de la Fig. 1, selon un mode de réalisation préféré de l’invention. Selon ce mode de réalisation, les unités de stockage 7 sont configurées pour stocker une base de données technique 15 en plus de la base de données contextuelle 13. La base de données technique 15 comprend un classement de probabilités de pannes attribuées aux composants remplaçables LRU de l’aéronef. Les valeurs des probabilités de pannes sont initialement attribuées par des experts des bureaux d’études sur la base de modèles numériques des composants LRU et/ou de tests sur bancs d’essais. A titre d’exemple, la base de données technique 15 peut être réalisée selon un format de carte de message de panne technique BED (Bite Exchange Database) organisé en plusieurs champs. Un premier champ peut comprendre des données concernant des codes de défauts, des messages en clair, un chapitre de l’association de transport aérien ATA, une description de la panne, un message du cockpit, et un code d’une liste principale d’équipement minimal MMEL (Master Minimum Equipment List). Un deuxième champ peut comprendre une liste des composants LRU potentiellement défectueux et leurs probabilités de panne associées. Un troisième champ peut comprendre un registre de l’évolution historique de recherche de pannes. Un quatrième champ peut comprendre des tests à réaliser pour une procédure de confirmation. Finalement, un cinquième champ peut comprendre des actions pour pallier les insuffisances avant l’entrée en service de l’aéronef. La base de données contextuelle 13 caractérisant la dématérialisation du manuel de recherche de pannes ainsi que la base de données technique 15 comprenant le classement de probabilités de pannes sont représentées par le bloc B1. Ces bases de données 13, 15 sont construites par le constructeur de l’aéronef représenté par le bloc B2. Le bloc B3 représente un module de gestion 17 interactive crée par le microprocesseur 5 en couplant la base de données technique 15 à la base de données contextuelle 13. Ce module de gestion 17 est configuré pour gérer en temps réel un flux interactif de tâches (voir Figs. 4 et 5). En outre, l’interface de sortie 9 est configurée pour afficher en temps réel le flux interactif de tâches à réaliser pour la recherche de panne. Avantageusement, l’unité d’acquisition 9 de données du système 1 de recherche de pannes est configurée pour acquérir de manière continue des données relatives au fonctionnement des composants de l’aéronef. Ces données peuvent être récupérées depuis plusieurs sources. Une première source représentée par le bloc B4 correspond à des modèles de comportement intrinsèques des composants. Ces modèles réalisés par des experts des bureaux d’études comportent l’évolution de l’usure et la durée de vie de chaque composant ainsi que la variation correspondante de sa probabilité de panne. Une deuxième source représentée par le bloc B5 comporte les systèmes d’enregistrement et de surveillance de l’aéronef. En effet, au cours de chaque vol, l’aéronef procède à l’enregistrement d’informations sur différents paramètres avioniques. Un système d’acquisition centralise et formate toutes les données issues des différents capteurs, calculateurs embarqués, ou d’autres instruments et les transfère aux systèmes d’acquisitions de données (type Fomax) et/ou aux enregistreurs de vol. Ces données comportent des données relatives au fonctionnement des composants. En outre, un système de supervision centralisé traite les données émises par des systèmes de détection de pannes et de surveillance et génère des rapports ou messages de pannes relatifs aux équipements et composants de l’aéronef. Une troisième source B6 est une flotte d’aéronefs en service. En effet, chaque aéronef transmet (pendant le vol et/ou en fin de vol) des données de vol et des messages d’alertes ou d’anomalies aux stations au sol pour être traités et archivés dans des bases de données au sol (type Skywise, Smartforce, etc.). Toutes ces données issues des sources B4, B5 et B6 et relatives au fonctionnement des composants sont utilisées par les experts au sol et en différé pour mettre à jour les valeurs des probabilités de pannes permettant ainsi une gestion dynamique et plus précise de la recherche de panne. On notera que la mise à jour des probabilités peut être manuelle ou automatique selon les données reçues et disponibles. En outre, la base de données technique 15 est avantageusement enrichie par des mises à jour relatives à des modifications ou améliorations apportées aux composants de l’aéronef ainsi que des mises à jour des valeurs de probabilités de panne associées à ces modifications. Ainsi, on obtient une traçabilité des différentes évolutions du composant, des diverses configurations, des services bulletins et une personnalisation de la recherche de pannes en fonction des modifications appliquées à l’aéronef tout au long de la vie du composant. Le bloc B7 représente la génération automatique par le microprocesseur d’un rapport 19 de recherche de pannes en fonction des entrées de l’utilisateur et des actions entreprises. Ce rapport 19 assure la traçabilité des travaux effectués comme requis par les réglementations et permet une fermeture des registres de maintenance (type logbook) de manière appropriée. Avantageusement, l’unité de transmission 11 est configurée pour transmettre ce rapport 19 de recherche de pannes au constructeur de l’aéronef (bloc B2) permettant à ce dernier de l’utiliser pour enrichir la base de données technique de futurs aéronefs. La Fig. 4 est un organigramme illustrant de manière schématique une première variante de la recherche de pannes, selon le mode de réalisation de la Fig. 3. A l’étape E11 un message d’alerte est signalé. A l’étape E12, à partir d’une requête formulée par le technicien de maintenance, le microprocesseur 5 en lien avec les bases de données contextuelle 13 et technique 15 est configuré pour générer un document numérique 21 comportant un séquencement de tâches à réaliser. Les tâches sont ordonnancées selon les valeurs de probabilités associées aux composants remplaçables LRU incriminés. Plus particulièrement, le document numérique 21 comporte une liste des différentes causes possibles de la panne, des tests à réaliser pour confirmer ou infirmer la panne, et des tâches à réaliser pour isoler la panne. Ainsi, l’étape E121 comporte la liste des différentes causes possibles de la panne, chaque cause étant référencée par un code connu pour le technicien de maintenance. L’étape E122 indique les tests à réaliser pour confirmer ou infirmer la panne. Si les résultats des tests indiquent qu’il n’y a pas de panne, on passe à l’étape E124 afin de fermer la procédure de recherche de pannes. Sinon, on passe à l’étape E123. L’étape E123 comporte l’ordonnancement des tâches à réaliser pour isoler la panne. Une fois que le composant défectueux a été identifié, on répare ou on remplace ce composant avant de passer à l’étape E124. A l’étape E124, le technicien de maintenance effectue les tests prédéterminés pour proprement fermer la procédure de recherche de pannes validant ainsi que tout est fonctionnel et que l’aéronef est navigable. La Fig. 5 est un organigramme illustrant de manière schématique une deuxième variante de la recherche de pannes, selon le mode de réalisation de la Fig. 3. A l’étape E21 un message d’alerte est signalé. Aux étapes E22-E25, le module de gestion 17 est configuré pour générer étape par étape des tâches en forme d’instructions et/ou de dialogues (par exemple, en forme de fenêtres ou boîtes de dialogues) destinées à guider le technicien de manière interactive dans sa recherche de panne. Plus particulièrement, à l’étape E22 le microprocesseur 5 est configuré pour proposer à l’utilisateur des tâches et tests à réaliser en fonction du message d’alerte afin de vérifier si la panne est réelle ou s’il s’agit d’une fausse alarme. Si les résultats des tests indiquent qu’il n’y a pas de panne, on passe à l’étape E27 pour fermer la procédure de recherche de pannes. Sinon, on passe à l’étape E23. A l’étape E23 le microprocesseur 5 est configuré pour acquérir les paramètres et données d’entrées de l’aéronef et de ces composants. On notera que ces données sont extraites des bases de données contextuelle 13 et technique 15 et comportent les valeurs de probabilité des composants LRU susceptibles d’être à l’origine de la panne. Ces valeurs sont enrichies par les mises à jour précises des probabilités de défaut grâces aux entrées venant des différentes sources représentées par les blocs B4, B5 et B6 de la Fig.3. A l’étape E24, le microprocesseur 5 est configuré pour classer les probabilités des composants pouvant être la cause de la panne et propose un flux de tâches le plus adapté au classement courant des composants incriminés. A l’étape E25, en fonction des réponses et actions réalisées par l’utilisateur, le microprocesseur 5 reboucle sur l’étape E24 pour calculer un autre classement et générer un autre flux courant de tâches si la panne n’a pas été isolée. En revanche, si le composant défectueux a été détecté, alors on passe à l’étape E26 afin de réparer la panne. A l’étape E27, la procédure de recherche de panne est proprement fermée. A l’étape E28, le microprocesseur 5 est configuré pour générer un rapport 19 de recherche de pannes à partir des entrées de l’utilisateur et des actions entreprises. Les Figs. 6, 7 et 8 illustrent un exemple d’une recherche de pannes, selon le mode de réalisation de la Fig. 5. La Fig. 6 illustre un calculateur 23 recevant les entrées de température T20, TAT1 et TAT2. Ces entrées sont relatives à une sonde de température moteur, une sonde de température d’une première centrale d’inertie ADIRU1 (Air Data and Inertial Reference Unit) et une sonde de température d’une deuxième centrale d’inertie ADIRU2 respectivement. Le comparateur 25 du calculateur 23 compare les valeurs de trois entrées et constate un désaccord entre ces trois valeurs. Le sélecteur 27 sélectionne l’origine probable du désaccord et finalement, le validateur 29 valide la sélection et transmet à la sortie un message d’alerte. En effet, la Fig. 7 indique à l’étape E31 qu’un message d’alerte a été signalé concernant un désaccord entre les trois sondes de température. On notera que la Fig. 8 illustre à titre indicatif et en un seul bloc, les différentes séries de tâches demandées par le système 1 de recherche de pannes. L’étape E32 concerne la confirmation de la panne. Le système 1 de recherche de panne affiche sur l’interface 9 de sortie une note (voir Fig. 8) indiquant qu’après une vérification croisée, une défaillance entre la sonde T20 du moteur et au moins l'une des deux sondes des ADIRU1 et ADIRU2 a été constatée. Au début, le système 1 de recherche de pannes propose à l’utilisateur de faire le test de mise à la terre (voir Fig. 8). Après la réalisation du test, le système 1 demande à l’utilisateur si le message de maintenance s'affiche sur le ‘système de gestion de vol’ MCDU (Multi-function Control and Display Unit) ou tout autre moyen d’interface à disposition. Si le message de maintenance n'apparaît pas sur le MCDU et qu'il n'y a pas eu d'action corrective, alors, le système 1 indique que c’est un problème intermittent et qu’il faut surveiller le moteur pour voir si la panne se reproduit lors des vols suivants. Si le message de maintenance ne s'affiche pas sur le MCDU et qu'une mesure corrective a été prise, alors le système indique que le problème a été résolu et renvoie l’utilisateur à l’étape E36 afin de bien fermer la procédure. En revanche, si le message de maintenance s'affiche sur le MCDU, alors à l’étape E33, le système 1 affiche sur l’interface 9 de sortie un premier flux de tâches basé sur le classement des probabilités des composants pouvant être la cause de la défaillance. Selon cet exemple, le système demande de faire un contrôle sur les messages de maintenance des ADIRU1 et ADIRU2, liés aux deux sondes. Plus particulièrement, il demande d’effectuer le dépannage des messages de maintenance dans l’ordre. Ensuite, à l’étape E34, le système 1 demande si le problème persiste après avoir résolu tous les messages de maintenance. Si oui, le système reboucle à l’étape E33 et affiche sur l’interface de sortie 9 un deuxième flux de tâches concernant cette fois le harnais. Le système 1 continue à proposer des suites de tâches jusqu’à ce que le composant défectueux soit identifié. Après réparation de la panne E35, le système 1 indique à l’utilisateur les actions qu’il faut faire (étape E36) pour proprement fermer la procédure de recherche de pannes. Finalement, à l’étape E37, le système 1 génère automatiquement un rapport 19 de recherche de pannes. Le système et procédé de recherche de pannes selon la présente invention présente plusieurs avantages parmi lesquels les avantages suivants: -permet d’éviter l’utilisation des documentations lourdes et complexes ; -permet la prédiction d’évènements à venir grâce à un système de stockage de données temporaires (buffer) dont les différents indicateurs sont paramétrables (température, vibration, etc.) pour déclencher une alerte à partir d’un seuil prédéfini ; -permet d’anticiper et de prévoir les opérations et les ressources nécessaires (i.e. outils, pièces de rechange, personnel, installations, etc.); -permet de réduire la charge de travail en guidant l'utilisateur à travers un flux de tâches personnalisé; - permet d’améliorer les connaissances techniques du constructeur des aéronefs et en particulier, pour le comportement de systèmes complexes; -permet de réduire le temps et les coûts de maintenance de l’aéronef en évitant de déposer des composants LRU n’étant pas en panne NNF (No Fault Found) ; -permet de faciliter le transfert de connaissances entre équipes; -permet d’assurer la traçabilité des travaux effectués comme requis par les réglementations ; -permet de fournir des mises à jour régulières sur les leçons tirées des problèmes rencontrés à partir d’une base de données centralisée ; et -permet de simplifier la flexibilité globale du système en proposant un produit entièrement numérisé. Système de recherche de pannes dans un aéronef, caractérisé en ce qu’il comporte: -des unités de stockages (7) configurées pour stocker une base de données contextuelle (13) modélisant des objets de procédure de recherche de pannes, ladite base de données contextuelle (13) étant une dématérialisation d’un manuel de recherche de pannes générée par une technique d’ingénierie de modélisation de systèmes complexes, -un microprocesseur (5) configuré pour implémenter lesdits objets de procédure de recherche de pannes en les structurant selon une représentation fonctionnelle et logique, et -une interface de sortie (9) configurée pour afficher ladite structure fonctionnelle et logique des objets de procédure de recherche de pannes. Système selon la revendication 1, caractérisé en ce que: -les unités de stockage (7) sont configurées en outre pour stocker une base de données technique (15) comprenant un classement de probabilités de pannes attribuées à des composants remplaçables de l’aéronef, -le microprocesseur (5) est configuré en outre pour créer un module de gestion (17) interactive en couplant la base de données technique (15) à la base de données contextuelle (13), ledit module de gestion étant adapté à gérer en temps réel un flux interactif de tâches, et -l’interface de sortie (9) est configurée en outre pour afficher en temps réel ledit flux interactif de tâches à réaliser pour la recherche de panne. Système selon la revendication 2, caractérisé en ce que ledit module de gestion (17) est configuré pour générer un document numérique comportant un séquencement de tâches à réaliser pour la recherche de panne. Système selon la revendication 2, caractérisé en ce que ledit module de gestion (17) est configuré pour générer étape par étape des tâches en forme d’instructions et/ou de dialogues destinés à guider l’utilisateur dans la recherche de pannes. Système selon l’une quelconque des revendications 2 à 4, caractérisé en ce que les valeurs des probabilités de pannes dans la base de données technique (15) sont initialement attribuées par des experts. Système selon l’une quelconque des revendications 2 à 5, caractérisé en ce qu’il comporte une unité d’acquisition de données (3) configurée pour acquérir de manière continue des données relatives au fonctionnement des composants de l’aéronef depuis des modèles de comportements intrinsèques desdits composants, et/ou depuis une flotte d’aéronefs en service, et/ou depuis un système de surveillance de l’aéronef, lesdites données relatives aux fonctionnement des composants sont utilisées pour mettre à jour les valeurs des probabilités de pannes. Système selon l’une quelconque des revendications 2 à 6, caractérisé en ce que la base de données technique (15) est enrichie par des modifications apportées aux composants de l’aéronef et par une mise à jour des valeurs de probabilités de panne correspondantes. Système selon l’une quelconque des revendications 2 à 7, caractérisé en ce que le microprocesseur (5) est configuré pour générer un rapport (19) de recherche de pannes à partir des entrées de l’utilisateur et des actions entreprises. Système selon la revendication 8, caractérisé en ce qu’il comporte une unité de transmission (11) configurée pour transmettre ledit rapport des opérations au constructeur de l’aéronef. Procédé de recherche de pannes dans un aéronef, caractérisé en ce qu’il comporte les étapes suivantes: - construction d’une base de données contextuelle en dématérialisant un manuel de recherche de pannes par une technique d’ingénierie de systèmes complexes, ladite base de données contextuelle modélisant des objets de procédure de recherche de pannes, et - structurer lesdits objets de procédure de recherche de pannes selon une représentation fonctionnelle et logique. Procédé selon la revendication 10, caractérisé en ce qu’il comporte en outre les étapes suivantes: -construction d’une base de données technique comprenant un classement de probabilités de pannes attribuées à des composants remplaçables de l’aéronef, et -coupler la base de données technique à la base de données contextuelle pour gérer en temps réel un flux interactif de tâches à réaliser pour la recherche de pannes.