FR2983600A1 - Procede et systeme de surveillance d'une interface graphique dans un cockpit d'aeronef - Google Patents

Abstract

L'invention a notamment pour objet un procédé et un système de surveillance d'une interface graphique dans un système informatique d'un cockpit d'aéronef. Le procédé comprend, outre l'affichage (520) d'une interface graphique d'une application cliente (110) à partir d'une arborescence d'objets graphiques d'interaction composant ladite interface graphique, les étapes suivantes : - obtenir (500) une pluralité d'objets graphiques d'interaction organisés de façon arborescente; - créer et ajouter (514), à ladite arborescence obtenue, au moins un nouvel objet graphique d'interaction (Wy, Wz) définissant une zone graphique d'affichage, dite critique (SC); - modifier (516) la dépendance arborescente d'au moins un objet graphique (Wi, Wj) d'interaction de l'arborescence obtenue, dit critique, pour le rendre dépendant du nouvel objet graphique d'interaction (Wy, Wz) définissant la zone critique; et - opérer (530) une surveillance, dite critique, des seuls objets graphiques critiques rattachés à la zone critique.

Description

La présente invention concerne les interfaces graphiques pour interagir avec des applications clientes dans les systèmes informatiques et plus particulièrement un procédé et un système de surveillance d'une interface graphique dans un système informatique d'un cockpit d'aéronef. Les systèmes d'affichage avionique, aussi appelé CDS (sigle de Control and Display System en terminologie anglo-saxonne) ont beaucoup évolué dans leurs fonctionnalités au cours des dernières années. Alors qu'à l'origine ils consistaient en de simples systèmes de visualisation (fonction d'affichage), ils permettent aujourd'hui une interactivité avec l'équipage en permettant, notamment, à des membres d'équipage d'effectuer des opérations définies dans des applications clientes, c'est-à- dire de contrôler ces dernières, à travers des moyens de saisie et de sélection tels qu'un clavier et un dispositif de pointage de type trackball. La figure 1 illustre schématiquement l'architecture d'une configuration matérielle de contrôle et d'affichage dans un cockpit d'aéronef. Comme illustré, la configuration matérielle 100 comprend au moins un calculateur 105 hébergeant un serveur de gestion d'affichage d'objets graphiques (CDS) relié, via un réseau de communication tel que Ethernet ou ARINC 429, à un système avionique 110 comprenant des applications avioniques dites clientes, au moins un écran 115, par exemple un écran LCD (sigle de Liquid Crystal Display en terminologie anglo-saxonne), et, notamment si cet écran n'est pas sensitif, des moyens de saisie et de sélection 120, aussi appelés KCCU (sigle de Keyboard and Cursor Control Unit en terminologie anglo-saxonne). Les moyens de saisie et de sélection 120 sont, par exemple, connectés au CDS 105 via un réseau privé 125 qui peut être de type CAN (sigle de Controller Area Network en terminologie anglo-saxonne). Le serveur de gestion d'affichage d'objets graphiques comporte un 30 gestionnaire d'événements 106 des périphériques d'entrée et un gestionnaire d'affichage 107 pour gérer l'affichage des interfaces graphiques en fonction d'instructions des applications clientes et des interactions avec l'équipage, par exemple le pilote. L'interface graphique ou « interface homme-machine » d'une application cliente peut notamment être définie par une arborescence d'objets graphiques 35 élémentaires d'interaction (boutons, champs de saisie, menus, etc.), également connus sous l'appellation « widgets » en langue anglo-saxonne, eux-mêmes définis au sein d'une bibliothèque locale d'objets graphiques élémentaires 108. Cette arborescence organise les objets graphiques de façon hiérarchique depuis un objet racine, appelé « calque » (ou « layer »), définissant la surface d'affichage dédiée à l'application cliente pour le tracé de son interface homme-machine, jusqu'aux objets graphiques à afficher au tout premier plan. Chaque widget obtient du gestionnaire d'affichage 107 une surface de dessin sur laquelle il peut se dessiner, constituant ainsi l'interface homme-machine de l'application cliente. Les widgets peuvent être interactifs, c'est-à-dire qu'ils peuvent accepter et réagir à des actions de l'équipage. ARINC 661 est une norme qui spécifie l'interface entre le CDS 105 et le système avionique 110. Selon ARINC 661, chaque interface graphique du cockpit est instancié à partir d'un fichier binaire nommé DF (definition file ou fichier de définition) définissant la structure de l'arborescence des widgets qui composent les écrans. La figure 2 illustre un premier exemple d'arborescence de widgets selon ARINC 661. Le système avionique 110 exécute, par exemple, des applications telles que des applications de gestion de vol dont des paramètres peuvent être affichés et/ou modifiés par les membres d'équipage, comme montré sur la figure. La figure 3 représente un exemple d'arborescence de widgets pour le panneau de commande (interface graphique) d'un système électronique d'instruments de vol (EFIS pour « Electronic Flight Instrument System ») représenté sur la figure 1. Un tel panneau de commande permet de piloter un certain nombre de paramètres pour les afficheurs EFIS. Les paramètres peuvent ainsi être transmis du système avionique au CDS 105, en charge de les afficher sur l'écran 115. Si le pilote veut modifier une valeur ou actionner un élément, il interagit, via les moyens de saisie et de sélection 120, sur l'interface graphique affichée (sur les widgets affichés) pour le ou la sélectionner et, le cas échéant, la modifier. Une commande d'interaction Cl est alors transmise par les moyens de saisie et de sélection 120 au gestionnaire d'événements 106 du CDS 105 pour effectuer cette sélection et/ou modification. La valeur modifiée est alors transmise (message « événement ») par le CDS au système avionique qui peut alors l'utiliser. En même temps l'affichage de l'élément peut être mis à jour par la génération d'une instruction d'affichage à partir de la commande d'interaction Cl. L'utilisation de la valeur modifiée par une application cliente du système avionique 110 peut conduire à une modification de l'affichage sur l'interface graphique.

Un message ou commande de mise à jour CM peut ainsi être transmis à nouveau au CDS 105 pour mettre à jour l'affichage sur l'écran 115 avec de nouveaux paramètres ("set_parameters"). Cette commande CM identifie notamment le widget à mettre à jour par un identifiant unique de celui-ci, et permet la génération d'instructions d'affichage correspondantes. Ainsi, le CDS peut être considéré comme une ressource d'affichage de données en provenance de l'avionique. Le CDS et l'avionique s'échangent des informations pour mettre à jour des éléments affichés et notifier des événements aux membres d'équipage. ARINC 661 définit également un protocole de communication entre le système avionique 110 et le CDS 105, permettant au système avionique d'envoyer ces modifications CM de widgets au CDS, et au CDS de renvoyer les évènements utilisateur Cl au système avionique. Certaines actions sur les interfaces graphiques de contrôle peuvent avoir des conséquences sur l'intégrité de l'aéronef ou de ses passagers si elles sont effectuées en dehors de leur cadre d'utilisation ou si elles s'avèrent être défaillantes. Le tableau ci-dessous illustre certaines défaillances redoutées : contrôles erroné et intempestif, ainsi que affichages erroné et intempestif. Catégories de flux Les défaillances redoutées Flux de contrôle Un contrôle erroné, c'est-à-dire la transmission d'un contrôle erroné à l'application cliente suite à une action de l'opérateur sur les moyens de saisie et de sélection 120. (du CDS 105 vers l'avionique 110). Un contrôle intempestif, c'est-à-dire la transmission d'un contrôle à l'application cliente sans action de l'utilisateur sur les moyens de saisie et de sélection 120. Flux d'affichage Un affichage erroné, c'est-à-dire l'affichage erroné d'une (de l'avionique 110 information transmise par les applications clientes sur les périphériques de sorties (écrans). vers le CDS 105). Un affichage intempestif, c'est-à-dire la mise à jour et l'affichage d'un paramètre sur les périphériques de sorties (écrans) par le CDS alors qu'aucune commande n'a été reçue de l'application cliente. Tableau 1 Etablir une surveillance sur l'ensemble des fonctions, c'est-à-dire des widgets, d'une application cliente peut s'avérer difficile, notamment du fait de besoins élevés en ressources de traitement. En effet, le nombre de widgets peut s'avérer être important selon les applications, alors que le nombre de widgets susceptible d'avoir un impact sur l'intégrité de l'aéronef et de ses passagers est relativement faible. Par exemple, pour une interface graphique de système de gestion de vol (FMS pour « Flight Management System »), moins de 10 widgets s'avèrent critiques sur les 3500 widgets constitutifs de cette interface. De même, pour un panneau plafond, moins de 20 widgets sont critiques sur un total de 400 widgets constitutifs de l'interface graphique. En outre, des interactions existent entre les widgets, typiquement, un widget parent envers l'état de ses widgets fils, de telle sorte que, la surveillance du flux de commande provenant de l'application cliente s'avère beaucoup plus complexe que la simple surveillance de chaque widget pris indépendamment. La figure 4 illustre cette influence dans un exemple où l'état du widget enfant W3 dépend des commandes 1 et 2 reçues par ses widgets parents W1 et W2. La surveillance du widget W3 nécessiterait par conséquent celle des widgets W1 et W2. Cette dépendance requiert donc généralement une surveillance de l'ensemble des widgets. De plus, le protocole d'échange des flux de commande selon ARINC 661 peut ne pas définir d'ordonnancement des commandes les unes par rapport aux autres, alors que plusieurs commandes peuvent venir modifier l'état d'un même paramètre de widget (en outre éventuellement de façon différente selon l'état du widget). Pour faire face à cette complexité de surveillance, les systèmes d'affichage et de contrôle des cockpits utilisés ces dernières décennies ont limité l'interactivité utilisateur à des fonctions ou widgets dits non critiques ayant pour pire conséquence une augmentation de la charge de travail des pilotes, sans impact sur l'intégrité de l'aéronef et de ses passagers. Cette limitation résulte de la délimitation, sur les écrans ou interfaces graphiques, de zones d'interaction aux seules zones correspondant à des fonctions non critiques. En d'autres termes, l'interface graphique est hétérogène en ce qu'elle présente à la fois des zones accessibles par les moyens de saisie et de sélection 120 (les widgets non critiques) et d'autres où l'utilisation de ces moyens 120 est interdite (les widgets critiques). Pourtant aujourd'hui, il est un objectif d'étendre cette interactivité aux fonctions et widgets critiques.

