FR3013831A1

FR3013831A1 - Systeme avionique d'un aeronef

Info

Publication number: FR3013831A1
Application number: FR1453296A
Authority: FR
Inventors: Jean-Claude Mere; Julien Bernat; Pierre Neri; Marc Vie
Original assignee: Airbus Operations SAS
Current assignee: Airbus Operations SAS
Priority date: 2013-11-26
Filing date: 2014-04-14
Publication date: 2015-05-29
Anticipated expiration: 2034-04-14
Also published as: US20150148998A1; FR3013929B1; US9606534B2; CN104670508B; US20150150095A1; US20150148996A1; FR3013881A1; FR3013929A1; CN104680852A; FR3013880B1; CN104670509A; CN104680852B; US10216180B2; US9323248B2; FR3013881B1; FR3013880A1; US9709982B2; CN104683142A; US20170147008A1; CN104670508A

Abstract

La présente invention concerne un système avionique d'un aéronef comprenant : - un module cœur (10) comprenant une pluralité d'applications génériques (11 à 1n) - un module supplémentaire (20) distinct du module cœur (10) et comprenant une pluralité d'applications supplémentaires principales (21a, 2ma), - une interface d'échange générique (30) de données entre ledit module cœur et le module supplémentaire, le module supplémentaire (20) comprend deux entités logicielles (I,II) distinctes, respectivement une première entité logicielle (I) dans laquelle la pluralité d'applications supplémentaires principales (21a, ..., 2ma) est implémentée et une seconde entité logicielle (II) dans laquelle au moins une application supplémentaire auxiliaire (21b, ..., 2kb) est implémentée, chaque application supplémentaire auxiliaire étant associée à au moins une application supplémentaire principale dont l'exécution requiert l'exécution de ladite application supplémentaire auxiliaire, le module supplémentaire comprenant en outre une interface d'échange spécifique (60) de données entre lesdites deux entités (I,II). L'architecture du module supplémentaire comprenant une ségrégation des deux entités logicielles (I, II) permet de mettre à jour indépendamment, et à des niveaux logiciels différents, ces deux entités.

Description

SYSTEME AVIONIQUE D'UN AERONEF. La présente invention concerne un système avionique, notamment un système de gestion de vol d'un aéronef. Des architectures connues de systèmes avioniques, notamment de systèmes de gestion de vol d'un aéronef, comprennent deux modules ségrégués et interconnectés: un module coeur mettant en oeuvre des fonctionnalités génériques relatives à la gestion du vol de l'aéronef et un module supplémentaire prévu pour mettre en oeuvre des fonctionnalités supplémentaires spécifiques, par exemple spécifiques à une entité à laquelle appartient ledit aéronef, telle qu'un modèle d'avion spécifique, une famille d'avions, une compagnie, une alliance, tout ou partie d'une flotte d'avions.

De telles architectures permettent à des opérateurs différents de développer indépendamment des fonctionnalités génériques du module coeur (dans ce cas, l'opérateur est par exemple un équipementier) et des fonctionnalités supplémentaires du module supplémentaire (dans ce cas, l'opérateur est par exemple un avionneur ou une compagnie aérienne) et donc de simplifier les évolutions du système de gestion de vol. Les opérations de mise à jour les plus fréquentes concernent uniquement certaines fonctionnalités supplémentaires qui mettent en oeuvre des algorithmes associées aux équations du vol. Lors de ces opérations de mise à jour et pour de telles fonctionnalités, les modifications opérées sont le plus souvent mineures puisqu'elles n'impliquent pas une modification en profondeur du code de la fonctionnalité supplémentaire, c'est-à-dire son comportement vis-à-vis des autres fonctionnalités génériques ou supplémentaires, mais uniquement un changement ou des corrections du code du ou des algorithmes qu'elle met en oeuvre, par exemple pour une redéfinition de l'algorithme afin de le rendre plus spécifique à une entité à laquelle appartient l'aéronef . Actuellement, même pour une telle modification d'un algorithme, les opérateurs doivent s'assurer que l'intégralité du code de la fonctionnalité supplémentaire modifiée est compatible avec les fonctionnalités génériques offertes par le module coeur et certaines autres fonctionnalités supplémentaires avec lesquelles elle peut interagir. Il en résulte qu'aujourd'hui, toute mise à jour même mineure d'un algorithme d'une fonctionnalité supplémentaire demande un effort et un délai important.

