FR3013929A1 - Systeme et procede de gestion de transmission de donnees sur un aeronef. - Google Patents

Abstract

- Système et procédé de gestion de transmission de données sur un aéronef. - Le système (1) de gestion de transmission de données comporte une liaison de transmission de données (4) qui est configurée pour permettre une transmission de données entre un dispositif électronique portable (3) et un système de gestion de vol (2) de l'aéronef, et un module de sécurisation de données (5) qui est configuré pour réaliser automatiquement une surveillance de données à transmettre et pour gérer automatiquement une autorisation de transmission de données entre le système de gestion de vol (2) et le dispositif électronique portable (3), en fonction de ladite surveillance.

Description

La présente invention concerne un système et un procédé de transmission de données sur un aéronef, en particulier sur un avion de transport. Plus précisément, l'invention est destinée à une transmission (ou un échange) de données entre un système de gestion de vol FMS (pour « Flight Management System » en anglais), de type avionique (c'est-à-dire qui est sécurisé de manière à obéir à des contraintes données notamment d'intégrité et de disponibilité), et un dispositif électronique portable, de type monde ouvert (c'est-à-dire non suffisamment sécurisé pour être intégré tel quel dans l'aéronef).

Plus particulièrement, bien que non exclusivement, ce dispositif électronique portable peut être un dispositif de vol électronique de type EFB (« Electronic Flight Bag » en anglais), ou tout autre ordinateur portable ou tablette tactile, permettant notamment de préparer un vol de l'aéronef. On sait qu'un dispositif EFB contient des applications de la compagnie 15 aérienne et/ou des données calculées par la compagnie aérienne qui permettent, lors de la préparation d'un vol ou lors d'un vol, d'entrer des données adéquates dans le système FMS de l'aéronef. Des contraintes de sécurité apparaissent lors de la transmission de données au système FMS, en raison d'exigences de sécurité pesant sur le système FMS, qui 20 est un système électronique sensible de l'aéronef. En particulier, il faut éviter qu'une personne malveillante dans l'aéronef puisse entrer des données comportant des codes corrompus dans le système FMS, ou que des applications défaillantes puissent envoyer des données qui pourraient entraîner un disfonctionnement du système FMS vers ce dernier. 25 Par conséquent, un dispositif EFB usuel n'est pas conçu pour transmettre des données au système FMS. Aussi, pour préparer un vol, l'équipage de l'aéronef recopie les données affichées sur l'écran du dispositif EFB dans le système FMS, via une interface homme/machine de l'aéronef. Un tel chargement de données présente une charge de travail importante 30 pour l'équipage, générant de plus une perte de temps et un risque d'erreur. La présente invention a pour objet de remédier à cet inconvénient. Elle concerne un système de gestion de transmission de données pour un aéronef, qui comporte : - un système de gestion de vol, de type avionique ; et - au moins un dispositif électronique portable, de type monde ouvert. Selon l'invention, ledit système de gestion de transmission de données comporte de plus : - une liaison de transmission de données qui est configurée pour permettre une transmission de données entre le dispositif électronique portable et le système de gestion de vol ; et - un module de sécurisation de données, qui est configuré pour réaliser automatiquement une surveillance de données à transmettre et pour gérer 10 automatiquement une autorisation de transmission de données entre le système de gestion de vol et le dispositif électronique portable, en fonction de ladite surveillance. Ainsi, le système conforme à l'invention est en mesure de transmettre (ou transférer) automatiquement et de façon sécurisée (grâce au module de sécurisation, comme précisé ci-dessous) des données du dispositif électronique portable, en 15 particulier un dispositif EFB tel que précité, vers le système de gestion de vol de l'aéronef. Ceci réduit la charge de travail de l'équipage, permettant ainsi à l'équipage de gagner du temps lors de la préparation de l'aéronef, tout en étant plus efficace (en évitant notamment des erreurs de saisie, ....). De préférence, ledit module de sécurisation de données comprend : 20 - un élément de commutation apte à être commandé, ledit élément de commutation étant configuré pour pouvoir être amené alternativement dans l'une ou l'autre de deux positions différentes, une première position dans laquelle il empêche la transmission de données entre le dispositif électronique portable et le système de gestion de vol via ladite liaison de transmission de données et une seconde position 25 dans laquelle il autorise la transmission de données entre le dispositif électronique portable et le système de gestion de vol via ladite liaison de transmission de données ; et - une unité de surveillance comprenant au moins une application de sécurité, l'application de sécurité étant configurée pour surveiller des données de manière à 30 pouvoir détecter des données incorrectes, ledit élément de commutation étant commandé de manière à être amené dans ladite première position au moins en cas de détection de données incorrectes par ladite application de sécurité.

Dans le cadre de la présente invention, on entend par « données incorrectes » un flux de données incorrect, des données qui ne sont pas attendues (par exemple sur certaines phases de vol) et/ou des données à transmettre après un intervalle de temps trop long suivant une requête correspondante.

Dans un mode de réalisation préféré, le système de gestion de vol comporte un module coeur et un module supplémentaire, l'unité de surveillance étant située sur le même équipement que l'un desdits deux modules coeur et supplémentaire. En outre, avantageusement, le système comporte une entité logicielle de sécurisation, l'entité logicielle de sécurisation comprenant au moins ladite application de sécurité de ladite unité de surveillance et au moins une application de sécurité supplémentaire, et ladite entité logicielle de sécurisation étant située sur le même équipement que l'un desdits deux modules coeur et supplémentaire. De préférence, l'unité de surveillance comprend : - une unité d'acquisition de données ; et - une partition de surveillance. Par ailleurs, dans un mode de réalisation particulier, l'entité logicielle de sécurisation comprend au moins l'une des applications de sécurité suivantes : - une application de détection de flux de données incorrect ; - une application de vérification de cohérence et de format de données ; - une application de vérification d'entrées ; et - une application de décryptage de données. En outre, avantageusement, le module supplémentaire comprend une première entité logicielle dans laquelle sont implémentées des applications supplémentaires principales et une seconde entité logicielle dans laquelle est implémentée au moins une application supplémentaire auxiliaire, et ledit système comporte une interface d'échange de données entre l'entité logicielle de sécurisation et l'une desdites première et seconde entités logicielles. Par ailleurs, de façon avantageuse, ledit élément de commutation est de l'un des types suivants : - de type matériel ; - de type logiciel.

