FR2963690A1 - Systeme informatique "client-serveur" securise pour applications interactives - Google Patents

Systeme informatique "client-serveur" securise pour applications interactives Download PDF

Info

Publication number
FR2963690A1
FR2963690A1 FR1003304A FR1003304A FR2963690A1 FR 2963690 A1 FR2963690 A1 FR 2963690A1 FR 1003304 A FR1003304 A FR 1003304A FR 1003304 A FR1003304 A FR 1003304A FR 2963690 A1 FR2963690 A1 FR 2963690A1
Authority
FR
France
Prior art keywords
widgets
display
secure
client
computer system
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR1003304A
Other languages
English (en)
Other versions
FR2963690B1 (fr
Inventor
Thierry Ganille
Patrice Capircio
Pierre Jean Turpeau
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Thales SA
Original Assignee
Thales SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Thales SA filed Critical Thales SA
Priority to FR1003304A priority Critical patent/FR2963690B1/fr
Priority to RU2011133131/08A priority patent/RU2586008C2/ru
Priority to BRPI1103857-8A priority patent/BRPI1103857A2/pt
Priority to US13/198,931 priority patent/US8812865B2/en
Priority to CN201110287539.6A priority patent/CN102571741B/zh
Publication of FR2963690A1 publication Critical patent/FR2963690A1/fr
Application granted granted Critical
Publication of FR2963690B1 publication Critical patent/FR2963690B1/fr
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0751Error or fault detection not based on redundancy
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0736Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function
    • G06F11/0739Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function in a data processing system embedded in automotive or aircraft systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/14Digital output to display device ; Cooperation and interconnection of the display device with other functional units
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/451Execution arrangements for user interfaces
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/12Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/131Protocols for games, networked simulations or virtual reality
    • GPHYSICS
    • G09EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09GARRANGEMENTS OR CIRCUITS FOR CONTROL OF INDICATING DEVICES USING STATIC MEANS TO PRESENT VARIABLE INFORMATION
    • G09G2358/00Arrangements for display data security
    • GPHYSICS
    • G09EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09GARRANGEMENTS OR CIRCUITS FOR CONTROL OF INDICATING DEVICES USING STATIC MEANS TO PRESENT VARIABLE INFORMATION
    • G09G2380/00Specific applications
    • G09G2380/12Avionics applications

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Quality & Reliability (AREA)
  • Human Computer Interaction (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Digital Computer Display Output (AREA)
  • User Interface Of Digital Computer (AREA)
  • Computer And Data Communications (AREA)

Abstract

Le domaine général de l'invention est celui des systèmes informatiques de type client-serveur pour applications graphiques, c'est-à-dire pour affichage de données sous formes d'unités logicielles appelées « widgets » sur des écrans d'affichage appelés « Display Unit », ledit système contrôlant le fonctionnement d'une machine, la machine comprenant au moins une interface homme-machine permettant d'interagir avec les widgets, ledit système gérant des données ou des fonctions critiques. Le système informatique selon l'invention comporte un moteur de sécurisation contrôlant l'intégrité de l'affichage des widgets critiques, les envois de commande effectués au moyen de l'interface homme-machine, la saisie et l'affichage des données critiques. Les principales dispositions de ce moteur de sécurisation sont l'emploi de « signatures » informatiques, la mise en place de circuits de « feedback» et l'utilisation de mécanismes de garde ou de boîtes de dialogue de confirmation dédiées. De façon préférentielle, la machine est un aéronef, le système informatique est l'avionique de bord dudit aéronef et les écrans d'affichage sont les systèmes de visualisation de cockpit.

Description

Système informatique « client-serveur » sécurisé pour applications interactives Le domaine de l'invention est celui des systèmes informatiques dits « client-serveur » sécurisés pour applications interactives, et en particulier pour applications avioniques.
10 Les systèmes « client-serveur», utilisés largement dans le monde des réseaux informatiques ont fait leur apparition au début des années 2000 dans l'avionique de cockpit. On entend par avionique de cockpit l'ensemble des moyens électroniques et informatiques permettant de traiter, de visualiser, de contrôler et de modifier les informations nécessaires au 15 pilotage et à la navigation d'un aéronef et plus généralement à l'accomplissement de la mission de l'aéronef pendant un vol. La norme ARINC 661 fournit un cadre standardisé pour la mise en oeuvre de ces architectures informatiques en aéronautique. Les composants d'un tel système sont principalement : 20 - Un serveur graphique fournissant une capacité à tracer des objets graphiques de base à partir de sollicitations reçues sous la forme de requêtes ou de commandes ; - Des clients baptisés « User Application » ou « U.A. » dans la norme ARINC 661 exécutant les fonctions opérationnelles et envoyant des 25 requêtes au serveur pour réaliser l'affichage des informations. Le serveur graphique offre aussi la capacité de traiter des actions qu'un opérateur, en l'occurrence l'équipage, veut lancer sur un client. Dans une architecture client-serveur, l'intelligence opérationnelle est donc localisée dans les clients. Le serveur se contente d'exécuter les requêtes de ses 30 clients sans n'en avoir aucune connaissance opérationnelle. A l'inverse, dans les architectures avioniques conventionnelles, l'intelligence opérationnelle est située dans les équipements de cockpit qui maîtrisent donc le contenu fonctionnel de ce qu'ils affichent. Les figures 1 et 2 décrivent les flots fonctionnels d'un serveur 35 interactif à l'initialisation du système et pendant l'utilisation du système. Une application interactive ou client envoie à l'initialisation du système, sous5 forme de commandes d«< instanciation », la définition des pages interactives qui sont stockées sur le serveur sous la forme du modèle des « widgets ». On entend par « widget » une unité logicielle associée à une représentation graphique et un comportement présenté sur les unités de visualisations de cockpits encore appelées « DU », signifiant « Display Unit ». Les widgets permettent à l'équipage au moyen d'un média de contrôle de donner des instructions au système de contrôle de l'aéronef et de recevoir des informations. A partir de ce modèle, comme on le voit sur la figure 2, des commandes graphiques sont générées cycliquement et envoyées à la machine graphique. Le modèle des widgets peut-être modifié soit par envoi d'une commande de l'application sur sa propre initiative, soit par l'action d'un utilisateur sur le média de contrôle qui génère également une réponse de l'application sous la forme d'une commande. Sur la figure 2, le parcours des commandes des média est représenté par des flèches en traits gras.
A titre d'exemples, les média de contrôle sont des claviers, des « souris » informatiques, des « trackballs », des écrans tactiles ou des postes de commande dédiés, par exemple de type « KCCU » pour « Keyboard Cursor Control Unit » . Les widgets sont classiquement des menus déroulants, des boutons graphiques, des zones de saisie numérique, des « combo-box » et plus généralement recouvrent l'ensemble des moyens d'interaction graphique.
En aéronautique, il existe un certain nombre de fonctions dites critiques qui doivent pouvoir être gérées par un système « client-serveur ».
On entend par donnée ou fonction critique une donnée ou une fonction dont la modification impromptue ou l'activation intempestive par un système piloté peut engendrer un scénario catastrophique ou un accident pour l'aéronef. Les événements redoutés sont de deux natures, les erreurs humaines d'une part, et des dysfonctionnements conduisant à un problème de non-intégrité des fonctions ou des données ou encore une activation intempestive d'autre part. Les erreurs humaines consistent en une action involontaire ou intempestive de l'opérateur, par exemple un click involontaire sur un widget. Le problème d'intégrité concerne trois types d'évènements : - Une interaction de l'utilisateur qui obtient un bon retour visuel, mais dont la commande associée n'est pas traitée ou envoyée et l'utilisateur ne le sait pas. II faut donc garantir la prise en compte d'une requête utilisateur issue d'une action sur un élément graphique et la réalisation du traitement associé ; - Une interaction utilisateur qui n'engendre. aucun retour visuel, mais dont la commande associée est traitée ou envoyée et l'utilisateur ne le sait pas. II faut donc assurer la cohérence entre une interaction utilisateur et le retour visuel associé ; - Une modification inopinée de la structure du modèle des widgets ou des attributs de ce modèle.
Sur le plan de la sûreté de fonctionnement, il est nécessaire de mettre en place un contrôle d'intégrité de la fonction opérationnelle dans le système de cockpit. L'une des techniques couramment mise en oeuvre est le «feedback » qui consiste à vérifier, par un calcul inverse, la cohérence des paramètres affichés avec les paramètres fournis au système. Le fondement mathématique de ce mécanisme est basé sur le fait que la composition d'une fonction par son inverse est égale à la fonction identité (F° F"1 = identité).
Ainsi, s'il est possible de trouver la fonction inverse F-1 de la fonction d'affichage F d'un paramètre critique p, il suffit de vérifier que F(F"1(p)) = p pour garantir que la fonction F s'est bien exécutée. D'un point de vue système, afin de garantir qu'il n'y a pas de panne pouvant affecter à la fois la fonction et sa surveillance, les fonctions F et F_1 doivent être suffisamment ségréguées. Des mécanismes spécifiques de ségrégation ou « partitioning » sont ainsi mis en oeuvre dans la structure d'accueil de chaque coeur de calcul afin d'éviter qu'une éventuelle pollution d'une panne d'une première fonction affecte une seconde fonction (en particulier la fonction de surveillance). La figure 3 illustre le mécanisme du contrôle par « feedback » d'une chaîne de visualisation comprenant classiquement : des moyens d'acquisition des informations issues d'un capteur qui peut être une centrale inertielle, par exemple ; des moyens de traitement des dits paramètres et ; des moyens de génération graphique, l'ensemble constituant une 35 fonction F de traitement des paramètres du capteur.
Cette chaîne comporte une chaîne de surveillance qui acquière en parallèle les informations venant du capteur et les compare avec les données issues d'une fonction F 1 qui recalcule, à partir des informations graphiques, la valeur des paramètres venant du capteur.
Par conséquent, un système « client-serveur » utilisable, par exemple pour des applications aéronautiques, pour des fonctions critiques doit permettre : - L'affichage sur les « DU » de données critiques envoyées sous la forme de commandes par une application interactive hébergée sur un client. On citera notamment l'affichage de paramètres moteur envoyés par les calculateurs idoines ; - L'utilisation de l'interactivité sur les « DU » pour contrôler des fonctions critiques. A titre d'exemple, on souhaite que l'équipage puisse modifier l'état d'une pompe du système de gestion du fuel de façon sûre. L'introduction des architectures client-serveur dans les systèmes critiques pose le problème de la mise en oeuvre du contrôle d'intégrité. Le mécanisme actuel de feedback couvrant l'ensemble de la chaîne fonctionnelle ne peut pas se décliner directement sur le serveur d'une part et le client d'autre part. De plus, l'interactivité utilisateur, c'est-à-dire le lancement de commandes par l'équipage à partir de l'interface graphique n'est actuellement pas mise en oeuvre pour des fonctions critiques ou bien est mise en oeuvre à l'aide de moyens supplémentaires fortement contraignants sur le plan des facteurs humains. Actuellement, pour éviter ces problèmes, les architectures « client-serveur » sont mises en oeuvre dans des systèmes embarqués non critiques.
La présente invention a pour objet de proposer un mécanisme de 30 sécurisation d'un système client-serveur permettant d'empêcher le déclenchement fortuit d'une fonction par l'utilisateur ; de garantir l'intégrité des fonctions du serveur, y compris le lancement d'actions interactives par l'opérateur de garantir la cohérence de des informations entre le serveur et les clients.
Le mécanisme de sécurisation est un ensemble fonctionnel encore appelé « moteur de sécurisation » mettant en oeuvre un ensemble de mécanismes propres à chaque famille de fonctions du serveur. Ainsi, le contrôle d'intégrité est basé sur un moteur de calcul concentrant les contrôles effectués sur un ensemble de mécanismes particuliers à chaque famille de fonction du serveur : Utilisation de « gardes » ; Utilisation de « signatures » mathématiques ; Mise en oeuvre de « feedback » sur certaines sous-fonctions mais pas sur la chaîne globale. La signature mathématique est une technique initialement conçue pour la surveillance des transmissions de données et de détection de corruption de fichiers informatiques. Cette technique est ici déclinée à des fins de sûreté de fonctionnement du système. Les mécanismes de sécurisation selon l'invention sont déclinés sur le protocole ARINC 661 mais cette invention est généralisable à tout type de systèmes interactifs client- serveur. Cette invention permet de garantir l'intégrité du serveur ARINC 661, c'est à dire garantir que les sorties critiques du serveur, c'est-à-dire des commandes en ARINC 661 ainsi que les instructions de tracé dans un langage graphique quelconque qu'on appelle dans la suite du texte « XGL » sont cohérentes de ses entrées fournies par le système de saisie et de pointage et les commandes ARINC 661. Il est à noter que le moteur de sécurisation est un ensemble de fonctions, de logiciels qui n'est pas localisé sur un calculateur particulier.
Plus précisément, l'invention a pour objet un système informatique de type client-serveur pour applications graphiques, c'est-à-dire pour affichage de données sous formes d'unités logicielles appelées « widgets » sur des écrans d'affichage appelés « Display Unit », chaque widget étant définie par des « attributs », ledit système destiné à contrôler le fonctionnement d'une machine, la machine comprenant au moins une interface homme-machine permettant d'interagir avec les widgets, ledit système gérant des données ou des fonctions critiques, c'est-à-dire des données ou des fonctions pouvant entraîner un dysfonctionnement grave de ladite machine, les widgets étant réunis dans une structure appelée « modèle » comprenant les propriétés de chaque widget ainsi que leur organisation hiérarchique, ledit modèle étant créé à partir d'un fichier de définition de l'application-client, les widgets assurant l'affichage des fonctions critiques étant appelés « widgets sécurisés », caractérisé en ce que ledit système informatique comporte un 10 moteur de sécurisation comprenant des dispositions_ de surveillance de l'affichage des widgets sécurisés, la première disposition de contrôle étant constituée par le premier calcul d'une « signature » du modèle des widgets sécurisés, par le second calcul d'une « signature » du fichier de définition des widgets sécurisés et par 15 la comparaison des deux signatures, une signature étant un code mathématique associé aux attributs des widgets sécurisés ; la seconde disposition de contrôle étant constituée par des algorithmes de vérification de la conformité de la pile d'instructions graphiques généré par le serveur avec le modèle des widgets sécurisés, 20 lesdits algorithme étant de type « feedback ». Avantageusement, le moteur de sécurisation comprend au moins une disposition de contrôle des envois de commande ainsi que de la saisie et de l'affichage de données effectués au moyen de l'interface homme-machine sur les widgets sécurisés, ladite disposition étant que les widgets sécurisées 25 sont de type « UA-Validation », c'est-à-dire que, lorsqu'un ordre de changement d'état dudit widget sécurisé est reçu venant de l'interface homme-machine, ledit widget sécurisé attend un message de confirmation du « client » avant de changer d'état. Avantageusement, le moteur de sécurisation comprend au moins : 30 - des premières dispositions de contrôle de commande ainsi que de la saisie et de l'affichage de données effectués au moyen de l'interface homme-machine sur les widgets sécurisés, lesdites premières dispositions étant que les widgets sécurisés comportent soit des mécanismes de garde, soit des boîtes de dialogue, un mécanismes de garde est un objet graphique protégeant le widget sécurisé que l'on doit nécessairement déverrouiller avant d'accéder au dit widget sécurisé ; - des secondes dispositions de contrôle de la saisie et de l'affichage de données effectués au moyen de l'interface homme-machine sur les widgets sécurisés, lesdites secondes dispositions assurant la cohérence du verrouillage de la garde ou de la boîte de dialogue avec l'état du widget sécurisé ; - des troisièmes dispositions de contrôle de commande ainsi que de la saisie et de l'affichage de données effectués au moyen de l'interface homme-machine sur les widgets sécurisés, lesdites troisièmes dispositions étant constituées par l'association de signatures des widgets critiques avec leurs gardes ou boutons de confirmation et la vérification par l'UA des couples de signatures via une table de correspondance; - des quatrièmes dispositions assurant l'intégrité de la valeur 15 saisie par l'utilisateur par la transmission à l'UA de la valeur et de sa signature pour vérification de leur cohérence par l'UA,
Préférentiellement, la machine est un aéronef, le système informatique est l'avionique de bord dudit aéronef et les écrans d'affichage 20 sont les systèmes de visualisation de cockpit et le système informatique fonctionne conformément à la norme aéronautique ARINC 661.
L'invention sera mieux comprise et d'autres avantages apparaîtront à la lecture de la description qui va suivre donnée à titre non 25 limitatif et grâce aux figures annexées parmi lesquelles : Les figures 1 et 2 représentent deux synoptiques déjà commentés du fonctionnement typique d'un système client serveur selon l'art antérieur, le premier synoptique à l'initialisation du système et le second en fonctionnement courant du système; 30 La figure 3 représente une chaîne de visualisation comprenant une chaîne de surveillance avec feedback selon l'art antérieur ; La figure 4 représente les différents flux de données dans le cadre d'une application client-serveur aéronautique ; La figure 5 est une partie de représentation graphique de boutons de garde en position verrouillée et déverrouillée dans le cadre de l'affichage des circuits de commande moteur ; Les figures 6, 7 et 8 représentent les principes de fonctionnement 5 selon l'invention de mécanisme de garde ou de boîtes de dialogue dans le cas d'envoi de commandes sécurisées. Tout ce qui suit concerne un système informatique client-serveur sécurisé pour applications avioniques fonctionnant sous ARINC 661. 10 Cependant, les notions développées dans ce cadre particulier sont facilement transposables dans d'autres domaines techniques ayant des exigences semblables en matière de sécurité des échanges informatiques et des présentations graphiques.
15 La figure 4 représente le synoptique des échanges de données entre les différentes composantes du système client-serveur avionique. Le coeur du système est l'unité d'affichage ou « Display Unit » ou DU. II affiche les widgets à partir du modèle des widgets qui est la structure de données en mémoire gérée par le serveur ARINC 661 stockant les propriétés de chaque 20 widget ainsi que la hiérarchie entre widgets. Ce modèle est créé à partir du "User Application Definition File" ou « UADF », appelé plus simplement « DF » dans ce qui suit. Le « DU » interagit avec les différents média d'interaction contrôlés par l'utilisateur et I«< UA ». Comme on l'a vu, le moteur de sécurisation doit garantir l'intégrité 25 de l'affichage de données critiques puis dans un second temps l'interactivité sur les Displays Units. La description qui suit comporte donc deux grands chapitres, le premier consacré à la sécurisation de l'affichage, le second à la sécurisation de l'interactivité.
30 Sécurisation de l'affichage Il est nécessaire d'assurer la sécurisation de l'affichage d'une donnée critique envoyée en ARINC 661 par une UA à une DU. Un serveur ARINC 661 gère l'affichage des widgets sur une DU en deux étapes : a) gestion en mémoire d'une structure de données appelé modèle 35 des widgets contenant les propriétés de chaque widget et supportant les relations parent-enfant entre les différents widgets ; b) génération des instructions graphiques dites XGL par parcours de la structure de données.
Le moteur de sécurisation doit couvrir ces deux étapes. a) Sécurisation du modèle des widgets Deux types d'événements peuvent modifier ce modèle : Une commande en A661 envoyée par une UA ; Un événement envoyé par l'avionique de cockpit dit « CDS » pour « Cockpit Display System » ayant, par exemple, pour conséquence une reconfiguration des DU ; Concernant les évènements envoyés par le CDS, on distingue les reconfigurations issues d'une interaction pilote comme, par exemple, une demande de changement de page par l'équipage sur une DU de celles dues à une modification de l'état du système comme, par exemple, la panne d'un DU entraînant une reconfiguration du système. Le résultat d'une reconfiguration est la modification de l'affichage des éléments interactifs qui conditionne les dialogues entre les UA et le serveur ARINC 661. Cette modification des dialogues a un impact plus ou moins important sur le modèle de widgets. L'activation d'une nouvelle page interactive est un exemple de modification visible de l'extérieur qui entraîne une mise à jour du modèle des widgets, les attributs de visibilité de l'ensemble des widgets constituant cette page étant modifiés.
La sécurisation du modèle des widgets revient donc : à gérer son intégrité vis à vis du DF à l'initialisation, puis à s'assurer que le modèle n'est pas modifié inopportunément pendant l'exécution ou « run-time » ; enfin à s'assurer que son évolution est conforme aux commandes 30 ARINC 661 reçues des UA et des événements CDS. Il est important lors de la spécification de bien identifier les widgets à sécuriser pour n'appliquer ce processus que sur ces widgets.
Pour assurer cette sécurisation, le moteur de sécurisation utilise 35 des « signatures », une signature étant un code mathématique associé aux attributs des widgets sécurisés. Ce code est généralement un code de « Hamming ». Il est à noter qu'un DF peut-être vu comme un ensemble de commandes ARINC 661 et donc que l'on peut utiliser la même méthode de signature pour une commande ARINC 661 envoyée par une UA et un fichier DF. Pour ces signatures, on peut utiliser une fonction tenant compte : Du type de la commande et de son code A661 ; Des identifiants du widget ; De la valeur de la commande. Par exemple, à l'initialisation de la DU ou sur reconfiguration, le moteur de cohérence calcule la signature du DF pour les widgets sécurisés et leurs parents et la signature du modèle et vérifie l'égalité des deux signatures. On a ainsi : SignatureDF = f(Eattributs des widgets sécurisés du DF) SignatureMod = f(Eattributs des widgets sécurisés du modèle) 15 Au « run-time », tant qu'aucun événement 'ne vient modifier le modèle, le moteur de cohérence recalcule cycliquement à chaque intervalle de temps At, la signature du modèle et vérifie que SignatureMod à t+At = SignatureMod à t. 20 Sur modification du modèle des widgets suite à une commande ARINC 661 envoyée par une UA, le moteur de cohérence retrouve la commande A661 à partir du changement d'attributs du modèle. On a: Commande A661 = F 1(changement d'attributs du modèle) Il vérifie l'égalité avec la commande A661 reçue. A titre de premier 25 exemple, le widget x de la page y de type « toggle button » ou « interrupteur à bascule » passe de l'état non enfoncé à l'état enfoncé. La fonction F-' (changement d'attributs du modèle) permet de retrouver la commande ARINC 661 intitulée « Enfoncer widget x de la page y ». A titre de second exemple, l'attribut « text » d'un widget x2 « text box » de la page y prend la 30 valeur « ALPHA » permet de retrouver la commande Set text « ALPHA » widget x2 page y. II est à noter que la surveillance d'intégrité du modèle de widget, c'est à dire le calcul et la vérification des signatures telles que décrit ci-dessus, doit être ségréguée de la fonction d'affichage. 35 Ainsi, la sécurisation du modèle des widgets par le moteur de cohérence se fait de la manière suivante : Pour éviter que le modèle soit non cohérent du DF : o Comparaison de la signature du DF avec la signature du modèle à l'initialisation et sur reconfiguration. Pour éviter une modification impromptue du modèle en l'absence de commande : o Comparaison de la signature du modèle entre t et t+At au run-time ; Pour éviter l'exécution d'une commande ne correspondant pas à la commande reçue : o Calcul de la commande ARINC661 sur modification du modèle et comparaison avec la commande reçue.
15 b) Sécurisation de la génération des instructions graphiques II s'agit de garantir la sécurisation de l'affichage d'une donnée critique jusqu'à la sortie du Serveur A661, c'est à dire la génération de la pile de commande graphique en XGL. La solution selon l'invention pour sécuriser la génération des 20 instructions graphiques consiste à faire vérifier cycliquement par le moteur de cohérence pour les widgets sécurisés la conformité de la pile d'instructions graphiques avec le modèle des widgets. Une telle vérification est dépendante du type de widget. A titre d'exemple, un algorithme de vérification de la conformité de la pile d'instructions graphiques avec le modèle des widgets 25 pour les widgets de type « Label » peut être : Pour tous les widgets sécurisés de type « Label », Trouver la commande « XGLWriteText » dans la pile d'instructions graphiques correspondant au widget. Pour cela, on a besoin d'un paramètre "feedback id" dans la commande XGLWriteText sur le 30 modèle de la fonction existante SGLFeedbackVertex ; A partir de la commande XGLWriteText, on remonte la pile jusqu'à la commande XGLSetAttributes précédente .et on compare ses paramètres avec les attributs du modèle pour le widget courant comme, par exemple, les couleurs de police et de fond, la taille de 35 la police de caractères, ... 10 On vérifie la conformité des coordonnées d'affichage. Dans la commande XGL, le système de coordonnées peut être différent du système de coordonnées du modèle. II convient donc d'avoir projeté préalablement dans le modèle pour chaque widget sécurisé leurs coordonnées relatives aux commandes XGL. Un algorithme doit être écrit sur ce modèle pour chaque type de widgets que l'on veut sécuriser. Ainsi, la sécurisation de la génération des instructions graphiques par le moteur de cohérence se fait de la manière suivante : Vérification cyclique de la cohérence de la conformité de la pile d'instructions graphiques générée (XGL) avec le modèle de widget par l'ajout de fonctions de type "feedback id" au langage graphique XGL.
Sécurisation de l'interactivité L'interactivité sur les DU regroupe plusieurs éléments qui sont : a) L'interaction à effet transitoire sur l'unité d'affichage, comprenant le déplacement du curseur, la gestion du focus, c'est-à-dire la zone de widget ou le widget sélectionnable, la surbrillance ou « highlight » des objets traversés par le curseur, l'ouverture d'une « combo-box », le défilement d'une liste ; ... b) L'interaction d'envoi d'une commande par un widget qui, pour les commandes critiques, doit être sécurisée ; c) L'interaction de saisie et d'affichage d'une donnée, qui pour des données critiques, doit être sécurisée.
a) L'interaction à effet transitoire L'interaction à effet transitoire a un retour visuel immédiat vers l'utilisateur qui détecte un éventuel disfonctionnement et peut utiliser un moyen d'interaction secondaire si nécessaire. Par exemple, la non prise en compte de la position du curseur. De plus, ce type d'interaction ne génère pas d'envoi de commandes ou de données vers l'application interactive. Ces deux arguments font que ce type d'interaction n'est pas critique et n'a donc pas besoin d'être sécurisé.35 b) L'interaction d'envoi d'une commande Pour l'interaction d'envoi d'une commande, les widgets critiques sont de type dites « UA Validation ». Ces widgets ont la particularité d'attendre un message de confirmation de l'application cliente avant de changer d'état. Par exemple, un bouton à deux états (enfoncé/non enfoncé) va envoyer sur un événement de click curseur une demande de changement d'état à I'UA qui pilote cette fonction et attendre un message de confirmation de l'UA avant d'effectuer son changement d'état. Si le message de confirmation ne parvient pas au widget avant une durée définie, il revient à son état initial. Ce mécanisme garanti la cohérence entre l'état de l'IHM et l'état de l'UA si on sait garantir le traitement d'une donnée critique entre une UA et une DU, point abordé au chapitre précédent. Ce mécanisme de « UA Validation » est nécessaire mais non suffisant. Il n'empêche pas un déclenchement inopportun d'un widget soit par bug, soit par erreur de l'utilisateur. Pour pallier ce dernier problème, toute commande critique est sécurisée soit par un mécanisme de garde, soit par une boîte de dialogue de confirmation. Un mécanisme de garde est un objet graphique protégeant un widget sécurisé que l'on doit nécessairement déverrouiller avant d'accéder audit widget sécurisé.
II convient ensuite de garantir la garde ou le bouton de confirmation. Pour assurer cette fonction, le moteur de sécurisation envoie à l'UA par le bouton de garde ou de confirmation une signature calculée par une fonction f appliquée par exemple à l'identifiant du widget ou tout autre caractéristique unique au moment ou la garde est levée ou le bouton de confirmation cliqué. On procède de même sur l'interaction du widget associé à la fonction critique. On envoie une signature calculée par la même fonction f, après avoir levé la garde ou avant l'affichage du bouton de confirmation. L'UA décode ensuite les deux signatures et en vérifie la cohérence l'une par rapport à l'autre dans une table d'association des identifiants des widgets critiques et de leurs gardes ou bouton de confirmation respectifs. Il convient également de ségréguer la gestion du bouton et celle de sa garde. A titre d'exemple, la figure 5 est une partie de la représentation graphique de boutons de garde en position verrouillée et déverrouillée dans le cadre de l'affichage des circuits de commande moteur. Sur cette figure, sont représentés les deux réacteurs de l'appareil au centre de la figure, leurs circuits d'alimentation en carburant, des indications de niveau « 6100 » et deux boutons de commande notés « ENG1 » et « ENG2 », permettant d'allumer ou d'éteindre les réacteurs. On comprend bien que ces boutons sont fondamentaux pour la bonne marche de l'appareil. Ces deux boutons sont sécurisés au moyen de gardes représentés par des rectangles en gris sur la figure 5. En position verrouillée, la garde recouvre le bouton comme on le voit à gauche de la figure 5. En position déverrouillée, la garde est en position abaissée et ne recouvre plus le bouton comme on le voit à droite de la figure 5. Pour verrouiller ou déverrouiller, l'utilisateur amène puis clique sur le pointeur représenté par les deux V en gras formant un X sur la figure 5 sur la garde choisie. Ainsi, pour sécuriser l'interaction d'envoi d'une commande critique en ARINC 661 d'une DU vers une UA, le moteur de sécurisation met en 15 oeuvre simultanément les trois moyens suivants : Pour éviter le déclenchement intempestif d'un widget au niveau de l'IHM due à une erreur humaine ; o Utilisation systématique d'un mécanisme de garde ou d'une boîte de dialogue sur la même DU géré par des logiciels ségrégués ; o Association de signatures des widgets critiques avec leurs gardes ou boutons de confirmation et vérification par l'UA des couples de signatures via une table de correspondance ; o Repositionnement automatique de la garde sur le bouton si besoin (après une interaction, après une durée définie,...) ; Pour éviter l'absence de cohérence entre l'IHM et l'UA, c'est-à-dire que des commande ne soient pas prises en compte et ne soient pas exécutées par l'UA : o Utilisation de widgets « UA Validation » uniquement.
Ainsi, le problème consistant à sécuriser l'interaction d'envoi d'une commande critique revient à garantir la cohérence de l'affichage des widgets 35 par rapport à l'état de I'UA. 20 25 30 c) L'interaction de saisie et d'affichage d'une donnée Dans le cas de l'interaction de saisie, l'implémentation actuelle de l'ARINC 661 pour des applications aéronautiques propose une famille de widgets « UA Validation ». La valeur saisie dans un widget de type « Edit box » ou sélectionnée dans un widget de type « Combo box » est vérifiée par l'UA puis renvoyée à la DU pour affichage définitif. L'emploi de telles widgets garantit la cohérence entre l'UA et la DU si on sait garantir le transfert d'une donnée critique entre une UA et une DU, problème déjà traité.
On peut se satisfaire de ce mécanisme et compter sur l'utilisateur pour vérifier que la valeur saisie est bien la valeur prise en compte par I'UA. Toutefois, il est plus sûr de mettre en place via le moteur de sécurisation selon l'invention un système de signature sur la valeur saisie ou sélectionnée depuis la DU selon le type de widget considéré (edit box ou combo box) jusqu'à l'UA. L'UA vérifie alors la cohérence de la signature avec la valeur saisie ou sélectionnée avant de valider et d'envoyer la valeur confirmée à la DU. Le calcul de la signature de la valeur doit se faire au plus près de la saisie et dans une couche logicielle ségréguée. Plusieurs solutions sont envisageables comme par exemple un clavier « intelligent » de type KCCU, acronyme de « Keyboard Cursor Control Unit », capable de mémoriser le résultat d'une saisie et d'en calculer la signature ou encore la transmission d'une signature « touche par touche » pour reconstituer la saisie sur la DU et vérifier la cohérence. Enfin, il est préférable de recourir à l'emploi systématique d'un mécanisme de garde pour protéger l'accès aux widgets de saisie ou bien d'une boîte de dialogue de confirmation, gérés dans les deux cas par une couche logicielle ségréguée, afin d'empêcher toute saisie involontaire. Cette garde ou cette boîte de dialogue doit obéir au mécanisme de contrôle par le moteur de cohérence avec le widget de saisie déjà décrit plus haut.
Ainsi, pour sécuriser l'interaction de saisie ou de sélection d'une valeur critique en ARINC 661 d'une DU vers une UA par l'emploi simultané des quatre moyens suivants : Pour éviter l'envoie intempestif d'une valeur par l'IHM ainsi que 35 pour éviter, après la saisie, l'envoi d'une valeur incorrecte o Utilisation systématique d'un mécanisme bouton de garde ou d'une boîte de dialogue sur la même DU mais géré par une couche logicielle ségréguée ; o Gestion par le moteur de sécurisation d'une association de signatures aux valeurs critiques saisies ou sélectionnées et vérification par l'UA de la cohérence de la signature et de la valeur ; o Gestion par le moteur de sécurisation de la cohérence de la garde ou boîte de dialogue avec le widget de saisie par l'UA. Pour garantir par la cohérence entre l'interface homme-machine et l'UA comme, par exemple, la confirmation de la prise en compte de la valeur saisie : o Utilisation de widgets "UA Validation" uniquement. 15 Ce principe est représenté sur les figures 6, 7 et 8 qui représentent les diagrammes de séquence d'utilisation de boutons de garde ou de boîtes de dialogue dans le cas d'envoi de commandes sécurisées. La figure 6 représente le principe général d'un diagramme de séquence pour 20 une saisie avec garde et les figures 7 et 8 représentent ce même diagramme selon qu'il s'agit d'un bouton gardé ou d'une boîte de dialogue de confirmation.
La figure 6 est organisée en trois colonnes, la première regroupe 25 les tâches effectuées par l'utilisateur ou « USER », la seconde les tâches effectuées par la « DU », la troisième les tâches effectuées par I«< UA ». Les lignes de tâches sont regroupées par ordre logique, les flèches indiquant le sens des actions, les lignes de tâches se succèdent par ordre chronologique. Ainsi, l'utilisateur assure trois tâches, la première « Click guard » consiste à 30 déverrouiller la garde choisie, la seconde « Edit value » consiste à entrer la valeur choisie, la troisième « Monitor Value » enfin consiste à valider la valeur choisie. Le DU transmet les informations reçues et l'UA assure la sécurisation des opérations. 10 Les figures 7 et 8 sont organisées en quatre colonnes, la première regroupe les tâches effectuées par l'utilisateur ou « USER », la seconde et la troisième les tâches effectuées par deux couches de logiciels ségréguées appartenant à la « DU » et notées « DU SW layer 1 » et « DU SW layer 2 », la quatrième les tâches effectuées par I«< UA ». Les lignes de tâches sont regroupées comme précédemment par ordre logique, les flèches indiquant le sens des actions, les lignes de tâches se succèdent par ordre chronologique. L'utilisateur assure comme dans le cas de la figure 6, les tâches de déverrouillage, de sélection et de validation.
Le tableau ci-dessous récapitule les différentes actions du « moteur de sécurisation » selon l'invention réparties entre la DU et l'UA et fonction des différentes phases de traitement du serveur ARINC 661. PHASE Display Unit (D.U.) User Application (U.A.) INITIALISATION Comparaison DF vs Modèle CYCLE DE Comparaison FONCTIONNEMENT signatures modèle entre T et T+AT Vérification cohérence commande XGL critiques et objets du modèle COMMANDE U.A. Feedback sur modification du modèle COMMANDE USER Calcul signature garde Vérification cohérence des signatures Calcul signature widget SAISIE USER Calcul signature garde Vérification cohérence des signatures Calcul signature widget Calcul signature valeur Vérification cohérence des signatures15