L'invention vise à résoudre ce problème et concerne un système avionique d'un aéronef, notamment système de gestion de vol d'un aéronef, comprenant : - un module coeur comprenant une pluralité d'applications génériques, l'exécution de chacune des applications génériques de ladite pluralité d'applications génériques mettant en oeuvre une fonctionnalité générique relative à la gestion du vol de l'aéronef, - un module supplémentaire distinct du module coeur et comprenant une pluralité d'applications supplémentaires principales, l'exécution de chacune des applications supplémentaires principales de ladite pluralité d'applications supplémentaires principales mettant en oeuvre une fonctionnalité supplémentaire spécifique à une entité à laquelle appartient ledit aéronef telle qu'un modèle d'avion spécifique, une famille d'avions, une compagnie, une alliance, tout ou partie d'une flotte d'avions, - une interface d'échange générique de données entre ledit module coeur et le module supplémentaire, le module supplémentaire comprend deux entités logicielles distinctes, respectivement une première entité logicielle dans laquelle la pluralité d'applications supplémentaires principales est implémentée et une seconde entité logicielle dans laquelle au moins une application supplémentaire auxiliaire est implémentée, chaque application supplémentaire auxiliaire étant associée à au moins une application supplémentaire principale dont l'exécution requiert l'exécution de ladite application supplémentaire auxiliaire, le module supplémentaire comprenant en outre une interface d'échange spécifique de données entre lesdites deux entités. Les caractéristiques de l'invention mentionnées ci-dessous, ainsi que d'autres, apparaîtront plus clairement à la lecture de la description suivante d'exemples de réalisation, ladite description étant faite en relation avec les dessins joints, parmi lesquels : - la Fig. 1 est un schéma synoptique d'un système gestion de vol d'un aéronef selon la présente invention ; et - la Fig. 2 est un diagramme illustrant une mise en oeuvre d'un système de gestion de vol d'un aéronef selon la présente invention. La présente description est faite en relation avec un système de gestion de vol (dénommé « FMS » en langage aéronautique) d'un aéronef mais on comprendra que les principes exposés peuvent être appliqués à tout système avionique, par exemple un système de navigation aéroportuaire. Le système avionique, notamment de gestion de vol représenté à la Fig. 1, est essentiellement constitué d'un module coeur 10 et d'un module supplémentaire 20.

Le module coeur 10 comprend une pluralité d'applications, dite applications génériques 11 à ln. L'exécution de chacune des applications génériques 11 à ln de la pluralité d'applications génériques met en oeuvre une fonctionnalité générique relative à la gestion du vol de l'aéronef (par exemple gestion du plan de vol, gestion du carburant, etc.). 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. Les applications génériques du module coeur sont implémentées dans au moins une partition logicielle (conformément au standard ARINC653) hébergée sur un équipement de type IMA (Integrated Modular Avionics est une architecture décrite essentiellement dans le standard ARINC653). Dans ce contexte ARINC653, une partition logicielle est un logiciel (ensemble de lignes de code) qui est exécutable et exécuté dans un espace de temps défini, ségrégué de celui des autres partitions logicielles et sur un espace physique (généralement, un espace mémoire ou des entrées/sorties) également ségrégué. L'équipement IMA du module coeur 10 comprend typiquement une unité de calculs, de la mémoire, des interfaces physiques avec divers dispositifs de l'avion ou avec d'autres équipements matériels ainsi qu'un système d'exploitation pour gérer un ensemble de partitions logicielles de manière que l'équipement en question puisse exécuter les applications génériques afin de mettre en oeuvre des fonctions ou des services.