La présente invention concerne également un procédé de gestion d'une transmission de données sur un aéronef entre un système de gestion de vol de type avionique et un dispositif électronique portable de type monde ouvert. Selon l'invention, ce procédé comprend une première étape consistant à réaliser automatiquement une surveillance de données à transmettre et une seconde étape consistant à gérer automatiquement, en fonction de ladite surveillance, une autorisation de transmission de données via une liaison de transmission de données entre le système de gestion de vol et le dispositif électronique portable. En outre, avantageusement, la surveillance de la première étape consiste à vérifier si l'une des premières conditions suivantes est remplie : - un flux de données à transmettre est incorrect ; - l'aéronef est dans une phase de vol, pour laquelle les données considérées ne sont pas attendues ; et - un temps supérieur à une valeur de temps prédéterminée s'est écoulé depuis l'émission d'une requête, et si au moins l'une de ces conditions est remplie, la seconde étape consiste à empêcher la transmission de données entre le système de gestion de vol et le dispositif électronique portable. Par ailleurs, de façon avantageuse, la surveillance de la première étape consiste à vérifier également si au moins une seconde condition est remplie et, si cette seconde condition est remplie, la seconde étape consiste à émettre une alerte. En outre, avantageusement, le procédé comporte une étape de présentation de valeurs à un membre d'équipage et de demande de validation, une transmission de données étant uniquement réalisée en cas de validation par un membre 25 d'équipage. Les figures annexées feront bien comprendre comment l'invention peut être réalisée. Sur ces figures, des références identiques désignent des éléments semblables. La figure 1 est le schéma synoptique d'un système de gestion de 30 transmission de données, qui illustre un mode de réalisation de l'invention. La figure 2 est le schéma synoptique d'un mode de réalisation particulier d'un système de gestion de transmission de données comprenant un système de gestion de vol qui est pourvu d'un module coeur et d'un module supplémentaire à double entité. Les figures 3 et 4 montrent schématiquement des moyens du système de la figure 1, utilisés pour la mise en oeuvre, respectivement, de deux exemples différents, avec une indication des différentes actions réalisées. Le système 1 représenté schématiquement sur la figure 1 et permettant d'illustrer l'invention, est notamment destiné à la gestion d'une transmission de données sur un aéronef (non représenté), en particulier un avion de transport, entre un système de gestion de vol 2, de type avionique, et un dispositif électronique portable 3, de type monde ouvert. Ce dispositif électronique portable (nommé « dispositif portable » ci-après) peut notamment être un dispositif de vol électronique de type EFB (« Electronic Flight Bag » en anglais), ou tout autre ordinateur portable ou tablette tactile, permettant en particulier de préparer un vol de l'aéronef.

