FR2935187A1 - Procede et dispositif de partage de donnees entre des systemes embarques dans un aeronef - Google Patents

Abstract

L'invention a notamment pour objet un procédé et un dispositif d'échange de données entre un système de gestion technique d'un aéronef et un système de gestion de mission dudit aéronef pour permettre à l'un desdits systèmes de déterminer les conséquences d'un événement détecté dans l'autre desdits systèmes. Après avoir détecté (300) au moins un événement dans l'un desdits systèmes de gestion technique et de gestion de mission dudit aéronef, au moins une information relative audit événement détecté est transmise (320) à l'autre desdits systèmes de gestion technique et de gestion de mission dudit aéronef. Les conséquences dudit événement détecté dans ledit autre desdits systèmes de gestion technique et de gestion de mission dudit aéronef sont ensuite déterminées (330). L'adaptation d'au moins une donnée dudit autre desdits systèmes de gestion technique et de gestion de mission dudit aéronef est évaluée en réponse à ladite étape de détermination.

Description

La présente invention concerne la gestion des systèmes embarqués dans les aéronefs et plus particulièrement un procédé et un dispositif de partage de données entre des systèmes embarqués dans un aéronef pour améliorer l'interface de contrôle de ces systèmes. Les systèmes électroniques et informatiques embarqués à bord des aéronefs visent des fonctionnalités distinctes. Un premier type de systèmes, appelé avionique, concerne l'assistance à l'équipage de l'aéronef pour assurer ses tâches de pilotage, de navigation, de communication, de surveillance de l'environnement et de gestion de la mission. Ce type de systèmes vise notamment les systèmes de commande de vol, le pilote automatique, les systèmes de communication (orale et de données) et de navigation (radio, inertielle et autonome) et les systèmes de surveillance de l'environnement (radar météo, anticollision terrain et anticollision trafic). En particulier, les systèmes de gestion de mission permettent au pilote de gérer sa trajectoire (préparation au sol, suivi et modification en vol) à partir des prescriptions de la compagnie aérienne, de l'intégration de l'aéronef dans le trafic aérien et de l'environnement comme la météorologie et les NOTAMs (acronyme de NOtice To Air Men en terminologie anglo-saxonne). Le deuxième type de systèmes vise la génération et la distribution électrique, la génération et la distribution hydraulique, la génération pneumatique, la climatisation et la pressurisation, la gestion du carburant et le moteur auxiliaire de puissance, appelés servitudes de l'aéronef. Ces systèmes sont indépendants les uns des autres. Ils sont contrôlés par des interfaces distinctes. Généralement, les interfaces de contrôle de l'avionique et de gestion de mission se trouvent face au pilote et sur ses côtés, sous le niveau du pare-brise, l'interface de contrôle des servitudes étant placée au plafond, entre le pilote et le copilote pour être accessible par chacun d'eux.

La figure 1 est une représentation schématique d'un cockpit d'aéronef présentant la position des interfaces de contrôle des différents systèmes de l'aéronef. Comme représenté, l'interface du cockpit 100 peut se décomposer en cinq zones principales : les commandes de vol du pilote et du copilote, référencées 105-1, 105-2 et 105-3, les interfaces de contrôle de l'avionique et de gestion de mission référencées 110, 115 et 120, la zone 120 ayant pour principal objet le contrôle du pilote automatique, et l'interface de commande des servitudes référencée 125.

Les commandes de vol référencées 105-1 à 105-3 ont pour objet de contrôler les principaux dispositifs utilisés pour piloter un aéronef et contrôler ainsi, en particulier, le lacet, le tangage et le roulis. Ces commandes sont souvent mécaniques ou électriques. L'interface de contrôle de l'avionique comprend généralement un nombre important de boutons ayant chacun une fonction particulière. Ces boutons sont essentiellement des boutons multi-positions, notamment de type marche/arrêt ainsi que des boutons de type rotacteur permettant de définir des valeurs. L'interface de gestion de mission comprend, en raison de la nature complexe des informations entrées, des touches de saisie alphanumériques et des dispositifs de pointage. Le dispositif de pointage est, par exemple, une boule de commande, appelé trackball en terminologie anglo-saxonne, ou un pavé tactile, appelé touchpad en terminologie anglo-saxonne. L'interface de commande des servitudes, installée dans le plafonnier et appelée OVHP (sigle de OVer Head Panel en terminologie anglo-saxonne) ou OVH, comprend essentiellement des boutons multi-positions, notamment de type marche/arrêt ainsi que des boutons de type rotacteur. Ces boutons sont généralement pourvus d'un système d'éclairage, par exemple par transparence, permettant d'indiquer une anomalie de la fonctionnalité liée au bouton. Ce système de signalisation par éclairage des boutons permet la mise en place d'une philosophie de gestion des systèmes, appelée dark cockpit philosophy en terminologie anglo-saxonne, qui consiste à indiquer l'état nominal d'une fonction par l'état éteint de ses boutons de commande et, à l'inverse, à indiquer un état anormal par l'état allumé de ses boutons de commande. L'application de cette philosophie permet ainsi d'identifier rapidement un bouton lorsqu'un problème est détecté et de visualiser le statut de l'ensemble des servitudes.

Alors que les interfaces de contrôle de l'avionique, de contrôle des servitudes et de gestion de mission donnent toute satisfaction aux pilotes, elles présentent néanmoins certains inconvénients. En particulier, la complexité des procédures à suivre, notamment lorsqu'une défaillance est détectée, combinée au nombre de boutons du cockpit peut conduire à une erreur du pilote.

