FR3005824A1 - Gestion distribuee des communications bord-sol dans un aeronef - Google Patents

Abstract

Procédé de configuration de gestion de communications à bord d'un aéronef comportant la mise en œuvre d'un mécanisme d'élection d'un équipement maître dans un réseau d'équipements informatiques en charge de communications bord-sol de l'aéronef et de configuration de gestion de communication en fonction dudit équipement maître. Le procédé permet de répartir les applications en charge des communications bord-sol entre les équipements informatiques connectés en réseau.

Description

05 82 4 1 La présente invention concerne le domaine des communications bord-sol dans les aéronefs, c'est-à-dire les communications émises depuis l'aéronef vers au moins une station au sol ou depuis au moins une station au sol vers l'aéronef.

Airbus a développé, notamment pour l'A380, une architecture réseau à bord de l'aéronef basée sur le NSS (sigle de « Network Server System », c'est-à-dire système de serveurs en réseau en anglais). Une partie du NSS est dédiée aux communications avioniques. Une autre partie est dédiée notamment aux opérations de vols (on parle du domaine « flight operations » en anglais, « NSS Flight ops » dans la suite). Ainsi, le domaine NSS Flight ops est connecté au monde extérieur, notamment les centres opérationnels des compagnies aériennes. Les communications bord-sol entre le domaine NSS Flight ops et le centre opérationnel des compagnies aériennes sont gérées par le système OWAG (sigle de « Open World Aircraft Ground » en anglais). Ce type de système est décrit dans le document WO 2008/139062. Le système OWAG permet des communications bord-sol transparentes vis-à-vis des applications communicantes du domaine NSS Flight ops et des centres opérationnels de compagnies aériennes.

Par exemple, le système OWAG gère les moyens de communication bord-sol du domaine NSS Flight ops. À ce jour, ces moyens sont entre autres le Gatelink (WiFi, cellulaire) et le Satcom SBB. Cette fonction de gestion des moyens de communication est assurée par un composant logiciel LGCM (sigle de « Light Green Communications Manager » en anglais), qui peut être installé sur le serveur ANSU-AFMR du domaine NSS Flight Ops. Le système OWAG peut en outre fournir un service asynchrone, robuste, centralisé et sécurisé pour l'échange de données entre l'avion (domaine NSS Flight ops) et le sol (centre opérationnel de la compagnie aérienne). Cette fonction est assurée par un composant logiciel OAMS (sigle de « On-board Asynchronous Messaging Server » en anglais), qui peut être installé sur le serveur ANSU-AFMR. En outre, ('OAMS dispose d'un pendant sol au niveau du centre opérationnel de la compagnie aérienne, appelé GAMS (sigle de « Ground Asynchronous Messaging Server » en anglais). Les communications de données bord-sol se font donc entre OAMS et GAMS dans les sens montant (sol vers bord) aussi bien que descendant (bord vers sol). Le système OWAG peut aussi fournir une interface aux applications 5 de communication ou nécessitant la mise en oeuvre de communications. Ces applications « communicantes » peuvent être à bord ou au sol. Elles peuvent utiliser un jeu de fonctionnalités primitives pour s'interfacer avec le système OWAG telles que « déposer des données à transmettre », « récupérer des données reçues » ou autre. Le jeu de fonctionnalités primitives offert aux 10 applications pour s'interfacer avec OWAG est appelé OAMS API à bord et GAMS API au sol. OAMS API est installé à bord sur le serveur ANSU-AFMR mais aussi sur les EFB (sigle de « Electronic Flight Bag » en anglais) de classe 3 dont disposent les pilotes dans la station de pilotage (« cockpit » en anglais et dans la suite) et sur lesquels les applications communicantes sont utilisées. 15 Le système OWAG gère notamment les pertes et rétablissements des communications bord-sol, les interruptions et reprises sur erreur de transferts d'informations. Ainsi, OWAG permet de masquer la complexité de la problématique « communications bord-sol » aux applications clientes d'OWAG. Les inventeurs ont constaté que les services OAMS et LGCM 20 d'OWAG ne sont exécutés que sur un seul équipement : le serveur ANSUAFMR du domaine NSS Flight ops. Ainsi en cas de panne ou d'arrêt du serveur ANSU-AFMR, les services OWAG ne sont plus disponibles pour les applications communicantes clientes de ce serveur, et ce, même dans le cas où des applications seraient en exécution sur les EFB de classe 3 du cockpit. 25 Les inventeurs ont aussi constaté que le nombre d'équipements dans le cockpit hébergeant des applications désirant communiquer avec le sol avec le même niveau de fiabilité est en augmentation. Il s'agit par exemple des tablettes tactiles connectées au réseau bord en WiFi ou d'autres moyens de communication sans fil. 30 La présente invention s'inscrit dans ce cadre.

Un premier aspect de l'invention concerne un procédé de configuration de gestion de communications à bord d'un aéronef comportant les étapes suivantes: - de détection d'un événement de configuration de gestion de communication, - d'échange d'informations relatives à au moins un critère d'élection d'un équipement maître dans un réseau d'équipements informatiques en charge des communications bord-sol de l'aéronef, - de détermination d'un équipement maître en fonction desdites informations échangées, - de configuration de gestion de communication en fonction dudit équipement maître déterminé. Un procédé selon le premier aspect permet de répartir les applications en charge des communications bord-sol (telles que celles du système OWAG, comme par exemple le LGCM et l'OAMS) entre les équipements informatiques connectés en réseau (par exemple celui du domaine NSS Flight Ops). Il est aussi possible de lancer les applications en charge des services de communications bord-sol non plus sur un seul équipement bord, mais sur tout ou partie des équipements bord. La mise en oeuvre d'un mécanisme de détermination (ou élection) d'un équipement maître basé sur un dialogue entre les différents équipements bord, permet d'exécuter chaque application de communication (par exemple LGCM et OAMS) de façon unique (par exemple sur la plateforme de bord à un instant donné). Ainsi, chaque application de communication peut être lancée sur plusieurs équipements de bord, mais elle ne s'exécute de façon active que sur un seul de ces équipements à un instant donné. En outre, un même équipement peut, à un instant donné, mettre en oeuvre une ou plusieurs applications de communication bord-sol.

Un procédé selon le premier aspect permet de résister à la défaillance d'un équipement maître, car dans cette éventualité, le mécanisme d'élection peut être mis en oeuvre notamment pour détecter la perte de l'équipement maître, pour désigner un nouvel équipement maître (par exemple en charge de l'exécution d'une application de communication), ou autre. Un procédé selon le premier aspect permet aussi la mise en commun de moyens de communication bord-sol (par exemple ceux du domaine NSS Flight Ops) de manière dynamique. Ainsi, l'équipement maître peut gérer à la fois les moyens de communications bord-sol de l'aéronef et ceux apportés par les équipements connectés au réseau au fur et à mesure. De manière générale, la gestion des communications bord-sol est rendue plus disponible car elle peut ne plus s'exécuter obligatoirement de manière centralisée sur un équipement unique pour toutes les applications. La redondance offerte par les équipements de bord est mise à profit. Le type et le nombre de moyens de communication pouvant être mis en oeuvre est accru. La gestion des communications à bord de l'aéronef est rendue plus flexible car elle peut s'adapter à différentes architectures en fonction des équipements disponibles à bord. La présente invention peut s'appliquer au système OWAG évoqué ci-avant et dans le reste de la description. Les compagnies aériennes peuvent faire communiquer les équipements à bord avec un serveur unique au sol : le GAMS installé chez la compagnie aérienne au niveau de son centre opérationnel. Des services de communications uniformes pour tous les équipements communicants peuvent être mis en oeuvre grâce à la réutilisation telle qu'existante de la solution OWAG.

Selon des exemples de réalisation, ledit événement est au moins l'un parmi : - une mise sous tension de l'aéronef, - une connexion d'un équipement informatique en charge de communications bord-sol de l'aéronef audit réseau, et - une déconnexion d'un équipement informatique en charge de communications bord-sol de l'aéronef dudit réseau.

Par exemple, au moins l'une desdites informations échangées comporte au moins l'un ou l'une parmi: - une donnée de priorité respectivement associée aux équipements informatiques connectés audit réseau, - une adresse réseau respectivement associée aux équipements informatiques connectés audit réseau, et - un message de forçage en provenance d'une autorité de gestion des communications. Selon des réalisations, les adresses réseaux des équipements sont 10 prises en compte pour départager des équipements associés à une même donnée de priorité. Par exemple, lorsqu'un message de forçage en provenance d'une autorité de gestion des communications est échangé, l'équipement associé audit message est déterminé comme équipement maître. 15 Le procédé peut en outre comporter une étape de désactivation d'au moins un service de communication bord-sol suite à la détection dudit événement. Par exemple, ladite étape de configuration comporte une transmission, par au moins un équipement dudit réseau, à destination dudit 20 équipement maître déterminé, d'au moins un message relatif à un type de communication prise en charge par ledit équipement. Par exemple, ledit type de communication identifie un moyen de communication disponible auprès dudit équipement, ladite étape de configuration comportant en outre une étape d'activation dudit moyen de 25 communication disponible auprès dudit équipement. Le procédé peut en outre comporter une étape de désactivation d'au moins un autre moyen de communication équivalent aussi moyen de communication activé, ledit autre moyen de communication étant disponible auprès d'un autre équipement dudit réseau. 30 Par exemple, ledit type de communication identifie une catégorie de messages, ladite étape de configuration comportant la prise en charge, par ledit équipement maître déterminé de ladite catégorie de messages, pour le compte des équipements dudit réseau. Selon des réalisations, le procédé comporte en outre une étape de détermination (305) d'un équipement de secours en fonction desdites informations échangées, ledit équipement de secours étant configuré pour fonctionner en tant qu'équipement maître en cas de défaillance de celui-ci. Un deuxième aspect de l'invention concerne un équipement informatique configuré pour prendre en charge des communications bord-sol à bord d'un aéronef, conformément au premier aspect.

Un tel équipement peut comporter une unité de traitement configurée pour détecter un événement de configuration de gestion de communication, échanger des informations relatives à au moins un critère d'élection d'un équipement maître dans un réseau d'équipements informatiques en charge de communications bord-sol de l'aéronef, déterminer un équipement maître en fonction desdites informations échangées, et configurer la gestion de communication en fonction dudit équipement maître déterminé. Par exemple, un équipement selon le deuxième aspect peut comporter des éléments matériels et logiciels permettant d'exécuter d'une part les applications de communications et d'autre part le mécanisme d'élection présenté ci-dessus. Ainsi, un équipement selon le deuxième aspect participe aux échanges du processus d'élection dès qu'un des événements parmi ceux listés ci-après est vérifié : la mise sous tension de l'avion, la connexion ou la déconnexion d'un équipement du réseau bord. Un troisième aspect de l'invention concerne un système de 25 communication à bord d'un aéronef configuré pour la mise en oeuvre d'un procédé selon le premier aspect. Un tel système comporte par exemple une pluralité d'équipements selon le deuxième aspect. Par exemple, un système selon le troisième aspect comporte des 30 éléments matériels et logiciels permettant d'exécuter d'une part les applications de communications et d'autre part le mécanisme d'élection présenté ci-dessus. Afin que ce système puisse être élu maître dans le cadre du processus d'élection, il est possible d'attribuer au système un « poids » et le système peut disposer d'un identifiant unique (par exemple son adresse MAC). Le mécanisme d'élection peut utiliser les poids et identifiants uniques de tous les équipements participant au processus d'élection pour désigner l'équipement maître pour chaque application de communication. En outre, une interface graphique peut être mise en oeuvre pour fournir aux pilotes et aux équipes de maintenance la possibilité de passer outre le mécanisme d'élection automatique et forcer la désignation d'un équipement maître pour chaque application de communication.

Un quatrième aspect de l'invention concerne un aéronef comportant un équipement selon le deuxième aspect et/ou un système selon le troisième aspect. Les objets selon les deuxième, troisième et quatrième aspects de l'invention offrent au moins les mêmes avantages que ceux offerts par l'objet selon le premier aspect dans ses divers exemples de réalisation. D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la présente description détaillée qui suit, à titre d'exemple non limitatif, et des figures annexées parmi lesquelles: - la figure 1 illustre schématiquement un contexte de mise en oeuvre de modes de réalisation de l'invention; - la figure 2 illustre schématiquement un réseau de communication selon des modes de réalisation ; - la figure 3 est un organigramme d'étapes mises en oeuvre selon des modes de réalisation; - la figure 4 illustre un contexte de mise en oeuvre de modes de réalisation dans un système OWAG; - la figure 5 illustre schématiquement des équipements selon des modes de réalisation. Dans le contexte général de mise en oeuvre de modes de réalisation de l'invention de la figure 1, un aéronef 100 comporte un réseau 101 (NET) d'équipements informatiques en charge de communications bord-sol (équipements dans la suite). Par exemple, il s'agit du système NSS (« Network Server System ») de l'aéronef. Les équipements informatiques peuvent mettre en oeuvre des communications avec une station au sol 102 (GRND STAT). Par exemple, il s'agit d'un centre opérationnel d'une compagnie aérienne. Les communications entre l'aéronef et la station au sol sont mises en oeuvre par radiocommunications entre des antennes respectives 103 et 104 de l'aéronef et de la station au sol. Comme illustré par la figure 2, le réseau 101 peut comporter divers types d'équipements. Il peut s'agir d'équipements 200 (EQUIP1) dont est initialement équipé l'aéronef, par exemple, le serveur ANSU-AFMR du NSS. Il peut aussi s'agir d'équipements 201 (EQUIP2), 202 (EQUIP3) intégrés au réseau en cours d'exploitation de l'aéronef, par exemple des EFB qui sont connectés et déconnectés en fonction des vols opérés. Chaque équipement peut mettre en oeuvre des applications (ou services informatiques), notamment des applications de communication avec le sol. Ces applications sont par exemple des applications de gestion de communication de type LGCM, des applications d'échange de données de type OAMS ou autres. Une même application peut être installée auprès de plusieurs équipements informatiques. Ainsi, par exemple, l'équipement 200 comporte une application 203 (APPLI1) et une application 204 (APPLI2). L'équipement 201 comporte quant à lui l'application 204 (également présente au sein de l'équipement 200) et l'application 205 (APPLI3). L'équipement 202 comporte quant à lui l'application 203 (également présente au sein de l'équipement 201) et l'application 206 (APPLI4).

Au fur et à mesure de la connexion d'équipements informatiques au sein du réseau 101, des redondances peuvent donc apparaître en termes de disponibilité d'applications (ou d'instances d'application). Dans l'exemple de la figure 2, l'application 203 est présente au sein de deux équipements 200 et 202 et peut être lancée par ces deux équipements. Dans le même exemple, l'application 204 est présente au sein de deux équipements 200 et 201 et peuvent être lancées par ces deux équipements.

Afin notamment de profiter de cette redondance tout en assurant une mise en oeuvre uniforme des applications, un processus d'élection d'un ou plusieurs équipements « maître » pour l'exécution d'une ou plusieurs applications est mis en oeuvre.

La figure 3 est un organigramme général d'étapes pouvant être mises en oeuvre dans un tel processus d'élection. Ces étapes peuvent par exemple être mises en oeuvre par chaque équipement du réseau. Ainsi, il est possible de prévoir que seuls les équipements configurés pour mettre en oeuvre le processus d'élection peuvent être intégrés au réseau pour communiquer avec l'extérieur de l'aéronef. Alternativement, ou en combinaison, lors de la connexion de chaque équipement au réseau il est installé un logiciel permettant à l'équipement de mettre en oeuvre le processus d'élection si celui-ci n'est pas configuré pour un tel processus. D'autres mesures peuvent être prévues en alternative ou en combinaison.

Lors d'une étape de détection d'événement 301 (EVENT ?) le processus d'élection est vérifié si une configuration de la gestion des communications à bord de l'aéronef doit être mise en oeuvre. Il peut aussi s'agir d'une mise à jour de cette configuration. Par exemple, un tel événement peut être la mise sous tension de l'aéronef (ou du réseau), la connexion d'un nouvel équipement au sein du réseau, la déconnexion d'un équipement ou autre. L'événement peut aussi être la réception d'un message indiquant qu'une configuration doit être mise en oeuvre. Le message peut provenir d'une autorité de contrôle des communications, par exemple le pilote ou une application de contrôle qui a par exemple détecté une panne sur un appareil. D'autres types d'événements peuvent être envisagés. Si l'événement est détecté (OK), les équipements peuvent être provisoirement déconnectés du monde extérieur lors d'une étape 302 (DISCONN.) afin de mettre en oeuvre l'élection de l'équipement maître. Ainsi, lors de la phase d'élection, les équipements ne communiquent plus avec l'extérieur ce qui peut éviter des problèmes de conflits ou de perte de données avant que l'équipement maître soit déterminé. 3005 82 4 10 Les équipements échangent ensuite des informations entre eux lors d'une étape 303 (XCHANGE INFO) afin de leur permettre de déterminer lors d'une étape 304 (DET MASTR) l'équipement maître. Plusieurs types d'informations peuvent être échangés. Par exemple, 5 il s'agit d'un indicateur (ou donnée) de priorité associée respectivement à chaque équipement. L'indicateur peut être directement associé à l'équipement. Dans ce cas, peu importe l'application mise en oeuvre par l'équipement, la priorité qui lui est associée est toujours la même. L'indicateur peut aussi être indirectement associé à l'équipement via une ou plusieurs applications qu'il met 10 en oeuvre. Ainsi, dans ce cas, l'équipement est associé à une pluralité d'applications et il peut être désigné maître pour l'une ou plusieurs applications en fonction des indicateurs. L'indicateur peut aussi être une adresse réseau (par exemple l'adresse MAC). Ainsi, en fonction de l'endroit où est connecté l'équipement, 15 celui-ci peut être désigné comme maître ou non. Parmi les informations échangées, l'on peut aussi trouver un message de forçage de la part d'une autorité de contrôle des communications, par exemple le pilote ou une application de contrôle. Un ou plusieurs critères peuvent être mis en oeuvre, à partir des 20 informations échangées, pour désigner l'équipement maître. Par exemple, en cas d'égalité des indicateurs de priorité pour deux équipements, l'adresse MAC peut être utilisée pour les départager. Par exemple encore, le message de forçage peut être considéré comme supérieur aux autres critères, ce qui peut conduire à désigner l'équipement associé au message comme maître, peu 25 importe les autres critères. D'autres combinaisons de critères sont possibles. Une fois l'équipement maître déterminé, il est possible de déterminer un autre équipement maître alternatif. Ce dernier peut servir d'équipement maître en cas de défaillance de l'équipement maître désigné en premier ou en cas de déconnexion de celui-ci. La désignation de l'équipement maître alternatif 30 est faite lors de l'étape 305 (DET MASTR*) de manière similaire à ce qui a été décrit pour l'étape 304. L'équipement désigné comme maître lors de l'étape 304 ne participe pas à l'étape 305.

