FR2970364A1

FR2970364A1 - Dispositif pour le partage de donnees entre un systeme de gestion du vol et un systeme d'aide au roulage d'un aeronef

Info

Publication number: FR2970364A1
Application number: FR1100053A
Authority: FR
Inventors: Jean Arnaud Causse; Pierre Gamet; Sylvain Yan
Original assignee: Thales SA
Current assignee: Thales SA
Priority date: 2011-01-07
Filing date: 2011-01-07
Publication date: 2012-07-13
Anticipated expiration: 2031-01-07
Also published as: FR2970364B1

Abstract

L'invention concerne un dispositif pour le partage de données entre un système de gestion du vol 201 et un système d'aide au roulage 202 d'un aéronef. Lesdites données sont stockées sur un serveur de données 203 comportant des moyens pour notifier au système de gestion du vol et au système d'aide au roulage des modifications sur les données qu'il stocke. Lesdits systèmes sont associés chacun à une façade respective leur fournissant un accès aux données stockées sur le serveur. Ladite façade comprend des moyens pour la souscription à un abonnement à une modification d'une donnée et des moyens pour filtrer les notifications émises par le serveur de données en fonction des abonnements souscrits, et pour avertir le système auquel elle est associée d'une modification d'une donnée à laquelle elle est abonnée.

Description

