FR2953668A1 - Procede et dispositif de traitement d'un message de requete recu dans un aeronef, en provenance du controle au sol, via un systeme de transmission de donnees - Google Patents

Abstract

Un procédé de traitement d'un message de requête reçu (E11) dans un aéronef depuis le contrôle aérien via un système de transmission de données, comprend l'identification (E13) d'un type de requête contenue dans le message reçu et l'extraction (E15) de paramètres associés au type de requête identifié. Le procédé comporte en outre des étapes de : - détermination (E17) de caractéristiques de vol à calculer, en fonction du type de requête identifié et desdits paramètres associés ; - sélection (E19) d'au moins un module de calcul, parmi un ensemble prédéterminé de modules de calcul, en fonction des caractéristiques de vol à calculer déterminées ; - calcul (E21) des caractéristiques de vol par au moins un module de calcul sélectionné, et obtention de résultats de calcul ; - création (E23, E25) d'un brouillon de réponse à ladite requête à partir des résultats de calcul obtenus.

Description

La présente invention a trait au domaine des opérations aériennes mettant en oeuvre des échanges équipage û contrôleurs, acheminés par une liaison de données de type CPDLC. Plus précisément, l'invention concerne un procédé et un dispositif de traitement d'un message de requête reçu dans un aéronef, en provenance du contrôle au sol, via un système de transmission de données. La majeure partie des zones océaniques et un nombre croissant de zones continentales (asiatique en particulier, européenne depuis peu) offrent aux aéronefs la capacité d'échanger des messages écrits, alphanumériques, montants ou descendants avec le contrôle au sol, généralement avec un contrôleur. A ce jour, les espaces aériens concernés sont essentiellement les espaces supérieurs, c'est-à-dire au-dessus d'un certain niveau de vol (typiquement, au-dessus de 25000 pieds). Des fréquences et des protocoles de communication sont dédiés à ces échanges numériques, les fréquences peuvent varier avec la zone survolée, et en particulier, utiliser des communications satellitaires et/ou emprunter des réseaux terrestres. Ce type d'échange de messages écrits entre le contrôle au sol et le pilote ou l'équipage de l'aéronef est désigné par le sigle CPDLC désignant les communications contrôleurs / pilotes par liaison de données (Controller / Pilot Data-Link Communications, en anglais). Le mode de communication CPDLC permet de communiquer des requêtes venant de l'équipage ou des instructions de contrôle provenant du sol appelées "clairances" (clearances en anglais), et plus généralement des messages de différents types, au format alphanumérique, composés de texte libre ou bien constitués de messages codifiés, avec le cas échéant, des champs paramétrables. Le mode de communication CPDLC, qui n'utilise pas le canal de la voix, est très avantageux en termes de fiabilité, de qualité, et de robustesse aux 30 erreurs, par rapport à la communication par un canal vocal. A ce jour, nombre de messages montants, issus du contrôle aérien, présupposent de la capacité de l'aéronef à satisfaire un ou plusieurs des paramètres demandés, et tout spécialement lorsque ces paramètres concernent les performances de vol de l'aéronef, telles que par exemple, la vitesse, l'altitude ou le taux de montée. Dans certains cas, ces messages montants posent explicitement au pilote des questions sur la capacité de l'aéronef à atteindre certaines performances. On donne ci-après un exemple d'instruction contenue dans un message CPDLC en provenance du contrôle au sol. Cette instruction est la suivante : " CROSS [position] AT OR AFTER [time] AT [altitude] " L'instruction CROSS ci-dessus signifie : "Passer par le point précis indiqué dans le champ [position] à l'altitude précise indiquée dans le champ [altitude] à compter de l'heure indiquée dans le champ [time] ". Comme illustré par l'exemple ci-dessus, il est donc possible qu'un contrôleur demande au pilote d'atteindre une altitude donnée avec des contraintes que l'aéronef ne peut remplir avec les marges de sécurité demandées, pour des raisons liées aux contraintes physiques du vol, qu'elles soient imposées par les caractéristiques de construction de l'aéronef, ou bien dues aux conditions du vol, telles que la masse de l'aéronef ou la température extérieure du jour. Dans d'autres cas, c'est rejoindre un point à une heure précise qui ne sera pas possible, car nécessitant une accélération et des vitesses physiquement inatteignables par l'aéronef. Par ailleurs, selon un type de messages plus basique, il est fréquent que des messages demandent simplement au pilote l'état des performances atteignables de l'aéronef. A titre d'exemple, un message fréquemment transmis est le suivant : " WHEN CAN YOU ACCEPT FL [level] ", signifiant : " A quelle heure serez-vous capables d'atteindre le niveau de vol indiqué dans le champ [level] ", par exemple, 350. Actuellement, compte tenu de la nature des messages et de la normalisation internationale (normes de l'Organisation de l'Aviation Civile Internationale (OACI)) dont ils relèvent, les systèmes embarqués de réception des messages CPDLC sont capables d'identifier la nature d'un message reçu et, le cas échéant, chacun des paramètres variables qui le composent, aux fins d'un traitement ultérieur par le pilote.

Cependant, compte tenu des divers types de messages exposés plus haut, il est souvent difficile pour un pilote de répondre aux questions posées ou d'anticiper sa capacité à répondre à une instruction de manoeuvre, car ces questions ou instructions requièrent en général d'effectuer des calculs.