L'invention a pour objet d'améliorer l'interface du cockpit afin de réduire la charge de travail du pilote et d'améliorer la sécurité des aéronefs. L'invention a ainsi pour objet un procédé d'échange de données entre un système de gestion technique d'un aéronef et un système de gestion de mission dudit aéronef pour permettre à l'un desdits systèmes de déterminer les conséquences d'un événement détecté dans l'autre desdits systèmes, ce procédé comprenant les étapes suivantes, - détection d'au moins un événement dans l'un desdits systèmes de gestion technique et de gestion de mission dudit aéronef ; - transmission d'au moins une information relative audit événement détecté à l'autre desdits systèmes de gestion technique et de gestion de mission dudit aéronef ; - détermination des conséquences dudit événement détecté dans ledit autre desdits systèmes de gestion technique et de gestion de mission dudit aéronef ; et, - évaluation de l'adaptation d'au moins une donnée dudit autre desdits systèmes de gestion technique et de gestion de mission dudit aéronef en réponse à ladite étape de détermination. Le procédé selon l'invention permet ainsi d'améliorer l'interface de contrôle des systèmes de l'aéronef, de réduire la charge de travail de l'équipage et de limiter les risques d'erreurs liées, notamment, à de mauvaises saisies.

Avantageusement, le procédé comprend en outre une étape de modification de ladite au moins une donnée dudit autre desdits systèmes de gestion technique et de gestion de mission dudit aéronef en réponse à ladite étape d'évaluation de l'adaptation de ladite au moins une donnée. Le procédé selon l'invention permet ainsi de réduire encore la charge de travail de l'équipage et de limiter les risques d'erreurs liées. Selon un mode de réalisation particulier, le procédé comprend en outre une étape d'affichage de ladite évaluation de l'adaptation de ladite au moins une donnée dudit autre desdits systèmes de gestion technique et de gestion de mission dudit aéronef pour permettre à l'équipage de prendre connaissance de l'adaptation évaluée. Le procédé comprend en outre, de préférence, une étape de validation de ladite évaluation de l'adaptation de ladite au moins une donnée dudit autre desdits systèmes de gestion technique et de gestion de mission dudit aéronef pour permettre à l'équipage de garder le contrôle des systèmes dudit aéronef. Toujours selon un mode de réalisation particulier, ladite étape d'affichage comprend une étape d'affichage d'une représentation activable d'une commande de contrôle d'au moins un dispositif d'au moins l'un desdits systèmes de gestion technique et de gestion de mission dudit aéronef, ladite étape de validation comprenant une étape d'activation de ladite commande permettant un accès contextuel aux commandes de contrôle des systèmes. De façon avantageuse, lesdites étapes d'affichage et de validation sont mises en oeuvre dans une interface logicielle centralisée desdits systèmes de gestion technique et de gestion de mission dudit aéronef pour simplifier l'interface de contrôle des systèmes, réduire les coûts de fabrication des aéronefs en réduisant le câblage nécessaire au contrôle des systèmes et permettre de personnaliser facilement l'interface. Selon un mode de réalisation particulier, le procédé comprend en outre une étape d'analyse dudit événement détecté, ladite étape de transmission de ladite au moins une information relative audit événement détecté étant effectuée en réponse à ladite étape d'analyse pour limiter l'échange de données entre les systèmes. Toujours selon un mode de réalisation particulier, le procédé comprend en outre une étape de détermination de l'état dudit aéronef, les conséquences dudit événement détecté étant déterminées en fonction dudit état et l'adaptation de ladite au moins une donnée étant évaluée en fonction dudit état pour être améliorée. L'invention a également pour objet un dispositif comprenant des moyens adaptés à la mise en oeuvre de chacune des étapes du procédé décrit 10 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 : - la figure 1 est une représentation schématique d'un cockpit 15 d'aéronef présentant la position des interfaces de contrôle des différents systèmes de l'aéronef ; - la figure 2 illustre un exemple de configuration de cockpit adaptée à mettre en oeuvre l'invention ; - la figure 3 représente un exemple d'algorithme pour transmettre 20 des données susceptibles de modifier la configuration de l'aéronef et/ou de la mission, ces données étant échangées entre le système de gestion technique de l'aéronef et le système de gestion de mission ; - la figure 4 illustre un premier exemple selon lequel la détection d'une défaillance d'un élément technique de l'aéronef est transmise au système 25 de gestion de mission pour permettre une évaluation automatique des restrictions dues à la défaillance sur l'exploitation de l'aéronef ; - les figures 5 et 6 représentent des pages d'un exemple d'interface homme-machine permettant d'accéder, de façon hiérarchique et contextuelle, aux paramètres de l'aéronef pour les contrôler, les modifier et/ou les saisir ainsi 30 que pour accéder à des représentations de commandes activables via l'interface ; - la figure 7 illustre un exemple de représentations d'une commande pouvant être utilisée pour activer la commande associée et visualiser l'état du dispositif commandé ; - la figure 8 illustre un exemple de contrôle d'un paramètre pouvant prendre plusieurs valeurs tel que la température via une représentation de la commande associée ; - la figure 9 représente un schéma synoptique comprenant des représentations de commandes telles que celles illustrées sur les figures 7 et 8, ces représentations pouvant être utilisées pour activer les commandes ; - la figure 10 illustre un exemple d'algorithme mis en oeuvre pour contrôler les éléments de l'interface logicielle permettant d'accéder à des pages comprenant des paramètres à vérifier, à modifier ou à saisir et/ou des représentations de commandes ; et, - la figure 11 illustre un exemple d'architecture matérielle adaptée à mettre en oeuvre l'invention. De façon générale, l'invention a pour objet l'échange de données entre d'une part le système de gestion technique de l'aéronef, c'est-à-dire le système de contrôle de l'avionique et/ou des servitudes et, d'autre part, le système de gestion de mission pour permettre à un système de prendre en compte une modification détectée ou reçue par un autre système afin de réduire la charge de travail du pilote. Ainsi, par exemple, si une défaillance est détectée dans l'avionique, les effets de cette défaillance sont transmis au système de gestion de mission pour, le cas échéant, modifier les paramètres de mission. De la même façon, des informations de mission peuvent être transmises à l'avionique et/ou au système de contrôle des servitudes pour modifier la configuration de l'aéronef. Par conséquent, le cockpit est réorganisé pour permettre une interaction entre les systèmes de contrôle de l'avionique, comprenant la gestion des missions, et de contrôle des servitudes.