Dispositif pour le partage de données entre un système de gestion du vol et un système d'aide au roulage d'un aéronef L'invention concerne le partage de données entre un calculateur de gestion du plan de vol et un calculateur d'aide au roulage à bord d'un aéronef. Les aéronefs modernes embarquent de nombreux calculateurs à leur bord parmi lesquels on peut citer le calculateur de gestion du vol FMS (pour Flight Management System) et le calculateur d'aide au roulage AN (pour Airport Navigation). Le calculateur embarqué de gestion du vol FMS est le calculateur qui détermine la géométrie du profil de vol de l'aéronef, et envoie au pilote ou au pilote automatique des consignes de guidage pour suivre ce profil. Un système de gestion de vol dispose classiquement de fonction de : Navigation pour effectuer la localisation optimale de l'aéronef en fonction des moyens de géolocalisation (GPS, GALILEO, balises radios VHF, centrales inertielles) ; Plan de vol, pour saisir les éléments géographiques constituant le squelette de la route à suivre (procédures de départ et d'arrivée, points de passages (waypoints), airways) ; Base de donnée de navigation pour construire des routes géographiques et des procédures à partir de données incluses dans les bases (points, 20 balises, legs d'interception ou d'altitude...) ; Base de données de performance, contenant les paramètres aérodynamiques et moteurs de l'appareil. - Trajectoire latérale, pour construire une trajectoire continue à partir des points du plan de vol, respectant les performances avion et les contraintes 25 de confinement ; Prédictions, pour construire un profil vertical optimisé sur la trajectoire latérale Guidage, pour guider dans les plans latéraux et verticaux l'aéronef sur sa trajectoire 3D, tout en optimisant la vitesse. 30 Le calculateur d'aide au roulage détermine un plan de roulage qui indique une succession de tronçon de voie de circulation d'un aéroport. Le plan de roulage est parcouru depuis la zone d'embarquement à la piste de décollage lors de la phase de décollage et depuis la piste d'atterrissage à la zone de débarquement des passagers lors de la phase d'atterrissage. Selon l'art connu, les systèmes de gestion du plan de vol et d'aide au roulage sont actuellement totalement indépendantes d'un point de vue informatique. La continuité et la cohérence d'information incombent à l'équipage. Les applications avioniques actuelles embarquent chacune individuellement les données qui lui sont nécessaires. Ces applications ne partagent pas leurs bases de données statiques. Plus encore, celles-ci ne partagent pas non plus des informations non statiques mais pourtant communes. On peut citer à titre d'exemple, les références des aéroports et des pistes de départ ou d'arrivée qui sont des informations communes au plan de vol et au le plan de roulage. Cette séparation des fonctionnalités simplifie la conception des systèmes, mais présente plusieurs inconvénients : la duplication des données entre le plan de vol et le plan de roulage avec des risques d'incohérences, la nécessité pour le pilote d'effectuer une double saisie de ces données communes, un surcroît de travail en cas de modification. De plus, cette séparation ne permet pas d'effectuer des prédictions de consommation de fuel ou d'horaire d'arrivée de bout en bout.

Le système de gestion du vol estime l'heure d'atterrissage en seuil de piste, mais ne peut pas donner l'heure d'arrivée à la porte de débarquement. II existe donc un besoin de partage de données entre le FMS et le AN Une solution consiste à échanger des informations par une liaison réseau directe. Un exemple d'un telle solution est illustré à la figure 1. La figure montre un système de gestion du vol 101 directement relié à un système d'aide au roulage 102. Chacune des flèches indiquent un événement modifiant des données au sein des calculateurs. Les événements sont décrits dans un ordre chronologique. Le premier événement 1 comprend la modification dans le fonction plan de vol du FMS 101 de la destination de l'aéronef. Cette modification entraine automatiquement un changement de la contrainte d'heure d'arrivée au nouvel aéroport (ETA). Les prédictions effectuées par le FMS 101, notamment l'heure d'arrivée au seuil de piste et la consommation en carburant, sont mises à jour.

Le deuxième événement 2 est la transmission vers le système d'aide au roulage 102 des informations modifiées et en particulier : le nouvel aéroport d'arrivée, la piste d'atterrissage prévue, la nouvelle contrainte d'heure d'arrivée et les prédications d'heure et de consommation en carburant mises à jour. Le troisième événement 3 est la prise en compte de ces nouvelles informations par le système d'aide au roulage 102. Le changement d'aéroport d'arrivée implique notamment la mise à jour de la carte d'aéroport affichée et le calcul d'une nouvelle prévision d'heure d'arrivée à la zone de débarquement des passagers. Toutefois, cette solution consistant à échanger des informations par une liaison réseau directe présente des inconvénients. Ces échanges directs restent une solution spécifique et non standard. Les informations échangées intéressent aussi d'autres fonctions de l'avion, en particulier dans de futurs avions aux fonctionnalités avioniques étendues. La solution consistant à développer pour chaque échange des solutions ponctuelles et spécifiques n'est pas techniquement évolutive, ni économiquement rentable. L'analyse des différents scénarii opérationnels mettant en jeu la gestion du vol et la gestion du roulage montre l'utilité qui pourrait être faite d'un meilleur partage d'information évoluant au cours d'un vol. Ces scénarii démontrent l'importance et l'intérêt d'améliorer l'échange de données semistatiques, c'est-à-dire des données pouvant être modifiées au cours du trajet effectué par l'avion. On peut citer à titre d'exemple l'information concernant la piste d'atterrissage. Cette information est nécessaire à la fois dans la gestion du vol et dans la gestion du roulage. Actuellement, le pilote doit saisir distinctement cette donnée dans chacune des deux applications : L'invention vise à pallier les problèmes cités précédemment en proposant un dispositif pour le partage de données entre un système de gestion du vol et un système d'aide au roulage d'un aéronef facilement intégrable à des systèmes existants et gérant des données semi-statiques. A cet effet, l'invention a pour objet un dispositif pour le partage de données entre un système de gestion du vol et un système d'aide au roulage d'un aéronef, lesdites données étant stockées sur au moins un serveur de données embarqué à bord de l'aéronef, lesdites données étant accessibles en écritures et pouvant être modifiées, caractérisé en ce que le serveur comporte des moyens pour notifier au système de gestion du vol et au système d'aide au roulage des modifications sur les données qu'il stocke, et en ce que le système de gestion du vol et le système d'aide au roulage sont associés chacun à une façade respective leur fournissant un accès aux données stockées sur le serveur, ladite façade comprenant : des moyens pour la souscription à un abonnement à une modification d'une donnée, des moyens pour filtrer les notifications émises par le serveur de données en fonction des abonnements souscrits, et pour avertir le système auquel elle est associée d'une modification d'une donnée à laquelle elle est abonnée. Avantageusement, les données stockées sur le serveur de données comprennent : un aéroport de départ, une piste de décollage, un aéroport de destination, une piste d'atterrissage, une liste d'aéroports de destination alternatifs, des prédictions en consommation de carburant, des prédictions d'heure d'arrivée à l'aéroport de destination et des avenants aux informations aéronautiques. L'invention permet de présenter au pilote un service totalement intégré comprenant la gestion d'un plan de vol et d'un plan de roulage de manière continue. Le pilote n'a plus à changer de fonction avion (Gestion du roulage au départ, puis gestion du vol et enfin à nouveau gestion du roulage à l'arrivée) en cours de trajet. La base de données stockant les informations mises en commun entre le système de gestion du vol et le système d'aide au roulage peut être alimentée ou alimenter d'autres fonctions comme les liaisons de données sol bord (connu sous le nom de « datalink ») ou les autres systèmes informatiques de bord qu'ils soient avioniques ou non (dits monde ouvert). L'invention a pour avantage d'être plus adaptée à la modification des systèmes actuels développés de manière totalement indépendante. En effet, l'utilisation d'une façade minimise les modifications à apporter au système de gestion du vol et au système d'aide au roulage. L'échange de données s'effectue au travers d'un troisième acteur, le serveur de données. Ceci permet d'éviter l'intégration des deux fonctions dans un même logiciel qui serait alors trop volumineux et peu efficace.

L'utilisation d'un intermédiaire, la façade, entre les deux applications avioniques permet un couplage souple et rapide avec les applications existantes. Cette caractéristique a pour avantage de minimiser l'interdépendance entre ces applications, diminuant les coûts de modifications et de certification. Ceci permet de faire évoluer les deux applications selon leur propre processus de qualification. L'invention sera mieux comprise et d'autres avantages apparaîtront à la lecture de la description détaillée faite à titre d'exemple non limitatif et à l'aide des figures parmi lesquelles : La figure 1, déjà présentée, illustre une solution de partage de données selon l'art connu. La figure 2 représente un schéma fonctionnelle du dispositif 300 selon l'invention. La figure 3 montre un exemple de données échangées par 15 différents systèmes. La figure 4 présente un premier mode de réalisation du dispositif selon l'invention. La figure 5 présente un second mode de réalisation du dispositif selon l'invention. 20 Le dispositif selon l'invention permet le partage de données, en particulier de données semi-statiques, à bord d'un aéronef par des applications avioniques indépendamment de la localisation du stockage des données et avec des qualités de service étendues telles que la tolérance aux pannes ou la répartition de la charge. 25 L'invention vise à minimiser l'impact des échanges entre les deux fonctions que sont le système de gestion du vol et le système d'aide au roulage en introduisant un acteur intermédiaire : un service d'échange de données. Un tel service d'échange de données est décrit dans la demande de brevet français n°1002893. 30 La solution est basée sur l'utilisation d'un service de base de données avionique. Dans le dispositif d'accès à des données à bord d'un aéronef selon l'invention, les données sont stockées sur des bases de données centralisées hébergées sur au moins un serveur.

Chaque application ou système est associé à une façade qui lui est propre qui lui permet de communiquer avec le serveur où sont stockées les données. L'entité regroupant une application et la façade avec laquelle elle est associée, est appelée client. Chaque client utilise sa façade pour adresser ses requêtes de lectures et d'écriture au serveur. La façade a donc pour rôle d'adresser les requêtes au serveur disposant physiquement de la base de données sollicitée. L'intégration fonctionnelle des fonctions de gestion peut s'effectuer selon deux modes de réalisation : en conservant une indépendance des calculateurs hébergeant la gestion du vol et la gestion du roulage, en hébergeant ces deux applications sur un même calculateur, mais dans des partitions différentes. Dans ces deux modes de réalisation, chacune des applications 15 embarquées comporte une composant façade permettant d'accéder au service de base de données. La figure 2 représente un schéma fonctionnelle du dispositif 300 selon l'invention. Ce dispositif a pour objet le partage de données entre un système de gestion du vol 201 et un système d'aide au roulage 202 d'un 20 aéronef. Les données à partagées sont stockées sur au moins un serveur 203 de données embarqué à bord de l'aéronef. Ces données sont semistatiques, c'est-à-dire accessibles en écritures et pouvant être modifiées. Le serveur 203 comporte des moyens pour notifier au système de gestion du vol 201 et au système d'aide au roulage 202 des modifications sur 25 les données qu'il stocke. Un serveur comprend : un point d'entrée (ou Front End), pour gérer les requêtes émises par les clients, un ensemble (ou Pool) de gestionnaires de requêtes, au moins une base de données et un éditeur (ou « publisher »). Le rôle de l'ensemble de gestionnaires de requêtes est de 30 traiter les requêtes provenant des clients. Le rôle d'un gestionnaire de requête est de traiter une seule requête à la fois. Le point d'entrée comprend une pile pour stocker des requêtes en attente. L'éditeur permet de publier des modifications d'une donnée à destination des clients. L'éditeur contribue à la mise en oeuvre d'un service de publication et d'abonnement aux modifications des données qui permet de notifier aux clients les modifications sur les données. Le système de gestion du vol 201 et le système d'aide au roulage 202 sont associés chacun à une façade respective leur fournissant un accès 5 aux données stockées sur le serveur 203. Une façade comprend : des moyens pour la souscription à un abonnement à une modification d'une donnée, des moyens pour filtrer les notifications émises par le serveur de données 10 en fonction des abonnements souscrits, et pour avertir le système auquel elle est associée d'une modification d'une donnée à laquelle elle est abonnée. Le rôle d'une façade est d'offrir un accès aux données hébergées sur les serveurs à une application embarquée à laquelle elle est associée 15 (par exemple, le système de gestion du vol, le système d'aide au roulage, le module de liaisons de données ou le module monde ouvert - voir ci-après). La connaissance des serveurs à utiliser se trouve dans la façade. Afin de masquer la localisation des bases de données à ces applications embarquées, la façade joue le rôle d'intermédiaire entre l'application et 20 l'accès aux serveurs. Des précisions sur le fonctionnement du serveur de données et des façades peuvent être trouvées dans la demande de brevet citée précédemment. La modification d'une donnée par un client et sa notification aux 25 autres clients se déroule de la façon suivante : Etape 1 : Une application modifie une donnée. Dans l'exemple, il s'agit d'une modification de l'aéroport de destination par le système de gestion du vol 201. Etape 2: La façade associée à l'application ayant modifiée la 30 donnée notifie la modification au serveur hébergeant la donnée. Dans l'exemple, la façade du système de gestion du vol 201 notifie au serveur 203, la modification de l'aéroport de destination. Etape 3 : Le serveur 203 inscrit la modification dans sa base de données et la diffuse vers tous les clients.

Etape 4 : Toutes les façades reçoivent l'information. Seules les façades dont l'application associée est abonnée pour les modifications de cette donnée transmettent l'information à leur application associée. Dans l'exemple, on suppose que le système d'aide au roulage 202 est abonné pour la donnée concernant l'aéroport de destination. La façade du système d'aide au roulage transmet la modification de données à cette application. Etape 5: Chacune des applications abonnées à la donnée modifiée reçoit l'information de modification et la traite. Dans l'exemple, le système d'aide au roulage 202 reçoit l'information concernant la modification ~o de l'aéroport de destination. Ce système 202 modifie en conséquence l'affichage de la carte de l'aéroport de destination. Selon une caractéristique de l'invention, l'aéronef comprend un module de liaisons de données 204 « datalink » permettant de recevoir des informations provenant du contrôle aérien. Le module de liaison de données 15 204 comporte lui aussi une façade permettant audit module d'accéder aux données hébergées par le serveur de données. Selon une caractéristique de l'invention, l'aéronef comprend un module appelé « monde ouvert » 205 hébergeant des applications non avioniques. Le module monde ouvert 205 comporte lui aussi une façade 20 permettant audit module d'accéder aux données hébergées par le serveur de données. La figure 3 montre un exemple de données échangées par différents systèmes. Selon une caractéristique de l'invention, les données partagées entre le système de gestion 201 du vol et le système d'aide au 25 roulage 202 comporte l'aéroport de départ et la piste de décollage, l'aéroport de destination et la piste d'atterrissage, une liste d'aéroports de destination alternatifs comprenant des noms d'aéroports de dégagement en rapport avec l'aéroport de destination, 30 des prédictions en consommation de carburant, des prédictions de temps, notamment d'heure d'arrivée à l'aéroport de destination, des avenants aux informations aéronautiques , avertissant des conditions particulières pouvant affecter l'exploitation aérienne incluant notamment la 35 phase de roulage sur les aéroports et qui sont généralement émises par le contrôle aérien (ou ATC pour « Air Traffic Control ») ou les compagnies aériennes (ou AOC pour « Aldine Operation Center »). Selon l'art connu, ces informations sont dispersées entre différents systèmes avioniques dont le système de gestion du vol 201 et le système 5 d'aide au roulage 202. Les flèches représentent des échanges de données entre les systèmes. Le transfert d'informations depuis le contrôle aérien vers le FMS se fait principalement par liaison de données datalink. Le transfert d'informations depuis le contrôle aérien vers le système d'aide au roulage et 10 les échanges de données entre le FMS et le système d'aide au roulage sont en fait des reports effectués manuellement par le pilote. II n'existe pas d'échange avec les systèmes non avioniques dits « monde ouvert » qui comprennent des fonctions, non critiques. La figure 4 présente un premier mode de réalisation du dispositif 15 selon l'invention. Selon ce mode de réalisation du dispositif de partage de données selon l'invention, le système de gestion du vol 201, le système d'aide au roulage 202 et le serveur de données 203 sont situés chacun sur des calculateurs différents 401, 402, 403. Le serveur peut aussi héberger des bases de données statiques si 20 le besoin apparaît de partager les données de cette base avec d'autres applications ou systèmes avioniques. Dans cet exemple, la base de navigation Nav et le plan de vol FLPN sont hébergés sur le serveur de données 203. Le premier mode de réalisation permet d'interconnecter les deux 25 applications tout en les laissant s'exécuter dans leur calculateur propre. Selon l'état de la technique, les deux systèmes (gestion du vol et aide au roulage) s'exécutent sur des calculateurs différents. Ce mode de réalisation est donc plus simple à mettre en oeuvre sur des systèmes avioniques existants car ils les impactent moins.

30 La figure 5 présente un second mode de réalisation du dispositif selon l'invention. Selon un autre mode de réalisation du dispositif de partage de données selon l'invention, le système de gestion du vol 201, le système d'aide au roulage 202 et le serveur de données 203 sont situés sur un même calculateur 501 comportant une pluralité de partitions d'exécution, le système de gestion du vol 201, le système d'aide au roulage 202 et le serveur de données 203 étant situés chacun sur des partitions différentes. Dans ce mode de réalisation, le serveur de données 203 héberge l'ensemble des bases de données statiques (navigation - Nav, carte d'aéroport, plan, de vol - FLPN) utilisées par les deux systèmes. Les partitions d'exécution permettent d'isoler les logiciels avioniques les uns des autres et de les rendre totalement indépendants et étanches entre eux. Ce mode de réalisation permet d'intégrer les deux logiciels (le ~o système de gestion du vol 201, le système d'aide au roulage 202) sur un même calculateur plus puissant afin d'économiser un calculateur par rapport au mode de réalisation précédant et simplifier ainsi l'avionique.

Claims

REVENDICATIONS1. Dispositif pour le partage de données entre un système de gestion du vol (201) et un système d'aide au roulage (202) d'un aéronef, lesdites données étant stockées sur au moins un serveur de données (203) embarqué à bord de l'aéronef, lesdites données étant accessibles en écritures et pouvant être modifiées, caractérisé en ce que le serveur (203) comporte des moyens pour notifier au système de gestion du vol (201) et au système d'aide au roulage (202) des modifications sur les données qu'il stocke, et en ce que le système de gestion du vol (201) et le système d'aide au roulage (202) sont associés chacun à une façade respective leur fournissant un accès aux données stockées sur le serveur, ladite façade comprenant : des moyens pour la souscription à un abonnement à une modification d'une donnée, des moyens pour filtrer les notifications émises par le serveur de données en fonction des abonnements souscrits, et pour avertir le système (201, 202) auquel elle est associée d'une modification d'une donnée à laquelle elle est abonnée.
2. Dispositif pour le partage de données selon la revendication 1, caractérisé en ce que les données stockées sur le serveur (203) de données comprennent : un aéroport de départ, une piste de décollage, un aéroport de destination, une piste d'atterrissage, une liste d'aéroports de destination alternatifs, des prédictions en consommation de carburant, des prédictions d'heure d'arrivée à l'aéroport de destination et des avenants aux informations aéronautiques.
3. Dispositif pour le partage de données selon l'une des revendications précédentes, dans lequel, l'aéronef comprenant un module de liaisons de données (204), le module de liaison de données (204) comporte une façade permettant audit module d'accéder aux données hébergées par le serveur de données.
4. Dispositif pour le partage de données selon l'une des revendications précédentes, dans lequel, l'aéronef comprenant un module hébergeant des applications non avioniques (205), ledit module (205) comporte une façade lui permettant d'accéder aux données hébergées par le serveur de données.
5. Dispositif pour le partage de données selon l'une des revendications précédentes, dans lequel, le système de gestion du vol (201), le système d'aide au roulage (202) et le serveur de données (203) sont situés chacun sur des calculateurs différents (401,402,403).
6. Dispositif pour le partage de données selon l'une des revendications 1 à 5, dans lequel, le système de gestion du vol (201), le système d'aide au roulage (202) et le serveur de données (203) sont situés sur un même calculateur (501) comportant une pluralité de partitions d'exécution, le système de gestion du vol (201), le système d'aide au roulage (202) et le serveur de données (203) étant situés chacun sur des partitions de calcul différentes.20