Ces calculs nécessaires, lorsqu'ils sont relativement simples, peuvent être effectués manuellement par le pilote, à l'aide d'outils de calcul basiques, tels que des abaques de type papier ou de type électronique, ou bien une calculette électronique. Cependant, lorsqu'ils sont plus complexes, ces calculs peuvent nécessiter l'utilisation par le pilote de ressources informatiques tels que des outils intégrés aux instruments de bord, tels qu'un système de gestion de vol (en anglais Flight Management System - FMS). Pourtant, malgré les outils susmentionnés à la disposition du pilote, il est difficile pour ce dernier de répondre à de nombreux types de messages. En effet, les systèmes de réception de messages et les outils de calcul précités, même s'ils permettent de répondre ponctuellement aux questions ou aux interrogations de l'équipage, requièrent de la part de l'équipage : - la prise de connaissance de l'instruction ou de la question contenue dans le message ; - l'exécution manuelle (abaques, calculette) et/ou le lancement de calculs effectués par des systèmes de calcul spécialisés, souvent selon une séquence d'étapes qui peut combiner les deux modes de calcul : manuel et par calculateur ; - la prise de connaissance, c'est-à-dire la récupération, le collationnement et l'analyse, de paramètres liés à l'aéronef (type, motorisation, masse, centrage, etc.), mais aussi de paramètres environnementaux (température, vents, météo, etc.) au voisinage ou le long de la route prévue de l'aéronef ; - un enchaînement de calculs pouvant être complexes et/ou nombreux ; - la comparaison des résultats de calculs ainsi effectués avec la requête du contrôle aérien ; - puis, l'élaboration d'une réponse et enfin l'envoi de celle-ci au contrôle au sol.

Il est à noter que la réponse transmise peut être de deux types selon qu'elle fait suite à un message relatif à une instruction de demande de manoeuvre ou à un message relatif à une question précise liée à une capacité de l'aéronef. Dans le premier cas, la réponse pourra indiquer simplement l'accord du pilote avec la manoeuvre ou au contraire le désaccord, avec éventuellement une justification de l'incapacité de l'aéronef à accomplir la manoeuvre demandée. Dans le second cas, la réponse de l'équipage pourra consister en une réponse précise et chiffrée sur la capacité demandée de l'aéronef û par exemple : "On peut atteindre le niveau 350 à 7h56" û, ou bien en une réponse négative, par exemple : "Pas capable d'atteindre le niveau demandé". Il ressort de ce qui précède, que la charge de travail subie par l'équipage, pour traiter les demandes contenues dans les messages en provenance du contrôle aérien, est importante.

Actuellement, les communications en contexte CPDLC ont lieu essentiellement lorsque le vol est en phase de croisière. Cependant cette situation risque d'empirer dans un proche avenir, puisqu'il est prévu, dans le cadre du projet européen SESAR (système européen de nouvelle génération pour la gestion du trafic aérien) ou du projet américain Next Generation Airspace, que ces échanges soient plus fréquents avec des messages plus variés, et qu'ils aient également lieu dans des phases de vol plus dynamiques, telles que les phases de montée ou de descente, phases durant lesquelles la charge de travail de l'équipage est plus élevée qu'en régime de croisière. Ainsi, dans ce nouveau contexte de communications CPDLC, la charge de travail subie par l'équipage sera encore plus lourde, risquant ainsi de rendre encore plus problématique le traitement de tels messages. Il ressort de la situation exposée ci-dessus, qu'il existe un réel besoin de systèmes embarqués d'assistance au traitement par l'équipage des messages montants du contrôle au sol transmis dans un environnement CPDLC, en particulier lorsque ces messages demandent à l'équipage d'effectuer des calculs de performance précis, ce qui accroît considérablement la charge de travail de l'équipage.

Afin de répondre au besoin exposé ci-dessus, la présente invention concerne, selon un premier aspect, un procédé de traitement d'un message de requête reçu dans un aéronef depuis le contrôle aérien via un système de transmission de données. Ce procédé comprend l'identification d'un type de requête contenue dans le message reçu et l'extraction de paramètres associés au type de requête identifié, et est remarquable en ce qu'il comporte en outre des étapes de : - détermination de caractéristiques de vol à calculer, en fonction du type de requête identifié et des paramètres associés ; - sélection d'au moins un module de calcul, parmi un ensemble prédéterminé de modules de calcul, en fonction des caractéristiques de vol à calculer déterminées ; - calcul des caractéristiques de vol par au moins un module de calcul sélectionné, et obtention de résultats de calcul ; - création d'un brouillon de réponse à la requête à partir des résultats de calcul obtenus. Grâce à un tel procédé de traitement automatique d'un message en provenance du contrôle aérien par une liaison de CPDLC, l'équipage de l'aéronef est soulagé des tâches suivantes : prise de connaissance de l'instruction ou de la question contenue dans le message, c'est-à-dire de l'analyse des caractéristiques de vol à calculer ; exécution manuelle ou assistée par des outils de calculs, comme expliqué plus haut, puisque selon l'invention, des modules de calcul sont automatiquement sélectionnés pour calculer les caractéristiques nécessaires au traitement du message ; la récupération, le collationnement et l'analyse des résultats de calculs intermédiaires, avec, le cas échéant, la récupération manuelle de paramètres liés à l'aéronef ou aux conditions de vol ; enfin, la comparaison des résultats de calculs finaux avec la requête du contrôle aérien d'une réponse, avant l'élaboration d'une réponse destinée à être envoyée au contrôle aérien. Ainsi, selon le procédé de l'invention, un brouillon de réponse à la requête est automatiquement fourni à l'équipage.