La figure 2 illustre un exemple de configuration de cockpit adaptée à mettre en oeuvre l'invention.

Le cockpit comprend un écran central de contrôle technique 200, appelé TMD (sigle de Technical Management Display en terminologie anglo-saxonne), et un écran central de gestion de mission 205, appelé MMD (sigle de Mission Management Display en terminologie anglo-saxonne).

Le cockpit comprend également deux écrans primaires 210-1 et 210-2, appelés PD (sigle de Primary Display en terminologie anglo-saxonne) et deux écrans complémentaires 215-1 et 215-2 de type OIS/CDS (sigles d'Onboard Information System et de Control and Display System en terminologie anglo-saxonne) situés devant le pilote et le copilote, respectivement.

Les écrans 200 et 205 sont utilisés comme interface principale pour la gestion de l'avionique, des servitudes et des paramètres de mission, en coopération avec des moyens de saisie tels qu'un clavier, un dispositif de pointage permettant de déplacer un curseur et/ou une technologie tactile combinée avec l'un ou les deux écrans. Le dispositif de pointage est, par exemple, une boule de commande ou un pavé tactile. L'interface mise en oeuvre à travers les écrans 200 et 205 permet notamment de définir et de modifier les paramètres de configuration technique et les paramètres de mission. En outre, cette interface permet, de préférence à l'aide de l'écran 200, de gérer les fonctions de mission telles que l'affichage des messages d'alerte, la mise en oeuvre des fonctions d'aide à la décision d'exploitation de l'aéronef lorsqu'au moins une défaillance est détectée, la consultation du journal de bord, appelé logbook en terminologie anglo-saxonne, et la saisie des entrées dans celui-ci.

De même, cette interface est utilisée, de préférence à l'aide de l'écran 205, comme système de gestion de vol, appelé FMS (sigle de Flight Management System en terminologie anglo-saxonne), pour l'exécution des applications de mission et des applications opérationnelles, notamment des applications de calcul de performance de l'aéronef.

La figure 3 représente un exemple d'algorithme pour transmettre des données susceptibles de modifier la configuration de l'aéronef et/ou de la mission, ces données étant échangées entre le système de gestion technique de l'aéronef (avionique ou servitudes) et le système de gestion de mission. L'algorithme comprend ici deux parties. Une première partie est mise en oeuvre dans un premier système. Elle a pour objet la détection et l'analyse d'un événement ainsi que la transmission d'informations relatives à cet événement si celui peut avoir des effets sur un second système. La seconde partie est mise en oeuvre dans le second système. Elle vise à déterminer et, le cas échéant, à prendre en compte les effets de l'événement détecté. Comme indiqué précédemment, les premier et second systèmes sont ici le système de gestion technique de l'aéronef et le système de gestion de mission. Si le premier système est le système de gestion technique de l'aéronef, le second système est ici le système de gestion de mission. Réciproquement, si le premier système est le système de gestion de mission, le second système est ici le système de gestion technique de l'aéronef.

De façon avantageuse, chacune des parties de l'algorithme représentées sur la figure 3 est mise en oeuvre dans chacun des systèmes de gestion technique de l'aéronef de gestion de mission pour permettre une prise en compte dans chaque système des événements détectés dans chaque autre système.

Une première étape (étape 300) a pour objet de détecter un événement. Un événement est ici considéré selon une définition large. Il peut s'agir de la détection d'une défaillance, d'une donnée reçue d'un système de l'aéronef ou d'un système extérieur ou d'une donnée saisie par le pilote. L'événement est ensuite analysé (étape 305) pour déterminer s'il est susceptible d'affecter le second système. A cette fin, les conséquences potentielles de l'événement sont déterminées. Selon un mode de réalisation particulier, les conséquences potentielles d'un événement sont mémorisées dans une table prédéterminée dont l'entrée correspond à une référence des événements. Une telle table est ici stockée dans la base de données 310.

Les conséquences potentielles sont par exemple des restrictions de configuration de l'aéronef telles que la puissance maximale des moteurs pouvant être utilisée ou des restrictions de mission telles qu'une altitude maximale de vol. Un test est alors effectué pour déterminer si l'événement détecté est susceptible d'affecter le second système (étape 315). Dans la négative, les étapes précédentes (étapes 300, 305 et 315) sont répétées dès qu'un autre événement est détecté. Si l'événement détecté est susceptible d'affecter le second système, un identifiant de l'événement, les conséquences potentielles liées à l'événement ou toute autre information relative à celui-ci sont transmises au second système (étape 320). Comme suggéré par le trait pointillé horizontal, les étapes 300, 305, 315 et 320 sont mises en oeuvre dans le premier système. La base de données 310 peut être propre au premier système ou commune aux premier et second systèmes.

Après avoir reçu l'identifiant d'un événement détecté, les conséquences potentielles liées à cet événement ou toute autre information relative à celui-ci (étape 325), le second système détermine les restrictions ou les modifications de paramétrages en résultant (étape 330) en comparant, par exemple, les conséquences potentielles de l'événement avec la configuration de l'aéronef ou avec les paramètres de mission. Les données de configuration et/ou les paramètres peuvent être mémorisés dans la base de données 335. La base de données 335 peut également être utilisée pour mémoriser une table prédéterminée dont l'entrée correspond à une référence de l'événement afin de permettre la détermination des conséquences potentielles d'un événement en fonction de références à celui-ci. Les modifications de paramétrage liées à un événement dépendent de la nature de l'événement détecté. Un test est ensuite effectué (étape 340) pour déterminer s'il convient de modifier certains paramètres de l'aéronef (avionique, servitude ou mission).

Dans la négative, les étapes précédentes sont répétées dans l'attente d'un nouvel événement détecté ayant potentiellement des effets sur le second système. Dans l'affirmative, l'adaptation de ces paramètres est évaluée et les paramètres sont modifiés (étape 350). Selon un mode de réalisation préféré, les paramètres de l'aéronef ne sont modifiés qu'après validation de ces modifications par le pilote (étape 345).

Après que les paramètres de l'aéronef aient été modifiés, ou lorsque le pilote ne valide pas les modifications, les étapes précédentes sont répétées dans l'attente d'un nouvel événement détecté ayant potentiellement des effets sur le second système. Comme suggéré par le trait pointillé horizontal, les étapes 325, 330 et 340 à 350 sont mises en oeuvre dans le second système. La base de données 335 peut être propre au premier système ou commune aux premier et second systèmes. La figure 4 illustre un premier exemple selon lequel la détection d'une défaillance d'un élément technique de l'aéronef est transmise au système de gestion de mission pour permettre une évaluation automatique des restrictions dues à la défaillance sur l'exploitation de l'aéronef. Ainsi, la figure 4 comprend deux pages pouvant être affichées sur les écrans de contrôle des paramètres d'un aéronef et des paramètres de mission lorsqu'une défaillance technique est détectée, conformément à l'algorithme représenté sur la figure 3. Selon cet exemple, le système de contrôle de l'avionique détecte une défaillance du système anti-givrage. Une telle défaillance a pour conséquence une restriction d'exploitation de l'aéronef, ce dernier ne pouvant pas voler dans des zones dont la température est telle qu'il existe un risque de formation de givre sur l'aéronef. Ainsi, conformément à l'invention, non seulement un message d'alerte est transmis au pilote mais, en outre, le système de gestion de mission, ayant reçu l'information de défaillance, indique au pilote les conséquences opérationnelles de la défaillance.

La page 400, affichée sur l'écran central de contrôle technique 200, comprend ici une alerte, sous forme du message 405, indiquant la défaillance du système anti-givrage, appelé deicing ou anti-icing en terminologie anglo-saxonne. Parallèlement, la page 410, affichée sur l'écran central de gestion de mission 205 et contenant ici un fond cartographique 415 représentant la zone survolée au cours de la mission, ou d'une partie de celle-ci, indique, par superposition, une zone 420. La zone 420 est avantageusement matérialisée à l'aide d'une texture et/ou d'une couleur particulières, laissant le fond cartographique partiellement visible. La zone 420 représente une zone à éviter du fait de la défaillance détectée. Il s'agit ici d'une zone dans laquelle la température est telle qu'il existe un risque de formation de givre sur l'aéronef. De la même façon, si une défaillance est détecté sur le système de pressurisation de la cabine de l'aéronef, la transmission d'une information relative à cette défaillance au système de gestion de mission permet à ce dernier de modifier ou de proposer une modification du plan de vol pour respecter un plafond réduit. Inversement, un paramètre du système de gestion de mission peut être transmis pour configurer le système de gestion technique de l'aéronef. Ainsi, par exemple, si la compagnie aérienne exploitant l'aéronef transmet au système de gestion de mission de ce dernier une information relative à sa politique de réduction de la puissance des moteurs durant les phases de décollage pour augmenter la durée de vie de ceux-ci et pour limiter la consommation de carburant, cette information est transmise au système de gestion technique de l'aéronef conformément à l'algorithme représenté sur la figure 3.

A partir de cette information, une nouvelle configuration technique de l'aéronef est utilisée pour arrêter le système anti-givrage afin de mettre en oeuvre la stratégie de la compagnie aérienne (il est rappelé ici que le système anti-givrage utilise de l'air issu des réacteurs et que, par conséquent, ce système utilise une partie de la puissance de ce dernier).

