FR2963121A1

FR2963121A1 - Procede et dispositif de protection de commandes logicielles dans un cockpit d'aeronef

Info

Publication number: FR2963121A1
Application number: FR1056007A
Authority: FR
Inventors: Yannick Deleris; Choitat Adrienne Tankeu; Sofyan Su
Original assignee: Airbus Operations SAS
Current assignee: Airbus Operations SAS
Priority date: 2010-07-22
Filing date: 2010-07-22
Publication date: 2012-01-27
Anticipated expiration: 2030-07-22
Also published as: US8897929B2; FR2963121B1; US20120022720A1

Abstract

L'invention a notamment pour objet le contrôle d'exécution de commandes logicielles d'un système informatique dans un cockpit d'aéronef comprenant des moyens pour permettre à un utilisateur d'appeler ces commandes. A ces fins, les moyens permettant d'appeler ces commandes sont initialement verrouillés (500) pour bloquer des appels aux commandes logicielles. Lors de la réception (505) d'une information de déverrouillage de ces moyens, ils sont déverrouillés (520) et les commandes logicielles peuvent être appelées. Les commandes logicielles ne peuvent être appelées (545) via les moyens d'appel que si ces moyens sont dans un état déverrouillé.

Description

La présente invention concerne les interfaces logicielles dans les systèmes informatiques et plus particulièrement un procédé et un dispositif de protection de commandes logicielles dans un cockpit d'aéronef, pour contrôler l'exécution de commandes logicielles à travers un système d'affichage et de contrôle.

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, ils permettent aujourd'hui une interactivité avec l'équipage en permettant, notamment, à des membres d'équipage d'effectuer des opérations de contrôles et de commandes sur les systèmes avioniques à 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é à 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 ControllerArea Network en terminologie anglo-saxonne).

Le système avionique 110 exécute, par exemple, des applications telles que des applications de gestion des moteurs ou des applications de gestion de carburant dont des paramètres peuvent être affichés et/ou modifiés par les membres d'équipage. Ces paramètres peuvent ainsi être transmis 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 le ou la sélectionne et, le cas échéant, la modifie via les moyens de saisie et de sélection 120. Cette valeur modifiée est alors transmise par le CDS au système avionique qui peut alors l'utiliser. 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.

Cependant, certaines des commandes visées par ces actions pouvant avoir des effets particulièrement importants pour la gestion de l'aéronef, il peut être nécessaire de mettre en oeuvre des mécanismes de protections contre des appuis intempestifs des membres de l'équipage comme il en existe aujourd'hui sur les boutons physiques de commande.

En effet, par exemple, les dispositifs de commandes, sur le panneau de plafond des cockpits, dont les actions sont irréversibles ou importantes pour l'opération de l'aéronef sont protégés par un cache coloré appelé garde. Ces protections obligent les membres d'équipage à effectuer au moins deux actions pour réaliser la commande visée (soulever le garde et appuyer sur le bouton).