Quelques solutions ont pu être proposées, comme par exemple la mise en place de requêtes de confirmation de message comme décrite dans la publication FR 2 931 329. Cette proposition est toutefois peu pratique car fortement dépendante de l'architecture matérielle et logicielle du CDS et limitée uniquement à certaines commandes prédéfinies. La présente invention permet de pallier au moins un des inconvénients exposés précédemment. Elle a notamment pour objet un procédé et un système de surveillance d'une interface graphique dans un système informatique d'un cockpit d'aéronef. L'invention vise en particulier la surveillance d'interfaces graphiques affichées pour l'interaction (via un écran tactile ou un simple écran combiné à des moyens de saisie et de sélection de type clavier et souris) avec une application cliente et définie par une arborescence d'objets graphiques élémentaires d'interaction ou « widgets ». L'invention a ainsi pour objet un procédé de surveillance d'une interface graphique dans un système informatique d'un cockpit d'aéronef, comprenant l'affichage d'une interface graphique d'une application cliente à partir d'une arborescence d'objets graphiques d'interaction composant ladite interface graphique, ce procédé étant caractérisé en ce qu'il comprend les étapes suivantes : - obtenir une pluralité d'objets graphiques d'interaction organisés de façon arborescente; - créer et ajouter, à ladite arborescence obtenue, au moins un nouvel objet graphique d'interaction définissant une zone graphique d'affichage, dite critique; - modifier la dépendance arborescente d'au moins un objet graphique d'interaction de l'arborescence obtenue, dit critique, pour le rendre dépendant du nouvel objet graphique d'interaction définissant la zone critique; et - opérer une surveillance, dite critique, des seuls objets graphiques critiques rattachés à la zone critique. Le procédé selon l'invention permet ainsi d'optimiser les objets graphiques (widgets) critiques à surveiller grâce à la création d'une zone critique à laquelle ceux-ci sont directement rattachés. Ainsi, le périmètre de surveillance critique est limité à cette zone, peu important les commandes reçues pour les autres objets graphiques (c'est-à-dire les objets non critiques). On notera que la décision quant à savoir si un objet graphique est critique ou non pour l'inclure dans cette zone critique peut être réalisée de façon manuelle au préalable par un utilisateur formé à cet égard, par exemple un responsable sûreté, selon notamment les interdépendances entre objets telles que décrites précédemment. En outre, la surveillance critique est rendue indépendante de l'architecture initiale de l'interface graphique puisque l'arborescence est ajustée selon la criticité des objets graphiques. L'obtention d'une surveillance efficace des objets graphiques (fonctions) critiques selon l'invention permet ainsi de rendre les interfaces graphiques d'interaction tolérantes aux éventuelles fautes du CDS ou du système avionique hébergeant les applications clientes.