Comme indiqué précédemment, si le paramétrage de l'aéronef et/ou de la mission peut être automatique en réponse à la détection d'un événement, il est préférable, dans de nombreux cas, notamment pour des raisons de sécurité, que le nouveau paramétrage soit validé par le pilote. Alors que le système de gestion de mission offre généralement une interface logicielle, les systèmes de contrôle de l'avionique et des servitudes utilisent souvent des boutons spécifiques. Il est donc avantageux de mettre en oeuvre une interface logicielle centralisée permettant notamment de contrôler les systèmes de contrôle de l'avionique, de contrôle des servitudes et de gestion de mission. De préférence, les commandes accessibles via cette interface sont groupées selon leurs fonctions et non selon les systèmes auxquels elles sont liées. Le nombre de commandes simultanément accessibles est avantageusement restreint. Ces commandes sont ici sélectionnées selon un contexte, le contexte étant lui-même déterminé en fonction de l'état de l'aéronef, par exemple la mise en route, l'arrêt ou la phase de vol (roulage au sol, décollage, montée, croisière, descente, atterrissage) et en fonction de la détection d'une panne ou d'une défaillance ou des conséquences potentielles en résultant. L'interface logicielle centralisée offre ainsi un accès sélectif, contextuel et interactif aux différents systèmes de l'aéronef ainsi que la possibilité d'enchaîner automatiquement plusieurs commandes. Combinée à l'algorithme décrit en référence à la figure 3, cette interface permet de réduire la charge du pilote, les commandes étant sélectionnées en fonction du contexte, et d'améliorer la sécurité du l'aéronef, les commandes inutiles pour le contexte considéré n'étant pas directement disponibles. Ainsi, lorsqu'un événement est détecté dans un système, le pilote n'a pas à déterminer si celui-ci a un effet dans un autre système, l'interface proposant automatiquement au pilote les modifications résultant de cet événement. Le pilote peut alors les valider ou non.