La figure 2 illustre schématiquement une partie d'un panneau de plafond d'un cockpit d'aéronef comprenant des boutons de commandes de systèmes, dont certains sont pourvus d'un garde. Les gardes sécurisent l'accès à ces boutons et indiquent à l'équipage l'importance de l'action à réaliser. Ainsi, pour appuyer sur un bouton, il est nécessaire, tout d'abord, de soulever le garde. La partie 200 d'un panneau de plafond d'aéronef représentée ici comprend une première zone 205-1 liée à la gestion de l'extinction des incendies des moteurs et une seconde zone 205-2 liée à la gestion des ressources hydrauliques. La première zone comprend notamment un bouton 225 associé à une unité de puissance auxiliaire (APU, sigle d'Auxiliary Power Unit en terminologie anglo-saxonne). Ce bouton étant situé derrière une garde 210, il n'est pas directement accessible et ne peut être manipulé par erreur. La garde 210 comprend, sur un côté, une charnière 215 et, sur un côté opposé, un ergot 220 permettant de la soulever afin d'atteindre le bouton 225 situé dessous pour activer la commande correspondante. En outre, un tel bouton comprend typiquement des moyens d'éclairage pour prévenir le pilote de la commande à sélectionner. Ainsi, typiquement, lorsqu'une alarme incendie visant l'unité de puissance auxiliaire est générée et qu'une fonction d'extinction de cette unité est activée, le bouton 225 situé sous le garde 210 s'illumine. Le pilote peut alors soulever la garde 210 et appuyer sur ce bouton pour couper l'alimentation en carburant de l'unité de puissance auxiliaire et l'arrêter. L'invention permet de résoudre au moins un des problèmes exposés précédemment. Elle a notamment pour objet un procédé et un dispositif de protection contre des sélections intempestives de commandes logicielles, dans un cockpit d'aéronef, accessibles via une interface homme machine (IHM).

L'invention vise en particulier des commandes logicielles accessibles via un écran tactile ou un simple écran combiné à des moyens de saisie et de sélection de type clavier et souris. L'invention a ainsi pour objet un procédé de protection d'au moins une commande logicielle d'un système informatique dans un cockpit d'aéronef, ledit système informatique comprenant des moyens pour permettre à un utilisateur d'appeler ladite au moins une commande logicielle, ce procédé comprenant les étapes suivantes, - verrouillage desdits moyens d'appel de ladite au moins une commande logicielle pour bloquer des appels à ladite au moins une commande logicielle ; - réception d'une information de déverrouillage desdits moyens d'appel de ladite au moins une commande logicielle ; et, - en réponse à ladite réception de ladite information de déverrouillage, déverrouillage desdits moyens d'appel de ladite au moins une commande logicielle, ladite au moins une commande logicielle ne pouvant être appelée via lesdits moyens d'appel de ladite au moins une commande logicielle que si lesdits moyens d'appel de ladite au moins une commande logicielle sont dans un état déverrouillé. Le procédé selon l'invention permet ainsi de proposer une interface de commande logicielle robuste face aux éventuelles erreurs d'interaction de l'équipage utilisant, par exemple, un clavier, une souris ou un écran tactile. Un tel procédé est générique, il peut être mis en oeuvre pour commander tous les systèmes d'un aéronef, en tant que recommandation ou implémentation. De façon avantageuse, le procédé comprend en outre une étape de verrouillage desdits moyens d'appel de ladite au moins une commande logicielle, suite à ladite étape de réception d'une information de déverrouillage, en l'absence d'appel d'une commande logicielle protégée dans un délai prédéterminé. Ainsi, si après avoir déverrouillé les moyens d'appel de ladite au moins une commande logicielle, une commande logicielle protégée quelconque n'est pas appelée dans un temps donné, les moyens d'appel sont automatiquement verrouillé afin d'éviter ultérieurement d'éventuelles erreurs d'interaction de l'équipage utilisant, par exemple, un clavier, une souris ou un écran tactile. Alternativement, le procédé comprend en outre une étape de verrouillage desdits moyens d'appel de ladite au moins une commande logicielle, suite à ladite étape de réception d'une information de déverrouillage, en l'absence d'appel de ladite au moins une commande logicielle dans un délai prédéterminé. Ainsi, si après avoir déverrouillé les moyens d'appel de ladite au moins une commande logicielle, cette dernière n'est pas appelée dans un temps donné, les moyens d'appel sont automatiquement verrouillé afin d'éviter ultérieurement d'éventuelles erreurs d'interaction de l'équipage utilisant, par exemple, un clavier, une souris ou un écran tactile. Le verrouillage est ainsi lié à la commande qui aurait du être appelée.

Selon un mode de réalisation particulier, le procédé comprend en outre une étape de réception d'une information de verrouillage, une étape de verrouillage desdits moyens d'appel de ladite au moins une commande logicielle étant effectuée en réponse à ladite réception de ladite information de verrouillage. Un membre d'équipage peut ainsi contrôler le verrouillage des moyens d'appel de ladite au moins une commande logicielle notamment si, après les avoir déverrouillés, il décide de ne pas appeler cette commande logicielle, afin d'éviter ultérieurement d'éventuelles erreurs d'interaction de l'équipage utilisant, par exemple, un clavier, une souris ou un écran tactile. Toujours selon un mode de réalisation particulier, le procédé comprend en outre une étape de vérification d'au moins une règle prédéterminée, ladite étape de déverrouillage desdits moyens d'appel de ladite au moins une commande logicielle étant effectuée en réponse à ladite étape de vérification. Le procédé permet ainsi de déverrouiller les moyens d'appel de ladite au moins une commande logicielle de façon sélective, par exemple selon la configuration de l'aéronef, un événement particulier, le niveau de criticité de la commande logicielle visée et/ou la phase de vol de l'aéronef. Une telle règle peut notamment être dépendante d'une caractéristique de ladite au moins une commande logicielle et/ou de la configuration d'un dispositif comprenant ledit système informatique. De façon avantageuse, le procédé comprend en outre une étape d'appel de ladite au moins une commande logicielle, ladite étape d'appel étant effectuée suite à l'exécution de ladite étape de déverrouillage desdits moyens d'appel de ladite au moins une commande logicielle et de réception d'une information de sélection desdits moyens d'appel, ladite information de sélection desdits moyens d'appel et ladite information de déverrouillage étant reçues de moyens distincts. Le procédé selon l'invention permet ainsi de fiabiliser l'interface d'appel à des commandes logicielles en utilisant des chemins ségrégés de déverrouillage et d'appel de commandes logicielles. Lesdits moyens d'appel de ladite au moins une commande logicielle comprennent, de préférence, des éléments graphiques représentés sur un écran et des moyens de sélection desdits éléments graphiques.

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 dispositif comprenant des moyens adaptés à la mise en oeuvre de chacune des étapes du procédé décrit précédemment ainsi qu'un aéronef comprenant un tel dispositif. Les avantages procurés par ce programme d'ordinateur, ce dispositif et cet aéronef sont similaires à ceux évoqués précédemment. 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 schématiquement une partie d'un panneau de plafond d'un cockpit d'aéronef comprenant des boutons de commandes de systèmes, dont certains sont pourvus d'un garde ; - la figure 3, comprenant les figures 3a à 3d, illustre schématiquement l'architecture d'une configuration matérielle de contrôle et d'affichage dans un cockpit d'aéronef, conformément à l'invention, selon plusieurs modes de mise en oeuvre d'une fonction de garde ; - la figure 4 illustre schématiquement un plan de vol d'un aéronef et associe une phase de vol à chaque segment du plan du vol ; - la figure 5 illustre certaines étapes d'une fonction de garde pour sécuriser l'accès à des commandes logicielles ; - la figure 6 illustre un exemple d'une zone d'affichage liée à une application de gestion de carburant, comprenant des éléments graphiques actifs et des éléments graphiques passifs ; - la figure 7 représente un exemple de diagramme de séquence pour le verrouillage et le déverrouillage d'un élément graphique ainsi que l'appel d'une commande logicielle correspondante ; et - la figure 8 illustre un exemple d'architecture matérielle adaptée à mettre en oeuvre certaines étapes de l'invention, en particulier des étapes 30 mises en oeuvre par une fonction de garde. Pour protéger des moyens d'appel de commandes logicielles, par exemple des éléments graphiques affichés sur un écran et accessibles via cet écran ou des moyens de saisie et de sélection distincts, dans un environnement sécurisé tel qu'un cockpit d'aéronef, l'invention met en oeuvre une fonction de garde logicielle et des moyens de déverrouillage pouvant être physiques ou logiciels.

La fonction de garde a notamment pour objet de répertorier les éléments graphiques d'appel des commandes logicielles issues d'applications clientes ainsi que de gérer le verrouillage et le déverrouillage de ces éléments graphiques, de préférence selon des règles prédéfinies. Une commande de déverrouillage, appelée ici Unlock CP, peut être utilisée par l'équipage pour informer la fonction de garde de son besoin d'interagir avec des éléments graphiques d'appel de commandes logicielles, c'est-à-dire pour rendre ces éléments graphiques actifs. La fonction de garde peut être intégrée à un système d'affichage, notamment à un système d'affichage de type CDS ou à un système comprenant des applications clientes exécutant les fonctions associées aux commandes logicielles visées ici. Elle peut également être indépendante, répartie dans plusieurs systèmes ou être partiellement indépendante. La figure 3, comprenant les figures 3a, 3b, 3c et 3d, illustre schématiquement l'architecture d'une configuration matérielle de contrôle et d'affichage dans un cockpit d'aéronef, conformément à l'invention, selon plusieurs modes de mise en oeuvre d'une fonction de garde. Comme illustré sur la figure 3a, la configuration matérielle 300 comprend au moins un calculateur 305 hébergeant un serveur de gestion d'affichage d'objets graphiques (CDS) relié à au moins un système avionique 310 comprenant des applications avioniques dites clientes, au moins un écran 315 tel qu'un écran LCD et, notamment si cet écran n'est pas sensitif, des moyens de saisie et de sélection (KCCU) 320 via, par exemple, un bus 325 de type CAN. Le système avionique 310, auquel est ici connecté un bouton « Unlock CP» 335 via une liaison filaire qui peut être discrète 340, comprend, dans ce mode de réalisation, une fonction de garde 330. Comme le système avionique 110 décrit précédemment, le système avionique 310 exécute des applications telles que des applications de gestion des moteurs ou des applications de gestion de carburant. Outre des paramètres de ces applications, des éléments graphiques permettant d'appeler des commandes logicielles associées à ces applications peuvent être transmis au CDS pour être affichés sur l'écran 315.

Cependant, la fonction de garde, mise en oeuvre dans le système avionique 310, désactive (ou verrouille) ces éléments graphiques de telle sorte que leur simple sélection n'appelle pas les commandes logicielles associées si le bouton « Unlock CP » 335 n'a pas été préalablement pressé. De façon avantageuse, le bouton « Unlock CP » 335 doit être pressé dans un délai d'une durée prédéterminée avant la sélection d'un élément graphique pour que cette sélection appelle la commande logicielle associée. Comme illustré sur la figure 3a, la fonction de garde 330 est ici spécifique au système avionique 310. Par conséquent, la fonction de garde 330 n'interagit pas avec d'autres systèmes avioniques (non représentés) connectés au CDS 305. En d'autres termes, la fonction de garde représentée sur la figure 3a vise la protection d'éléments graphiques d'appel de commandes logicielles spécifiques à un système particulier. Selon un second mode de réalisation, illustré sur la figure 3b, la configuration matérielle 300' comprend au moins un calculateur 305 hébergeant un serveur de gestion d'affichage d'objets graphiques relié au moins à un système avionique 310' comprenant des applications avioniques clientes, via une fonction de garde 330', au moins un écran 315 tel qu'un écran LCD et, notamment si cet écran n'est pas sensitif, des moyens de saisie et de sélection 320 via, par exemple, un bus 325 de type CAN. La fonction de garde 330' est ici liée au bouton « Unlock CP» 335 via une liaison, par exemple discrète, 340'. Comme le système avionique 310 décrit précédemment, le système avionique 310' exécute des applications telles que des applications de gestion des moteurs ou des applications de gestion de carburant. A nouveau, outre des paramètres de ces applications, des éléments graphiques permettant d'appeler des commandes logicielles associées à ces applications peuvent être transmis au CDS pour être affichés sur l'écran 315.

Cependant, la fonction de garde, mise en oeuvre entre le système avionique 310' et le CDS 305, verrouille ces éléments graphiques de telle sorte que leur simple sélection n'appelle pas les commandes logicielles associées si le bouton « Unlock CP » 335 n'a pas été préalablement pressé. Le bouton « Unlock CP » 335 doit, de préférence, être pressé dans un délai d'une durée prédéterminée avant la sélection d'un élément graphique pour que cette sélection appelle la commande logicielle associée. Il est noté que la fonction de garde 330' peut ici être spécifique au système avionique 310', commune à certains systèmes avioniques reliés au CDS 305, dont le système avionique 310', ou commune à tous les systèmes avioniques reliés au CDS 305. Selon un troisième mode de réalisation, illustré sur la figure 3c, la configuration matérielle 300" comprend au moins un calculateur 305', hébergeant un serveur de gestion d'affichage d'objets graphiques ainsi qu'une fonction de garde 330", relié à des systèmes avioniques 310-1 à 310-n comprenant des applications avioniques clientes, au moins un écran 315 tel qu'un écran LCD et, notamment si cet écran n'est pas sensitif, des moyens de saisie et de sélection 320 via, par exemple, un bus 325 de type CAN. Les systèmes avioniques 310-1 à 310-n sont ici liés au bouton « Unlock CP» 335 via, par exemple, une liaison discrète 340" et un commutateur 345. Comme les systèmes avioniques 310 et 310' décrits précédemment, les systèmes avioniques 310-1 à 310-n exécutent des applications telles que des applications de gestion des moteurs ou des applications de gestion de carburant. A nouveau, outre des paramètres de ces applications, des éléments graphiques permettant d'appeler des commandes logicielles associées à ces applications peuvent être transmis au CDS pour être affichés sur l'écran 315. Cependant, la fonction de garde 330", mise en oeuvre dans le CDS 305', verrouille ces éléments graphiques de telle sorte que leur simple sélection n'appelle pas les commandes logicielles associées si le bouton « Unlock CP » 335 n'a pas été préalablement pressé. Le bouton « Unlock CP » 335 doit, de préférence, être pressé dans un délai d'une durée prédéterminée avant la sélection d'un élément graphique pour que cette sélection appelle la commande logicielle associée. Il est noté que la fonction de garde 330" est ici commune à tous les systèmes avioniques reliés au CDS 305. Un tel mode de réalisation est particulièrement adapté au cas de l'affichage d'une page contenant des éléments graphiques permettant d'appeler des commandes logicielles de plusieurs systèmes avioniques. En effet, il est plus simple de mettre en oeuvre une seule fonction de garde au niveau du CDS qui centralise toutes les informations que de multiplier ces fonctions.

Bien que plusieurs boutons « Unlock CP » puissent être utilisés, l'utilisation d'un commutateur permet de transmettre l'événement de déverrouillage vers le système correspondant à l'élément graphique sélectionné et, notamment, de réduire la surface occupée par les boutons ainsi que limiter la complexité de connexion de ces boutons.

Selon un quatrième mode de réalisation, illustré sur la figure 3d, la configuration matérielle 300- comprend au moins un calculateur 305", hébergeant un serveur de gestion d'affichage d'objets graphiques ainsi qu'une fonction de verrouillage automatique 350, relié à au moins un système avionique 310" comprenant des applications avioniques clientes et une fonction de verrouillage 355, via une fonction de contrôle 360, au moins un écran 315 tel qu'un écran LCD et, notamment si cet écran n'est pas sensitif, des moyens de saisie et de sélection 320 via, par exemple, un bus 325 de type CAN. Le système avionique 310" est ici lié au bouton « Unlock CP» 335 via, par exemple, la liaison discrète 340.

La fonction de garde est ainsi répartie dans la fonction de verrouillage automatique 350, la fonction de verrouillage 355 et la fonction de contrôle 360. Comme les systèmes avioniques 310, 310' et 310-1 à 310-n décrits précédemment, le système avionique 310" exécute des applications telles que des applications de gestion des moteurs et des applications de gestion de carburant. A nouveau, outre des paramètres de ces applications, des éléments graphiques permettant d'appeler des commandes logicielles associées à ces applications peuvent être transmis au CDS pour être affichés sur l'écran 315. Cependant, la fonction de garde mise en oeuvre à travers la fonction de verrouillage automatique 350, la fonction de verrouillage 355 et la fonction de contrôle 360 verrouille ces éléments graphiques de telle sorte que leur simple sélection n'appelle pas les commandes logicielles associées si le bouton « Unlock CP » 335 n'a pas été préalablement pressé. Le bouton « Unlock CP » 335 doit, de préférence, être pressé dans un délai d'une durée prédéterminée avant la sélection d'un élément graphique pour que cette sélection appelle la commande logicielle associée. Plus précisément, la fonction de verrouillage automatique 350 verrouille ici automatiquement les éléments graphiques affichés après un temps prédéterminé à compter de la pression du bouton « Unlock CP », la fonction de verrouillage 355 verrouille les éléments graphiques devant être affichés et la fonction de contrôle 360 vérifie que le CDS 305" et les applications exécutées par le système avionique 310" transmettent des ordres cohérents. Ainsi, la fonction de garde peut apporter une protection à deux niveaux aux commandes logicielles, selon son mode de mise en oeuvre. Elle peut être associée à un système particulier pour protéger les commandes logicielles associées à ce système ou être associée à tous les systèmes (ou à plusieurs systèmes) pour protéger toutes les commandes logicielles de ces systèmes. De façon avantageuse, la fonction de garde est paramétrable de telles sortes que les commandes logicielles soient accessibles ou non et verrouillées ou non en fonction, par exemple, de la configuration de l'aéronef, sa phase de vol et/ou la criticité du ou des systèmes à protéger. Ce paramétrage est ici réalisé par l'application des règles pouvant être définies pour chaque commande logicielle. En outre, selon la criticité des commandes logicielles pouvant être appelées et/ou des systèmes avioniques considérés, il peut être nécessaire de multiplier les mesures de sécurité en exigeant, par exemple, plusieurs pressions du bouton de déverrouillage. 12

Le niveau de criticité peut notamment être défini selon la norme DO-178B qui fixe le niveau de développement du logiciel et du matériel des systèmes avioniques. Selon cette norme, un niveau A correspond aux systèmes pouvant avoir un problème catastrophique, un niveau B à ceux pouvant avoir un problème dangereux, un niveau C à ceux pouvant avoir un problème majeur, un niveau D à ceux pouvant avoir un problème mineur tandis qu'un niveau E vise ceux sans effet sur la sécurité. Par ailleurs, la phase de vol d'un aéronef est définie selon son plan de vol. La figure 4 illustre schématiquement un plan de vol d'un aéronef et associe une phase de vol à chaque segment du plan du vol. Il est ainsi défini une phase de décollage, une phase de montée, une phase de croisière, une phase de descente, une phase d'approche et une phase d'atterrissage. Pour améliorer la protection des commandes logicielles, il est également possible de multiplier le nombre d'actions à effectuer pour appeler une commande logicielle. Ainsi, par exemple, une commande logicielle ayant un niveau d'impact opérationnel faible peut être appelée dès que l'élément graphique correspondant est sélectionné tandis qu'une commande logicielle ayant un niveau d'impact opérationnel moyen peut être appelée dès que l'élément graphique correspondant est sélectionné après que le bouton « Unlock CP » ait été pressé une fois et une commande logicielle ayant un niveau d'impact opérationnel élevé peut être appelée dès que l'élément graphique correspondant est sélectionné après que le bouton « Unlock CP » ait été pressé deux fois. Le niveau d'impact opérationnel d'une commande logicielle peut être défini selon le niveau de criticité du système avionique associé. A titre d'illustration, le niveau d'impact opérationnel d'une commande logicielle peut être égal à un si le niveau de criticité du système avionique correspondant est égal à E, D ou C, à deux si le niveau de criticité du système avionique correspondant est égal à B et à trois si le niveau de criticité du système avionique correspondant est égal à A. Selon cet exemple, le niveau d'impact opérationnel d'une commande logicielle définie le nombre d'actions devant être exécutées pour lancer la commande logicielle correspondante.

Les règles de déverrouillage d'un élément graphique d'appel d'une commande logicielle peuvent ainsi s'exprimer sous la forme suivante, Déverrouillagej(appel commande i) si (configuration ; phase ; criticité système_i) où la variable j indique le nombre de pression devant être exercée sur le bouton « Unlock CP » durant une période de temps prédéterminée, appel commande _i désigne un élément graphique permettant d'appeler la commande logicielle i, configuration vise une liste d'éléments de l'aéronef et leur état, phase désigne la phase de vol et criticité système_i désigne le niveau de criticité du système devant exécuter la commande i susceptible d'être appelée. Chaque paramètre peut être exprimé sous forme de combinaisons logiques de variables. A titre d'illustration, la règle suivante peut être liée à la commande logicielle d'extinction d'un moteur, Déverrouilla ge_2(extinctionmoteur) si (moteur 1 OU moteur 2 ; montée OU croisière OU descente OU atterrissage ; C OU D) Ainsi, selon cet exemple, un moteur peut être arrêté si deux pressions sont exercées sur le bouton « Unlock CP » durant une période de temps prédéterminée et si au moins un des moteurs moteur 1 et moteur 2 fonctionne normalement, l'aéronef est en phase de montée, croisière, descente ou atterrissage et si le niveau de criticité de l'application faisant appel à cette commande est égal à C ou D. De façon similaire, la règle suivante impose la désactivation du calculateur X pour permettre le déverrouillage des commandes a, b et c, Déverrouillage_ 1(a, b, c) si (NO(calculateur X)) La figure 5 illustre certaines étapes d'une fonction de garde pour sécuriser l'accès à des commandes logicielles. Durant une première étape (étape 500), les éléments graphiques devant être affichés et permettant l'appel de commandes logicielles sont identifiés et verrouillés afin que la sélection de l'un d'eux n'appelle pas la commande logicielle correspondante. Ces éléments graphiques sont, par exemple, des boutons virtuels, devant être affichés sur un écran, de type pushbutton, checkbutton ou togglebutton. Un test est alors effectué pour déterminer si le bouton « Unlock CP » a été pressé (étape 505). Dans la négative, l'algorithme boucle sur lui-même tant qu'il n'y est pas mis fin ou tant qu'une autre page ne doit pas être affichée. Si, au contraire, une pression du bouton « Unlock CP » a été détectée, les éléments graphiques devant être déverrouillés sont identifiés (étape 510). Comme décrit précédemment, cette identification est, de préférence, réalisée selon des règles prédéterminées liées, notamment, à la situation de l'aéronef, sa configuration, sa phase de vol et/ou la criticité du ou des systèmes exécutant la commande logicielle considérée. Ces règles sont ici mémorisées dans la base de données 515. Les éléments graphiques identifiés sont alors déverrouillés de telle sorte qu'ils puissent être sélectionnés et appeler des commandes logicielles (étape 520). Un compte à rebours, définissant une période de temps prédéterminée, est alors lancé (étape 525) et un test est effectué pour détecter la fin du compte à rebours (étape 530). A la fin du compte à rebours, l'algorithme retourne à la première étape pour verrouiller tous les éléments graphiques affichés d'appel de commandes logicielles. Parallèlement, s'il existe un bouton de verrouillage des éléments graphiques d'appel de commandes graphiques (bouton « Lock CP »), un test est effectué pour détecter une pression de ce bouton (étape 535). Un tel bouton permet d'inhiber une pression préalable effectuée sur le bouton « Unlock CP » suite, par exemple, à une erreur d'appréciation, ou si le pilote a fini d'interagir avec des éléments de commandes logicielles et veut volontairement les reverrouiller. Si une pression du bouton de verrouillage des éléments graphiques d'appel de commandes logicielles est détectée, l'algorithme retourne à la première étape pour verrouiller tous les éléments graphiques affichés d'appel de commandes logicielles. Toujours de façon parallèle, un test est effectué pour déterminer si un élément graphique préalablement identifié et déverrouillé est sélectionné (étape 540). Dans l'affirmative, la commande logicielle correspondant à l'élément graphique sélectionné est appelée (étape 545). L'algorithme retourne alors à l'étape précédente pour, le cas échéant, détecter une nouvelle sélection d'un élément graphique identifié et déverrouillé.

Comme décrit précédemment, l'algorithme retourne à la première étape pour verrouiller tous les éléments graphiques affichés d'appel de commandes logicielles à la fin du compte à rebours ou lorsqu'une pression du bouton de verrouillage des éléments graphiques d'appel de commandes graphiques est détectée.

Selon un autre mode de réalisation, illustré sur la figure 5 par la flèche en trait pointillé, le compte à rebours est réinitialisé chaque fois qu'un membre d'équipage sélectionne un élément graphique d'appel de commande logicielle afin de permettre à l'équipage d'enchaîner des séquences d'appels de commandes sans nécessiter de nombreuses pressions du bouton « Unlock CP ». Il est observé ici que la sélection d'éléments graphiques préalablement verrouillée et non déverrouillés n'entraîne aucun appel aux commandes logicielles associées. A titre d'illustration, l'invention peut être mise en oeuvre dans des 20 systèmes interagissant conformément à la norme ARINC 661 (ARINC est une marque) qui peut être utilisée pour gérer des écrans interactifs. La norme ARINC 661 définit ici l'interface entre le CDS et les systèmes avioniques offrant une possibilité d'interaction, via des écrans, aux membres d'équipage. 25 Il est rappelé ici que la norme ARINC 661 permet la mise en oeuvre de fenêtres multiples, selon le même principe qu'un ordinateur domestique. Des zones d'affichage d'un écran, aussi appelées layers en terminologie anglo-saxonne, contiennent des éléments graphiques, aussi appelés widgets en terminologie anglo-saxonne, permettant d'appeler des commandes logicielles 30 d'applications exécutées par des systèmes avioniques. Chaque application est ici responsable de la gestion fonctionnelle de l'interface tandis que le CDS a en charge l'affichage des éléments graphiques, leur représentation et la configuration des zones d'affichage. Typiquement, le CDS notifie un événement externe lié à un élément graphique, tel qu'une sélection, à l'application à laquelle est lié cet élément graphique. De même, une application indique au CDS les mises à jour des paramètres d'éléments graphiques suite à un événement interne (propre à l'application) ainsi que les mises à jour des zones d'affichage. A titre d'illustration, il est considéré ici une application de gestion fonctionnelle d'éléments graphiques d'un système avionique de gestion de carburant. Une zone d'affichage « carburant » comporte ici deux catégories d'éléments graphiques, des éléments graphiques actifs d'appel de commandes logicielles, par exemple de type pushbutton, permettant de modifier l'état de configuration du système de gestion de carburant, typiquement des électrovannes, et des éléments graphiques passifs d'affichage de paramètres du système de gestion de carburant qui ne permettent pas d'interaction avec le système de gestion de carburant (ils permettent au plus de modifier la configuration d'affichage, c'est-à-dire la modification de la configuration du CDS). La figure 6 illustre un exemple d'une zone d'affichage liée à une telle application de gestion de carburant dans laquelle des éléments graphiques actifs sont placés à gauche (référence 600) et des éléments graphiques passifs sont situés à droite (référence 605), de façon distincte. Par ailleurs, il est considéré ici que la fonction de garde utilisée est mise en oeuvre à l'extérieur du CDS et du système de gestion de carburant. Les règles de déverrouillage des éléments graphiques (actifs) sont ici uniquement déterminées selon le niveau d'impact opérationnel associé aux commandes logicielles comme défini dans le tableau 1 présenté en annexe, sans condition. Dans cet exemple, le niveau d'impact opérationnel représente le nombre d'actions devant être effectuées pour déverrouiller un élément graphique, c'est-à-dire le nombre de pressions devant être exercées sur le bouton « Unlock CP » plus un. Durant une première phase, avant de créer la zone d'affichage du système de gestion de carburant, le CDS informe l'application de gestion fonctionnelle d'éléments graphiques du système de gestion de carburant et la fonction de garde de ce prochain affichage, en indiquant la liste des éléments graphiques devant être affichés. Cette application de gestion fonctionnelle d'éléments graphiques du système de gestion de carburant transmet alors une requête à la fonction de garde pour rendre visible les éléments graphiques indiqués. La fonction de garde établie alors la liste de tous les éléments graphiques permettant d'appeler des commandes logicielles, devant être protégés, qui doivent être affichés dans la zone d'affichage. La fonction de garde adresse ensuite au CDS une notification de verrouillage des éléments graphiques ainsi identifiés. Par conséquent, lorsque les éléments graphiques liés à la zone d'affichage liée à l'application de gestion de carburant sont affichés, les éléments graphiques permettant d'appeler des commandes logicielles sont verrouillés, à l'exception de ceux ayant un impact opérationnel de niveau un qui ne demandent qu'une seule action pour appeler la commande logicielle correspondante. Durant une deuxième phase, pour interagir avec les éléments graphiques permettant d'appeler des commandes logicielles ayant un impact opérationnel de niveau deux et plus, les membres d'équipage doivent utiliser le bouton « Unlock CP » pour déverrouiller les éléments graphiques. A la première pression du bouton « Unlock CP », l'évènement de déverrouillage est transmis à la fonction de garde via, par exemple, un lien discret ou un bus de type CAN si le bouton « Unolck CP » est un bouton physique ou un réseau de type AFDX (sigle de Avionics Full DupleX terminologie anglo-saxonne) si le bouton « Unlock CP » est un bouton logiciel.

A la réception de cet évènement, la fonction de garde vérifie les règles de déverrouillage des éléments graphiques d'appel de commandes logicielles et, le cas échéant, déverrouille les éléments graphiques d'appel de commandes logicielles ayant un impact opérationnel de niveau deux. Ainsi, l'appel à ces commandes requiert deux actions, une pression sur le bouton « Unlock CP» et la sélection de l'élément graphique correspondant. Pour les éléments graphiques d'appel de commandes logicielles ayant un impact opérationnel de niveau trois, il est nécessaire d'exercer une seconde pression sur le bouton « Unlock CP », ou une autre action spécifique telle qu'une pression sur un autre bouton spécifique, la sélection d'un élément graphique particulier ou une commande vocale, afin de déverrouiller les éléments graphiques correspondants.

Comme décrit précédemment, les membres d'équipage peuvent interagir avec les éléments graphiques déverrouillés pour appeler des commandes logicielles. Ainsi, durant une troisième phase, lorsqu'un élément graphique déverrouillé est sélectionné, un événement correspondant est transmis à l'application associée pour appeler la commande logicielle visée. De façon parallèle, la fonction de garde surveille les activités de l'équipage (vis-à-vis de la sélection d'éléments graphiques) pour vérifier que les applications reçoivent toujours des trames de commandes. A nouveau, si la fonction de garde constate une inactivité, c'est-à-dire l'absence de réception de trames de commandes durant un temps prédéterminé, elle ordonne le verrouillage des éléments graphiques préalablement déverrouillés. Les membres d'équipage ont également, de préférence, la possibilité de verrouiller manuellement les éléments graphiques d'appel de commandes logicielles à l'aide d'un bouton, physique ou logiciel, dédié. A titre d'illustration, le bouton « Unlock CP » peut, après une ou plusieurs pressions successives, se transformer en bouton « Lock CP ». Ces trois phases sont représentées sur la figure 7 qui illustre un exemple de diagramme de séquence pour le verrouillage et le déverrouillage d'un élément graphique ainsi que l'appel d'une commande logicielle correspondante.

Comme illustré, le diagramme de séquence vise ici les échanges de messages entre un bouton « Unlock CP » 700, un CDS 705, une application 710 permettant l'exécution d'une commande logicielle et une fonction de garde 715. Le diagramme de séquence est décomposé en trois phases, une phase de verrouillage 720 d'éléments graphiques, une phase de déverrouillage 725 d'éléments graphiques et une phase 730 d'appel de commandes logicielles et/ou de verrouillage d'éléments graphiques en fonction d'un délai prédéterminé.

Durant la première phase 720, le CDS 705 adresse à l'application 720 une notification d'affichage (735), par exemple une notification d'affichage d'informations relatives au système de gestion de carburant et d'éléments graphiques permettant d'appeler des commandes logicielles. L'application 710 transmet alors (740) une commande à la fonction de garde 715 pour que ces informations et ces éléments graphiques soient rendus visibles. A la réception de cette commande, l'application de garde 715 analyse (745) le contenu des données devant être affichées pour identifier les éléments graphiques permettant d'appeler des commandes logicielles. Un état de verrouillage est associé à chacun de ces éléments graphiques identifiés. La fonction de garde 715 transmet alors (750) une instruction au CDS 705 d'affichage de ces données en indiquant l'état de verrouillage des éléments graphiques concernés. Durant la deuxième phase 725, après qu'une pression sur le bouton « Unlock CP» 700 ait été détectée et que l'événement ait été transmis (755) à la fonction de garde 715, cette dernière, après vérification selon des règles prédéterminées, adresse (760) au CDS 705 une instruction de déverrouillage des éléments graphiques verrouillés vérifiant les règles. Optionnellement, une notification de déverrouillage peut être transmise (765) par le CDS 705 à la fonction de garde 725. Lorsque des éléments graphiques permettant d'appeler des commandes logicielles sont déverrouillés, ils peuvent être sélectionnés, durant la troisième phase 730. Après la sélection d'un tel élément graphique et la vérification de cohérence de la sélection par la fonction de garde (770), la commande logicielle correspondante est appelée et exécutée par l'application 710 (775). Parallèlement, la fonction de garde 715 surveille (780) l'activité des membres d'équipage vis-à-vis de la sélection d'éléments graphiques déverrouillés. Si aucun élément graphique déverrouillé n'est sélectionné durant une période de temps prédéterminé, la fonction de garde 715 adresse une instruction (785) au CDS 705 pour verrouiller les éléments graphiques permettant d'appeler des commandes logicielles préalablement déverrouillés.

De façon avantageuse, afin d'éviter des transmissions intempestives d'appels de commandes logicielles par un CDS, un appel à une commande logicielle n'est effectif que si une instruction de déverrouillage a été préalablement transmise par une fonction de garde. Cette dernière est donc utilisée pour vérifier la cohérence des instructions et des appels de commandes logicielles. Il est observé ici que si la description précédente vise essentiellement la protection de groupe de commandes logicielles, il est possible, selon le même principe, de protéger individuellement les commandes logicielles. Ainsi, le verrouillage d'un élément graphique après une pression sur un bouton « Unlock CP » peut être effectué si, durant une période de temps prédéterminé, cet élément graphique n'a pas été sélectionné, indépendamment de la sélection d'autres éléments graphiques. Il est également possible de prendre en compte le niveau de criticité des commandes logicielles visées pour décider du verrouillage d'un élément graphique selon la sélection de ce dernier et/ou d'autres éléments graphiques appartenant à un même groupe, c'est-à-dire, par exemple, liés à un même système avionique ou liés de façon fonctionnelle. En outre, si la description précédente vise essentiellement la protection de commandes logicielles pouvant être appelées par la sélection d'un élément graphique sur un écran, le procédé s'applique de façon similaire à d'autres modes de sélection d'appels de commandes logicielles, notamment à l'appel vocal de telles commandes. La figure 8 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 par une fonction de garde. Le dispositif 800 comporte ici un bus de communication 805 auquel sont reliés : - une ou plusieurs unités centrales de traitement ou microprocesseurs 810 (CPU, sigle de Central Processing Unit en terminologie anglo-saxonne) ; 21

- une mémoire morte 815 (ROM, acronyme de Read Only Memory en terminologie anglo-saxonne) pouvant comporter des programmes (prog, prog1 et prog2) nécessaires à la mise en oeuvre de l'invention ; - une mémoire vive ou mémoire cache 820 (RAM, acronyme de Random Access Memory en 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 850 adaptée à transmettre et à recevoir des données.

Le dispositif 800 dispose également, de préférence, des éléments suivants : - une ou plusieurs unités d'affichage 825 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 830 ou d'un autre dispositif de pointage tel qu'un écran tactile ou une télécommande ; - d'un disque dur 835 pouvant comporter les programmes précités ainsi que des informations traitées ou à traiter selon l'invention ; et - d'un lecteur de cartes mémoires 840 adapté à recevoir une carte 20 mémoire 845 et à y lire ou à y écrire des données traitées ou à traiter selon l'invention. Le bus de communication permet la communication et l'interopérabilité entre les différents éléments inclus dans le dispositif 800 ou reliés à lui. La représentation du bus n'est pas limitative et, notamment, l'unité 25 centrale est susceptible de communiquer des instructions à tout élément du dispositif 800 directement ou par l'intermédiaire d'un autre élément du dispositif 800. Le code exécutable de chaque programme permettant au dispositif programmable de mettre en oeuvre les processus selon l'invention, peut être 30 stocké, par exemple, dans le disque dur 835 ou en mémoire morte 815. Selon une variante, la carte mémoire 845 peut contenir des 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 800, est stocké dans le disque dur 835. 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 850, pour être stocké de façon identique à celle décrite précédemment. De manière plus générale, le ou les programmes ainsi que les informations à traiter selon l'invention pourront être chargés dans un des moyens de stockage du dispositif 800 avant d'être exécutés.

L'unité centrale 810 va commander et diriger l'exécution des instructions ou portions de code logiciel du ou des programmes selon l'invention, instructions qui sont stockées dans le disque dur 835 ou dans la mémoire morte 815 ou bien dans les autres éléments de stockage précités. Lors de la mise sous tension, le ou les programmes qui sont stockés dans une mémoire non volatile, par exemple le disque dur 835 ou la mémoire morte 815, sont transférés dans la mémoire vive 820 qui contient alors le code exécutable du ou des programmes selon l'invention, ainsi que des registres pour mémoriser les variables et paramètres nécessaires à la mise en oeuvre de l'invention.

Naturellement, pour satisfaire des besoins spécifiques, une personne compétente dans le domaine de l'invention pourra appliquer des modifications dans la description précédente.

ANNEXE OBJET Niveau d'impact opérationnel Pump 1 OFF 3 Pump 2 OFF 3 Transfert X 2 Transfert Y 2 Transfert Z 2 System A ON 1 System B ON 1 System C On 1 System A OFF 1 System B OFF 1 System C OFF 1 Table 1

Claims

REVENDICATIONS1. Procédé de protection d'au moins une commande logicielle d'un système informatique d'un cockpit d'aéronef, ledit système informatique comprenant des moyens pour permettre à un utilisateur d'appeler ladite au moins une commande logicielle, ce procédé étant caractérisé en ce qu'il comprend les étapes suivantes, - verrouillage (500) desdits moyens d'appel de ladite au moins une commande logicielle pour bloquer des appels à ladite au moins une commande logicielle ; - réception (505) d'une information de déverrouillage desdits moyens d'appel de ladite au moins une commande logicielle ; et - en réponse à ladite réception de ladite information de déverrouillage, déverrouillage (520) desdits moyens d'appel de ladite au moins une commande logicielle, ladite au moins une commande logicielle ne pouvant être appelée (545) via lesdits moyens d'appel de ladite au moins une commande logicielle que si lesdits moyens d'appel de ladite au moins une commande logicielle sont dans un état déverrouillé.
2. Procédé selon la revendication 1 comprenant en outre une étape de verrouillage desdits moyens d'appel de ladite au moins une commande logicielle, suite à ladite étape de réception d'une information de déverrouillage, en l'absence d'appel d'une commande logicielle protégée dans un délai prédéterminé.
3. Procédé selon la revendication 1 comprenant en outre une étape de verrouillage desdits moyens d'appel de ladite au moins une commande logicielle, suite à ladite étape de réception d'une information de déverrouillage, en l'absence d'appel de ladite au moins une commande logicielle dans un délai prédéterminé. 25
4. Procédé selon l'une quelconque des revendications précédentes comprenant en outre une étape de réception (535) d'une information de verrouillage, une étape de verrouillage desdits moyens d'appel de ladite au moins une commande logicielle étant effectuée en réponse à ladite réception de ladite information de verrouillage.
5. Procédé selon l'une quelconque des revendications précédentes comprenant en outre une étape de vérification (510) d'au moins une règle prédéterminée, ladite étape de déverrouillage desdits moyens d'appel de ladite au moins une commande logicielle étant effectuée en réponse à ladite étape de vérification.
6. Procédé selon la revendication 5 selon laquelle ladite au moins une règle est dépendante d'une caractéristique de ladite au moins une commande logicielle et/ou de la configuration d'un dispositif comprenant ledit système informatique.
7. Procédé selon l'une quelconque des revendications précédentes comprenant en outre une étape d'appel (545) de ladite au moins une commande logicielle, ladite étape d'appel étant effectuée suite à l'exécution de ladite étape de déverrouillage desdits moyens d'appel de ladite au moins une commande logicielle et de réception d'une information de sélection desdits moyens d'appel, ladite information de sélection desdits moyens d'appel et ladite information de déverrouillage étant reçues de moyens distincts.
8. Procédé selon l'une quelconque des revendications précédentes, lesdits moyens d'appel de ladite au moins une commande logicielle comprenant des éléments graphiques représentés sur un écran et des moyens de sélection desdits éléments graphiques.
9. Programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé selon l'une quelconque des revendications précédente lorsque ledit programme est exécuté sur un ordinateur.
10. Dispositif comprenant des moyens adaptés à la mise en oeuvre de chacune des étapes du procédé selon l'une quelconque des revendications 1 à 8.
11. Aéronef comprenant le dispositif selon la revendication précédente.