EP2158525A1 - Système informatique de maintenance d'un aéronef - Google Patents

Système informatique de maintenance d'un aéronef

Info

Publication number
EP2158525A1
EP2158525A1 EP08760549A EP08760549A EP2158525A1 EP 2158525 A1 EP2158525 A1 EP 2158525A1 EP 08760549 A EP08760549 A EP 08760549A EP 08760549 A EP08760549 A EP 08760549A EP 2158525 A1 EP2158525 A1 EP 2158525A1
Authority
EP
European Patent Office
Prior art keywords
module
maintenance
hosted
documentation
computer system
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP08760549A
Other languages
German (de)
English (en)
Inventor
Jean-Philippe Corbefin
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Airbus Operations SAS
Original Assignee
Airbus Operations SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Airbus Operations SAS filed Critical Airbus Operations SAS
Publication of EP2158525A1 publication Critical patent/EP2158525A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/105—Multiple levels of security
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B23/00—Testing or monitoring of control systems or parts thereof
    • G05B23/02—Electric testing or monitoring
    • G05B23/0205—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults
    • G05B23/0218—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults characterised by the fault detection method dealing with either existing or incipient faults
    • G05B23/0243—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults characterised by the fault detection method dealing with either existing or incipient faults model based detection method, e.g. first-principles knowledge model
    • G05B23/0245—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults characterised by the fault detection method dealing with either existing or incipient faults model based detection method, e.g. first-principles knowledge model based on a qualitative model, e.g. rule based; if-then decisions
    • G05B23/0248—Causal models, e.g. fault tree; digraphs; qualitative physics
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B23/00—Testing or monitoring of control systems or parts thereof
    • G05B23/02—Electric testing or monitoring
    • G05B23/0205—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults
    • G05B23/0259—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults characterized by the response to fault detection
    • G05B23/0267—Fault communication, e.g. human machine interface [HMI]
    • G05B23/0272—Presentation of monitored results, e.g. selection of status reports to be displayed; Filtering information to the user
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks

Definitions

  • the present invention relates generally to the field of aeronautical maintenance.
  • logbook is also in the form of an electronic document, called "eLogbook”.
  • the aforementioned electronic documents are also linked together by means of hyperlinks, so that the operator can easily switch from one application to another.
  • CMS Centralised Maintenance System
  • BITE Built In Test Equipment
  • the maintenance operator therefore has at his disposal a plurality of disparate computer tools that he must master to be able to diagnose and solve a possible failure.
  • the on-board network is generally partitioned into two sub-networks, the first located in a so-called avionic zone, the second in a so-called open or non-secure zone.
  • the links between the two sub-networks are necessarily unidirectional, directed from the avionics subnet to the open subnet.
  • the links can be bidirectional.
  • Hosting the maintenance tools in the open area would not guarantee their integrity, ie effectively guard against malicious access and / or corruption of the programs and data that constitute them. As a result, maintenance tools would not be eligible for certification.
  • An object of the present invention is to propose a maintenance tool for an aircraft that does not have the aforementioned drawbacks, that is to say, on the one hand, that allows to guide the operator in a systematic way and to on the other hand, which offers an implementation compatible with the partition of the embedded network.
  • the present invention is defined by a computer maintenance system for an aircraft equipped with a partitioned network in a secure area, called avionics, and an open area, said computer system comprising a first software module hosted in the avionics area and a second software module hosted in the open area, the first module being adapted to traverse a diagnostic tree, the second module being adapted to present an electronic maintenance documentation, the path of the diagnostics shaft by the first module inducing automatically and synchronously presenting by the second page module of said maintenance documentation respectively associated with these nodes.
  • each node of said diagnostic tree corresponds to at least one maintenance task and the first module transmits to the second module a hyperlink pointing to a page of the maintenance documentation associated with this task when the first module reaches said node.
  • the first module typically determines the next node based on the result of the execution of said maintenance task corresponding to that node.
  • the diagnostic tree is determined for example from a fault identifier code, said code being itself obtained from an analysis of an entry of an electronic logbook hosted in the avionics zone. If the first module determines that a device of the aircraft is defective at the end of the path of the diagnostics tree, said system can be adapted to verify the presence of this equipment in a minimum list of aircraft equipment, called MEL list, hosted in the avionics area.
  • the system is adapted to calculate the corresponding cost in terms of functional performance losses or safety margins of the aircraft.
  • a third software module housed in the avionics zone, and a fourth software module, hosted in the open zone, may be provided, the third module being adapted to browse and select the elements of the MEL list, the fourth software module to be presented.
  • documentation pages corresponding to said equipment the selecting an element by said third software module inducing automatically and synchronously a presentation by the fourth module of a documentation page relating to this element.
  • the third module advantageously transmits to the fourth module, a hyperlink pointing to a URL containing said documentation page relating to this element.
  • the first module and, if applicable, the third module can be hosted in a first computer of the avionics zone and the second module and, where appropriate, the fourth module can be hosted ( s) in a second computer of the open area, the second computer then being connected to the network portion of the avionic area by a unidirectional link to the open area and a wireless access point.
  • the first module and, where appropriate, the third module can be hosted in a first computer of the avionics zone and the second module and, where appropriate, the fourth module can be hosted in a second computer of the open area, the inputs / outputs of the first and second computers being connected to a KVM switch, said switch being adapted to switch said inputs / outputs to a common input / output interface.
  • Fig. 1 schematically illustrates a first embodiment of the maintenance system according to the invention
  • Fig. 2 schematically illustrates an alternative embodiment of the maintenance system according to the invention
  • Fig. 3 illustrates the operation of the maintenance system according to the invention
  • Fig. 4 gives an example of a diagnostic tree
  • Figs. 5A to 5G represent the contents of a first screen and a second screen of the maintenance system, during the progression of the diagnostic module along successive nodes of the diagnostic tree.
  • the idea underlying the invention is to provide a maintenance system comprising a first software module hosted in the avionics area and a second software module hosted in the open area, the first being a diagnostic module adapted to perform a route in a diagnostic tree, the second being dedicated to the presentation of the maintenance documentation, the path of nodes of the diagnostic tree automatically and synchronously inducing a presentation of the documentation pages respectively associated with these nodes.
  • Fig. 1 illustrates a maintenance computer system according to an embodiment of the invention.
  • the system is composed of two parts 101 and 102 respectively included in the avionics zone AW and the open zone OW.
  • Each of the parts of the system comprises a plurality of equipment interconnected by bidirectional links, for example virtual links of a switched Ethernet network.
  • the two parts are connected to each other only by one or more unidirectional link (s) directed (s) from the AW zone to the OW zone, symbolized in the figure by diodes.
  • the part of the avionic zone comprises a maintenance terminal 110 or OMT (Onboard Maintenance Terminal) hosting a centralized maintenance system (CMS), 113.
  • This system comprises in particular a first software module, called diagnostic module, 115, adapted to traverse a predetermined diagnostic tree.
  • the OMT terminal also hosts a software module 120, responsible for managing the logbook.
  • the OMT terminal is also connected to integrated test modules, 130, implemented in some equipment to be tested, and to a unit 160 responsible for controlling all the circuit breakers relating to these devices. The activation of a circuit breaker makes it possible to cut off the power supply of one or more pieces of equipment in order to replace it safely.
  • the OMT terminal has an input / output interface 150 including a display screen and a keyboard.
  • the part of the system in the open area includes a terminal for consulting the maintenance documentation, hereinafter referred to as information terminal.
  • This terminal may for example take the form of a laptop computer, 190, or an electronic slate (Tablet PC TM), 195.
  • the maintenance documentation is housed either directly in the laptop 190 or the electronic slate 195 , if its memory size is sufficiently low, either in an embedded server 170, otherwise.
  • the laptop or electronic slate can be connected via a wireless link to the wired network via an AP access point. If the access point is connected to the avionic part of the network, this connection is made by means of a unidirectional link 181, as shown in the figure.
  • Frame switches denoted SW allow routing on the various links of the network.
  • a common input / output interface 155 (keyboard, screen and, where appropriate, mouse) is shared between the computer 110 hosting the diagnostic module and the computer 191 hosting the maintenance documentation.
  • the inputs / outputs of these computers are connected through the KVM (Keyboard Video Mouse) switch 185, to this common input / output interface, said switch to switch, manually or automatically, between the two computers.
  • KVM Keyboard Video Mouse
  • the maintenance operator can easily switch from the diagnostic screen to the documentation screen, as will be seen below. In case of failure, the system
  • CMS is notified either directly by a message transmitted by the flight alarm system or FWS (Flight Warning System), or by a note of the driver recorded as entry in the logbook 120, or by both jointly .
  • the CMS system can correlate different failures to look for the likely common cause (s). In all cases, the CMS system provides a probable fault identification code, associated with one or more replaceable equipment (s) or LRUs (Line Replaceable ⁇ nits).
  • the diagnostic module, 115 receives a fault identification code and retrieves the diagnostics tree corresponding to this code.
  • the module 115 is adapted to traverse this diagnostic tree according to the indications provided by the maintenance operator and / or the test modules integrated in the equipment to be tested.
  • the diagnostic tree generally comprises a first part relating to the confirmation of the failure and a second part, relating to the actual resolution, in case the failure is actually confirmed.
  • Each node of the diagnostic tree includes a task or a sequence of tasks to be performed, the result of which determines the choice of the next node.
  • Each node of the diagnostics tree corresponds to a page of the maintenance documentation intended to be displayed on the information terminal 190 or 195.
  • the path of the diagnosis tree induces simultaneously and automatically a navigation through the pages of the the documentation associated with the traversed nodes. More specifically, each time a node is visited by the diagnostic module, a hyperlink is transmitted by the terminal OMT to said terminal.
  • the latter includes a navigation module that synchronizes automatically by searching for the URL pointed to by the hyperlink.
  • the corresponding page can be retrieved locally in the information terminal if the documentation is stored there or if said page is available in the cache memory, or in the embedded server 170. Alternatively, the documentation page can be retrieved from a server on the ground.
  • the maintenance operator is thus routinely guided through the diagnostic procedure while being able to consult the maintenance documentation for each step of the procedure.
  • Storing maintenance documentation in the open area facilitates update operations.
  • the latter can be performed for example by means of a data downloading method complying with the ARINC 615 protocol or simply by replacing a memory medium.
  • the update usually leaves the diagnostic tree unchanged, which ensures the integrity of the maintenance system.
  • the diagnostics tree can be extracted from the existing maintenance documentation, ie the aforementioned AMM and TSM manuals. More precisely, the diagnostic tree corresponds to the tree structure of the TSM manual.
  • a step in the fault repair procedure corresponding to a tree node in the TSM manual, requires the completion of certain maintenance tasks in the AMM manual. In this case the tree constituting these tasks is grafted locally to the aforementioned node.
  • the set of tree nodes in the TSM manual to which the trees of the maintenance tasks related to these nodes are thus grafted forms the diagnostic tree.
  • the diagnostic tree will be obtained by removing the visual representation elements, for example layout elements, images, three-dimensional schemas , animation scripts. These elements are rejected in the documentation section. However, all the functional elements will be kept in the diagnostic tree, including hyperlinks to launch test applications, download software for a device, activate or deactivate a circuit breaker, etc.
  • a diagnostic tree is obtained and on the other hand a purely documentary file, both being, for example, in XML or SGML format but having distinct DTDs.
  • a hyperlink to a page of the document file.
  • the diagnostic tree and the document file can also be developed in parallel, provided that they respect their
  • Fig. 3 illustrates an example of operation of the maintenance computer system according to the invention.
  • a fault identification code is transmitted to the diagnostic module, for example from a logbook setpoint.
  • the diagnostics module searches for the diagnostics tree (indicated here by "Task N") corresponding to this code. This tree is divided into two parts noted (I) and (II) respectively corresponding to the procedure of confirmation of failure and the procedure of resolution of failure.
  • the presentation of the maintenance documentation is synchronized as each node of the tree passes. For example, when the diagnostic module goes through node 5, the documentation page relating to sub-task 5 is displayed on the information terminal. It should be noted, however, that switching from one node to the next does not necessarily require a change of the page to be displayed.
  • the maintenance operator can navigate freely through the documentation through hyperlinks. For example, the operator can click on the hyperlink "subtask 5- 2" to see the page related to this subtask. However, as soon as the diagnostic module passes to the next node (in this case node 8), the documentation page for this last node ("subtask 8") will automatically appear on the terminal screen. information.
  • the fault is resolved or the fault remains and the corresponding mention is recorded in the logbook.
  • the defective equipment is listed and compared with the contents of the Minimum Equipment List (MEL). This list, contrary to what its name indicates, gives the list of equipment whose operation is optional for the operation of the device. Thus, if equipment diagnosed as defective is not on the list, the flight must be canceled. On the other hand, if a device diagnosed as defective is in the MEL list, the system determines the constraints imposed by the malfunction of the equipment and the associated cost in terms of functional performance losses or safety margins.
  • MEL Minimum Equipment List
  • the malfunction of an equipment may impose a constraint on the amount of fuel that the aircraft will be able to embark, which will in turn result in a limit of its range of action.
  • the aforementioned costs are stored in a file hosted in the avionics area.
  • the computer system comprises a third software module, hosted in the avionic zone, for example in the diagnostic terminal, allowing the pilot or the maintenance operator to browse the MEL list and select any equipment from this list.
  • the computer system also comprises a fourth software module, hosted in the open zone, for example in the information terminal, responsible for displaying the documentation relating to the elements of the MEL list.
  • This documentation is housed in the open area, for example by the information terminal or the embedded server 170. Alternatively, this documentation may be hosted by a server on the ground.
  • the MEL list is, meanwhile, hosted in the avionics area, for example in the diagnostic terminal.
  • an element of the MEL list When an element of the MEL list is selected by means of the third software module, it transmits via the network to the fourth module a hyperlink pointing to a URL giving the documentation page relating to this element.
  • the fourth software module retrieves this page and displays it on the information terminal screen. In this way, the path of the elements of the MEL list automatically and synchronously induces a presentation of the corresponding documentation pages by the information terminal.
  • FIG. 4 gives an example of a diagnostics tree used by the diagnostic module 115, corresponding to a determined fault code, noted here TSM 31-50-810-982-A, corresponding to a failure of the software of a system of diagnosis.
  • flight alarm FWS 2 Flight Warning System
  • the part of the tree relating to the confirmation procedure and the part relating to the isolation procedure are separated by a horizontal dashed line.
  • FIGS. 5A to 5G show the contents of the screens of the OMT terminal and the information terminal for an example of a path of the diagnostics shaft shown in FIG. 4.
  • the root 410 of the diagnostics tree 400 is associated with a documentation page shown in the left-hand part of FIG. 5A. This page shows the main steps of the procedure for confirming and isolating the fault.
  • the diagnostic module tests the failure indicated in the logbook. In this case, the status of the fault is confirmed (node 421) and therefore the diagnostic module proceeds to node 441.
  • the node 441 is associated with the execution of an integrated test program (BITE) of a unit (LRU) of the FWS system called CPIOM-C2 (Core Processing Input / Output Module).
  • BITE integrated test program
  • CPIOM-C2 Core Processing Input / Output Module
  • the screen of the terminal OMT indicates the degree of completion of the test program, and the information screen the details of the corresponding procedure.
  • the program returns an error code as indicated on the screen of the OMT terminal in FIG. 5C.
  • the failure of the CPIOM-C2 unit is therefore isolated (node 441 of the diagnostics tree).
  • Node 451 corresponds to a procedure for replacing the CPIOM-C2 unit, as illustrated in FIG.
  • the information terminal screen indicates the detail.
  • the circuit breaker of the CPI0M-C2 power supply circuit is activated, that is, its power supply is cut off, and then in a second step (see Fig. 5E) a new unit is installed.
  • the diagnostics module tests the FWS again, that is, returns to root 410 of the diagnostics tree.
  • the test of the system proves this time satisfactory (absence of error code), as indicated in FIG. 4G.
  • the documentation page is of course the same as that displayed during the first pass in the diagnostic tree.
  • the maintenance operator therefore concludes that the fault has been repaired and bears the corresponding mention in the logbook.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Automation & Control Theory (AREA)
  • Computer Hardware Design (AREA)
  • Human Computer Interaction (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Debugging And Monitoring (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Test And Diagnosis Of Digital Computers (AREA)

Abstract

La présente invention concerne un système informatique de maintenance d'un aéronef équipé d'un réseau partitionné en une zone sécurisée, dite avionique (101), et une zone ouverte (102). Le système comprend un premier module logiciel hébergé dans la zone avionique et un second module logiciel hébergé dans la zone ouverte, le premier module étant adapté à parcourir un arbre de diagnostic, le second module étant adapté à présenter une documentation électronique de maintenance, le parcours de l'arbre de diagnostic par le premier module induisant de manière automatique et synchrone une présentation par le second module de pages de ladite documentation de maintenance respectivement associées à ces nœuds.

Description

SYSTÈME INFORMATIQUE DE MAINTENANCE D'UN AÉRONEF
DESCRIPTION
DOMAINE TECHNIQUE La présente invention concerne de manière générale le domaine de la maintenance aéronautique.
ÉTAT DE LA TECHNIQUE ANTÉRIEURE
Traditionnellement, la maintenance d'un aéronef est effectuée au sol par des techniciens de maintenance au moyen d'une documentation papier.
Cette documentation se présentait autrefois sous forme de manuels ou de classeurs de maintenance et de réparation, respectivement désignés par les acronymes AMM (Aircraft Maintenance Manual) et TSM
(TroubleShooting Manual) . Elle décrivait de manière exhaustive les procédures de maintenance préventive, de détection et de réparation des pannes pouvant affecter un équipement quelconque de l'aéronef. De manière similaire, les remarques des pilotes étaient consignées dans un journal de bord ou « logbook » sous forme papier. Les techniciens de maintenance utilisaient alors ce journal à l'escale pour les besoins de la maintenance. Plus récemment, avec la tendance de diminuer voire de supprimer tout papier dans le cockpit (Less Paper Cockpit) les manuels AMM, TSM et le journal de bord ont été remplacés par des applications informatiques embarquées. Plus précisément, les manuels AMM et TSM se présentent désormais sous la forme de documents électroniques dans laquelle l'opérateur de maintenance peut librement naviguer grâce à des hyperliens. Ces documents contiennent une description des équipements de l'aéronef et des pannes qui peuvent les affecter, permettant à l'opérateur de maintenance d'identifier et de résoudre la panne.
De manière similaire, le journal de bord se présente aussi sous la forme d'un document électronique, dit « eLogbook ».
Les documents électroniques précités sont également liés entre eux au moyen d'hyperliens, de sorte que l'opérateur peut aisément passer d'une application à l'autre.
En outre, un système de maintenance centralisé, dit CMS (Centralised Maintenance System) permet de lancer le test d'un équipement à distance lorsque celui-ci est équipé d'un module de test intégré ou BITE (Built In Test Equipment) , de recevoir les messages d'erreurs éventuels et de les corréler entre eux ou avec des pannes de manière à faciliter le diagnostic .
L'opérateur de maintenance a donc à sa disposition une pluralité d'outils informatiques disparates qu' il doit maîtriser pour pouvoir diagnostiquer et résoudre une panne éventuelle.
En outre, ces outils de maintenance présentent un certain nombre d' insuffisances : Tout d'abord, l'opérateur n'est pas guidé de manière systématique dans son diagnostic : il est libre de suivre la procédure qui lui semble la plus appropriée et, le cas échéant, de sauter des étapes de test voire d'inverser l'ordre indiqué dans le manuel, avec le risque d'une convergence plus ou moins rapide selon les options qui auront été prises.
Ensuite, dans les avions de conception récente, du fait de la partition du réseau embarqué en une zone sécurisée et une zone non sécurisée, il est délicat de prévoir où seront hébergées les applications informatiques relatives à la maintenance. Plus précisément, le réseau embarqué est généralement partitionné en deux sous-réseaux, le premier localisé dans une zone dite avionique, le second dans une zone dite ouverte ou non sécurisée. Les liaisons entre les deux sous-réseaux sont obligatoirement unidirectionnelles, dirigées du sous-réseau avionique vers le sous-réseau ouvert. En revanche, à l'intérieur d'un même sous-réseau les liaisons peuvent être bidirectionnelles . L'hébergement des outils de maintenance dans la zone ouverte ne permettrait pas de garantir leur intégrité, autrement dit de se prémunir efficacement contre un accès malveillant et/ou une corruption des programmes et des données qui les constituent. Par voie de conséquence, les outils de maintenance ne seraient pas susceptibles de faire l'objet d'une certification. En outre, une mauvaise utilisation des outils de maintenance (tests intempestifs ou incohérents) pourrait être préjudiciable au bon fonctionnement des systèmes de la zone avionique. A l'inverse, un hébergement de ces outils dans une zone avionique ne serait guère envisageable car il nécessiterait un développement d'applications spécifiques, particulièrement coûteux, et n'autoriserait pas la possibilité d'effectuer de fréquentes mises à jour.
Un but de la présente invention est de proposer un outil de maintenance d'un aéronef qui ne présente pas les inconvénients précités, c'est-à-dire, d'une part, qui permette de guider l'opérateur de manière systématique et d'autre part, qui offre une implémentation compatible avec la partition du réseau embarqué .
EXPOSÉ DE L'INVENTION
La présente invention est définie par un système informatique de maintenance d'un aéronef équipé d'un réseau partitionné en une zone sécurisée, dite avionique, et une zone ouverte, ledit système informatique comprenant un premier module logiciel hébergé dans la zone avionique et un second module logiciel hébergé dans la zone ouverte, le premier module étant adapté à parcourir un arbre de diagnostic, le second module étant adapté à présenter une documentation électronique de maintenance, le parcours de l'arbre de diagnostic par le premier module induisant de manière automatique et synchrone une présentation par le second module de pages de ladite documentation de maintenance respectivement associées à ces nœuds. Avantageusement, chaque nœud dudit arbre de diagnostic correspond au moins une tâche de maintenance et que le premier module transmet au second module un hyperlien pointant vers une page de la documentation de maintenance associée à cette tâche lorsque le premier module atteint ledit nœud.
Le premier module détermine typiquement le nœud suivant en fonction du résultat de l'exécution de ladite tâche de maintenance correspondant à ce nœud. L'arbre de diagnostic est déterminé par exemple à partir d'un code identificateur de panne, ledit code étant lui-même obtenu à partir d'une analyse d'une entrée d'un journal de bord électronique hébergé dans la zone avionique. Si le premier module détermine qu'un équipement de l'aéronef est défaillant au terme du parcours de l'arbre de diagnostic, ledit système peut être adapté à vérifier la présence de cet équipement dans une liste minimale d'équipements de l'aéronef, dite liste MEL, hébergée dans la zone avionique.
Si ledit équipement défaillant est présent dans la liste MEL, le système est adapté à calculer le coût correspondant en termes de pertes de performances fonctionnelles ou de marges de sécurité de l'aéronef. On peut prévoir en outre un troisième module logiciel, hébergé dans la zone avionique, et un quatrième module logiciel, hébergé dans la zone ouverte, le troisième module étant adapté à parcourir et sélectionner les éléments de la liste MEL, le quatrième module logiciel à présenter des pages de documentation correspondant aux dits équipements, la sélection d'un élément par ledit troisième module logiciel induisant de manière automatique et synchrone une présentation par le quatrième module d'une page de documentation relative à cet élément. Pour chaque élément de la liste MEL, le troisième module transmet avantageusement au quatrième module, un hyperlien pointant vers une URL contenant ladite page de documentation relative à cet élément.
Le premier module et, le cas échéant le troisième module, peut (peuvent) être hébergé (s) dans un premier ordinateur de la zone avionique et que le second module et, le cas échéant le quatrième module, peut (peuvent) être hébergé (s) dans un second ordinateur de la zone ouverte, le second ordinateur étant alors relié à la partie du réseau de la zone avionique par une liaison unidirectionnelle vers la zone ouverte et un point d'accès sans fil.
Selon une variante, le premier module et, le cas échéant le troisième module, peut (peuvent) hébergé (s) dans un premier ordinateur de la zone avionique et que le second module et, le cas échéant le quatrième module, peut (peuvent) hébergé (s) dans un second ordinateur de la zone ouverte, les entrées/ sorties des premier et second ordinateurs étant reliées à un commutateur KVM, ledit commutateur étant adapté à commuter lesdits entrées/sorties vers une interface d'entrée/sortie commune.
BRÈVE DESCRIPTION DES DESSINS D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture d'un mode de réalisation préférentiel de l'invention fait en référence aux figures jointes parmi lesquelles :
La Fig. 1 illustre schématiquement un premier mode de réalisation du système de maintenance selon l'invention ;
La Fig. 2 illustre schématiquement une variante de réalisation du système de maintenance selon 1' invention ;
La Fig. 3 illustre l'opération du système de maintenance selon l'invention ;
La Fig. 4 donne un exemple d'arbre de diagnostic ;
Les Figs . 5A à 5G représentent le contenu d'un premier écran et d'un second écran du système de maintenance, lors de la progression du module de diagnostic le long de nœuds successifs de l'arbre de diagnostic .
EXPOSÉ DÉTAILLÉ DE MODES DE RÉALISATION PARTICULIERS
L'idée à la base de l'invention est de prévoir un système de maintenance comportant un premier module logiciel hébergé dans la zone avionique et un second module logiciel hébergé dans la zone ouverte, le premier étant un module de diagnostic adapté à effectuer un parcours dans un arbre de diagnostic, le second étant dédié à la présentation de la documentation de maintenance, le parcours de nœuds de l'arbre de diagnostic induisant de manière automatique et synchrone une présentation des pages de documentation respectivement associées à ces nœuds. La Fig. 1 illustre un système informatique de maintenance selon un mode de réalisation de 1' invention .
Le système est composé de deux parties 101 et 102 respectivement comprises dans la zone avionique AW et la zone ouverte OW. Chacune des parties du système comprend une pluralité d'équipements reliés entre eux grâce à des liaisons bidirectionnelles, par exemple des liaisons virtuelles d'un réseau Ethernet commuté. En revanche, les deux parties ne sont reliées entre elles que par une ou plusieurs liaison (s) unidirectionnelle (s) dirigée (s) de la zone AW vers la zone OW, symbolisées sur la figure par des diodes.
La partie de la zone avionique comprend un terminal de maintenance 110 ou OMT (Onboard Maintenance Terminal) hébergeant un système de maintenance centralisé (CMS), 113. Ce système comprend notamment un premier module logiciel, dit module de diagnostic, 115, adapté à parcourir un arbre de diagnostic prédéterminé. Le terminal OMT héberge également un module logiciel 120, chargé de la gestion du journal de bord. Le terminal OMT est par ailleurs relié à des modules de test intégrés, 130, implémentés dans certains équipements à tester, ainsi qu'à une unité 160 chargée de contrôler l'ensemble des disjoncteurs relatifs à ces équipements. L'activation d'un disjoncteur permet de couper l'alimentation d'un ou de plusieurs équipements pour procéder à son remplacement en toute sécurité. Enfin, le terminal OMT possède une interface entrée/sortie 150 comprenant notamment un écran d'affichage et un clavier. La partie du système dans la zone ouverte comprend un terminal permettant la consultation de la documentation de maintenance, ci-après dénommé terminal d'information. Ce terminal peut par exemple prendre la forme d'un ordinateur portable, 190, ou d'une ardoise électronique (Tablet PC™), 195. La documentation de maintenance est hébergée soit directement dans l'ordinateur portable 190 ou l'ardoise électronique 195, si sa taille mémoire est suffisamment faible, soit dans un serveur embarqué 170, dans le cas contraire. L'ordinateur portable ou l'ardoise électronique pourra être relié par une liaison sans fil au réseau filaire via un point d'accès AP. Si le point d'accès est connecté à la partie avionique du réseau, cette connexion est réalisée au moyen d'une liaison unidirectionnelle 181, comme indiqué sur la figure. Des commutateurs de trames notés SW permettent le routage sur les différentes liaisons du réseau.
Selon un second mode de réalisation représenté en Fig. 2, une interface entrée/sortie commune 155 (clavier, écran et le cas échéant souris) est partagée entre l'ordinateur 110 hébergeant le module de diagnostic et l'ordinateur 191 hébergeant la documentation de maintenance. Les entrées/sorties de ces ordinateurs sont reliées à travers le commutateur KVM (Keyboard Video Mouse) 185, à cette interface d'entrée/sortie commune, ledit commutateur permettant de la commuter, de manière manuelle ou automatique, entre les deux ordinateurs. On notera que seul le signal vidéo de l'ordinateur 191 remonte de la zone ouverte à la zone avionique de sorte que la sécurité de cette dernière n'en est pas affectée. L'opérateur de maintenance peut ainsi basculer aisément de l'écran de diagnostic à l'écran de documentation, comme on le verra plus loin. En cas de survenance de panne, le système
CMS en est averti soit directement par un message transmis par le système de gestion des alarmes en vol, ou FWS (Flight Warning System) , soit par une remarque du pilote consignée comme entrée dans le journal de bord 120, soit encore par les deux conjointement. Le système CMS peut effectuer une corrélation entre différentes pannes de manière à rechercher la/les cause (s) probable (s) commune (s). Dans tous les cas, le système CMS fournit un code d'identification d'une panne probable, associé à un ou plusieurs équipement (s) remplaçable (s) ou LRUs (Line Replaceable ϋnits) .
Le module de diagnostic, 115, reçoit un code d'identification de panne et récupère l'arbre de diagnostic correspondant à ce code. Le module 115 est adapté à parcourir cet arbre de diagnostic selon les indications fournies par l'opérateur de maintenance et/ou les modules de test intégrés dans l'équipement à contrôler. L'arbre de diagnostic comprend généralement une première partie relative à la confirmation de la panne et une seconde partie, relative à la résolution proprement dite, au cas où la panne est effectivement confirmée .
Chaque nœud de l'arbre de diagnostic comprend une tâche ou une suite de tâches à effectuer dont le résultat détermine le choix du nœud suivant. A chaque nœud de l'arbre de diagnostic correspond une page de la documentation de maintenance destinée à être visualisée sur le terminal d'information 190 ou 195. Le parcours de l'arbre de diagnostic induit simultanément et automatiquement une navigation à travers les pages de la documentation associées aux nœuds traversés. Plus précisément, à chaque fois qu'un nœud est visité par le module de diagnostic un hyperlien est transmis par le terminal OMT au dit terminal. Ce dernier comprend un module de navigation qui se synchronise automatiquement en recherchant l'URL pointée par l'hyperlien. La page correspondante peut être récupérée localement dans le terminal d' information si la documentation y est stockée ou encore si ladite page est disponible dans la mémoire cache, ou bien dans le serveur embarqué 170. Alternativement, la page de documentation peut être récupérée à partir d'un serveur au sol.
L'opérateur de maintenance est ainsi guidé systématiquement dans la procédure de diagnostic tout en pouvant consulter la documentation de maintenance afférente à chacune des étapes de la procédure.
Le stockage de la documentation de maintenance dans la zone ouverte facilite les opérations de mise à jour. Cette dernière peut être effectuée par exemple au moyen d'un procédé de téléchargement de données conforme au protocole ARINC 615 ou par simple remplacement d'un support mémoire. La mise à jour laisse généralement l'arbre de diagnostic inchangé, ce qui garantit l'intégrité du système de maintenance . L'arbre de diagnostic peut être extrait à partir de la documentation de maintenance existante, c'est-à-dire des manuels AMM et TSM précités. Plus précisément, l'arbre de diagnostic correspond à l'arborescence du manuel TSM. Lorsqu'une étape de la procédure de réparation d'une panne, correspondant à un nœud de l'arborescence du manuel TSM, nécessite l'exécution de certaines tâches de maintenance du manuel AMM. Dans ce cas l'arbre constitutif de ces tâches est greffé localement au nœud précité. L'ensemble des nœuds de l'arborescence du manuel TSM auxquels sont ainsi greffés les arbres des tâches de maintenance afférentes à ces nœuds, forme l'arbre de diagnostic . Si les manuels AMM et TSM se présentent sous forme de documents au format XML ou SGML, l'arbre de diagnostic sera obtenu en supprimant les éléments de représentation visuelle, par exemple les éléments de mise en page, les images, les schémas en trois dimensions, les scripts d'animation. Ces éléments sont rejetés dans la partie documentation. En revanche, tous les éléments fonctionnels seront conservés dans l'arbre de diagnostic, notamment les hyperliens permettant de lancer des applications de test, de télécharger un logiciel pour un équipement, d'activer ou de désactiver un disjoncteur, etc.
On obtient ainsi d'une part un arbre de diagnostic et d' autre part un fichier purement documentaire, les deux étant, par exemple, au format XML ou SGML mais possédant des DTDs distinctes. En outre, à chaque nœud de l'arbre de diagnostic est associé un hyperlien vers une page du fichier documentaire .
L'arbre de diagnostic et le fichier documentaire peuvent également être élaborés en parallèle, à condition toutefois de respecter leurs
DTDs respectives et la cohérence des hyperliens entre les deux documents.
La Fig. 3 illustre un exemple de fonctionnement du système informatique de maintenance selon l'invention.
Un code d' identification de panne est transmis au module de diagnostic, à partir par exemple d'une consigne du journal de bord. Le module de diagnostic recherche l'arbre de diagnostic (indiqué ici par « Task N ») correspondant à ce code. Cet arbre est divisé en deux parties notées (I) et (II) correspondant respectivement à la procédure de confirmation de panne et la procédure de résolution de panne.
Lors du parcours de l'arbre de diagnostic, la présentation de la documentation de maintenance est synchronisée au passage par chaque nœud de l'arbre. Par exemple, lorsque le module de diagnostic passe par le nœud 5, la page de documentation relative à la sous- tâche 5 est affichée sur le terminal d'information. Il convient de noter cependant que le passage d'un nœud au suivant ne requiert pas nécessairement un changement de la page à afficher. En outre, l'opérateur de maintenance peut naviguer à sa guise au sein de la documentation grâce à des hyperliens. Par exemple, l'opérateur peut cliquer sur l'hyperlien « subtask 5- 2 » pour voir la page relative à cette sous-tâche. Toutefois, dès lors que le module de diagnostic passera au nœud suivant (en l'occurrence le nœud 8), la page de documentation relative à ce dernier nœud (« subtask 8 ») s'affichera automatiquement à l'écran du terminal d'information.
Au terme du parcours de l'arbre de diagnostic, soit la panne est résolue, soit la panne subsiste et la mention correspondante est consignée dans le journal de bord. Si la panne subsiste, les équipements défectueux sont listés et comparés avec le contenu de la liste minimale d'équipements ou MEL (Minimum Equipment List) . Cette liste, contrairement à ce que son nom l'indique, donne la liste d'équipements dont le bon fonctionnement est facultatif pour l'opération de l'appareil. Ainsi, si un équipement diagnostiqué comme défectueux ne se trouve pas dans la liste, le vol doit être annulé. En revanche, si un équipement diagnostiqué comme défectueux est dans la liste MEL, le système détermine les contraintes imposées par le dysfonctionnement de l'équipement et le coût qui y est associé en termes de pertes de performances fonctionnelles ou de marges de sécurité. Par exemple, le dysfonctionnement d'un équipement pourra imposer une contrainte sur la quantité de carburant que l'aéronef pourra embarquer, ce qui se traduira à son tour par une limite de son rayon d'action. Les coûts précités sont stockés dans un fichier hébergé dans la zone avionique.
Selon une variante de réalisation non représentée, le système informatique selon l'invention comprend un troisième module logiciel, hébergé dans la zone avionique, par exemple dans le terminal de diagnostic, permettant au pilote ou à l'opérateur de maintenance de parcourir la liste MEL et de sélectionner un équipement quelconque de cette liste. Le système informatique comprend également un quatrième module logiciel, hébergé dans la zone ouverte, par exemple dans le terminal d' information, chargé de l'affichage de la documentation relative aux éléments de la liste MEL. Cette documentation est hébergée dans la zone ouverte, par exemple par le terminal d'information ou le serveur embarqué 170. Alternativement, cette documentation pourra être hébergée par un serveur au sol. La liste MEL est, quant à elle, hébergée dans la zone avionique, par exemple dans le terminal de diagnostic.
Lorsqu'un élément de la liste MEL est sélectionné grâce au troisième module logiciel, il transmet via le réseau au quatrième module un hyperlien pointant vers une URL donnant la page de documentation relative à cet élément. Le quatrième module logiciel récupère alors cette page et l'affiche sur l'écran du terminal d'information. De cette manière le parcours des éléments de la liste MEL induit de manière automatique et synchrone une présentation des pages de documentation correspondantes par le terminal d' information.
La Fig. 4 donne un exemple d'arbre de diagnostic utilisé par le module de diagnostic 115, correspondant à un code de panne déterminé, noté ici TSM 31-50-810-982-A, correspondant à une panne du software d'un système d'alarme en vol FWS 2 (Flight Warning System) . La partie de l'arbre relative à la procédure de confirmation et celle relative à la procédure d'isolation sont séparées par un trait discontinu horizontal. Les Figures 5A à 5G montrent le contenu des écrans du terminal OMT et du terminal d'information pour un exemple de parcours de l'arbre de diagnostic représenté en Fig. 4.
La racine 410 de l'arbre de diagnostic 400 est associée à une page de documentation représentée dans la partie gauche de la Fig. 5A. Cette page indique les principales étapes de la procédure de confirmation et d'isolation de la panne. En 410, le module de diagnostic teste la panne indiquée dans le journal de bord. Dans le cas présent, le statut de la panne est confirmé (nœud 421) et par conséquent le module de diagnostic passe au nœud 441.
Le nœud 441 est associé à l'exécution d'un programme de test intégré (BITE) d'une unité (LRU) du système FWS dénommée CPIOM-C2 (Core Processing Input/Output Module) . Comme illustré en Fig. 5B, l'écran du terminal OMT indique le degré d'accomplissement du programme de test, et l'écran d' information les détails de la procédure correspondante . Dans le cas présent, au terme du test, le programme renvoie un code d'erreur comme indiqué sur l'écran du terminal OMT en Fig. 5C. La panne de l'unité CPIOM-C2 est par conséquent isolée (nœud 441 de l'arbre de diagnostic) . La page de documentation reste inchangée à ce stade. Le nœud 451 correspond à une procédure de remplacement de l'unité CPIOM-C2, comme illustré en Fig. 5D et l'écran du terminal d'information en indique le détail. Dans une première étape, le disjoncteur du circuit d'alimentation de l'unité CPI0M-C2 est activé, autrement dit son alimentation est coupée, puis dans une seconde étape (cf. Fig. 5E), une nouvelle unité est installée .
Un fois la nouvelle unité installée et l'alimentation rétablie, le module de diagnostic teste à nouveau le système FWS, c'est-à-dire retourne à la racine 410 de l'arbre de diagnostic. Le test du système se révèle cette fois-ci satisfaisant (absence de code d'erreur), comme indiqué en Fig. 4G. La page de documentation est bien entendu la même que celle affichée lors du premier passage dans l'arbre de diagnostic .
L'opérateur de maintenance conclut par conséquent que la panne a été réparée et porte la mention correspondante dans le journal de bord.

Claims

REVENDICATIONS
1. Système informatique de maintenance d'un aéronef équipé d'un réseau partitionné en une zone sécurisée, dite avionique (101), et une zone ouverte
(102), caractérisé en ce qu'il comprend un premier module logiciel hébergé dans la zone avionique et un second module logiciel hébergé dans la zone ouverte, le premier module étant adapté à parcourir un arbre de diagnostic, le second module étant adapté à présenter une documentation électronique de maintenance, le parcours de l'arbre de diagnostic par le premier module induisant de manière automatique et synchrone une présentation par le second module de pages de ladite documentation de maintenance respectivement associées à ces nœuds.
2. Système informatique selon la revendication 1, caractérisé en ce qu'à chaque nœud dudit arbre de diagnostic correspond au moins une tâche de maintenance et que le premier module transmet au second module un hyperlien pointant vers une page de la documentation de maintenance associée à cette tâche lorsque le premier module atteint ledit nœud.
3. Système informatique selon la revendication 2, caractérisé en ce que pour chaque nœud de l'arbre de diagnostic, le premier module détermine le nœud suivant en fonction du résultat de l'exécution de ladite tâche de maintenance correspondant à ce nœud.
4. Système informatique selon l'une des revendications précédentes, caractérisé en ce que l'arbre de diagnostic est déterminé à partir d'un code identificateur de panne, ledit code étant lui-même obtenu à partir d'une analyse d'une entrée d'un journal de bord électronique (120) hébergé dans la zone avionique .
5. Système informatique selon l'une des revendications précédentes, caractérisé en ce que, si le premier module détermine qu'un équipement de l'aéronef est défaillant au terme du parcours de l'arbre de diagnostic, ledit système est adapté à vérifier la présence de cet équipement dans une liste minimale d'équipements de l'aéronef, dite liste MEL, hébergée dans la zone avionique.
6. Système informatique selon la revendication 5, caractérisé en ce que, si ledit équipement défaillant est présent dans la liste MEL, le système est adapté à calculer le coût correspondant en termes de pertes de performances fonctionnelles ou de marges de sécurité de l'aéronef.
7. Système informatique selon les revendications 5 ou 6, caractérisé en ce qu'il comprend un troisième module logiciel, hébergé dans la zone avionique, et un quatrième module logiciel, hébergé dans la zone ouverte, le troisième module étant adapté à parcourir et sélectionner les éléments de la liste MEL, le quatrième module logiciel à présenter des pages de documentation correspondant aux dits équipements, la sélection d'un élément par ledit troisième module logiciel induisant de manière automatique et synchrone une présentation par le quatrième module d'une page de documentation relative à cet élément.
8. Système informatique selon la revendication 7, caractérisé en ce que, pour chaque élément de la liste MEL, le troisième module transmet au quatrième module, un hyperlien pointant vers une URL contenant ladite page de documentation relative à cet élément .
9. Système informatique selon l'une des revendications précédentes, caractérisé en ce que le premier module et, le cas échéant le troisième module, est (sont) hébergé (s) dans un premier ordinateur de la zone avionique et que le second module et, le cas échéant le quatrième module, est (sont) hébergé (s) dans un second ordinateur de la zone ouverte, le second ordinateur étant relié à la partie du réseau de la zone avionique par une liaison unidirectionnelle (181) vers la zone ouverte et un point d'accès sans fil (180) .
10. Système informatique selon l'une des revendications 1 à 8, caractérisé en ce que le premier module et, le cas échéant le troisième module, est (sont) hébergé (s) dans un premier ordinateur de la zone avionique et que le second module et, le cas échéant le quatrième module, est (sont) hébergé (s) dans un second ordinateur de la zone ouverte, les entrées/ sorties des premier et second ordinateurs étant reliées à un commutateur KVM, ledit commutateur étant adapté à commuter lesdits entrées/sorties vers une interface d'entrée/sortie commune (155).
EP08760549A 2007-06-15 2008-06-05 Système informatique de maintenance d'un aéronef Withdrawn EP2158525A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0755789A FR2917521B1 (fr) 2007-06-15 2007-06-15 Systeme informatique de maintenance d'un aeronef
PCT/EP2008/056970 WO2008155227A1 (fr) 2007-06-15 2008-06-05 Système informatique de maintenance d'un aéronef

Publications (1)

Publication Number Publication Date
EP2158525A1 true EP2158525A1 (fr) 2010-03-03

Family

ID=38963227

Family Applications (1)

Application Number Title Priority Date Filing Date
EP08760549A Withdrawn EP2158525A1 (fr) 2007-06-15 2008-06-05 Système informatique de maintenance d'un aéronef

Country Status (9)

Country Link
US (1) US8433475B2 (fr)
EP (1) EP2158525A1 (fr)
JP (1) JP5336477B2 (fr)
CN (1) CN101681160B (fr)
BR (1) BRPI0813340A2 (fr)
CA (1) CA2700933A1 (fr)
FR (1) FR2917521B1 (fr)
RU (1) RU2486566C2 (fr)
WO (1) WO2008155227A1 (fr)

Families Citing this family (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8341298B2 (en) 2005-12-02 2012-12-25 The Boeing Company Scalable on-board open data network architecture
US9719799B2 (en) * 2008-12-12 2017-08-01 Honeywell International Inc. Next generation electronic flight bag
WO2010119597A1 (fr) 2009-04-13 2010-10-21 シャープ株式会社 Appareil d'affichage, appareil d'affichage à cristaux liquides, procédé de commande pour appareil d'affichage et récepteur de télévision
FR2950176B1 (fr) * 2009-09-11 2012-12-14 Airbus Operations Sas Procede et dispositif d'acces a la documentation et performance d'un aeronef selon des alarmes generees dans ce dernier
US20110179390A1 (en) * 2010-01-18 2011-07-21 Robert Paul Morris Methods, systems, and computer program products for traversing nodes in path on a display device
GB2492328A (en) * 2011-06-24 2013-01-02 Ge Aviat Systems Ltd Updating troubleshooting procedures for aircraft maintenance
FR2981446B1 (fr) * 2011-10-14 2013-11-15 Thales Sa Procede de reinitialisation rapide pour dispositif de visualisation de planche de bord
US9571181B2 (en) 2012-03-01 2017-02-14 Honeywell International Inc. Programmable portable electronic device for airborne operational communications
FR2989500B1 (fr) * 2012-04-12 2014-05-23 Airbus Operations Sas Procede, dispositifs et programme d'ordinateur d'aide a l'analyse de la tolerance aux pannes d'un systeme d'un aeronef, utilisant des graphes d'evenements redoutes
CN103455161A (zh) * 2012-06-01 2013-12-18 南京神易网络科技有限公司 一种安全kvm切换器
US9334063B2 (en) * 2012-09-10 2016-05-10 Rosemount Aerospace, Inc. Aircraft avionics tablet interface module
US9563580B2 (en) 2013-07-25 2017-02-07 North Flight Data Systems, LLC System, methodology, and process for wireless transmission of sensor data onboard an aircraft to a portable electronic device
US9260182B2 (en) 2013-10-30 2016-02-16 Westjet Airlines Ltd. Integrated communication and application system for aircraft
EP3108615B1 (fr) 2014-02-21 2019-01-02 Astronautics Corporation Of America Système de communication d'informations avioniques via des dispositifs électroniques portables
US10375087B2 (en) * 2014-07-21 2019-08-06 Honeywell International Inc. Security architecture for the connected aircraft
FR3026882B1 (fr) * 2014-10-02 2016-11-04 Snecma Procede de determination d'au moins un equipement defaillant d'un aeronef et systeme correspondant
CN104318491B (zh) * 2014-10-27 2017-05-10 国家电网公司 多源互联配电网检修防误操作验算方法
US9550583B2 (en) 2015-03-03 2017-01-24 Honeywell International Inc. Aircraft LRU data collection and reliability prediction
US9590718B1 (en) 2015-09-22 2017-03-07 Honeywell International Inc. End-to-end wireless connectivity between vehicle and remote server using wireless radios of two mobile devices
US10191479B2 (en) 2015-09-29 2019-01-29 General Electric Company Methods and systems for network-based detection of component wear
FR3047340B1 (fr) 2016-02-02 2019-10-18 Dassault Aviation Systeme d'aide a la decision d'autorisation a partir d'un aeronef, et procede associe
FR3049415B1 (fr) * 2016-03-25 2018-04-20 Sagem Defense Securite Procede de gestion et de maintenance d’un aeronef comportant une zone de haut degre de securite
FR3050351B1 (fr) * 2016-04-15 2018-05-11 Thales Procede de controle d'integrite de l'avionique d'un aeronef, dispositif et produit programme d'ordinateur associes
US10067817B2 (en) 2016-05-25 2018-09-04 International Business Machines Corporation Equipment failure risk detection and prediction in industrial process
US11210434B2 (en) 2017-10-17 2021-12-28 Textron Innovations Inc. Fault isolation
CN111504341B (zh) * 2020-04-30 2023-09-19 中国直升机设计研究所 一种直升机飞行状态识别方法
CN111698288B (zh) * 2020-05-11 2023-04-07 北京空间技术研制试验中心 一种基于以太网面向无连接的星上软件在轨维护方法
CN116360394A (zh) * 2023-03-24 2023-06-30 北京控制工程研究所 卫星控制系统在轨故障信息的获取方法及装置

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6115656A (en) * 1997-06-17 2000-09-05 Mcdonnell Douglas Corporation Fault recording and reporting method
US6208955B1 (en) * 1998-06-12 2001-03-27 Rockwell Science Center, Llc Distributed maintenance system based on causal networks
RU2163745C2 (ru) * 1999-04-29 2001-02-27 Щеглов Андрей Юрьевич Система защиты виртуального канала корпоративной сети с аутентифицирующим маршрутизатором, построенной на каналах и средствах коммутации сети связи общего пользования
TW498228B (en) * 1999-11-24 2002-08-11 Elegent Technologies Inc Self-contained network browser with diagnostic abilities
US6574537B2 (en) * 2001-02-05 2003-06-03 The Boeing Company Diagnostic system and method
RU2181334C1 (ru) * 2001-06-08 2002-04-20 Владимиров Игорь Михайлович Способ оценки технического состояния агрегатов несущей системы вертолета для продления ресурса
FR2838585B1 (fr) * 2002-04-15 2004-12-10 Airbus France Procede et dispositif de transmission de donnees sur un aeronef
FI113121B (fi) * 2002-05-30 2004-02-27 Metso Automation Oy Järjestelmä, tietoliikenneverkko ja menetelmä tietojen lähettämiseksi
US8510083B2 (en) * 2003-07-31 2013-08-13 The Boeing Company Method, apparatus and computer program product for constructing a diagnostic network model
US7149612B2 (en) * 2004-01-05 2006-12-12 Arinc Incorporated System and method for monitoring and reporting aircraft quick access recorder data
US7167788B2 (en) * 2004-01-30 2007-01-23 United Technologies Corporation Dual-architecture microserver card
RU2276466C1 (ru) * 2004-11-10 2006-05-10 Общество с ограниченной ответственностью Фирма "Анкад" Способ создания защищенных виртуальных сетей
US7668632B2 (en) * 2004-11-22 2010-02-23 The Boeing Company System, method and computer program product for real-time event identification and course of action interpretation
US7788002B2 (en) * 2005-08-08 2010-08-31 The Boeing Company Fault data management
US8341298B2 (en) * 2005-12-02 2012-12-25 The Boeing Company Scalable on-board open data network architecture
US7756145B2 (en) * 2005-12-02 2010-07-13 The Boeing Company Methods and apparatus providing an airborne e-enabled architecture as a system of systems
US7983809B2 (en) * 2007-12-21 2011-07-19 Sikorsky Aircraft Corporation Aircraft integrated support system (ISS)
US8306685B2 (en) * 2008-04-17 2012-11-06 The Boeing Company Electronic logbook flight preparation system and method
US9719799B2 (en) * 2008-12-12 2017-08-01 Honeywell International Inc. Next generation electronic flight bag
FR2949161B1 (fr) * 2009-08-14 2011-09-09 Thales Sa Dispositif pour le diagnostic de systeme

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2008155227A1 *

Also Published As

Publication number Publication date
FR2917521A1 (fr) 2008-12-19
RU2010101065A (ru) 2011-07-20
JP2010529921A (ja) 2010-09-02
RU2486566C2 (ru) 2013-06-27
WO2008155227A1 (fr) 2008-12-24
CN101681160B (zh) 2013-08-21
CN101681160A (zh) 2010-03-24
FR2917521B1 (fr) 2009-10-02
US20100198431A1 (en) 2010-08-05
CA2700933A1 (fr) 2008-12-24
BRPI0813340A2 (pt) 2014-12-23
JP5336477B2 (ja) 2013-11-06
US8433475B2 (en) 2013-04-30

Similar Documents

Publication Publication Date Title
WO2008155227A1 (fr) Système informatique de maintenance d'un aéronef
EP2145426B1 (fr) Systeme de communication entre un reseau d'ordinateurs dans un aeronef et un reseau d'ordinateurs au sol
EP0780746B1 (fr) Dispositif de surveillance d'un système complexe, notamment d'un aéronef
US8509990B2 (en) System and method for performing real-time data analysis
FR2935186A1 (fr) Procede et dispositif d'aide au diagnostic et a la decision d'exploitation d'un aeronef
FR2915292A1 (fr) Procede et systeme de modification d'un contenu d'un message d'alerte a bord d'un aeronef.
FR2953954A1 (fr) Dispositif d'elaboration des alertes d'un systeme d'aeronef
EP2975363B1 (fr) Traitement des messages d'alarmes et de maintenance d'un aeronef
WO2016034824A1 (fr) Architecture bi-voies avec liaisons ccdl redondantes
BR102012015582A2 (pt) Sistema, método e produto de programa de computador
CN101651669A (zh) 业务箱集成服务器和业务箱集成方法
FR2950177A1 (fr) Procede et dispositif de gestion d'informations dans un aeronef
FR2978264A1 (fr) Un procede de rechargement automatique de logiciel et un dispositif de rechargement automatique de logiciel
EP2874106A1 (fr) Système et procédé de diagnostic de panne aéronef
FR3007000A1 (fr) Systeme de surveillance d'une plateforme avionique a architecture trois tiers
FR3027386A1 (fr) Procede et dispositif d'aide a la gestion de procedures, notamment de pannes de systemes d'un aeronef.
FR3001556A1 (fr) Procede, dispositif et programme d'ordinateur d'aide a la maintenance d'un systeme d'un aeronef utilisant un outil d'aide au diagnostic et des donnees de retour d'experience
WO2007036462A1 (fr) Procede et systeme de diagnostic des pannes pour aerodynes
EP2149823A1 (fr) Système aéronautique embarqué à reconfiguration dynamique, procédé associé et aéronef embarquant un tel système
EP1846824B1 (fr) Systeme et procede de traitements embarques d'essais en vol
CN112882892B (zh) 数据处理方法和装置、电子设备及存储介质
FR2938675A1 (fr) Dispositif permettant l'amelioration des procedures de maintenance d'equipements embarques
FR3089375A1 (fr) Procédé et système de protection d’un aéronef contre une instruction de commande incohérente
FR3001065A1 (fr) Dispositif centralise pour la gestion automatique de la configuration et de la reconfiguration de systemes multiples d'un aeronef.
FR2999318A1 (fr) Procede d'evaluation de la surete de fonctionnement d'un systeme complexe

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20091214

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MT NL NO PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL BA MK RS

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20110810

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20180103