Les fonctionnalités génériques mises en oeuvre par le module coeur 10 via l'exécution d'applications génériques 11 à ln sont, par exemple, l'une au moins des fonctions suivantes : une fonction de gestion de plan de vol, une fonction de calcul de trajectoire dans l'espace, une fonction de calcul de prédictions des valeurs prises le long d'une trajectoire donnée de l'avion par des grandeurs physiques relatives aux conditions de vol (vitesse, temps, quantité de carburant, etc.), une fonction d'extrapolation de valeurs prises le long d'une trajectoire donnée de l'avion par des grandeurs physiques liées aux conditions météorologiques (vent, température, etc.) sur la base d'un modèle donné, une fonction de calcul de la position courante de l'avion, une fonction de calcul des déviations entre la position courante de l'avion et une position d'une trajectoire théorique donnée, une fonction de calcul des consignes de guidage pour asservir l'avion sur une trajectoire donnée, un ensemble de fonctions permettant de gérer le cockpit de l'avion selon une philosophie type split (au moyen de synchronisation et de contrôle entre plusieurs instances des fonctions au sein du cockpit), etc. Le module supplémentaire 20 comprend une pluralité d'applications logicielles supplémentaires principales 21a, ..., 2ma et, selon l'invention, une pluralité d'applications logicielles supplémentaires auxiliaires 21b, ..., 2kb dont chacune est accessible par une ou plusieurs applications supplémentaires principales selon un protocole qui sera détaillé ci-dessous. Chaque application supplémentaire principale et supplémentaire auxiliaire est spécifique à une entité à laquelle appartient l'aéronef, telle qu'un modèle d'avion spécifique, une famille d'avions, une compagnie, une alliance, tout ou partie d'une flotte d'avions.

Une application supplémentaire auxiliaire 21b, ..., 2kb 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 21a, 2ma. L'exécution d'une application auxiliaire est possible exclusivement à la réception de paramètres d'entrées destinés à alimenter les algorithmes de calcul.

Selon l'invention, certaines applications supplémentaires principales 21a, ..., 2ma sont associées à une ou plusieurs applications supplémentaires auxiliaires auxquelles elles font appel afin d'obtenir des données nécessaires à leur exécution. De telles applications supplémentaires principales sont celles dont l'exécution implique des calculs ou encore des traitements numériques particuliers sur des données, lesdits calculs ou traitement étant réalisés par une ou plusieurs applications supplémentaires auxiliaires. A titre d'exemples : - un type de calcul effectué par une application supplémentaire auxiliaire est un calcul de prédiction pour des applications supplémentaires principales dont l'exécution met en oeuvre une fonctionnalité d'aide à l'équipage dans son rôle de navigation, en intégrant les équations de la mécanique du vol avec des conditions initiales différentes par exemple ou en considérant des modes de guidage différents d'une application supplémentaire principale à l'autre ; et - un traitement particulier sur des données est une consolidation de données avant son utilisation dans une application générique ou une application supplémentaire principale selon un algorithme spécifique nouveau ou différent par rapport à celui utilisé dans le module générique.

L'exécution de chacune des applications supplémentaires principales de la pluralité d'application supplémentaires principales 21a, 2ma met en oeuvre une fonctionnalité supplémentaire du module supplémentaire 20. Chaque fonctionnalité supplémentaire est spécifique à une entité à laquelle appartient l'aéronef, telle qu'un modèle d'avion spécifique, une famille d'avions, une compagnie, une alliance, tout ou partie d'une flotte d'avions. 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 des services supplémentaires par rapport aux services du module coeur 10 qui utilisent une ou plusieurs de ces fonctions supplémentaires. Selon l'invention, les applications supplémentaires principales 21a, 2ma sont implémentées dans une première entité logicielle I et les applications supplémentaires auxiliaires 21b, ..., 2kb sont mises en oeuvre dans une seconde entité logicielle II distincte de la première. Une entité logicielle est une partition logicielle ou un composant logiciel d'une partition logicielle. De manière connue, un composant logiciel est un ensemble de lignes de code cohérent d'un point de vue fonctionnel/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 LH (conformément à ARINC653) hébergées sur un même équipement IMA qui comprend une unité de calculs, de la mémoire, des interfaces physiques avec divers dispositifs de l'avion ou avec d'autres équipements matériels ainsi qu'un système d'exploitation pour gérer les deux partitions logicielles I, II de manière que l'équipement en question puisse exécuter les applications supplémentaires principales et supplémentaires auxiliaires associées à des applications supplémentaires principales afin de mettre en oeuvre les fonctionnalités supplémentaires du module supplémentaire 20. Ces deux partitions sont distinctes entre elles et sont distinctes de la partition logicielle portant les fonctionnalités génériques 11 à ln. La ségrégation entre les deux partitions logicielles I,II du module supplémentaire 20 est assurée par des couches logicielles de bas niveau, comme par exemple un système d'exploitation qui utilise, pour la ségrégation temporelle, des horloges matérielles internes au microprocesseur déroulant ladite partition logicielle et, pour la ségrégation spatiale, des mécanismes de contrôle d'accès à l'espace physique (la mémoire ou les entrées/sorties) en question.