Un tel procédé est générique, et peut être mis en oeuvre pour surveiller les interfaces graphiques de tout système d'aéronef. On notera que les autres objets de l'arborescence peuvent également être soumis à une surveillance (non critique) de degré moindre que la surveillance dite critique (c'est-à-dire nécessitant moins de ressources par exemple), même si de préférence ils ne seront soumis à aucune surveillance. De façon avantageuse, le nouvel objet graphique d'interaction définissant la zone critique est rattaché directement à la racine de l'arborescence. On isole ainsi totalement les objets graphiques critiques soumis à surveillance des autres objets non critiques. La conduite de la surveillance s'en trouve alors simplifiée.

Par ailleurs, ledit nouvel objet graphique d'interaction créé définit, de préférence, une zone graphique critique correspondant à une surface d'affichage distincte des surfaces d'affichage des objets graphiques non critiques. Cette ségrégation dans l'affichage permet de simplifier les traitements de commandes d'interaction d'un utilisateur sur l'affichage, via les moyens de saisie et de sélection.

Selon une caractéristique particulière, ledit nouvel objet graphique d'interaction créé comprend, de préférence, un objet Panel de la norme ARINC 661 auquel sont rattachés lesdits objets graphiques critiques. Cet objet « Panel » présente en effet l'avantage de définir une zone rectangulaire d'affichage au sein de laquelle d'autres objets, en l'espèce les objets graphiques critiques, peuvent être dessinés. On notera d'ailleurs que la propriété « Parentldent » de cet objet peut être mise à 0 afin de rattacher cet objet Panel directement à la racine de l'arborescence comme évoqué précédemment. Selon un mode de réalisation de l'invention, le procédé comprend en outre une étape de tri, parmi des commandes reçues à destination des objets graphiques d'interaction de l'arborescence, entre les commandes, dites critiques, à destination des objets graphiques critiques et les commandes à destination des autres objets graphiques, dits non critiques; et la surveillance critique s'opère sur les commandes critiques uniquement. Cette ségrégation préalable des commandes reçues permet de réduire les ressources nécessaires à ladite surveillance critique selon l'invention.

Les commandes d'interaction d'un utilisateur peuvent par exemple être identifiées à partir du positionnement d'un pointeur (souris, écran tactile) relativement à une surface d'affichage de ladite zone critique ou de l'objet graphique actif (par exemple en état d'édition) lors d'une saisie sur un clavier. Les commandes issues de l'application cliente avec laquelle un utilisateur interagit (via l'interface graphique affichée) peuvent être triées aisément en fonction par exemple d'un identifiant d'objet graphique qu'elles contiennent. Selon un mode de réalisation particulier de l'invention, la surveillance critique d'un objet graphique critique comprend, pour une commande reçue à destination de cet objet graphique critique, la comparaison entre un message de sortie de l'objet graphique critique en réponse à la commande reçue et un message théorique de sortie déterminé par un module de surveillance à partir de la commande reçue, et comprend la génération d'un message d'erreur en cas de comparaison négative. Selon une caractéristique particulière, un objet graphique critique est un objet informatique comprenant, outre un bloc fonctionnel correspondant à la fonction propre de l'objet graphique critique, un bloc de contrôle pour effectuer ladite comparaison. Ce bloc de contrôle est par conséquent un élément constitutif du module de surveillance. Selon cette configuration les objets critiques sont ainsi autonomes dans leur contrôle.

En particulier, le bloc de contrôle d'un objet graphique critique comprend un bloc fonctionnel simplifié pour réaliser une fonction simplifiée de ladite fonction de l'objet graphique critique, et un comparateur pour comparer une sortie du bloc fonctionnel simplifié avec une sortie correspondante du bloc fonctionnel. Cette disposition permet d'aboutir à un contrôle à coût réduit. En effet, en faisant appel à une simplification de la fonction de l'objet, les ressources nécessaires à son contrôle sont réduites. Notamment, la fonction simplifiée peut se cantonner aux propriétés que l'on souhaite garantir, et passer outre les propriétés d'intérêt moindre (par exemple le rendu graphique, tel que la mise en « focus » de l'objet lorsque le pointeur de souris le survole).

Selon un mode de réalisation de l'invention, le procédé comprend en outre une étape d'identification, à partir d'un fichier de configuration, des objets graphiques critiques rendus ou à rendre dépendants du nouvel objet graphique parmi les objets graphiques de l'arborescence. Ce fichier de configuration peut notamment être annexé au fichier DF cité précédemment. En variante, le procédé comprend en outre une étape d'identification, à partir d'une plage d'identifiants réservée aux objets graphiques critiques, des objets graphiques critiques rendus ou à rendre dépendants du nouvel objet graphique parmi les objets graphiques de l'arborescence. Cette disposition est aisée à mettre en oeuvre et requiert peu de ressources pour identifier les objets graphiques critiques. L'identification des objets graphiques critiques est utile lors du rattachement de ceux-ci au nouvel objet graphique créé, mais également pour trier les commandes reçues de sorte à traiter uniquement celles à destination des objets critiques sujets à surveillance.

Selon un mode de réalisation de l'invention, l'affichage de l'interface graphique d'interaction à partir de l'arborescence comprend une première étape d'exécution des instructions d'affichage relatives aux objets graphiques non critiques, suivie d'une deuxième étape d'exécution des instructions d'affichage relatives aux objets graphiques critiques. Ici l'ensemble des objets graphiques non critiques est affiché avant l'ensemble des objets graphiques critiques. L'affichage est ainsi séquentiel, permettant d'assurer qu'aucun objet non critique ne sera affiché par dessus la zone d'affichage critique. Cette disposition contribue à simplifier les traitements de ségrégation des commandes d'interaction déclenchées par un utilisateur. En variante, le procédé comprend en outre les étapes consistant à : - détecter lorsqu'au moins un objet graphique non critique est affiché en superposition (c'est-à-dire au dessus) au moins partielle de la zone graphique critique comprenant les objets graphiques critiques; et - inhiber, pendant la durée de la superposition, des fonctions d'interaction d'un utilisateur avec les objets graphiques critiques.

Cette disposition offre un haut degré de sécurisation des fonctions critiques. En effet, des modules de surveillance qui opèrent uniquement sur les objets graphiques critiques peuvent ne pas avoir connaissance de la présence et du type d'objets non critiques en superposition. Il existerait donc un risque qu'une information traitée par ces modules soit polluée par la présence d'un objet non critique. La présente disposition évite ainsi une telle situation en inhibant les interactions. La surveillance des objets graphiques critiques peut ainsi également être inhibée. En particulier, le procédé comprend en outre une étape de déclenchement d'un compte à rebours à détection de la superposition, et une étape de génération d'un message d'alerte à l'expiration du compte à rebours. Ainsi, l'utilisateur peut être aisément averti pour déplacer l'objet graphique non critique en superposition et ainsi retrouver l'ensemble des fonctions critiques. La mise en oeuvre du compte à rebours permet de limiter dans le temps l'impossibilité d'accès à une fonction dite critique, alors que dans un aéronef il est préconisé d'avoir accès à l'ensemble des fonctions si nécessaire. Le compte à rebours peut être de l'ordre de quelques secondes. Selon une autre caractéristique particulière, la détection de la superposition comprend une étape de mise à jour d'un tableau de profondeurs lors d'une mise à jour (notamment l'affichage initial) de l'affichage de l'interface graphique, ledit tableau de profondeurs mémorisant pour chaque pixel d'affichage la profondeur de l'objet graphique le moins profond situé au niveau de ce pixel, et comprend une étape de détermination d'un pixel qui appartient à ladite zone graphique critique et, à la fois, dont la profondeur mémorisée dans le tableau correspond à un objet graphique non critique. L'invention a également pour objet un programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé décrit précédemment lorsque ledit programme est exécuté sur un ordinateur, un système 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 un tel dispositif. Les avantages procurés par ce programme d'ordinateur, ce système et cet aéronef sont similaires à ceux évoqués précédemment. En particulier, l'invention concerne également un système de surveillance d'une interface graphique dans un système informatique d'un cockpit d'aéronef, comprenant un module d'affichage pour commander l'affichage d'une interface graphique d'une application cliente à partir d'une arborescence d'objets graphiques d'interaction composant ladite interface graphique, ce système étant caractérisé en ce qu'il comprend : - un moyen pour obtenir une pluralité d'objets graphiques d'interaction organisés de façon arborescente; - un module de définition d'une zone graphique critique à surveiller pour créer et ajouter, à ladite arborescence obtenue, au moins un nouvel objet graphique d'interaction définissant une zone graphique d'affichage, dite critique, et pour modifier la dépendance arborescente d'au moins un objet graphique d'interaction de l'arborescence obtenue, dit critique, de sorte à le rendre dépendant du nouvel objet graphique d'interaction définissant la zone critique; et - un module de surveillance des objets graphiques critiques pour opérer une surveillance, dite critique, des seuls objets graphiques élémentaires critiques rattachés à la zone critique. De façon avantageuse, le module de définition est agencé pour rattacher directement le nouvel objet graphique d'interaction définissant la zone critique à la racine de l'arborescence. Par ailleurs, le module de définition est agencé pour définir, par ledit nouvel objet graphique d'interaction créé, une zone graphique critique correspondant à une surface d'affichage distincte des surfaces d'affichage des objets graphiques non critiques.

Selon une caractéristique particulière, ledit nouvel objet graphique d'interaction créé comprend, de préférence, un objet Panel de la norme ARINC 661 auquel sont rattachés lesdits objets graphiques critiques. Selon un mode de réalisation de l'invention, le système comprend en outre un module de tri de commandes pour trier, parmi des commandes reçues à destination des objets graphiques d'interaction de l'arborescence, entre les commandes, dites critiques, à destination des objets graphiques critiques et les commandes à destination des objets graphiques, dits non critiques; et le module de surveillance opère sur les commandes critiques uniquement. Selon un mode de réalisation particulier de l'invention, le module de surveillance comprend : - un module de détermination théorique pour déterminer, à partir d'une commande reçue à destination d'un objet graphique critique, un message théorique de sortie dudit objet graphique critique; - un comparateur pour comparer, pour cette commande reçue, un message de sortie de l'objet graphique critique en réponse à la commande reçue et ledit message théorique de sortie; et - un module de génération d'un message d'erreur en cas de comparaison négative.

Selon une caractéristique particulière, un objet graphique critique est un objet informatique comprenant, outre un bloc fonctionnel correspondant à la fonction propre de l'objet graphique, un bloc de contrôle pour effectuer ladite comparaison. En particulier, le bloc de contrôle d'un objet graphique critique inclut un module propre de détermination théorique pour réaliser une fonction simplifiée de ladite fonction de l'objet graphique critique, et un comparateur propre pour comparer le message théorique de sortie du module de détermination théorique avec une sortie correspondante du bloc fonctionnel. Selon un mode de réalisation de l'invention, le module d'affichage de l'interface graphique d'interaction à partir de l'arborescence est configuré pour commander d'abord l'exécution des instructions d'affichage relatives aux objets graphiques non critiques, puis l'exécution des instructions d'affichage relatives aux objets graphiques critiques. En variante, le système comprend en outre : - un module de détection pour détecter un objet graphique non critique affiché en superposition au moins partielle de la zone graphique critique comprenant les objets graphiques critiques; et - un module d'inhibition pour inhiber, pendant la durée de la superposition, des fonctions d'interaction d'un utilisateur avec les objets graphiques critiques.

En particulier, le module d'inhibition est configuré pour déclencher un compte à rebours à détection de la superposition, et générer un message d'alerte à l'expiration du compte à rebours. Selon une autre caractéristique particulière, le module de détection détecte la superposition d'objets à partir d'un tableau de profondeurs mémorisant pour chaque pixel d'affichage la profondeur de l'objet graphique le moins profond situé au niveau de ce pixel. 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 illustre schématiquement l'architecture d'une configuration matérielle de contrôle et d'affichage dans un cockpit d'aéronef ; - la figure 2 illustre un exemple d'arborescence de widgets selon la norme ARINC 661 ; - la figure 3 illustre un autre exemple d'arborescence de widgets correspondant à l'interface graphique représentée figure 1 ; - la figure 4 illustre l'influence entre widgets d'une arborescence de widgets, consécutivement à la réception de commandes ; - la figure 5 représente, sous forme de logigramme, des étapes générales d'un mode de réalisation de l'invention ; - la figure 6 illustre schématiquement la création d'une zone graphique critique selon l'invention au sein d'une arborescence de widgets ; - la figure 7 illustre, sous forme d'un diagramme fonctionnel, un CDS incorporant des fonctions selon l'invention ; - la figure 8 représente un panneau de commande d'EFIS incluant des widgets critiques ; - la figure 9 représente un exemple d'arborescence de widgets selon l'invention pour l'interface EFIS de la figure 8 ; - la figure 10 illustre la ségrégation de commandes à l'aide d'un lien virtuelle, selon un mode de réalisation de l'invention ; - la figure 11 illustre la ségrégation de commandes par filtrage, selon un mode de réalisation de l'invention ; - la figure 12 illustre la ségrégation d'affichage de widgets par affichage séquentiel de ceux-ci, selon un mode de réalisation de l'invention ; - la figure 13 illustre des mécanismes de gestion de l'affichage concurrentiel entre des widgets critiques et des widgets non critiques selon l'invention, en l'absence de superposition (13a) et en cas de superposition (13b) ; - la figure 14 illustre un exemple de compromission d'une interface graphique de PFD (pour "Primary Flight Display') dessinée à partir de widgets de primitives graphiques ; - la figure 15 illustre la notion de widget autotestable selon l'invention ; - la figure 16 illustre la surveillance, par un widget autotestable, d'un flux de commandes émis par une application cliente, selon l'invention ; - la figure 17 illustre la surveillance, par un widget autotestable, d'un flux de commandes d'interaction utilisateur, selon l'invention ; - la figure 18 illustre un cas particulier de widget autotestable selon l'invention, dérivant du widget "PushButton" d'ARINC 661 ; - la figure 19 illustre la structure de comparaison au sein du widget autotestable de la figure 18 ; et - la figure 20 illustre un exemple d'architecture matérielle adaptée à mettre en oeuvre certaines étapes de l'invention, en particulier de surveillance de widgets critiques. Pour surveiller de façon efficace les objets graphiques d'interaction, ou "widgets", d'une interface graphique affichée à partir d'une arborescence de ces objets graphiques, l'invention met en oeuvre une ségrégation de l'ensemble des objets graphiques dits critiques (ceux à surveiller) dans l'ensemble des objets graphiques, à l'aide d'un nouvel objet graphique introduit dans cette arborescence. Ce nouvel objet graphique a pour objet de définir une zone graphique critique qui seule sera à surveiller. Ainsi les seuls objets graphiques critiques qui seront rattachés à ce nouvel objet graphique peuvent être surveillés, évitant de la sorte de tenir compte des autres objets graphiques dits non critiques. L'invention minimise par ailleurs les contraintes sur l'application cliente, comme il sera vu par la suite.

Un système de surveillance, incluant notamment un logiciel de surveillance, dans le CDS 105 met en oeuvre le procédé de surveillance selon l'invention tel que décrit par la suite. Comme illustré sur la figure 5, un procédé de surveillance d'une application cliente selon l'invention comprend une étape 500 d'obtention d'une pluralité d'objets graphiques d'interaction organisés de façon arborescente. Il s'agit notamment de l'arbre de widgets définissant l'interface homme-machine de l'application cliente en question. Par exemple, l'étape 500 consiste à récupérer le fichier binaire DF de l'application cliente.

Le procédé de surveillance selon l'invention se poursuit à l'étape 510 par la mise en place d'une zone graphique critique de surveillance. Pour ce faire, le système de surveillance détermine (étape 512) l'existence d'objets graphiques critiques au sein de l'arborescence obtenue, et obtient une identification de ceux-ci, le cas échéant.

Ces objets graphiques critiques peuvent avoir été définis au préalable, par exemple au travers d'un fichier de configuration des widgets critiques, listant les identifiants d'objets à considérer comme critiques. L'établissement de ce fichier de configuration peut être réalisé manuellement par un opérateur selon des considérations de criticité des fonctions associées aux objets graphiques et d'interdépendance entre les objets graphiques comme illustré par la figure 4 ci-dessus. A titre d'exemple, ce fichier de configuration peut être annexé au fichier de définition DF de l'arborescence.

Dans une variante s'appuyant sur la mise en oeuvre de widgets autotestables tels que décrits par la suite, seuls les objets graphiques dotés d'un bloc interne de contrôle et présents dans l'arborescence obtenue sont identifiés comme objets graphiques critiques. On rappelle ici que la définition de chaque objet graphique est stockée dans la bibliothèque 108 des widgets. Ainsi, le système de surveillance déterminera, pour chaque objet graphique listé dans le fichier DF, si celui-ci est de type autotestable par sondage de la bibliothèque 108, auquel cas cet objet sera considéré comme critique. Une fois déterminé qu'il existe des objets critiques, le système de surveillance crée une zone graphique d'affichage critique à l'étape 514. Bien entendu, plusieurs zones graphiques critiques peuvent être créées, dans le cas par exemple où plusieurs groupes d'objets graphiques critiques peuvent être déterminés à l'étape 512. Parmi les objets graphiques disponibles dans la bibliothèque 108, le système de surveillance recherche un objet graphique permettant de définir une surface d'affichage et ayant la capacité d'être le parent d'autres objets graphiques. En effet, comme décrit par la suite, les objets graphiques critiques seront rattachés à ce nouvel objet graphique définissant la zone graphique critique. Par ce nouvel objet graphique, on définit ainsi une surface d'affichage qui peut aisément être isolée du reste de l'affichage (c'est-à-dire de l'affichage des objets graphiques non critiques).

Ce nouvel objet graphique créé est alors ajouté à l'arborescence obtenue à l'étape 500, définissant ainsi concrètement une nouvelle surface d'affichage critique dans l'interface homme-machine de l'application cliente. En particulier, pour ségréguer au maximum cette nouvelle surface critique du reste des objets graphiques non critiques, le nouvel objet graphique créé est rattaché directement à la racine de l'arborescence. Puis à l'étape 516, le système de surveillance modifie la dépendance arborescente des objets graphiques d'interaction critiques pour les rendre dépendants du nouvel objet graphique créé et définissant la zone critique. En effet, le nouvel objet graphique créé pouvant être un parent, on peut lui rattacher un certain nombre d'objets graphiques fils, les objets critiques, sur lesquelles il est nécessaire d'effectuer la surveillance. La figure 6 illustre cette étape 510 de mise en place d'une zone graphique critique de surveillance. L'étape 512 permet par exemple d'identifier, dans l'arborescence obtenue (haut de la figure) les widgets Wi et Wj comme critiques. L'étape 514 crée alors deux nouveaux widgets Wy et Wz pour définir deux nouvelles zones d'affichage critiques. Ces deux nouveaux widgets sont directement rattachés à la racine WO de l'arbre. Enfin, à l'étape 516, les deux widgets critiques Wi et Wj sont rattachés aux deux nouveaux widgets créés, respectivement Wy et Wz, de sorte à inclure les widgets critiques Wi et Wj dans les deux nouvelles zones d'affichage critiques. En variante, un seul widget Wy pourrait être prévu pour recevoir Wi et Wj. Cette méthode est simple à mettre en oeuvre et impose peu de contraintes vis à vis de l'application cliente (par exemple nécessité de gérer les widgets critiques de manière indépendante du reste de la page, comme illustré dans le cas de la figure 10 décrit ci-après). De retour à la figure 5, le CDS 105 dessine et affiche sur l'écran 115 l'interface IHM de l'application cliente à partir de l'arborescence modifiée obtenue à l'issue de l'étape 516 (étape 520). Cette opération classique consiste à instancier, à partir de la bibliothèque 108, chaque objet graphique du fichier DF en tenant compte des nouveaux objets graphiques créés à l'étape 514 et des nouvelles dépendances résultant de l'étape 516. De préférence, lors de l'instanciation, les objets graphiques critiques (donc ceux rendus dépendants des nouvelles zones graphiques critiques créées) sont associés à des identifiants uniques appartenant à une plage réservée de valeurs d'identifiants. Cela permettra d'identifier aisément des commandes à destination de ces objets graphiques et donc les commandes à surveiller. Une fois l'interface graphique IHM affichée, le système de surveillance opère une surveillance dite critique de cette interface graphique (étape 530). En particulier, seuls les objets graphiques critiques rattachés à la zone critique (ou aux zones critiques) sont surveillés. Bien entendu, la présente invention peut s'appliquer au cas où deux niveaux (voire plus) de surveillance sont mis en oeuvre. La surveillance la plus contraignante (c'est-à-dire critique) est mise en oeuvre selon les mécanismes de l'invention, les autres niveaux de surveillance étant alors appliqués aux objets graphiques non critiques au sens de l'invention.