Claims (7)

  1. REVENDICATIONS1. Système informatique de type client-serveur pour applications graphiques, c'est-à-dire pour affichage de données sous forme d'unités logicielles appelées «widgets » sur des écrans d'affichage appelés « Display Unit » (DU), chaque widget étant définie par des « attributs », un client étant appelé « User Application » (UA), ledit système contrôlant le fonctionnement d'une machine, la machine comprenant au moins une interface homme-machine permettant d'interagir avec les widgets, ledit système gérant des données ou des fonctions critiques, c'est-à-dire des données ou des fonctions pouvant entraîner un dysfonctionnement grave de ladite machine, les widgets étant réunis dans une structure appelée « modèle » comprenant les propriétés de chaque widget ainsi que leur organisation hiérarchique, ledit modèle étant créé à partir d'un fichier de définition de l'application-client (DF), les widgets assurant l'affichage des fonctions critiques étant appelés « widgets sécurisés », caractérisé en ce que ledit système informatique comporte un moteur de sécurisation comprenant des dispositions de contrôle de l'affichage des widgets sécurisés, la première disposition de contrôle étant constituée par le premier calcul d'une « signature » du modèle des widgets sécurisés, par le second calcul d'une « signature » du fichier de définition des widgets sécurisés et par la comparaison des deux signatures, une signature étant un code mathématique associé aux attributs des widgets sécurisés ; la seconde disposition de contrôle étant constituée par des algorithmes de vérification de la conformité de la pile d'instructions graphiques généré par le serveur avec le modèle des widgets sécurisés, lesdits algorithme étant de type « feedback ».
  2. 2. Système informatique de type client-serveur selon la revendication 1, caractérisé en ce que le moteur de sécurisation comprend au moins une disposition de contrôle des envois de commande et des saisies de l'utilisateur effectués au moyen de l'interface homme-machine sur les widgets sécurisés, ladite disposition étant que les widgets sécurisés sont de type « UA-Validation », c'est-à-dire que, lorsqu'un ordre de changementd'état dudit widget sécurisé est reçu venant de l'interface homme-machine, ledit widget sécurisé attend un message de confirmation du client (UA) avant de changer d'état.
  3. 3. Système informatique de type client-serveur selon l'une des revendications 1 ou 2, caractérisé en ce que le moteur de sécurisation comprend au moins des premières dispositions de contrôle de commande ainsi que de la saisie et de l'affichage de données effectués au moyen de l'interface homme-machine sur les widgets sécurisés, lesdites premières dispositions étant que les widgets sécurisés comportent soit des mécanismes de garde, soit des boîtes de dialogue, un mécanismes de garde est un objet graphique protégeant le widget sécurisé que l'on doit nécessairement déverrouiller avant d'accéder au dit widget sécurisé.
  4. 4. Système informatique de type client-serveur selon la revendication 3, caractérisé en ce que le moteur de sécurisation comprend au moins des secondes dispositions de contrôle de la saisie et de l'affichage de données effectués au moyen de l'interface homme-machine sur les widgets sécurisés, lesdites secondes dispositions assurant la cohérence du verrouillage de la garde ou de la boîte de dialogue avec l'état du widget sécurisé.
  5. 5. Système informatique de type client-serveur selon la revendication 3, caractérisé en ce que le moteur de sécurisation comprend au moins des troisièmes dispositions de contrôle de commande ainsi que de la saisie et de l'affichage de données effectués au moyen de l'interface homme-machine sur les widgets sécurisés, lesdites troisièmes dispositions étant constituées par l'association de signatures des widgets critiques avec leurs gardes ou boutons de confirmation et la vérification par le client (UA) des couples de signatures via une table de correspondance.
  6. 6 Système informatique de type client-serveur selon la revendication 3, caractérisé en ce que le moteur de sécurisation comprend au moins des quatrièmes dispositions de contrôle de la saisie et de l'affichage de données effectués au moyen de l'interface homme-machinesur les widgets sécurisés, lesdites quatrièmes dispositions assurant l'intégrité de la valeur saisie par l'utilisateur par la transmission au client (UA) de la valeur et de sa signature pour vérification de leur cohérence par le client (UA).
  7. 7. Système informatique de type client-serveur selon l'une des revendications précédentes, caractérisé en ce que la machine est un aéronef, le système informatique est l'avionique de bord dudit aéronef et les écrans d'affichage sont les systèmes de visualisation de cockpit et que le système informatique travaille selon la norme aéronautique ARINC 661.