Dans le contexte du standard ARINC653, chaque partition logicielle est associée à au moins un port de communication par partage de mémoire, dit port RAM, ou à au moins une zone mémoire d'échange de fichiers, lui permettant d'échanger des messages avec les autres partitions logicielles. Cet échange peut se faire par échantillonnage (Sampling port : la mémoire associée au port est remise à jour à chaque réception d'une donnée) ou par file d'attente (Queuing port : les messages reçus sont mis en file d'attente). Ces messages qui sont soit émis, soit reçus par un port, sont par exemple les suivants : requêtes de données spécifiques, requêtes d'exécution de fonctions ou de services, requêtes de calcul, réponse sous forme de retours de résultats de calculs, messages retour, demande d'échange de fichiers, etc.

Le module supplémentaire 20 représenté à la Fig. 1 comprend en outre une interface d'échange 60 de données, dite interface d'échange spécifique, prévue entre les deux partitions I, II. La communication entre les deux partitions logicielles via cette interface spécifique 60 est effectuée au moyen de ports RAM ou échange de fichiers, etc. A cet effet, à l'interface d'échange spécifique 60, sont affectés au moins un port, par exemple un port RAM, respectivement de la première et de la seconde partition logicielle I, II du module supplémentaire 20 par lequel transitent les messages transmis via l'interface d'échange spécifique 60. L'interface d'échange spécifique 60 met de préférence en oeuvre un protocole d'encodage des messages transitant par elle à des fins de sécurisation des échanges de données. Ce protocole d'encodage, qui gère la communication entre les deux partitions logicielles I, II est tel que la partition logicielle II du module supplémentaire 20 dans laquelle sont implémentées les applications supplémentaires auxiliaires 21b, - - - , 2kb ne peut communiquer qu'avec l'autre partition logicielle I du module supplémentaire et ce uniquement par une réponse à une requête émise par une application principale 21a, 2ma à destination d'une application auxiliaire 21b, 2kb . La requête envoyée à une application supplémentaire auxiliaire comprend alors les paramètres d'entrées permettant à l'application supplémentaire auxiliaire d'effectuer le calcul, ces paramètres étant fournis par d'autres applications supplémentaires principales ou par les applications génériques du module coeur. En effet, les fonctionnalités génériques et les applications supplémentaires principales peuvent échanger des messages entre elles. A cette fin, la communication entre les deux équipements comprenant les modules coeur 10 et supplémentaire 20 est effectuée au moyen de ports RAM ou échange de fichiers, etc. A cet effet, le système de gestion de vol représenté à la Fig. 1 comprend ainsi une interface 30 d'échange de données, dite interface d'échange générique, prévue entre le module coeur 10 et le module supplémentaire 20. A cette interface d'échange générique 30, sont affectés au moins un port respectivement du module coeur 10 et du module supplémentaire 20 par lesquels transitent les données sous forme de messages, ce ou ces ports pouvant être des ports RAM. Avantageusement, l'interface d'échange générique 30 met en oeuvre un protocole d'encodage des données portées par les messages transitant par elle. 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 de s'interfacer avec des systèmes embarqués de l'aéronef 40 20 comprenant au moins une interface homme-machine 41, dite générique. Les systèmes embarqués peuvent comprendre également, comme c'est le cas à la Fig. 1, des dispositifs embarqués génériques 42 tels que ceux couramment installés dans des aéronefs, comme des instruments de vol, divers capteurs, etc... Les applications supplémentaires principales peuvent, via l'interface d'échange 25 générique 30 et via l'application générique d'interfaçage 16, s'interfacer avec l'interface homme-machine générique 41. Le module supplémentaire 20 possède également une application supplémentaire principale d'interfaçage 26, accessible par les autres applications 30 supplémentaires principales, et qui lorsqu'elle est exécutée, met en oeuvre une fonctionnalité d'interfaçage permettant l'interfaçage avec une interface homme-machine 50 spécifique au module supplémentaire 20. En outre, dans le cas où certaines applications supplémentaires principales sont associées à des dispositifs embarqués spécifiques 51 (instruments de vol, calculateurs, divers capteurs tels des capteurs anémométriques ou inertiels ...) dédiés à leurs besoins spécifiques, l'exécution de l'application supplémentaire principale d'interfaçage 26, accessible par les autres applications supplémentaires principales, peut mettre en oeuvre une fonctionnalité d'interfaçage permettant l'interfaçage avec un dispositif embarqué spécifique 51. Chaque interface homme-machine 41 ou 50 est par exemple constituée de dispositifs pris parmi : des écrans, écrans tactiles, etc., claviers, souris, trackballs, systèmes de vision tête haute, systèmes de réalité augmentée, ou encore dispositifs de type EFB (pour electronic flight bag : dispositif fournissant des informations de vol à l'équipage), ordinateurs portables, etc. L'exécution de l'application générique d'interfaçage 16 du module coeur 10 permet l'acquisition de données avion issues des différents dispositifs 42 (instruments de vol, capteurs divers, etc.). Cette application générique d'interfaçage 16 est avantageusement équipée de moyens de filtrage pour détecter et exclure toute donnée invalide et de moyens de consolidation pour mixer l'ensemble des données valides en une donnée consolidée. Pour accéder à cette donnée, une application supplémentaire principale 21a, 2ma émet une requête sur un port d'accès à l'application générique d'interfaçage 16 (ladite requête transite alors par l'interface d'échange générique 30) laquelle émet en retour une réponse contenant ladite donnée. Il s'agit là d'un mécanisme de réponse à une requête adressée à ladite application générique d'interfaçage 16. Dans la suite de la description, on va donner, en relation avec la Fig. 2, un exemple de mise en oeuvre d'un ensemble de fonctionnalités supplémentaires du module supplémentaire 20 afin de permettre à l'équipage d'un avion de rechercher les aérodromes les plus proches de la position courante de l'avion et de les afficher en les classant selon des critères qu'il aura choisis, puis de proposer un plan de vol alternatif menant à l'un des aérodromes sélectionnés et pouvant être activé en lieu et place du plan de vol courant.

Dans cet exemple le module coeur 10 est fournisseur d'au moins les services fonctionnels suivants : une fonctionnalité de fourniture de l'identification des aérodromes les plus proches de la position courante de l'avion (cette information est normalement déterminée à partir d'informations stockées dans une base de données 18, dite de navigation), une fonctionnalité d'affichage de ces informations sur l'interface homme-machine générique 41, une fonctionnalité d'émission de données de disponibilité de plan de vol, une fonctionnalité d'insertion d'un nouveau plan de vol, etc. A cette fin, le module coeur 10 comprend les applications suivantes : une application générique 110 de fourniture de l'identification des aérodromes les plus proches de la position courante de l'avion (cette information est normalement déterminée à partir d'informations stockées dans une base de données 18, dite de navigation), une application générique 120 d'affichage de ces informations sur l'interface homme-machine générique 41, une application générique 130 d'émission de données de disponibilité de plan de vol, une application générique 140 d'insertion d'un nouveau plan de vol, etc. Quant au module supplémentaire 20, son application supplémentaire principale d'interfaçage 26 est prévue, lorsqu'elle est exécutée, pour s'interfacer avec une interface homme-machine spécifique 50 qui permet à l'équipage de faire des requêtes et d'entrer pour celles-ci des paramètres. Il comporte une application supplémentaire principale 210 de commande de recherche de l'identification des aérodromes les plus proches, une application supplémentaire principale de classement 220, selon les critères choisis par l'équipage au moyen de l'interface homme-machine spécifique 50 et selon des résultats de calculs de prédiction, des résultats obtenus en réponse à des requêtes émises. Il comporte aussi une application supplémentaire principale 240 pour générer un plan de vol alternatif à celui déjà établi, et une application supplémentaire principale 250 pour vérifier la disponibilité d'un plan de vol, etc. Dans cet exemple, l'application supplémentaire principale 220 mettant en oeuvre des calculs de prédiction est associée à une application supplémentaire auxiliaire 220A. Le module supplémentaire 20 assure le séquencement des requêtes à destination des applications génériques du module coeur 10 (via les ports permettant d'accéder auxdites fonctionnalités). Comme décrit précédemment, les fonctionnalités génériques et les applications supplémentaires principales peuvent échanger des messages entre elles via l'une interface générique 30, prévue entre le module coeur 10 et le module supplémentaire 20. On décrit ci-après les différentes étapes d'échanges mises en oeuvre. Dans une première étape El, au moyen de l'interface homme-machine spécifique 50, l'équipage lance l'exécution de l'application supplémentaire principale 210 (par exemple : une fonctionnalité de recherche de l'aérodrome le plus proche) du module supplémentaire 20 et entre les valeurs des paramètres nécessaires à la mise en oeuvre de cette application (par exemple : le rayon de recherche autour de la position courante de l'avion, le nombre maximum d'aérodromes, etc.).

Dans une seconde étape E2, l'application supplémentaire principale 210 émet une requête à destination de l'application générique 110 d'identification des aérodromes les plus proches du module coeur 10 afin que celui-ci recherche dans la base de données de navigation 18 les aérodromes les plus proches de la position courante de l'avion. Cette requête inclut les paramètres précédemment sélectionnés par l'équipage. Selon un mode de réalisation, cette requête se présente sous forme d'un message contenant lesdits paramètres qui pourrait être adressée, en mode file d'attente (Queuing port), au port RAM (ARINC 653) de la fonctionnalité 110 concernée du module coeur 10. Dans une troisième étape E3, l'application générique concernée 110 du module coeur 10 émet une réponse à destination de l'application principale 210. Selon un mode de réalisation, cette réponse est adressée, en mode file d'attente (Queuing), au port RAM (ARINC 653) permettant d'accéder à l'application concernée du module supplémentaire. Dans une quatrième étape E4, l'application supplémentaire principale 210 transmet la réponse à l'application supplémentaire principale 220 du module supplémentaire 20 qui, lorsqu'elle est exécutée, émet une requête de calcul vers l'application supplémentaire auxiliaire 220A pour que cette dernière exécute un algorithme de calcul de prédictions basées sur des extrapolations de valeurs tabulées pour chacun des aérodromes identifiés dans la réponse du module coeur. L'application principale 220 reçoit par un message retour les résultats de l'application supplémentaire auxiliaire 220A et effectue un classement desdits aérodromes en fonction desdites prédictions, selon des critères qui peuvent être définis par l'équipage sur l'interface homme machine spécifique 50, et affiche le résultat sur l'interface homme-machine spécifique 50.

Dans une cinquième étape E5, l'application supplémentaire principale de classement 220 du module supplémentaire 20 émet à destination de l'application générique d'affichage 120 du module coeur 10 une requête visant à afficher les aérodromes d'une couleur particulière sur l'interface homme-machine générique 41, notamment l'écran de navigation (Navigation Display). Comme précédemment, cette requête est adressée, en mode file d'attente (Queuing), au port RAM (ARINC 653) permettant d'accéder à la fonctionnalité concernée du module coeur 10. Dans une sixième étape E6, au moyen de l'interface homme-machine spécifique 50, le pilote de l'avion sélectionne un aérodrome parmi les aérodromes affichés sur l'écran de navigation 41. Alternativement à l'étape E6, et dans une étape E6bis, le pilote de l'avion sélectionne un aérodrome parmi les aérodromes affichés sur l'écran de navigation au moyen de l'interface homme-machine générique 41. Ensuite, dans une septième étape E7, une application supplémentaire principale 240 du module supplémentaire 20 calcule un plan de vol alternatif menant directement à l'aérodrome qui a été sélectionné. Dans une huitième étape E8, l'application supplémentaire principale 250 lit les données concernant l'existence et la disponibilité d'un plan de vol secondaire (donc, non occupé) qu'une application générique 130 du module coeur 10 émet périodiquement au moyen de messages sur un port, en mode échantillonnage (Sampling port). Si, à la lecture de ces données, il s'avère qu'aucun plan de vol secondaire n'est disponible, l'application supplémentaire principale 250 commande, via l'interface d'échange générique 30, l'affichage sur l'interface homme-machine générique d'un message pour avertir l'équipage. Si au contraire, il s'avère qu'un plan de vol secondaire est disponible (comme c'est le cas à la Fig. 2), alors l'application supplémentaire principale 250 adresse à une application générique 140 du module coeur une requête d'insertion du plan de vol alternatif dans le plan de vol secondaire disponible. Cette requête peut par exemple être portée par un message sur un port RAM (ARINC 653) en mode "file d'attente" (Queuing). A cet instant, le module coeur 10 dispose d'un plan de vol secondaire sur lequel il calcule des prédictions, consultable par l'équipage, via son interface homme- machine générique, et éventuellement activable pour guidage. L'avantage de l'invention et de procurer une plus grande souplesse industrielle (évolutivité, démonstration de certification) au module supplémentaire. En effet, l'architecture du module supplémentaire sur deux entités logicielles I, II permet de mettre à jour indépendamment, et à des niveaux logiciels différents, les deux entités logicielles du module supplémentaire 20. 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. Le code de l'application supplémentaire principale qui régit quant à lui le comportement de ladite application supplémentaire vis-à-vis des autres applications supplémentaires principales ou applications génériques n'est pas modifié et n'a alors pas besoin d'être vérifié. Des fonctionnalités spécifiques à une entité, telle qu'un avion, une famille d'avions, une compagnie, une alliance, tout ou partie d'une flotte d'avions, peuvent ainsi être mises à jour dans le système de gestion de vol sans nécessiter de vérifications longues et coûteuses des applications supplémentaires principales ou génériques.

L'invention a été décrite dans le cas où les deux entités logicielles I, II du module supplémentaire 20 sont des partitions logicielles hébergées sur un même équipement IMA, ce qui offre les meilleurs avantages en terme de ségrégation et d'indépendances des entités logicielles. En variante, les deux entités logicielles I, II sont des composants logiciels d'une même partition hébergée par un seul équipement IMA, les deux composants logiciels communiquent entre eux au moyen de partage de mémoire via l'interface d'échange spécifique 60. Cette variante présente des avantages en termes de rapidité de calcul, puisque la mise en oeuvre de l'invention n'augmente pas le nombre de partitions du module supplémentaires 20. Dans une autre variante de réalisation, les deux entités I, II du module supplémentaires sont hébergés dans deux équipements IMA distincts, chacune des entités étant dans un équipement distinct de l'autre. Dans, ce cas, la communication entre ces deux équipements IMA est effectuée au moyen d'un réseau AFDX (Application Full Duplex Ethernet), par un réseau Ethernet, ou encore par un réseau ARINC429 via l'interface d'échange spécifique 60.

Chacun des modules coeur 10 ou supplémentaire 20 peut également mettre en oeuvre d'autres applications que celles qui ont été précédemment décrites. Ainsi, le module coeur 10 et/ou le module supplémentaire 20 peut encore comporter une application (non représentée) d'acquisition de données émises par le sol pour l'avion et transmises via un réseau ATN (Aeronautical Telecommunications Network : réseau de télécommunications pour l'aéronautique), un réseau ACARS (Aircraft Communication Adressing and Reporting System : système d'adressage et de report de communication pour avion), un réseau spécifique VHF (Very High Frequency : Très haute fréquence) ou une liaison rapide point à point sans fil. Ces données sont également accessibles par un mécanisme de réponse à requête adressée à la fonctionnalité en question. Le module coeur 10 peut encore comporter au moins une base de données embarquée 18 dans laquelle sont par exemple stockées des données créées par l'équipage, ou des données fournies et chargées au sol (comme des pistes, des points de navigations, etc.). Il comporte également des applications génériques de gestion de ces bases de données. Là encore, ces données sont accessibles en lecture/écriture par un mécanisme de réponse à requête adressée à l'application générique de gestion en question.

Les bases de données du module coeur 10 ne sont accessibles que par le module coeur 10 lui-même ou par les applications supplémentaires principales du module supplémentaire 20, indirectement via l'interface d'échange générique 30 et le module coeur 10. Dans ce dernier cas, requêtes et réponses sont transmises via l'interface d'échange générique 30 qui, comme cela est mentionné ci-dessus, peut comporter des moyens de cryptage, ce qui assure la sécurité de ces requêtes et réponses. Le module supplémentaire 20 peut lui aussi comprendre une ou des bases de données spécifiques (ce qui n'est pas le cas à la Fig. 1). Le module coeur 10 peut encore comporter une application générique 19 de maintenance qui lorsqu' elle est exécutée met en oeuvre une fonctionnalité de maintenance. Cette fonctionnalité peut consister, lorsqu'une panne a été détectée sur un équipement, à envoyer des messages informant de cette panne au centre de maintenance de l'avion. Elle peut également consister à répondre aux requêtes du centre de maintenance pour la réalisation de tests interactifs, etc. Le module supplémentaire 20 peut également comporter une application supplémentaire principale mettant en oeuvre une telle fonctionnalité.

Claims

REVENDICATIONS1) Système avionique d'un aéronef, notamment système de gestion de vol d'un aéronef, comprenant : - un module coeur (10) comprenant une pluralité d'applications génériques (11 à 1n), l'exécution de chacune des applications génériques de ladite pluralité d'applications génériques mettant en oeuvre une fonctionnalité générique relative à la gestion du vol de l'aéronef, - un module supplémentaire (20) distinct du module coeur (10) et comprenant une pluralité d'applications supplémentaires principales (21a, 2ma), l'exécution de chacune des applications supplémentaires principales de ladite pluralité d'applications supplémentaires principales mettant en oeuvre une fonctionnalité supplémentaire spécifique à une entité à laquelle appartient ledit aéronef telle qu'un modèle d'avion spécifique, une famille d'avions, une compagnie, une alliance, tout ou partie d'une flotte d'avions, et - une interface d'échange générique (30) de données entre ledit module coeur et le module supplémentaire, caractérisé en ce que le module supplémentaire (20) comprend deux entités logicielles (I,II) distinctes, respectivement une première entité logicielle (I) dans laquelle la pluralité d'applications supplémentaires principales (21a, 2ma) est implémentée et une seconde entité logicielle (II) dans laquelle au moins une application supplémentaire auxiliaire (21b, ..., 2kb) est implémentée, chaque application supplémentaire auxiliaire étant associée à au moins une application supplémentaire principale dont l'exécution requiert l'exécution de ladite application supplémentaire auxiliaire, le module supplémentaire comprenant en outre une interface d'échange spécifique (60) de données entre lesdites deux entités (I,II).
2) Système avionique selon la revendication 1, caractérisé en ce que l'exécution d'une application supplémentaire auxiliaire (2 lb, ..., 2kb) est possible uniquement à la réception de paramètres d'entrées fournis par au moins une application supplémentaire principale (21a, 2ma) ou au moins une application générique (11 à 1n) du module coeur (10).
3) Système avionique selon la revendication 2, caractérisé en ce que chaque application supplémentaire auxiliaire (21b, ..., 2kb) comprend un ou plusieurs algorithmes de calcul.
4) Système avionique selon l'une quelconque des revendications 1 à 3, caractérisé en ce que chaque application supplémentaire auxiliaire (21b, ..., 2kb) est exécutée exclusivement à la requête d'au moins une application supplémentaire principale (21a, ..., 2ma).
5) Système avionique selon l'une quelconque des revendications 1 à 4, caractérisé en ce que les deux entités logicielles (I, II) appartiennent à un même équipement IMA.
6) Système avionique selon l'une quelconque des revendications 1 à 5, caractérisé en ce qu'une entité logicielle (I, II) est une partition logicielle.
7) Système avionique selon la revendication 6, caractérisé en ce que l'interface d'échange spécifique (60) met en oeuvre un protocole d'encodage des données transitant par elle de sorte que la seconde entité logicielle (II) communique exclusivement avec la première entité logicielle (I) et uniquement par un message de retour en réponse à une requête émise par une application principale (21a, 2ma) à destination d'une application auxiliaire (21b, ..., 2kb) .
8) Système avionique selon l'une quelconque des revendications 1 à 5, caractérisé en ce qu'une entité logicielle (I, II) est un composant logiciel d'une partition logicielle.
9) Système avionique selon l'une quelconque des revendications 1 à 8, caractérisé en ce que le module coeur (10) est pourvu d'une application générique dite d'interfaçage (16) permettant son interfacage à des systèmes embarqués (40) dudit aéronef comprenant au moins une interface homme-machine générique (41) et, - ledit module supplémentaire (20) est également pourvu d'une application supplémentaire principale dite d'interfaçage (26), permettant son interfacage à aumoins une interface homme-machine spécifique (50) liée audit module supplémentaire (20).
10) Système avionique selon la revendication 9, caractérisé en ce que ladite application supplémentaire principale d'interfaçage (26) dudit module supplémentaire (20) permet d'accéder auxdits systèmes embarqués (40) dudit aéronef par l'intermédiaire dudit module coeur (10).