La mise en oeuvre du procédé selon l'invention fournit ainsi au pilote d'un aéronef, tel qu'un avion de ligne par exemple, une assistance au traitement des requêtes du contrôle aérien, permettant de baisser considérablement la charge de travail et l'attention requises classiquement pour le pilote pour traiter ces requêtes. L'invention contribue par conséquent à améliorer encore la sécurité dans le transport aérien. Elle permet également d'augmenter l'efficacité de l'espace aérien par une réponse plus rapide et plus fiable donnée aux sollicitations du contrôle (accepter une manoeuvre à juste titre ; refuser une clairance que l'on ne peut satisfaire). Selon d'autres caractéristiques de l'invention : - le brouillon de réponse est ensuite soumis à l'équipage de l'aéronef, via une interface homme-machine adaptée ; - l'équipage valide, directement ou après modification, via l'interface homme-machine, le brouillon de réponse à la requête, la validation du brouillon de réponse déclenchant l'envoi d'un message de réponse à destination du contrôle au sol ; - le procédé selon l'invention comprend en outre une étape de création et d'envoi d'un message de réponse à la requête, le message de réponse étant basé sur le brouillon de réponse ; - l'étape d'identification d'un type de requête est précédée des étapes de communication du message de requête reçu à l'équipage via une interface homme-machine adaptée, et de validation de la mise en oeuvre de l'étape d'identification, en fonction d'une action prédéterminée exercée par l'équipage au moyen de l'interface homme-machine ; - le message de requête reçu est communiqué à l'équipage, via une interface homme-machine, en parallèle avec l'étape d'identification d'un type de requête ; - l'ensemble prédéterminé de modules de calcul comprend au moins des modules destinés respectivement à effectuer l'une des catégories de calcul suivantes : calculs de base des performances de l'aéronef, calculs impliquant l'exploitation d'une version électronique d'un brouillon de plan de vol, calculs mettant en oeuvre des simulations de type "à rebours", calculs impliquant majoritairement des opérations manuelles, calculs impliquant l'exploitation directe de la version électronique du plan de vol actif. Selon un deuxième aspect, l'invention concerne un dispositif de traitement d'un message de requête reçu dans un aéronef depuis le contrôle au sol via un système de transmission de données. Conformément à l'invention, ce dispositif comprend : - un module d'analyse de messages destiné à identifier un type de requête contenue dans le message reçu, à extraire des paramètres associés au type de requête identifié, et à déterminer des caractéristiques de vol à calculer, en fonction du type de requête identifié et des paramètres associés ; - un ensemble de modules de calcul de caractéristiques de vol de différentes catégories ; - un module de sélection de ressources de calcul, destiné à sélectionner au moins un module de calcul, parmi l'ensemble prédéterminé de modules de calcul, en fonction des caractéristiques de vol à calculer déterminées, le (ou les) module(s) de calcul sélectionné(s) étant chargé(s) de calculer les caractéristiques de vol déterminées ; - un module de création de brouillon de réponse, destiné à créer un 20 brouillon de réponse à la requête à partir des résultats de calcul obtenus par le (ou les) module(s) de calcul sélectionné(s). Selon un autre aspect, l'invention concerne un programme d'ordinateur sur un support d'informations, ce programme comportant des instructions adaptées à la mise en oeuvre d'un procédé de traitement d'un message de 25 requête reçu dans un aéronef depuis le contrôle aérien, selon l'invention, tel que brièvement exposé plus haut, lorsque le programme est chargé et exécuté dans un système informatique. Les avantages procurés par le dispositif de traitement d'un message de requête susmentionné, ainsi que par le programme d'ordinateur précité, sont 30 identiques à ceux mentionnés plus haut en relation avec le procédé de traitement d'un message de requête, selon l'invention, et ne seront par conséquent pas rappelés ici.

L'invention a également pour objet un aéronef muni d'un dispositif de traitement de message de requête, selon l'invention, tel qu'exposé plus haut. L'invention sera mieux comprise à l'aide de la description détaillée qui va suivre, faite en se référant aux dessins annexés dans lesquels : - la figure 1 est un organigramme illustrant les principales étapes d'un procédé de traitement d'un message de requête reçu dans un aéronef depuis le contrôle au sol, selon un mode de réalisation particulier de l'invention ; et - la figure 2 représente un système de traitement de messages de requête reçus dans un aéronef depuis le contrôle au sol, incorporant un dispositif de traitement de messages selon l'invention. En liaison avec la figure 1, on va à présent décrire les principales étapes d'un procédé de traitement d'un message de requête reçu dans un aéronef depuis le contrôle au sol, selon un mode de réalisation particulier de l'invention. Ce procédé est mis en oeuvre dans un système de traitement de messages CPDLC reçus dans un aéronef depuis le contrôle au sol, tel que représenté à la figure 2. Comme illustré à la figure 1, un message (MSG) M1 en provenance du contrôle au sol est reçu via un système de transmission de données connu en soi, adapté à transmettre via une liaison de données des communications de type CPDLC. Le message M1 est un message, dit "montant", contenant classiquement une requête d'informations de part du contrôle au sol. A l'étape El 1, le message montant M1 est reçu classiquement dans l'aéronef par un dispositif, connu en soi, de réception de messages CPDLC (figure 2, 21).

Au cours de l'étape suivante (E13), le dispositif de réception de messages CPDLC (21), identifie classiquement un type ou catégorie de la requête contenue dans le message (cette identification est normalisée et déterministe), extrait du message des paramètres associés au type de requête identifié.

Les différents types de messages montants sont illustrés à l'Annexe 1 qui figure en fin de description et qui fournit une liste de quelques messages montants (clearances), extraits du document 4444 de l'OACI (Organisation de l'Aviation Civile Internationale), liés à une problématique de performances de l'aéronef. L'Annexe 2 qui figure elle aussi en fin de description, fournit une liste de messages de réponse (descendants) pouvant être employés pour répondre à une problématique de performances (extrait du document 4444 de l'OACI), en réponse aux messages montants. Ainsi, comme illustré par les exemples de messages figurant dans l'annexe 1, on peut définir six grandes catégories ou types de requêtes. Ces types sont référencés notés 0, 1, 1 bis, 2, 3, et 4 dans les trois tableaux de l'annexe 1. La catégorie de requêtes désignée par "type 0" correspond à des calculs basiques et ponctuels des performances de l'aéronef, par exemple le calcul de l'enveloppe de vitesses en fonction de conditions précises. Ainsi, dans le tableau 3 de l'annexe 1, les messages portant les numéros 111, 112, 113 appartiennent à cette catégorie, et concerne l'augmentation ou la diminution de la vitesse de l'aéronef. La catégorie de requêtes désignée par "type 1" correspond aux calculs impliquant l'exploitation d'une version électronique d'un brouillon de plan de vol, c'est-à-dire l'utilisation directe d'un module de calcul « plan de vol » et de ses fonctionnalités classiques de prédictions en temps, vitesses, altitudes, masses, de passage aux divers points du plan de vol, etc. Ceci revient à une modélisation d'intégration des équations de la mécanique du vol. La catégorie de requêtes désignée par "type Ibis" dans le tableau 2 de l'annexe 1 (cf. message N° 58) correspond également aux calculs impliquant l'exploitation d'une version électronique d'un brouillon de plan de vol, mais se distingue du type 1 précité, par le fait que le plan de vol brouillon est utilisé de manière itérative, c'est-à-dire en itérant son utilisation en fonction de la valeur d'un ou plusieurs paramètres d'entrée, jusqu'à trouver le résultat escompté. La catégorie de requêtes désignée par "type 2" dans le tableau 1 de l'annexe 1 (voir, par exemple, le message N° 26) correspond à des calculs effectuant des simulations dites "à rebours". Une simulation à rebours correspond à un cas de vol défini par des conditions "forcées", qui correspondent à une situation finale requise, directement déduite des paramètres du message montant. On notera ici que l'avantage de ce type d'algorithme à rebours c'est-à-dire "en temps décroissants", est qu'il permet d'éviter de devoir mettre en oeuvre des itérations sur un algorithme en "temps croissant" lorsqu'on vise un cas de vol final bien précis. La catégorie de requêtes désignée par "type 3" dans le tableau 1 notamment de l'Annexe 1 (voir par exemple messages N° 171 et 173), concerne les requêtes impliquant des calculs qui sont le plus souvent effectués "manuellement" par le pilote, autrement dit des calculs impliquant majoritairement des opérations manuelles. Ce sont des calculs pour lesquels les dernières générations de calculateurs de gestion du vol (FMS, Flight Management System) n'implémentent pas toujours les algorithmes qui sont à la base de ces calculs. En particulier, il s'agit notamment de calculs de mécanique du vol. Par exemple, l'instruction 171, dans le tableau 1, demande à l'avion de monter à une vitesse verticale minimum donnée (CLIMB AT (vertical rate) MINIMUM). Pour pouvoir répondre au message, le pilote devra utiliser des équations de mécanique du vol, ou alors des abaques û sous forme papier ou bien électronique, lorsqu'ils existent dans les sacoches de vol électroniques û comme expliqué brièvement dans la case "Compléments et commentaires" correspondant à ce message. Enfin, la catégorie de requêtes désignée par "type 4" dans le tableau 2 de l'annexe 1 (voir par exemple messages N° 55, 56, 57 et 61), concerne les requêtes impliquant des calculs nécessitant l'exploitation directe du plan de vol actif, c'est-à-dire le plan de vol officiellement suivi par l'avion. De retour à la figure 1, comme mentionné plus haut, au cours de l'étape E13, le dispositif de réception de messages CPDLC, identifie le type ou catégorie de la requête contenue dans le message reçu, c'est-à-dire les types 0 à 4 précités, et extrait de chaque message les paramètres associés au type de requête identifié, en particulier les valeurs contenues dans les champs associés à l'instruction correspondant à la requête.

A l'étape E17 qui suit, les caractéristiques de vol à calculer sont déterminées en fonction du type de requête identifié et des paramètres associés. Ensuite, à l'étape E19, il est procédé à la sélection d'au moins un module de calcul, parmi un ensemble prédéterminé de modules de calcul, en fonction des caractéristiques de vol à calculer qui ont été déterminées. Puis à l'étape E21, les calculs des caractéristiques de vol nécessaires pour bâtir une réponse au message montant sont effectués. Plus précisément, ces modules de calcul sont respectivement adaptés à mettre en oeuvre les opérations nécessaires au traitement de chaque type de requête identifié, c'est-à-dire adaptés à effectuer : - des calculs de base des performances de l'aéronef ; - des calculs impliquant l'exploitation d'une version électronique d'un brouillon de plan de vol ; - des calculs mettant en oeuvre des simulations de type "à rebours" ; - des calculs automatisant les opérations manuelles traditionnellement requises pour les requêtes de type 3 mentionnées plus haut ; - des calculs impliquant l'exploitation directe de la version électronique du plan de vol actif. A l'étape E23 qui suit, les résultats des calculs effectués par le ou les modules de calcul sélectionnés sont récupérés et analysés. Enfin, à l'étape E25, un brouillon de réponse (PR1) à la requête contenue dans le message reçu, est automatiquement élaboré à partir des résultats de calcul obtenus. En pratique, le procédé de traitement de message selon l'invention, peut comprendre, selon le mode de réalisation choisi, l'une ou plusieurs des étapes suivantes (non représentées à la figure 1) : - Soumission du brouillon de réponse à l'équipage de l'aéronef, via une interface homme-machine adaptée. - Validation par l'équipage, directement ou après modification, via une interface homme-machine adaptée, du brouillon de réponse à la requête ; la validation du brouillon de réponse déclenchant l'envoi du message de réponse à destination du contrôle au sol. - Création et envoi d'un message de réponse final à la requête, ce message de réponse final étant basé sur le brouillon de réponse. En outre, selon un mode de réalisation particulier, l'identification d'un type de requête est précédée des étapes de : - communication à l'équipage, via une interface homme-machine adaptée, du message de requête reçu ; - validation de la mise en oeuvre de l'étape d'identification, en fonction d'une action prédéterminée exercée par l'équipage au moyen de l'interface homme-machine.

On peut également prévoir que le message de requête reçu soit communiqué à l'équipage, via une interface homme-machine, en parallèle avec l'étape d'identification d'un type de requête. La figure 2 représente un système de traitement de messages de requête reçus dans un aéronef depuis le contrôle au sol, incorporant un dispositif de traitement de messages selon l'invention. Ce dispositif de traitement de messages porte le numéro de référence 3 à la figure 2. Comme représenté à la figure 2, le dispositif de traitement d'un message de requête selon l'invention comprend les modules suivants : - un module 31 d'analyse de messages destiné à identifier un type de requête contenue dans le message reçu, à extraire des paramètres associés au type de requête identifié, et à déterminer des caractéristiques de vol à calculer, en fonction du type de requête identifié et des paramètres associés ; - un ensemble de n modules (351 û 35n) de calcul de caractéristiques de vol de différentes catégories ; - un module 33 de sélection de ressources de calcul, destiné à sélectionner au moins un module de calcul, parmi l'ensemble prédéterminé de modules de calcul, en fonction des caractéristiques de vol à calculer déterminées, le ou les modules de calcul sélectionnés étant chargés de calculer les caractéristiques de vol déterminées ; - un module 37 de création de brouillon de réponse, destiné à créer un brouillon de réponse à la requête à partir des résultats de calcul obtenus par le (ou les) module(s) de calcul sélectionné(s).

Le module de création 37 d'un brouillon de réponse élabore ainsi de façon automatique un brouillon de message de réponse, en fonction du message montant (issu du contrôleur) et des résultats de calcul effectués par le ou les modules appropriés. Un tel brouillon de réponse est conforme aux messages de réponse descendants (downlink) normalisés, indiqués dans les tableaux de l'Annexe 2. Un tel message de réponse peut être constitué d'un ou plusieurs messages descendants prévus par la normalisation (cf. Annexe 2). A titre d'exemples, dans l'Annexe 2 : - le message numéroté '3' signifie "Bien reçu" (ROGER), sans autres commentaires car l'instruction initiale ne pose pas de problème ; - le message numéroté '0' signifie "OK, j'accepte la demande" réponse par exemple à une demande formelle de trajectoire du contrôleur ; - le message numéroté '1' signifie : "Je suis incapable de réaliser la trajectoire demandée" et peut être concaténé à un message numéroté 66 signifiant "Pour des raisons de performances" ; - le message numéroté 81 signifie : "Je peux réaliser le changement de niveau demandé", en renseignant les champs "levef' (niveau) et "time" (temps) de la manière suivante. Le paramètre "lever est celui contenu dans la sollicitation du contrôleur, et le paramètre "time" est celui issu du calcul ; si le calcul indique que le changement de niveau est réalisable immédiatement, le paramètre "time" sera l'heure d'élaboration du message brouillon ou, dans une variante, l'heure d'émission vers le sol. De retour à la figure 2, le système de traitement de messages CPDLC 25 comprend classiquement : - un dispositif 23 de réception de messages (MSG) M1 ; - un dispositif 25 de création et/ou modification, non automatique, de messages de réponse ; - un dispositif d'émission de messages (MSG) de réponse (messages 30 descendants) R1. Selon un mode de réalisation particulier, le dispositif de traitement 3 selon l'invention comprend en outre un module de soumission (non représenté) du brouillon de réponse élaboré, au pilote ou à l'équipage de l'aéronef, via une interface homme-machine adaptée, par exemple le dispositif d'affichage cockpit 23. Comme mentionné précédemment, les modules de calcul 35(l_n) automatisent les traitements classiquement opérés manuellement par l'équipage, ou au moyens d'outils de calcul commandés ou manipulés par l'équipage. Ainsi, en pratique, les modules de calculs 35(1_n) implémentent, au moins en partie, les spécifications techniques détaillées (DTS) du système de gestion de vol (Flight Management System - FMS), telles que, par exemple, celles relatives au calcul d'enveloppes de vitesse, ou bien utilisent des équations connues de mécanique du vol (équation de propulsion par exemple). Pour les requêtes de "type 1", le traitement automatique mis en oeuvre par le module de calcul sélectionné comprend notamment les opérations suivantes : - création d'un plan de vol brouillon en copiant le plan de vol actif actuel; - modification des paramètres de vol (par exemple, montée depuis un point précis à un niveau de vol désigné), ou ajout d'une contrainte ; - récupération des résultats de calcul ; - extraction des éléments nécessaires à l'élaboration de la réponse (par exemple, capacité ou non de rejoindre le niveau de vol inséré dans le brouillon); - élaboration de la réponse à la question et affichage dans le cockpit de la réponse. En variante, pour les messages de type 1, Ibis ou 2, les calculs de simulations peuvent utiliser des modélisations simplifiées ù c'est-à-dire n'utilisant pas de calculs de prédictions en premier principe, comme par exemple des forfaits ou une formule de Bréguet, par exemple ù afin d'améliorer les temps de réponse. En effet, l'utilisation d'un calcul de prédictions de plan de vol brouillon utilise déjà de base des algorithmes précis mais complexes et peut se révéler coûteux en temps de calcul. Pour les requêtes de type 2, le traitement automatique effectué par le module de calcul sélectionné consiste en la mise en oeuvre d'une simulation à rebours. A cette fin, des lois connues de régression temporelle sont utilisées pour modéliser à l'envers (dans le sens de l'accroissement) l'évolution de la masse, de la trajectoire latérale, des vitesses et de l'altitude de l'aéronef. La simulation à rebours est interrompue pour une condition de vol donnée et les prédictions sont récupérées. Ensuite, les éléments nécessaires à l'élaboration de la réponse au message de requête sont extraits, par exemple la capacité ou non de rejoindre le niveau de vol inséré dans le brouillon. La réponse à la question est finalement élaborée et affichée dans le cockpit. Pour les requêtes de type 3, le traitement automatique les opérations manuelles, mentionnées plus haut, traditionnellement requises pour les requêtes de type 3, par exemple des calculs de mécanique du vol. Pour les requêtes de type 4, le traitement automatique effectué par le module de calcul sélectionné consiste notamment en : - la récupération des prédictions de l'actuel plan de vol actif ; - pour la position, le temps ou la vitesse fournis en paramètres de la requête (clearance CPDLC), récupération des conditions relatives à l'avion (par exemple la masse) et à l'environnement (par exemple, température ou vents prédits) ; - calcul des performances ponctuelles autour du point de vol défini ci- dessus, il s'agit là du même type de calculs que ceux visés pour le type 0 de calculs exposé plus haut (par exemple, enveloppe de vitesses, calcul classique de performances). Le fonctionnement du système de traitement de messages représenté à la figure 2, est le suivant. Selon un mode de réalisation choisi, le dispositif de réception 21 communique (flèche F1 b) le message de requête M1 reçu à l'équipage, via le dispositif d'affichage cockpit 23, et le transmet en parallèle (flèche F1 a) au module d'analyse de message pour identification du type de la requête. En variante, comme représenté par les flèches successives F1 b et F2, le message reçu est d'abord communiqué (flèche F1 b) à l'équipage, via une interface homme-machine adaptée, ici le dispositif d'affichage 23. Puis, en réponse à une validation par l'équipage au moyen d'une interface de commande adaptée, l'opération d'identification est déclenchée et le message reçu est transmis au module d'analyse 31 (flèche F2). Selon un mode de réalisation, le brouillon de réponse élaboré par le module 37 de création de brouillons de réponse, est transmis (flèche F6) systématiquement au dispositif d'affichage 23 et ainsi soumis à l'équipage. Dans ce cas, l'équipage peut modifier le message de réponse via le dispositif de Création/Modification 25 (flèche F3) û comme c'est le cas dans l'état de la technique û puis déclencher son envoi (flèche F4). L'équipage peut aussi déclencher directement l'envoi du message sans le modifier (flèche F5).

