FR3103300A1 - Espace collaboratif de gestion de contexte de plan de vol - Google Patents
Espace collaboratif de gestion de contexte de plan de vol Download PDFInfo
- Publication number
- FR3103300A1 FR3103300A1 FR1912712A FR1912712A FR3103300A1 FR 3103300 A1 FR3103300 A1 FR 3103300A1 FR 1912712 A FR1912712 A FR 1912712A FR 1912712 A FR1912712 A FR 1912712A FR 3103300 A1 FR3103300 A1 FR 3103300A1
- Authority
- FR
- France
- Prior art keywords
- modification
- flight plan
- objects
- message
- interaction
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000012986 modification Methods 0.000 claims abstract description 316
- 230000004048 modification Effects 0.000 claims abstract description 316
- 238000000034 method Methods 0.000 claims abstract description 28
- 238000004590 computer program Methods 0.000 claims abstract description 3
- 238000004891 communication Methods 0.000 claims description 61
- 230000003993 interaction Effects 0.000 claims description 54
- 238000004364 calculation method Methods 0.000 claims description 45
- 238000010200 validation analysis Methods 0.000 claims description 33
- 230000006870 function Effects 0.000 claims description 29
- 230000008859 change Effects 0.000 claims description 17
- 238000012217 deletion Methods 0.000 claims description 16
- 230000037430 deletion Effects 0.000 claims description 16
- 238000007726 management method Methods 0.000 description 36
- 238000007792 addition Methods 0.000 description 7
- 238000003780 insertion Methods 0.000 description 4
- 230000037431 insertion Effects 0.000 description 4
- 230000001360 synchronised effect Effects 0.000 description 4
- 230000000644 propagated effect Effects 0.000 description 3
- 230000002441 reversible effect Effects 0.000 description 3
- RZVHIXYEVGDQDX-UHFFFAOYSA-N 9,10-anthraquinone Chemical compound C1=CC=C2C(=O)C3=CC=CC=C3C(=O)C2=C1 RZVHIXYEVGDQDX-UHFFFAOYSA-N 0.000 description 2
- 230000009471 action Effects 0.000 description 2
- 238000011161 development Methods 0.000 description 2
- 230000018109 developmental process Effects 0.000 description 2
- 235000021183 entrée Nutrition 0.000 description 2
- 230000002452 interceptive effect Effects 0.000 description 2
- 230000004807 localization Effects 0.000 description 2
- 230000008569 process Effects 0.000 description 2
- 230000004044 response Effects 0.000 description 2
- KRQUFUKTQHISJB-YYADALCUSA-N 2-[(E)-N-[2-(4-chlorophenoxy)propoxy]-C-propylcarbonimidoyl]-3-hydroxy-5-(thian-3-yl)cyclohex-2-en-1-one Chemical compound CCC\C(=N/OCC(C)OC1=CC=C(Cl)C=C1)C1=C(O)CC(CC1=O)C1CCCSC1 KRQUFUKTQHISJB-YYADALCUSA-N 0.000 description 1
- 241001080024 Telles Species 0.000 description 1
- 241000897276 Termes Species 0.000 description 1
- 230000004913 activation Effects 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 230000002457 bidirectional effect Effects 0.000 description 1
- 239000012530 fluid Substances 0.000 description 1
- 239000000446 fuel Substances 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000005457 optimization Methods 0.000 description 1
- 230000035515 penetration Effects 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 230000001629 suppression Effects 0.000 description 1
- 238000012800 visualization Methods 0.000 description 1
- 230000001755 vocal effect Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/10—Office automation; Time management
- G06Q10/101—Collaborative creation, e.g. joint development of products or services
-
- G—PHYSICS
- G08—SIGNALLING
- G08G—TRAFFIC CONTROL SYSTEMS
- G08G5/00—Traffic control systems for aircraft, e.g. air-traffic control [ATC]
- G08G5/003—Flight plan management
- G08G5/0039—Modification of a flight plan
-
- G—PHYSICS
- G08—SIGNALLING
- G08G—TRAFFIC CONTROL SYSTEMS
- G08G5/00—Traffic control systems for aircraft, e.g. air-traffic control [ATC]
- G08G5/0004—Transmission of traffic-related information to or from an aircraft
- G08G5/0013—Transmission of traffic-related information to or from an aircraft with a ground station
-
- G—PHYSICS
- G08—SIGNALLING
- G08G—TRAFFIC CONTROL SYSTEMS
- G08G5/00—Traffic control systems for aircraft, e.g. air-traffic control [ATC]
- G08G5/0017—Arrangements for implementing traffic-related aircraft activities, e.g. arrangements for generating, displaying, acquiring or managing traffic information
- G08G5/0021—Arrangements for implementing traffic-related aircraft activities, e.g. arrangements for generating, displaying, acquiring or managing traffic information located in the aircraft
-
- G—PHYSICS
- G08—SIGNALLING
- G08G—TRAFFIC CONTROL SYSTEMS
- G08G5/00—Traffic control systems for aircraft, e.g. air-traffic control [ATC]
- G08G5/0017—Arrangements for implementing traffic-related aircraft activities, e.g. arrangements for generating, displaying, acquiring or managing traffic information
- G08G5/0026—Arrangements for implementing traffic-related aircraft activities, e.g. arrangements for generating, displaying, acquiring or managing traffic information located on the ground
-
- G—PHYSICS
- G08—SIGNALLING
- G08G—TRAFFIC CONTROL SYSTEMS
- G08G5/00—Traffic control systems for aircraft, e.g. air-traffic control [ATC]
- G08G5/0047—Navigation or guidance aids for a single aircraft
- G08G5/006—Navigation or guidance aids for a single aircraft in accordance with predefined flight zones, e.g. to avoid prohibited zones
Landscapes
- Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Aviation & Aerospace Engineering (AREA)
- Business, Economics & Management (AREA)
- Entrepreneurship & Innovation (AREA)
- Human Resources & Organizations (AREA)
- Computer Networks & Wireless Communication (AREA)
- Strategic Management (AREA)
- Economics (AREA)
- Data Mining & Analysis (AREA)
- Marketing (AREA)
- Operations Research (AREA)
- Quality & Reliability (AREA)
- Tourism & Hospitality (AREA)
- General Business, Economics & Management (AREA)
- Theoretical Computer Science (AREA)
- Radar, Positioning & Navigation (AREA)
- Remote Sensing (AREA)
- Traffic Control Systems (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Navigation (AREA)
Abstract
L’invention concerne la gestion des éléments du contexte d’un ou des plans de vols. Plus spécifiquement, l’invention concerne des systèmes, méthodes et programmes d’ordinateur permettant un travail collaboratif en temps réel sur et autour d’un ou des plans de vol entre plusieurs systèmes distants. Pour ce faire, un premier système selon l’invention comprend la réception d’une modification, effectuée sur un deuxième système, d’un plan de vol et d’un ensemble d’objets associés ou d’un autre ensemble d’objets non associés, l’affichage de la modification, et, si la modification est validée, le renvoi de la modification, telle qu’appliquée sur le premier système, au deuxième système pour assurer l’unicité autour de l’espace collaboratif de navigation entre des intervenants distants. Figure pour l’abrégé : Fig. 1
Description
Domaine de l’invention
La présente invention concerne le domaine de l’avionique et plus particulièrement de la définition de la gestion des plans de vols d’aéronefs et de leur contexte.
Etat de l’art précédent
Etat de l’art précédent
Les plans de vols sont utilisés pour calculer les trajectoires suivies par les aéronefs, et permettre aux différents opérateurs (pilote, contrôleur aérien…) d’évaluer, à l’avance, le chemin qui sera suivi par l’aéronef. Les plans de vols sont généralement définis par une succession de points de cheminement, chaque point de cheminement étant généralement associé à un temps de passage et une altitude.
De manière classique, le pilote d’un aéronef dispose d’un affichage du plan de de vol, lui permettant de visualiser le contexte de plan de vol actuel incluant le plan de vol et l’environnement tel que la météo, les NOTAMs, le trafic, les espaces aériens, etc, mais également de le modifier. La modification peut alors être soumise à un système de gestion de vol qui vérifie que le plan de vol modifié sera bien volable par l’aéronef, et valide ou non la modification.
Il est également intéressant pour des opérateurs au sol, notamment les centres CCS (Centre de Contrôle au Sol) comprenant les centres de contrôle aérien (ATC Air Traffic Control) et les centres opérationnels des opérateurs (OCC), de connaître le contexte de plan de vol de l’aéronef. En particulier, les opérateurs et systèmes au sol et à bord doivent pouvoir communiquer sur le plan de vol de l’aéronef, pour différentes raisons: si le pilote modifie le plan de vol, les contrôleurs aériens CCS doivent en être informés pour pouvoir vérifier que le nouveau plan de vol est bien compatible avec les contraintes de l’espace aérien (par exemple, avec les trajectoires des autres aéronefs, les espaces aériens…). Inversement, un CCS peut demander une modification du plan de vol à l’aéronef, par exemple pour s’adapter à des modifications de la circulation aérienne dans l’espace aérien courant ou à des besoins opérationnels de l’opérateur. De manière plus générale, des opérateurs au sol ou à bord peuvent soumettre une modification du plan de vol.
Aujourd’hui, les possibilités de communications entre le sol et le bord comprennent l’échange de messages radios entre le sol et le bord. Ces messages peuvent prendre la forme de communication vocales, ou d’échanges de données. Si ces messages permettent de soumettre des modifications du plan de vol du sol vers le bord, ou inversement, les possibilités d’interaction restent limitées.
En effet, dans les procédures actuelles, lorsque des modifications du plan de vol sont demandées, le plan de vol est défini soit au sol par le CCS soit à bord, et le nouveau plan de vol est renvoyé en entier à l’autre partie. Ceci induit plusieurs désavantages. Tout d’abord, le volume de données échangées est très important. Ceci induit une latence dans les communications, et un engorgement des canaux de données entre le bord et le sol. De plus, l’interaction entre le sol et le bord est limitée: si une modification du plan de vol, ou d’un paramètre de calcul de celui-ci est soumise par le sol ou le bord, le temps de validation de la modification sera important. Enfin, ces communications ne permettent pas de s’assurer qu’un plan de vol identique est partagé en temps réel entre le sol et le bord.
Le même problème se pose de manière plus générale lorsque plusieurs opérateurs travaillent à distance sur le plan de vol d’un aéronef. Par exemple, plusieurs centres de contrôle ATC ou de commande de drone peuvent suivre le plan de vol d’un drone. La même problématique de synchronisation des informations sur le plan de vol du drone se présente alors.
Il y a donc besoin d’un espace de travail partagé permettant de visualiser et modifier un plan de vol ou un contexte de plan de vol d’un aéronef de manière interactive entre plusieurs opérateurs, et ce à distance et en temps réel.
A cet effet, l’invention a pour objet un premier système comprenant: au moins un dispositif d’affichage configuré pour afficher un ensemble d’objets comprenant un plan de vol de référence de l’aéronef et au moins un objet d’environnement ou de contexte ; au moins une interface d’entrée ; au moins un port de communication configuré pour communiquer avec au moins un deuxième système ; au moins une unité de calcul configurée, à la réception, par le port de communication d’un message indiquant une première description d’une modification dudit ensemble, pour : générer l’affichage de la modification; recevoir une validation ou un rejet de la modification par l’interface d’entrée ; envoyer, par l’au moins un port de communication, un message au deuxième système contenant: en cas de validation, une deuxième description de ladite modification; sinon, une indication du rejet de la modification.
Avantageusement, l’au moins une unité de calcul est configurée, à la réception d’une modification de l’ensemble d’objets par l’interface d’entrée, pour: générer l’affichage de la modification; envoyer, par l’au moins un port de communication, un message au deuxième système contenant une première description de la modification; recevoir du deuxième système un message contenant une indication du rejet de la modification, ou une deuxième description de la modification; si le message reçu du deuxième système est un message de rejet, ou si la première et la deuxième description sont différentes, annuler la modification; sinon, valider la modification.
Avantageusement, l’au moins un objet d’environnement ou de contexte comprend au moins un objet appartenant à un type d’objets choisi dans un groupe comprenant: une zone de texte; un symbole informatif; une surface fermée; un pseudo point sur le plan de vol de référence; un élément graphique; une section de plan de vol distincte du plan de vol de référence.
Avantageusement, le premier système comprend au moins un système de gestion de vol, et dans lequel l’au moins une unité de calcul est configurée: à la réception d’une modification du plan de vol de référence par l’au moins un système de gestion de vol, afficher la modification et envoyer par l’au moins un port de communication, un message contenant une description du plan de vol de référence modifié; si ladite modification de l’ensemble d’objets reçue par l’interface d’entrée est une modification du plan de vol, et est validée, l’envoyer au système de gestion de vol.
Avantageusement, l’au moins une unité de calcul est configurée, à la réception d’une modification de l’ensemble d’objets, pour: vérifier si ladite modification du plan de vol de référence implique une interaction entre le plan de vol de référence modifié et un autre objet de l’ensemble; si la modification implique une interaction, créer un objet fonctionnel symbolisant l’interaction.
Avantageusement, l’au moins une unité de calcul est configurée pour: vérifier si la modification du plan de vol de référence implique le passage du plan de vol de référence modifié dans une surface fermée existante ou nouvelle ; si la modification implique le passage du plan de vol de référence modifié dans une surface fermée existante ou nouvelle, créer un pseudo point à l’entrée dudit plan de vol dans la surface fermée, et un pseudo-point à la sortie dudit plan de vol de la surface fermée.
Avantageusement, l’au moins une unité de calcul est configurée, à la réception d’une modification de l’ensemble d’objets, pour: vérifier si ladite modification implique une suppression de l’interaction entre le plan de vol de référence modifié et un autre objet de l’ensemble; si la modification implique la suppression de l’interaction, supprimer un objet fonctionnel symbolisant l’interaction.
Avantageusement, l’au moins une unité de calcul est configurée, à la réception d’une modification de l’ensemble d’objets comprenant l’ajout ou la modification d’un objet d’environnement ou de contexte, pour: vérifier si ladite modification implique une interaction entre le plan de vol de référence et l’objet d’environnement ou de contexte ajouté ou modifié ; si la modification implique une interaction, créer un objet fonctionnel symbolisant l’interaction.
Avantageusement, l’objet d’environnement ou de contexte ajouté ou modifié est une surface fermée ajoutée ou modifiée, et l’au moins une unité de calcul est configurée pour: vérifier si la modification implique le passage du plan de vol de référence dans la surface fermée ajoutée ou modifiée ; si la modification implique le passage du plan de vol de référence dans la surface fermée ajoutée ou modifiée, créer un pseudo point à l’entrée dudit plan de vol dans la surface fermée ajoutée ou modifiée, et un pseudo-point à la sortie dudit plan de vol de la surface fermée ajoutée ou modifiée.
Avantageusement, l’au moins une unité de calcul est configurée, à la réception d’une modification de l’ensemble d’objets comprenant la suppression d’un objet d’environnement ou de contexte, pour: vérifier si ladite modification implique une suppression de l’interaction entre le plan de vol de référence et l’objet d’environnement ou de contexte supprimé; si la modification implique la suppression de l’interaction, supprimer un objet fonctionnel symbolisant l’interaction.
Avantageusement, l’au moins une unité de calcul est configurée pour effectuer un codage d’un objet préalablement à l’envoi d’un message, et effectuer un décodage d’un objet suite à la réception d’un message, le codage de l’objet comprenant : une section de code comprenant un code prédéfini définissant le type d’objet, et pour chacun des attributs de l’objet, un code prédéfini définissant le type de l’attribut; une suite alphanumérique définissant, pour chacun des attributs, la valeur associée.
Avantageusement, dans lequel l’au moins une unité de calcul est configurée pour effectuer un codage d’une modification du plan de vol de référencepréalablement à l’envoi d’un message, et effectuer un décodage d’une modification du plan de vol de référence suite à la réception d’un message, le codage de la modification de plan de vol de référence comprenant : une section de code comprenant un code prédéfini définissant une modification du plan de vol de référence, et pour chacune des fonctions de plan de vol modifiées, un code prédéfini définissant le type de fonction; une suite alphanumérique définissant, les points de cheminement modifiés, et, pour chacune des fonctions, les valeurs de paramètres associées.
Avantageusement, la première et la deuxième modification de l’ensemble sont représentées respectivement en un premier et un deuxième codage d’un objet ou d’une modification du plan de vol de référence; l’au moins une unité de calcul est configurée pourvérifier si les première et deuxième modifications sont identiques en vérifiant si les premier et deuxième codages sont identiques.
Avantageusement, le port de communication est configuré pour communiquer avec une pluralité de deuxièmes systèmes; l’unité de calcul est configurée, à la réception, par le port de communication, du message indiquant la description de la modification, et en cas de validation, pour envoyer, par l’au moins un port de communication, à chacun des deuxièmes systèmes de ladite pluralité, le message contenant la deuxième description de la modification.
L’invention a également pour objet une méthode mise en œuvre par ordinateur comprenant: la réception, par au moins un port de communication d’un premier système, configuré pour communiquer avec au moins un deuxième système, d’un message indiquant une première description d’une modification d’un ensemble d’objets comprenant un plan de vol de référence d’un aéronef et au moins un objet d’environnement ou de contexte ; l’affichage de ladite modification sur au moins un dispositif d’affichage du premier système; la réception de la validation ou du rejet, par une interface d’entrée du premier système; l’envoi, par l’au moins un port de communication, d’un message au deuxième système contenant: en cas de validation, une deuxième description de ladite modification; sinon, une indication du rejet de la modification.
L’invention a également pour objet un programme d’ordinateur comprenant des instructions de code de programme enregistrées sur un support lisible par ordinateur, lesdites instructions de code de programme étant configurées pour: recevoir, par au moins un port de communication d’un premier système, configuré pour communiquer avec au moins un deuxième système, d’un message indiquant une première description d’une modification d’un ensemble d’objets comprenant un plan de vol de référence d’un aéronef et au moins un objet d’environnement ou de contexte; afficher ladite modification sur au moins un dispositif d’affichage du premier système; recevoir la validation ou du rejet, par une interface d’entrée du premier système; envoyer, par l’au moins un port de communication, d’un message au deuxième système contenant: en cas de validation, une deuxième description de ladite modification; sinon, une indication du rejet de la modification.
D’autres caractéristiques, détails et avantages de l’invention ressortiront à la lecture de la description faite en référence aux dessins annexés donnés à titre d’exemple et qui représentent, respectivement:
Certains acronymes anglo-saxons couramment utilisés dans le domaine technique de la présente demande pourront être employés au cours de la description. Ces acronymes sont listés dans le tableau ci-dessous, avec notamment leur expression anglo-saxonne et leur signification ainsi que la définition des principaux termes du domaine technique dans lequel se situe l’invention.
| Acronyme | Expression | Signification |
| ACARS | Aircraft Communication Addressing and Reporting System | Système de communication, d’adressage et de rapport d’aéronef. Système de communications codes entre un aéronef et le sol, défini selon les standards ARINC. L’ACARS peut notamment se baser sur des liaisons HF, VHF ou SatCom. |
| AFCS | Automatic Flight Control System | Système de Contrôle de Vol Automatique. Système de pilote automatique permettant d’actionner automatiquement les actuateurs de l’aéronef pour réaliser une trajectoire fournie en entrée. |
| ARINC | Aeronautical Radio INCorporated | Société de Radio Aéronautique. Société détenue par de grands acteurs aéronautiques américains connue pour définir les principaux standards de communication à l’intérieur des aéronefs et entre les aéronefs et le sol. Désigne à la fois la société et les standards produits, par exemple les standards ARINC 429 ou ARINC 661. |
| ATC | Air Traffic Control | Contrôle de Circulation Aérienne (CCA). Service fourni par des contrôleurs aériens au sol pour diriger un aéronef au sol en sécurité. |
| ATN | Aeronautical Telecommunication Network | Réseau de Télécommunication Aéronautique. Architecture de communication réseau permettant de faire communiquer des systèmes air et sol. |
| CCS | Centre de Contrôle Sol | Définition générique d’un système de gestion de mission de vol situé hors de l’aéronef (généralement au sol) pouvant être un Centre de Contrôle des Opérations Aériennes OCC (pour un opérateur Aérien civil ou militaire), un Centre de Contrôle Aérien (ATC) ou un Centre de Contrôle de Drones. |
| CPDLC | Controller-Pilot Data Link Communications | Lien de données de communication contrôleur-pilote. Méthode de communication entre les contrôleurs et les pilotes, définissant un ensemble de messages élémentaires pouvant être échangés. Ces messages correspondent aux procédures utilisées pour le contrôle aérien. |
| EFB | Electronic Flight Bag | Sacoche de vol électronique. Dispositif électronique de gestion de l’information permettant aux équipages d’aéronef d’effectuer des tâches de gestion de vol plus facilement et efficacement, avec moins de papier. |
| FL | Flight Level | Niveau de Vol. En aéronautique, désigne une altitude exprimée en centaines de pieds au-dessus de la surface isobare 1013,25 hPa. |
| FMS | Flight Management System | Système de Gestion de Vol. Système informatisé permettant de calculer des trajectoires et plans de vol d’aéronef, et de fournir les consignes de guidage adaptées au pilote ou pilote automatique pour suivre la trajectoire calculée. |
| FPL | Flight PLan | Plan de vol. |
| HF | High Frequency | Haute Fréquence. Fréquences radio comprises entre 3 et 30 MHz. |
| MMS | Mission Management System | Système de Gestion de Mission: système de mission permettant au pilote d’un aéronef de superviser la mission de l’aéronef. |
| NOTAM | NOTice to AirMen | Messages aux navigants aériens. Messages publiés par les agences gouvernementales de contrôle de la navigation aérienne dans le but d’informer les pilotes d’évolutions sur les infrastructures. |
| OCC | Operation Control Center | Centre de Contrôle des Opérations. Centre vers lequel convergent toutes les informations d’une compagnie aérienne pour traiter les opérations de vol. |
| OFP | Online Flight Planning | Planification de vol en ligne. Détermination de plan de vol à distance d’un aéronef. |
| SatCom | Satellite Communication | Communications Satellite. Liaisons par satellite permettant l’échange de messages entre un aéronef et le sol, notamment en zone océanique. |
| VCS | Voice Communication Systems | Systèmes de Communication Vocaux. Systèmes de communication vocale utilisés dans le trafic aérien. |
| VHF | Very High Frequency | Très Haute Fréquence. Fréquences Radio comprises entre 30 et 300 MHz. |
La figure 1 représente un exemple de deux systèmes collaborant sur un plan de vol interactif selon un ensemble de modes de réalisation de l’invention.
Dans l’exemple de la figure 1, le système 1000 est un système de bord d’un aéronef, et le système 1100 est un système de contrôle sol (CCS) des opérations aériennes. Ainsi, le système 1000 contrôle la trajectoire de l’aéronef, alors que le système 1100 interagit avec le système 1000, mais ne peut pas asservir directement la trajectoire de l’aéronef. Cependant, les systèmes 1000 et 1100 sont donnés à titre d’exemple uniquement. Selon d’autres modes de mise en œuvre de l’invention, le système 1000 peut contrôler la trajectoire d’un aéronef à distance, il peut par exemple s’agir d’un système de contrôle d’un drone à distance. De même, le système 1000 peut interagir avec plusieurs systèmes, par exemple plusieurs CCS. Les systèmes de l’invention peuvent, de manière plus générale, être des systèmes permettant la visualisation à distance du plan de vol de l’aéronef, et l’interaction avec le premier système. Il peut par exemple s’agir de centres de contrôles d’opérations, par exemple des centres de contrôle de drones de surveillance maritime.
Ainsi, l’invention peut s’appliquer de manière plus générale à tout ensemble de systèmes comprenant un système apte à visualiser le contexte de plan de vol d’un aéronef, et piloter à partir du plan de vol, et au moins un système apte à visualiser le contexte de plan de vol et interagir avec le premier système sur ce contexte de plan de vol.
Le système 1000 peut par exemple être un système de bord d’un aéronef, comprenant une application de type EFB pouvant être par exemple une application de navigation et d’optimisation du vol ou FMS étendu ayant la capacité de s’interfacer avec l’avionique, par exemple un FMS.
Le système 1000 comprend au moins un dispositif d’affichage 1010 configuré pour afficher un premier ensemble d’éléments comprenant un plan de vol de référence de l’aéronef, et en fonction des circonstances de la mission, des objets du contexte du plan de vol.
Le dispositif d’affichage peut typiquement consister en un ou plusieurs écrans de l’aéronef. Ce dispositif affiche au moins un plan de vol de l’aéronef, mais aussi des objets pouvant influer sur le ou les plans de vol. Les objets peuvent notamment comprendre:
- des éléments de l’environnement du plan de vol;
- des éléments de l’environnement, ou de contexte de l’aéronef.
Le premier système 1000 comprend également au moins une interface d’entrée 1020. Cette interface peut comprendre tout type d’interface apte à recevoir des données d’entrée de l’opérateur (dans cet exemple, du pilote de l’aéronef).
Le premier système 1000 comprend également au moins un port de communication 1030 apte à communiquer avec le système 1100. Le port de communication 1030 peut typiquement comprendre une antenne de communication radio VHF, HF ou SatCom, et, dans le cas où le système 1000 est un système de bord d’un aéronef communiquant avec le sol, la communication peut se faire par le protocole datalink. Le port de communication 1030 est donc apte à envoyer et recevoir des messages avec le système 1100.
Le système 1000 comprend enfin au moins une unité de calcul 1040. L’au moins une unité de calcul 1040 peut être n’importe quel type d’unité de calcul apte à effectuer des calculs informatiques. Par exemple, l’unité de calcul peut être un processeur configuré avec des instructions machines, un microprocesseur, un circuit intégré, un microcontrôleur, un circuit logique programmable, ou tout autre unité de calcul apte à être programmée pour effectuer des opérations de calcul.
Le système 1100 peut être un système de contrôle des opérations aériennes au Sol (CCS), ou, de manière plus générale, un système permettant de visualiser et modifier à distance le contexte de plan de vol de l’aéronef. Le système 1100 peut ainsi exécuter une application de type OFP connectée à l’outil de génération de plan de vol de l’opérateur. Le système 1100 peut également être connecté à des applications et outils, comme ceux relatifs à la météo, aux informations de vol de l’espace aérien, afin d’intégrer de manière automatisée des éléments à porter à la connaissance du premier système.
Le système 1100 comprend au moins un dispositif d’affichage 1110 configuré pour afficher un ou plusieurs plans de vol et un ensemble d’objets associé à ce ou ces plans de vol. Le dispositif d’affichage 1110 peut typiquement comprendre un ou plusieurs écrans.
Le système 1100 comprend également au moins une interface d’entrée 1120, pouvant comprendre tout type d’interface d’entrée autorisant un opérateur à entrer des données: clavier, micro, souris, etc.
Le système 1100 comprend également au moins un port de communication 1130 apte à communiquer avec le système 1000. Le port de communication 1130 peut typiquement comprendre une antenne de communication radio, et, dans le cas où le système 1000 est un système de bord d’un aéronef communiquant avec le sol, la communication peut se faire par un protocole datalink. Le port de communication 1130 est donc apte à envoyer et recevoir des messages numériques avec le premier système 1000.
Selon différents modes de réalisation de l’invention, différents protocoles de liaison de données peuvent être utilisés. Notamment les protocoles datalink dits ACARS ou ATN peuvent être utilisés pour transmettre des données entre le système 1000 et le système 1100.
Le deuxième système 1100 comprend enfin au moins une unité de calcul 1140. L’au moins une unité de calcul 1140 peut être n’importe quel type d’unité de calcul apte à effectuer des calculs informatiques. Par exemple, l’unité de calcul peut être un processeur configuré avec des instructions machines, un microprocesseur, un circuit intégré, un microcontrôleur, un circuit logique programmable, ou tout autre unité de calcul apte à être programmée pour effectuer des opérations de calcul.
L’un des objectifs de l’invention est de synchroniser, en temps réel, les premier et deuxième ensembles d’objets, afin de permettre aux opérateurs des différents systèmes de visualiser, en temps réel le même plan de vol et les mêmes objets, tout en effectuant un travail indépendant de traitement des ensembles d’objets.
A cet effet les systèmes 1000 et 1100 échangent des messages, via leurs ports de communication 1030, 1130. Afin de simplifier la figure 1, les messages envoyés du système 1100 au système 1000 sont notés 1200, et les messages envoyés du système 1000 au système 1200 sont notés 1210. Bien que la figure 1 représente un unique message 1200, et un unique message 1210, l’invention peut être appliquée à des échanges de nombreux messages successifs entre le système 1000, et le système 1100.
Le plan de vol et les objets associés peuvent être crées et modifiés de différentes manières: un opérateur, au sol ou à bord, peut apporter des modifications, par exemple en proposant une modification du plan de vol, en ajoutant une zone de texte, ou en modifiant ou ajoutant un élément d’environnement, telle qu’une zone interdite. Une modification peut également être issue d’un système de gestion de vol modifiant le plan de vol.
En cas de modification d’un ensemble d’objets sur l’un des systèmes, un message décrivant la modification est envoyé à l’un au moins des autres systèmes.
Par exemple, si une modification du deuxième ensemble d’objets est effectuée au niveau du système 1100, un message 1200 décrivant la modification est envoyé par le système 1100 au système 1000. Inversement, si une modification est effectuée sur le premier ensemble d’objets côté bord, un message 1210 décrivant la modification est envoyé du système 1000 au système 1100. Dans un ensemble de modes de réalisation de l’invention, les messages sont codés grâce à un système de code permettant de définir les objets, leurs statuts et attributs et leurs modifications. Les messages peuvent ainsi être codés et décodés de manière transparente par les systèmes 1000, 1100. Un exemple de codage et décodage d’objets est fourni en figures 7a et 7b.
A la réception d’un message 1200, 1210 indiquant une modification de l’ensemble d’objets, l’au moins une unité de calcul 1040, 1140 est configurée 1040, 1041 pour générer l’affichage de la modification. Afin de bien mettre en évidence la modification, celle-ci peut être mise en évidence de différentes manières: surbrillance, couleur, clignotement, surbrillance, surlignage, pop-up, etc. Ceci permet à l’opérateur du système recevant le message de visualiser la modification. Il peut alors utiliser l’interface d’entrée 1020, 1120 pour valider ou refuser 1042, 1142 la modification.
Si la modification est acceptée, l’ensemble d’objets est mis à jour au niveau du (des) système(s) qui a (ont) reçu la modification, côté sol ou côté bord. Ensuite, l’au moins une unité de calcul 1040, 1140 renvoie vers l’autre (les autres) système(s) une mise à jour du plan de vol dynamique et des objets associés tels qu’effectivement mis en œuvre.
Enfin, l’au moins une unité de calcul 1040, 1140 est configurée pour envoyer, par l’au moins un port de communication 1043, 1143, un message 1210, 1200 aux autres systèmes contenant :
- en cas de validation, ladite modificationdu plan de vol dynamique et des objets associés, afin d’assurer que le système émetteur et les systèmes receveurs ont un contexte de plan de vol identique et valider qu’il n’y a pas eu de corruption ;
- sinon, une indication du rejet de la modification.
Ce procédé est assujetti aux droits de modification de chacun des systèmes. Par exemple, le système sol de contrôle des opérations aériennes CCS peut proposer des modifications vers le système bord que ce dernier peut accepter, refuser ou ajuster, l’inverse pouvant ne pas être autorisé. De même le système bord peut proposer des modifications vers le système sol CCS, par exemple le Contrôle Aérien (ATC) qui peut les accepter, refuser ou ajuster, l’inverse étant dans ce cas particulier possible.
Plus concrètement, si une modification du plan de vol, ou d’un autre des objets affichés, est effectuée sur l’un des systèmes mettant en œuvre l’invention, cette modification est envoyée aux autres systèmes. L’opérateur de chacun des systèmes bord (ou sol dans le cas de l’ATC) peut alors accepter ou refuser la modification. En cas d’acceptation d’une partie ou de l’ensemble d’objets, ces derniers sont modifiés dans le système récepteur, et un message de réponse détaillant la modification telle que réalisée par le système récepteur est renvoyée. Le système envoyeur peut alors vérifier si la modification effectuée par le système est bien identique à la modification envoyée. Si c’est le cas, la modification est acceptée dans le statut de l’objet considéré.
Ainsi, l’invention permet de synchroniser la représentation du plan de vol et des objets environnants entre le système 1000 et le système 1200. En effet, des modifications effectuées d’un côté sont propagées de l’autre. Ceci permet de créer un espace de travail collaboratif, dans lequel les différents opérateurs, par exemple un pilote et un contrôleur des opérations aériennes, peuvent interagir en temps réel. On parle alors de contexte de plan de vol dynamique déterministe, car le plan de vol et son contexte sont partagés dynamiquement entre l’ensemble des systèmes collaborant au plan de vol. Il est par ailleurs déterministe au sens où il est non interprétable.
De plus, lorsqu’un message est envoyé d’un système à l’autre avec une modification, un message de réponse est renvoyé avec un statut indiquant soit le rejet de la modification, soit, lorsque la modification est acceptée, un renvoi de la même modification, ou de modifications subséquentes. Ainsi, l’envoyeur d’une modification peut vérifier si la modification a été appliquée à l’identique, ou a impliqué des modifications subséquentes.
Toutes ces caractéristiques permettent de fiabiliser et sécuriser les communications entre les différents opérateurs, en particulier entre le sol et le bord des aéronefs.
Ceci permet aussi une interaction en temps réel entre les différents opérateurs.
La latence des communications se trouve également réduite. En effet, le temps de validation d’un plan de vol à la fois par le sol et le bord est considérablement réduit par rapport aux procédures existantes: les pilotes et contrôleurs aériens n’ont par exemple pas besoin de communiquer par le biais de messages vocaux.
L’invention permet également de garantir une meilleure sécurité aérienne, car les différents opérateurs disposent en permanence, et en temps réel, d’informations à jour.
Si l’invention est, de manière générale, présentée dans le cadre d’une communication entre un aéronef et un centre de contrôle opérationnel, elle est également applicable à de nombreux autres cas, tels que la communication entre un aéronef et plusieurs autres centres de contrôle opérationnels voire tours de contrôle, ou la communication entre plusieurs centres de contrôle d’un drone.
Dans un ensemble de modes de réalisation de l’invention, le premier système 1000 comprend au moins un système de gestion de vol 1050. Si le premier système est un système de bord d’un aéronef, le système de gestion de vol peut typiquement être un FMS. Si le premier système 1000 est un système de contrôle d’un drone à distance, le système de gestion de vol 1050 peut être un système de calcul de trajectoire du drone à partir du plan de vol, au sol ou à bord. Dans tous les cas, le système de gestion de vol 1050 est apte à vérifier la capacité de l’aéronef à suivre un plan de vol, notamment au vu de ses performances aérodynamiques, à calculer une trajectoire à partir du plan de vol, et à asservir l’aéronef sur la trajectoire, par exemple en envoyant des instructions à un pilote automatique ou AFCS.
L’au moins une unité de calcul 1040 peut interagir de manière bidirectionnelle avec le système de gestion de vol 1050, pour envoyer ou recevoir des modifications du plan de vol.
Dans un ensemble de modes de réalisation de l’invention, une modification du plan de vol peut être initiée par le système de gestion de vol 1050. Elle est alors transmise à l’au moins une unité de calcul 1040, et intégrée dans l’interface graphique. Dans un ensemble de modes de réalisation de l’invention, une modification du plan de vol initiée par l’avionique n’a pas besoin d’être validée par l’opérateur du système 1000 : elle peut être directement transmise au système 1100.
Inversement, les modifications du plan de vol dans l’interface collaborative peuvent être envoyées à l’avionique, dès qu’elles sont validées à la fois au niveau du système 1000 et du système 1100, ou manuellement sur requête de l’opérateur du système 1000.
Ceci permet de s’assurer que le plan de vol collaboratif affiché sur l’interface collaborative est bien consistant avec le plan de vol utilisé par l’avionique, et de modifier dynamiquement le plan de vol depuis chacun des systèmes implémentant l’invention. Ceci permet également de prendre en compte les modifications du plan de vol issues de l’avionique.
La figure 2 représente un exemple d’une interface graphique dans un mode de réalisation de l’invention.
L’interface graphique 200 peut être utilisée aussi bien par le premier système 1000, que par le deuxième système 1100. Elle représente l’ensemble des objets de l’espace de travail.
Dans l’exemple de la figure 2, l’ensemble des objets dans l’environnement du plan de vol 210, défini notamment par les points de cheminement 211, 212, et 213, comprend:
- des zones définies le long du plan de vol:
- une zone de prédiction d’interruption de service GPS 220;
- une zone de prédiction de turbulences 221;
- des modifications du plan de vol, ou informations définies sur le plan de vol:
- un changement de vitesse 230 (passage à Mach 79);
- une création ou un changement d’offset (décalage latéral) de trajectoire à un point 231,
- une montée vers un nouveau FLà un point 213;
- un point de non-retour vers l’aérodrome de départ 240;
- un point équidistant ou équi-temps entre les aérodromes de départ et d’arrivée 241;
- des informations définies en dehors du plan de vol:
- une localisation de zone dangereuse 250;
- une localisation de zone interdite 251;
- une mise en valeur d’un aérodrome de dégagement 252.
- Une section de plan de vol inactive n’appartenant pas au plan de vol actif
De manière générale, lorsque les dernières modifications sont validées par chacun des systèmes, la même interface graphique s’affiche sur chacun des systèmes, et permet à chacun des opérateurs de disposer d’une même vue du plan de vol modifié et de son environnement pour cette mission. En effet, les opérateurs au sol peuvent voir plusieurs missions mais pour une mission donnée, le plan de vol et l’interface sont les même que ceux du vol en question. Ceci permet ainsi une interaction plus fluide entre les différents opérateurs, notamment entre les pilotes et les opérateurs au sol.
L’interface graphique 200 peut être exécutée, sous la forme d’un module spécifique, par les unités de calcul 1040, 1140 peuvent exécuter, en lien avec les dispositifs d’affichage 1010, 1110, et les interfaces d’entrée 1020, 1120 respectivement.
De nombreuses actions peuvent être effectuées sur l’interface graphique. Par exemple, les opérateurs peuvent zoomer, décaler la vue, mais également interagir avec, notamment en modifiant le plan de vol, ajoutant des objets ou en validant des objets ajoutés par d’autres opérateurs.
L’interface graphique 200 permet la définition de caractéristiques des objets, et leur placement sur la carte. Elle permet également de visualiser leur insertion, et de les envoyer vers les autres systèmes utilisant l’interface partagée.
Chacun des objets peut être défini à l’aide d’une bibliothèque d’attributs, comprenant entre autres: un type, un label, un texte, et une fonction. La forme et la position d’un objet peuvent être définies de plusieurs manières. Par exemple, elles peuvent être définies graphiquement sur l’interface de mission, sous la forme d’une succession de points, ou en rentrant des paramètres sous forme textuelle.
La figure 3 représente plusieurs exemples d’objets d’une interface graphique dans un ensemble de modes de réalisation de l’invention.
Les objets échangés par les messages, peuvent, selon différents modes de mise en œuvre de l’invention, appartenir aux différentes catégories.
Indépendamment des objets, on considère les révisions du plan de vol. Il peut s’agir de l’ajout ou la suppression d’un ou plusieurs points, de procédure(s), de section(s) de FPL. Ces révisions mettent à jour le plan de vol de manière dynamique. Par exemple, la révision 310 consiste en une instruction de révision du plan de vol de type «DirectTo» donnant instruction à l’aéronef de se rendre directement au point de cheminement WPT2, sans passer par le point de cheminement WPT1. Si cette modification est acceptée, le plan de vol initial 311, comprenant le point de cheminement WPT1, puis le point de cheminement WPT2, devient le plan de vol 312, dans lequel l’aéronef se rend directement au point de cheminement WPT2, à partir d’un point de départ géographique (latitude/longitude) T-P qui est lui aussi partagé entre le sol et le bord. Ces révisions peuvent être issues d’applications de navigation ou du système de gestion de vol 1040 et peuvent comprendre:
- des fonctions usuelles de navigation, telles que les fonctions Direct To, offset (décalage latéral), ajout, effacement de point(s), circuit d’attente, procédure(s)…;
- des mises à jour de parties de plans de vol.
Une révision du plan de vol peut être initiée par un opérateur sur l’une des interfaces 1020, 1120, ou par le système de gestion de vol 1040.
Dans un ensemble de modes de réalisation, les objets peuvent également appartenir à l’un des types suivants:
- une zone de texte;
- un symbole informatif;
- une surface fermée;
- un pseudo point défini comme un autre type de point crée par l’opérateur ou le système pouvant être fixe ou mouvant le long du plan de vol, différent d’un point de cheminement fixe issu d’une base de données ;
- un élément graphique;
- une section de plan de vol non reliée au plan de vol de référence.
De manière plus générale, tout objet graphique pouvant s’insérer dans une interface de navigation peut être utilisé par l’invention, qu’il soit de nature purement informative ou graphique (exemple: une zone de texte), ou qu’il contienne des informations susceptibles d’interagir avec le plan de vol de référence (exemple: une surface fermée représentant une zone de danger météorologique. Une révision de plan de vol est une fonction directement applicable dans la fonction de gestion de plan de vol au sens de l’état de l’art des fonctions de navigation d’un système de gestion de vol FMS, par exemple l’effacement d’un point, l’activation d’un Direct To, l’insertion d’un échelon vertical de montée…
Ces objets sont définis par un ensemble d’attributs pouvant notamment comprendre:
- un type: définit le type d’objets graphique: point, surface…;
- une position: celle-ci peut être définie de différentes manières, par exemple par des coordonnées géographiques, ou une position relative sur le plan de vol;
- un label;
- un texte;
- le cas échéant, une fonction définissant une interaction avec le plan de vol (par exemple, une zone traversée par le plan de vol génère une fonction comme un offset (décalage latéral).
Dans un ensemble de modes de réalisation de l’invention, un système peut être utilisé pour visualiser plusieurs plans de vol différents, de plusieurs aéronefs. Par exemple, un système de contrôle aérien peut afficher alternativement plusieurs plans de vols différents correspondant à différents aéronefs avec lesquels le contrôleur aérien peut communiquer.
Les objets à afficher peuvent être plus ou moins pertinents en fonction du plan de vol considéré: des objets peuvent être définis, de manière générale, à un emplacement quel que soit le plan de vol considéré. Par exemple, une surface fermée indiquant une tempête constitue un objet pertinent quel que soit le plan de vol ou l’aéronef considéré. On parlera alors d’objet universel, s’affichant quel que soit le plan de vol considéré du côté du CCS.
Au contraire certains objets ne sont pertinents que pour un plan de vol donné. Par exemple, un pseudo-point sur un plan de vol ne devra être affiché que pour un plan de vol considéré, et pas pour les autres aéronefs. On parle alors d’objet spécifique, associé à un plan de vol dynamique donné.
Dans un ensemble de modes de réalisation de l’invention, les objets universels sont affichés quel que soit le plan de vol étudié, et les objets spécifiques uniquement lorsque le plan de vol auquel il est associé est affiché. Ceci permet par exemple à un opérateur du centre de contrôle opérationnel de changer de plan de vol pour collaborer avec différents aéronefs, tout en disposant d’un ensemble d’objets universels visibles en permanence.
Un objet de type «zone de texte» peut placer un texte fournissant une indication aux autres opérateurs. Par exemple, un texte «NO ENTRY FL 200 FL 400» indique qu’une zone est interdite de vol entre les FL 200 et 400.
Les objets de type symbole peuvent être définis à partir d’une bibliothèque de symboles commune aux différents systèmes, chaque symbole étant défini par un identifiant dans la bibliothèque. Par exemple, le symbole 320 représente des ondes orographiques (ou «mountain waves» en anglais) et peut être inséré par l’un des opérateurs à tout endroit de la zone de travail pouvant être associé à une zone géographique. L’utilisation d’une base commune de symboles permet d’ajouter de manière interactive des symboles immédiatement compréhensibles par tous les opérateurs, ce qui permet une interaction encore plus fluide entre les différents opérateurs.
Des zones fermées peuvent être définies par un ensemble de positions géographiques définissant une forme géométrique, délimitée par un contour, un remplissage répondant à un critère associé à l’objet et un label. Par exemple, l’espace hachuré de la zone 330 définit un danger météorologique.
Un objet de type «mise en valeur» définit une figure géométrique disposée autour d’un objet de l’interface. Cette figure peut notamment être définie par une forme, une couleur et une épaisseur, afin de mettre en valeur un élément représenté sur l’interface. Par exemple, les objets 340 et 341 mettent respectivement en valeur les points de cheminement «SIROD», et un aéroport «LSTR», afin de signifier que l’aéroport LSTR est un aéroport préféré en diversion.
Un objet de type «section de plan de vol» représente un ensemble de points et/ou d’éléments de plan de vol indépendants du plan de vol dynamique. Par exemple, la section de plan de vol 350 définit une section de plan de vol entre les points de cheminement WPTA, WPTB, et l’aéroport ARPTI.
Un objet de type «pseudo point» représente un pseudo point du plan de vol, c’est-à-dire un point sur le plan de vol n’impliquant pas de modification ou de révision de celui-ci. Par exemple, il peut s’agir d’un point informatif. Par exemple, le pseudo-point 360, associé au label «PNR» (Point de Non-Retour), indique un point du plan de vol à partir duquel l’aéronef ne peut plus faire demi-tour pour rejoindre l’aérodrome de départ avec le carburant minimum à bord.
La figure 4 représente un premier exemple de création d’objets dérivés, avant et après révision d’un plan de vol, dans un ensemble de modes de réalisation de l’invention.
Dans un ensemble de modes de réalisation de l’invention, l’interaction de certains objets avec le plan de vol dynamique induit la création d’autres objets, que l’on pourra appeler objets dérivés.
Ainsi, à la réception d’une modification de l’ensemble d’objets, l’au moins une unité de calcul est configurée pour:
- vérifier si ladite modification implique une interaction entre le plan de vol et un autre objet de l’ensemble;
- si la modification implique une interaction, créer un objet symbolisant l’interaction. Ce nouvel objet est un objet dérivé.
Inversement, si la modification des objets implique la suppression d’une interaction avec le plan de vol, les objets dérivés correspondants peuvent être supprimés. A cet effet, chaque système selon l’invention peut tenir en permanence à jour une liste d’objets originaux, et d’objets dérivés, et ajouter ou supprimer de manière itérative des objets dérivés, lorsque les modifications des objets originaux impliquent la création ou la suppression d’une interaction avec le plan de vol.
Ceci permet de repérer automatiquement les points d’intérêts liés à l’interaction entre le plan de vol et son environnement.
Ceci peut se faire, soit lorsqu’un opérateur modifie les objets. Les objets dérivés sont alors créés localement, puis envoyés aux autres systèmes en même temps que la modification initiale.
Dans un ensemble de modes de réalisation de l’invention, lorsque des objets originaux sont créés sur un système bord, ou de manière plus générale sur un système comprenant une interface avec l’avionique, d’éventuelles modifications des objets dérivés sont calculées, puis l’ensemble des modifications (sur les objets originaux, et sur les objets dérivés) sont envoyées aux systèmes sol.
Ceci peut également se faire à la réception d’un message indiquant une modification effectuée sur un système émetteur. Dans ce cas, les modifications sur les objets dérivées sont effectuées, et un message de retour est envoyé au système émetteur, avec l’ensemble des changements appliqués, sur les objets originaux et les objets dérivés.
Dans un ensemble de modes de réalisation de l’invention, lorsque des objets originaux sont créés sur un système sol, ou plus généralement sur un système non avionique, les objets dérivés des plans de vol non affichés dans le système sol ne sont pas créés; seuls les objets originaux et les objets dérivés (issus de l’interaction avec un ou des plans de vol) sont créés. Les objets originaux sont alors envoyés vers le système bord, qui les prendra en compte pour générer les objets dérivés.
Dans un ensemble de modes de réalisation de l’invention, une interaction entre le plan de vol et les autres objets consiste à placer ou supprimer des pseudo-points lorsque le plan de vol entre ou sort d’une surface fermée. L’ajout ou la suppression des pseudo-points peut survenir, soit lorsqu’une surface fermée est ajoutée ou supprimée, soit lorsque le plan de vol est modifié. Les pseudo-points peuvent être associés à des fonctions de plan de vol dépendant de la signification de la surface fermée. La figure 6 fournit un exemple d’une telle association.
Ceci permet de repérer l’entrée et la sortie de l’aéronef de zones particulières. Par exemple, si la zone fermée représente une zone de turbulences, l’entrée et la sortie de l’aéronef des turbulences peuvent être automatiquement représentées.
D’autres types d’objets dérivés sont utilisables, selon différents modes de réalisation de l’invention. Par exemple, l’interaction entre le plan de vol et une surface ou un volume peut générer la production et la modification d’objets tels que des volumes 4D, variant dans le temps. Par exemple, ces volumes peuvent représenter la pénétration de l’aéronef dans une zone de danger.
Dans l’exemple de la figure 4, le plan de vol 410 comprend initialement les points 420, 421 et 422. Deux surfaces fermées 430, 440 sont définies dans l’environnement du plan de vol. Initialement, le plan de vol travers la surface 440, en y entrant au pseudo-point 441, et en en sortant au pseudo-point 442.
Le plan de vol est ensuite modifié en un plan de vol 411, en supprimant le point de cheminement 421: l’aéronef va alors directement du point 420 au point 422. Il ne traverse alors plus la zone 440, mais la zone 430: les pseudo-points 441 et 442 sont supprimés, mais les pseudo-points 431 et 432 sont ajoutés, respectivement à l’entrée et la sortie de l’aéronef de la surface fermée 430.
La figure 5 représente un deuxième exemple de création d’objets dérivés, avant et après révision d’un plan de vol, dans un ensemble de modes de réalisation de l’invention.
Dans cet exemple, le plan de vol 510 est constitué des points de cheminement 520, 521 et 522, et traverse la zone fermée 530. Des objets dérivés sont ainsi présents: les pseudo-points 540 et 541, représentant respectivement l’entrée et la sortie de la surface fermée 530.
Ensuite, le plan de vol 510 est modifié en un plan de vol 511: le point de cheminement 521 est remplacé par le point 523. Le plan de vol traverse alors toujours la surface 530, mais les points d’entrée et de sortie sont modifiés. En conséquence, les pseudo-points 540 et 541 sont supprimés, et remplacés par les pseudo-points 542 et 543 respectivement situés à la nouvelle entrée dans la zone 530, et à la nouvelle sortie de la zone.
La figure 6 représente un exemple de création d’un objet dérivé fonction de plan de vol après insertion d’un objet original surface fermée, dans un ensemble de modes de réalisation de l’invention.
Dans cet exemple, une surface fermée 620 est ajoutée côté sol, délimitant une zone de navigation en offset (décalage latéral) de distance à 5 miles nautiques à droite du plan de vol 600. Cette surface est traversée par le plan de vol. Après ajout côté sol, la surface est envoyée au système bord.
Le système bord vérifie alors si l’interaction entre la surface et le plan de vol induit la création d’objets dérivés. Dans cet exemple, la réponse est positive, et deux points de cheminement 630 et 631 sont ajoutés sur le plan de vol, respectivement à l’entrée du plan de vol dans la surface, et à la sortie du plan de vol de la surface. Ces points de cheminement sont associés respectivement à une fonction de début et de fin de vol en offset (décalage latéral) de 5 miles nautiques.
Cet exemple est donné à titre d’exemple non limitatif uniquement et, de manière générale, l’interaction d’une surface avec un plan de vol pour engendrer la création de points de cheminement sur le plan de vol, associé à une fonction dépendant de la signification de la surface fermée.
Les figures 7a et 7b représentent respectivement un exemple de codage d’un objet, et un exemple de codage d’une révision de plan de vol, selon un ensemble de modes de réalisation de l’invention.
Afin de pouvoir communiquer de manière déterministe les objets, et modifications des objets, les unités de calcul 1040, 1140 sont configurées pour coder les objets ajoutés ou modifiés avant l’envoi d’un message, et décoder, de manière symétrique, l’objet à la réception d’un message en vue de son inclusion. Le codage des ajouts ou modifications peut prendre différentes formes. Par exemple, un label peut être attribué aux objets ajoutés et/ou modifiés. Une estampille temporelle peut également être insérée, correspondant à la dernière modification de l’objet.
Dans l’exemple de la figure 7a, un objet 710a est défini par un ou plusieurs attributs, pouvant être par exemple choisis parmi les attributs suivants: type, position, label, texte, fonction. L’objet 710a peut par exemple être un objet de contexte ou d’environnement.
Dans un ensemble de modes de réalisation, le codage de l’objet est basé sur une liste de codes prédéfinis définissant les différents types d’objets et d’attributs, et consiste à représenter l’objet de la manière suivante:
- tout d’abord un code prédéfini représentant le type d’objets, puis, pour chaque attribut présent pour l’objet, un code prédéfini représentant chaque type d’attribut. Ces ensembles de codes représentent une section de code 721a. Cette section peut également comprendre un identifiant d’objet choisi parmi des identifiant d’un objet parmi tableau 730a d’objets déjà ajoutés dans l’interface. Ceci permet de détecter que le codage définit une modification d’un objet déjà présent, et non l’ajout d’un nouvel objet ;
- ensuite, une suite alphanumérique de caractères 722a définit, pour chaque attribut, la valeur associée.
Par exemple, un objet pourra être représenté comme ci-dessous:
- chaque type d’objet est codé sous formée alphanumérique. Par exemple, un objet de type«zone» sera représenté par l’attribut «Z», un objet de type «Mountain wave» par l’attribut «M»;
- chaque type d’objet est associé à un ensemble d’attributs prédéfinis. Par exemple les attributs d’une zone Z seront une série de positions définies sous formes de latitude et de longitudes;
- une suite de caractères alphanumériques est insérée pour chacun des attributs, par exemple une suite de caractères représentant les latitudes et les longitudes successives pour un objet de type zone.
A la réception d’un message, l’opération inverse peut être effectuée: tout d’abord la section de code 721a est décodée, ce qui permet de déterminer quel est le type d’objet décodé, et quels attributs sont présents. Ensuite, la suite alphanumérique 722a est lue afin de fournir une valeur à chacun des attributs.
Cette convention permet d’échanger des messages définissant les objets de manière déterministe: les créations et modifications d’objets peuvent être codées et décodées de manière transparente par les différents systèmes. Ce codage des objets permet donc une interopérabilité dans la gestion des objets entre les différents systèmes. Cependant, elle est donnée à titre d’exemple non limitatif uniquement, et n’importe quelle convention permettant de coder et décoder les objets peut être utilisée selon différents modes de réalisation de l’invention.
Dans un ensemble de modes de réalisation de l’invention, chaque type d’attribut est associé à une suite de caractères alphanumériques de longueur prédéfinie. Par exemple, les coordonnées géographiques des objets peuvent être définies par une suite de caractères d’une longueur donnée représentant leur latitude et leur longitude.
Ceci permet, une fois les types d’attributs utilisés par l’objet définis dans la section de code 721a, de ne stocker dans le codage de l’objet que les caractères alphanumériques nécessaires aux attributs effectivement utilisés par l’objet. Ceci permet donc de coder les objets de manière compacte, et donc d’économiser de la bande passante lors des échanges de messages.
Le codage des objets selon différents modes de réalisation de l’invention peut être combiné au codage, normalisé, des points de cheminement. Par exemple, le code normalisé d’un point de cheminement peut être inséré dans le code de l’objet échangé entre les interfaces selon l’invention.
Dans tous les cas, l’inclusion de caractères alphanumériques uniquement pour les attributs modifiés permet un codage compact et une économie de bande passante pour la communication entre les systèmes distants.
Le même principe est appliqué aux modifications de plan de vol qui peuvent être codées et décodées grâce à un codage partagé entre les différents systèmes utilisant l’invention.
Un exemple de codage de modifications de plan de vol est présenté en figure 7b. Ici encore, il ne s’agit que d’un exemple non limitatif, et tout type de codage permettant un codage et un décodage déterministe de modifications de plan de vol peut être utilisé selon différents modes de réalisation de l’invention.
Une modification du plan de vol 710b peut être définie par un ou plusieurs points de cheminement, et une ou plusieurs fonctions de plan de vol. Les fonctions peuvent être par exemple des trajectoires issues de fonctions spécifiques du système bord, telles que la trajectoire en offset (décalage latéral).
Un codage 720b des modifications du plan de vol peut comprendre:
- une section de code 721b comprenant:
- un code prédéfinit définissant qu’il s’agit d’une modification de plan de vol;
- pour chacune des fonctions de la modification, un code prédéfini définissant le type de fonction. Lorsqu’une fonction est modifiée, son identifiant peut être indiqué, parmi un tableau 730b des fonctions du plan de vol;
- une suite alphanumérique 722b définissant les coordonnées de chaque point de cheminement, et les paramètres des fonctions ajoutées.
Un exemple de codage d’une modification de plan de vol: Fonction «Direct To» (aller vers) vers le point de cheminement ABCDE. Le «Direct To» est codé «D», la suite définissant le codage fonctionnel est D ABCDE.
Comme pour les objets, cette convention permet d’échanger les modifications du plan de vol, de manière transparente entre les différents systèmes utilisant une interface partagée.
De plus, la suite alphanumérique ne contient que les valeurs de paramètres correspondant au codage des points de cheminement et fonctions effectivement présents dans la modification. Cette convention permet donc un codage compact des modifications du plan de vol, et des économies de bande passante.
Par ailleurs, le codage des objets, et modifications de plan de vol permet une validation efficace de l’intégrité des modifications.
En effet, comme expliqué plus haut, à la réception d’une modification de l’ensemble d’objets, le système récepteur applique la modification, la présente à un opérateur, et, si celui-ci approuve la modification, recode la modification, telle qu’appliquée au système récepteur, pour la renvoyer au système émetteur. Il suffit alors au système émetteur de comparer les codes de la modification envoyée, et de la modification reçue, pour vérifier l’intégrité de la modification côté récepteur: si les codes sont identiques, la modification aura bien été appliquée à l’identique côté récepteur.
Ce mécanisme de codes fournit donc une méthode simple et efficace permettant de valider l’intégrité des modifications auprès de tous les systèmes impliqués, et de s’assurer que les modifications sont correctement synchronisées par les différents systèmes.
La figure 8 représente une méthode d’application d’une modification sur un système sol, et de validation de la modification sur un système bord dans un ensemble de modes de réalisation de l’invention.
Dans cet exemple, une modification d’un ensemble d’objets d’une interface est effectuée par un contrôleur aérien dans le système 1100, et envoyée au système 1000. Cependant, cette méthode est donnée à titre d’exemple non limitatif uniquement : certaines étapes ne sont utilisées que pour certains modes de réalisation de l’invention.
De plus, la mise en œuvre par les systèmes 1000 et 1100 est donnée à titre d’exemple uniquement. De manière plus générale, cette méthode peut être mise en œuvre entre un système ayant uniquement accès à l’interface partagée, et un système ayant accès à un système de gestion de vol. De même, le pilote et le contrôleur aérien peuvent être remplacés par d’autres opérateurs, tels qu’un pilote de drone à distance.
Les figures 8 et 9 montrent respectivement des exemples de création d’objets côté sol et côté bord. En effet, bien que l’interaction côté sol et côté bord présente un grand nombre de caractéristiques symétriques, dans un ensemble de modes de réalisation de l’invention, certaines différences sont présentes. Par exemple, les modifications côté bord peuvent être considérées comme prioritaires par rapport aux modifications côté sol. Ainsi, certaines modifications côté bord ne requièrent pas de validation côté sol. De même, l’interaction avec l’avionique se fait côté bord. Ces principes peuvent également, de manière plus générale, être applicables à une interaction entre un système ayant accès uniquement à l’interface, et un système ayant accès à un système de gestion de vol.
Enfin, les figures 8 et 9 sont présentées, pour des raisons de simplicité, pour l’interaction entre deux systèmes. Cependant, il s’agit là d’un mode de réalisation non limitatif: l’invention est applicable à des interactions entre plus de deux systèmes sur la même interface partagée: il suffit dans ce cas d’envoyer les modifications à l’ensemble des systèmes, et d’étendre la notion de validation au retour de l’ensemble des systèmes, une modification étant considérée comme définitivement adoptée que lorsqu’elle est validée par l’ensemble des systèmes.
Les étapes de la méthode 8000 peuvent notamment être exécutées par les unités de calcul 1040, 1140.
Dans une première étape 8010, le contrôleur aérien effectue une modification de l’ensemble d’objets de l’interface, tel que représenté par le système 1100. Cette modification peut par exemple consister en la création d’un objet, la modification ou la suppression d’un objet existant, ou une modification du plan de vol. La modification est notamment effectuée par les entrées 1120, en lien avec l’affichage 1110.
Dans l’exemple de l’interface 200, la modification peut par exemple consister en une modification du plan de vol 210, la suppression ou la modification d’un des objets originaux de l’interface (par exemple un des objets 220, 221, 240, 241, 250, 251), ou l’ajout d’un nouvel objet.
La méthode peut comprendre une étape intermédiaire d’affichage de la modification dans le système 1100, de validation de la modification telle qu’affichée par le contrôleur aérien, et de commande de l’envoi.
Ensuite, dans une étape 8020 la modification est codée, par exemple selon les principes discutés en référence aux figures 7a et 7b.
A l’étape 8030 la modification est envoyée au système 1000.
A l’étape 8040 la modification est reçue par le système 1000 et décodée.
A l’étape 8050 la modification est affichée par le système 1000, pour être vue par le pilote.
Le pilote peut alors valider ou rejeter la modification, notamment via l’au moins une interface d’entrée 1020. A l’étape 8060 le retour (validation ou rejet du pilote) est reçu.
A l’étape 8070 le type de retour est testé.
En cas de rejet, un message de rejet 8080 est envoyé du système 1000 au système 1100. Lorsque ce message est reçu par le système 1100, la modification est annulée à l’étape 8090 dans le système 1100, qui revient donc à l’état antérieur.
Sinon, si le pilote a validé la modification, à l’étape 8100 l’impact de la modification sur les objets dérivés est vérifiée, par exemple sur le modèle expliqué en référence aux figures 4 et 5: si, suite à la modification, des objets dérivés doivent être créés, modifiés ou supprimés, ces modifications sont évaluées et affichées à l’étape 8100.
A l’étape 8110 la modification, telle qu’appliquée dans le système 1000, est recodée. Cette étape 8110 de recodage comprend donc le codage de la modification reçue, telle qu’effectivement appliquée au niveau du système 1000, et si applicable, un codage des modifications des objets dérivés.
Dans d’autres modes de réalisation de l’invention, les modifications des objets dérivés sont calculées, codées et envoyées ultérieurement.
A l’étape 8120 le recodage de la modification est envoyé au système 1100.
A l’étape 8130 le recodage est reçu par le système 1100.
A l’étape 8140 le système 1100 vérifie que le recodage (hors modifications des objets dérivés) est identique au codage initial, effectué à l’étape 8020).
Si les codages ne sont pas identiques 8150, cela signifie qu’une erreur est survenue, et que la modification n’a pas été adoptée à l’identique par le système 100.
La modification est alors annulée à l’étape 8160. Ceci permet de s’assurer que les modifications sont bien appliquées à l’identique sur les différents systèmes, et donc de fiabiliser l’interaction entre les systèmes. Cette étape 8160 peut notamment comprendre une notification du contrôleur aérien que la modification est annulée, et l’annulation de l’affichage. Elle peut également comprendre l’envoi d’un message au système 1000, pour que celui-ci annule également la modification de son côté.
Le contrôleur aérien, peut alors, s’il le souhaite, ré-effectuer une modification, et la méthode 8000 est exécutée à nouveau, avec une nouvelle modification.
Si les codages sont bien identiques, un message de validation 8170 est envoyé au système 1000. Les systèmes sont bien synchronisés, et la modification devient alors définitive.
A l’étape 8180 le système 1000 vérifie si les modifications ont un impact sur le plan de vol. C’est par exemple le cas si la modification envoyée est une modification du plan de vol collaboratif, ou si certains objets impactent le plan de vol, comme dans l’exemple de la figure 6.
Si un impact sur le plan de vol existe, celui-ci est affiché au pilote à l’étape 8190.
A l’étape 8200, la validation du pilote est reçue. Dans le cas où le pilote rejette les modifications du plan de vol impliquées par la modification, celle-ci est annulée. Un message est envoyé au système 1100 pour informer le contrôler aérien, et annuler la modification côté système 1100.
Après validation du pilote, la modification du plan de vol est envoyée à l’étape 8210 au système de gestion de vol 1050.
Dans le cas où le système de gestion de vol rejette la modification, par exemple si elle n’est pas compatible avec les performances aérodynamiques de l’aéronef, la modification est annulée, à la fois dans le système 1000 et 1100.
Dans le cas où la modification du plan de vol est acceptée par le système de gestion de vol 1050, mais implique de nouvelles modifications, celles-ci sont reçues par l’interface collaborative, comme expliqué par exemple en figure 9.
La figure 9 représente une méthode d’application d’une modification sur un système bord, et de validation de la modification sur un système sol dans un ensemble de modes de réalisation de l’invention.
Dans cet exemple, une modification d’un ensemble d’objets d’une interface est effectuée dans le système 1000, soit par action du pilote, soit par réception d’une modification de plan de vol par le système de gestion de vol 1050, et envoyée au système 1000. Cependant, cette méthode est donnée à titre d’exemple non limitatif uniquement: certaines étapes ne sont utilisées que pour certains modes de réalisation de l’invention.
De plus, la mise en œuvre par les systèmes 1000 et 1100 est donnée à titre d’exemple uniquement. De manière plus générale, cette méthode peut être mise en œuvre entre un système ayant uniquement accès à l’interface partagée, et un système ayant accès à un système de gestion de vol. De même, le pilote et le contrôleur aérien peuvent être remplacés par d’autres opérateurs, tels qu’un pilote de drone à distance.
Les étapes de la méthode 9000 peuvent notamment être exécutées par les unités de calcul 1040, 1140.
Dans une première étape 9010, est reçue en entrée une modification de l’ensemble d’objets de l’interface, tel que représenté par le système 1000. Cette modification peut par exemple consister en la création d’un objet, la modification ou la suppression d’un objet existant, ou une modification du plan de vol.
La modification peut notamment être initiée par :
- le pilote, qui les entre par les entrées 1020, en lien avec l’affichage 1010;
- le système de gestion de vol 1050, qui initie une modification du plan de vol. Si cette modification est validée par le pilote, la modification est reçue en entrée de la méthode 9000.
Dans l’exemple de l’interface 200, la modification peut par exemple consister en une modification du plan de vol 210, la suppression ou la modification d’un des objets originaux de l’interface (par exemple un des objets 220, 221, 240, 241, 250, 251), ou l’ajout d’un nouvel objet.
Si, suite à la modification, des objets dérivés doivent être créés, modifiés ou supprimés, ces modifications sont évaluées et affichées à l’étape 9020. Le pilote peut alors, dans un ensemble de modes de réalisation de l’invention, accepter ou refuser les modifications. S’il refuse, la modification est annulée.
Dans les cas où la modification n’est pas issue du système de gestion de vol 1050, mais implique une modification de celui-ci, et où le pilote accepte les modifications, la modification du plan de vol est envoyée au système de gestion de vol 1050.
Dans le cas où le système de gestion de vol rejette la modification, par exemple si elle n’est pas compatible avec les performances aérodynamiques de l’aéronef, la modification est annulée.
Dans le cas où la modification du plan de vol est acceptée par le système de gestion de vol 1050, mais implique de nouvelles modifications, celles-ci sont reçues par l’interface collaborative, en tant que modification additionnelles, et affichées au pilote, qui peut les accepter ou les refuser.
A l’étape 9040, la validation du pilote est reçue, pour l’ensemble des modifications.
Ensuite, dans une étape 9050 la modification ou les modifications (modification initiale, modifications des objets dérivés, modifications du plan de vol suite à l’envoi FMS) sont codées, par exemple selon les principes discutés en référence aux figures 7a et 7b.
A l’étape 9060 l’ensemble des modifications est envoyé au système 1100.
A l’étape 9070 l’ensemble des modifications est reçu par le système 1100.
A l’étape 9080 les modifications sont affichées par le système 1100, pour être vue par le contrôleur aérien.
Selon différents modes de réalisation de l’invention, le contrôleur aérien doit valider ou non les modifications. Par exemple, le contrôleur aérien peut devoir valider toutes les modifications. Au contraire, les modifications envoyées par le bord peuvent toutes être automatiquement appliquées au sol, sans validation du contrôleur aérien. Enfin, seuls certains types de modifications (par exemple, les modifications du plan de vol), peuvent être soumises à validation par le contrôleur aérien.
Si la modification est sujette à validation de la part du contrôleur aérien, celui-ci peut valider ou rejeter la modification, notamment via les entrées 1120. A l’étape 9090 le retour (validation ou rejet du contrôleur aérien) est reçu. Les étapes subséquentes 9100, 9110, 9120 ne sont également activées que si la modification est sujette à validation du contrôleur aérien.
A l’étape 9100 le type de retour est testé.
En cas de rejet, un message de rejet 9110 est envoyé du système 1100 au système 1000. Lorsque ce message est reçu par le système 1000, les modifications sont annulées à l’étape 9120 dans le système 1000, qui revient donc à l’état antérieur.
Sinon, si le contrôleur aérien valide les modifications, ou si celles- ci ne sont pas sujettes à validation, à l’étape 9130 les modifications, telle qu’appliquées dans le système 1100, sont recodées. Cette étape 9130 de recodage comprend donc le codage des modifications reçues, telle qu’effectivement appliquée au niveau du système 1100.
Dans d’autres modes de réalisation de l’invention, les modifications des objets dérivés sont calculées, codées et envoyées ultérieurement.
A l’étape 9140 le recodage de la modification est envoyé au système 1000.
A l’étape 9150 le recodage est reçu par le système 1000.
A l’étape 9160 le système 1000 vérifie que le recodage est identique au codage initial, effectué à l’étape 9050.
Si les codages ne sont pas identiques 9170, cela signifie qu’une erreur est survenue, et que la modification n’a pas été adoptée à l’identique par le système 100.
Les modifications sont alors annulées à l’étape 9180. Ceci permet de s’assurer que les modifications sont bien appliquées à l’identique sur les différents systèmes, et donc de fiabiliser l’interaction entre les systèmes. Cette étape 9180 peut notamment comprendre une notification du pilote que les modifications sont annulées, et l’annulation de l’affichage. Elle peut également comprendre l’envoi d’un message au système 1100, pour que celui-ci annule également la modification de son côté.
Le pilote, peut alors, s’il le souhaite, ré-effectuer une modification, et la méthode 9000 est exécutée à nouveau, avec une nouvelle modification.
Alternativement, le codage des modifications peut être à nouveau envoyé au système 1100, sans annulation des modifications.
Si les codages sont bien identiques, un message de validation 9190 est envoyé au système 1100. A l’étape 9200 le message 9190 est reçu par le système 1100. Les systèmes sont bien synchronisés, et la modification devient définitive.
Comme la méthode 8000, la méthode 9000 démontre la capacité de l’invention à permettre à plusieurs systèmes de travailler, de manière collaborative, sur des plans de vol, tout en s’assurant que les modifications apportées de part et d’autres sont bien synchronisées entre les différents systèmes.
Pour des raisons de simplicité, les exemples fournis ont trait à des échanges entre deux systèmes. De manière plus générale, l’invention est applicable à des échanges entre plus de deux systèmes. Selon un ensemble de modes de réalisation de l’invention, un système peut par exemple «centraliser» les opérations. Dans ce cas, les modifications des objets de l’interface collaborative sont propagées depuis le système central vers les autres, et les exemples développés ci-dessus peuvent être généralisés. Par exemple, si une modification est effectuée sur le système central, elle sera propagée aux autres systèmes, et pourra être annulée si l’un au moins des autres systèmes rejette la modification. Si une modification est reçue par le système central, et validée par celui-ci, un message comprenant la modification pourra être envoyé aux autres systèmes. Ceci permet de déployer l’interface collaborative à plus de deux systèmes.
Les exemples ci-dessus démontrent la capacité de l’invention à mettre en œuvre une interface de travail et un plan de vol collaboratifs entre différents systèmes. Ils ne sont cependant donnés qu’à titre d’exemple et ne limitent en aucun cas la portée de l’invention, définie dans les revendications ci-dessous.
Claims (16)
- Un premier système (1000, 1100) comprenant:
- au moins un dispositif d’affichage (1010, 1110) configuré pour afficher un ensemble d’objets comprenant un plan de vol de référence de l’aéronef et au moins un objet d’environnement ou de contexte ;
- au moins une interface d’entrée (1020, 1120);
- au moins un port de communication (1030, 1130) configuré pour communiquer avec au moins un deuxième système (1100, 1000);
- au moins une unité de calcul (1040, 1140) configurée, à la réception, par le port de communication (1030, 1130) d’un message (1200, 1210) indiquant une première description d’une modification dudit ensemble, pour :
- générer l’affichage (1041, 1141) de la modification;
- recevoir une validation ou un rejet (1042, 1142) de la modification par l’interface d’entrée (1020, 1120);
- envoyer (1043, 1143), par l’au moins un port de communication, un message (1210, 1200) au deuxième système contenant:
- en cas de validation, une deuxième description de ladite modification;
- sinon, une indication du rejet de la modification.
- Le premier système de la revendication 1, dans lequel l’au moins une unité de calcul (1040, 1140) est configurée, à la réception d’une modification de l’ensemble d’objets par l’interface d’entrée (1020, 1120), pour:
- générer l’affichage de la modification;
- envoyer (1053, 1153), par l’au moins un port de communication, un message (1210, 1200) au deuxième système contenant une première description de la modification;
- recevoir du deuxième système un message contenant une indication du rejet de la modification, ou une deuxième description de la modification;
- si le message reçu du deuxième système est un message de rejet, ou si la première et la deuxième description sont différentes, annuler la modification;
- sinon, valider la modification.
- Système selon l’une des revendications 1 à 2, dans lequel l’au moins un objet d’environnement ou de contexte comprend au moins un objet appartenant à un type d’objets choisi dans un groupe comprenant :
- une zone de texte;
- un symbole informatif;
- une surface fermée;
- un pseudo point sur le plan de vol de référence;
- un élément graphique;
- une section de plan de vol distincte du plan de vol de référence.
- Le premier système (1000) de l’une des revendications 1 à 3, comprenant au moins un système de gestion de vol (1050), et dans lequel l’au moins une unité de calcul (1040) est configurée:
- à la réception d’une modification du plan de vol de référence par l’au moins un système de gestion de vol, afficher la modification et envoyer par l’au moins un port de communication, un message contenant une description du plan de vol de référence modifié;
- si ladite modification de l’ensemble d’objets reçue par l’interface d’entrée (1020) est une modification du plan de vol, et est validée, l’envoyer au système de gestion de vol (1050).
- Système selon la revendication 4, dans lequel l’au moins une unité de calcul (1040, 1140) est configurée, à la réception d’une modification de l’ensemble d’objets, pour:
- vérifier si ladite modification du plan de vol de référence implique une interaction entre le plan de vol de référence modifié et un autre objet de l’ensemble;
- si la modification implique une interaction, créer un objet fonctionnel symbolisant l’interaction.
- Système selon la revendication 5, dans lequel l’au moins une unité de calcul (1040, 1041) est configurée pour:
- vérifier si la modification du plan de vol de référence implique le passage du plan de vol de référence modifié dans une surface fermée existante ou nouvelle (430, 440, 530);
- si la modification implique le passage du plan de vol de référence modifié dans une surface fermée existante ou nouvelle, créer un pseudo point à l’entrée dudit plan de vol dans la surface fermée (431, 441, 540, 542), et un pseudo-point à la sortie dudit plan de vol de la surface fermée (432, 442, 541, 543).
- Système selon l’une des revendications 5 ou 6 dans lequel l’au moins une unité de calcul (1040, 1140) est configurée, à la réception d’une modification de l’ensemble d’objets, pour:
- vérifier si ladite modification implique une suppression de l’interaction entre le plan de vol de référence modifié et un autre objet de l’ensemble;
- si la modification implique la suppression de l’interaction, supprimer un objet fonctionnel symbolisant l’interaction.
- Système selon l’une des revendications 1 à 7, dans lequel l’au moins une unité de calcul (1040, 1140) est configurée, à la réception d’une modification de l’ensemble d’objets comprenant l’ajout ou la modification d’un objet d’environnement ou de contexte, pour:
- vérifier si ladite modification implique une interaction entre le plan de vol de référence et l’objet d’environnement ou de contexte ajouté ou modifié ;
- si la modification implique une interaction, créer un objet fonctionnel symbolisant l’interaction.
- Système selon la revendication 8, dans lequel l’objet d’environnement ou de contexte ajouté ou modifié est une surface fermée ajoutée ou modifiée (620), et l’au moins une unité de calcul (1040, 1041) est configurée pour:
- vérifier si la modification implique le passage du plan de vol de référence dans la surface fermée ajoutée ou modifiée (620);
- si la modification implique le passage du plan de vol de référence dans la surface fermée ajoutée ou modifiée, créer un pseudo point (630) à l’entrée dudit plan de vol dans la surface fermée ajoutée ou modifiée (620), et un pseudo-point (631) à la sortie dudit plan de vol de la surface fermée ajoutée ou modifiée (620).
- Système selon l’une des revendications 8 ou 9 dans lequel l’au moins une unité de calcul (1040, 1140) est configurée, à la réception d’une modification de l’ensemble d’objets comprenant la suppression d’un objet d’environnement ou de contexte, pour:
- vérifier si ladite modification implique une suppression de l’interaction entre le plan de vol de référence et l’objet d’environnement ou de contexte supprimé;
- si la modification implique la suppression de l’interaction, supprimer un objet fonctionnel symbolisant l’interaction.
- Système selon l’une des revendications 1 à 10, dans lequel l’au moins une unité de calcul (1040, 1140) est configurée pour effectuer un codage (720a) d’un objetpréalablement à l’envoi d’un message, et effectuer un décodage d’un objet suite à la réception d’un message, le codage de l’objet comprenant :
- Une section de code (721a) comprenant un code prédéfini définissant le type d’objet, et pour chacun des attributs de l’objet, un code prédéfini définissant le type de l’attribut;
- une suite alphanumérique (722a) définissant, pour chacun des attributs, la valeur associée.
- Système selon l’une des revendications 1 à 11, dans lequel l’au moins une unité de calcul (1040, 1140) est configurée pour effectuer un codage (720b) d’une modification du plan de vol de référencepréalablement à l’envoi d’un message, et effectuer un décodage d’une modification du plan de vol de référence suite à la réception d’un message, le codage de la modification de plan de vol de référence comprenant :
- une section de code (721b) comprenant un code prédéfini définissant une modification du plan de vol de référence, et pour chacune des fonctions de plan de vol modifiées, un code prédéfini définissant le type de fonction;
- une suite alphanumérique (722b) définissant, les points de cheminement modifiés, et, pour chacune des fonctions, les valeurs de paramètres associées.
- Système selon l’une des revendications 11 ou 12, dépendant de la revendication 2, dans lequel:
- la première et la deuxième modification de l’ensemble sont représentées respectivement en un premier et un deuxième codage d’un objet ou d’une modification du plan de vol de référence;
- l’au moins une unité de calcul (1040, 1140) est configurée pourvérifier si les première et deuxième modifications sont identiques en vérifiant si les premier et deuxième codages sont identiques.
- Système selon l’une des revendications 1 à 13, dans lequel:
- le port de communication est configuré pour communiquer avec une pluralité de deuxièmes systèmes;
- l’unité de calcul est configurée, à la réception, par le port de communication, du message indiquant la description de la modification, et en cas de validation, pour envoyer, par l’au moins un port de communication, à chacun des deuxièmes systèmes de ladite pluralité, le message contenant la deuxième description de la modification.
- Méthode mise en œuvre par ordinateur comprenant:
- la réception (8040, 9070), par au moins un port de communication d’un premier système (1000, 1100), configuré pour communiquer avec au moins un deuxième système (1100, 1000), d’un message (1200, 1210) indiquant une première description d’une modification d’un ensemble d’objets comprenant un plan de vol de référence d’un aéronef et au moins un objet d’environnement ou de contexte ;
- l’affichage (8050, 9080) de ladite modification sur au moins un dispositif d’affichage (1010, 1110) du premier système;
- la réception de la validation ou du rejet (8060, 9090), par une interface d’entrée (1020, 1120) du premier système;
- l’envoi (8120, 9140), par l’au moins un port de communication, d’un message (1210, 1200) au deuxième système contenant:
- en cas de validation, une deuxième description de ladite modification;
- sinon, une indication du rejet de la modification.
- Produit programme d’ordinateur comprenant des instructions de code de programme enregistrées sur un support lisible par ordinateur, lesdites instructions de code de programme étant configurées pour:
- recevoir (8040, 9070), par au moins un port de communication d’un premier système (1000, 1100), configuré pour communiquer avec au moins un deuxième système (1100, 1000), d’un message (1200, 1210) indiquant une première description d’une modification d’un ensemble d’objets comprenant un plan de vol de référence d’un aéronef et au moins un objet d’environnement ou de contexte;
- afficher (8050, 9080) ladite modification sur au moins un dispositif d’affichage (1010, 1110) du premier système;
- recevoir la validation ou du rejet (8060, 9090), par une interface d’entrée (1020, 1120) du premier système;
- envoyer (8120, 9140), par l’au moins un port de communication, d’un message (1210, 1200) au deuxième système contenant:
- en cas de validation, une deuxième description de ladite modification;
- sinon, une indication du rejet de la modification;
Priority Applications (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1912712A FR3103300B1 (fr) | 2019-11-14 | 2019-11-14 | Espace collaboratif de gestion de contexte de plan de vol |
| PCT/EP2020/080126 WO2021094081A1 (fr) | 2019-11-14 | 2020-10-27 | Espace collaboratif de gestion de contexte de plan de vol |
| US17/776,545 US20220406198A1 (en) | 2019-11-14 | 2020-10-27 | Collaborative space for managing flight plans |
| EP20793409.2A EP4058959A1 (fr) | 2019-11-14 | 2020-10-27 | Espace collaboratif de gestion de contexte de plan de vol |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1912712A FR3103300B1 (fr) | 2019-11-14 | 2019-11-14 | Espace collaboratif de gestion de contexte de plan de vol |
| FR1912712 | 2019-11-14 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR3103300A1 true FR3103300A1 (fr) | 2021-05-21 |
| FR3103300B1 FR3103300B1 (fr) | 2022-01-21 |
Family
ID=70613834
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR1912712A Active FR3103300B1 (fr) | 2019-11-14 | 2019-11-14 | Espace collaboratif de gestion de contexte de plan de vol |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US20220406198A1 (fr) |
| EP (1) | EP4058959A1 (fr) |
| FR (1) | FR3103300B1 (fr) |
| WO (1) | WO2021094081A1 (fr) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110322161A (zh) * | 2019-07-10 | 2019-10-11 | 中国民航信息网络股份有限公司 | 航班生效批次的生效调整方法及装置 |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9691287B1 (en) * | 2013-09-26 | 2017-06-27 | Rockwell Collins, Inc. | Graphical method to set vertical and lateral flight management system constraints |
-
2019
- 2019-11-14 FR FR1912712A patent/FR3103300B1/fr active Active
-
2020
- 2020-10-27 WO PCT/EP2020/080126 patent/WO2021094081A1/fr unknown
- 2020-10-27 EP EP20793409.2A patent/EP4058959A1/fr active Pending
- 2020-10-27 US US17/776,545 patent/US20220406198A1/en active Pending
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9691287B1 (en) * | 2013-09-26 | 2017-06-27 | Rockwell Collins, Inc. | Graphical method to set vertical and lateral flight management system constraints |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2021094081A1 (fr) | 2021-05-20 |
| FR3103300B1 (fr) | 2022-01-21 |
| EP4058959A1 (fr) | 2022-09-21 |
| US20220406198A1 (en) | 2022-12-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2898527C (fr) | Systeme de communication d'information relative a un objet en vol | |
| US9697737B2 (en) | Automatic real-time flight plan updates | |
| US10121384B2 (en) | Aircraft performance predictions | |
| US9424755B2 (en) | Flight analogous and projection system | |
| FR3025920A1 (fr) | Procede de calcul temps reel d'une trajectoire planifiee, notamment de plan de vol, combinant une mission, et systeme de gestion d'une telle trajectoire | |
| CN106952504B (zh) | 具有增强cpdlc消息管理的飞机系统 | |
| FR3061342A1 (fr) | Gestion des messages aux navigants aeriens | |
| US20160093218A1 (en) | Flight path discontinuities | |
| FR2910124A1 (fr) | Procede de creation et de mise a jour d'un plan de vol atc en temps reel pour la prise en compte de consignes de vol et dispositif de mise en oeuvre | |
| FR2940426A1 (fr) | Dispositif d'assistance au choix d'un aeroport de deroutement | |
| FR3021401A1 (fr) | Reconfiguration de l'affichage d'un plan de vol pour le pilotage d'un aeronef | |
| FR2954847A1 (fr) | Systeme et procede de gestion centralisee d'informations de navigation | |
| FR3035534B1 (fr) | Procede et systeme de communication et de partage d'informations pour aeronef | |
| FR3027127A1 (fr) | Interface tactile pour le systeme de gestion du vol d'un aeronef | |
| FR3038750A1 (fr) | Procede d'integration d'un nouveau service de navigation dans un systeme avionique embarque a architecture ouverte de type client-serveur, en particulier d'un service de manoeuvre fim | |
| US11436930B2 (en) | Recording data associated with an unmanned aerial vehicle | |
| US11972691B2 (en) | Autonomous aerial vehicle flight management | |
| CA3037319A1 (fr) | Systeme d'etablissement de plan de vol operationnel d'aeronef et procede associe | |
| FR3038751A1 (fr) | Procede d'integration d'une application d'optimisation de route (s) sous contraintes dans un systeme embarque avionique a architecture ouverte de type client serveur | |
| EP4097555A2 (fr) | Coordination d'une recherche aérienne entre des véhicules aériens sans pilote | |
| FR2913799A1 (fr) | Procede de routage des clairances numeriques atc optimisant leur prise en compte a bord d'un aeronef | |
| FR2954490A1 (fr) | Procede et systeme de gestion dynamique d'une procedure de vol d'un plan de vol d'un aeronef | |
| EP4097918A1 (fr) | Authentification hybride basée sur une chaîne de blocs | |
| FR3103300A1 (fr) | Espace collaboratif de gestion de contexte de plan de vol | |
| EP2381432A1 (fr) | Procédés et systèmes de programmation des vols |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 2 |
|
| PLSC | Publication of the preliminary search report |
Effective date: 20210521 |
|
| PLFP | Fee payment |
Year of fee payment: 3 |
|
| PLFP | Fee payment |
Year of fee payment: 4 |
|
| PLFP | Fee payment |
Year of fee payment: 5 |