Brevet FR3110264A1 — publié le 20211119

Un système d’interfaçage homme-machine permet des interactions entre des applications aéronautiques (201a, 201b, 201c) et des instruments de commande et d’affichage d’aéronef. Le système d’interfaçage homme machine comprend un serveur d’interface (200) communiquant, grâce à un protocole cœur commun, avec les applications aéronautiques (201a, 201b, 201c) et des gestionnaires de contrôle et d’affichage (202a, 202b) réalisant une abstraction des instruments de commande et d’affichage. Le système d’interfaçage homme machine comprend des bibliothèques applicatives d’extension (203a, 203b, 203c) fournissant une implémentation du protocole cœur commun dédiée à chaque application aéronautique (201a, 201b, 201c), ainsi qu’une définition de fenêtres d’affichage dédiée à chaque application aéronautique (201a, 201b, 201c). Le système d’interfaçage homme machine comprend au moins une bibliothèque d’extension d’utilitaires de commande et d’affichage (204) fournissant une implémentation du protocole cœur commun dédiée aux gestionnaires de contrôle et d’affichage (202a, 202b). Ainsi, une architecture flexible, portable et réutilisable, avec des possibilités d’extension et de mise à l’échelle aisées, est proposée. Figure à publier avec l’abrégé : Fig. 2 ARCHITECTURE D’INTERFACAGE HOMME-MACHINE DANS UN AERONEF Le domaine de la présente invention est celui de l’interfaçage homme-machine dans un aéronef. Plus particulièrement, la présente invention concerne une architecture pour mettre en relation des applications aéronautiques avec des instruments de commande et d’affichage destinés aux pilotes d’aéronefs. ETAT DE LA TECHNIQUE ANTERIEURE Dans un aéronef, le cockpit comporte un certain nombre d’instruments de commande et d’affichage. Parmi ceux-ci, des afficheurs permettent d’afficher des données issues d’applications aéronautiques, d’assistance de vol notamment, implémentées par des serveurs d’une avionique de l’aéronef. Aussi, des consoles permettent d’effectuer des saisies de commande (e.g., boutons dédiés) ou de chaînes de caractères (e.g., clavier), notamment pour paramétrer ces applications ou de changer d’écran ou de contexte visualisé sur un afficheur. On peut par exemple citer des planches de bord tout écran, souvent désignées par l’acronyme anglo-saxon CDS (pour « Cockpit Display System »), ou aussi des unités multifonctionnelles de contrôle et d’affichage, désignées sous l’acronyme anglo-saxon MCDU (pour « Multifunctional Control and Display Unit »), ou encore des unités de communications de liaison de données contrôleur-pilote CPDLC (pour « Controller–Pilot Data Link Communications » en anglais), telles que des unités DLCDU (pour « Data Link Control And Display Unit » en anglais). Actuellement, les applications aéronautiques sont dédiées aux instruments de commande et d’affichage avec lesquelles lesdites applications aéronautiques interagissent. D’une famille d’aéronefs à une autre et/ou d’un avionneur à un autre, les instruments de commande et d’affichage, ainsi que les applications aéronautiques, sont typiquement différents. Cette approche entraîne de nombreux développements, bien que les fonctions réalisées soient identiques en substance. De plus, un ajout de nouvelles fonctionnalités d’applications aéronautiques et/ou de nouveaux instruments de commande et d’affichage est une opération complexe et coûteuse en temps de développement, d’intégration et de validation. Il est donc souhaitable de fournir une architecture, pour mettre en relation des applications aéronautiques avec des instruments de commande et d’affichage, qui offre plus de flexibilité, de portabilité et de réutilisabilité, ainsi que de possibilités d’extension et de mise à l’échelle (« scalability » en anglais). A cet effet, il est proposé un système d’interfaçage homme-machine adapté pour permettre des interactions entre des applications aéronautiques et des instruments de commande et d’affichage d’aéronef via le système d’interfaçage homme machine, comprenant : un serveur d’interface où sont connectés les applications aéronautiques et des gestionnaires de contrôle et d’affichage, chaque gestionnaire de contrôle et d’affichage étant associé avec un instrument de commande et d’affichage et réalisant une abstraction de l’instrument de commande et d’affichage associé, le serveur d’interface communiquant avec chaque application aéronautique et chaque gestionnaire de contrôle et d’affichage selon un protocole cœur commun ; des bibliothèques applicatives d’extension auxquelles fait appel le serveur d’interface pour obtenir une implémentation du protocole cœur commun dédiée à chaque application aéronautique, ainsi qu’une définition de fenêtres d’affichage qui est dédiée à chaque application aéronautique et qui a une partie agnostique à toute technologie d’affichage et une autre partie propre à une technologie d’affichage ; et au moins une bibliothèque d’extension d’utilitaires de commande et d’affichage à laquelle fait appel le serveur d’interface pour obtenir une implémentation du protocole cœur commun dédiée aux gestionnaires de contrôle et d’affichage. Ainsi, grâce à une telle architecture, plus de flexibilité, de portabilité et de réutilisabilité sont offertes, ainsi que des possibilités d’extension et de mise à l’échelle. En effet, lorsqu’une nouvelle application aéronautique doit être supportée, les interactions avec tout instrument de commande et d’affichage existant sont assurées grâce au serveur d’interface et au protocole cœur commun. Il suffit alors de fournir une bibliothèque applicative d’extension adaptée aux données / informations produites par cette nouvelle application aéronautique. De même, lorsqu’un nouvel instrument de commande et d’affichage doit être supporté, les interactions avec toute application aéronautique existante sont aussi assurées grâce au serveur d’interface et au protocole cœur commun. Il suffit alors d’associer un gestionnaire de contrôle et d’affichage qui effectue une abstraction adaptée au nouvel instrument de commande et d’affichage. Au besoin une bibliothèque d’extension d’utilitaires de commande et d’affichage peut être aussi ajoutée si le fonctionnement de ce nouvel instrument de commande et d’affichage ne peut être calqué sur ceux déjà présents. Selon un mode de réalisation particulier, le serveur d’interface comporte un gestionnaire de ressources, les ressources permettant une transition entre un domaine propre à des données manipulées et fournies par les applications aéronautiques et un domaine propre à l’affichage, les ressources utilisant pour ce faire les définitions de fenêtres d’affichage dédiées aux applications aéronautiques. Selon un mode de réalisation particulier, le serveur d’interface comporte un gestionnaire de rappels, des premières queues dédiées aux échanges avec les applications aéronautiques et des secondes queues dédiées aux échanges avec les gestionnaires de contrôle et d’affichage, le gestionnaire de rappels étant configuré pour traiter des requêtes et événements reçus et stockés dans les premières et secondes queues en faisant appel aux bibliothèques applicatives d’extension et à ladite au moins une bibliothèque d’utilitaires de commande et d’affichage afin de mettre à jour en conséquence lesdites ressources, le gestionnaire de rappels étant configuré pour insérer dans les secondes queues des événement de mise à jour d’affichage lorsque lesdites ressources sont mises à jour, et le gestionnaire de rappels étant configuré pour insérer dans les premières queues des événements lorsque lesdites ressources sont mises à jour suite au traitement d’événements. Il est aussi proposé une avionique comportant de la circuiterie électronique comportant un tel système d’interfaçage homme-machine sous forme de circuiterie électronique. Il est aussi proposé un aéronef comportant une telle avionique. Il est aussi proposé un procédé d’interfaçage homme-machine adapté pour permettre des interactions entre des applications aéronautiques et des instruments de commande et d’affichage d’aéronef, le procédé étant exécuté par un système d’interfaçage homme machine comprenant : un serveur d’interface où sont connectés les applications aéronautiques et des gestionnaires de contrôle et d’affichage, chaque gestionnaire de contrôle et d’affichage étant associé avec un instrument de commande et d’affichage et réalisant une abstraction de l’instrument de commande et d’affichage associé ; des bibliothèques applicatives d’extension ; et au moins une bibliothèque d’extension d’utilitaires de commande et d’affichage. Le procédé comporte les étapes suivantes effectuées par le serveur d’interface : communiquer avec chaque application aéronautique et chaque gestionnaire de contrôle et d’affichage selon un protocole cœur commun ; faire appel aux bibliothèques applicatives d’extension pour obtenir une implémentation du protocole cœur commun dédiée à chaque application aéronautique, ainsi qu’une définition de fenêtres d’affichage qui est dédiée à chaque application aéronautique et qui a une partie agnostique à toute technologie d’affichage et une autre partie propre à une technologie d’affichage ; et faire appel à ladite au moins une bibliothèque d’extension d’utilitaires de commande et d’affichage pour obtenir une implémentation du protocole cœur commun dédiée aux gestionnaires de contrôle et d’affichage. Il est aussi proposé un produit programme d’ordinateur comportant des instructions implémentant un tel procédé lorsque les instructions sont exécutées par un processeur. Il est aussi proposé un support de stockage d’informations stockant un tel produit programme d’ordinateur. Les caractéristiques de l’invention mentionnées ci-dessus, ainsi que d’autres, apparaîtront plus clairement à la lecture de la description suivante d’un exemple de réalisation, ladite description étant faite en relation avec les dessins joints, parmi lesquels : illustre schématiquement, en vue de dessus, un aéronef dans lequel la présente invention peut être implémentée ; illustre schématiquement un agencement logique d’un système d’interfaçage homme-machine de l’aéronef ; illustre schématiquement un exemple d’agencement matériel du système d’interfaçage homme-machine ; illustre schématiquement un agencement fonctionnel du système d’interfaçage homme-machine ; illustre schématiquement un agencement matériel d’une circuiterie électronique du système d’interfaçage homme-machine ; illustre schématiquement un premier exemple d’échanges intervenant dans le système d’interfaçage homme-machine ; et illustre schématiquement un second exemple d’échanges intervenant dans le système d’interfaçage homme-machine. EXPOSE DETAILLE DE MODES DE REALISATION La Fig. 1 illustre schématiquement, en vue de dessus, un aéronef 100. L’aéronef 100 comporte un cockpit dans lequel au moins un pilote est destiné à s’installer pour manœuvrer l’aéronef 100. Dans le cockpit, le ou les pilotes disposent d’instruments de commande et d’affichage, tels que des planches de bord tout écran CDS, des unités multifonctionnelles de contrôle et d’affichage MCDU, une unité de communications de liaison de données contrôleur-pilote CPDLC, ou des équipements portables de type sacoche de vol électronique EFB (pour « Electronic Flying Bag » en anglais), etc. L’aéronef 100 est en outre équipé de serveurs 101 d’avionique implémentant des applications aéronautiques fournissant une assistance au ou aux pilotes pour manœuvrer l’aéronef 100. Par exemple, ces applications aéronautiques concernent la gestion de vol (« Flight Management » en anglais) ou les communications contrôleur-pilote. Pour assurer les interactions entre les applications aéronautiques et les instruments de commande et d’affichage, l’aéronef 100 comporte un système d’interfaçage homme-machine, dont un agencement logique est schématiquement illustré sur la Fig. 2 . Le système d’interfaçage homme-machine comporte un serveur d’interface HMI_S 200 configuré pour permettre à des applications aéronautiques d’interagir avec des instruments de commande et d’affichage de l’aéronef 100. Trois applications aéronautiques APP1 201a, APP2 201b, APP3 201c sont représentées à titre illustratif sur la Fig. 2. Chaque instrument de commande et d’affichage est muni, de manière intégrée ou associée en externe (voir Fig. 3 ci-après), d’un gestionnaire de contrôle et d’affichage CDM (« Control and Display Manager » en anglais). Deux gestionnaires de contrôle et d’affichage CDM1 202a, CDM2 202b sont représentés à titre illustratif sur la Fig. 2. Chaque application aéronautique et chaque gestionnaire de contrôle et d’affichage CDM sont connectés au serveur d’interface HMI_S 200 et sont clients de fonctionnalités d’abstraction du serveur d’interface HMI_S 200. Pour ce faire, chaque application aéronautique et chaque gestionnaire de contrôle et d’affichage CDM communiquent avec le serveur d’interface HMI_S 200 selon un protocole cœur commun ; ainsi des messages au même format sont échangés entre les applications aéronautiques APP1 201a, APP2 201b, APP3 201c et le serveur d’interface HMI_S 200 et entre le serveur d’interface HMI_S 200 et les gestionnaires de contrôle et d’affichage CDM1 202a, CDM2 202b. Typiquement, ces messages sont des requêtes, éventuellement suivies de réponses, et des événements, éventuellement aussi suivis de réponses (e.g., transmission de code d’erreur le cas échéant). Selon un mode de réalisation, chaque message du protocole cœur suit un format commun comportant un champ ClientID d’identifiant de client (qui identifie le client concerné), un champ L de longueur (qui renseigne la longueur du message), un champ OpCode de code d’opération et un champ PLD de données utiles (« payload data » en anglais) qui dépendent de la valeur du champ de code d’opération OpCode. D’autres champs peuvent être prédéfinis dans le format commun. Les applications aéronautiques APP1 201a, APP2 201b, APP3 201c produisent des données, comme par exemple des données de vol (e.g., altitude), ou plus généralement des informations, comme par exemple des alarmes, à afficher sur un ou plusieurs des instruments de commande et d’affichage. Les applications aéronautiques ne sont pas en charge de la manière dont ces informations sont effectivement rendues au ou aux pilotes de l’aéronef 100. Le système d’interfaçage homme-machine comporte en outre des bibliothèques applicatives d’extension, chacune d’elles étant associée à une application aéronautique. Ainsi, la Fig. 2 présente à titre illustratif trois bibliothèques applicatives d’extension AEXT1 203a, AEXT2 203b, AEXT3 203c. Les bibliothèques applicatives d’extension AEXT1 203a, AEXT2 203b, AEXT3 203c définissent le détail du protocole d’échanges entre le serveur d’interface HMI_S 200 et les applications aéronautiques APP1 201a, APP2 201b, APP3 201c respectives, notamment les différents codes d’opération OpCode utilisables, toute structure de données applicable à chaque code d’opération OpCode, y compris la définition de requêtes (fourniture de données ou de mise à jour d’informations, génération de signal d’alerte…) et d’événements (saisie d’informations utilisateur…). Les bibliothèques applicatives d’extension AEXT1 203a, AEXT2 203b, AEXT3 203c fournissent en outre une implémentation du protocole d’échanges entre le serveur d’interface HMI_S 200 et les applications aéronautiques APP1 201a, APP2 201b, APP3 201c respectives, c’est-à-dire le comportement du serveur d’interface HMI_S 200 dans les échanges avec les applications aéronautiques APP1 201a, APP2 201b, APP3 201c respectives pour traiter les requêtes, générer les événements et les éventuelles réponses aux requêtes… De plus, les bibliothèques applicatives d’extension AEXT1 203a, AEXT2 203b, AEXT3 203c contextualisent l’affichage des données et informations produites par leurs applications aéronautiques respectives APP1 201a, APP2 201b, APP3 201c. Les gestionnaires de contrôle et d’affichage CDM1 202a, CDM2 202b sont des modules d’abstraction des instruments de commande et d’affichage, et servent ainsi à faire une conversion entre des messages échangés avec le serveur d’interface HMI_S 200 et des signaux ou instructions d’interaction réelle avec les instruments de commande et d’affichage. Les gestionnaires de contrôle et d’affichage CDM1 202a, CDM2 202b permettent ainsi d’interagir avec tout type d’instrument de commande et d’affichage en s’appuyant sur le format du protocole cœur. Le système d’interfaçage homme-machine comporte en outre au moins une bibliothèque d’extension d’utilitaires de commande et d’affichage CDEXT 204. Préférentiellement, le système d’interfaçage homme-machine comporte une unique bibliothèque d’extension d’utilitaires de commande et d’affichage CDEXT 204, car les interactions avec les différents instruments de commande et d’affichage sont similaires (appui sur un bouton, demande de mise à jour d’affichage…). La bibliothèque d’extension d’utilitaires de commande et d’affichage CDEXT 204 définit le détail du protocole d’échanges entre le serveur d’interface HMI_S 200 et les gestionnaires de contrôle et d’affichage CDM1 202a, CDM2 202b, notamment les différents codes d’opération OpCode utilisables, toute structure de données applicable à chaque code d’opération OpCode, y compris la définition de requêtes (demande d’affichage, de mise à jour ou de rafraichissement d’affichage…) et d’événements (saisie de caractère, appui sur un bouton ou un icône, réglage de molette…). La bibliothèque d’extension d’utilitaires de commande et d’affichage CDEXT 204 fournit en outre une implémentation du protocole d’échanges entre le serveur d’interface HMI_S 200 et les gestionnaires de contrôle et d’affichage CDM1 202a, CDM2 202b, c’est-à-dire le comportement du serveur d’interface HMI_S 200 dans les échanges avec les gestionnaires de contrôle et d’affichage CDM1 202a, CDM2 202b pour générer les requêtes, traiter les événements… Une telle architecture du système d’interfaçage homme-machine permet de séparer les fonctionnalités qui sont de l’ordre du domaine des données / informations elles-mêmes et les fonctionnalités qui sont de l’ordre du domaine de l’affichage. Cet aspect est détaillé ci-dessous en relation avec la Fig. 4. La Fig. 3 illustre schématiquement un exemple d’agencement matériel du système d’interfaçage homme-machine focalisant sur des localisations possibles des applications aéronautiques APP1 201a, APP2 201b, APP3 201c et des gestionnaires de contrôle et d’affichage CDM1 202a, CDM2 202b. Le serveur d’interface HMI_S 200 est implémenté par une circuiterie électronique 310. Par exemple, comme illustré sur la Fig. 3, la circuiterie électronique 310 est une circuiterie électronique de l’avionique 300 de l’aéronef 100 qui implémente aussi les applications aéronautiques APP1 201a, APP2 201b. La circuiterie électronique 310 est par exemple un dispositif serveur ou un ensemble de dispositifs serveurs. Le gestionnaire de contrôle et d’affichage CDM1 202a est aussi implémenté par une circuiterie électronique de l’avionique 300. Le gestionnaire de contrôle et d’affichage CDM1 202a est connecté via un jeu d’entrées-sorties à un instrument de commande et d’affichage HMI1 330, tel qu’une unité multifonctionnelle de contrôle et d’affichage MCDU. Le gestionnaire de contrôle et d’affichage CDM2 202b et l’application aéronautique APP3 201c sont embarqués dans une sacoche de vol électronique EFB 320. Par exemple, dans l’agencement de la Fig. 3, l’application aéronautique APP1 201a génère des données / informations qui sont affichées par l’instrument de commande et d’affichage HMI1 330 via le gestionnaire de contrôle et d’affichage CDM1 202a, l’application aéronautique APP2 201b génère des données / informations qui sont affichées par la sacoche de vol électronique EFB 320 via le gestionnaire de contrôle et d’affichage CDM2 202b. L’application aéronautique APP3 201c génère des données / informations qui sont affichées par la sacoche de vol électronique EFB 320 via le gestionnaire de contrôle et d’affichage CDM2 202b. Les données / informations générées par l’application aéronautique APP3 201c peuvent aussi être affichées par l’instrument de commande et d’affichage HMI1 330 via le gestionnaire de contrôle et d’affichage CDM1 202a. Les bibliothèques applicatives d’extension AEXT1 203a, AEXT2 203b, AEXT3 203c, ainsi que ladite au moins une bibliothèque d’extension d’utilitaires de commande et d’affichage CDEXT 204, sont aussi implémentées par de la circuiterie électronique de l’avionique 300, par exemple par la circuiterie électronique 310. La Fig. 3 montre ainsi que l’architecture proposée offre une grande flexibilité de mise en œuvre. La Fig. 4 illustre schématiquement un agencement fonctionnel du système d’interfaçage homme-machine. La Fig. 4 illustre plus particulièrement un agencement du serveur d’interface HMI_S 200, dans le cadre d’une mise en relation entre l’application aéronautique APP1 201a et le gestionnaire de contrôle et d’affichage CDM1 202a. Le serveur d’interface HMI_S 200 comporte des premières queues APPQ 440 dédiées aux échanges avec les applications aéronautiques APP1 201a, APP2 201b, APP3 201c. Les premières queues APPQ 440 sont configurées pour stocker temporairement des messages, formatés selon le protocole cœur commun, échangés avec les applications aéronautiques APP1 201a, APP2 201b, APP3 201c. Préférentiellement, les premières queues APPQ 440 incluent une queue de transmission et une queue de réception pour chaque application aéronautique. Le serveur d’interface HMI_S 200 comporte des secondes queues CDMQ 450 dédiées aux échanges avec les gestionnaires de contrôle et d’affichage CDM1 202a, CDM2 202b. Les secondes queues CDMQ 450 sont configurées pour stocker temporairement des messages, formatés selon le protocole cœur commun, échangés avec les gestionnaires de contrôle et d’affichage CDM1 202a, CDM2 202b. Préférentiellement, les secondes queues CDMQ 450 incluent une queue de transmission et une queue de réception pour chaque gestionnaire de contrôle et d’affichage CDM. Le serveur d’interface HMI_S 200 comporte un gestionnaire de rappels CB_MGR (« callback manager » en anglais) 430 en charge d’exécuter un processus principal (« main process » en anglais) du serveur d’interface HMI_S 200. Le processus principal est en charge de traiter des messages reçus dans les premières queues APPQ 440, et d’effectuer en conséquence des appels vers les bibliothèques applicatives d’extension AEXT1 203a, AEXT2 203b, AEXT3 203c. Comme déjà mentionné, les bibliothèques applicatives d’extension AEXT1 203a, AEXT2 203b, AEXT3 203c fournissent une définition et une implémentation (labélisées PROT sur la Fig. 4) du protocole d’échanges entre le serveur d’interface HMI_S 200 et les applications aéronautiques APP1 201a, APP2 201b, APP3 201c respectives. Les bibliothèques applicatives d’extension AEXT1 203a, AEXT2 203b, AEXT3 203c fournissent aussi une définition (labélisée DREF sur la Fig. 4) des structures de données / informations potentiellement fournies par les applications aéronautiques APP1 201a, APP2 201b, APP3 201c respectives. Le processus principal est aussi en charge de traiter les messages reçus dans les secondes queues CDMQ 450, et d’effectuer en conséquence des appels vers ladite au moins une bibliothèque d’extension d’utilitaires de commande et d’affichage CDEXT 204. Comme déjà mentionné, ladite au moins une bibliothèque d’extension d’utilitaires de commande et d’affichage CDEXT 204 fournit une définition et une implémentation (labélisées PROT sur la Fig. 4) du protocole d’échanges entre le serveur d’interface HMI_S 200 et les gestionnaires de contrôle et d’affichage CDM1 202a, CDM2 202b. Le processus principal est aussi en charge d’assurer des mises à jour d’affichage auprès des gestionnaires de contrôle et d’affichage CDM1 202a, CDM2 202b grâce à des définitions de fenêtres d’affichage (labelisées WDW sur la Fig. 4), qui sont fournies par les bibliothèques applicatives d’extension AEXT1 203a, AEXT2 203b, AEXT3 203c. Les définitions de fenêtres d’affichage WDW ont une partie agnostique à toute technologie d’affichage et une partie propre à l’affichage. Cela permet de donner de la flexibilité pour une potentielle évolution par ajout d’un nouvel instrument de commande et d’affichage, car seule la partie propre à l’affichage est alors à adapter, le reste pouvant être réutilisé d’une conception préédente. Préférentiellement, pour la partie propre à l’affichage, les définitions de fenêtres d’affichage sont hiérarchisées par contextes, pages, entités et éléments atomiques (e.g. « widgets »). Les éléments atomiques sont les plus petits éléments affichables. Une ou plusieurs entités sont affichées sur une même page, et comportent chacune un ou plusieurs éléments atomiques. Un contexte est composé d’une ou plusieurs pages associées à un même sujet d’affichage, par exemple par équivalence à des couches de pages d’application utilisateur UAPL (« User Applications Page Layers » en anglais, parfois aussi dénommés sous l’acronyme simplifié UAL, pour « User Application Layers » en anglais) du standard ARINC 661. Le processus principal est aussi en charge d’assurer des transmissions de messages (e.g., événements, réponses) stockés dans les premières queues APPQ 440 à l’attention des applications aéronautiques APP1 201a, APP2 201b, APP3 201c et des transmissions de messages (e.g., pour mise à jour d’affichage) stockés dans les secondes queues CDMQ 450 à l’attention des gestionnaires de contrôle et d’affichage CDM1 202a, CDM2 202b. Des exemples d’exécutions réalisées par le processus principal sont présentés ci-après en relation avec les Figs. 6 et 7. Ainsi, l’architecture proposée effectue une transition entre un domaine 470 propre aux données / informations telles que manipulées et fournies par les applications aéronautiques APP1 201a, APP2 201b, APP3 201c et un domaine 460 propre à l’affichage. Pour gérer cette transition, le serveur d’interface HMI_S 200 met en œuvre des ressources gérées par un gestionnaire de ressources RES_MGR 410 qui utilisent les définitions de fenêtres d’affichage WDW pour faire le lien entre le domaine 470 propre aux données / informations telles que manipulées et fournies par les applications aéronautiques APP1 201a, APP2 201b, APP3 201c et le domaine 460 propre à l’affichage. Par exemple, sur la Fig. 4, une ressource RES1 420 fait la transition entre le domaine 470 des données de l’application aéronautique APP1 210a et le domaine 460 des données du gestionnaire de contrôle et d’affichage CDM1 202a. Chaque ressource définit un type de donnée concernée (chaîne de caractères, entier, date…) et définit aussi si la mise à jour de la ressource est réalisable depuis le domaine 460 (e.g., saisie utilisateur) ou depuis le domaine 470 (donnée poussée par l’application aéronautique concernée). Lorsque l’application aéronautique APP1 201a pousse une mise à jour d’une donnée, la ressource RES1 420 est mise à jour en conséquence par écriture via le domaine 470 et l’affichage de cette donnée par le gestionnaire de contrôle et d’affichage CDM1 202a est mis à jour via le domaine 460 par lecture de cette ressource RES1 420. Des transitions depuis le domaine 460 vers le domaine 470 sont aussi possibles via la ressource RES1 420, par exemple lorsqu’une saisie de caractères est effectuée via l’instrument de commande et d’affichage géré par le gestionnaire de contrôle et d’affichage CDM1 202a. La Fig. 5 illustre schématiquement un agencement matériel d’une circuiterie électronique du système d’interfaçage homme-machine, comme par exemple la circuiterie électronique 310. La circuiterie électronique considérée comporte alors, reliés par un bus de communication 510 : un processeur ou CPU (« Central Processing Unit » en anglais) 501 ; une mémoire vive RAM (« Read-Only Memory » en anglais) 502 ; une mémoire morte 503, par exemple de type ROM (« Read Only Memory » en anglais) ou EEPROM (pour « Electrically-Erasable Programmable ROM » en anglais) ; une unité de stockage 504, telle qu’un disque dur HDD (pour « Hard Disk Drive » en anglais), ou un lecteur de support de stockage, tel qu’un lecteur de cartes SD (pour « Secure Digital » en anglais) ; un gestionnaire d’entrées-sorties ou d’interfaces de communication COM 505. Le processeur 501 est capable d’exécuter des instructions chargées dans la mémoire vive 502 à partir de la mémoire morte 303, d’une mémoire externe, d’un support de stockage (tel qu’une carte SD), ou d’un réseau de communication. Lorsque la circuiterie électronique est mise sous tension, le processeur 501 est capable de lire de la mémoire vive 502 des instructions et de les exécuter. Ces instructions forment un programme d’ordinateur causant l’implémentation, par le processeur 501, de tout ou partie des modules, étapes et fonctionnements décrits ici en relation avec de la circuiterie électronique. Tout ou partie des modules, étapes et fonctionnements décrits ici en relation avec de la circuiterie électronique peut ainsi être implémenté sous forme logicielle par exécution d’un ensemble d’instructions par une machine programmable, par exemple un processeur de type DSP (« Digital Signal Processor » en langue anglo-saxonne) ou un processeur, ou être implémenté sous forme matérielle par une machine ou un composant (« chip » en anglais) dédié, par exemple un composant FPGA (pour « Field Programmable Gate Array » en anglais) ou ASIC (pour « Application Specific Integrated Circuit » en anglais). A noter qu’il est possible de déployer les application aéronautiques APP, le serveur d’interface HMI_S et les gestionnaires de contrôle et d’affichage CDM, sur des machines séparées ou sur une même machine sans modification structurelle de l’architecture présentée sur la Fig. 2. La Fig. 6 illustre schématiquement un premier exemple d’échanges intervenant dans le système d’interfaçage homme-machine. Dans une étape 601, le gestionnaire de rappels CB_MGR 430 vérifie si des messages sont stockés en attente dans les premières queues APPQ 440 en provenance des applications aéronautiques APP1 201a, APP2 201b, APP3 201c. Si tel est le cas, le gestionnaire de rappels CB_MGR 430 accède en lecture (RD sur la Fig. 6) aux premières queues APPQ 440 dans une étape 602. Une gestion de priorité peut être mise en place dans l’ordre de traitement des messages en attente dans les premières queues APPQ 440. Considérons à titre illustratif que le gestionnaire de rappels CB_MGR 430 obtient une requête soumise par l’application aéronautique APP1 201a et pour laquelle l’application aéronautique APP1 201a fournit une mise à jour d’une donnée à afficher. Dans une étape 603, le gestionnaire de rappels CB_MGR 430 traite la requête obtenue à l’étape 602. Le gestionnaire de rappels CB_MGR 430 lance une exécution (EXEC sur la Fig. 6) d’un traitement correspondant au code d’opération OpCode contenu dans la requête, en accédant dans une étape 604 à la bibliothèque applicative d’extension AEXT1 203a associée avec l’application aéronautique APP1 201a. Dans une étape 605, le traitement défini par l’implémentation protocolaire de la bibliothèque applicative d’extension AEXT1 203a est effectué. Durant ce traitement, dans une étape 606, une instruction de mise à jour (ST sur la Fig. 6) de la ressource RES1 conformément à la requête soumise par l’application aéronautique APP1 201a est transmise au gestionnaire de ressources RES_MGR 410, qui effectue la mise à jour dans une étape 607. Dans une étape 608, le gestionnaire de rappels CB_MGR 430 vérifie si une mise à jour d’affichage doit être effectuée. La ressource RES1 ayant été mise à jour suite à la requête soumise par l’application aéronautique APP1 201a, le gestionnaire de rappels CB_MGR 430 obtient (GT sur la Fig. 6), dans une étape 609, la nouvelle valeur de la donnée correspondante par le biais du gestionnaire de ressources RES_MGR 410, avec la définition de fenêtre d’affichage définie par la bibliothèque applicative d’extension AEXT1 203a. Dans une étape 610, le gestionnaire de rappels CB_MGR 430 génère un événement destiné au gestionnaire de contrôle et d’affichage CDM1 202a pour prendre en compte la mise à jour d’affichage. Alors, dans une étape 611, le gestionnaire de rappels CB_MGR 430 accède en écriture (WR sur la Fig. 6) aux secondes queues CDMQ 450 pour y stocker l’événement en question. L’événement est alors transmis par le gestionnaire de rappels CB_MGR 430 au gestionnaire de contrôle et d’affichage CDM1 202a dès lors que des messages éventuellement déjà stockés dans les secondes queues CDMQ 450 ont été eux-mêmes transmis. Une gestion de priorité peut toutefois être mise en place dans l’ordre de transmission des messages en attente dans les secondes queues CDMQ 450. La Fig. 7 illustre schématiquement un second exemple d’échanges intervenant dans le système d’interfaçage homme-machine. Dans une étape 701, le gestionnaire de rappels CB_MGR 430 vérifie si des messages sont stockés en attente dans les secondes queues CDMQ 450 en provenance des gestionnaires de contrôle et d’affichage CDM1 202a, CDM2 202b. Si tel est le cas, le gestionnaire de rappels CB_MGR 430 accède en lecture (RD sur la Fig. 7) aux secondes queues CDMQ 450 dans une étape 702. Une gestion de priorité peut être mise en place dans l’ordre de traitement des messages en attente dans les secondes queues CDMQ 450. Considérons à titre illustratif que le gestionnaire de rappels CB_MGR 430 obtient un événement soumis par le gestionnaire de contrôle et d’affichage CDM1 202a et pour lequel le gestionnaire de contrôle et d’affichage CDM1 202a fournit une saisie utilisateur à prendre en compte. Dans une étape 703, le gestionnaire de rappels CB_MGR 430 traite l’événement obtenu à l’étape 702. Le gestionnaire de rappels CB_MGR 430 lance une exécution (EXEC sur la Fig. 7) d’un traitement correspondant au code d’opération OpCode contenu dans la requête, en accédant dans une étape 704 à ladite au moins une bibliothèque d’extension d’utilitaires de commande et d’affichage CDEXT 204. Dans une étape 705, le traitement défini par l’implémentation protocolaire de ladite au moins une bibliothèque d’extension d’utilitaires de commande et d’affichage CDEXT 204 est effectué. Durant ce traitement, dans une étape 706, un administrateur (« handler » en anglais, HDL sur la Fig. 7) d’événements qui est attaché à la définition de fenêtres d’affichage (WDW) de la bibliothèque applicative d’extension AEXT1 203a est appelé. Cet administrateur d’événements est exécuté dans une étape 707, au cours de laquelle une instruction de mise à jour (ST sur la Fig. 7) de la ressource RES1 conformément à l’événement soumis par le gestionnaire de contrôle et d’affichage CDM1 202a est transmise, dans une étape 708, au gestionnaire de ressources RES_MGR 410, qui effectue la mise à jour dans une étape 709. La mise à jour de la ressource RES1 depuis le domaine 460 doit être signifiée à l’application aéronautique APP1 201a. Pour ce faire, dans une étape 710, le gestionnaire de ressources RES_MGR 410 appelle un administrateur (« handler » en anglais, HDL sur la Fig. 7) d’événements qui est attaché à l’implémentation protocolaire de la bibliothèque applicative d’extension AEXT1 203a. Cet administrateur d’événements génère, dans une étape 711, un événement destiné à l’application aéronautique APP1 201a pour prendre en compte la saisie de caractères soumise par le gestionnaire de contrôle et d’affichage CDM1 202a. Alors, dans une étape 712, cet administrateur d’événements accède en écriture (WR sur la Fig. 7) aux premières queues APPQ 440 pour y stocker l’événement en question. Dans une étape 713, le gestionnaire de rappels CB_MGR 430 vérifie si une mise à jour d’affichage doit être effectuée. La ressource RES1 ayant été mise à jour suite à l’événement soumis par le gestionnaire de contrôle et d’affichage CDM1 202a, le gestionnaire de rappels CB_MGR 430 obtient (GT sur la Fig. 7), dans une étape 714, la mise à jour d’affichage concernant la saisie de caractères. La mise à jour d’affichage est obtenue par le biais du gestionnaire de ressources RES_MGR 410, avec la définition de fenêtre d’affichage définie par la bibliothèque applicative d’extension AEXT1 203a. Dans une étape 715, le gestionnaire de rappels CB_MGR 430 génère un événement destiné au gestionnaire de contrôle et d’affichage CDM1 202a pour prendre en compte la mise à jour d’affichage. Alors, dans une étape 716, le gestionnaire de rappels CB_MGR 430 accède en écriture (WR sur la Fig. 7) aux secondes queues CDMQ 450 pour y stocker l’événement en question. L’événement est alors transmis par le gestionnaire de rappels CB_MGR 430 au gestionnaire de contrôle et d’affichage CDM1 202a dès lors que des messages éventuellement déjà stockés dans les secondes queues CDMQ 450 ont été eux-mêmes transmis. Ici encore, une gestion de priorité peut toutefois être mise en place dans l’ordre de transmission des messages en attente dans les secondes queues CDMQ 450. Ainsi, grâce à l’architecture et aux fonctionnements présentés ci-dessus, lorsqu’une nouvelle application aéronautique doit être supportée, les interactions avec tout instrument de commande et d’affichage existant sont assurées grâce au serveur d’interface HMI_S 200 et au protocole cœur commun. Il suffit alors de fournir une bibliothèque applicative d’extension adaptée aux données / informations produites par cette nouvelle application aéronautique. De même, lorsqu’un nouvel instrument de commande et d’affichage doit être supporté, les interactions avec toute application aéronautique existante sont aussi assurées grâce au serveur d’interface HMI_S 200 et au protocole cœur commun. Il suffit alors d’associer un gestionnaire de contrôle et d’affichage CDM qui effectue une abstraction adaptée au nouvel instrument de commande et d’affichage. L’architecture proposée offre ainsi flexibilité, portabilité et réutilisabilité, ainsi que des possibilités d’extension et de mise à l’échelle aisées. Système d’interfaçage homme-machine adapté pour permettre des interactions entre des applications aéronautiques (201a, 201b, 201c) et des instruments de commande et d’affichage d’aéronef (320, 330) via le système d’interfaçage homme machine, comprenant : - un serveur d’interface (200) où sont connectés les applications aéronautiques (201a, 201b, 201c) et des gestionnaires de contrôle et d’affichage (202a, 202b), chaque gestionnaire de contrôle et d’affichage (202a, 202b) étant associé avec un instrument de commande et d’affichage (320, 330) et réalisant une abstraction de l’instrument de commande et d’affichage associé, le serveur d’interface (200) communiquant avec chaque application aéronautique (201a, 201b, 201c) et chaque gestionnaire de contrôle et d’affichage (202a, 202b) selon un protocole cœur commun ; - des bibliothèques applicatives d’extension (203a, 203b, 203c) auxquelles fait appel le serveur d’interface (200) pour obtenir une implémentation du protocole cœur commun dédiée à chaque application aéronautique (201a, 201b, 201c), ainsi qu’une définition de fenêtres d’affichage qui est dédiée à chaque application aéronautique (201a, 201b, 201c) et qui a une partie agnostique à toute technologie d’affichage et une autre partie propre à une technologie d’affichage ; et - au moins une bibliothèque d’extension d’utilitaires de commande et d’affichage (204) à laquelle fait appel le serveur d’interface (200) pour obtenir une implémentation du protocole cœur commun dédiée aux gestionnaires de contrôle et d’affichage (202a, 202b). Système d’interfaçage homme-machine selon la revendication 1, dans lequel le serveur d’interface (200) comporte un gestionnaire de ressources (410) gérant des ressources (420) permettant une transition entre un domaine (470) propre à des données manipulées et fournies par les applications aéronautiques et un domaine (460) propre à l’affichage, les ressources utilisant pour ce faire les définitions de fenêtres d’affichage dédiées aux applications aéronautiques (201a, 201b, 201c). Système d’interfaçage homme-machine selon la revendication 2, dans lequel le serveur d’interface (200) comporte un gestionnaire de rappels (430), des premières queues (440) dédiées aux échanges avec les applications aéronautiques (201a, 201b, 201c) et des secondes queues (450) dédiées aux échanges avec les gestionnaires de contrôle et d’affichage (202a, 202b), le gestionnaire de rappels (430) étant configuré pour traiter des requêtes et événements reçus et stockés dans les premières (440) et secondes (450) queues en faisant appel aux bibliothèques applicatives d’extension (203a, 203b, 203c) et à ladite au moins une bibliothèque d’extension d’utilitaires de commande et d’affichage (204) afin de mettre à jour en conséquence lesdites ressources (420), le gestionnaire de rappels (430) étant configuré pour insérer dans les secondes queues (450) des événements de mise à jour d’affichage lorsque lesdites ressources (420) sont mises à jour, et le gestionnaire de rappels (430) étant configuré pour insérer dans les première queues (440) des événements lorsque lesdites ressources (420) sont mises à jour suite au traitement d’événements. Avionique (300) comportant de la circuiterie électronique (310) comportant le système d’interfaçage homme-machine selon l’une des revendications 1 à 3 sous forme de circuiterie électronique. Aéronef (100) comportant l’avionique (300) selon la revendication 4. Procédé d’interfaçage homme-machine adapté pour permettre des interactions entre des applications aéronautiques (201a, 201b, 201c) et des instruments de commande et d’affichage (320, 330) d’aéronef (100), le procédé étant exécuté par un système d’interfaçage homme machine comprenant : - un serveur d’interface (200) où sont connectés les applications aéronautiques (201a, 201b, 201c) et des gestionnaires de contrôle et d’affichage (202a, 202b), chaque gestionnaire de contrôle et d’affichage (202a, 202b) étant associé avec un instrument de commande et d’affichage (320, 330) et réalisant une abstraction de l’instrument de commande et d’affichage (320, 330) associé ; - des bibliothèques applicatives d’extension (203a, 203b, 203c) ; et - au moins une bibliothèque d’extension d’utilitaires de commande et d’affichage (204), le procédé comportant les étapes suivantes effectuées par le serveur d’interface (200) : - communiquer avec chaque application aéronautique (201a, 201b, 201c) et chaque gestionnaire de contrôle et d’affichage (202a, 202b) selon un protocole cœur commun ; - faire appel aux bibliothèques applicatives d’extension (203a, 203b, 203c) pour obtenir une implémentation du protocole cœur commun dédiée à chaque application aéronautique (201a, 201b, 201c), ainsi qu’une définition de fenêtres d’affichage qui est dédiée à chaque application aéronautique (201a, 201b, 201c) et qui a une partie agnostique à toute technologie d’affichage et une autre partie propre à une technologie d’affichage ; et - faire appel à ladite au moins une bibliothèque d’extension d’utilitaires de commande et d’affichage (204) pour obtenir une implémentation du protocole cœur commun dédiée aux gestionnaires de contrôle et d’affichage (202a, 202b). Produit programme d’ordinateur comportant des instructions implémentant le procédé selon la revendication 6 lorsque les instructions sont exécutées par un processeur. Support de stockage d’informations stockant un produit programme d’ordinateur selon la revendication 7.