Selon l'invention, le système 1 comporte, en plus du système de gestion de vol 2 et du dispositif électronique 3 : - une liaison de transmission de données 4 qui est configurée pour permettre une transmission de données entre le dispositif électronique 3 et le système de gestion de vol 2; et - un module de sécurisation de données 5, qui est configuré pour réaliser automatiquement une surveillance de données à transmettre et pour gérer automatiquement une autorisation de transmission de données entre le système de gestion de vol 2 et le dispositif électronique 3, en fonction de ladite surveillance. Le module de sécurisation de données 5 comprend : - un élément de commutation 6 apte à être commandé. Cet élément de commutation 6 est configuré pour pouvoir être amené alternativement dans l'une ou l'autre de deux positions différentes, une première position dans laquelle il empêche la transmission de données électronique entre le dispositif électronique 3 et le système de gestion de vol 2 via ladite liaison de transmission de données 4 et une seconde position dans laquelle il autorise la transmission de données via ladite liaison de transmission de données 4 ; et - une unité (ou module) de surveillance 7 comprenant au moins une application de sécurité Al. Cette application de sécurité Al est configurée pour surveiller des données de manière à pouvoir détecter un flux de données incorrect. Plus généralement, l'unité de surveillance 7 est apte à détecter des données incorrectes, à savoir un flux de données incorrect, des données qui ne sont pas attendues (par exemple sur certaines phases de vol de l'aéronef) et/ou des données à transmettre après un intervalle de temps trop long suivant une requête correspondante. De plus, l'élément de commutation 6 est commandé de manière à être 10 amené dans la première position empêchant la transmission de données entre le dispositif électronique 3 et le système de gestion de vol 2 au moins en cas de détection de données incorrectes. Dans un mode de réalisation préféré, le système 1 comporte une entité logicielle de sécurisation 8. Cette entité logicielle de sécurisation 8 comprend au 15 moins l'application Al de l'unité de surveillance 7, ainsi qu'au moins une application de sécurité supplémentaire, comme précisé ci-dessous. Ainsi, le système 1 est en mesure de transmettre (ou transférer) automatiquement et en toute sécurité (grâce au module de sécurisation de données 5, comme précisé ci-dessous) des données entre le dispositif électronique 3, en 20 particulier un dispositif EFB tel que précité, et le système de gestion de vol 2 de l'aéronef, qui appartiennent à deux mondes bien ségrégués sur l'aéronef. Ceci réduit la charge de travail de l'équipage, et permet ainsi à l'équipage de gagner du temps lors de la préparation de l'aéronef, tout en étant plus efficace (en évitant notamment des erreurs de saisie, ....). 25 Dans un mode de réalisation préféré, la présente invention s'applique à un système de gestion de vol 2 comportant, comme représenté sur la figure 2, un module coeur (ou standard) 10 et un module supplémentaire (ou spécifique) 20. Le module coeur 10 et le module supplémentaire 20 sont hébergés sur le même équipement IMA ou sur deux équipements IMA distincts. Le module 30 supplémentaire 20 comprend deux entités logicielles, une première entité I comprenant les applications supplémentaires principales et une seconde entité II comprenant les applications supplémentaires auxiliaires, comme précisé ci-dessous, les deux entités logicielles I et II étant situées sur le même équipement IMA. De plus, l'entité logicielle de sécurisation 8 est située sur le même équipement que l'un desdits deux modules coeur et supplémentaire. Dans un premier mode de réalisation préféré, le système 1 comprend : - un élément de commutation 6 (matériel ou logiciel) situé, de préférence, à l'extérieur du système de gestion de vol 2 dans un équipement séparé (élément matériel différent), qui permet de bloquer les données avant qu'elles n'arrivent au système de gestion de vol 2 dans le module coeur 10 ou dans le module supplémentaire 20 ; et - l'unité (ou module) de surveillance 7.

Dans une variante moins préférentielle, on peut prévoir un élément de commutation logiciel implémenté dans le module supplémentaire 20. Il est également envisageable d'implémenter l'élément de commutation, de type logiciel, dans le module coeur 10 du système de gestion de vol 2. En outre, l'unité de surveillance 7 comprend : - une fonctionnalité d'acquisition de données ; et - une partition de surveillance 32. La partition de surveillance 32 surveille l'utilisation CPU de la partition sur laquelle l'entité logicielle de sécurisation 8 est hébergée (et détecte une surcharge CPU en cas d'attaque malveillante).

On dispose d'une fonctionnalité qui est hébergée sur une partition qui est distincte des deux partitions du module supplémentaire 20, et située sur le même équipement IMA que les deux entités logicielles du module supplémentaire 20 ou sur un équipement IMA différent. Dans ce dernier cas, on prévoit une communication par liaison AFDX avec les autres équipements IMA. La partition de surveillance 32 a des ressources mémoires et CPU limitées pour réduire son impact sur le module spécifique. Dans une variante préférée de ce premier mode de réalisation, le système 1 comporte l'entité logicielle de sécurisation 8 située sur le même équipement IMA que les deux entités logicielles I et II du module supplémentaire 20. Il est également envisageable que l'entité logicielle de sécurisation 8 soit située sur le même équipement IMA que le module coeur 10. Cette entité logicielle de sécurisation 8 comprend une pluralité d'applications de sécurité.

La liaison entre le dispositif électronique 3 et le système de gestion de vol 2 passe par l'entité logicielle de sécurisation 8, via un bus de type A429 ou Ethernet. Dans le mode de réalisation particulier représenté sur la figure 2, le système 1 comprend une interface d'échange de données 33 entre l'entité logicielle de sécurisation 8 et l'entité logicielle I comprenant les applications supplémentaires principales. Cette interface d'échange de données 33 gère la communication entre les deux entités logicielles 8 et I. Par ailleurs, l'élément de commutation 6 est : - soit un élément de commutation de type matériel. Un tel élément de commutation est, par exemple, un interrupteur (transistor) piloté par l'unité de surveillance 7 et une ou des applications de sécurité qui permet d'isoler les deux équipements ; - soit un élément de commutation de type logiciel. Un tel élément de commutation est un programme qui coupe automatiquement la liaison lorsqu'une condition particulière est détectée, par exemple un flux de données incorrect, un format erroné,...

L'élément de commutation 6 (logiciel ou matériel) permet de couper physiquement l'échange d'informations entre le dispositif électronique 3 et le système de gestion de vol 2. L'élément de commutation 6 est activé suite à la détection de flux de données incorrect, ou sur certaines phases de vol où les données ne sont pas attendues, ou encore après un intervalle de temps trop long suivant une requête de données, comme précisé ci-dessous. L'élément de commutation 6 est piloté par l'unité de surveillance 7. Comme indiqué ci-dessus, dans un mode de réalisation préféré, le système de gestion de vol 2, de type FMS (« Flight Management System » en anglais), présente, comme représenté sur la figure 2, une architecture comprenant : - le module coeur 10 (ou module (ou partie) standard) pour mettre en oeuvre des fonctionnalités génériques relatives à la gestion du vol de l'aéronef ; et - le module supplémentaire 20 (ou module (ou partie) spécifique) pour mettre en oeuvre des fonctions supplémentaires spécifiques. Le module coeur 10 et le module supplémentaire 20 sont liés ensemble par 30 une interface d'échange de données 30. Le module coeur 10 comprend un ensemble 11 d'applications, dites applications génériques. L'exécution de chacune des applications génériques met en oeuvre une fonctionnalité générique relative à la gestion du vol de l'aéronef (par exemple la gestion du plan de vol, la gestion du carburant, ... ). Les fonctionnalités génériques sont, soit des fonctions de base génériques d'un système de gestion de vol, soit des services fonctionnels également génériques d'un système de gestion de vol.

Par ailleurs, le module supplémentaire 20 comprend un ensemble 21 d'applications logicielles supplémentaires principales, et un ensemble 22 d'applications logicielles supplémentaires auxiliaires dont chacune est accessible par une ou plusieurs applications supplémentaires principales. Chacune des applications supplémentaires, principales ou auxiliaires, est spécifique à une entité à laquelle appartient l'aéronef, telle qu'un modèle d'aéronef spécifique, une famille d'aéronefs, une compagnie, une alliance, ou tout ou partie d'une flotte. Une application supplémentaire auxiliaire comprend un ou plusieurs algorithmes de calcul et son exécution ne vise qu'à fournir des résultats de calcul à une ou plusieurs applications supplémentaires principales.

L'exécution de chacune des applications supplémentaires principales met en oeuvre une fonctionnalité supplémentaire du module supplémentaire 20. Les fonctionnalités supplémentaires sont, soit des fonctions nouvelles par rapport aux fonctions du module coeur 10, soit des fonctions alternatives aux fonctions du module coeur 10 auxquelles elles apportent des modifications de comportement, soit encore des services supplémentaires par rapport aux services du module coeur 10 qui utilisent une ou plusieurs de ces fonctions supplémentaires. L'ensemble 21 d'applications supplémentaires principales est implémenté dans la première entité logicielle I et l'ensemble 22 d'applications supplémentaires auxiliaires est implémenté dans la seconde entité logicielle II distincte de la première. Une entité logicielle est une partition logicielle ou un composant logiciel d'une partition logicielle. Un composant logiciel est un ensemble de lignes de code cohérent d'un point de vue fonctionnel ou logique et pouvant partager des ressources communes avec plusieurs autres composants d'une même partition. Une partition logicielle peut héberger plusieurs composants logiciels. De préférence, les applications supplémentaires principales et les applications supplémentaires auxiliaires du module supplémentaire 20 sont mises en oeuvre dans deux partitions logicielles I, II (conformément à ARINC653) hébergées sur un même équipement IMA. Ces deux partitions sont distinctes entre elles et sont distinctes de la partition logicielle portant les fonctionnalités génériques relatives à l'ensemble 11. Le module supplémentaire 20 comprend en outre une interface d'échange de données 60, prévue entre les deux partitions I et II. Le module coeur 10 possède en outre une application générique d'interfaçage 16, qui lorsqu'elle est exécutée, met en oeuvre une fonctionnalité d'interfaçage permettant au module coeur 1 0 de s'interfacer avec des systèmes embarqués 40 de l'aéronef, comprenant au moins une interface homme/machine 41, dite générique. Les systèmes embarqués 40 peuvent également comprendre des dispositifs embarqués 42 tels que ceux couramment installés dans des aéronefs, comme par exemple des instruments de vol, des capteurs,... Les applications supplémentaires principales peuvent, via l'interface d'échange de données 30 générique et via l'application générique d'interfaçage 16, s'interfacer avec l'interface homme/machine 41 générique. Le module supplémentaire 2 0 possède également une fonctionnalité d'interfaçage 26 prévue pour accéder, via l'interface d'échange de données 30, à la fonctionnalité d'interfaçage du module coeur 10 pour pouvoir s'interfacer avec l'interface homme/machine 41 générique. Cette fonctionnalité d'interfaçage 26 du module supplémentaire 20 peut également permettre un interfaçage direct avec l'interface homme/machine 41 générique, ainsi que l'interfaçage avec une interface homme/machine 50 spécifique au module supplémentaire 20. La ou chaque interface homme/machine 41, 50 peut être constituée d'écrans (larges, tactiles, ...), de claviers, de souris, de boules de commande, de systèmes de vision tête haute, de systèmes de réalité augmentée, ..., et permet notamment à l'équipage d'entrer des données. Le module coeur 10 peut comporter, en outre, un ensemble 12 d'éléments, tels qu'une base de données ou une fonctionnalité de maintenance. Grâce à cette structure à deux modules distincts, les fonctionnalités 30 supplémentaires du module supplémentaire 20 sont intégrées au système de gestion de vol 2 sans nécessiter de modification des éléments logiciels du module coeur 10 et n'utilisent de ce dernier, de ce fait, que les fonctions et services fonctionnels qu'il propose (en l'occurrence les fonctionnalités génériques d'un système de gestion de vol). Aussi, ces fonctionnalités supplémentaires peuvent être développées indépendamment du module coeur 10. De plus, l'architecture du module supplémentaire 20 sur deux entités logicielles I et II permet de mettre à jour indépendamment, et à des niveaux logiciels différents, ces deux entités logicielles. Ainsi, des fonctionnalités supplémentaires du module supplémentaire peuvent être modifiées uniquement via la modification des algorithmes des applications supplémentaires auxiliaires. Ceci procure une plus grande souplesse industrielle au module supplémentaire 20. Par ailleurs, dans un exemple de réalisation particulier, l'entité logicielle de sécurisation 8 comprend au moins, les applications de sécurité suivantes comme représenté sur la figure 1 : A/ l'application Al de détection de flux de données incorrect. Dans le premier mode de réalisation du système 1, on utilise une partition dédiée, et on acquiert toutes les données comme elles viennent, en les mémorisant, et on les traite dans l'ordre d'arrivée, si bien que si l'émetteur ne respecte pas un délai imparti entre deux envois, la deuxième donnée n'est pas prise en compte. Ainsi, en cas de « flooding », tout le temps CPU va être utilisé à ces acquisitions, provoquant ainsi une surcharge CPU qui va pouvoir être détectée par la partition de surveillance ; B/ une application A2 de vérification de cohérence et de format des données. Cette application A2 compare un format attendu à un format mesuré, en fonction de la catégorie des données considérées. Même les données de plan de vol et les données de vent/température qui ont un contenu et une taille variables présentent un format et une dimension (« range ») connus et détectables. Le format attendu des données est codé dans le logiciel de l'application, pour éviter qu'une personne malveillante ne puisse contourner la protection. L'application A2 se comporte comme un filtre en rejetant des données qui ne sont pas au bon format ou dans la bonne dimension avant qu'elles ne soient insérées dans le système de gestion de vol 2 ; C/ une application A3 de vérification de la cohérence des données d'entrée entre le début et la fin de la transmission ; et D/ une application A4 de décryptage des données. Elle met en oeuvre une méthode usuelle de calcul d'une valeur (CRC) dépendant de la donnée considérée. L'émetteur et le récepteur appliquent le même algorithme pour calculer cette valeur, et si la donnée est envoyée avec son code CRC, le récepteur est capable de décoder la donnée, recalculer le code CRC et comparer la valeur calculée avec celle reçue de l'émetteur. Le décryptage permet de s'assurer que les données n'ont pas été corrompues pendant le transfert d'informations, mais il ne permet pas de vérifier que les données étaient valides à l'origine.

On décrit ci-après le fonctionnement général du système 1 dans des exemples particuliers relatifs à deux exemples de mise en oeuvre (on entend par un « exemple de mise en oeuvre », une application particulière) : - un premier exemple de mise en oeuvre (ou première application) concernant la transmission de résultats de calculs de performance à basse vitesse, en référence à la figure 3 ; et - un second exemple de mise en oeuvre (ou seconde application) concernant la transmission d'un plan de vol, en référence à la figure 4. Ces exemples, sont présentés sur la base du premier mode de réalisation de l'invention 1 précisé ci-dessus en référence à la figure 1.

L'élément de commutation 6 est un élément de commutation de type matériel, et il est situé à l'extérieur du système de gestion de vol 2. Bien que cela ne soit pas le cas sur l'exemple des figures 3 et 4, dans un mode de réalisation préféré, l'entité 8 est dans une partition séparée avec les applications A2 (pour l'exemple des figures 3 et 4), A3 et A5 (pour l'exemple de la figure 3), en lien avec le module 20 via l'interface 33 comme sur la figure 2. La figure 1 représente l'architecture détaillée pour ces deux exemples de mise en oeuvre, montrant notamment les applications de sécurité utilisées. Il s'agit des applications suivantes : - l'application Al de détection de flux de données incorrect ; - l'application A2 de vérification de cohérence et de format ; - l'application A3 de vérification de la cohérence des données d'entrée entre le début et la fin de la transmission ; et - l'application A4 de décryptage de données. Les applications Al et A2 sont génériques, alors que l'application A3 est 30 dédiée au premier exemple de mise en oeuvre. En outre, l'application A4 de décryptage de données peut s'appliquer aux deux exemples de mise en oeuvre ou à aucun d'eux.

Le premier exemple de mise en oeuvre concerne des calculs de performance à basse vitesse (décollage, atterrissage), qui ne sont actuellement pas pris en compte par le système de gestion de vol. Ces calculs sont effectués par une application de la compagnie aérienne et/ou de l'équipe au sol, qui est hébergée dans le dispositif électronique 3. Ces calculs sont réalisés lors de la préparation du vol, en fonction de paramètres tels que le vent et la masse de l'aéronef, qui sont entrés dans le dispositif électronique 3 par le pilote. Dans la situation usuelle, contrairement à l'invention, les résultats de ces calculs sont ensuite saisis par les pilotes dans le système de gestion de vol, via une interface homme/machine lors de la préparation du vol. Dans ce premier exemple de mise en oeuvre, le dispositif électronique 3 comprend un module de calcul M1 (destiné à réaliser les calculs de performance à basse vitesse). L'application A3 a pour fonction de comparer les données envoyées audit module de calcul M1 du dispositif électronique 3 avec ces mêmes données renvoyées par le module de calcul M1 après calcul, pour s'assurer que les données n'ont pas été corrompues entre le système de gestion de vol 2 et le dispositif électronique 3 et que le calcul a bien été fait avec les bonnes données. Le module supplémentaire 20 comprend, en outre, une application A5 de calcul, précisée ci-dessous qui est une application supplémentaire auxiliaire. Une requête (message sur port RAM ou partage de mémoire) lancée par une application principale A6 relative à l'interface homme/machine s'adresse à la fois à l'application A5 et au module M1. L'interface homme/machine sur laquelle est effectuée la validation est soit l'interface homme/machine 50 spécifique, soit l'interface homme/machine 41 générique (dont on a représenté une page P à titre d'illustration sur la figure 1). Dans ce premier exemple de mise en oeuvre, les calculs sont effectués dans le module supplémentaire 20 et dans le dispositif électronique 3 (qui est considéré comme un calculateur externe). Les données à transmettre sont les résultats des calculs du module M1 du dispositif électronique 3. Ces données comprennent des données de décollage et des données d'atterrissage. Plus précisément, les données de décollage comprennent : - des données à charger dans le système de gestion de vol 2 (vitesse de décollage, configuration moteurs, configuration aérodynamique, accélération, altitude) ; - des résultats secondaires d'informations de l'équipage, à savoir des données complémentaires fournies par le module M1 et non utilisées par le système de gestion de vol 2. Ces données peuvent être affichées notamment sur l'interface homme/machine 50 spécifique ; et - des entrées de calcul pour une vérification. En outre, les données d'atterrissage comprennent : - des résultats devant être chargés dans le système de gestion de vol 2 (vitesse d'approche, configuration aérodynamique) ; - des résultats secondaires d'informations de l'équipage ; et - des entrées de calcul pour une vérification. Généralement, ces données sont transmises : - deux à quatre fois pendant la préparation du vol (données de décollage, et données d'atterrissage éventuellement) ; et - une à deux fois pendant le vol (données d'atterrissage). L'unité (ou le module) de surveillance 7 active l'élément de commutation 6 (pour autoriser la transmission de données) sur réception d'une requête de calcul de l'équipage, via l'interface homme/machine 50 spécifique, et transmet la requête au module M1 dans le dispositif électronique 3. L'élément de commutation 7 reste activé pendant une durée donnée, ou bien tant que la réponse à la requête n'a pas été reçue et que l'aéronef n'est pas en vol (sauf pour les données d'atterrissage). De même, l'unité de surveillance 7 peut bloquer la transmission en commandant l'élément de commutation 6, s'il détecte un format de données incorrect ou un flux de données anormal par rapport à ce qui est attendu. L'application A5 met en oeuvre un algorithme de calcul simplifié, permettant de vérifier la cohérence du calcul fourni par le module Ml. Ce calcul est moins précis que le calcul du module Ml, mais il sert uniquement à la génération d'une alerte en cas de différence importante.

En outre : - l'application A2 vérifie le volume et le format des données par rapport à ce qui est attendu (entier, caractère,...) ; et - l'application Al surveille le débit (taux d'utilisation de la CPU).

Le premier exemple de mise en oeuvre (ou première application) peut présenter, dans un mode de mise en oeuvre particulier, les étapes El à E10 successives suivantes, comme représenté sur la figure 3 : El/ l'équipage utilise l'interface homme/machine 41 standard (associée à une application A7), comme illustré par un doigt 34 agissant sur un élément d'interface 35, pour demander à l'application A6 du module spécifique 20 d'afficher la page P1 spécifique correspondante ; E2/ la page P1 est affichée sur l'interface homme/machine 50 spécifique ; E3/ l'équipage vérifie et ajuste si nécessaire les données qui vont être utilisées pour le calcul, et il déclenche le calcul sur l'interface homme/machine 50 spécifique ; E4/ l'application A6 émet une requête vers le module de calcul M1 hébergé dans le dispositif électronique 3 et ferme l'élément de commutation (ou demande à l'unité de surveillance 7 de le fermer). Cette requête contient l'ensemble des données, revues et ajustées éventuellement par l'équipage, qui sont nécessaires pour le calcul. Le module de calcul M1 dans le dispositif électronique 3 réceptionne ces données et réalise (de façon usuelle) les calculs correspondants de performance à basse vitesse ; E5/ les résultats des calculs, ainsi que les données d'entrée, sont envoyés vers l'application A6 via l'élément de commutation et l'unité de surveillance 7.

Dans ce cas, si l'une des conditions suivantes est remplie, l'unité de surveillance 7 rejette les données ou commande l'élément de commutation pour bloquer la transmission. Un message peut être prévu en retour vers le dispositif électronique 3 pour redemander un envoi. Ces conditions sont : - aucune réponse n'est reçue dans un temps imparti ; ou - l'aéronef décolle (pour les données de décollage uniquement) ; ou - le format/dimension ou le flux des données n'est pas conforme à ce qui est attendu. De plus : - si le format/volume ou le flux est correct, mais que les données d'entrée renvoyées 30 par le module M1 ne correspondent pas à celles qui ont été envoyées avec la requête, une alerte est émise pour indiquer à l'équipage que les résultats ne correspondent pas forcément à ce qui est attendu, en raison d'une erreur de transmission ; et - si les résultats ne sont pas cohérents avec des calculs réalisés par l'application A5, une alerte est également émise pour prévenir l'équipage ; E6/ les résultats sont affichés sur une page P2 sur l'interface homme/machine 50 spécifique pour une validation par le pilote ; E7/ le pilote utilise l'interface homme/machine 50 spécifique pour demander d'envoyer les valeurs une fois qu'elles sont validées vers le système de gestion de vol 2 ; E8/ les valeurs sont prises en compte par une application A8 de plan de vol ; E9/ les nouvelles données sont affichées sur une page P3 sur l'interface 10 homme/machine 41 standard ; et E10/ le pilote confirme les nouvelles données à l'aide de l'interface homme/machine 41 standard. Cette étape El 0 est facultative. Par ailleurs, le second exemple de mise en oeuvre (ou seconde application) concerne la transmission d'un plan de vol. Il est relatif à un plan de vol calculé CFP 15 (pour « Computerized Flight Plan » en anglais). Dans ce second exemple de mise en oeuvre, le dispositif électronique 3 est considéré comme une base de données. De façon usuelle, la compagnie aérienne fournit le plan de vol au pilote et/ou à l'équipe au sol qui prépare l'aéronef avant le vol. Le plan de vol est chargé dans le 20 dispositif électronique 3 (via une disquette, une clé USB ou par wifi par exemple) avant le vol, puis il est entré lors de la préparation du vol dans le système de gestion de vol via une interface homme/machine (contrairement à la présente invention). Aucun calcul n'est réalisé, car l'ensemble des données est enregistré dans une mémoire M2 du dispositif électronique 3. 25 Dans ce second mode de mise en oeuvre, les données à transmettre sont notamment les données suivantes contenues dans le dispositif électronique 3 : - les données initiales du vol (aéroport de départ, numéro de vol, date, heure de décollage estimé) ; - la planification du carburant et de la masse de l'aéronef ; 30 - le plan de vol (comprenant une séquence de procédures, de couloirs, de points de passage,...) ; et - le vent et la température le long du plan de vol.

Généralement, ces données sont entrées une à deux fois lors de la préparation du vol. Ce second exemple de mise en oeuvre peut présenter, dans un mode de mise en oeuvre particulier, les étapes F1 à F9 successives suivantes, comme représenté sur la figure 4 : F1/ un opérateur de la compagnie aérienne ou un membre de l'équipage de l'aéronef entre au moins certaines des données précitées dans le dispositif électronique 3 durant la préparation du vol ; F2/ un membre d'équipage utilise l'interface homme/machine 41 standard (page P4) 10 pour demander à une application A9 (de chargement de plan de vol calculé CFP) du module supplémentaire 20 du système de gestion de vol 2 d'envoyer une requête vers le dispositif électronique 3 ; F3/ l'application A9 émet une requête simple vers le dispositif électronique 3 et ferme l'élément de commutation pour autoriser la transmission (ou demande à l'unité de 15 surveillance 7 de le fermer) ; F4/ le dispositif électronique 3 envoie les données de la mémoire M2 vers l'application A9, via l'élément de commutation et l'unité de surveillance 7. Dans ce cas, si l'une des conditions suivantes est remplie, l'unité de surveillance 7 rejette les données ou commande l'élément de commutation pour bloquer la 20 transmission. Un message peut être prévu en retour vers le dispositif électronique 3 pour redemander un envoi. Ces conditions sont : - aucune réponse n'est reçue dans un temps imparti ; ou - l'avion décolle ; ou 25 - le format/dimension ou le flux des données n'est pas conforme à ce qui est attendu. F5/ les résultats sont affichés sur l'interface homme/machine 50 spécifique (page P5) pour une validation par le pilote ; F6/ le pilote décide d'envoyer les valeurs une fois validées vers le système de gestion de vol 2 pour leur prise en compte et leur affichage dans la partie standard ; 30 F7/ les valeurs sont transmises à l'application A8 de plan de vol pour leur intégration dans un plan de vol secondaire par exemple ; F8/ les données du plan de vol secondaire sont affichées sur l'interface homme/machine 41 standard (page P6) ; et F9/ le pilote confirme les nouvelles données à l'aide de cette interface homme/machine 41 standard de manière à activer le plan de vol secondaire. Par ailleurs, dans une variante de réalisation, les applications A2, A3 et A4 notamment peuvent faire du module supplémentaire 20 ou du module coeur 10, à la place de l'entité 8. En outre, dans une variante de réalisation particulière, un interrupteur manuel est implémenté sur la liaison entre le système de gestion de vol 2 et le dispositif électronique 3, afin que le(s) pilote(s) puisse(nt) couper la liaison manuellement sur détection d'une condition particulière.

Par ailleurs, dans un second mode de réalisation de l'invention, le système 1 comporte : - un élément de commutation situé, de préférence, à l'extérieur du système de gestion de vol dans un équipement séparé, qui permet de bloquer les données avant qu'elles n'arrivent au module spécifique, ou bien, dans une variante moins préférentielle, un élément de commutation logiciel implémenté dans la partie spécifique ; et - une unité (ou module) de surveillance, comprenant au moins l'application de détection de flux de données incorrect (à savoir une application supplémentaire principale). Cette application est hébergée dans l'entité logicielle de sécurisation, si le système comprend une telle entité logicielle de sécurisation, et elle a pour fonction de limiter la profondeur d'acquisition des données et d'en maîtriser le flux de manière à ignorer des données qui ne correspondent pas au flux attendu. Dans une variante particulière de ce second mode de réalisation, le système 1 comporte, de plus, une entité logicielle de sécurisation. Cette entité logicielle de sécurisation comprend une pluralité d'applications de sécurité telles que précitées, qui sont des applications supplémentaires principales de l'entité logicielle I. Par ailleurs, dans ce second mode de réalisation du système 1, concernant l'application de détection de flux de données incorrect, située sur la même partition que les autres fonctionnalités du système de gestion de vol 2, on limite, au niveau de l'application, la profondeur des ports de réception à 1 et on maîtrise la période d'acquisition des données. Cela a pour effet d'ignorer des données trop fréquentes, en ne consacrant qu'un temps limité aux acquisitions.

Le système 1, tel que décrit ci-dessus, présente notamment les avantages indiqués ci-après. L'entité logicielle de sécurisation 8 est implémentée dans une entité logicielle différente des deux autres entités logicielles I et II du module supplémentaire 20, avec des ressources CPU/mémoire restreintes et surveillées, afin de n'avoir aucune incidence sur leurs fonctions. Ainsi, la ségrégation des applications de sécurité des autres applications du système de gestion de vol 2 protège efficacement le système de gestion de vol 2 contre l'introduction d'un code malveillant dans ledit système de gestion de vol 2 ou l'introduction de données incorrectes.

Une transmission de flux de données peut-être bloquée en amont du système de gestion de vol 2 (par l'élément de commutation 6), si l'application Al de détection de flux de données incorrect détecte un problème ou si l'unité de surveillance 7 détecte une suractivité de partitions. Dans l'entité logicielle de sécurisation 8, les autres applications de sécurité permettent de bloquer la transmission vers le module spécifique 20 de données incorrectes, c'est-à-dire invalides ou non cohérentes (fonctionnellement). Ceci concerne une partie seulement de ces données, l'autre partie étant détectée lors de la validation par le pilote. Le système 1 permet d'éviter un « flooding » ou de couper la liaison, lorsqu'aucune transmission de données n'est prévue, ce qui permet de prémunir le système de gestion de vol 2 de toute attaque ou transfert de données non désiré. En effet, la liaison pour la transmission de données entre le dispositif électronique 3 et le système de gestion de vol 2 est disponible uniquement lorsque cela est nécessaire, et elle est indisponible pour le reste du temps, afin d'éviter des transmissions de données indésirables vers le système de gestion de vol 2 pendant le vol. Par ailleurs, l'élément de commutation 6 permet d'autoriser la transmission de données pendant un court laps de temps. Il permet : - de bloquer la transmission de données après ce court laps de temps ou lorsque la réponse attendue du dispositif électronique 3 a été reçue (les données ne peuvent 30 plus être transmises, et ne sont pas encore en mémoire tampon) ; et - de bloquer la transmission en cas de réception de trame incorrecte en provenance du dispositif électronique 3 ou lorsque l'unité de surveillance détecte un usage CPU anormal (ce qui peut correspondre à la réception d'une grande quantité inattendue de données). La liaison entre le dispositif électronique 3 et le système de gestion de vol 2 est réalisée via l'entité logicielle de sécurisation 8 qui agit comme une zone tampon.

Claims (12)

1. REVENDICATIONS1. Système de gestion de transmission de données pour un aéronef, ledit système (1) comportant : - un système de gestion de vol (2), de type avionique ; et - au moins un dispositif électronique portable (3), de type monde ouvert, caractérisé en ce qu'il comporte de plus : - une liaison de transmission de données (4) qui est configurée pour permettre une transmission de données entre le dispositif électronique portable (3) et le système de gestion de vol (2) ; et - un module de sécurisation de données (5), qui est configuré pour réaliser automatiquement une surveillance de données à transmettre et pour gérer automatiquement une autorisation de transmission de données entre le système de gestion de vol (2) et le dispositif électronique portable (3), en fonction de ladite surveillance.
2. 2. Système selon la revendication 1, caractérisé en ce que ledit module de sécurisation de données (5) comprend : - un élément de commutation (6) apte à être commandé, ledit élément de commutation (6) étant configuré pour pouvoir être amené alternativement dans l'une ou l'autre de deux positions différentes, une première position dans laquelle il empêche la transmission de données entre le dispositif électronique portable (3) et le système de gestion de vol (2) via ladite liaison de transmission de données (4) et une seconde position dans laquelle il autorise la transmission de données entre le dispositif électronique portable (3) et le système de gestion de vol (2) via ladite liaison de transmission de données (4) ; et - une unité de surveillance (7) comprenant au moins une application de sécurité (A1), l'application de sécurité (A1) étant configurée pour surveiller des données de manière à pouvoir détecter des données incorrectes, ledit élément de commutation (6) étant commandé de manière à être amené dans ladite première position au moins en cas de détection de données incorrectes par ladite application de sécurité (A1).
3. 3. Système selon la revendication 2,caractérisé en ce que le système de gestion de vol (2) comporte un module coeur (10) et un module supplémentaire (20), l'unité de surveillance (7) étant située sur le même équipement que l'un desdits deux modules coeur et supplémentaire (10, 20).
4. 4. Système selon la revendication 3, caractérisé en ce qu'il comporte une entité logicielle de sécurisation (8), l'entité logicielle de sécurisation (8) comprenant au moins ladite application de sécurité (A1) de ladite unité de surveillance (7) et au moins une application de sécurité supplémentaire (A2 à A4), et ladite entité logicielle de sécurisation (8) étant située sur le même équipement que l'un desdits deux modules coeur et supplémentaire (10, 20).
5. 5. Système selon la revendication 4, caractérisé en ce que l'entité logicielle de sécurisation (8) comprend au moins l'une des applications de sécurité suivantes : - une application (A1) de détection de flux de données incorrect ; - une application (A2) de vérification de cohérence et de format de données ; - une application (A3) de vérification d'entrées ; et - une application (A4) de décryptage de données.
6. 6. Système selon l'une des revendications 4 et 5, caractérisé en ce que le module supplémentaire (20) comprend une première entité logicielle (I) dans laquelle sont implémentées des applications supplémentaires principales et une seconde entité logicielle (II) dans laquelle est implémentée au moins une application supplémentaire auxiliaire, et en ce que ledit système (1) comporte une interface d'échange de données (33) entre l'entité logicielle de sécurisation (8) et l'une desdites première et seconde entités logicielles (I, II).
7. 7. Système selon l'une quelconque des revendications 2 à 6, caractérisé en ce que l'unité de surveillance (7) comprend : - une unité d'acquisition de données ; et - une partition de surveillance (32).
8. 8. Système selon l'une quelconque des revendications précédentes, caractérisé en ce que ledit élément de commutation (6) est de l'un des types suivants : - de type matériel ; - de type logiciel.
9. 9. Procédé de gestion d'une transmission de données sur un aéronef entre un système de gestion de vol (2) de type avionique et un dispositif électronique portable (3) de type monde ouvert, caractérisé en ce qu'il comprend une première étape consistant à réaliser automatiquement une surveillance de données à transmettre et une seconde étape consistant à gérer automatiquement, en fonction de ladite surveillance, une autorisation de transmission de données via une liaison de transmission de données (4) entre le système de gestion de vol (2) et le dispositif électronique portable (3).
10. 10. Procédé selon la revendication 9, caractérisé en ce que la surveillance de la première étape consiste à vérifier si l'une des premières conditions suivantes est remplie : - un flux de données à transmettre est incorrect ; - l'aéronef est dans une phase de vol, pour laquelle les données considérées ne sont pas attendues ; et - un temps supérieur à une valeur de temps prédéterminée s'est écoulé depuis l'émission d'une requête, et si au moins l'une de ces conditions est remplie, la seconde étape consiste à empêcher la transmission de données entre le système de gestion de vol (2) et le dispositif électronique portable (3).
11. 11. Procédé selon l'une des revendications 9 et 10, caractérisé en ce que la surveillance de la première étape consiste à vérifier également si au moins une seconde condition est remplie et, si cette seconde condition est remplie, la seconde étape consiste à émettre une alerte.
12. 12. Procédé selon l'une quelconque des revendications 9 à 11, caractérisé en ce qu'il comporte une étape de présentation de valeurs à un membre d'équipage et de demande de validation, une transmission de données étant uniquement réalisée en cas de validation par un membre d'équipage.