Une fois l'équipement maître déterminé (et éventuellement le ou les équipements maître alternatifs), les équipements sont configurés de façon à tenir compte de la gestion des communications par l'équipement maître. Cette configuration est mise en oeuvre lors de l'étape 306 (CONFIG).

Il s'agit par exemple, pour chaque équipement de déclarer les applications de communication qu'il met en oeuvre, ou les moyens de communication dont il dispose. Une fois ce type de déclarations faites, l'équipement maître peut déterminer le type de moyens de communications qu'il aura à gérer pour le compte des autres équipements.

Ainsi, lorsque plusieurs équipements mettent en oeuvre la même application de communication, ils s'en remettent à l'équipement maître pour la mise en oeuvre effective de la communication vers l'extérieur. Lorsque la configuration est terminée, l'équipement maître est reconnecté au monde extérieur lors de l'étape 307 (CONN.) pour la mise en 15 oeuvre des communications. Le mécanisme d'élection décrit ci-dessus peut permettre d'élire un ou plusieurs dispositifs maîtres. En effet, un dispositif maître peut être élu pour chaque application mise en oeuvre par une pluralité d'équipements. La suite de la description est faite dans le contexte du système 20 OWAG à titre purement illustratif. L'invention ne se limite toutefois pas à ce système ou à ce type de système. Il est considéré que les applications LGCM et OAMS du système OWAG sont installées sur le serveur ANSU-AFMR du domaine NSS Flight ops et aussi sur des équipements informatiques connectés au domaine. Ainsi, les 25 applications LGCM et OAMS peuvent être exécutées sur le serveur ANSUAFMR, mais aussi sur d'autres équipements tels que des EFB (de classe 1, 2 ou 3). Conformément au processus général décrit ci-avant, un dialogue et instauré entre les différentes instances LGCM et OAMS du domaine dans le but 30 d'élire une seule instance « LGCM Maître » (c'est-à-dire une exécution de l'application LGCM sur un équipement maître pour cette application) et une seule instance « OAMS Maître » (c'est-à-dire une exécution de l'application OAMS sur un équipement maître pour cette application), qui assurent effectivement les fonctions LGCM et OAMS pour le compte de toutes les instances de ces applications au sein du domaine NSS Flight ops. Si plusieurs équipements informatiques sont configurés pour 5 exécuter le système OWAG, des instances « LGCM Secours » et « OAMS Secours » peuvent également être désignées. Les autres instances LGCM et OAMS qui s'exécutent sur les autres équipements du domaine (celles qui ne sont ni « maître » ou « secours ») sont mises en attente, disponibles pour participer au processus d'élection suivant. 10 Une fois le processus d'élection automatique mis en oeuvre, un processus de partage dynamique des moyens de communication est mis en oeuvre. Le LGCM maître précédemment élu est informé par les différents équipements informatiques du domaine de la liste de tous les moyens de 15 communication bord-sol disponibles au sein du domaine NSS Flight ops. Ces moyens de communication peuvent être offerts par l'aéronef lui-même (c'est-à-dire par des équipements intégrés à celui-ci), ou par des équipements informatiques connectés au domaine (par exemple des EFB classe 1, 2 ou 3, des tablettes tactiles, des ordinateurs portables ou autre). 20 En tant qu'équipement élu, le LGCM Maître a pour rôle de gérer l'ensemble des moyens de communication du domaine. Ainsi, les moyens de communication offerts par un équipement du domaine sont utilisables par tous les équipements de ce domaine. L'OAMS Maître précédemment élu gère quant à lui les messages 25 envoyés et reçus par les applications communicantes du domaine. Avec l'utilisation d'équipements Maîtres et Secours, on peut profiter d'un mécanisme de redondance de service. Les instances LGCM Maître et LGCM Secours disposent en permanence du même niveau d'information afin que le LGCM Secours prenne 30 immédiatement le relais en cas de panne ou de déconnexion éventuelle de l'équipement informatique sur lequel l'instance LGCM Maître est exécutée.