FR1003304A 2010-08-06 2010-08-06 Systeme informatique "client-serveur" securise pour applications interactives Expired - Fee Related FR2963690B1 (fr)

Priority Applications (5)

Application Number Priority Date Filing Date Title
FR1003304A FR2963690B1 (fr) 2010-08-06 2010-08-06 Systeme informatique "client-serveur" securise pour applications interactives
RU2011133131/08A RU2586008C2 (ru) 2010-08-06 2011-08-05 Защищенная компьютерная система с архитектурой "клиент-сервер" для интерактивных приложений
BRPI1103857-8A BRPI1103857A2 (pt) 2010-08-06 2011-08-05 Sistema de computador "cliente servidor" seguro para aplicações interativas
US13/198,931 US8812865B2 (en) 2010-08-06 2011-08-05 Secured client-server computer system for interactive applications
CN201110287539.6A CN102571741B (zh) 2010-08-06 2011-08-08 用于交互式应用的安全“客户端-服务器”计算机系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR1003304A FR2963690B1 (fr) 2010-08-06 2010-08-06 Systeme informatique "client-serveur" securise pour applications interactives

Publications (2)

Publication Number Publication Date
FR2963690A1 true FR2963690A1 (fr) 2012-02-10
FR2963690B1 FR2963690B1 (fr) 2012-08-03