L'étape 530 comprend deux étapes: l'une, 532, pour ségréguer les commandes en entrée (Cl, CM) et en sortie (instructions d'affichage par exemple) afin d'identifier celles à destination ou concernent des objets graphiques critiques et donc à surveiller, et l'autre, 534, pour assurer la surveillance effective du périmètre de surveillance, c'est-à-dire des zones graphiques critiques. L'étape 532 de ségrégation des commandes consiste en partie à trier, parmi des commandes reçues à destination des objets graphiques d'interaction de l'arborescence, entre les commandes, dites critiques, à destination des objets graphiques critiques et les commandes à destination des autres objets graphiques, dits non critiques. Ainsi, la surveillance selon l'invention va s'opérer sur les commandes critiques uniquement. En effet, toutes les commandes CM reçues de l'application cliente ou commandes d'interaction Cl à destination de la zone critique (c'est-à-dire des objets graphiques critiques) doivent être ségréguées du reste. Le système de surveillance dans le serveur CDS 105 est configuré pour extraire, parmi le flux de commandes reçues, toutes les commandes qui modifient l'état d'un des objets graphiques critiques de la zone d'affichage critique. En ce qui concerne les commandes d'interaction Cl par exemple, puisque la zone d'affichage critique est définie par un objet graphique ayant lui-même une surface définie, l'identification des commandes Cl à destination de la zone critique peut simplement consister à identifier les interactions d'un moyen de sélection 120 (pointeur souris ou interacteur tactile) sur les objets critiques en réalisant un test d'inclusion de l'événement dans la surface définie, et/ou à identifier les saisies du clavier lorsque l'un des objets critiques est dans un état acceptant des évènements clavier par exemple lorsqu'il a le focus ou lorsqu'il est dans un état d'édition. En ce qui concerne les commandes de mise à jour CM envoyées par l'application cliente 110, le système de surveillance peut aisément identifier l'ensemble des commandes à surveiller du fait de la ségrégation des objets graphiques introduites par la création des nouveaux objets graphiques rattachés à la racine de l'arborescence. Ainsi, la simple identification des commandes à destination des objets graphiques critiques des zones critiques (à l'aide de leurs identifiants) est suffisante. Là où le nouvel objet graphique d'interaction créé définit une zone graphique critique correspondant à une surface d'affichage distincte des surfaces d'affichage des objets graphiques non critiques, la gestion de l'affichage des objets critiques ne pose a priori aucune difficulté. En revanche, lorsque ces différentes surface et zones peuvent se chevaucher, c'est-à-dire se superposer au moins partiellement, il conviendra de vérifier que l'affichage des objets graphiques critiques n'est pas perturbé par l'affichage des widgets non critiques. Des mécanismes adaptés sont notamment proposés dans la description qui suit.

L'étape 534 de surveillance effective des zones graphiques critiques telles que créées à l'étape 510 a pour objet de s'assurer que le flux de sortie de chaque objet graphique critique, donc surveillé, est conforme à l'ensemble des commandes CM reçues par l'application cliente et d'interaction Cl de l'utilisateur à destination de ces objets graphiques critiques. La sortie d'un objet graphique est soit un événement envoyé à l'application cliente généralement en réponse à une interaction de l'utilisateur, soit un affichage modifié en réponse à une commande de mise à jour émise par l'application cliente (c'est-à-dire une instruction d'affichage). Pour réaliser cette opération de surveillance, le système de surveillance peut notamment mémoriser en continu l'état de chaque objet graphique critique (c'est- à-dire l'état résultant des commandes CM et Cl précédentes), analyser l'impact d'une commande CM ou Cl reçue sur l'objet graphique surveillé concerné par cette commande, et enfin vérifier que la sortie de cet objet graphique (instruction graphique ou événement vers l'application cliente) est bien conforme à l'état courant de l'objet graphique.