Les instances OAMS Maître et OAMS Secours disposent quant à elles en permanence du même niveau d'information afin qu'aucune information à transmettre et en cours de transmission ne soit perdue ou dupliquée. Les équipements informatiques du domaine NSS Flight ops (nativement présents ou connectés par la suite) peuvent communiquer entre eux et échanger des informations, notamment pour le mécanisme d'élection, car ils sont interconnectés en réseau. Ces interconnexions peuvent être câblées (Ethernet par exemple), ou sans fil (WiFi par exemple). Dans le document WO 2008/139062, les logiciels LGCM (gestion de 10 communications) et OAMS (serveur de messagerie) du système OWAG sont installés sur un seul équipement: le serveur ANSU-AFMR du domaine NSS Flight ops. Dans le présent exemple d'illustration, les logiciels LGCM et OAMS sont installés et exécutés sur une pluralité d'équipements informatiques (voire 15 tous) du domaine capables d'exécuter ces logiciels. Il s'agit du serveur ANSU- AFMR, mais aussi de tous les équipements informatiques à-même de se connecter en réseau au domaine à un moment donné : des ordinateurs portables, des EFB classe 1, 2, 3, des tablettes tactiles, ou autres équipements mobiles. 20 Conformément à la description générale décrite ci-avant, afin d'éviter que les rôles LGCM et OAMS soient assurés simultanément par plusieurs équipements, une phase d'élection préalable à l'activation proprement dite des services LGCM et OAMS est mise en oeuvre. Ainsi, un « LGCM Maître » et un « OAMS Maître » sont élus. Les principes décrits ici pour LGCM et OAMS 25 pourraient être appliqués à d'autres types d'applications. La phase d'élection peut être mise en oeuvre lors de la mise sous tension de l'aéronef (ou plus particulièrement lors de l'activation du NSS), la connexion d'un nouvel équipement informatique au domaine NSS Flight ops (par exemple lorsqu'un pilote connecte une tablette dans le cockpit), la 30 déconnexion d'un équipement informatique du domaine (par exemple un pilote déconnecte sa tablette du cockpit), ou d'autres types d 'événements.

Les instances LGCM et OAMS en cours d'exécution sur les différents équipements du domaine se mettent d'abord en état « inactif ». C'est-à-dire que temporairement, elles communiquent seulement entre elles, mais elles ne communiquent plus avec l'extérieur.

Les instances LGCM et OAMS entrent dans une phase de dialogue, au travers du réseau du domaine NSS Flight Ops, afin que soient désignés automatiquement et sans ambiguïté, une seule instance LGCM Maître et une seule instance OAMS Maître. Les instances ci-dessus élues restent à l'état inactif dans cette étape.

Lors de l'installation des logiciels LGCM et OAMS sur les équipements du domaine, un « poids » est attribué aux instances LGCM et OAMS de façon à être utilisé comme critère d'élection. Ce poids (ou donnée de priorité) peut être attribué par la compagnie aérienne qui exploite l'aéronef. Ce poids peut être modifiable au cours du temps.

D'autres informations peuvent être utilisées, notamment pour départager les équipements à égalité sur un autre critère. Ainsi, par exemple, en cas d'égalité sur les poids attribués à deux équipements, les adresses MAC des coupleurs Ethernet des équipements informatique peuvent être utilisées pour déterminer un ordre de préférence.

Dans un premier exemple, purement illustratif, on considère que l'instance LGCM a un poids de « 1 » sur l'ANSU-AFMR, un poids de « 2 » sur un EFB classe 3 d'un co-pilote et un poids de « 3 » sur une tablette du pilote. On considère par ailleurs que l'instance OAMS a un poids de « 1 » sur l'ANSUAFMR, un poids de « 2 » sur l'EFB classe 3 du co-pilote et un poids de « 3 » sur la tablette du pilote. Dans cet exemple, au terme du processus d'élection, les instances LGCM et OAMS qui s'exécutent sur le serveur ANSU-AFMR sont désignées « LGCM Maître » et « OAMS Maître » car elles bénéficient du poids le plus important (« 3 »). On considère ici que les poids sont des entiers et que le poids de « 1 » est le plus important, que le poids de « 2 » vient ensuite, et ainsi de suite.

Dans un deuxième exemple, purement illustratif, on considère que l'instance LGCM a un poids de « 1 » sur l'ANSU-AFMR, un poids de « 2 » sur un EFB classe 3 d'un co-pilote et un poids de « 3 » sur une tablette du pilote. On considère par ailleurs que l'instance OAMS a un poids de « 1 » sur l'ANSU- AFMR qui a une adresse MAC « B », un poids de « 2 » sur l'EFB classe 3 du co-pilote et un poids de « 1 » sur la tablette du pilote qui a une adresse MAC « A ». Dans cet exemple, au terme du processus d'élection, l'instance LGCM qui s'exécute sur le serveur ANSU-AFMR est désignée « LGCM Maître » car elle a le poids le plus important (« 1 ») et l'instance OAMS qui s'exécute sur la Tablette Pilote sera désignée « OAMS Maître » car elle a le poids le plus important « 1 » avec celle de l'ANSU-AFMR et qu'elle a une adresse MAC prioritaire (on suppose que l'adresse MAC A du cockpit, ou du poste du pilote est prioritaire sur celle de l'ANSU-AFMR).

Une interface peut être fournie aux pilotes de façon à ce qu'ils puissent, quels que soient les poids définis au préalable, forcer l'élection du « LGCM Maître » et du « OAMS Maître » sur le(s) équipement(s) qu'ils préfèrent. Ainsi, ils peuvent émettre un message de forçage pour attribuer le rôle de maître à leurs équipements. Ce message de forçage peut aussi émaner d'un 20 équipement de contrôle, par exemple en cas de détection de panne ou autre. Dans le cas où plusieurs instances LGCM et OAMS sont en exécution dans le domaine NSS Flight Ops, le processus d'élection continue afin que soient désignés automatiquement et sans ambiguïté, une instance « LGCM Secours » et une instance « OAMS Secours ». Les instances ci-dessus 25 élues restent à l'état « inactif » dans cette étape. Une fois le mécanisme d'élection terminé, Les diverses instances LGCM en cours d'exécution annoncent au LGCM Maître et au LGCM Secours la liste des moyens de communication bord-sol offerts par l'équipement informatique sur lequel ces instances s'exécutent. Ainsi, le LGCM Maître et le 30 LGCM Secours ont connaissance de tous les moyens de communication du domaine qu'ils ont à gérer. En fonction des équipements connectés sur le domaine à un instant donné, le LGCM Maître se retrouve avec plus ou moins de moyens de communication à gérer. Dans le cas où plusieurs équipements du domaine offrent un même moyen de communication (par exemple une connectivité cellulaire offerte à la fois par une Tablette et un ordinateur portable de classe 3 connectés), le LGCM Maître choisit d'en activer un seul et de désactiver les autres. Les instances LGCM précédemment élues restent à l'état « inactif » dans cette étape. Les diverses instances OAMS en cours d'exécution confient quant à elles à l'OAMS Maître la liste de tous les messages qu'ils ont à gérer. Ainsi, l'OAMS Maître centralise l'ensemble des messages qu'il à traiter. L'OAMS Secours se synchronise avec l'OAMS Maître afin de disposer lui aussi de l'ensemble des messages à traiter. Les instances précédemment élues restent à l'état « inactif » dans cette étape.

Une fois ces informations relatives aux types de communications prises en charge par les logiciels, le LGCM Maître et le LGCM Secours passent à l'état « actif », les autres instances LGCM restent à l'état « inactif ». A partir de cette étape, le LGCM Maître gère de façon effective tous les moyens de communication bord-sol du domaine. Par exemple, cette gestion peut se faire conformément aux enseignements du document WO 2008/139062. En outre, le LGCM Secours reste, quant à lui, prêt à prendre le relai immédiatement en cas de défaillance du LGCM Maître. Par ailleurs, l'OAMS Maître et l'OAMS Secours passent à l'état « actif », les autres instances OAMS restent à l'état « inactif ».

A partir de cette étape, l'OAMS Maître communique avec les applications bord au travers des différentes OAMS API et avec le serveur GAMS au sol de la compagnie aérienne. L'OAMS Maître traite de façon effective tous les messages à transmettre/recevoir. Par exemple, ce traitement peut se faire conformément aux enseignements du document WO 2008/139062. L'OAMS Secours reste quant à lui prêt à prendre le relais immédiatement en cas de défaillance de l'OAMS Maître. 3005 824 17 La figure 4 illustre le contexte de réalisation décrit ci-dessus. Un réseau NSS 400 comporte, de manière illustrative, quatre équipements configurés pour la mise en oeuvre du système OWAG. Ces équipements sont connectés sur le réseau du domaine NSS Flight Ops. 5 La plateforme NSS 401 (NSS_PLATFRM), dispose de moyens de communication bord-sol 402 (COM), tels que par exemple un WiFi Gatelink, un Satcom SBB, un Wired Gatelink ou autre. La plateforme comporte par ailleurs un système OWAG virtuel 403 (OWAG) avec un moteur d'élection 404 (ELECT) pour mettre en oeuvre le 10 mécanisme d'élection décrit ci-avant) , un module LGCM 405 dont le poids attribué est « 2 » et un module OAMS 406 dont le poids attribué est « 4 ». La plateforme comporte aussi un jeu de fonctionnalités primitives 407 (OAMS API) pour la mise en oeuvre des communications et un jeu d'applications diverses 408 (APPS) pour mettre en oeuvre d'autres fonctionnalités. 15 La plateforme peut mettre en oeuvre des communications filaires 409 ou des communications sans fil 410 avec d'autres équipements informatiques du système NSS. Le NSS comporte un ordinateur portable 411 de classe 3. Celui-ci est connecté à la plateforme, via la communication filaire 409. Cet ordinateur 20 portable comporte un système OWAG virtuel 412 (OWAG) avec un moteur d'élection 413 (ELECT) pour mettre en oeuvre le mécanisme d'élection décrit ci-avant) , un module LGCM 414 dont le poids attribué est « 4 » et un module OAMS 415 dont le poids attribué est « 2 ». La plateforme comporte aussi un jeu de fonctionnalités primitives 416 (OAMS API) pour la mise en oeuvre des 25 communications et un jeu d'applications diverses 417 (APPS) pour mettre en oeuvre d'autres fonctionnalités. Contrairement à la plateforme NSS, l'ordinateur portable 411 n'a pas de moyens de communication bord-sol. Le NSS comporte aussi un ordinateur portable 418 de classe 2. 30 Celui-ci est connecté à la plateforme, via la communication sans fil 410. Cet ordinateur portable comporte un système OWAG virtuel 419 (OWAG) avec un moteur d'élection 420 (ELECT) pour mettre en oeuvre le mécanisme d'élection décrit ci-avant) , un module LGCM 421 dont le poids attribué est « 3 » et un module OAMS 422 dont le poids attribué est « 1 ». La plateforme comporte aussi un jeu de fonctionnalités primitives 423 (OAMS API) pour la mise en oeuvre des communications et un jeu d'applications diverses 424 (APPS) pour mettre en oeuvre d'autres fonctionnalités. L'ordinateur portable 418 dispose de moyens de communication bord-sol 425 (COM_CELL) de type cellulaire. Le NSS comporte aussi une tablette 426 de classe 2. Celle-ci est connectée à la plateforme, via la communication sans fil 410. Cet ordinateur portable comporte un système OWAG virtuel 427 (OWAG) avec un moteur d'élection 428 (ELECT) pour mettre en oeuvre le mécanisme d'élection décrit ci-avant) , un module LGCM 429 dont le poids attribué est « 1 » et un module OAMS 430 dont le poids attribué est « 3 ». La plateforme comporte aussi un jeu de fonctionnalités primitives 431 (OAMS API) pour la mise en oeuvre des communications et un jeu d'applications diverses 432 (APPS) pour mettre en oeuvre d'autres fonctionnalités. La tablette 426 dispose de moyens de communication bord-sol 433 (COM_CELL) de type cellulaire. Pour la mise en oeuvre du mécanisme d'élection, les moteurs d'élection peuvent communiquer entre eux (flèches 434) via le NSS. Dans l'exemple de la figure 4, le mécanisme d'élection conduit à attribuer les rôles suivants (on rappelle que plus le poids est faible en valeur, c'est-à-dire proche de « 1 », plus l'équipement est prioritaire, on rappelle également que l'adresse MAC peut servir à départager des équipements de même poids et que les équipements de secours sont déterminés après avoir déterminé les équipements maîtres, pour chaque application) : - LGCM Maître : Tablette 426 car elle a le poids le plus prioritaire pour cette application - LGCM Secours : plateforme NSS 401 car elle a le poids le plus prioritaire après la tablette 426 pour cette application - LGCM Inactifs : les ordinateurs portables 411 et 418 (car ils ne sont ni maître si secours) - OAMS Maître : ordinateur 418 car a le poids le plus prioritaire pour cette application - OAMS Secours : ordinateur 411 car il a le poids le plus prioritaire après l'ordinateur 418 pour cette application - OAMS Inactifs : plateforme NSS 401 et tablette 426 (car elles ne sont ni maître si secours). Le mécanisme de mise en commun des moyens de communication du domaine conduit à confier au LGCM Maître la liste des moyens de communication suivants : - WiFi Gatelink (via plateforme NSS) - Wired Gatelink (via plateforme NSS) - Cellulaire (via ordinateur portable 418 et tablette 426). Ici, le LGCM Maître choisit par exemple de n'activer que le Cellulaire offert par le l'ordinateur 418.

Un programme d'ordinateur pour la mise en oeuvre d'un procédé selon un mode de réalisation de l'invention peut être réalisé par la personne du métier à la lecture de l'organigramme de la figure 3 et de la présente description détaillée. La figure 5 illustre un équipement selon des modes de réalisation.

L'équipement 50 comporte une unité de mémoire 51 (MEM). Cette unité de mémoire comporte une mémoire vive pour stocker de manière non durable des données de calcul utilisées lors de la mise en oeuvre d'un procédé selon un mode de réalisation. L'unité de mémoire comporte par ailleurs une mémoire non volatile (par exemple du type EEPROM) pour stocker par exemple un programme d'ordinateur selon un mode de réalisation pour son exécution par un processeur (non représenté) d'une unité de traitement 52 (PROC) de l'équipement. La mémoire peut également stocker d'autres données évoquées ci-avant. L'équipement comporte par ailleurs une unité de communication 53 30 (COM) pour mettre en oeuvre des communications, par exemple pour communiquer avec d'autres équipements conformément aux enseignements ci-avant ou avec le sol.

La présente invention a été décrite et illustrée dans la présente description détaillée en référence aux figures jointes. Toutefois la présente invention ne se limite pas aux formes de réalisation présentées. D'autres variantes, modes de réalisation et combinaisons de caractéristiques peuvent être déduits et mis en oeuvre par la personne du métier à la lecture de la présente description et des figures annexées. Pour satisfaire des besoins spécifiques, une personne compétente dans le domaine de l'invention pourra appliquer des modifications ou adaptations.

Dans les revendications, le terme "comporter" n'exclut pas d'autres éléments ou d'autres étapes. L'article indéfini « un » n'exclut pas le pluriel. Un seul processeur ou plusieurs autres unités peuvent être utilisées pour mettre en oeuvre l'invention. Les différentes caractéristiques présentées et/ou revendiquées peuvent être avantageusement combinées. Leur présence dans la description ou dans des revendications dépendantes différentes, n'exclut pas en effet la possibilité de les combiner. Les signes de référence ne sauraient être compris comme limitant la portée de l'invention.

Claims (14)

1. REVENDICATIONS1. Procédé de configuration de gestion de communications à bord d'un aéronef (100) comportant les étapes suivantes: - de détection (300) d'un événement de configuration de gestion de communication, - d'échange (303) d'informations relatives à au moins un critère d'élection d'un équipement maître dans un réseau (101) d'équipements informatiques en charge de communications bord-sol de l'aéronef, - de détermination (304) d'un équipement maître en fonction desdites informations échangées, - de configuration (306) de gestion de communication en fonction dudit équipement maître déterminé.
2. 2. Procédé selon la revendication 1, dans lequel, ledit événement est au moins l'un parmi : - une mise sous tension de l'aéronef, - une connexion d'un équipement informatique en charge de communications bord-sol de l'aéronef audit réseau, et - une déconnexion d'un équipement informatique en charge de communications bord-sol de l'aéronef dudit réseau.
3. 3. Procédé selon l'une des revendications précédentes, dans lequel au moins l'une desdites informations échangées comporte au moins l'un ou l'une parmi: - une donnée de priorité respectivement associé aux équipements informatiques connectés audit réseau, - une adresse réseau respectivement associé aux équipements informatiques connectés audit réseau, et - un message de forçage en provenance d'une autorité de gestion des communications.
4. 4. Procédé selon la revendication 3, dans lequel les adresses réseaux des équipements sont prises en compte pour départager des équipements associés à une même donnée de priorité.
5. 5. Procédé selon l'une des revendications 3 et 4, dans lequel lorsqu'un message de forçage en provenance d'une autorité de gestion des communications est échangé, l'équipement associé audit message est déterminé comme équipement maître.
6. 6. Procédé selon l'une des revendications précédentes, comportant en outre une étape de désactivation (302) d'au moins un service de communication bord-sol suite à la détection dudit événement.
7. 7. Procédé selon l'une des revendications précédentes, dans lequel ladite étape de configuration comporte une transmission, par au moins un équipement dudit réseau, à destination dudit équipement maître déterminé, d'au moins un message relatif à un type de communication prise en charge par ledit équipement.
8. 8. Procédé selon la revendication 7, dans lequel ledit type de communication identifie un moyen de communication disponible auprès dudit équipement, ladite étape de configuration comportant en outre une étape d'activation dudit moyen de communication disponible auprès dudit équipement.
9. 9. Procédé selon la revendication 8, comportant en outre une étape de désactivation d'au moins un autre moyen de communication équivalent aussi moyen de communication activé, ledit autre moyen de communication étant disponible auprès d'un autre équipement dudit réseau.
10. 10. Procédé selon l'une des revendications 7 à 9, dans lequel ledit type de communication identifie une catégorie de messages, ladite étape deconfiguration comportant la prise en charge, par ledit équipement maître déterminé de ladite catégorie de messages, pour le compte des équipements dudit réseau.
11. 11. Procédé selon l'une des revendications précédentes comportant en outre une étape de détermination (305) d'un équipement de secours en fonction desdites informations échangées, ledit équipement de secours étant configuré pour fonctionner en tant qu'équipement maître en cas de défaillance de celui-ci.
12. 12. Equipement informatique (50, 411, 418, 426, 403) de gestion de communications à bord d'un aéronef comportant une unité de traitement configurée pour détecter un événement de configuration de gestion de communication, échanger des informations relatives à au moins un critère d'élection d'un équipement maître dans un réseau d'équipements informatiques en charge de communications bord-sol de l'aéronef, déterminer un équipement maître en fonction desdites informations échangées, et configurer la gestion de communication en fonction dudit équipement maître déterminé.
13. 13. Système (400) de communication à bord d'un aéronef comportant une pluralité d'équipements selon la revendication 12.
14. 14. Aéronef (100) comportant un système selon la revendication 13.