Dans une variante de réalisation, le module 37 de création de message, peut directement et automatiquement transmettre le message de réponse au dispositif d'émission 27 de message, comme représenté par la flèche F7. En pratique, les modules précités constitutifs d'un dispositif 3 de traitement de messages selon l'invention, sont mis en oeuvre sous forme de modules logiciels, c'est-à-dire un ou plusieurs programmes d'ordinateur formant un ensemble et comprenant des instructions adaptées à la mise en oeuvre du procédé de traitement d'un message de requête, selon l'invention. Un procédé selon l'invention est par conséquent mis en oeuvre lorsque ce ou ces programmes sont chargés et exécutés dans un système informatique embarqué dans un aéronef. On notera aussi qu'un programme d'ordinateur selon l'invention, dont la finalité est la mise en oeuvre de l'invention lorsqu'il est exécuté par un système informatique approprié, peut être stocké sur un support d'information de types variés. En effet, un tel support d'information peut être constitué par n'importe quelle entité ou dispositif capable de stocker un programme selon l'invention. Par exemple, le support en question peut comporter un moyen de stockage matériel, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette ou un disque dur. En variante, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant utilisé pour la mise en oeuvre du procédé considéré.

D'un point de vue conception, un programme d'ordinateur selon l'invention peut utiliser n'importe quel langage de programmation et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet (par ex., une forme partiellement compilée), ou dans n'importe quelle autre forme souhaitable pour implémenter un procédé selon l'invention. 5 Annexe 1 Extraits de listes de messaqes montants (clearances) liés à une problématique de performances (extrait du document 4444 de l'OACI) Tableau 1 : Clairances verticales N° Message Message N° MSG Type Compléments et intention/usage de de commentaires retour calcul 6 Notification qu'une EXPECT 3 si OK ; 1 Utilisation de la instruction de (level) 82 & 66 si fonction STEP ALT : changement de niveau pas (level) et observation doit être attendue. capable de la réponse (capable ou pas) 7 Notification qu'une EXPECT 3 si OK ; 1 1) Détermination de instruction doit être CLIMB AT 1 & 66 si la position et de la attendue indiquant à (time) pas masse avion à l'aéronef de capable (time) commencer à monter 2) Utilisation de la au temps spécifié. fonction STEP ALT : niveau courant + 2000 ft 3) Observation de la réponse (capable ou pas) 19 Instruction de MAINTAIN 0 si OK ; 1 maintenir le niveau (level) 1, 82 & 66 spécifié. si pas capable 24 Instruction d'initier à 0 si OK ; un temps spécifié une AT (time) 1 & 66 si 1 descente à un niveau DESCEND pas spécifié, et de TO (level) capable maintenir le niveau spécifié une fois atteint. 26 Conditions finales Instruction d'initier CLIMB TO 0 si OK ; requises : altitude égale une montée à un taux REACH 1 & 66 si à (level), vitesse égale à tel que le niveau (level) BY pas 2 la vitesse courante, spécifié soit atteint à, (time) capable masse calculée grâce à ou avant, le temps un forfait de délestage spécifié. en montée. Calcul à rebours de la montée. Il reste à comparer la somme de la durée de montée et du temps N° Message Message N° MSG Type Compléments et intention/usage de de commentaires retour calcul courant par rapport à (time). 27 Instruction d'initier CLIMB TO 0 si OK ; 2 Conditions finales une montée à un taux REACH 1 & 66 si requises : altitude égale tel que le niveau (level) BY pas à (level), vitesse égale à spécifié soit atteint à, (position) capable la vitesse courante, ou avant, la position masse calculée grâce à spécifiée. un forfait de délestage en montée. Calcul à rebours de la montée. Il reste à comparer la somme de la distance de montée et de la position courante par rapport à (position). 28 Instruction d'initier DESCEND 0 si OK ; 2 Conditions finales une descente à un taux TO REACH 1 & 66 si requises : altitude égale tel que le niveau (level) BY pas à (level), vitesse égale à spécifié soit atteint à, (time) capable la vitesse courante, ou avant, le temps masse calculée grâce à spécifié. un forfait de délestage en descente. Calcul à rebours de la descente. Il reste à comparer la somme de la durée de descente et du temps courant par rapport à (time). 29 Instruction d'initier DESCEND 0 si OK ; 2 Conditions finales une descente à un taux TO REACH 1 & 66 si requises : altitude égale tel que le niveau (level) BY pas à (level), vitesse égale à spécifié soit atteint à, (position) capable la vitesse courante, ou avant, la position masse calculée grâce à spécifiée. un forfait de délestage en descente. Calcul à rebours de la descente. Il reste à comparer la somme de la distance de descente et de la position courante par rapport à (position). 192 Instruction de REACH 0 si OK ; 2 Tester le niveau (level) poursuivre un (level) BY 1 & 66 si demandé va impliquer changement de niveau, (time) pas une montée ou une mais à un taux tel que capable descente, puis le niveau spécifié soit référence aux messages atteint à, ou avant le N° Message Message N° MSG Type Compléments et intention/usage de de commentaires retour calcul temps spécifié. 26 ou 28 209 Instruction qu'un REACH 0 si OK ; 2 Test le niveau (level) changement de niveau (level) BY 1 & 66 si demandé va impliquer doit être poursuivi, (position) pas une montée ou une mais à un taux tel que capable descente, puis le niveau spécifié soit référence aux messages atteint à, ou avant la 27 ou 29 position spécifiée. 171 Instruction de monter CLIMB AT 0 si OK ; 3 Utilisation Mécanique avec un taux supérieur (vertical rate) 1 & 66 si du vol (équation ou égal au taux MINIMUM pas propulsion) avec pente spécifié. capable totale figée (configuration avion actuelle, régime max climb) et utilisation loi de vitesse courante (CAS ou Mach constant). La vitesse verticale maximum est déduite de ces hypothèses. 173 Instruction de DESCEND 0 si OK ; 3 Utilisation Mécanique descendre avec un AT (vertical 1 & 66 si du vol (équation taux supérieur ou égal rate) pas propulsion) avec pente au taux spécifié. MINIMUM capable totale figée (configuration avion actuelle, régime idle) et utilisation loi de vitesse courante (CAS ou Mach constant). La vitesse verticale minimum est déduite de ces hypothèses. Variante : l'utilisation des aérofreins peut être admise.5 5 Tableau 2 : Contraintes de croisement N° Message Message N° MSG Type Compléments et intention /usage de de commentaires retour calcul 55 Instruction de traverser CROSS 0 si OK ; 4 Récupération des la position spécifiée à (position) AT 1 & 66 si informations prédites la vitesse spécifiée qui (speed) pas (masse, niveau, vent et doit être maintenue capable T°) au waypoint ensuite jusqu'à nouvel "position", puis calcul ordre. d'enveloppes de vitesses. 56 Instruction de traverser CROSS 0 si OK ; 4 Récupération des la position spécifiée (position) AT 1 & 66 si informations prédites avec une vitesse OR LESS pas (masse, niveau, vent et inférieure ou égale à la THAN (speed) capable T°) au waypoint vitesse spécifiée, et de "position", puis calcul garder ensuite une d'enveloppes de vitesse inférieure ou vitesses. égale à la vitesse spécifiée jusqu'à nouvel ordre. 57 Instruction de traverser CROSS 0 si OK ; 4 Récupération des la position spécifiée (position) AT 1 & 66 si informations prédites avec une vitesse OR pas (masse, niveau, vent et supérieure ou égale à la GREATER capable T°) au waypoint vitesse spécifiée, et de THAN (speed) "position", puis calcul garder ensuite une d'enveloppes de vitesse supérieure ou vitesses. égale à la vitesse spécifiée jusqu'à nouvel ordre. 58 Instruction de traverser CROSS 0 si OK ; Ibis Itération sur le point de la position spécifiée au (position) AT 1 & 66 si début de montée / temps spécifié et au (time) AT pas descente et les vitesses niveau spécifié. (level) capable de vol (utilisation d'un Cost Index (CI) virtuel par exemple) 61 Instruction de traverser CROSS 0 si OK ; 4 1) Récupération des la position spécifiée au (position) AT 1 & 66 si prédictions issues du niveau et vitesse AND pas plan de vol Actif, pour spécifiés, et de MAINTAIN capable la (position) demandée maintenir ensuite le (level) AT 2) calcul de niveau et la vitesse. (speed) l'allègement compte tenu de la montée vers (level) 3) calcul d'enveloppe de vitesses 10 Tableau 3 : Changements de vitesse N° Message Message N° MSG Type Compléments et intention /usage de de commentaires retour calcul 111 Instruction d'augmenter INCREASE 0 si OK ; 0 la vitesse actuelle à la SPEED TO 1, 84 & 66 vitesse spécifiée et de (speed) si pas maintenir cette vitesse capable jusqu'à nouvel ordre. 112 Instruction d'augmenter INCREASE 0 si OK ; 0 la vitesse actuelle pour SPEED TO 1, 84 & 66 atteindre une vitesse (speed) OR si pas supérieure ou égale à la GREATER capable vitesse spécifiée, puis maintenir ou dépasser cette vitesse jusqu'à nouvel ordre. 113 Instruction de réduire REDUCE 0 si OK ; 0 la vitesse actuelle à la SPEED TO 1, 84 & 66 vitesse spécifiée et de (speed) si pas maintenir cette vitesse capable jusqu'à nouvel ordre. Tableau 4 : Requêtes de négociation (lien montant) N° Message Message N° MSG Type Compléments et intention /usage de de commentaires retour calcul 148 Demande du temps le WHEN CAN 81 si OK ; Ibis Si descente, pas de plus proche où le YOU 82 si pas problématique niveau spécifié peut ACCEPT capable performances. être accepté. (level) Pour montée, itération sur le temps de mise en montée vers (level). Sous-entendu à Iso Mach. Par défaut la précision souhaitée est à une minute. 3 Variante pour le message 148 (cas de montée) : N° Message Message N° MSG Type Compléments et intention /usage de de commentaires retour calcul 1) calcul délestage montée vers (level) 2) calcul délestage / unité de temps en vol croisière suivant les hypothèses courantes 3) Itération sur calcul d'enveloppe à (level) pour déterminer la masse minimale nécessaire pour déclencher la montée 4) Conversion de la masse obtenue en 3 en temps, grâce aux points 1) et 2). Annexe 2 Liste de messaqes descendants pouvant être employés pour répondre à une problématique de performances (extrait du document 4444 de l'OACI)

Tabif: A5-13. Re: pon.5es own ink) lÉS 7ge i<e~'.'rtç: ~! ~ G _`4LR.: The n'ann:t~en und sto 3 .nd w<J ,4~°IL{.O N M N be Coinphed t.,th. Th m3nuchon canne lie cc~ `_ed LTN.BLE `N M N wlth. ~. s~T.3St-fo 3.1epi:'. SLi vDBY ti M N ~Ies.s ge i .cei.-ed aad un le u d. ROGER \ M N 4 s` Y. AFFlR N M N No. NEcATIVE \ M N 2953668 2 4 Table A5-23. Additionemes5ages (downIlhp MeSSCgO Messageeiene .AIRT f.55 L'ed tc eXphin te yoii's kif pilot' DUE TO .WEATHER L N 5,ied- e.-xPL3111 :fin pile DUE :#.a AIRCRAFT L L N PERFORMANCE Table A5-24: Ngotiatiea. respi)mes (dweinlii) Merig ,wnytir:ese Message Et2emett ili_F ÀLRT RE,SP We can accept the 11:e..cafied lewl WE CAN ACCEPT L L N die t cified haut. AT fflmej 115 We can accept the %aehlfred E ('AN ACCEPT L L N the pecified po,htion_ AT r'psto.

82 We came 1ccept the specified level.. WE CANI'ZOT ACCEPT L .L N We accept the sçecified speed WE CAN ACCEPT L L N cati the 'specified tinte. AT (tieie) 116 accept the ,;thilfied WE CAN ACCEPT L L N .p? fiel ^z ltiÿk3i. AT p:::.s:'elon) 84 We cannot accept die Çpecrfied CANNOT ACCEPT L L N espee 85 We can accept a pa.rallel Ira& ctiliei WE CAN ACCEPT (.ÿe k7 L L N the tfecified distance in the specified dfseimc:e) Oreillit.a) AT direction at: die specified h:rue. 11- 7 We mn accept F.ra'ilel hmi offiet WE CAN ACCEPT (speeed L N die pecified distmice in the sperified Oreeto?i) AT direction at the ieecified poitien_ t16 caiinot accept a parailel tract WE CANNOT ACCEPT L L N cffie. the .,iTecified distance ln the secifted Tecified direction. i.dirccn) Note.ù Wi'te.vi;er tae ievei speeeed, ;he elsc.ge can peft ec.;ter stagie ee.teci iitage, 5

