FR 2935180 A1 20100226 FR 0855654 A 20080820 La présente invention concerne la commande des systèmes dans un aéronef et plus particulièrement un procédé et un dispositif interactif de contrôle des servitudes dans un aéronef. Les systèmes électroniques et informatiques embarqués à bord d'un aéronef visent essentiellement deux types de fonctionnalités distinctes. Le premier type de systèmes, appelé avionique, concerne l'assistance à l'équipage de l'aéronef pour assurer ses tâches de pilotage, navigation, communication, surveillance de l'environnement et 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, autonome) et les systèmes de surveillance de l'environnement (radar météo, anticollision terrain, anticollision trafic). 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. L'ensemble de ces systèmes est commandé via des interfaces de contrôle. Généralement, l'interface de contrôle de l'avionique se trouve 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 écrans de contrôle référencés 110, l'interface de l'avionique référencée 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 avionique 115 comprend, en raison de la nature complexe des informations entrées dans l'avionique, des touches de saisie alphanumériques ainsi que des boutons de type rotacteur permettant de définir des valeurs. L'interface 125 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 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 et 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 et il existe un risque non négligeable que l'état d'un bouton soit modifié par inadvertance, à la place d'un autre, tous les boutons étant par nature actifs. L'invention permet de résoudre au moins un des problèmes exposés précédemment. L'invention a ainsi pour objet un dispositif de contrôle d'une pluralité de servitudes dans un aéronef, ce dispositif comprenant les moyens suivants, - moyens de filtrage adaptés à déterminer au moins une commande associée à au moins une servitude de ladite pluralité de servitudes selon au moins un paramètre de contexte ; - moyens d'affichage adaptés à afficher au moins une représentation de ladite au moins une commande déterminée ; - moyens de sélection adaptés à sélectionner ladite au moins une représentation ; - moyens d'activation adaptés à transmettre ladite au moins une commande à ladite au moins une servitude en réponse à l'activation de ladite au moins une représentation sélectionnée. Le dispositif selon l'invention permet ainsi d'améliorer l'interface de contrôle des servitudes et de limiter les risques d'erreur de sélection d'une mauvaise commande. Ce dispositif 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 servitudes. Par ailleurs, l'interface de contrôle des servitudes peut être facilement personnalisée. Avantageusement, le dispositif comprend en outre des moyens pour détecter au moins un événement lié audit aéronef, ledit paramètre de contexte étant déterminé selon ledit au moins un événement détecté. Le dispositif selon l'invention permet ainsi d'améliorer la réactivité de l'équipage en fonction des événements détectés. Le dispositif comprend en outre, de préférence, des moyens pour saisir au moins une information, ledit paramètre de contexte étant déterminé selon au moins une information saisie. L'équipage peut ainsi sélectionner simplement les commandes de servitudes. Selon un mode de réalisation particulier, lesdits moyens d'affichage sont adaptés à afficher l'état de ladite au moins une servitude en association avec ladite au moins une représentation. L'équipage peut ainsi visualiser l'état des servitudes dont les commandes peuvent être sélectionnées. Toujours selon un mode de réalisation particulier, lesdits moyens d'affichage sont adaptés à afficher au moins un schéma synoptique dont au moins un élément correspond à ladite au moins une représentation. L'équipage peut ainsi visualiser, dans leur contexte fonctionnel, une représentation des servitudes dont les commandes peuvent être sélectionnées, facilitant la sélection des commandes. Toujours selon un mode de réalisation particulier, lesdits moyens d'activation sont adaptés à transmettre ladite au moins une commande à plusieurs servitudes de ladite pluralité de servitudes en réponse à l'activation de ladite au moins une représentation sélectionnée. Le dispositif selon l'invention permet ainsi de contrôler plusieurs servitudes à l'aide d'une seule commande pour réduire la charge de travail de l'équipage et réduire les risques d'erreur de sélection de mauvaises commandes. Avantageusement, lesdits moyens d'affichage sont adaptés à afficher une pluralité de tâches et/ou de vérifications devant être effectuées, au moins un indicateur étant associé à chacune de ces tâches et/ou vérification pour indiquer si la tâche ou la vérification correspondante a été effectuée. Le dispositif selon l'invention permet ainsi de guider le pilote dans la sélection des commandes. Lesdits moyens d'affichage sont, de préférence, adaptés à afficher au moins un lien associé à au moins une tâche, le dispositif comprenant en outre des moyens pour accéder directement à une représentation d'au moins une commande associée à ladite au moins une tâche selon ledit au moins un lien afin de simplifier la sélection des commandes. De façon avantageuse, le dispositif comprend en outre un dispositif spécifique dédié adapté à générer ladite au moins une commande. L'invention a également pour objet un aéronef comprenant le dispositif selon l'une quelconque des revendications précédentes. 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 deux exemples de représentations de commandes pouvant être utilisées pour accéder aux commandes des servitudes associées et visualiser leur état conformément à l'invention ; - la figure 3 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 conformément à l'invention ; - la figure 4 représente un schéma synoptique comprenant des représentations de commandes telles que celles illustrées sur les figures 2 et 3, ces représentations pouvant être utilisées pour accéder aux commandes ; - la figure 5 illustre l'utilisation d'un arbre de commandes pour contrôler l'alimentation électrique de plusieurs secteurs d'un aéronef selon une granularité variable ; - la figure 6 illustre un exemple de page d'écran de l'interface logicielle permettant d'accéder aux commandes des servitudes, de guider la bonne application d'une procédure à appliquer suite à une anomalie, de vérifier que certaines tâches ont bien été effectuées et/ou de saisir des informations pouvant être utilisées pour des opérations de maintenance et de diagnostic ; - la figure 7 illustre schématiquement un exemple d'algorithme pour sélectionner les commandes de servitudes directement accessibles via l'interface logicielle ; et, - la figure 8 illustre un exemple d'architecture matérielle adaptée à mettre en oeuvre l'invention. L'invention vise à utiliser une interface logicielle, dans un aéronef, pour contrôler au moins certaines servitudes, généralement contrôlées par des boutons du plafonnier, afin de permettre notamment un accès sélectif, contextuel et interactif des commandes de ces servitudes ainsi que l'enchaînement automatique d'une séquence de commandes. Selon un mode de réalisation particulier, un écran est utilisé pour afficher les représentations des commandes accessibles des servitudes pouvant être contrôlées à travers l'interface logicielle. Avantageusement, l'état des servitudes associées à 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'une ou de plusieurs servitudes à travers l'interface logicielle. Cette interface utilise, par exemple, un mécanisme de sélection et d'activation basé sur un système de pointage tel qu'une souris, un écran tactile ou un système similaire. L'interface logicielle de commande des servitudes utilise, par exemple, un écran de contrôle situé dans la zone 110 de la figure 1, les dispositifs permettant d'interagir avec l'interface étant situés, par exemple, dans la zone 115. Bien que l'interface logicielle présentée ici permette de remplacer tous 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 de servitudes sont accessibles à travers l'interface logicielle et les boutons du plafonnier ; - toutes les commandes de servitudes sont accessibles à travers l'interface logicielle, certaines l'étant également à travers les boutons du plafonnier ; - toutes les commandes de servitudes sont accessibles à travers l'interface logicielle, aucune ne l'étant via les boutons du plafonnier ; - certaines commandes de servitudes sont accessibles à travers l'interface logicielle, toutes ces commandes étant accessibles à travers les boutons du plafonnier ; et, - certaines commandes de servitudes sont accessibles à travers l'interface logicielle et certaines commandes le sont via les boutons du plafonnier, des commandes pouvant être accessibles via l'interface logicielle et les boutons du plafonnier. Le choix du mode d'accessibilité des commandes peut être déterminé de différentes façons. Par exemple, ce choix peut être fondé sur la fréquence d'utilisation des commandes, leur rôle vis-à-vis de la sécurité de l'aéronef ou l'intérêt de leur accessibilité selon certaines conditions telle que la détection d'une défaillance ou la phase de vol. De même, la nature de la commande, par exemple le fait que la commande agisse sur un élément ou sur un ensemble d'éléments, peut être un critère de sélection de l'accessibilité de la commande. Le choix du mode d'accessibilité d'une commande peut également être déterminé selon la qualité des personnes pouvant y accéder. Par exemple, le réglage de la température de la cabine peut être réglé, dans certaines limites, par n'importe quel membre d'équipage. Une telle fonction devrait donc être, de préférence, accessible via une interface logicielle pour pouvoir être contrôlée du cockpit mais aussi de la cabine. Pour limiter les risques d'erreur du pilote, du copilote ou d'un membre d'équipage de sélectionner une mauvaise commande, il est avantageux de présenter un nombre limité de commandes accessibles simultanément. L'interface logicielle est donc, de préférence, contextualisée, c'est-à-dire qu'un filtre est utilisé pour n'afficher que les commandes qui sont potentiellement utiles ou qui répondent à une sélection manuelle ou automatique. Le choix des commandes accessibles simultanément peut être défini de plusieurs façons liées à un paramétrage de l'aéronef et/ou à une instruction du pilote, du copilote ou d'un membre d'équipage. Le choix des commandes accessibles simultanément peut être déterminé par les éléments visés par les commandes, par exemple les éléments électriques, les éléments de contrôle du carburant ou les éléments de climatisation, par un état de l'aéronef tel que la phase de vol (roulage au sol, décollage, montée, croisière, descente, atterrissage) ou par la détection d'une panne ou d'une défaillance. Les commandes accessibles simultanément peuvent également être modifiées automatiquement en réponse à la détection d'un état particulier. Ainsi, à titre d'illustration, si le pilote choisit d'afficher les commandes visant la gestion du système électrique, celles-ci peuvent être automatiquement remplacées, avec ou sans validation du pilote ou du copilote, par des commandes de gestion du carburant si une défaillance est détectée sur ces systèmes. Lorsque le nombre de commandes accessibles simultanément est trop important pour permettre un affichage cohérent de celles-ci, elles sont affichées sous forme de plusieurs pages d'écran qui peuvent être affichées les unes à la suite des autres, automatiquement ou sous contrôle du pilote ou du copilote. La figure 2 illustre deux exemples de représentations de commandes pouvant être utilisées pour accéder aux commandes et visualiser l'état des servitudes associées. La référence 200 vise 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 205 présente la commande et l'état de la pompe lorsque celle-ci est activée (� on �). Le bouton virtuel 205 comprend ici deux parties, une partie 205-1 dans laquelle est représentée une icône indiquant le statut de la servitude et une partie 205-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 état (� on � ou � off �), il suffit par conséquent de sélectionner la représentation 205 et d'actionner un bouton d'activation pour changer son état. Ainsi, par exemple, la représentation 205 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 210 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 215 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 220 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 225 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. De façon similaire, la référence 230 vise une représentation d'une commande selon plusieurs états de la servitude associée. Il s'agit ici d'une commande de vanne. La référence 235 représente l'état de la vanne fermée dans un mode de contrôle automatique tandis que la référence 240 représente l'état de la vanne ouverte dans un mode de contrôle manuel en position ouverte et que la référence 245 représente l'état de la vanne ouverte dans un mode de contrôle automatique. 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 commande 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 et la fermeture d'une vanne ainsi que la mise en route et l'arrêt d'une pompe. Dans ce cas, la représentation de la servitude indique 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 3 illustre un exemple de contrôle d'un paramètre pouvant prendre plusieurs valeurs, ici la température. Selon l'exemple référencé 300, la température est sélectionnée à l'aide de plusieurs boutons référencés 305-1 à 305-3. Alternativement, selon l'exemple référencé 310, la température est sélectionnée en déplaçant un curseur 320 sur une règle graduée 315. 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 325. Selon cet exemple un mécanisme de sélection de la température 330, tel que le mécanisme 300 ou le mécanisme 310, est associé à plusieurs boutons référencés 335-1 à 335-3 permettant de sélectionner une zone de l'aéronef. La température réglée à l'aide du mécanisme 330 correspond à la zone ou aux zones activées. De façon avantageuse, les commandes illustrées sur les figures 2 et 3 sont intégrées dans des schémas synoptiques tels que celui représenté sur la figure 4 pour permettre de visualiser la servitude contrôlée dans le système. Le schéma illustré ici concerne un système de gestion du carburant génériquement référencé 400. 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 405-1 et 405-2 adressent des éléments systèmes redondants et que la pompe 405-1, fonctionnant en mode dégradé, est secondée par la pompe 405-2 pour transmettre le carburant vers les vannes ouvertes 410-1 et 410-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 5 illustre l'utilisation d'un tel arbre de commande pour contrôler l'alimentation électrique de plusieurs secteurs d'un aéronef. La partie gauche de la figure illustre l'arbre de commande tandis que la partie droite illustre la page graphique pouvant être affichée pour accéder aux représentations des commandes. Comme illustré, l'arbre de commande 500 comprend une racine représentant une première commande adaptée à activer ou désactiver l'alimentation électrique d'un secteur A référencé 505 via un bouton 510 affiché sur une page 515 pouvant comprendre d'autre boutons, par exemple des boutons pour contrôler des secteurs B et C. Comme indiqué précédemment, chaque bouton comprend avantageusement une représentation de l'état de la servitude associée. De même, chaque bouton comprend de préférence une référence permettant de l'identifier. Le bouton 510 comprend ici la référence � Zone A �, l'indication � ON � et une icône illustrant qu'aucune anomalie n'est détectée. L'arbre 500 comprend un deuxième niveau permettant de contrôler plusieurs sous-ensembles du secteur A tels que les secteurs A1, A2 et A3, référencés 520-1 à 520-3, respectivement. L'affichage correspondant à ce niveau de l'arbre est représenté sur la page 525 comprenant les boutons 530-1 à 530-3 permettant d'activer ou de désactiver l'alimentation électrique des secteurs A1, A2 et A3, respectivement. De façon similaire, l'arbre 500 comprend ici un troisième niveau permettant de contrôler plusieurs sous-ensembles de certains secteurs du second niveau. Selon cet exemple, le troisième niveau permet de contrôler plusieurs sous-ensembles des secteurs A2 et A3 mais pas du secteur Al. A titre d'illustration, les secteurs A21, A22 et A23 du secteur A2 peuvent être contrôlés indépendamment. L'affichage correspondant à cette branche du troisième niveau de l'arbre 500 est représenté sur la page 540 comprenant les boutons 545-1 à 545-3 permettant d'activer ou de désactiver l'alimentation électrique des secteurs A21, A22 et A23, respectivement. Ainsi, lorsque le bouton 510 est sélectionné, il est possible, selon une première commande, d'accéder aux sous-ensembles représentés par ce bouton, c'est-à-dire ici à la page 525. De même, lorsqu'un bouton de l'écran 525 est sélectionné, il est possible, selon une première commande, d'accéder aux sous-ensembles représentés par ce bouton, c'est-à-dire, par exemple, à la page 540. Une deuxième commande permet d'activer ou de désactiver tous les éléments associés à un bouton. Par exemple, si le bouton 510 est sélectionné, cette seconde commande permet d'activer ou de désactiver l'alimentation électrique de tous les secteurs appartenant au secteur A. Les première et seconde commandes peuvent être contrôlées par des boutons physiques, tels que les boutons gauche et droit d'une souris, ou des boutons logiques affichés sur les pages d'écran. De façon similaire à l'utilisation de schémas synoptiques, il est possible de contrôler les commandes à travers une interface textuelle utilisant, par exemple, des liens hypertextes pour passer d'un document à un autre, d'une partie d'un document à une autre ou pour sélectionner la représentation d'une commande ou les représentations de plusieurs commandes. Cette approche permet d'apporter une aide décisionnelle au pilote ou au copilote. Il est également possible d'utiliser une interface textuelle pour atteindre des schémas synoptiques permettant de contrôler les servitudes, comme illustré sur la figure 6. Cette interface peut aussi être utilisée pour saisir des informations permettant de contextualiser l'accès aux commandes de contrôle des servitudes, pour mémoriser de telles informations qui peuvent être utilisées pour des opérations de diagnostic et/ou de maintenance et pour permettre au pilote ou au copilote de contrôler l'exécution de certaines opérations selon une liste de tâches à effectuer. La contextualisation des écrans d'accès aux représentations des commandes est avantageusement liée à un module de diagnostic pour proposer au pilote ou au copilote l'accès aux commandes susceptibles d'être utilisées. 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 configurer les servitudes. 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 de l'action correspondant à la ligne. Cette indication peut être automatiquement mise à jour si l'action a été commandée à travers l'interface logicielle ou manuelle si l'action a été commandée via un bouton du plafonnier. Ainsi, par exemple, 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 représentations de commandes relatives à la fonction définie par la ligne 610. De même, il convient de noter que l'indicateur 630 précise que l'action associée à la ligne 605 n'a pas été exécutée tandis que l'indicateur 635 précise que l'action associée à la ligne 610 a été effectuée. 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. La représentation illustrée sur la figure 6 peut notamment représenter une page de contrôle pouvant être affichée lorsqu'un événement ou une défaillance est détectée. Par exemple, une telle page peut être affichée suite à une détection de fumée. Elle prend alors la forme d'une liste de tâches ou de vérifications à effectuer. Comme décrit précédemment, l'interface de contrôle des servitudes 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 et/ou selon 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 et selon 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 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 représentations des commandes correspondantes 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 représentations des commandes correspondantes est affichée directement pour permettre au pilote ou au copilote de prendre les actions nécessaires rapidement. La figure 7 illustre un exemple d'algorithmes mis en oeuvre pour contrôler les éléments de l'interface logicielle permettant d'accéder à des commandes de contrôle des servitudes. Une étape 700 a pour objet la détermination des éléments de l'interface logicielle devant être affichés, c'est-à-dire la détermination des commandes dont une représentation doit être affichée. Comme décrit précédemment, cette détermination peut être réalisée selon les entrées du pilote ou du copilote ou selon 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 705 sous forme de pages d'écran prédéterminées. Après avoir été déterminés, ces éléments sont affichés (étape 710) sous la forme d'une page. Un test est ensuite effectué pour déterminer si le pilote ou le copilote a sélectionné un objet de la page affichée ou saisi une donnée liée à l'interface logicielle (étape 715). Si le pilote ou le copilote a sélectionné un objet de la page affichée ou saisi une donnée liée à l'interface logicielle, une nouvelle détermination des éléments de l'interface logicielle devant être affichés est effectuée (étape 700) en tenant compte de la sélection ou de la saisie. De façon avantageuse, les pages d'écran sont organisées hiérarchiquement pour permettre le passage de l'une à l'autre selon les entrées du pilote ou du copilote, 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 720 pouvant être mémorisé dans la base de données 705 ou dans une autre zone de stockage. Ainsi, la sélection ou la saisie effectuée par le pilote ou le copilote permet de sélectionner, dans la base de données 705, la page recherchée selon la structure déterminée dans le fichier 720. Les éléments déterminés sont affichés (étape 710) et le processus se poursuit. Si aucun objet de la page affichée n'a été sélectionné et si aucune saisie n'a été effectuée, un autre test est effectué pour déterminer si un événement a été détecté (étape 725). Un événement est ici une défaillance, un changement de configuration, un changement d'état ou plus généralement tout changement pouvant être détecté, de préférence automatiquement. Si aucun événement n'a été détecté, les deux dernières étapes (715 et 725) sont répétées dans l'attente d'une intervention du pilote ou du copilote ou de la détection d'un événement. Au contraire, si un événement est détecté, une nouvelle détermination des éléments de l'interface logicielle devant être affichés est effectuée (étape 700) en tenant compte de l'événement détecté et en utilisant, par exemple, la structure hiérarchique du fichier 720 ou une table de correspondance prédéterminée. Les éléments déterminés sont affichés (étape 710) et le processus se poursuit. La figure 8 illustre un exemple d'architecture matérielle adaptée à mettre en oeuvre l'invention. Le dispositif 800 comporte ici un bus de communication 805 auquel sont reliés : - une unité centrale de traitement ou microprocesseur 810 (CPU, sigle de Central Processing Unit en terminologie anglo-saxonne) ; - une mémoire morte 815 (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 820 (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 850 adaptée à transmettre et à recevoir des données, notamment vers et depuis les servitudes pour les contrôler et connaître leur état. Le dispositif 800 dispose également, de préférence, des éléments suivants : - un écran 825 permettant de visualiser des données telles que 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 830 ou d'un autre dispositif de pointage tel qu'un écran tactile ou une télécommande ; - d'un disque dur 835 pouvant comporter les programmes précités et des données traitées ou à traiter selon l'invention ; et - d'un lecteur de cartes mémoires 840 adapté à recevoir une carte mémoire 845 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 800 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 800 directement ou par l'intermédiaire d'un autre élément du dispositif 800. 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 835 ou en mémoire morte 815. Selon une variante, la carte mémoire 845 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 800, est stocké dans le disque dur 835. Selon une autre variante, le code exécutable des programmes pourra être reçu, au moins partiellement, par l'intermédiaire de l'interface 850, pour être stocké de façon identique à celle décrite précédemment. De manière plus générale, le ou les programmes pourront être chargés dans un des moyens de stockage du dispositif 800 avant d'être 25 exécutés. L'unité centrale 810 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 835 ou dans la mémoire morte 815 ou bien dans les autres éléments de stockage précités. 30 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 835 ou la mémoire morte 815, sont transférés dans la mémoire vive 820 qui contient alors le code exécutable du ou des programmes selon l'invention, ainsi que des registres pour mémoriser les variables et paramètres nécessaires à la mise en oeuvre de l'invention. Naturellement, pour satisfaire des besoins spécifiques, une personne 5 compétente dans le domaine de l'invention pourra appliquer des modifications dans la description précédente. REVENDICATIONS1. Dispositif de contrôle d'une pluralité de servitudes dans un aéronef, ce dispositif étant caractérisé en ce qu'il comprend les moyens suivants, - moyens de filtrage adaptés à déterminer au moins une commande associée à au moins une servitude de ladite pluralité de servitudes selon au 10 moins un paramètre de contexte ; - moyens d'affichage adaptés à afficher au moins une représentation (405, 410, 200, 230, 300, 310) de ladite au moins une commande déterminée ; - moyens de sélection adaptés à sélectionner ladite au moins une 15 représentation ; - moyens d'activation adaptés à transmettre ladite au moins une commande à ladite au moins une servitude en réponse à l'activation de ladite au moins une représentation sélectionnée. 2. Dispositif selon la revendication précédente comprenant en outre 20 des moyens pour détecter au moins un événement lié audit aéronef, ledit paramètre de contexte étant déterminé selon ledit au moins un événement détecté. 3. Dispositif selon l'une quelconque des revendications précédentes comprenant en outre des moyens pour saisir au moins une information, ledit 25 paramètre de contexte étant déterminé selon au moins une information saisie. 4. Dispositif selon l'une quelconque des revendications précédentes selon lequel lesdits moyens d'affichage sont adaptés à afficher l'état de ladite au moins une servitude en association avec ladite au moins une représentation. 5. Dispositif selon l'une quelconque des revendications précédentes 30 selon lequel lesdits moyens d'affichage sont adaptés à afficher au moins un schéma synoptique dont au moins un élément correspond à ladite au moins une représentation. 6. Dispositif selon l'une quelconque des revendications précédentes selon lequel lesdits moyens d'activation sont adaptés à transmettre ladite au moins une commande à plusieurs servitudes de ladite pluralité de servitudes en réponse à l'activation de ladite au moins une représentation sélectionnée. 7. Dispositif selon l'une quelconque des revendications précédentes selon lequel lesdits moyens d'affichage sont adaptés à afficher une pluralité de tâches et/ou de vérifications devant être effectuées, au moins un indicateur étant associé à chacune de ces tâches et/ou vérification pour indiquer si la tâche ou la vérification correspondante a été effectuée. 8. Dispositif selon la revendication précédente selon lequel lesdits moyens d'affichage sont adaptés à afficher au moins un lien associé à au moins une tâche, le dispositif comprenant en outre des moyens pour accéder directement à une représentation d'au moins une commande associée à ladite au moins une tâche selon ledit au moins un lien. 9. Dispositif selon l'une quelconque des revendications précédentes comprenant en outre un dispositif spécifique dédié adapté à générer ladite au moins une commande. 10. Aéronef comprenant le dispositif selon l'une quelconque des revendications précédentes.