Par ailleurs, l'état des dispositifs associés aux commandes accessibles est, de préférence, affiché en liaison avec les représentations de ces commandes. Une telle représentation permet d'optimiser la vision du pilote sur les éléments de l'aéronef. Bien qu'une telle interface permette de remplacer tous les boutons spécifiques, en particulier tous les boutons des systèmes de gestion technique de l'aéronef, il est néanmoins possible de conserver une partie ou la totalité de ces boutons, par exemple, pour satisfaire des exigences de redondance ou pour offrir un double système d'interface particulièrement adapté à certaines situations d'urgence. Ainsi, les différentes implémentations suivantes peuvent être mises en oeuvre, - toutes les commandes sont accessibles à travers l'interface logicielle et les boutons spécifiques ; - toutes les commandes sont accessibles à travers l'interface logicielle, certaines l'étant également à travers des boutons spécifiques ; - toutes les commandes sont accessibles à travers l'interface logicielle, aucune ne l'étant via des boutons spécifiques ; - certaines commandes sont accessibles à travers l'interface logicielle, toutes ces commandes l'étant à travers les boutons spécifiques ; et, - certaines commandes sont accessibles à travers l'interface logicielle et certaines commandes le sont via des boutons spécifiques, des commandes pouvant être accessibles via l'interface logicielle et des boutons spécifiques. La figure 5 représente une première page d'un exemple d'interface homme-machine permettant d'accéder, de façon hiérarchique et contextuelle, aux paramètres techniques de l'aéronef (avionique et servitudes) pour les contrôler, les modifier et/ou les saisir ainsi que pour accéder à des représentations de commandes activables via l'interface. L'interface 500 comprend ici une partie située à gauche permettant de sélectionner les actions ou les vérifications à effectuer (référence 505) selon l'état de l'aéronef (référence 510).

De façon avantageuse, l'état de l'aéronef est automatiquement déterminé. A partir de cet état, les fonctions et les paramètres accessibles sont déterminés et présentés au pilote. Les fonctions sont avantageusement regroupées selon leur nature. Selon l'exemple présenté sur la figure 5, l'aéronef est au sol et s'apprête à effectuer une mission comme l'illustre la sélection de l'icône située en haut à gauche. Les paramètres de mise en route ont été entrés et vérifiés, l'indication A/C power up étant validée. Le pilote peut maintenant vérifier le niveau des fluides ( Fluid levels ), la capacité de l'aéronef à effectuer la mission ( Dispatch ), d'autres paramètres de l'aéronef ( Walkaround ) ou accepter les paramètres techniques de l'aéronef liés à la mission à effectuer ( A/C technical acceptance ). La partie droite de l'interface est ici utilisée pour présenter et modifier des informations telles que des statuts, un journal, un historique et des données de vol. Ces informations peuvent être sélectionnées selon leur catégorie, par exemple à l'aide d'onglets comme représenté. Ici, l'onglet 515 lié aux informations de statut est sélectionné. Cet onglet permet notamment d'accéder à la liste des défaillances détectées, appelées open items , et à la liste des défaillances détectées différées, appelées differed items , à partir de la zone 520. La contextualisation de l'accès aux paramètres et aux fonctions permet en outre de guider le pilote dans la configuration de l'aéronef et dans les vérifications à effectuer. Il est ainsi possible de mettre en oeuvre des moyens de vérifications afin de signaler au pilote tout oubli, par exemple sous forme de message d'alerte. La page 500 peut être utilisée comme page principale pour accéder aux paramètres et aux fonctions accessibles via cette interface. La figure 6 représente une page d'un second exemple d'interface homme-machine permettant d'accéder, de façon hiérarchique et contextuelle, aux paramètres techniques de l'aéronef pour les contrôler, les modifier et/ou les saisir ainsi que pour accéder à des représentations de commandes activables via l'interface. L'exemple illustré représente, par exemple, une page automatiquement affichée lorsqu'une pression insuffisante de carburant est détectée ou lorsque de la fumée est détectée. Cette page permet au pilote d'être alerté de la défaillance, de vérifier les paramètres des éléments liés à cet incident et d'effectuer les actions nécessaires.

Simultanément, l'écran du système de gestion de mission peut afficher un fond cartographique similaire à celui présenté sur la figure 4 et indiquer des zones d'atterrissage conseillées ou le rayon d'action de l'aéronef au-delà duquel sa sécurité peut être comprise.

L'interface textuelle 600 permet notamment de sélectionner des groupes de commandes ou des schémas synoptiques en utilisant des liens associés aux lignes présentées et de guider le pilote ou le copilote pour effectuer les configurations nécessaires. Chaque ligne représente ici une ou plusieurs tâches et/ou vérifications à effectuer ou une ou plusieurs fonctions.