Claims (12)

1. REVENDICATIONS1. Procédé de traitement d'un message de requête reçu (El 1) dans un aéronef depuis le contrôle aérien via un système de transmission de données, ledit procédé comprenant l'identification (E13) d'un type de requête contenue dans le message reçu et l'extraction (E15) de paramètres associés au type de requête identifié ; ledit procédé étant caractérisé en ce qu'il comporte en outre des étapes de : - détermination (E17) de caractéristiques de vol à calculer, en fonction du type de requête identifié et desdits paramètres associés ; - sélection (E19) d'au moins un module de calcul, parmi un ensemble prédéterminé de modules de calcul, en fonction des caractéristiques de vol à calculer déterminées ; - calcul (E21) desdites caractéristiques de vol par ledit au moins un module de calcul sélectionné, et obtention de résultats de calcul ; - création (E23, E25) d'un brouillon de réponse à ladite requête à partir des résultats de calcul obtenus.
2. 2. Procédé selon la revendication 1, comprenant en outre une étape de soumission dudit brouillon de réponse à l'équipage de l'aéronef, via une interface homme-machine adaptée.
3. 3. Procédé selon la revendication 2, dans lequel l'équipage valide, directement ou après modification, via ladite interface homme-machine, ledit brouillon de réponse à la requête, la validation du brouillon de réponse déclenchant l'envoi d'un message de réponse à destination du contrôle au sol.
4. 4. Procédé selon la revendication 1, comprenant en outre une étape de création et d'envoi d'un message de réponse à ladite requête, ledit message de réponse étant basé sur ledit brouillon de réponse.
5. 5. Procédé selon l'une quelconque des revendications 1 à 4, dans lequel l'étape d'identification d'un type de requête est précédée des étapes de : - communication à l'équipage, via une interface homme-machine adaptée, du message de requête reçu ; - validation de la mise en oeuvre de ladite étape d'identification, en fonction d'une action prédéterminée exercée par l'équipage au moyen de l'interface homme-machine.
6. 6. Procédé selon l'une quelconque des revendications 1 à 4, dans lequel le message de requête reçu est communiqué à l'équipage, via une interface homme-machine, en parallèle avec l'étape d'identification d'un type de requête.
7. 7. Procédé selon l'une quelconque des revendications précédentes, dans lequel ledit ensemble prédéterminé de modules de calcul comprend au moins des modules destinés respectivement à effectuer l'une des catégories de calcul suivantes : - calculs de base des performances de l'aéronef ; - calculs impliquant l'exploitation d'une version électronique d'un brouillon de plan de vol ; - calculs mettant en oeuvre des simulations de type "à rebours" ; - calculs impliquant majoritairement des opérations manuelles - calculs impliquant l'exploitation directe de la version électronique du plan de vol actif.
8. 8. Dispositif de traitement d'un message de requête reçu dans un aéronef depuis le contrôle au sol via un système de transmission de données, ledit dispositif comprenant : - un module (31) d'analyse de messages destiné à identifier un type de requête contenue dans le message reçu, à extraire des paramètres associés autype de requête identifié, et à déterminer des caractéristiques de vol à calculer, en fonction du type de requête identifié et desdits paramètres associés ; - un ensemble de modules (351-35n) de calcul de caractéristiques de vol de différentes catégories ; - un module (33) de sélection de ressources de calcul, destiné à sélectionner au moins un module de calcul, parmi l'ensemble prédéterminé de modules de calcul, en fonction des caractéristiques de vol à calculer déterminées, ledit au moins un module de calcul sélectionné étant chargé de calculer lesdites caractéristiques de vol déterminées ; - un module (37) de création de brouillon de réponse, destiné à créer un brouillon de réponse à ladite requête à partir des résultats de calcul obtenus par ledit au moins un module de calcul sélectionné.
9. 9. Dispositif selon revendication 8, comprenant en outre un module de soumission dudit brouillon de réponse à l'équipage de l'aéronef, via une interface homme-machine adaptée.
10. 10. Dispositif selon la revendication 8 ou 9, comportant des moyens adaptés à la mise en oeuvre d'un procédé de traitement d'un message de requête, selon l'une quelconque des revendications 3 à 7.
11. 11. Aéronef caractérisé en ce qu'il comporte un dispositif de traitement d'un message de requête, selon l'une quelconque des revendications 8 à 10.
12. 12. Programme d'ordinateur sur un support d'informations, caractérisé en ce qu'il contient des instructions de programme adaptées à la mise en oeuvre d'un procédé de traitement d'un message de requête, selon l'une quelconque des revendications 1 à 7, lorsque ce programme est chargé et exécuté par un système informatique.