Family

ID=43629204

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1003304A Expired - Fee Related FR2963690B1 (fr) 2010-08-06 2010-08-06 Systeme informatique "client-serveur" securise pour applications interactives

Country Status (5)

Country Link
US (1) US8812865B2 (fr)
CN (1) CN102571741B (fr)
BR (1) BRPI1103857A2 (fr)
FR (1) FR2963690B1 (fr)
RU (1) RU2586008C2 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2765514A1 (fr) 2013-02-08 2014-08-13 Thales Dispositif de sécurisation d'une application client pour un système d'affichage de symbologie du type client-serveur
EP2950049A1 (fr) 2014-05-28 2015-12-02 Airbus Helicopters Procédé contributeur de la sécurisation d'une représentation graphique synthétique de la vue extérieure d'un aéronef

Families Citing this family (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6942826B2 (en) * 2002-11-14 2005-09-13 Dynea Chemicals Oy Spectroscopic monitoring of resin-application prior to assembly of composite wood veneer product
US8766936B2 (en) 2011-03-25 2014-07-01 Honeywell International Inc. Touch screen and method for providing stable touches
US9733707B2 (en) 2012-03-22 2017-08-15 Honeywell International Inc. Touch screen display user interface and method for improving touch interface utility on the same employing a rules-based masking system
US9060010B1 (en) * 2012-04-29 2015-06-16 Rockwell Collins, Inc. Incorporating virtual network computing into a cockpit display system for controlling a non-aircraft system
US9836989B2 (en) 2012-06-05 2017-12-05 Rockwell Collins, Inc. Training data management method and related system
CN104603857B (zh) * 2012-06-05 2018-01-02 罗克韦尔柯林斯公司 训练数据管理方法及相关系统
US9423871B2 (en) 2012-08-07 2016-08-23 Honeywell International Inc. System and method for reducing the effects of inadvertent touch on a touch screen controller
US9128580B2 (en) 2012-12-07 2015-09-08 Honeywell International Inc. System and method for interacting with a touch screen interface utilizing an intelligent stencil mask
CN103905387B (zh) * 2012-12-26 2017-09-12 深圳市赛格导航科技股份有限公司 客户端与服务器通信的方法和装置
US20150111180A1 (en) * 2013-10-23 2015-04-23 Airbus (S.A.S) Methods, systems, and computer readable media for cursor and text entry for aircraft interface simulation
CN114257627A (zh) * 2015-05-28 2022-03-29 罗克韦尔柯林斯公司 生成支持区域、国内和国际无人机系统的基于网络云系统的系统及方法
CN105335158B (zh) * 2015-10-29 2018-08-31 西安电子科技大学 基于arinc661自定义符号库的飞行界面显示方法
US10412100B2 (en) * 2016-08-01 2019-09-10 The Boeing Company System and methods for providing secure data connections in an aviation environment
FR3058290B1 (fr) * 2016-10-27 2019-08-02 Thales Equipement avionique avec signature a usage unique d'un message emis, systeme avionique, procede de transmission et programme d'ordinateur associes
US10496351B2 (en) 2017-06-07 2019-12-03 Ge Aviation Systems Llc Automatic display unit backup during failures of one more display units through the utilization of graphic user interface objects defined for control transfer and reversion after resolution of the failures
US11232218B2 (en) * 2017-07-28 2022-01-25 Koninklijke Philips N.V. Evaluation of a monitoring function
CN107678862B (zh) * 2017-10-10 2021-04-13 中电科航空电子有限公司 一种解决arinc661规范中竞态条件的方法
FR3073966B1 (fr) * 2017-11-21 2019-11-01 Thales Dispositif avionique et procede d'emission d'un message de donnees a destination d'au moins un dispositif electronique recepteur, dispositif electronique recepteur, procede de reception et programme...
CN108132779A (zh) * 2017-12-07 2018-06-08 中国航空工业集团公司西安航空计算技术研究所 一种基于arinc661的可视化df的设计验证方法
FR3087019B1 (fr) * 2018-10-09 2021-06-18 Thales Sa Systeme de controle de commande d'un systeme commande via une interface graphique et procede de controle associe
CN109634498B (zh) * 2018-12-18 2021-08-10 南京航空航天大学 一种基于arinc661的座舱显示系统外部事件高效处理方法
CN110263371B (zh) * 2019-05-13 2020-10-02 北京航空航天大学 基于aadl的ima动态重构过程配置路径生成方法
US10996764B1 (en) * 2019-07-12 2021-05-04 Rockwell Collins, Inc. Systems and methods for automating components with guarded touchscreen controls
FR3110264B1 (fr) * 2020-05-18 2022-04-22 Airbus Operations Sas Architecture d’interfacage homme-machine dans un aeronef

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2884949A1 (fr) * 2005-04-26 2006-10-27 Thales Sa Dispositif de generation graphique comportant des moyens de surveillance de son fonctionnement.
US20080148235A1 (en) * 2006-12-15 2008-06-19 Microsoft Corporation Runtime inspection of user interfaces

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040162895A1 (en) * 2003-02-19 2004-08-19 B2B Booster, Inc. Web site management with electronic storefront and page categorization
US7546543B2 (en) * 2004-06-25 2009-06-09 Apple Inc. Widget authoring and editing environment
US7761800B2 (en) * 2004-06-25 2010-07-20 Apple Inc. Unified interest layer for user interface
FR2901442B1 (fr) * 2006-05-17 2008-08-22 Airbus France Sas Methode de transfert de fichier securise
FR2901946B1 (fr) 2006-06-06 2008-11-21 Thales Sa Procede de codage d'une image numerique couleur comportant une information de marquage
FR2908916B1 (fr) * 2006-11-17 2009-04-17 Thales Sa Systeme de traitement d'objets graphiques comportant un gestionnaire graphique securise
FR2918349B1 (fr) * 2007-07-05 2009-10-02 Airbus France Sa Systeme d'affichage d'applications avioniques et non-avioniques

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2884949A1 (fr) * 2005-04-26 2006-10-27 Thales Sa Dispositif de generation graphique comportant des moyens de surveillance de son fonctionnement.
US20080148235A1 (en) * 2006-12-15 2008-06-19 Microsoft Corporation Runtime inspection of user interfaces

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
DAVID NAVARRE ET AL: "A Formal Approach for User Interaction Reconfiguration of Safety Critical Interactive Systems", 22 September 2008, COMPUTER SAFETY, RELIABILITY, AND SECURITY; [LECTURE NOTES IN COMPUTER SCIENCE], SPRINGER BERLIN HEIDELBERG, BERLIN, HEIDELBERG, PAGE(S) 373 - 386, ISBN: 978-3-540-87697-7, XP019106620 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2765514A1 (fr) 2013-02-08 2014-08-13 Thales Dispositif de sécurisation d'une application client pour un système d'affichage de symbologie du type client-serveur
EP2950049A1 (fr) 2014-05-28 2015-12-02 Airbus Helicopters Procédé contributeur de la sécurisation d'une représentation graphique synthétique de la vue extérieure d'un aéronef
US9489758B2 (en) 2014-05-28 2016-11-08 Airbus Helicopters Method contributing to making safe a synthetic graphics representation of the view outside an aircraft

Also Published As

Publication number Publication date
CN102571741B (zh) 2016-08-03
US20120036445A1 (en) 2012-02-09
RU2586008C2 (ru) 2016-06-10
FR2963690B1 (fr) 2012-08-03
RU2011133131A (ru) 2013-02-10
CN102571741A (zh) 2012-07-11
US8812865B2 (en) 2014-08-19
BRPI1103857A2 (pt) 2014-03-11

Similar Documents

Publication Publication Date Title
FR2963690A1 (fr) Systeme informatique &#34;client-serveur&#34; securise pour applications interactives
US9555544B2 (en) Robotic process automation
FR2983600A1 (fr) Procede et systeme de surveillance d&#39;une interface graphique dans un cockpit d&#39;aeronef
FR3067803A1 (fr) Synchronisation d&#39;un systeme dual avionique et non-avionique
US10467029B1 (en) Predictive graphical user interfaces
US9043810B2 (en) Interfacing between native and web applications utilizing a mobile module
FR2935179A1 (fr) Procede et dispositif d&#39;aide au controle des systemes embarques dans un aeronef
WO2011020954A2 (fr) COMPOSANT LOGICIEL ET DISPOSITIF POUR LE TRAITEMENT AUTOMATISÉ DE DONNÉES MULTI-USAGES, METTANT EN œUVRE DES FONCTIONS AVANT BESOIN DE DIFFÉRENTS NIVEAUX DE SÛRETÉ OU LIMITES DE RESPONSABILITÉ
FR2740884A1 (fr) Interface administrateur pour base de donnees dans un environnement informatique distribue
FR2935186A1 (fr) Procede et dispositif d&#39;aide au diagnostic et a la decision d&#39;exploitation d&#39;un aeronef
FR2950177A1 (fr) Procede et dispositif de gestion d&#39;informations dans un aeronef
US11153321B2 (en) Secure investigations platform
FR2935187A1 (fr) Procede et dispositif de partage de donnees entre des systemes embarques dans un aeronef
EP3637207B1 (fr) Système de génération de commandes d&#39;un système commandé via une interface graphique et procédé associé
US8286087B1 (en) Active route validation in workflow process authoring
US20230205572A1 (en) Secure incident investigation workspace generation and investigation control
US10156957B2 (en) Semi-modal interaction blocker
US10169603B2 (en) Real-time data leakage prevention and reporting
Fayollas et al. Interactive cockpits as critical applications: a model-based and a fault-tolerant approach
US20220108025A1 (en) Testing instrumentation for intrusion remediation actions
CN106648280B (zh) 任务管理交互方法和装置
US20210014300A1 (en) Methods and systems for enhanced component relationships in representations of distributed computing systems
US9736160B2 (en) Protected graphical user interface for role-based application and data access
Zhernova et al. Adaptive Touch Interface: Application for Mobile Internet Security
Magutshwa et al. A Qualitative Risk Identification Framework for Cyber-Physical-Social Systems.

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 7

PLFP Fee payment

Year of fee payment: 8

PLFP Fee payment

Year of fee payment: 9

PLFP Fee payment

Year of fee payment: 10

PLFP Fee payment

Year of fee payment: 11

ST Notification of lapse

Effective date: 20220405