Brevet FR2935179A1 — publié le 20100226

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 d'aide au contrôle 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-position, 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ée 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-position, 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 l'interface de commande de l'avionique, des systèmes d'aide à la navigation et des servitudes donne toute satisfaction aux pilotes, elle présente néanmoins certains inconvénients. En particulier, en raison du nombre de boutons nécessaires, il existe un risque non négligeable qu'un bouton soit sélectionné à la place d'un autre. Par ailleurs, en raison de l'espace limité adapté à les recevoir (ils doivent être accessibles par le pilote et le copilote), les boutons sont proches les uns des autres ce qui augmente le risque de sélectionner un bouton au lieu d'un autre. 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'aide au contrôle des systèmes embarqués dans un aéronef comprenant au moins un dispositif d'affichage adapté à afficher des paramètres de configuration dudit aéronef et au moins un dispositif de saisie associé, ce procédé comprenant les étapes suivantes, - détermination de l'état dudit aéronef ; - sélection, selon ledit état dudit aéronef, d'une pluralité d'éléments à afficher sur ledit au moins un dispositif d'affichage dans un ensemble prédéterminé d'éléments comprenant au moins un paramètre de configuration de l'avionique, au moins un paramètre de configuration de servitude et au moins une représentation activable d'au moins une commande de servitude dudit aéronef ; et, - affichage de ladite pluralité d'éléments sur ledit dispositif d'affichage. Le procédé selon l'invention permet ainsi d'améliorer l'interface de contrôle des systèmes de l'aéronef et de limiter les risques d'erreurs liées, notamment, à de mauvaises saisies. Ce procédé permet également de réduire les coûts de fabrication des aéronefs en réduisant le câblage nécessaire au contrôle des systèmes. Par ailleurs, ce procédé permet de personnaliser facilement l'interface de contrôle. Avantageusement, le procédé comprend en outre une étape de saisie, de validation, de modification ou d'activation d'au moins un élément sélectionné. Selon un mode de réalisation particulier, ledit ensemble d'éléments comprend en outre au moins un lien vers au moins un élément présélectionné dudit ensemble d'éléments, le procédé comprenant en outre une étape de choix d'au moins un élément de ladite pluralité d'éléments à l'aide desdits moyens de saisie et, en réponse audit choix, la sélection et l'affichage dudit au moins un élément présélectionné. Le procédé selon l'invention permet ainsi de guider l'équipage dans les tâches qu'il doit effectuer. Toujours selon un mode de réalisation particulier, le procédé comprend en outre une étape de détection d'au moins une défaillance, au moins un élément dudit ensemble d'éléments étant associé à ladite au moins une défaillance, et, en réponse à ladite détection de ladite au moins une défaillance, la sélection et l'affichage dudit au moins un élément associé à ladite au moins une défaillance. Le procédé selon l'invention permet ainsi d'améliorer la réactivité de l'équipage en fonction des événements détectés. Le procédé comprend en outre, de préférence, une étape de détermination d'un niveau de priorité lié à ladite au moins une défaillance, ladite sélection dudit au moins un élément associé à ladite au moins une défaillance étant déterminée en réponse à ladite détection de ladite au moins une défaillance et audit niveau de priorité. Le procédé selon l'invention permet ainsi d'améliorer encore la réactivité de l'équipage en fonction des événements détectés, selon leur importance et/ou leurs conséquences possibles. De façon avantageuse, le procédé comprend en outre une étape d'analyse de ladite au moins une défaillance et, en réponse à ladite analyse de ladite au moins une défaillance, transmission d'une information relative à ladite au moins une défaillance à un dispositif de gestion de paramètres de mission pour permettre à celui-ci de déterminer un éventuel impact de la défaillance détectée sur l'exécution de la mission en cours ou d'une mission future. Selon un mode de réalisation particulier, au moins un élément dudit ensemble d'éléments comprend une indication d'au moins une tâche et/ou d'au moins une vérification à effectuer, le procédé comprenant en outre une étape de validation de ladite indication. Le procédé selon l'invention permet ainsi d'assister l'équipage dans les tâches qu'il doit effectuer. Toujours selon un mode de réalisation particulier, ladite représentation activable d'au moins une commande de servitude dudit aéronef comprend une indication relative à l'état du dispositif contrôlé par ladite au moins une commande, le procédé comprenant une étape de détermination de l'état d'au moins un dispositif contrôlé par au moins une commande dont la représentation appartient audit ensemble d'éléments. L'équipage peut ainsi visualiser l'état des servitudes dont les commandes peuvent être sélectionnées. 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 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 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 ; - les figures 3 à 5 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 que pour accéder à des représentations de commandes activables via l'interface ; - la figure 6 illustre un exemple de représentation d'une commande pouvant être utilisée pour accéder à la commande de la servitude associée et visualiser son état ; - la figure 7 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 8 représente un schéma synoptique comprenant des représentations de commandes telles que celles illustrées sur les figures 6 et 7, ces représentations pouvant être utilisées pour accéder aux commandes ; - la figure 9 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 ; - la figure 10 représente un exemple d'algorithme pouvant être utilisé pour contextualiser l'affichage des paramètres de mission lorsqu'une défaillance technique est détectée ; - la figure 11 illustre un exemple des pages 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 10 ; et, - la figure 12 illustre un exemple d'architecture matérielle adaptée à mettre en oeuvre l'invention. Alors que les interfaces mises en oeuvre dans un cockpit d'aéronef visent généralement à présenter un maximum de commandes au pilote et au copilote, ces commandes étant groupées selon leurs fonctions, seules certaines commandes sont, selon l'invention, simultanément accessibles, ces commandes, accessibles à travers une interface logicielle centralisée, étant déterminées selon un contexte. L'interface centralisée permet notamment de visualiser la configuration de l'aéronef, de le configurer selon un mode d'exploitation normal, de le configurer selon un mode d'exploitation dégradé, d'obtenir une aide à la décision d'exploitation de l'aéronef lorsqu'au moins une défaillance est détectée et de saisir des informations techniques utilisées, notamment, pour des opérations de maintenance. Le contexte peut être déterminé de plusieurs façons. Selon un mode de réalisation particulier, le contexte est 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), en fonction de la détection d'une panne ou d'une défaillance et/ou en réponse à une sélection du pilote. L'interface logicielle centralisée permet de contrôler certains dispositifs de l'aéronef, notamment certaines servitudes, généralement contrôlées par des boutons spécifiques, afin de permettre un accès sélectif, contextuel et interactif aux commandes de ces dispositifs ainsi que la possibilité d'enchaîner automatiquement plusieurs commandes. L'état des dispositifs associés à ces commandes est affiché en liaison avec les représentations de ces commandes. Les commandes accessibles sont ici les commandes permettant de modifier directement l'état d'un ou de plusieurs dispositifs à travers l'interface. Bien que l'interface présentée ici permette de remplacer tous les boutons spécifiques, en particulier les boutons installés sur le plafonnier, 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. Par ailleurs, le cockpit est réorganisé pour permettre une interaction entre l'avionique, comprenant les systèmes de gestion du vol, et les systèmes de contrôle et de commande des servitudes. Ainsi, par exemple, le changement d'un paramètre dans une servitude ayant une incidence sur la mission en cours est transmis aux fonctions de gestion du vol pour alerter le pilote et lui permettre d'adapter la mission sans saisir manuellement les données. 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 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 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'interface 300 comprend ici une partie située à gauche permettant de sélectionner les actions ou les vérifications à effectuer (référence 305) selon l'état de l'aéronef (référence 310). 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 3, 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 315 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 320. 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érification afin de signaler au pilote tout oubli, par exemple sous forme de message d'alerte. La page 300 peut être utilisée comme page principale pour accéder aux paramètres et aux fonctions accessibles via cette interface. La figure 4 représente une deuxième page 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 que pour accéder à des représentations de commandes activables via l'interface. Cette page permet notamment d'afficher les limitations et les conditions fonctionnelles et opérationnelles de l'aéronef (référence 400). Cette page peut être accédée, à partir de l'interface 300, en sélectionnant le bouton � dispatch � de la partie gauche de la page. Selon l'exemple présenté sur la figure 4, l'aéronef est en phase de croisière comme l'illustre la sélection de l'icône située en haut, au centre de la partie gauche. La figure 5 représente une troisième page 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 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. L'interface textuelle 500 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 500, 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, par exemple, les boutons du plafonnier. Ainsi, à titre d'illustration, les lignes 505 et 510 comprennent les indicateurs 515 et 520 dans la première colonne précisant qu'elles sont associées à un lien alors que la ligne 525 n'en possède pas. Il sera observé en outre que l'indicateur 520 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 510. De même, il convient de noter que l'indicateur 530 précise que les actions et/ou vérifications associées à l'objet de la ligne 505 n'ont pas été exécutées tandis que l'indicateur 535 précise que les actions et/ou vérifications associées à la ligne 510 ont été effectuées. L'indicateur 540 vise un lien permettant d'atteindre des représentations de commandes accessibles via l'interface logicielle 500 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 5 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 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équence importante 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 6 illustre un exemple de représentation d'une commande pouvant être utilisée pour accéder à une commande, ici une commande de servitude, et visualiser l'état de la servitude. La référence 600 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 30 commande de pompe. La référence 605 présente la commande et l'état de la pompe lorsque celle-ci est activée (� on �). Le bouton virtuel 605 comprend ici deux parties, une partie 605-1 dans laquelle est représentée une icône indiquant le statut de la servitude et une partie 605-2 décrivant l'état de la commande ainsi que le statut de la servitude, sous forme textuelle. La commande représentée est ici une commande à deux états (� on � ou � off�), il suffit par conséquent de sélectionner la représentation 605 et d'actionner un bouton d'activation pour changer son état. Ainsi, par exemple, la représentation 605 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 610 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 615 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 620 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 625 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 (� lo �). Une indication textuelle correspondante est affichée (� fault �). Un code couleur 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 à une commande du plafonnier pour effectuer une action, une commande de l'interface logicielle peut également être associée à une séquence d'autres commandes. Ce type de commandes offre de nombreux avantages en terme de temps de réaction et en terme 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 7 illustre un exemple de contrôle d'un paramètre pouvant prendre plusieurs valeurs, ici la température. Selon l'exemple référencé 700, la température est sélectionnée à l'aide de plusieurs boutons référencés 705-1 à 705-3, chaque bouton correspondant à une température. Alternativement, selon l'exemple référencé 710, la température est sélectionnée en déplaçant un curseur 720 sur une règle graduée 715. 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 725. Selon cet exemple un mécanisme de sélection de la température 730, tel que le mécanisme 700 ou le mécanisme 710, est associé à plusieurs boutons référencés 735-1 à 735-3 permettant de sélectionner une zone de l'aéronef. La température réglée à l'aide du mécanisme 730 correspond à la zone ou aux zones activées. De façon avantageuse, les commandes illustrées sur les figures 6 et 7 sont intégrées dans des schémas synoptiques tels que celui représenté sur la figure 8 pour permettre la visualisation de la servitude contrôlée 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 5. Le schéma illustré ici concerne un système de gestion du carburant génériquement référencé 800. 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 805-1 et 805-2 adressent des éléments systèmes redondants et que la pompe 805-1, fonctionnant en mode dégradé, est secondée par la pompe 805-2 pour transmettre le carburant vers les vannes ouvertes 810-1 et 810-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 9 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 900 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 905 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 910 sous forme de pages d'écran prédéterminées. Après avoir été déterminés, ces éléments sont affichés (étape 915) 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 920). 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 925) 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 930). 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 935) pour déterminer les conséquences de celui-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 940 pouvant être mémorisé dans la base de données 910 ou dans une autre zone de stockage. Les éléments déterminés sont alors affichés (étape 915) et le processus se poursuit. La figure 10 représente un exemple d'algorithme pouvant être utilisé pour contextualiser l'affichage des paramètres de mission lorsqu'une défaillance technique est détectée dans l'avionique. Après avoir détecté un événement et déterminé que ce dernier est lié à une défaillance technique (étape 1000), les conséquences potentielles de la défaillance sont analysées (étape 1005) afin de déterminer les limitations que peut entraîner la défaillance sur le déroulement d'une mission. Ces limitations sont transmises au dispositif de gestion des paramètres de mission (étape 1010). Une étape suivante a pour objet de déterminer les conséquences de la défaillance sur la mission en cours ou sur une mission future (étape 1015) en corrélant ces conséquences et les paramètres de la mission. Si la défaillance a un impact sur la mission ou sur une mission future, le pilote est alerté (étape 1020). L'alerte peut être un simple message, une représentation graphique des limitations dues à la défaillance détectée et/ou une proposition de modification de la mission. La figure 11 illustre un exemple des pages 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 10. La page 1100 pouvant être affichée sur l'écran central de contrôle technique 200 comprend ici une alerte, sous forme de message 1105, indiquant la défaillance du système de dégivrage, appelé deicing ou anti-icing en terminologie anglo-saxonne. La page 1110 pouvant être affichée sur l'écran central de gestion de mission 205 contient ici un fond cartographique 1115 représentant la zone survolée au cours de la mission, ou une partie de celle-ci, sur lequel est superposée une zone 1120 à éviter matérialisée, par exemple, à l'aide d'une texture et/ou d'une couleur particulière, laissant, de préférence, le fond cartographique partiellement visible. La zone 1120 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. La figure 12 illustre un exemple d'architecture matérielle adaptée à mettre en oeuvre l'invention. Le dispositif 1200 comporte ici un bus de communication 1205 auquel sont reliées : - une unité centrale de traitement ou microprocesseur 1210 (CPU, sigle de Central Processing Unit en terminologie anglo-saxonne) ; - une mémoire morte 1215 (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 1220 (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 1250 adaptée à transmettre et à recevoir des données, notamment vers et depuis les servitudes pour les 10 contrôler et connaître leur état. Le dispositif 1200 dispose également, de préférence, des éléments suivants : - un écran 1225 permettant de visualiser des données telles que des représentations des commandes et de servir d'interface graphique avec 15 l'utilisateur qui pourra interagir avec les programmes selon l'invention, à l'aide d'un clavier et d'une souris 1230 ou d'un autre dispositif de pointage tel qu'un écran tactile ou une télécommande ; - d'un disque dur 1235 pouvant comporter les programmes précités et des données traitées ou à traiter selon l'invention ; et 20 - d'un lecteur de cartes mémoires 1240 adapté à recevoir une carte mémoire 1245 et à y lire ou à y écrire des données traitées ou à traiter selon l'invention. Le bus de communication permet la communication et l'interopérabilité entre les différents éléments inclus dans le dispositif 1200 ou 25 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 1200 directement ou par l'intermédiaire d'un autre élément du dispositif 1200. Le code exécutable de chaque programme permettant au dispositif 30 programmable de mettre en oeuvre les processus selon l'invention, peut être stocké, par exemple, dans le disque dur 1235 ou en mémoire morte 1215. Selon une variante, la carte mémoire 1245 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 1200, est stocké dans le disque dur 1235. Selon une autre variante, le code exécutable des programmes pourra être reçu, au moins partiellement, par l'intermédiaire de l'interface 1250, 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 10 chargés dans un des moyens de stockage du dispositif 1200 avant d'être exécutés. L'unité centrale 1210 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 1235 ou dans la 15 mémoire morte 1215 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 1235 ou la mémoire morte 1215, sont transférés dans la mémoire vive 1220 qui contient alors le code exécutable du ou des programmes selon l'invention, ainsi que des registres 20 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. REVENDICATIONS1. Procédé d'aide au contrôle des systèmes embarqués dans un aéronef comprenant au moins un dispositif d'affichage adapté à afficher des paramètres de configuration dudit aéronef et au moins un dispositif de saisie associé, ce procédé étant caractérisé en ce qu'il comprend les étapes suivantes, - détermination (900) de l'état dudit aéronef ; - sélection (905), selon ledit état dudit aéronef, d'une pluralité d'éléments à afficher sur ledit au moins un dispositif d'affichage dans un ensemble prédéterminé d'éléments comprenant au moins un paramètre de configuration de l'avionique, au moins un paramètre de configuration de servitude et au moins une représentation activable d'au moins une commande de servitude dudit aéronef ; et, - affichage de ladite pluralité d'éléments sur ledit dispositif d'affichage. 2. Procédé selon la revendication précédente comprenant en outre une étape de saisie, de validation, de modification ou d'activation d'au moins un élément sélectionné. 3. Procédé selon la revendication 1 ou la revendication 2 selon lequel ledit ensemble d'éléments comprend en outre au moins un lien vers au moins un élément présélectionné dudit ensemble d'éléments, le procédé comprenant en outre une étape de choix (920) d'au moins un élément de ladite pluralité d'éléments à l'aide desdits moyens de saisie et, en réponse audit choix, la sélection et l'affichage dudit au moins un élément présélectionné. 4. Procédé selon l'une quelconque des revendications précédentes comprenant en outre une étape de détection (930) d'au moins une défaillance, au moins un élément dudit ensemble d'éléments étant associé à ladite au moins une défaillance, et, en réponse à ladite détection de ladite au moins unedéfaillance, la sélection et l'affichage dudit au moins un élément associé à ladite au moins une défaillance. 5. Procédé selon la revendication précédente comprenant en outre une étape de détermination d'un niveau de priorité lié à ladite au moins une défaillance, ladite sélection dudit au moins un élément associé à ladite au moins une défaillance étant déterminée en réponse à ladite détection de ladite au moins une défaillance et audit niveau de priorité. 6. Procédé selon la revendication 4 ou la revendication 5 comprenant en outre une étape d'analyse (1005) de ladite au moins une défaillance et, en réponse à ladite analyse de ladite au moins une défaillance, transmission (1010) d'une information relative à ladite au moins une défaillance à un dispositif de gestion de paramètres de mission. 7. Procédé selon l'une quelconque des revendications précédentes selon lequel au moins un élément dudit ensemble d'éléments comprend une indication d'au moins une tâche et/ou d'au moins une vérification à effectuer, le procédé comprenant en outre une étape de validation de ladite indication. 8. Procédé selon l'une quelconque des revendications précédentes selon lequel ladite représentation activable d'au moins une commande de servitude dudit aéronef comprend une indication relative à l'état du dispositif contrôlé par ladite au moins une commande, le procédé comprenant une étape de détermination de l'état d'au moins un dispositif contrôlé par au moins une commande dont la représentation appartient audit ensemble d'éléments. 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. Aéronef comprenant le dispositif selon la revendication précédente.