La figure 7 illustre fonctionnellement une surveillance d'objets graphiques selon l'invention. Partant du fichier de définition de l'interface graphique IHM de l'application cliente, ce fichier ayant été modifié pour introduire les zones d'affichage critiques et pour y rattacher les objets critiques comme décrit précédemment, chaque objet graphique est instancié dans le serveur de gestion d'affichage. La ségrégation des zones critiques permet de distinguer un sous-arbre des objets graphiques non critiques et un sous-arbre des objets graphiques critiques à surveiller, ces sous-arbres étant rattachés à la même racine. L'affichage sur l'écran 115 est ainsi réalisé à partir de ces sous-arbres.

Comme illustré sur la figure, la zone graphique critique affichée peut être distincte (c'est-à-dire sans superposition ou chevauchement) de la ou les surfaces d'affichage des objets graphiques non critiques. Lors de la surveillance des objets critiques, les commandes CM et Cl reçues de l'application cliente 110 et des moyens de saisie et de sélection 120 sont séparées entre commandes dites critiques à destination des objets graphiques critiques et commandes dites non critiques à destination des objets graphiques non critiques. Toutes les commandes reçues sont envoyées à un module d'affichage pour commander la mise à jour de l'interface graphique ou l'envoi d'un événement en 5 fonction de ces commandes. En parallèle, seules les commandes critiques sont transmises au module (bloc fonctionnel) de surveillance qui procède à une évaluation de l'état de sortie des objets critiques concernés par ces commandes. Cet état de sortie évalué est alors comparé à l'état de sortie effectif de 10 l'objet critique correspondant. En cas de différence, un message d'alerte peut être émis à l'attention de l'utilisateur. On décrit maintenant en référence aux figures 8 à 19 notamment un mode de réalisation de l'invention pour l'interface IHM d'un système électronique d'instruments de vol (EFIS pour « Electronic Flight Instrument System ») représentée 15 sur l'écran de la figure 1, conforme à la norme ARINC 661. On a repris cette interface sur la figure 8 dans laquelle les références A à F, LS, W, TX et SC permettent de faire le lien avec la figure 9. Bien entendu, les mécanismes décrits ci-après pour cette interface peuvent être mis en oeuvre, en totalité ou en partie uniquement, pour d'autres interfaces IHM. 20 La norme ARINC 661 propose un ensemble de widgets qui peut être organisé sous forme d'arbre. La structure des calques (ou layers) dans lesquels les objets graphiques viennent s'afficher est définie de manière statique au travers d'un fichier de définition. Chaque calque est défini de façon indépendante. Chaque widget peut avoir un parent, définissant ainsi une arborescence depuis un widget racine de 25 calque. Les widgets de type « Container » permettent de regrouper un ensemble de widgets. Le widget « Panel » appartient à ce type de widgets. Le « Panel » est un widget qui regroupe plusieurs widgets au sein d'une zone rectangulaire sur laquelle un rognage peut être appliqué. Dans le tableau ci-dessous, on a représenté les propriétés du widget 30 « Panel » telles que définies dans la norme susvisée.

Paramètres Description Paramètres couramment utilisés WidgetType A661 PANEL Widgetldent Identifiant unique du widget Parentldent Identifiant du container direct du widget Visible Visibilité du widget Enable Habilité du widget à être activé StyleSet Référence à des caractéristiques graphiques prédéfinies dans le CDS MotionAllowed Capacité à pouvoir changer les paramètres PosX, PosY, SizeX, SizeY lors de la phase d'exécution PosX La position X du point de référence du widget PosY La position Y du point de référence du widget SizeX Largeur du widget SizeY Hauteur du widget Tableau 2 Le fichier de définition DF pour l'interface graphique de l'application EFIS est représenté sur la figure 3.

Pour construire une surface critique au sens de l'invention (l'étape 510), on utilise un widget « Panel » que l'on rattache directement à la racine (c'est-à-dire que la propriété « Parentldent » est mise à 0 pour le widget « Panel » créé). Le widget « Panel » est ainsi utilisé ici pour définir une surface sur laquelle ses widgets fils (les widgets critiques de l'invention) viendront se dessiner. Il constitue la surface critique sur laquelle la surveillance sera appliquée. Les widgets critiques que l'on souhaite sécuriser sont rattachés à ce widget « Panel », par exemple en indiquant dans une propriété de ces widgets critiques (« Parentldent ») l'identifiant unique du widget « Panel » en question. Bien entendu, si un sous-arbre entier s'avère composé uniquement de widgets critiques, seul le widget de profondeur la plus basse (le widget critique parent commun à tous dans l'arbre) est rattaché au widget « Panel ». Par transitivité, ses widgets critiques enfants seront également rattachés à la zone critique définie par ce widget « Panel ». Une fois la surface critique créée, il est nécessaire d'indiquer au gestionnaire de surveillance que la surface définie par ce widget « Panel » est critique et qu'il doit y appliquer une surveillance.

Cette indication peut être réalisée au travers d'une identification statique de la surface critique ou des widgets critiques, par exemple : - soit en adjoignant au fichier de définition DF un fichier de configuration qui contient l'ensemble des widgets critiques ; - soit en définissant une plage d'identifiants réservée aux widgets critiques et à la surface critique. Cette solution présente l'avantage d'éviter le développement d'un format de fichier supplémentaire, d'éviter le téléchargement et la gestion de configuration de ce fichier supplémentaire. La plage des identifiants étant de 0-65535 par calque (layer), il est facile de réserver une grande plage pour les widgets critiques sans pénaliser la conception du reste de l'IHM. Pour simplifier les explications suivantes, considérons, dans l'exemple de l'EFIS, que seul l'affichage du calage barométrique est critique (un mauvais calage induit l'affichage d'une altitude erronée). Bien entendu, les explications ci-dessous pourront s'appliquer de façon identique pour un plus grand nombre de fonctions ou widgets critiques. On a indiqué sur la figure 8, par la référence SC, l'affichage des widgets correspondant au calage barométrique : un widget label indiquant « QNH » et un widget d'édition dont le champ d'édition comprend ici la valeur « 1013 ». La figure 9 représente l'arborescence de widgets à l'issue de l'étape 510 de création d'une zone d'affichage critique. Dans le cas de cette interface IHM il n'y a pas de chevauchement ou superposition des widgets affichés. Ainsi, le nouveau widget « Panel » créé peut prendre les mêmes dimensions et positions que le widget critique « calage barométrique » à surveiller. L'affichage de l'interface IHM apparaît, dans ce cas, inchangé pour l'utilisateur.

Dans l'arborescence modifiée conformément à l'invention, le nouveau widget « Panel » a été rattaché directement à la racine du calque courant. Puis les deux widgets définissant le calage barométrique ont été rattachés à ce nouveau widget « Panel ». Une fois l'interface IHM affichée à partir de l'arborescence de la figure 9, le système de surveillance procède à la distinction entre les commandes critiques à surveiller et les commandes non critiques. Dans le lien entre l'application cliente 110 et le CDS 105 (Ethernet, ARINC 429, etc.), les commandes CM sont envoyées sous forme de blocs, chaque bloc identifiant le calque concerné. Puis chaque commande à l'intérieur d'un bloc identifie le widget sur lequel celle-ci doit s'appliquer.

Diverses mises en oeuvre de la distinction sur les commandes CM peuvent être prévues. On en décrira ci-après deux. Un premier mode de réalisation schématiquement illustré sur la figure 10 repose sur la création d'un lien virtuel (VL) dédié aux commandes critiques entre l'application cliente 110 et le CDS 105. En d'autres termes, deux canaux ou liens virtuels distincts sont utilisés, l'un pour les widgets non critiques et l'autre dédié aux widgets critiques. Il s'agit donc pour l'application cliente 110 de savoir quels widgets sont critiques (par exemple via le fichier de configuration susmentionné) afin d'envoyer les commandes CM qui leur sont destinées dans le lien virtuel dédié. En outre, une synchronisation entre les deux liens virtuels doit être prévue afin de garantir un affichage synchronisé entre les widgets critiques et ceux non critiques. Cette solution est simple à mettre en oeuvre pour le serveur de gestion d'affichage, sans nécessité de rajouter un lien physique supplémentaire entre l'application cliente et le CDS. Un deuxième mode de réalisation schématiquement illustré sur la figure 11 repose sur la mise en oeuvre d'un filtre de tri au niveau du CDS 105. Sur la figure, il a été décidé d'utiliser un filtre uniquement en amont du module de surveillance. Bien entendu, d'autres configurations peuvent être envisagées.

Dans l'exemple de la figure, le filtre opère un filtrage des commandes à la réception du bloc ARINC 661 de sorte à ne transmettre au module de surveillance que les commandes critiques. Le module d'affichage reçoit, en revanche, l'ensemble des commandes reçues. Le filtre prévu a pour objet de trier les commandes à destination des widgets critiques des autres, grâce à l'identification qui est faite des widgets lors de leur instanciation et à l'identification indiquée dans les commandes. Contrairement au premier mode de réalisation, c'est le serveur de gestion d'affichage qui supporte, dans cette configuration avec filtre, la charge du tri des commandes.

Il existe dans la norme ARINC 661 un mode appelé « BufferFormat » permettant d'adresser une commande à plusieurs widgets à la fois. Il est clair que le premier mode de réalisation ne permet pas de tirer profit de ce mode du fait de la ségrégation des commandes dans les liens virtuels selon la criticité des widgets concernés. En revanche, cette mutualisation peut être conservée dans le deuxième mode de réalisation avec filtrage, auquel cas le filtre (ou un module en amont) sera configuré pour convertir une commande en mode « BufferFormat » en une pluralité de commandes équivalentes à destination de chacun des widgets destinataires. Dans le lien entre les moyens de saisie et de sélection 120 et le CDS 105, on a déjà pu évoquer le tri des commandes Cl à l'aide d'un test d'inclusion d'un événement d'interaction dans une zone graphique critique ou de l'identification d'une saisie clavier lorsqu'un widget critique est actif ou en état d'édition. Ce tri permet d'envoyer au module de surveillance uniquement les commandes Cl relatives à des widgets critiques. Le test d'inclusion notamment repose sur le fait que les zones d'affichage critiques ne doivent pas être chevauchées, ce qui n'est pas toujours le cas. Le tracé de l'interface IHM de l'application cliente est donc également source d'incertitude quant à savoir à quel widget une interaction utilisateur s'applique, par exemple en cas de superposition des widgets. En particulier, les instructions d'affichage (qu'elles résultent d'une interaction Cl ou d'une commande CM émise par l'application cliente) peuvent également être triées pour s'assurer que les instructions de tracé relatives aux widgets critiques ne viennent pas perturber la zone d'affichage non critique, vice et versa. Et ceci en raison du fait que la surveillance selon l'invention n'est pas réalisée sur l'ensemble des widgets mais seulement sur les widgets critiques.

Divers mécanismes permettant de traiter ce risque de chevauchement peuvent être prévus. Un premier mécanisme schématiquement illustré sur la figure 12 repose sur la réservation exclusive d'une surface d'affichage pour l'affichage d'une zone graphique critique. En d'autres termes, aucun autre widget, qu'il soit critique ou non, non rattaché à la zone graphique critique (c'est-à-dire au widget "Panel" correspondant) ne doit pouvoir être dessiné sur la surface réservée. En assurant cette réservation exclusive, on évite d'éventuels conflits ou incertitudes quant à savoir à quel widget s'appliquerait une nouvelle interaction utilisateur. Pour garantir cette réservation exclusive, deux mécanismes sont mis en oeuvre par le serveur de gestion d'affichage. Tout d'abord, un mécanisme anti-collision permet de s'assurer de l'absence de collision entre les surfaces d'affichage de deux zones graphiques critiques au sens de l'invention. Ce mécanisme peut s'avérer être simple: un calcul d'intersection entre les surfaces d'affichage critiques prises deux à deux suffit.

Puis, un mécanisme anti-chevauchement permet de s'assurer qu'aucun widget non rattaché à la surface d'affichage critique ne sera dessiné sur cette surface. Un mécanisme anti-chevauchement possible consiste à mettre en place un adressage séquentiel de l'affichage : dans ce cas, l'affichage de l'interface graphique d'interaction à partir de l'arborescence comprend d'abord une première étape d'exécution des instructions d'affichage relatives aux widgets non critiques, suivie d'une deuxième étape d'exécution des instructions d'affichage relatives aux widgets critiques. L'algorithme du peintre s'appliquant (le dernier tracé sera dessiné au-dessus des précédents), on s'assure ainsi que ce qui est affiché correspond à la pile d'instructions graphiques relatives à la surface d'affichage critique. Ce premier mode de réalisation est particulièrement bien adapté pour des interfaces IHM dans lesquelles aucun widget ne doit être dessiné en superposition d'un autre. C'est notamment le cas du panneau de commande EFIS ou d'une virtualisation du panneau plafond de cockpit.

En revanche, pour les interfaces IHM possédant des widgets susceptibles de s'afficher en superposition, tels que des menus déroulants, des popups, il y a lieu de prévoir, dès la conception de l'interface IHM, que ces widgets ne viendront jamais chevaucher une (autre) surface d'affichage critique. En effet, autrement, ces widgets seraient partiellement affichés voire pas affichés du tout (les surfaces d'affichage critiques étant au dessus en raison de l'algorithme du peintre), conduisant pour le pilote à une impossibilité, éventuellement partielle, à pouvoir interagir avec ces widgets. Par ailleurs, dans le cas d'une symbologie complexe réalisée à partir d'un ensemble de widgets tel que des primitives graphiques (GpLine, GpTriangle, GpLabel,...) et dont on ne souhaiterait sécuriser qu'un seul de ces éléments, ce premier mode de réalisation n'apparaît pas approprié. Un autre mécanisme de ségrégation d'affichage devra, de préférence, être utilisé, comme évoqué par la suite en référence à la figure 14. Un deuxième mécanisme schématiquement illustré sur la figure 13 repose sur la réservation non exclusive d'une surface d'affichage pour l'affichage d'une zone graphique critique. En d'autres termes, des widgets non critiques peuvent être dessinés au dessus de la zone graphique critique.

Selon ce mécanisme : - on détecte lorsqu'au moins un widget non critique est affiché en superposition (c'est-à-dire au dessus) au moins partielle de la zone graphique critique comprenant les widgets critiques; et - on inhibe, pendant la durée de la superposition, des fonctions d'interaction d'un utilisateur avec les widgets critiques. Cette inhibition peut s'accompagner d'une modification du rendu de la surface d'affichage critique correspondante (par exemple par modification de la couleur), de sorte à avertir visuellement l'utilisateur, ici un pilote. L'inhibition permet d'éviter que le pilote ne puisse interagir avec la surface d'affichage critique en cas de superposition. En effet, d'une part, le module de surveillance n'a pas connaissance de l'existence ou de la nature du widget non critique en superposition, et est donc incapable de savoir si les interactions du pilote sont adressées aux widgets critiques ou non. D'autre part, si le pilote interagit avec un widget critique, rien ne garantit que l'information qu'il perçoit de ce widget ne soit pas polluée par un widget non critique. Bien entendu, dès la détection de fin de superposition, les interactions avec les widgets critiques peuvent reprendre, en supprimant l'inhibition. Par ailleurs, il est préférable que la surface d'affichage critique ne soit pas masquée pendant un temps trop important car l'inhibition empêche par exemple au pilote d'accéder à des fonctions critiques. Pour cela, un compte à rebours est prévu pour la durée de la superposition. Ainsi, le compte à rebours est déclenché à détection de la superposition, puis, le cas échéant, un message d'alerte est émis à l'expiration du compte à rebours. Le message d'alerte peut être une sanction signalant la compromission de la surface d'affichage critique. De préférence, ce message d'alerte est transmis au pilote de telle sorte que ce dernier puisse déplacer le widget en superposition et libérer les zones d'affichage critiques. Le haut 13(a) de la figure 13 illustre la situation lorsque aucun widget non critique W1 ou W2 n'est affiché en superposition d'une zone graphique critique Si ou S2. Le bas 13(b) de la même figure illustre, en revanche, la situation lorsque un widget (ici W2) est affiché en superposition d'une zone graphique critique (ici S1). La détection de la superposition déclenche, outre le compte à rebours, l'inhibition des interactions avec les surfaces d'affichage critiques (ici 51), l'affichage désactivé de ces mêmes surfaces (leur mise à jour est gelée, c'est-à-dire l'affichage figé) et la suspension de la surveillance des widgets critiques.

Cette détection d'un chevauchement ou superposition peut reposer sur l'utilisation d'une mémoire tampon de profondeurs également connue sous l'appellation de "Z-buffer". Dans cette mémoire, de la taille de la zone d'affichage, pour chaque pixel de l'affichage, on mémorise la profondeur du widget devant être dessiné, sachant que lorsque pour un pixel deux widgets se superposent, seule la profondeur de l'objet le moins profond est mémorisée. En pratique, le Z-buffer mémorise l'identifiant de l'objet widget à afficher dans chaque pixel correspondant, la profondeur de cet objet widget pouvant par exemple être récupérée de l'arborescence. Une fois le tracé de l'interface IHM terminé, il suffit de vérifier, pour chaque pixel des surfaces d'affichage critiques, que la profondeur mémorisée dans le tampon de profondeurs correspond à un widget critique. Si tel n'est pas le cas, alors une superposition est détectée. Pour assurer la surveillance de la surface d'affichage critique par le gestionnaire de surveillance, il y a lieu de récupérer les instructions graphiques relatives aux widgets critiques (afin de vérifier si elles correspondent aux commandes CM et Cl reçues). Pour ce faire, des marqueurs peuvent être prévus au niveau de ces instructions "critiques" dans la pile d'instructions graphiques, les marqueurs étant ajoutés lors de la génération de ces instructions par le module d'affichage. Si les principes décrits ci-dessus s'appliquent à la majorité des cas d'interfaces IHM, il existe certains cas particuliers que l'homme du métier saura appréhender le cas échéant. Tel est le cas particulier d'une symbologie réalisée au travers de widgets de primitives graphiques (GPxxxx). Ce cas particulier est illustré par la figure 14, montrant un écran principal de vol (PFD pour "primary flight display") constitué, sur un fond, d'un premier widget critique (primitive "GPLine") indiquant la direction de vol et d'un deuxième widget non critique (également primitive "GPLine") indiquant la piste. Les deux approches évoquées ci-dessus s'avèrent insuffisantes pour sécuriser l'affichage de cette symbologie. En effet, il est presque impossible de garantir que des erreurs sur des widgets non critiques ne viennent pas corrompre l'affichage des widgets critiques. Dans l'exemple de la figure, le widget GPLine non critique de la piste a été corrompu: modification de couleur et de position (illustration à droite). Cet affichage serait alors susceptible d'induire en erreur le pilote. Il y a donc lieu de prévoir des mécanismes supplémentaires de ségrégation d'affichage entre les widgets de primitives. Dans un mode de réalisation, les widgets sont sécurisés en utilisant des styles spécifiques aux widgets critiques (par exemple un effet de halo autour des widgets critiques affichés permettant au pilote d'identifier avec certitude les éléments critiques). Un autre cas particulier évoqué ici concerne les widgets transparents, c'est- à-dire recouvrant de manière permanente la surface d'affichage critique mais dont aucune information n'est visible sur l'écran 115 pour le pilote. De tels widgets transparents sont généralement utilisés pour intercepter les interactions du pilote. Pour assurer une surveillance efficace dans ce cas, on peut prévoir que le module d'affichage est configuré pour interdire à ce genre de widget d'intercepter les interactions si celles-ci sont destinées à une surface d'affichage critique.

Une fois les commandes et les instructions d'affichage triées pour permettre au module de surveillance de recevoir celles relatives aux widgets critiques, ce module procède à la surveillance à proprement parler, c'est-à-dire à la vérification de la conformité entre une sortie d'un widget critique et une sortie estimée par le module de surveillance pour ce même widget, à partir de la même commande reçue.

Jusqu'à présent il a été fait référence à un module de surveillance pour effectuer cette opération de surveillance. Ainsi, un tel module peut être prévu pour surveiller de façon globale l'ensemble des widgets critiques. Dans une variante, ce module de surveillance est composé d'une pluralité de modules hébergés dans les widgets critiques eux-mêmes. Ces widgets dotés d'une fonction propre de surveillance sont nommés ci-après "widgets autotestables". Ce mode de réalisation s'apparente à une surveillance orientée objet, où chaque widget critique est un objet informatique incluant une fonction propre et une fonction de contrôle ou de surveillance, comme montré sur la figure 15. Un widget autotestable permet une surveillance de l'ensemble des entrées et sorties du widget, avec une couverture de détection totale de fautes. En raison des ressources qu'il nécessite, il est avantageusement mis en oeuvre lorsque l'interface IHM comporte peu de widgets critiques, par exemple au plus une dizaine. Le bloc fonctionnel propre décrit le comportement précis du widget, c'est-à- dire les états du widget, la gestion des commandes CM (setparameter) émises par l'application cliente, les événements émis par le widget, les commandes d'interaction Cl reçues des moyens de saisie et de sélection 120 et le rendu graphique du widget. Le bloc de contrôle inclut un module propre de détermination théorique pour réaliser une fonction simplifiée de la fonction propre du widget, et un comparateur propre pour comparer le message théorique de sortie du module de détermination théorique avec une sortie correspondante du bloc fonctionnel.

La fonction simplifiée est notamment un modèle réduit du comportement du widget, ayant pour but la vérification des propriétés que l'on veut surveiller. Ainsi, il est possible de limiter la surveillance à certaines propriétés uniquement. Par exemple, une réduction de complexité peut consister en la non prise en compte des paramètres liés au rendu graphique, par exemple le focus lorsque le curseur est sur le widget. Le comparateur a pour rôle de vérifier la cohérence entre les résultats du bloc fonctionnel et du modèle simplifié de la fonction. Les comparaisons réalisées permettent de vérifier la cohérence des sorties en fonction des commandes en entrée. Un message d'erreur est émis le cas échéant en fonction du résultat de la comparaison. La figure 16 illustre ce contrôle à réception d'une commande CM de l'application cliente pour effectuer une mise à jour de l'affichage. Le fonctionnement prévu au niveau du widget autotestable est le suivant : - duplication de la commande CM reçue (setparameter) vers le bloc fonctionnel et vers le bloc de contrôle; - traitement en parallèle de cette commande CM par le bloc fonctionnel (fonctionnement classique du widget) et par la fonction simplifiée. Puis envoi des résultats au comparateur; - comparaison des résultats par le comparateur. S'il y a incohérence, une erreur est levée, sinon seule la sortie du bloc fonctionnel est envoyée pour affichage. De façon similaire, la figure 17 illustre le contrôle à réception d'une commande d'interaction Cl pour transmettre un message d'événement à l'application cliente. Le fonctionnement prévu au niveau du widget autotestable est le suivant : - les événements Cl des moyens de saisie et de sélection 120 initiés par l'utilisateur sont dupliqués vers le bloc fonctionnel et le bloc de contrôle; - le bloc fonctionnel et la fonction simplifiée effectuent en parallèle le traitement de l'événement en fonction de l'état interne du widget. Les résultats des deux blocs sont ensuite envoyés au comparateur; - le comparateur effectue une comparaison des résultats. S'il y a incohérence, une erreur est levée, sinon seule la sortie du bloc fonctionnel est envoyée à l'application cliente 110. Bien entendu, cet envoi peut être accompagné d'une mise à jour du widget à raison de l'interaction réalisée par l'utilisateur. La figure 18 illustre le schéma de communication pour un widget "PushButton" (selon la norme ARINC 661) rendu autotestable selon l'invention.

Différents événements d'interaction Cl peuvent être reçus par le widget "PushButton": MouseClicked, MouseReleased et MouseDown, bien connus de l'homme de l'art. Différents paramètres sont modifiables par l'application cliente via une commande CM (set_parameter): Visible, Enable, LabelString et Styleset, également connus de l'homme de l'art. En réponse à une interaction Cl de l'utilisateur, l'assertion ou règle du widget "PushButton" est la suivante : Evénement A661_EVT SELECTION envoyé à l'application cliente 110 si: réception Evénement ProcessMouseclick et enable = vrai et visible = vrai. Plusieurs cas de défaillance peuvent donc se produire : - satisfaction de l'ensemble de la condition (réception de l'événement ProcessMouseclick et enable = vrai et visible = vrai) sans que l'événement A661_EVT SELECTION ne soit envoyé; - absence de réception de l'événement ProcessMouseClick alors que l'événement A661_EVT SELECTION est envoyé; - enable = faux et/ou visible = faux, alors que l'événement A661_EVT SELECTION est envoyé. Dans ce cas assez simple, la fonction simplifiée est identique à la fonction propre du widget, et reprend donc l'assertion/règle définie ci-dessus dépendant à la fois de la commande Cl en entrée et des états courants enable et visible du widget. La surveillance du widget à l'égard de l'une de ces défaillances est illustrée par la figure 19. Le bloc fonctionnel propre et la fonction simplifiée déterminent, chacun indépendamment de l'autre, le résultat de la règle ci-dessus. Une comparaison des sorties du bloc fonctionnel et de la fonction simplifié (sortie théorique ou estimée) permet alors de détecter l'une de ces défaillances. En ce qui concerne la réponse du widget à une commande CM (set_parameter) émise par l'application cliente, la surveillance peut consister à détecter toute valeur corrompue sur les paramètres renseignés dans la commande CM.

Pour le paramètre LabelString (chaîne de caractères), considérons labelstring F la valeur en sortie du bloc fonctionnel propre et labelstring C la valeur estimée en sortie de la fonction simplifiée. Si le comparateur détecte labelstring F 0 labelstring C, alors une erreur est levée. Une approche identique peut être appliquée pour les autres paramètres Visible, Enable et Styleset.

Les aspects de l'invention décrits précédemment permettent d'obtenir une surveillance complète des widgets critiques (aussi bien les événements d'interactions Cl que les modifications de paramètres CM émises par l'application cliente), notamment au travers des widgets "autotestables". L'approche adoptée repose en outre sur une architecture générique de surveillance applicable à tout type de widget (de commande, de saisie ou d'affichage). Enfin, le procédé de construction de surface d'affichage critique selon l'invention permet d'optimiser les widgets critiques à surveiller, autant dans leur affichage que dans leur utilisation.

La figure 20 illustre un exemple d'architecture matérielle, par exemple un serveur ou un ordinateur, adaptée à mettre en oeuvre certaines étapes de l'invention, en particulier les étapes mises en oeuvre pour la surveillance. Le dispositif 2000 comporte ici un bus de communication 2005 auquel sont reliés : - une ou plusieurs unités centrales de traitement ou microprocesseurs 2010 (CPU, sigle de Central Processing Unit en terminologie anglo-saxonne) ; - une mémoire morte 2015 (ROM, acronyme de Read Only Memory en terminologie anglo-saxonne) pouvant comporter des programmes (prog, progl et prog2) nécessaires à la mise en oeuvre de l'invention ; - une mémoire vive ou mémoire cache 2020 (RAM, acronyme de 20 Random Access Memory en terminologe 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 2050 adaptée à transmettre et à recevoir des données. 25 Le dispositif 2000 dispose également, de préférence, des éléments suivants : - une ou plusieurs unités d'affichage 2025 permettant de visualiser des données et pouvant servir d'interface graphique avec un utilisateur qui pourra interagir avec des programmes selon l'invention, à l'aide d'un clavier et d'une souris 2030 ou 30 d'un autre dispositif de pointage tel qu'un écran tactile ou une télécommande ; - d'un disque dur 2035 pouvant comporter les programmes précités ainsi que des informations traitées ou à traiter selon l'invention ; et - d'un lecteur de cartes mémoires 2040 adapté à recevoir une carte mémoire 2045 et à y lire ou à y écrire des données traitées ou à traiter selon 35 l'invention.

Le bus de communication permet la communication et l'interopérabilité entre les différents éléments inclus dans le dispositif 2000 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 2000 directement ou par l'intermédiaire d'un autre élément du dispositif 2000. 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 2035 ou en mémoire morte 2015. Selon une variante, la carte mémoire 2045 peut contenir des informations, notamment des informations à traiter selon l'invention, ainsi que le code exécutable des programmes précités qui, une fois lu par le dispositif 2000, est stocké dans le disque dur 2035. Selon une autre variante, le code exécutable des programmes et les informations à traiter selon l'invention pourront être reçus, au moins partiellement, par l'intermédiaire de l'interface 2050, pour être stocké de façon identique à celle décrite précédemment. De manière plus générale, le ou les programmes ainsi que les informations à traiter selon l'invention pourront être chargés dans un des moyens de stockage du dispositif 2000 avant d'être exécutés.

L'unité centrale 2010 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 2035 ou dans la mémoire morte 2015 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 2035 ou la mémoire morte 2015, sont transférés dans la mémoire vive 2020 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 compétente dans le domaine de l'invention pourra appliquer des modifications dans la description précédente.

Claims (15)

1. REVENDICATIONS1. Procédé de surveillance d'une interface graphique dans un système informatique d'un cockpit d'aéronef, comprenant l'affichage (520) d'une interface graphique d'une application cliente (110) à partir d'une arborescence d'objets graphiques d'interaction composant ladite interface graphique, ce procédé étant caractérisé en ce qu'il comprend les étapes suivantes : - obtenir (500) une pluralité d'objets graphiques d'interaction organisés de façon arborescente; - créer et ajouter (514), à ladite arborescence obtenue, au moins un nouvel objet graphique d'interaction (Wy, Wz) définissant une zone graphique d'affichage, dite critique (SC); - modifier (516) la dépendance arborescente d'au moins un objet graphique (Wi, Wj) d'interaction de l'arborescence obtenue, dit critique, pour le rendre dépendant du nouvel objet graphique d'interaction (Wy, Wz) définissant la zone critique; et - opérer (530) une surveillance, dite critique, des seuls objets graphiques critiques rattachés à la zone critique.
2. 2. Procédé selon la revendication 1, dans lequel le nouvel objet graphique d'interaction définissant la zone critique est rattaché directement à la racine (WO) de l'arborescence.
3. 3. Procédé selon la revendication 1 ou 2, dans lequel ledit nouvel objet graphique d'interaction créé définit une zone graphique critique correspondant à une surface d'affichage distincte des surfaces d'affichage des objets graphiques non critiques.
4. 4. Procédé selon l'une des revendications précédentes, comprenant en outre une étape de tri (532), parmi des commandes (CM, Cl) reçues à destination des objets graphiques d'interaction de l'arborescence, entre les commandes, dites critiques, à destination des objets graphiques critiques (Wi, Wj) et les commandes à destination des autres objets graphiques, dits non critiques; et la surveillance critique s'opère sur les commandes critiques uniquement.
5. 5. Procédé selon l'une des revendications précédentes, dans lequel la surveillance critique d'un objet graphique critique comprend, pour une commande (CM, Cl) reçue à destination de cet objet graphique critique, la comparaison entre un message de sortie de l'objet graphique critique en réponse à la commande reçue et unmessage théorique de sortie déterminé par un module de surveillance à partir de la commande reçue, et comprend la génération d'un message d'erreur en cas de comparaison négative.
6. 6. Procédé selon la revendication 5, dans lequel un objet graphique critique est un objet informatique comprenant, outre un bloc fonctionnel correspondant à la fonction propre de l'objet graphique critique, un bloc de contrôle pour effectuer ladite comparaison.
7. 7. Procédé selon la revendication 6, dans lequel le bloc de contrôle d'un objet graphique critique comprend un bloc fonctionnel simplifié pour réaliser une fonction simplifiée de ladite fonction de l'objet graphique critique, et un comparateur pour comparer une sortie du bloc fonctionnel simplifié avec une sortie correspondante du bloc fonctionnel.
8. 8. Procédé selon l'une des revendications 1 à 7, dans lequel l'affichage de l'interface graphique d'interaction à partir de l'arborescence comprend une première étape d'exécution des instructions d'affichage relatives aux objets graphiques non critiques, suivie d'une deuxième étape d'exécution des instructions d'affichage relatives aux objets graphiques critiques.
9. 9. Procédé selon l'une des revendications 1 à 7, comprenant en outre les étapes consistant à : - détecter lorsqu'au moins un objet graphique non critique est affiché en superposition au moins partielle de la zone graphique critique comprenant les objets graphiques critiques; et - inhiber, pendant la durée de la superposition, des fonctions d'interaction d'un utilisateur avec les objets graphiques critiques.
10. 10. Procédé selon la revendication 9, dans lequel la détection de la superposition comprend une étape de mise à jour d'un tableau de profondeurs lors d'une mise à jour de l'affichage de l'interface graphique, ledit tableau de profondeurs mémorisant pour chaque pixel d'affichage la profondeur de l'objet graphique le moins profond situé au niveau de ce pixel, et comprend une étape de détermination d'un pixel qui appartient à ladite zone graphique critique et, à la fois, dont la profondeur mémorisée dans le tableau correspond à un objet graphique non critique.
11. 11. Système de surveillance d'une interface graphique dans un système informatique d'un cockpit d'aéronef, comprenant un module d'affichage pour commander l'affichage d'une interface graphique d'une application cliente (110) à partird'une arborescence d'objets graphiques d'interaction composant ladite interface graphique, ce système étant caractérisé en ce qu'il comprend : - un moyen pour obtenir une pluralité d'objets graphiques d'interaction organisés de façon arborescente; - un module de définition d'une zone graphique critique à surveiller pour créer et ajouter, à ladite arborescence obtenue, au moins un nouvel objet graphique d'interaction définissant une zone graphique d'affichage, dite critique, et pour modifier la dépendance arborescente d'au moins un objet graphique d'interaction de l'arborescence obtenue, dit critique, de sorte à le rendre dépendant du nouvel objet graphique d'interaction définissant la zone critique; et - un module de surveillance des objets graphiques critiques pour opérer une surveillance, dite critique, des seuls objets graphiques élémentaires critiques rattachés à la zone critique.
12. 12. Système selon la revendication 11, dans lequel le module d'affichage de l'interface graphique d'interaction à partir de l'arborescence est configuré pour commander d'abord l'exécution des instructions d'affichage relatives aux objets graphiques non critiques, puis l'exécution des instructions d'affichage relatives aux objets graphiques critiques.
13. 13. Système selon la revendication 11, comprenant en outre : - un module de détection pour détecter un objet graphique non critique affiché en superposition au moins partielle de la zone graphique critique comprenant les objets graphiques critiques; et - un module d'inhibition pour inhiber, pendant la durée de la superposition, des fonctions d'interaction d'un utilisateur avec les objets graphiques critiques.
14. 14. Système de surveillance comprenant des moyens adaptés à la mise en oeuvre de chacune des étapes du procédé selon l'une quelconque des revendications 1 à 10.
15. 15. Aéronef comprenant un système de surveillance selon l'une des revendications 11 à 14.