Brevet FR2950176A1 — publié le 20110318

La présente invention concerne la documentation des aéronefs et plus particulièrement un procédé et un dispositif d'accès à la documentation et performance d'un aéronef selon des alarmes générées dans celui-ci. Pour effectuer un vol, l'équipage d'un aéronef dispose de documents emportés à bord de l'aéronef ou directement disponibles à l'intérieur de celui-ci. Ce type de documents comprend notamment la documentation technique de l'aéronef, c'est-à-dire la description des systèmes et des procédures, les tolérances, la liste d'équipements minimum ou MEL (acronyme de Minimum Equipment List en terminologie anglo-saxonne) et la liste des écarts de configuration ou CDL (sigle de Configuration Deviation List en terminologie anglo-saxonne), la documentation opérationnelle compagnie (critères de choix d'un aéroport de diversion, règles de travail en équipage, etc.), les performances (décollage, atterrissage et en vol) ainsi que les cartes de navigations et d'aérodromes. Il est observé ici que les performances aéronef sont données, pour certaines familles d'aéronefs, dans le FCOM (acronyme de Flight Crew Operating Manual en terminologie anglo-saxonne) Vol. 2/3, dans le QRH (acronyme de Quick Reference Handbook en terminologie anglo-saxonne) ou dans des documents spécifiques tels que des fiches limitations au décollage. En outre, le pilote utilise des documents spécifiques à chaque vol tels que le dossier de vol comprenant, en particulier, le plan de vol et les cartes météorologiques du parcours. Dans la suite, il est considéré que la documentation opérationnelle concerne l'ensemble de la documentation disponible à bord d'un aéronef et liée à celui-ci, notamment le FCOM et le MEL ainsi que celle liée à la compagnie exploitant cet aéronef et celle nécessaire au calcul des performances de l'aéronef au décollage et à l'atterrissage. La documentation opérationnelle peut être dans un format papier ou électronique. Lorsqu'elle est dans un format électronique elle peut notamment être hébergée sur une plateforme informatique particulière intégrée à l'aéronef mais faisant partie d'un domaine dit ouvert auquel la compagnie a librement accès et qu'elle peut modifier, contrairement au domaine avionique dont chaque modification est généralement soumise à l'approbation du constructeur de l'aéronef. Par ailleurs, chaque aéronef est équipé d'un système d'alarmes appelé FWS (sigle de Flight Warning System en terminologie anglo-saxonne) capable de détecter des pannes ou des configurations anormales afin de prévenir l'équipage grâce à la génération d'alertes visuelles et/ou sonores et à l'affichage des procédures à effectuer et de l'état de l'aéronef (liste des systèmes inopérants, des limitations de performances, etc.) via un système d'affichage d'alertes. Un tel système d'alarmes fait partie de l'avionique de l'aéronef. Lorsque le FWS détecte la panne d'un système, la procédure que doit suivre le pilote est alors affichée sur un écran. Suite à la détection de cette panne, le copilote, appelé Pilot Non-Flying, effectue les actions requises affichées sur cet écran. Lorsque toutes les actions requises ont été effectuées et que, par conséquent, la procédure n'est plus affichée, le pilote peut alors consulter sa documentation opérationnelle si le temps lui permet. Cette consultation est en général optionnelle. Elle donne des informations supplémentaires au pilote quant à l'impact de la panne. Ainsi il dispose de toutes les informations nécessaires pour analyser la situation et prendre la meilleure décision possible concernant la poursuite de la mission et/ou la préparation d'un prochain vol. A ces fins, plusieurs manuels peuvent être consultés. L'ordre de consultation dépend de la situation de l'aéronef. Ainsi, en général et à titre d'illustration, si l'aéronef est sur le taxiway en route pour le décollage, le MEL doit tout d'abord être consulté. Le pilote peut ensuite consulter le FCOM. La documentation opérationnelle papier impose aux pilotes une bonne connaissance de la structure des manuels afin d'accéder rapidement à l'information cherchée. Lorsque la page associée à la panne a été identifiée selon la structure du manuel dans lequel l'information est cherchée, le pilote consulte des informations détaillées relatives à la procédure qu'il vient de suivre sur l'écran. S'il est considéré que la panne ne sera pas réparée durant la prochaine escale, le pilote peut consulter le MEL afin d'évaluer l'impact de la panne sur la prochaine mission. A travers les différentes pages de ce manuel, le pilote peut déterminer les conditions de vol pour la prochaine mission ainsi que les différentes procédures opérationnelles particulières qu'il devra suivre. En d'autres termes, la consultation du MEL lui permet de déterminer si l'état actuel de l'aéronef est compatible avec la prochaine mission. Par ailleurs, si la panne du système affecte les performances de l'aéronef à l'atterrissage, le pilote doit trouver les informations nécessaires au calcul de l'impact de la panne. Celles-ci sont généralement disponibles dans le QRH. Si la panne affecte le décollage, c'est le MEL qui donnera cette indication. La figure 1 illustre schématiquement un exemple d'environnement, dans un aéronef, où sont gérées les alertes et où la documentation correspondante peut être accédée. Ce système comprend ici trois parties distincts : l'environnement avionique 100, l'environnement informatique dit ouvert 105 et l'environnement 110 de documentation disponible dans un format papier. Comme indiqué précédemment, l'avionique 100 comprend en particulier un FWS 115 pour détecter des pannes ou des anomalies ainsi qu'un système d'affichage d'alerte 120 pour afficher les procédures à effectuer lorsque des alarmes sont générées ainsi que l'état de l'aéronef. L'environnement informatique dit ouvert 105 comprend un système d'information embarqué ouvert 130 auquel est relié une base de donnée 125 dans laquelle est mémorisée la documentation opérationnelle, ou une partie de celle-ci. Le système d'information embarqué ouvert permet de consulter la documentation électronique mémorisée à bord de l'aéronef, par exemple à l'aide de mots clés. Bien que ces documents soient généralement structurés sous forme hiérarchique, à partir de milliers d'unités documentaires, il n'est pas nécessaire, ici (avec l'aide de mots clés), de connaître la structure du document dans lequel des informations sont cherchées. Enfin, l'environnement 110 de documentation disponible dans un format papier comprend les manuels 135 tels que le FCOM, le MEL et le CDL. Si le pilote utilise le format papier, il doit connaître la source de l'information qu'il recherche dans les multiples documentations qu'il a à sa disposition à bord de l'aéronef. La première action que le pilote doit effectuer est donc de sélectionner le manuel opérationnel dans lequel aller chercher l'information. Lorsqu'il pense savoir dans quel document chercher son information, il lui faut connaître la structure du manuel pour aller au plus vite à l'information. Il est donc nécessaire que le pilote ait une bonne connaissance de sa documentation opérationnelle. Par ailleurs, la recherche de l'information pertinente dans l'ensemble de la documentation opérationnelle est une tâche fastidieuse et longue pour le pilote et, par conséquent, réduit sa réactivité. Il est observé qu'en outre, il peut être nécessaire de combiner des informations issues de plusieurs manuels pour déterminer les impacts opérationnels d'une alarme, notamment dans le cas du calcul de performance. Enfin, il est observé que la tâche du pilote augmente lorsque plusieurs alarmes sont générées simultanément, chacune devant être traitée l'une après l'autre mais pouvant avoir des impacts opérationnels supplémentaires lorsqu'elles sont combinées entre elles. L'utilisation d'une documentation au format électronique à l'aide de mots clés permet au pilote de s'affranchir de la connaissance de la structure documentaire et de l'utilisation des abaques de performance pour prendre en compte l'impact d'une panne car des moyens de recherche, notamment par mots clés, ou la sélection directe d'une panne facilitent l'accès à l'information. Cependant, le pilote doit toujours identifier chaque panne détectée et un oubli de sa part peut contribuer à une mauvaise appréciation des impacts de la panne sur l'aéronef, notamment sur les performances au décollage et à l'atterrissage. Il existe donc un besoin pour améliorer les systèmes d'accès à la documentation dans un aéronef. 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'accès à la documentation d'un aéronef dans ledit aéronef, ladite documentation comprenant au moins un document modifiable indépendamment du constructeur dudit aéronef, ce procédé comprenant les étapes suivantes, - réception d'au moins une indication relative à au moins une alarme générée par l'avionique dudit aéronef ; et, - extraction et affichage d'au moins une donnée relative à ladite au moins une alarme, ladite au moins une donnée comprenant un lien vers au moins un élément de ladite documentation. Ainsi, le procédé selon l'invention permet de contextualiser la documentation opérationnelle dans un aéronef pour apporter une interactivité supplémentaire dans le cockpit. Cette interactivité augmente l'intégration du système d'information en fournissant un accès rapide et facile aux informations relatives au contexte actuel de vol, selon une panne détectée par un calculateur d'alarmes. Ces informations permettent au pilote une meilleure compréhension et connaissance des systèmes de l'aéronef, une meilleure analyse de l'état actuel de l'aéronef, une meilleure analyse des impacts opérationnels d'une panne, une meilleure anticipation pour la conduite à terme de la mission en cours et une meilleure anticipation de la prochaine mission. Ces informations facilitent ainsi la tâche du pilote dans les situations chargées et suppriment la nécessité de connaître la structure de la documentation opérationnelle. Selon un mode de réalisation particulier, le procédé comprend en outre les étapes suivantes, - identification d'au moins une partie d'au moins un document de ladite documentation relatif à ladite au moins une alarme selon ladite au moins une indication reçue ; et, - accès à ladite au moins une partie dudit au moins un document. Ainsi, le procédé selon l'invention permet d'accéder directement à une partie de la documentation relative à une alarme lorsque cette dernière se produit. Ladite au moins une donnée est, de préférence, affichée parmi une pluralité de données représentant des liens vers ladite documentation, ladite au moins une donnée étant affichée de façon identifiable. Selon un mode de réalisation particulier, le procédé comprend en outre une étape d'authentification de ladite au moins une indication reçue pour contrôler la validité des indications reçues. Ladite au moins une indication est reçue via un lien unidirectionnel pour protéger l'avionique par rapport aux données issues des systèmes d'informations embarqués ouverts. Ladite au moins une donnée comprend en outre, de préférence, une information relative aux conditions ayant conduit à la génération de ladite au moins une alarme permettant de préciser le contexte. Ladite documentation comprend avantageusement au moins l'un des documents parmi un FCOM, un MEL, un CDL, un manuel de l'exploitant dudit aéronef et/ou des éléments de calcul de performance. 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. L'invention a aussi pour objet un dispositif comprenant des moyens 25 adaptés à la mise en oeuvre de chacune des étapes du procédé décrit précédemment ainsi qu'un aéronef comprenant ce dispositif. 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 : 30 - la figure 1 illustre schématiquement un exemple d'environnement, dans un aéronef, où sont gérées les alertes et où la documentation correspondante peut être accédée ; - la figure 2 illustre schématiquement un exemple d'environnement, dans un aéronef, où sont gérées les alertes, cet environnement permettant d'accéder de façon pertinente à la documentation opérationnelle, conformément à l'invention ; - la figure 3 présente schématiquement un exemple de certaines étapes des algorithmes utilisant les codes d'alarmes reçus du FWS et utilisés par le système d'information embarqué ouvert ; - la figure 4 illustre un exemple d'une copie d'un écran du système d'information embarqué ouvert, représentant l'interface d'une application de calcul de performance lorsqu'une alarme ayant un impact performance a été générée dans le FWS ; - la figure 5, comprenant les figures 5a, 5b et 5c, illustre des exemples de copies d'un écran du système d'information embarqué ouvert, représentant l'interface d'une application d'accès à la documentation opérationnelle lorsqu'une alarme a été générée dans le FWS ; - la figure 6 illustre un exemple d'une fenêtre d'un écran du système d'information embarqué ouvert représentant l'interface d'une application d'accès à la documentation opérationnelle lorsqu'une alarme de type feu dans une cage de train est générée ; et, - la figure 7 illustre schématiquement un dispositif adapté à mettre en oeuvre l'invention. De façon générale, l'invention permet la transmission de codes associés aux alarmes générées par le FWS, se situant dans le domaine avionique de l'aéronef, vers des applications hébergées dans le domaine informatique dit ouvert (système d'information embarqué ouvert). En utilisant ces informations, les applications hébergées dans le système d'information embarqué ouvert présentent alors au pilote des menus contextualisés faisant le lien vers la documentation pertinente relative aux alarmes générées et à ses causes et/ou conséquences. Le système selon l'invention permet ainsi de donner un accès rapide et facile aux « pages » pertinentes de la documentation opérationnelle lorsque des pannes sont détectées. Il est considéré ici qu'un document peut être un contenu informatif passif pouvant être présenté, par exemple, sous forme de texte et/ou de schémas prédéterminés, un contenu informatif dynamique pouvant également être présenté sous forme de texte et/ou de schémas mais dont au moins une partie est évaluée selon des données reçues de l'avionique ou un contenu interactif permettant d'évaluer des résultats selon des données reçues de l'avionique et des données entrées par l'utilisateur. Dans une application appelée OPS LIBRARY, l'équipage a accès, via un onglet ECAM ALERTS, à la liste des alarmes générées durant le vol par le FWS. Des liens affichés dans cet onglet donnent des accès directs aux « pages » de la documentation opérationnelle relative aux alarmes. D'autres applications, notamment des applications de calcul de performances, utilisent les informations relatives aux alarmes générées par le FWS pour contextualiser les informations présentées au pilote, par exemple pour contextualiser le calcul de performance d'atterrissage en cas d'alarmes ayant des impacts performances. Selon un mode de réalisation particulier, un code spécifique est attribué à chaque alarme pouvant être générée par le FWS. Un lien fiable et sécurisé est mis en oeuvre pour transmettre les codes correspondant aux alarmes générées par le FWS de ce dernier au système d'information embarqué ouvert qui est capable de recevoir de tels codes et de les mettre à disposition de l'ensemble des applications de consultation de documentation ou de calcul de performances. La figure 2 illustre schématiquement un exemple d'environnement, dans un aéronef, où sont gérées les alertes, cet environnement permettant d'accéder de façon pertinente à la documentation opérationnelle, conformément à l'invention. Ce système comprend ici deux environnements informatiques distincts : l'environnement avionique 100' et l'environnement informatique dit ouvert 105'. De façon standard, l'avionique 100' comprend ici, en particulier, un FWS 115' pour générer des alarmes selon des pannes ou des anomalies détectées ainsi qu'un système d'affichage d'alertes 120 pour afficher l'état de l'aéronef ainsi que les procédures à effectuer lorsque des alarmes sont générées. Cependant, le FWS 115' est ici adapté à transmettre un code correspondant aux alarmes générées. L'environnement informatique dit ouvert 105' comprend un système d'information embarqué ouvert 130' auquel sont reliées ici les bases de données 200 à 215 dans lesquelles sont mémorisées la documentation opérationnelle, ou une partie de celle-ci. Plus précisément, la base de données 200 mémorise la documentation FCOM, la base de données 205 mémorise la documentation MEL, la base de données 210 mémorise la documentation de la compagnie aérienne exploitant l'aéronef et la base de données 215 mémorise la documentation relative aux calculs de performance. Il convient de remarquer ici que les informations mémorisées dans les bases de données 200 à 215 peuvent être mémorisées ou réparties dans 15 plusieurs bases de données de façon différente. L'environnement informatique dit ouvert 105' est relié à l'environnement avionique 100' par un lien unidirectionnel 220 comprenant un élément de contrôle de communication 225 ayant une fonction de type « diode ». L'élément 225 permet de contrôler l'échange d'informations entre les 20 environnements 100' et 105' afin d'éviter que des données du système d'information embarqué ouvert, faisant partie du domaine dit ouvert, ne puissent être transmises vers l'avionique. Le lien 200 permet au calculateur d'alarmes d'informer en temps réel le système de documentation électronique de l'apparition ou de l'activation 25 d'alarmes. Il permet également au calculateur d'alarmes d'informer en temps réel de la disparition d'une alarme. Les données sont mises à jour à chaque cycle de calcul du calculateur d'alarmes. Le calculateur d'alarmes transmet ainsi au système d'information embarqué ouvert les codes identifiants associés aux alertes sonores ou visuelles générées à chaque cycle de calcul. 30 Ces codes sont avantageusement mémorisés par le système d'information embarqué ouvert, par exemple dans une mémoire tampon, d'où ils sont accessibles par les applications exécutées par le système d'information embarqué ouvert. Par ailleurs, afin de garantir l'intégrité des informations échangées entre le calculateur d'alarmes et le système d'information embarqué ouvert, le système d'information embarqué ouvert authentifie avantageusement les données reçues du FWS. A ces fins, le calculateur d'alarmes attribue un numéro d'identification commun à chaque ensemble de données envoyé et détermine le nombre d'informations envoyées. Ces informations sont envoyées à chaque cycle de calcul en plus des informations relatives aux alarmes identifiées. Le système d'information embarqué ouvert peut ainsi valider les données reçues en vérifiant les numéros d'identification et en comparant le nombre de données reçues avec le nombre indiqué. A titre d'illustration, le système d'information embarqué ouvert comprend une première application OPS LIBRARY de gestion de la documentation et une seconde application LDG PERF de calcul de performances, ces deux applications étant configurées pour prendre en compte les alarmes générées par le FWS. Il convient d'observer ici que la documentation étant sujette à révision, elle peut être régulièrement mise à jour. De même, le FWS peut évoluer afin d'incorporer de nouvelles fonctionnalités ou de nouvelles surveillances. Pour permettre une correspondance entre les codes issus du FWS et la documentation gérée par le système d'information embarqué ouvert en dépit de l'évolution de ces systèmes, un processus de création d'unités documentaires spécifiques est de préférence mis en oeuvre. Lors du développement d'un nouveau standard FWS, l'équipe en charge de son développement communique la liste des codes présents dans ce standard et les alarmes correspondantes aux équipes en charge de la rédaction des divers documents et/ou de la réalisation de l'application de calcul des performances. Cette communication peut notamment se faire à travers une base de données produite par un outil dédié sous la forme d'un ensemble de fichiers XML (sigle d'eXtensible Markup Language en terminologie anglo-saxonne). Durant la phase de rédaction d'une documentation, par exemple du document FCOM, les auteurs reproduisent, de préférence dans le chapitre des procédures anormales, toutes les procédures qui sont traitées par le système d'affichage des alertes lorsque des alarmes sont générées par le FWS. Les auteurs saisissent chaque alarme dans une unité documentaire particulière en mentionnant les informations suivantes : - code de l'alarme ; et, - liens vers les unités documentaires correspondantes du document considéré. Une telle unité documentaire particulière peut correspondre à une ou à plusieurs alarmes. De façon avantageuse, chaque unité documentaire particulière créée comprend en outre les informations complémentaires suivantes : - le nom associé à l'alarme dans le système d'affichage des alertes ; - les conditions qui ont déclenchées l'alarme ; et, - des commentaires qui aident notamment à la compréhension des actions à effectuer ou des restrictions engendrées. L'application de calcul des performances est modifiée de façon similaire pour prendre en compte les codes spécifiques de chaque alarme. La table 1 présentée en annexe illustre un exemple du contenu d'une unité documentaire créée pour prendre en compte des codes d'alarmes reçus du FWS. Chaque ligne correspond ici à une alarme. Comme illustré, la première colonne représente le code de l'alarme considérée, la seconde comprend les liens correspondant vers les unités documentaires concernées, la troisième comprend les conditions qui ont déclenchées l'alarme et la dernière comprend des commentaires permettant d'expliciter l'alarme et/ou les actions à entreprendre. Les liens comprennent de préférence une description permettant au pilote de déterminer la nature des informations visées par le lien ainsi que le lien lui-même. A titre d'illustration, le lien (« FCOM », fcom-chap_3-sect_2-par_3) permet d'accéder, à partir de l'affichage « FCOM », à la page correspondant au troisième paragraphe de la deuxième section du troisième chapitre du document FCOM. Les liens permettant d'accéder aux documents sont, de préférence, formatés selon le système d'exploitation utilisé par le système d'information embarqué ouvert. Ils peuvent donc représenter des chemins et être définis, de façon relative ou absolue, selon les emplacements des unités documentaires visées en fonction de l'organisation hiérarchique liée à leur mémorisation. Une base de données contenant ces unités documentaires utilisées pour établir des liens entre les codes d'alarmes et la documentation est de préférence publiée lors de chaque révision de la documentation opérationnelle. Elle contient tous les codes spécifiques qui mettent en relation les unités documentaires et les alarmes. Cette base de données est chargée dans l'aéronef en même temps que la révision de la documentation. Elle est appelée lors du déclenchement de la recherche d'un code d'alarme. La figure 3 illustre schématiquement un exemple de certaines étapes des algorithmes utilisant les codes d'alarmes reçus du FWS et utilisés par le système d'information embarqué ouvert. Après que l'application ait été lancée (étape 300), une première étape vise à déterminer si une ou plusieurs alarmes ont été générées dans le FWS (étape 305). Cette étape analyse notamment la partie de la mémoire 310 du système d'information embarqué ouvert dans laquelle sont mémorisés les codes reçus des alarmes générées dans l'avionique. Si une ou plusieurs alarmes ont été générées dans le FWS, les données relatives aux codes de ces alarmes sont extraites (étape 315) selon la ou les unités documentaires particulières mémorisées dans la base de données 320 établissant les liens entre des codes d'alarmes et des unités documentaires de la documentation de l'aéronef. A l'issue de cette étape, les données extraites sont affichées (étape 325) pour permettre à l'utilisateur de sélectionner et d'activer des liens associés à ces données et de naviguer dans la documentation (étape 330) mémorisée dans les bases de données 335. Comme indiqué précédemment, les informations affichées comprennent par exemple le nom des alarmes générées, les conditions les ayant générées, des commentaires sur celles-ci et des liens permettant d'accéder à des informations relatives à celles-ci dans la documentation opérationnelle. Si l'application exécutée a pour objet une simple consultation de la documentation, la documentation accédée comprend, de préférence, le FCOM, le MEL, le CDL et des documents développés par la compagnie aérienne exploitant l'aéronef. Si, au contraire, l'application exécutée a pour objet un calcul de performance, la documentation accédée correspond au calcul de performance dont les valeurs sont initialisées selon les alarmes générées. Si aucune alarme n'a été générée, c'est-à-dire si aucun code d'alarme n'est présent dans la mémoire 310, un affichage par défaut de la documentation est initialisé (étape 345) pour permettre la navigation dans celle- ci. Parallèlement à la navigation dans la documentation, l'application analyse le contenu de la mémoire 310 pour détecter la présence de codes correspondant à de nouvelles alarmes (étape 340). Si une ou plusieurs nouvelles alarmes sont identifiées, les étapes précédentes (étapes 315 à 345) sont répétées. Il est observé que lorsque plusieurs alarmes sont identifiées, leur traitement est généralement effectué selon leur ordre d'apparition. En outre, une référence aux alarmes traitées par les applications du système d'information embarqué ouvert est de préférence mémorisée par chacune d'elles pour permettre de traiter en priorité, au lancement de ces applications, celles qui n'ont pas encore été traitées. Lorsque des alarmes sont générées par le FWS, c'est-à-dire lorsque des conditions d'alarmes sont détectées par le FWS, le pilote les traite dans le système d'affichage d'alertes. Simultanément, le FWS transmet automatiquement les codes d'alarmes correspondant vers le système d'information embarqué ouvert à travers le lien de communication établi entre l'avionique et le système d'information embarqué ouvert. Après le traitement de la panne dans le système d'affichage d'alertes et au moment opportun choisi par le pilote, celui-ci peut analyser, à partir du système d'information embarqué ouvert, l'impact des pannes ayant généré les alarmes. Cette analyse est, par exemple, réalisée dans la partie documentation opérationnelle à travers l'application OPS LIBRARY. Elle peut également être réalisée dans l'application LDG PERF s'il y a un impact sur la performance de l'aéronef. L'application LDG PERF récupère automatiquement le code de l'alarme correspondant à une panne ayant un impact performance. Lorsque le pilote lance l'application LDG PERF permettant d'effectuer un calcul sur les performances d'atterrissage, celle-ci récupère automatiquement le code des alarmes correspondant à une panne ayant un impact performance, par exemple une panne F/CTL PRIM 1 FAULT. Le pilote peut alors effectuer les calculs de performance selon les pannes détectées. La figure 4 illustre un exemple d'une copie d'un écran du système d'information embarqué ouvert représentant l'interface de l'application LDG PERF lorsque l'alarme F/CTL PRIM 1 FAULT, affectant les performances de l'aéronef, a été générée. Cette dernière est ici affichée dans la zone 400. La fenêtre de calcul de performance 405 est initialisée selon les paramètres relatifs à la panne détectée afin de diminuer autant que possible la tâche du pilote. De façon similaire, la documentation opérationnelle relative aux alarmes générées est accessible via l'application OPS LIBRARY grâce aux liens préalablement définis. Ainsi, lorsque le pilote souhaite consulter l'ensemble des éléments de la documentation opérationnelle relative à une alarme, le pilote lance l'application OPS LIBRARY. Suite à l'occurrence d'une alarme, la page d'un onglet ECAM ALERTS de l'interface de cette application est automatiquement affichée. Cette page présente la liste des alarmes affichées pendant le vol, par exemple l'alarme F/CTL PRIM 1 FAULT. La figure 5a illustre un exemple d'une copie d'un écran du système d'information embarqué ouvert représentant l'interface de l'application OPS LIBRARY lorsqu'une alarme a été générée. La page 500, correspondant à l'onglet ECAM ALERTS 505, comprend la liste des alarmes générées, ici l'alarme F/CTL PRIM 1 FAULT, référencée 510. Le pilote sélectionne et active alors la panne dont il souhaite consulter la documentation opérationnelle attenante. L'activation est, par exemple, réalisée en cliquant sur le bouton SEARCH portant la référence 515. La sélection est, de préférence, réalisée à l'aide d'un dispositif de pointage tel qu'une souris, un écran tactile ou un KCCU (sigle de Keyboard Cursor Control Unit en terminologie anglo-saxonne). La liste des manuels opérationnels contenant des informations relatives à l'alarme sélectionnée est alors présentée au pilote. Les références à ces manuels sont, de préférence, affichées dans une couleur verte. Les autres manuels sont, par exemple, référencés dans une couleur bleue. La figure 5b illustre un exemple d'une copie d'un écran du système d'information embarqué ouvert représentant l'interface de l'application OPS LIBRARY lorsqu'une alarme a été générée. La liste 520 correspond à la liste des manuels disponibles, les manuels faisant référence à l'alarme identifiée étant représentés en vert (ici en texte souligné). Suivant le contexte du vol (préparation du vol, décollage, phase de croisière, atterrissage, etc.), le pilote sélectionne le manuel à consulter et suit le « fil vert » qui lui permet d'aboutir aux différentes pages relatives à l'alarme générée. La figure 5c illustre un exemple d'une copie d'un écran du système d'information embarqué ouvert représentant l'interface de l'application OPS LIBRARY lorsqu'une alarme et un manuel ont été sélectionnés. La fenêtre 525 représente une page relative à l'alarme générée, ici dans le manuel FCOM, tandis que la fenêtre 530 indique la position de cette page dans la structure hiérarchique du manuel sélectionné. Selon un mode de réalisation particulier, la sélection des informations relatives aux alarmes générées prend automatiquement en compte l'état de l'aéronef. En effet, les procédures à appliquer et transmises par le FWS au système d'affichage d'alertes peuvent différer selon l'état de l'aéronef au moment de la survenue de l'alarme (phase de vol, système fautif en cours d'utilisation ou non, panne d'un système tiers, système optionnel impacté par la panne installé sur l'aéronef ou non, etc.). Ainsi une même alarme n'entraîne pas toujours exactement les mêmes procédures. Par exemple lorsqu'un feu est détecté dans une cage d'un train d'atterrissage, les procédures ne sont pas les mêmes si l'aéronef est en vol ou s'il est au sol. Selon ce mode de réalisation, les codes des alarmes générées sont transmis du FWS au système d'information embarqué ouvert avec des codes correspondant aux lignes de procédures effectivement affichées pour ces alarmes. Ainsi, une sélection est opérée dans les manuels affichés pour identifier automatiquement les conditions comportant les lignes présentées dans le système d'affichage d'alertes et masquer les autres. L'équipage a alors directement accès aux informations relatives au cas précis rencontré, les autres restant accessibles en ouvrant les conditions masquées. Une telle interface d'affichage/masquage peut notamment utiliser le principe de développement/réduction selon lequel seul les titres de sections sont toujours affichés, le contenu des sections pouvant être affiché ou masqué à l'aide d'une fonction développer/réduire représentée, par exemple, à l'aide d'un triangle placé devant le titre de la section. Selon ce principe, toutes les sections sont réduites à l'exception de celles relatives aux alarmes générées. La figure 6 illustre un exemple d'une fenêtre d'un écran du système d'information embarqué ouvert représentant l'interface de l'application OPS LIBRARY lorsqu'une alarme de type feu dans une cage d'un train est détectée. L'affichage est ici automatiquement contextualisé selon l'état de l'aéronef. L'aéronef étant ici considéré en vol, la section 600 relative à la condition « en vol » est développée, c'est-à-dire que son contenu 605 est au moins partiellement visualisable tandis que la section 610 « au sol » est réduite, c'est-à-dire que son contenu est masqué. De façon similaire, en supposant que la vitesse de l'aéronef est supérieure à 250 noeuds, la sous-section 615 « vitesse supérieure à 250 noeuds » est développée tandis que la sous-section 620 « vitesse inférieure à 250 noeuds » est réduite. Une telle interface permet au pilote d'accéder directement aux informations utiles sans pour autant l'empêcher d'accéder à d'autres informations. De façon similaire, d'autres applications du système d'information embarqué ouvert peuvent utiliser les informations issues du FWS et/ou d'autres équipements pour optimiser leurs interfaces. La figure 7 illustre schématiquement un dispositif adapté à mettre en oeuvre l'invention. Le dispositif représenté est de préférence un dispositif standard, par exemple un ordinateur ou un calculateur d'aéronef. Le dispositif 700 comporte ici un bus interne de communication 705 auquel sont reliés : - une unité centrale de traitement ou microprocesseur 710 (CPU, sigle de Central Processing Unit en terminologie anglo-saxonne) ; - une mémoire morte 715 (ROM, acronyme de Read Only Memory en terminologie anglo-saxonne) pouvant comporter les programmes nécessaires à la mise en oeuvre de l'invention ; - une mémoire vive ou mémoire cache 720 (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 des programmes précités ; - une interface de communication 740 adaptée à transmettre et à recevoir des données vers et depuis un réseau de communication, filaire ou non. L'interface de communication 740 permet, en particulier, de recevoir de données de l'avionique. Le dispositif 700 dispose également, de préférence, des éléments suivants : - un disque dur 725 pouvant comporter les programmes précités et des données traitées ou à traiter selon l'invention ; et - un lecteur de cartes mémoires 730 adapté à recevoir une carte mémoire 735, ou tout autre système de stockage externe de données, et à y lire ou à y écrire des données traitées ou à traiter selon l'invention. Le bus interne de communication permet la communication et l'interopérabilité entre les différents éléments inclus dans le dispositif 700 ou reliés à lui. La représentation du bus interne n'est pas limitative et, notamment, le microprocesseur est susceptible de communiquer des instructions à tout élément du dispositif 700 directement ou par l'intermédiaire d'un autre élément du dispositif 700. Le code exécutable de chaque programme permettant au dispositif programmable de mettre en oeuvre les processus selon l'invention, peut être stocké, par exemple, dans le disque dur 725 ou en mémoire morte 715. Selon une variante, la carte mémoire 735 peut contenir des données, notamment une table de correspondance entre les événements détectés et les commandes pouvant être sollicitées, ainsi que le code exécutable des programmes précités qui, une fois lu par le dispositif 700, est stocké dans le disque dur 725. Selon une autre variante, le code exécutable des programmes pourra être reçu, au moins partiellement, par l'intermédiaire de la première interface de communication 740, pour être stocké de façon identique à celle décrite précédemment. De manière plus générale, le ou les programmes pourront être chargés dans un des moyens de stockage du dispositif 700 avant d'être exécutés. Le microprocesseur 710 va commander et diriger l'exécution des instructions ou portions de code logiciel du ou des programmes selon l'invention, instructions qui sont stockées dans le disque dur 725 ou dans la mémoire morte 715 ou bien dans les autres éléments de stockage précités. Lors de la mise sous tension, le ou les programmes qui sont stockés dans une mémoire non volatile, par exemple le disque dur 725 ou la mémoire morte 715, sont transférés dans la mémoire vive 720 qui contient alors le code exécutable du ou des programmes selon l'invention, ainsi que des registres pour mémoriser les variables et paramètres nécessaires à la mise en oeuvre de l'invention. L'appareil de communication comportant le dispositif selon l'invention peut également être un appareil programmé. Cet appareil contient alors le code du ou des programmes informatiques par exemple figé dans un circuit intégré à application spécifique, aussi appelé ASIC (acronyme d'Application-Specific Integrated Circuit en terminologie anglo-saxonne). Naturellement, pour satisfaire des besoins spécifiques, une personne compétente dans le domaine de l'invention pourra appliquer des modifications 10 dans la description précédente. ANNEXE Code Nom Liens Conditions Commentaires alarme alarme 00001 Nom1 Lient, lien2 CI, C2, C3 Commentaire ... ... ... ... ... Nom, Lien, C,, Cy Commentaires Table 1 REVENDICATIONS1. Procédé pour ordinateur d'accès à la documentation d'un aéronef dans ledit aéronef, ladite documentation comprenant au moins un document modifiable indépendamment du constructeur dudit aéronef, ce procédé étant caractérisé en ce qu'il comprend les étapes suivantes, - réception (305) d'au moins une indication relative à au moins une alarme générée par l'avionique dudit aéronef ; et, - extraction (315) et affichage (325) d'au moins une donnée relative à ladite au moins une alarme, ladite au moins une donnée comprenant un lien vers au moins un élément de ladite documentation. 2. Procédé selon la revendication précédente comprenant en outre les étapes suivantes, - identification d'au moins une partie d'au moins un document de ladite documentation relatif à ladite au moins une alarme selon ladite au moins une indication reçue ; et, - accès à ladite au moins une partie dudit au moins un document. 3. Procédé selon la revendication 1 ou la revendication 2 selon lequel ladite au moins une donnée est affichée parmi une pluralité de données représentant des liens vers ladite documentation, ladite au moins une donnée étant affichée de façon identifiable. 4. Procédé selon l'une quelconque des revendications précédentes comprenant en outre une étape d'authentification de ladite au moins une indication reçue. 5. Procédé selon l'une quelconque des revendications précédentes selon lequel ladite au moins une indication est reçue via un lien unidirectionnel. 6. Procédé selon l'une quelconque des revendications précédentes selon lequel ladite au moins une donnée comprend en outre une information relative aux conditions ayant conduit à la génération de ladite au moins une alarme. 7. Procédé selon l'une quelconque des revendications précédentes selon lequel ladite documentation comprend au moins l'un des documents parmi un FCOM, un MEL, un CDL, un manuel de l'exploitant dudit aéronef et/ou des éléments de calcul de performance. 8. Programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé selon l'une quelconque des revendications précédentes lorsque ledit programme est exécuté sur un ordinateur. 9. Dispositif comprenant des moyens adaptés à la mise en oeuvre 10 de chacune des étapes du procédé selon l'une quelconque des revendications 1 à 7. 10. Aéronef comprenant le dispositif selon la revendication précédente.