L'interface 600, telle que représentée, contient deux rangées d'indicateurs, situées sur la gauche de l'écran, chaque indicateur étant associé à une ligne. La première colonne indique la présence ou l'absence d'un lien. En d'autres termes, lorsqu'un carré est représenté dans la première colonne, cela signifie qu'un lien est associé à la ligne. Lorsque ce carré contient des flèches, le lien permet d'atteindre un groupe de commandes, par exemple sous la forme d'un schéma synoptique. La seconde colonne donne une indication relative à l'exécution des actions ou des vérifications correspondant à l'objet de la ligne considérée. Cette indication peut être automatiquement mise à jour si les actions ou vérifications ont été effectuées à travers l'interface logicielle ou manuellement mise à jour si les actions ou vérifications ont été effectuées via des boutons spécifiques. Ainsi, à titre d'illustration, les lignes 605 et 610 comprennent les indicateurs 615 et 620 dans la première colonne précisant qu'elles sont associées à un lien alors que la ligne 625 n'en possède pas. Il sera observé en outre que l'indicateur 620 comporte des flèches indiquant qu'il est possible, à partir de cet indicateur, d'atteindre des paramètres et/ou des représentations de commandes relatifs à l'objet de la ligne 610. De même, il convient de noter que l'indicateur 630 précise que les actions et/ou vérifications associées à l'objet de la ligne 605 n'ont pas été exécutées tandis que l'indicateur 635 précise que les actions et/ou vérifications associées à la ligne 610 ont été effectuées. L'indicateur 640 vise un lien permettant d'atteindre des représentations de commandes accessibles via l'interface logicielle 600 dont l'exécution peut être indiquée par une couleur particulière (le sigle SD, sigle de System Display en terminologie anglo-saxonne, indique ici que la ou les commandes correspondantes sont accessibles via l'interface logicielle). Par ailleurs, l'interface présentée sur la figure 6 comprend, sur la partie droite de l'écran, des flèches de défilement permettant de visualiser le texte situé au-dessus ou au-dessous de celui qui est affiché. Naturellement, d'autres types d'indicateurs peuvent être utilisés. L'interface centralisée comprend plusieurs pages pouvant notamment se présenter sous forme textuelle ou sous forme de schémas synoptiques. La composition de ces pages peut être prédéterminée et mémorisée dans une base de données. Cette composition peut également être déterminée dynamiquement selon les sélections du pilote ou du copilote, l'état de l'aéronef et/ou les événements détectés. Selon un mode de réalisation particulier, les pages devant être affichées sont déterminées selon un mécanisme de liens tel que décrit précédemment, l'état de l'aéronef et les événements détectés, par exemple une défaillance, une table de correspondance étant établie entre les événements détectés et les pages devant être affichées. De façon avantageuse, la détection d'une défaillance entraîne l'affichage de la page contenant les paramètres et/ou les représentations des commandes correspondant à cette défaillance, en fonction de la table de correspondance prédéterminée. Un mécanisme de priorité peut être mis en oeuvre. Ainsi, si une défaillance n'ayant pas de conséquences importantes est détectée, une simple alerte peut être générée, la page comprenant les paramètres et/ou les représentations des commandes correspondants n'étant affichée qu'après acceptation du pilote ou du copilote. Pour une défaillance ayant des conséquences directes sur la sécurité de l'aéronef, la page comprenant les paramètres et/ou les représentations des commandes correspondants est affichée directement pour permettre au pilote ou au copilote de prendre les actions nécessaires rapidement.

La figure 7 illustre un exemple de représentations d'une commande pouvant être utilisée pour activer la commande associée, ici une commande de servitude, et visualiser l'état du dispositif commandé. La référence 700 vise ainsi la représentation d'une commande selon plusieurs états de la commande et de la servitude associée. Il s'agit ici d'une commande de pompe. La référence 705 présente la commande et l'état de la pompe lorsque celle-ci est activée ( on ). Le bouton virtuel 705 comprend ici deux parties, une partie 705-1 dans laquelle est représentée une icône indiquant le statut de la servitude et une partie 705-2 décrivant l'état de la commande ainsi que le statut de la servitude, sous forme textuel. La commande représentée est ici une commande à deux état ( on ou off ), il suffit par conséquent de sélectionner la représentation 705 et d'actionner un bouton d'activation pour changer son état. Ainsi, par exemple, la représentation 705 peut être sélectionnée à l'aide d'un pointeur tel qu'une souris et l'état peut être changé par un clic de souris. D'autres méthodes peuvent être utilisées telles que l'utilisation d'un écran tactile permettant de sélectionner et de changer directement l'état de la commande. La référence 710 présente la commande et l'état de la pompe lorsque celle-ci est désactivée ( off ). Comme représenté, l'icône est modifiée pour matérialiser l'état de la pompe et le texte est changé. La référence 715 présente la commande et l'état de la pompe lorsqu'une défaillance est détectée ( fault ). Comme représenté, l'icône est modifiée pour matérialiser l'état désactivé de la pompe bien que la pompe n'ait pas été arrêtée. La référence 720 présente la commande et l'état de la pompe lorsqu'une défaillance est détectée ( fault ) mais que la pompe est volontairement désactivée ( off ). Comme représenté, l'icône est modifiée pour matérialiser l'état désactivé de la pompe.

Enfin, la référence 725 présente la commande et l'état de la pompe lorsqu'une défaillance est détectée ( fault ) mais que la pompe continue à fonctionner dans un mode dégradé. Comme représenté, l'icône est modifiée pour matérialiser l'état dégradé de la pompe ( /o ). Une indication textuelle correspondante est affichée ( fault ). Un code de couleurs peut être associé aux représentations des commandes. Par exemple, les icônes peuvent être vertes si la servitude fonctionne correctement, orange si elle est dans un mode dégradé et rouges si elle est défaillante. Le pilote et le copilote peuvent ainsi visualiser d'un simple coup d'oeil l'état des servitudes représentées. Il convient de remarquer ici que si une commande de l'interface logicielle peut être utilisée de façon similaire à un bouton spécifique pour effectuer une action, une commande de l'interface logicielle peut également être associée à une séquence d'autres commandes. Ce type de commande offre de nombreux avantages en termes de temps de réaction et en termes de mise à jour des fonctions d'un aéronef, une commande pouvant à tout moment être modifiée ou ajoutée.

A titre d'illustration, une commande peut contrôler simultanément l'ouverture ou la fermeture d'une vanne ainsi que la mise en route ou l'arrêt d'une pompe. Dans ce cas, la représentation de la servitude indique, de préférence, l'état de l'ensemble des servitudes contrôlées. Ainsi, un état de panne sera affiché si la pompe ou la vanne est défectueuse.

La figure 8 illustre un exemple de contrôle d'un paramètre pouvant prendre plusieurs valeurs, ici la température. Selon l'exemple référencé 800, la température est sélectionnée à l'aide de plusieurs boutons référencés 805-1 à 805-3, chaque bouton correspondant à une température. Alternativement, selon l'exemple référencé 810, la température est sélectionnée en déplaçant un curseur 820 sur une règle graduée 815. La sélection de la température peut être couplée à un mécanisme de sélection de zone comme illustré par la référence 825. Selon cet exemple, un mécanisme de sélection de la température 830, tel que le mécanisme 800 ou le mécanisme 810, est associé à plusieurs boutons référencés 835-1 à 835-3 permettant de sélectionner une zone de l'aéronef. La température réglée à l'aide du mécanisme 830 correspond à la zone ou aux zones activées.

De façon avantageuse, les commandes illustrées sur les figures 7 et 8 sont intégrées dans des schémas synoptiques tels que celui représenté sur la figure 9 pour permettre la visualisation du dispositif contrôlé dans son environnement. Un tel schéma synoptique peut être atteint à partir d'un lien tel que ceux présentés en référence à la figure 6. Le schéma illustré ici concerne un système de gestion du carburant génériquement référencé 900. Ce schéma permet de visualiser les relations entre les différentes commandes ainsi que leurs effets. Par exemple, il est facile de voir que les commandes 905-1 et 905-2 sont redondantes et que la pompe 905-1, fonctionnant en mode dégradé, est secondée par la pompe 905-2 pour transmettre le carburant vers les vannes ouvertes 910-1 et 910-2. Selon un mode de réalisation particulier, la granularité des schémas synoptiques est variable. Ainsi, chaque commande représentée peut concerner un élément ou un ensemble d'éléments. L'état affiché représente alors l'état d'un élément ou d'un ensemble d'éléments. Selon les paramètres utilisés, la sélection d'une commande permet de modifier l'état de la commande ou d'accéder aux différents éléments contrôlés par la commande. La figure 10 illustre un exemple d'algorithme mis en oeuvre pour contrôler les éléments de l'interface logicielle permettant d'accéder à des pages comprenant des paramètres à vérifier, à modifier ou à saisir et/ou des représentations de commandes. Une étape 1000 vise à déterminer l'état de l'aéronef par rapport à une liste d'états prédéterminés tels que la mise en route, l'arrêt ou la phase de vol, notamment le roulage au sol, le décollage, la montée, le vol de croisière, la descente, ou l'atterrissage. Une étape 1005 a pour objet la sélection des éléments de l'interface logicielle devant être affichés, c'est-à-dire la détermination des paramètres et/ou des commandes dont une représentation doit être affichée. Comme décrit précédemment, cette sélection peut être réalisée selon les entrées du pilote ou du copilote, l'état de l'aéronef et/ou des événements détectés. Par défaut, des éléments permettant d'accéder aux différents schémas synoptiques sont affichés, sous forme textuelle ou graphique. Ces éléments sont, par exemple, mémorisés dans une base de données 1010 sous forme de pages d'écran prédéterminées. Après avoir été déterminés, ces éléments sont affichés (étape 1015) sous la forme d'une page.

Un test est ensuite effectué pour déterminer si le pilote ou le copilote a sélectionné un élément de la page affichée ou saisi une donnée liée à l'interface logicielle (étape 1020). Si le pilote ou le copilote a sélectionné un élément de la page affichée ou saisi une donnée liée à l'interface logicielle, une analyse de la saisie est effectuée (étape 1025) pour permettre sa prise en compte, notamment pour savoir si celle-ci vise la saisie ou la modification d'un paramètre de l'aéronef, l'activation d'une commande ou la sélection d'un lien permettant l'affichage d'une nouvelle page. Un autre test est ensuite effectué pour déterminer si un événement a été détecté (étape 1030). Un événement est ici une défaillance, un changement de configuration ou plus généralement tout changement pouvant être détecté, de préférence automatiquement. Si un événement est détecté, une analyse de l'événement est effectuée (étape 1035) pour déterminer les conséquences de celle-ci et déterminer s'il convient de modifier le contenu de la page affichée.

Les étapes précédentes sont ensuite répétées pour déterminer à nouveau, si nécessaire, le contenu de la page affichée. La sélection des éléments de la page affichée tient alors compte de l'état de l'aéronef et, le cas échéant, de la saisie effectuée par le pilote ou le copilote et/ou de l'événement détecté.

De façon avantageuse, les pages d'écran sont organisées hiérarchiquement pour permettre le passage de l'une à l'autre selon l'état de l'aéronef, une saisie effectuée par le pilote (ou le copilote) et/ou des événements détectés ou des configurations particulières. La structure de la hiérarchie est par exemple mémorisée dans le fichier 1040 pouvant être mémorisé dans la base de données 1010 ou dans une autre zone de stockage. Les éléments déterminés sont alors affichés (étape 1015) et le processus se poursuit.

La figure 11 illustre un exemple d'architecture matérielle adaptée à mettre en oeuvre l'invention, notamment chacune des parties de l'algorithme représenté sur la figure 3. Le dispositif 1100 comporte ici un bus de communication 1105 auquel sont reliés : - une unité centrale de traitement ou microprocesseur 1110 (CPU, sigle de Central Processing Unit en terminologie anglo-saxonne) ; - une mémoire morte 1115 (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 1120 (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 ; et - une interface de communication 1150 adaptée à transmettre et à 15 recevoir des données, notamment vers et depuis les dispositifs commandés de l'aéronef pour les contrôler et connaître leur état. Le dispositif 1100 dispose également, de préférence, des éléments suivants : - un écran 1125 permettant de visualiser des données telles que 20 des représentations des commandes et de servir d'interface graphique avec l'utilisateur qui pourra interagir avec les programmes selon l'invention, à l'aide d'un clavier et d'une souris 1130 ou d'un autre dispositif de pointage tel qu'un écran tactile ou une télécommande ; - d'un disque dur 1135 pouvant comporter les programmes précités 25 et des données traitées ou à traiter selon l'invention ; et - d'un lecteur de cartes mémoires 1140 adapté à recevoir une carte mémoire 1145 et à y lire ou à y écrire des données traitées ou à traiter selon l'invention. Le bus de communication permet la communication et 30 l'interopérabilité entre les différents éléments inclus dans le dispositif 1100 ou reliés à lui. La représentation du bus n'est pas limitative et, notamment, l'unité centrale est susceptible de communiquer des instructions à tout élément du dispositif 1100 directement ou par l'intermédiaire d'un autre élément du dispositif 1100. 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 1135 ou en mémoire morte 1115. Selon une variante, la carte mémoire 1145 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 1100, est stocké dans le disque dur 1135. Selon une autre variante, le code exécutable des programmes pourra être reçu, au moins partiellement, par l'intermédiaire de l'interface 1150, 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 15 chargés dans un des moyens de stockage du dispositif 1100 avant d'être exécutés. L'unité centrale 1110 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 1135 ou dans la 20 mémoire morte 1115 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 1135 ou la mémoire morte 1115, sont transférés dans la mémoire vive 1120 qui contient alors le code exécutable du ou des programmes selon l'invention, ainsi que des registres 25 pour mémoriser les variables et paramètres nécessaires à la mise en oeuvre de l'invention. Naturellement, pour satisfaire des besoins spécifiques, une personne compétente dans le domaine de l'invention pourra appliquer des modifications dans la description précédente.

Claims (10)

1. REVENDICATIONS1. Procédé d'échange de données entre un système de gestion technique d'un aéronef et un système de gestion de mission dudit aéronef pour permettre à l'un desdits systèmes de déterminer les conséquences d'un événement détecté dans l'autre desdits systèmes, ce procédé étant caractérisé en ce qu'il comprend les étapes suivantes, - détection (300) d'au moins un événement dans l'un desdits systèmes de gestion technique et de gestion de mission dudit aéronef ; - transmission (320) d'au moins une information relative audit événement détecté à l'autre desdits systèmes de gestion technique et de gestion de mission dudit aéronef ; - détermination (330) des conséquences dudit événement détecté dans ledit autre desdits systèmes de gestion technique et de gestion de mission dudit aéronef ; et, - évaluation de l'adaptation d'au moins une donnée dudit autre desdits systèmes de gestion technique et de gestion de mission dudit aéronef en réponse à ladite étape de détermination.
2. 2. Procédé selon la revendication précédente comprenant en outre une étape de modification (350) de ladite au moins une donnée dudit autre desdits systèmes de gestion technique et de gestion de mission dudit aéronef en réponse à ladite étape d'évaluation de l'adaptation de ladite au moins une donnée.
3. 3. Procédé selon la revendication 1 ou la revendication 2 comprenant en outre une étape d'affichage de ladite évaluation de l'adaptation de ladite au moins une donnée dudit autre desdits systèmes de gestion technique et de gestion de mission dudit aéronef.
4. 4. Procédé selon la revendication précédente comprenant en outre une étape de validation (345) de ladite évaluation de l'adaptation de ladite aumoins une donnée dudit autre desdits systèmes de gestion technique et de gestion de mission dudit aéronef.
5. 5. Procédé selon la revendication précédente selon lequel ladite étape d'affichage comprend une étape d'affichage d'une représentation activable d'une commande de contrôle d'au moins un dispositif d'au moins l'un desdits systèmes de gestion technique et de gestion de mission dudit aéronef, ladite étape de validation comprenant une étape d'activation de ladite commande.
6. 6. Procédé selon l'une quelconque des revendications 3 à 5 selon lequel lesdites étapes d'affichage et de validation sont mises en oeuvre dans une interface logicielle centralisée desdits systèmes de gestion technique et de gestion de mission dudit aéronef.
7. 7. Procédé selon l'une quelconque des revendications précédentes comprenant en outre une étape d'analyse dudit événement détecté, ladite étape de transmission de ladite au moins une information relative audit événement détecté étant effectuée en réponse à ladite étape d'analyse.
8. 8. Procédé selon l'une quelconque des revendications précédentes comprenant en outre une étape de détermination de l'état dudit aéronef, les conséquences dudit événement détecté étant déterminées en fonction dudit état et l'adaptation de ladite au moins une donnée étant évaluée en fonction dudit état.
9. 9. Dispositif comprenant des moyens adaptés à la mise en oeuvre de chacune des étapes du procédé selon l'une quelconque des revendications précédentes.
10. 10. Aéronef comprenant le dispositif selon la revendication précédente.