FR3067805A1 - Aide a la decision pour le pilotage d'un aeronef - Google Patents

Abstract

Différentes modalités de régulation et/ou d'intégration de systèmes avioniques avec des systèmes non-avioniques ou ouverts (à fiabilité moindre) sont décrites. Des développements de l'invention décrivent notamment différentes modalités d'interaction homme-machine, de manière à faciliter l'exploration, par le pilote, des possibles déterminées par des systèmes non-avioniques aux capacités supérieures à l'avionique. Des développements décrivent des étapes et critères d'optimisation dans les systèmes ouverts, l'utilisation de ressources de calcul par exemple distantes et de données étendues, des dispositifs de sélection graphique d'une route candidate, par manipulation du temps en particulier. Des aspects de logiciel et de système sont décrits (E.F.B. et F.M.S.)

Description

AIDE A LA DECISION POUR LE PILOTAGE D’UN AERONEF

Domaine de l’invention

L’invention concerne le domaine de l’avionique en général. En particulier, l’invention concerne des procédés et des systèmes pour l’aide à la décision du pilote d’un aéronef. Des exemples d’exploration, notamment au cours du temps, des données relatives au vol de l’aéronef sont décrits.

Etat de la Technique

Les différents plans de vol (e.g. plan de vol courant, révisions, alternatives, prédictions, etc) manipulés par le pilote et/ou l’avionique embarquée dans un aéronef sont nombreux et complexes.

Le plan de vol d’un aéronef (e.g. avion, drone, hélicoptère) manipulé par le pilote au moyen des équipements de type avionique comprend généralement différents éléments. Le plan de vol « référence initial » constitue le plan de vol que la compagnie aérienne a dans ses bases de données. C’est le plan de vol que la compagnie dépose auprès des services de la navigation aérienne ou de YATC control flot. Le plan de vol de « référence » en vol correspond au plan de vol que l’avionique est en train de voler jusqu’à l’aéroport d’arrivée. Dans l’avionique, ce plan de vol est appelé « plan de vol actif ». Les plans de vols « alternatifs » désignent tous les plans de vol que le pilote et/ou le système peuvent créer dans le monde non-avionique ouvert (et/ou dans l’avionique) en prenant en compte des hypothèses variées comme un vol en mode économique (ou un vol avec un critère de coût différent), un vol pour respecter certaines contraintes de temps à certains/tous les points/le point d’arrivée, un vol avec un chemin latéral différent du plan de vol de référence, un vol avec des altitudes différentes du plan de vol de référence, un vol avec des vitesses ou « cost index » différents du plan de vol de référence, un vol alternatif avec des limitations en vitesse, plafond, trainée, etc. différents de la base de données de performances de référence (pour tenir compte des limitations en vol liés à la structure avion, inséré par le pilote ou plus généralement d’un vol avec un ou plusieurs paramètres différents du plan de vol de référence.

Dans les systèmes existants, même dans les cockpits d’aéronefs modernes, la manipulation (e.g. détermination, visualisation, édition, etc) de ces plans de vol est limitée en raison de plusieurs facteurs.

Dans les systèmes avioniques connus, les plans de vol sont manipulés par le système de gestion de vol (ou Flight Management System, acronyme FMS) en lien avec des interfaces homme-machine (IHM), comprenant des systèmes de saisies et des écrans d’affichage situés dans le cockpit.

Ces équipements de type avionique présentent des limitations, de différentes natures.

Par exemple, les capacités d’affichage embarquées sont limitées. Les écrans sont en nombre fini, et l’espace d’affichage se révèle exigu pour l’affichage d’une très grande quantité d’informations.

Les contenus affichés sont généralement normalisés ou standardisés, laissant peu de flexibilité à la marge. L’ergonomie des interfaces est généralement déterminée et ne peut pas être substantiellement modifiée. En particulier, l’affichage du plan de vol complet est peu lisible en raison des limitations énumérées. En ce qui concerne les plans de vol alternatifs, les interfaces connues permettent d’afficher le plan de vol actif et un seul autre plan de vol alternatif.

De fait, la navigation dans les données du vol (l’exploration des options) est rendue laborieuse sinon impossible. Par exemple, le déroulement pas-à-pas des plans de vol n’est pas permise par l’avionique contemporaine et ne devrait pas l’être à moyen terme à cause des ressources sollicitées, notamment en matière de processeurs qui sont requis pour permettre ce type de traitement.

Les limitations d’affichage, d’ergonomie et de ressources de calcul ne sont pas les seuls facteurs limitants. Concernant la prise en compte de la météorologie, dont les données sont critiques pour tout aéronef, la portée du radar météorologique avionique embarqué est limitée, de manière inhérente, généralement de l’ordre de 200 miles nautiques (NM). La profondeur de pilotage actuelle ne permet donc pas de considérer des conditions de bout en bout du plan de vol.

Représentatif des approches connues, le document de brevet EP1757520 intitulé « Tastature multifonctionelle pour tableau de bord d'avion à curseur» décrit un système de commande et d'affichage. Un pilote ou un copilote peuvent réaliser l'entrée du plan de vol et la modification en manipulant des informations graphiques et textuelles sur les dispositifs d'affichage en utilisant un dispositif de commande à curseur et un clavier multifonction. L'interface substantiellement centralise les commandes d'avionique dans un seul contrôleur, et réduit le temps de tête basse de l'équipage. Cette approche ne fait intervenir que des moyens de type avioniques et requiert de nombreuses manipulations de données. Cette approche présente d’autres limitations.

II existe un besoin pour des procédés et des systèmes avancés d’aide à la décision pour le pilotage d’un aéronef.

Résumé de l’invention

Différentes modalités de régulation et/ou d’intégration de systèmes avioniques avec des systèmes non-avioniques ou ouverts (à fiabilité moindre) sont décrites. Des développements de l’invention décrivent notamment différentes modalités d’interaction homme-machine, de manière à faciliter l’exploration, par le pilote, des possibles déterminées par des systèmes non-avioniques aux capacités supérieures à l’avionique. Des développements décrivent des étapes et critères d’optimisation dans les systèmes ouverts, l’utilisation de ressources de calcul par exemple distantes et de données étendues, des dispositifs de sélection graphique d’une route candidate, par manipulation du temps en particulier. Des aspects de logiciel et de système sont décrits (E.F.B. et F.M.S.)

Avantageusement, les modes de réalisation de l’invention apportent une aide à la décision pour le pilote.

Dans un mode de réalisation avantageux, l’invention permet au pilote (ou aux systèmes embarqués) d’anticiper et de gérer de façon stratégique les évènements intervenant lors du déroulement d’un vol.

Selon les modes de réalisation, cette aide à la décision peut être réalisée en boucle ouverte i.e. recevoir des commandes (binaires ou des instructions interprétables i.e. plus complexes) de la part du pilote et/ou de système tiers, mais peut également être effectuée en boucle fermée (e.g. applications de règles logiques traduisant le modèle de décision). Dans certains modes de réalisation, par exemple en raison d’exigences règlementaires, le pilote peut conserve l’initiative et peut affiner les alternatives jusqu’à celle qu’il considère optimale.

Avantageusement, un mode de réalisation de l’invention permet le déport graphique des informations vers le monde ouvert (tablettes informatiques à haute résolution, projecteurs, réalité augmentée et/ou virtuelle), ce qui pallie aux insuffisances des interfaces de type avionique et les complémente. Ainsi, l’affichage d’une pluralité de plans de vol alternatifs devient possible.

Avantageusement, un mode de réalisation de l’invention permet une visualisation réaliste et/ou en continu du déroulement du vol ou de ses alternatives. Le pilote peut « simuler » le vol dans le temps. Par exemple, le déroulement du vol peut être commandé en faisant croître ou décroître le temps.

Avantageusement, un mode de réalisation de l’invention permet de déterminer en tout point du plan de plan de vol (ou de ses révisions ou alternatives), des éléments tels que les éléments dits « 5D » (i.e. position 3D, Fuel restant et temps) du vol tel que prévu à l’instant t, la vitesse de l’avion et des éléments concernant l’environnement du vol (e.g des évènements météo Cb, turbulences, METAR, TAF, vents, etc ; le trafic environnant via l’ADS-B ou le lien dit data link).

Avantageusement, un mode de réalisation de l’invention permet de prendre en compte des données météorologiques significativement plus complètes. Les instruments non-avioniques peuvent en effet accéder à tout type d’événement météorologique, de manière actualisée et couvrant la totalité du vol.

Plus généralement, en se rapprochant de l’exhaustivité, l’accès à un grand nombre de données d’origine non-avionique et/ou l’accès à des ressources de calcul plus importantes (par exemple accédées à distance, élastiques, à la demande, etc) permettent une meilleure gestion du vol (prise en compte des évènements qui peuvent perturber le déroulement du vol), améliorant la sécurité et la sûreté aéronautique.

Avantageusement, l’invention peut être mise en oeuvre dans une application logicielle fournissant des outils pour optimiser les plans de vol et exécutée par exemple sur/par un EFB (Electronic Flight bag).

Avantageusement, l’invention peut être mise en œuvre au sein d’avions contemporains comprenant des systèmes de gestion de vol FMS de dernière ou de nouvelle génération. Ces systèmes de gestion de vol FMS, par exemple les FMS de type « Open Capacity » (à capacités ouvertes) offrent par défaut des liens de communication avec des systèmes non-avioniques. Ces liens de communication peuvent être utilisés par l’invention. Des FMS d’ancienne génération peuvent être adressés de différentes manières, notamment au travers de liens de communication existants (data link, liens sol-bord détaillés ciaprès).

Avantageusement, au-delà des seules ressources avioniques, des données enrichies, des capacités de calcul et des modalités d’interaction hommemachine de type non avioniques peuvent être mises en œuvre. Des données d’origine non avionique mais complémentaires (e.g. météorologie sur la totalité du vol) peuvent être prises en compte. Des ressources de calcul extérieures à l’avionique (e.g. tablette, ordinateur portable, serveur déporté, ressources distantes type cloud computing) peuvent être sollicitées (par exemple permettant la détermination puis l’évaluation puis l’insertion de la route alternative dans l’avionique). Des procédés et des méthodes d’interaction homme-machine modernes, fiables, robustes, éprouvés voire standards de fait, à la courbe d’apprentissage rapide (e.g. écrans tactiles, à retour de force, réalité augmentée et/ou virtuelle) peuvent faciliter la navigation dans le volume de données calculées.

Avantageusement, l’invention peut trouver application pour la gestion de vol ou de mission d’un aéronef, que ce soit avant ou pendant le vol.

Avantageusement, l’invention peut être implémentée sur des tablettes utilisables à bord ou en escale hors de l’avion. Elle peut être déployée sur des EFB à bord de l’avion. Elle peut également être proposée au sol dans les centres opérationnels compagnie, en assurant les échanges avec l’avionique à travers les fonctions de liaison de donnée sol-bord.

Description des figures

Différents aspects et avantages de l’invention vont apparaître en appui de la description d’un mode préféré d’implémentation de l’invention mais non limitatif, avec référence aux figures ci-dessous :

La figure 1 illustre l'environnement technique global de l'invention ;

La figure 2 illustre des exemples d’intégration des systèmes de type avionique avec des systèmes de type non-avionique ;

La figure 3 illustre un exemple de contrôle de l’affichage d’un plan de vol selon un mode de réalisation de l’invention;

La figure 4 montre des exemples d’étapes d’un mode de réalisation du procédé selon l’invention.

Description détaillée de l’invention

Un aéronef au sens de l’invention est un moyen de transport capable d'évoluer au sein de l'atmosphère terrestre. Par exemple, un aéronef peut être un avion ou un hélicoptère (ou bien encore un drone). Par extension, les modes de réalisation de l’invention sont applicables à tout type de transport terrestre, naval, aérien, aérospatial (optimisation de trajectoires orbitales).

La gestion de mission d’un aéronef est de plus en plus complexe. Les données sont plus nombreuses et plus complexes. Les traitements effectués sur ces données sont également plus nombreux et plus complexes.

En particulier, il peut être tiré avantage d’une intégration particulière entre un ou plusieurs systèmes de type avionique et un ou plusieurs systèmes de type nonavionique.

La figure 1 illustre l'environnement technique global de l'invention.

La figure montre des exemples de systèmes (ou « équipements » ou « instruments » ou « matériels » ou « appareils » ou « moyens ») de type « nonavionique » ou « (monde) ouvert » et des équipements de type « avionique » (certifié par le régulateur).

Un aéronef est un moyen de transport capable d'évoluer au sein de l'atmosphère terrestre. Par exemple, un aéronef peut être un avion ou un hélicoptère (ou bien encore un drone). L'aéronef comprend une cabine de pilotage ou un cockpit 120. Au sein du cockpit se trouvent des équipements de pilotage 121 (dits équipements avioniques, certifiés par le régulateur aéronautique) et des équipements optionnels (dits non-avioniques ou « monde ouvert »).

Un « système avionique » (ou « système de type avionique ») est un système présentant des caractéristiques techniques spécifiques en comparaison d’un système « non-avionique » (ou « système de type non-avionique » ou « monde ouvert »), ces caractéristiques techniques étant certifiées administrativement par une autorité de confiance (en l’occurrence le régulateur aéronautique). Techniquement, des délégations d’autorités peuvent permettre à l’avenir une gestion de nature technique de cette gestion de type administrative (e.g. crypto ledgers).

Concernant les caractéristiques techniques distinctives d’un système avionique, un système - de manière générale, i.e. avionique ou non-avionique - peut présenter ou être associé avec un taux de défaillance prédéfini (parmi une plage de taux de défaillance prédéfinie), un taux de défaillance comprenant ou déterminant un taux d’erreur d’exécution prédéfini. Dans un mode de réalisation, le taux de défaillance d’un système de type avionique est inférieur au taux de défaillance d’un système de type non-avionique. Dans un mode de réalisation, le taux de défaillance d’un système avionique est significativement ou substantiellement inférieur à celui d’un système non-avionique.

Un système avionique désigne un système fiabilisé (ou à fiabilité garantie). C’est un système dont la défaillance a des conséquences excédant des limites acceptées ou acceptables, donc redoutées. Une défaillance peut se caractériser par la perte de la fonction considérée, ou par la production de données erronées, avec ou sans détection d’une erreur. Selon le niveau de criticité des conséquences redoutées, la probabilité d’occurrence doit être maintenue inférieure à un seuil d’acceptabilité. Ainsi, plus la conséquence est critique, pour la probabilité d’occurrence acceptable est faible. Par exemple, en aéronautique, un événement catastrophique (décès multiples) devra avoir une probabilité d’occurrence inférieure à 10^Λ-9 par heure de vol, alors qu’un incident majeur (réduction des marges de sécurité et des capacités opérationnelles, inconfort ou blessures légères) devra avoir une probabilité d’occurrence inférieure à 10^Λ-5 par heure de vol. Pour assurer ces objectifs, l’architecture du système avionique (fiabilisé) ainsi que la conception de chaque composant garantissent cette probabilité d’occurrence par des garanties de taux de panne de chaque équipement (pannes physiques) et des niveaux de vérification (couverture fonctionnelle et structurelle de test) des logiciels.

Ces exigences imposent un effort important de conception et de vérification, et imposent une limitation dans la complexité des traitements mis en œuvre.

A l’inverse, la défaillance d’un système non-fiabilisé, ou à la fiabilité non garantie (système non-avionique) a des conséquences jugées tolérables, non critiques, ou même sans impact opérationnel significatif. Les exigences sur l’architecture, les composants physiques ou les traitements logiciels sont donc moindres, et autorisent des traitements plus complexes, et un effort de développement et de vérification réduits par rapport à un système fiabilisé.

Afin d’utiliser lors des opérations en vol des données issues d’un calculateur non fiabilisé, du fait que la fiabilité des données n’est pas garantie (ou garanti avec un taux d’erreur inférieur aux exigences du système fiabilisé), il est avantageux d’utiliser le procédé selon l’invention. Les étapes du procédé permettent notamment de s’assurer qu’aucune donnée erronée ne soit utilisée opérationnellement par le système fiabilisé. Les étapes peuvent comprendre la vérification par l’opérateur humain, suite à une saisie manuelle ou une transmission automatique, ou encore divers moyens de vérification des données transmises. Dans certains modes de réalisation, il est également possible d’avoir des étapes de calcul ou de vérification de la cohérence des données du système non-avionique faite par le monde système avionique (par exemple, il peut être vérifié qu’une trajectoire est construite avec des points connus et qu’elle est volable)

La défaillance d’un système peut être appréhendée de manière déterministe mais également de manière probabiliste.

Dans un mode de réalisation, un critère additionnel d’exhaustivité permet de nuancer le critère du taux de défaillance. Ce critère d’exhaustivité désigne la couverture des tests (excitations, challenges sans nécessairement de réponse connue) et/ou des vérifications (e.g. comparaison de la réponse produite avec celle qui est connue et attendue) qui ont été préalablement effectués sur le système avionique ou système non-avionique dans la détermination du taux de défaillance. Dans un mode de réalisation, l’exhaustivité des tests et/ou vérifications effectuées est supérieure dans un système avionique en comparaison d’un système non-avionique.

Dans un mode de réalisation, additionnellement au taux de défaillance global du système avionique ou système non-avionique, les taux de défaillance propres aux composants du système avionique ou système non-avionique peuvent être pris en compte, ainsi que la propagation des défaillances.

Les équipements avioniques (ci-après «l’avionique») 121 comprennent par exemple un ou plusieurs calculateurs de bord (moyens de calcul, de mémorisation et de stockage de données), dont un système de gestion de vol (« Flight Management System », acronyme FMS), des moyens d’interface homme-machine, comme des moyens d'affichage (e.g. des écrans incorporés aux équipements avioniques) et/ou de saisie de données (e.g. claviers, boutons, curseurs, rotacteurs, etc), des moyens de communication ou de retours haptiques. Par extension, les systèmes avioniques peuvent comprendre des systèmes accessibles à distance, par exemple de contrôle de traffic aérien et/ou de centre opérationnel, qui peuvent être en communication (bilatérale) via les liaisons sol-bord. Par ailleurs, les systèmes de contrôle de traffic aérien 1001 et/ou de centre opérationnel peuvent accéder (e.g. recevoir, collecter, sélectionner, croiser, déterminer) à des sources de données de type ouvert (e.g. données météorologique de type non-règlementaire), par exemple accessible depuis le réseau Internet et dont la couverture et la profondeur couvre la totalité du vol de l’aéronef./

Des systèmes non-avioniques 122 désignent des dispositifs embarqués ou au sol qui peuvent par exemple comprendre une ou plusieurs tablettes informatiques ou EFB (« Electronic Flight Bag » pour Cartable électronique), de manière portative ou intégrée dans le cockpit, des moyens de visualisation (e.g. des écrans additionnels, des lunettes connectées, des visées tête haute, des projecteurs, des systèmes holographiques, des casques de réalité virtuelle et/ou augmentée dits « wearable computers » ou « head-mounted displays », etc), ainsi que des moyens d’interaction (e.g. des claviers à projection laser, dépliables, déroulables; des systèmes haptiques, à retour de force, mécaniques, pneumatiques, électriques ; des moyens de dictée ou de reconnaissance vocale avec suppression de bruit etc).

Un EFB ou de manière générale un équipement de type non-avionique peut interagir (communication unidirectionnelle ou bilatérale 123) avec les équipements avioniques 121.

Les systèmes avioniques et/ou non-avioniques sont en communication avec un aéronef 110 (e.g. son cockpit, tableau de bord etc).

Un ou plusieurs systèmes non-avioniques peuvent également être en communication 124 avec des ressources informatiques externes, accessible par le réseau (par exemple informatique en nuage ou Cloud computing 125. En particulier, les calculs peuvent s'effectuer localement sur l'EFB ou de manière partielle ou totale dans les moyens de calculs accessibles via ou par ou dans le réseau.

Les équipements de bord 121 sont généralement certifiés et régulés tandis que l'EFB 122 et les moyens informatiques connectés 125 ne le sont généralement pas (ou dans une moindre mesure). Selon les modes de réalisation (types d’intégration 123), les architectures pouvant être implémentées permettent d'injecter de la flexibilité et des capacités fonctionnelles du côté du monde ouvert (e.g. via l'EFB 122) en s'assurant d'une sécurité (contrôlée) du côté de l’avionique embarquée 121.

La figure 2 montre des exemples de systèmes de type avionique 121, des exemples de systèmes de type non-avionique 122 ainsi que des exemples d’intégration entre ces deux types de système.

Les systèmes avioniques 121 peuvent notamment comprendre un dispositif de liaison numérique sol-bord 1211, des interfaces homme-machine IHM ou interfaces homme-système IHS 1212, un ou plusieurs systèmes de gestion du vol de l’aéronef 1213, un ou plusieurs systèmes de gestion de mission 1214.

Selon les modes de réalisation de l’invention, des systèmes de type nonavionique 122 peuvent comprendre un ou plusieurs des systèmes suivants : un système d’évaluation du plan de vol alternatif 231, des équipements d’interface homme-machine pour la visualisation du plan de vol 232 et une librairie de calcul de gestion de vol, par exemple implémentée dans un ou plusieurs calculateurs de type ouvert 233.

Les systèmes avioniques et non-avioniques interagissent par l’entremise d’un organe de régulation 220.

Les principes de la régulation des échanges entre les systèmes avioniques 121 et systèmes de type non-avionique 122 peuvent être divers. Les différentes modalités peuvent prendre en compte (i.e. moduler directement ou indirectement) un ou plusieurs des paramètres suivants : a) la directionalité des échanges (unidirectionnelle et/ou bidirectionnelle, statique et invariante au cours du temps, ou évolutive, par exemple suivant le contexte de vol ou des règles prédéfinies ; b) la forme des données échangées (e.g. format de données, type de protocoles, traduction/pontage, etc). Des algorithmes de compression ou de transcodage peuvent être utilisés, c) le fond, i.e. la nature ou la qualité des objets communiqués ; ces objets peuvent être filtrés, censurés, adaptés en fonction des besoins de l’avionique, etc. d) la quantité (ou le volume) des données échangées. L’avionique ne devant généralement pas être sur-sollicitée (gestion des ressources et propagation d’erreurs), un suivi des volumes et un ajustement de ce dernier est avantageux, e) des privilèges ou des priorités associés aux données et/ou aux systèmes matériels. L’allocation des rôles, privilèges ou priorités pourra être prédéfinie ou dynamique. Les architectures ou modèles peuvent être variés: systèmes maitres/esclaves, évolutifs ou non, réseaux de pairs-à-pairs, etc.

A titre d'exemple d’une combinaison particulièrement avantageuse dans le métier de l’avionique, un système dual hiérarchisé est décrit ci-après. Le système dual selon ce mode de réalisation comprend (au moins) un système avionique maître et (au moins) un système non-avionique esclave. Plusieurs modalités d’interaction (e.g. mécanismes de synchronisation) sont possibles, entre ces deux systèmes, en particulier entre les données déterminées par le système de gestion de vol 1213 du côté avionique et la librairie de calcul 233 du côté non-avionique.

Dans un mode de réalisation, il y a échange partiel de données et recalcul de part et d’autre (1213, 233) pour reproduire une situation fonctionnellement équivalente. Dans un mode de réalisation, le système maître a des données particulières (exemple position réelle de l’avion) qui permettent d’imposer le résultat. La vérification de l’intégrité ou de la viabilité des données produites est possible grâce à une aide, par exemple visuelle via 232, montrant les différences entre les deux calculs. Dans un mode de réalisation cette vérification est effectuée par l’humain (via une interface IHM). Dans un mode de réalisation cette vérification est effectuée par la machine (via un système de règles logiques manipulant des faits quantifiés. Dans un mode de réalisation, la vérification est conjointe homme-machine (e.g. pondérée ou pas, dernier mot pour le pilote ou non, etc).

Dans un mode de réalisation, il y a échange complet des données et des états de l’avion. Les données de la partie esclave ou asservie (e.g. 233) sont remplacées en intégralité par les données par la partie maître (e.g. 1213). Le système avionique impose ses états et ses données.

Dans un mode de réalisation interviennent des échanges complémentaires de données avec chaque partie (qui peut endosser un rôle de maître pour certains types de données ou d’objets manipulés), les autres données restantes étant recalculées localement par chaque partie. Dans un mode de réalisation, chaque partie peut en effet être spécialisée i.e. endosser le rôle de maître pour certaines données et le rôle asservi pour d’autres données. Certaines données peuvent être fournies par une partie ou par l’autre (par exemple, des données saisies depuis les interfaces homme-machine).

Dans un mode de réalisation, l’intégration avionique / non-avionique peut être effectuée de manière discrète, cad déterminée selon des intervalles de temps prédéfinis. Dans un mode de réalisation, chaque système peut recevoir les mêmes données en entrée, recalculer tous les états, des points de synchronisation temporels prédéfinis (e.g. périodiques ou intermittents) et/ou effectués à la demande et/ou en fonction de l’occurrence d’un événement prédéfini peuvent conduire à vérifier que les états de sortie de chaque système restent dans une fourchette donnée (i.e. que les systèmes ne divergent pas). SI les systèmes divergent, le système maître peut imposer son état pour resynchroniser le système esclave.

Dans un mode de réalisation, l’intégration peut être effectuée continuellement ou de manière quasi-continue, e.g. les résultats de calculs intermédiaires sont comparés (et non plus les résultats finaux, comme dans les modes de réalisation décrits ci-avant). Avantageusement, une éventuelle divergence des systèmes sera détectée plus tôt que dans le cas d’une intégration ponctuelle.

A titre d’exemple, une autre combinaison est particulièrement avantageuse dans le métier de l’avionique : la communication entre système avionique et système non-avionique peut être bidirectionnelle mais asymétrique (plus de données évadées du système avionique que de données qui y sont réinjectées), sans contrôle sur la sortie du système avionique mais avec un double contrôle sur les réinjections de données, en matière de i) nature des données réinjectées (e.g. seuls certains objets avioniques sont autorisés) et de ii) volume de données (e.g. afin de préserver le cœur FMS de sur-sollicitations). Des mécanismes de filtrage par types d’objets peuvent être mis en œuvre. Au-delà de tests sur les formats, des tests logiques sur les données peuvent être effectués. Le volume des données manipulé par le cœur avionique peut être asservi à une mesure de la charge et/ou de la capacité de traitement du cœur avionique (feedback control).

L’organe de régulation 220 des échanges peut comprendre un ou plusieurs des composants suivant : un espace de stockage passif (mémoire tampon, « buffer ») et/ou un espace de stockage actif (e.g. ordonner la file d’attente, en fonction de priorités, selon le contexte de vol et/ou l’utilisation des ressources avioniques) et/ou des entités logiques (e.g. pour tester les données passant d’un monde à l’autre).

L’organe de sécurité peut être complémenté ou augmenté de différents mécanismes, comprenant un ou plusieurs des mécanismes comprenant le chiffrement des données (par exemple à clefs asymétriques), des mécanismes d'authentification (par exemple biométrique), des mécanismes d’autosurveillance (e.g. machine à états, « watchdog »), des mécanismes anti-intrusion (e.g. IDS), des mécanismes de vérification continue de l’intégrité des données manipulées dans le serveur passerelle, le partage d’un secret préalable, etc.

Dans un mode de réalisation, l’organe de régulation entre systèmes avioniques et systèmes non-avioniques peut être agréé (ou reconnu ou accepté ou autorisé) par les systèmes non-avioniques d’une part et les systèmes avioniques d’autre part, de manière intermittente, régulière ou à la demande. Dans un mode de réalisation, un ou plusieurs mécanismes de vote peuvent permettre de répudier ou rejeter sur demande le serveur passerelle qui serait considéré comme corrompu (par exemple si au moins un des systèmes avioniques le détermine comme tel; d’autres modèles peuvent prévoir des votes à la majorité, etc).

Dans un mode de réalisation, le système d’évaluation du plan de vol alternatif 231 vise à comparer et évaluer ladite route alternative. Dans un mode de réalisation, le système d’évaluation du plan de vol alternatif 231 vise à identifier les gains opérationnels. Dans un mode de réalisation, le système d’évaluation du plan de vol alternatif 231 vise à vérifier la conformité de la route chargée dans l’avionique.

Le système d’évaluation du plan de vol alternatif 231 et/ou les interfaces 232 et/ou ia librairie de calcul de gestion du vol 233 et l’organe de régulation 220 peuvent interagir de différentes manières.

La granularité ou le périmètre des comparaisons est variable ou configurable (seuls les résultats finaux peuvent être comparés et/ou les résultats intermédiaires, les conditions aux limites peuvent aussi être comparées, etc). Les modalités de comparaison peuvent être diverses (e.g. comparaison à l’identique ou modulo des tolérances, suivant des modèles prédéfinis).

Dans un mode de réalisation, le code avionique du FMS est exécuté dans la librairie de calcul de gestion du vol 233, exactement de la même manière qu’il le serait dans le système avionique natif. Les résultats obtenus sont alors envoyés et analysés par le système d’évaluation du plan de vol alternatif 231 qui, si nécessaire, communique au pilote via l’interface 232 les différences entre les éléments calculés de manière avionique d’une part et de manière non-avionique d’autre part (de manière optionnelle, des seuils ou des plages de seuils peuvent être appliqués, si des modèles non représentés permettent la gestion de risques systémiques, e.g. une différence de valeur de 1% pour certains types de valeur peut engendrer des conséquences catastrophiques tandis que d’autres types de paramètres peuvent être moins sensibles ; par ailleurs les combinaisons de telles valeurs différentielles peuvent également être considérées).

Après autorisation par exemple expresse de la part du pilote, éventuellement sécurisée par la saisie d’un code ou d’une authentification (par exemple biométrique), les données autorisées sont transmises vers les systèmes avioniques 121 via l’organe de régulation 220.

Dans un mode de réalisation, l’interface IHM/IHS 232 peut comprendre un ou plusieurs des écrans d’affichage et/ou systèmes d’interactions 232 liés à ce calculateur permettant à l’opérateur de visualiser les résultats déterminés par les systèmes non avioniques, et d’ajuster manuellement la solution ou des caractéristiques particulières de cette solution ; par exemple le pilote pourra visualiser sur l’écran de la tablette le résultat des calculs (mais dans des modes de réalisation, ces informations pourront être projetées ou affichées en surimpression, par réalité augmentée, etc).

Les dispositifs d’affichage peuvent comprendre ou mettre en oeuvre un ou plusieurs dispositifs tels que des casques de réalité virtuelle et/ou des lunettes de réalité augmentée (e.g. head-mounted display, wearable computer, des glasses ou un visiocasque) et/ou des dispositifs de projection (e.g.

holographique). Un casque de réalité virtuelle porté par le pilote peut être opaque ou semi transparent ou à transparence configurable). L’affichage peut être à « visée haute ». Le casque peut comprendre un ou plusieurs dispositifs de calcul et de communication, de projection, d’acquisition audio, de projection et/ou d'acquisition vidéo (par exemple pour la capture ou le scraping de données accessibles de manière analogique depuis le cockpit ou la cabine de pilotage de l'aéronef). Le cockpit de l’aéronef peut également comprendre des dispositifs de commande vocale. L’instrumentation embarquée peut avantageusement permettre au pilote de visualiser son plan de plan de vol ou sa trajectoire en 3D, notamment les différentes routes alternatives selon l’invention. Le pilote pourra par exemple visualiser - par exemple en surimpression de son environnement réel ces routes alternatives, les rejointes de trajectoire quand ces dernières sont encore possibles (passer d’une route à une autre). Enfin des dispositifs de retour haptique incorporés dans le système pour la mise en œuvre de l’invention pourront enrichir le choix des routes, le guidage/pilotage (vibrations spécifiques lors du franchissement effectif d’un point de passage, etc).

Concernant l’affichage, les informations peuvent être affichées dans un ou plusieurs casque(s) de réalité virtuelle et/ou augmentée. Les informations peuvent donc être entièrement virtuelles (affichées dans un casque individuel), entièrement réelles (par exemple projetées sur les surfaces planes disponibles dans l'environnement réel du cockpit de l’aéronef) ou une combinaison des deux (en partie un affichage virtuel superposé ou fusionné avec la réalité et en partie un affichage réel via des projecteurs). L'affichage peut également se caractériser par l'application de règles d'emplacements et de règles d'affichage prédéfinies. Par exemple, les interfaces homme-machine (ou les informations) peuvent être distribuées (segmentées en portions distinctes, éventuellement partiellement redondantes, puis réparties) entre les différents écrans virtuel ou réels.

Dans un mode de réalisation, la librairie de calcul de gestion du vol 233 accède (de manière active) et/ou reçoit (de manière passive) des informations de sources extérieures 1251, lesquelles sont fournies par un ou plusieurs réseaux de données externes 1252, ces réseaux externes étant également en interaction avec un ou plusieurs centres opérationnels.

En ce qui concerne les données recueillies sur les réseaux ouverts à l’extérieur (1251, 1252), ces dernières peuvent être volumineuses (quantité, e.g. nombre, diversité), complexes (qualité, e.g. fiabilité, obsolescence variable, formats variables), multidimensionnelles (en temps et en espace, i.e. intégrant le présent et également le futur, en comprenant par exemple des prédictions d’évolution au cours du temps, éventuellement accompagnées de degrés de fiabilité, ou encore des variantes associées à des critères de probabilité ou de statistique).

Ces données peuvent concerner des données météorologiques, telles que le vent et la température échantillonnés selon l’altitude, la position géographique, et sur différentes heures prédites ; et/ou l’état du trafic aérien, soit en termes de trajectoires planifiée des différents aéronefs sur les secteurs rencontrés, soit des densités de trafic par secteurs, avec des prévisions au cours de temps, ou des variantes statistiques de l’évolution du trafic ; et/ou des zones géométriques (polyèdres, ou polygones par tranches d’altitude) définissant des zones de danger, d’évitement, ou des phénomènes influant sur le vol, et leur évolution temporelle : nuages de cendres volcaniques, zones de turbulence atmosphérique, de convection (orages), de givrage, ou encore zones d’exclusion militaire ou de risque tactique ; et/ou des informations discrétisées sous formes de cartes numériques : images de radar météo, relief numérisé ; et/ou des obstacles ponctuels, fixes ou mobiles : aéronefs, aérostats, menaces tactiques, etc.

Toutes ces données peuvent influer sur la mission, et peuvent potentiellement être prises en compte dans l’élaboration d’une route alternative.

Leur étendue spatiale et leur évolution temporelle peuvent également être prises en compte dans un calcul de route automatique. En outre, les données brutes et/ou traitées peuvent être affichées au pilote pour évaluation de l’impact sur la route actuelle (ou sur la route alternative en cours d’élaboration).

En complément de ces informations, des données spécifiques aéronautiques peuvent être prises en compte, par exemple des bases de données de navigation aérienne, intégrant les aéroports, procédures d’arrivée et de départ, radiobalises, point de navigation, routes aériennes, sur les zones géographiques concernant la mission, ou sur l’ensemble du globe ; ou encore la sectorisation de l’espace aérien, avec les zones de contrôle aérien, les rails de navigation aérienne océanique, et les frontières étatiques.

Les informations énumérées ci-avant peuvent être prises en compte pour déterminer une route optimisée, qui s’intégre au mieux dans l’espace aérien contrôlé et/ou qui exploite de manière optimale les zones de navigation libre (dites « free routing »).

Dans certains modes de réalisation, les (i) interfaces de communication externes à l’avionique (1251, 1252), et/ou les (ii) moyens de calcul externes à l’avionique 233 et/ou les (iii) systèmes IHM d’interaction homme-système 232 externes à l’avionique peuvent être utilisées autant que possible (mode de délégation maximal). L’emploi de ces modalités peut donc être optimisé (et donc maximisé en particulier).

La librairie de calcul de gestion de vol 233 désigne du code logiciel exécuté sur du matériel. Ce bloc logique, selon les modes de réalisation, peut effectuer des calculs de prédiction de trajectoire identiques, ou fonctionnellement équivalents, à ceux effectués dans le système avionique. Les calculs menés reproduisent autant que possible les traitements tels qu’ils seront appliqués par le système avionique (le code logiciel est structurellement identique, éventuellement recompilé, ou il est fonctionnellement équivalent). Le bloc 233 peut aussi implémenter diverses étapes d’optimisation (e.g. heuristiques, algorithmes Astar, algorithmes génétiques, algorithmes à base de champs de potentiels, etc). Le bloc 233 peut aussi traduire ou transcrire les données sortantes dans un format fonctionnellement équivalent à celui manipulé par le système avionique1213.

Dans un mode de réalisation, le FMS avionique 121 présente des interfaces prévues pour la communication vers des systèmes tiers (FMS dit « Open Capacity»), Le cas échéant, le calcul de la gestion du vol 1213 peut être mis à disposition par le système de gestion de vol FMS NG et sa capacité « Open Capacity ». Dans un mode de réalisation, la fonction d’évaluation des alternatives 231 pourra moduler les intervalles de temps et le nombre d’alternatives à évaluer en fonction des ressources de l’avionique allouées au système d’optimisation 233 (monde ouvert).

La figure 3 illustre un exemple de contrôle de l’affichage d’un plan de vol selon un mode de réalisation de l’invention.

La figure 3 montre un écran d’affichage 410 (par exemple sur un EFB mais tout autre dispositif d’affichage non-avionique peut être considéré) et une zone d’interaction 420.

En déplaçant un curseur symbolique, le pilote peut fictivement manipuler la flèche du temps. Il peut accélérer vers le futur (« fast-forward ») 421 ou retourner dans le passé (« rewind ») 422, par exemple de manière à afficher les différentes valeurs des paramètres de vol. Le pilote peut aller loin dans le futur, de manière à améliorer la « profondeur » de pilotage. La possibilité d’aller en avant 421 et en arrière 422 permet aussi d’osciller autour d’un point d’intérêt (comparaisons avant/après).

Dans un mode de réalisation, l’interface homme-machine 232 peut être spécifique, et le pilote peut actionner un curseur de temps pour visualiser, le long de la trajectoire de référence (dans l’exemple LHR - ORY - NCE) ou d’une trajectoire alternative (LHR - CDG - NCE), figurée en pointillée, à tout instant, la position et certains paramètres futurs de l’avion ou autour de l’avion (conditions météorologiques et conditions de trafic qui changent au cours du temps). Par exemple, le pilote peut connaître les paramètres du vol au point de plan de vol 412 et les comparer à ceux au point 411.

Avantageusement la manipulation graphique du temps permet au pilote d’explorer les données de vol (existantes, prédites, possibles, etc), telles que déterminées par des ressources de type non-avioniques et validées dans les systèmes avioniques, et lui permet in fine d’améliorer la prise de décision.

Matériellement, différents moyens ou actionneurs tangibles peuvent être utilisés (e.g. rotacteurs, trackpad, curseurs, etc). Des gestes peuvent être utilisés (e.g. doigts sur écran tactile, déplacement de la main suivi par des capteurs de capture du mouvement, reconnaissance de gestes par analyse d’images etc).

Sur le fond, peuvent être affichés des paramètres intrinsèques à l’aéronef (e.g. position 3D dans l’espace, quantité de carburant à la fin du vol prévu, vitesse de l’aéronef en tout point) et/ou des paramètres extrinsèques à l’aéronef (i.e. environnement autour de l’avion, e.g. conditions météorologiques autour de l’avion, état du trafic autour de l’avion).

Dans un mode de réalisation, le système d’aide à la décision peut faire intervenir des étapes de rendu visuel (mais pas nécessairement). Dans un mode de réalisation (essentiellement non-visuel), des scores ou notations synthétiques peuvent agréger les résultats associés aux différentes routes possibles (ou à certains points de l’espace et/ou instants temporels associés à ces routes) et réduire ou simplifier l’exploration des possibles. Le rendu peut par exemple être vibratile (une certaine direction d’espace trop fortement contrainte peut déclencher un retour haptique conventionnellement défini comme négatif)

Dans un mode de réalisation, des événements spécifiques (par exemple des conflits avec des évènements météorologiques sévères) sont déterminés (détectés en fonction de critères prédéfinis). Ces événements détectés peuvent éventuellement être affichés à destination du pilote, ce qui permet à ce dernier d’anticiper puis décider l’action adéquate pour gérer/éviter ces évènements.

Dans un mode de réalisation, le procédé selon l'invention peut être en boucle ouverte (détermination calcul par la machine et validation humaine). Pour chaque plan de vol, le système recherche de façon continue et en tache de fond s’il existe des évènements à signaler au pilote. Si le système détecte un ou plusieurs évènements, il alerte le pilote et lui signale quel est le plan de vol concerné par l’évènement. Ce signalement peut se faire de diverses façons comme une coloration ou un clignotement du plan de vol ou un une fenêtre popup qui indique quel(s) type(s) d’évènement est (sont) à gérer. Le pilote peut décider d’utiliser le mode manuel afin de mieux visualiser l’occurrence de l’évènement et décider s’il y a lieu de l’éviter et comment.

Dans un mode de réalisation, le procédé selon l’invention peut être en boucle fermée (i.e. automatisé). Le système calcule la meilleure alternative en chaque point selon des critères prédéfinis avec un classement prioritaire sur ces critères. Ces exemples de critères sont détaillés ci-après. Dans un mode de réalisation, le procédé comprend une étape consistant à classer (e.g. visuellement) les plans de vol (par exemple du meilleur au pire par rapport aux critères euxmêmes classés). Le pilote peut décider de visualiser l’occurrence de l’évènement sur un ou plusieurs plans de vol.

Dans un mode de réalisation, la bascule de la boucle ouverte à la boucle fermée (ou inversement) peut être déclenchée par le pilote. Dans ce mode de réalisation, le pilote peut donc décider de faire confiance au système, lequel peut alors sélectionner le meilleur plan de vol tel que remonté par le système.

Dans un mode de réalisation, en boucle semi-ouverte ou mode-semi-manuel, conjointement ou isolément, les systèmes avioniques et non-avioniques en interaction peuvent chercher et/ou optimiser des routes alternatives ou tout type d’objet/paramètre avionique (en tâche de fond, i.e. de manière continue, au moins adaptative, cad en actualisant sans cesse les alternatives aux conditions évolutives de l’avion et/ou de son environnement). Parmi les routes alternatives candidates, un mécanisme de sélection produit une route candidate laquelle est soumise pour appréciation au pilote. A défaut d’une route alternative, la sélection peut aussi s’effectuer sur des événements à signaler au pilote. Si un système détecte un ou plusieurs évènements, il alerte le pilote et lui signale quel est le plan de vol concerné par ledit évènement. Le pilote peut définir les évènements qu’il veut détecter (et/ou filtrer pour éviter les alertes qu’il considère de moindre gravité). Les alertes ou signalements peuvent être effectuées de multiples manières, y compris multimodales (visuel, sonore, vibratile, etc). Par exemple, la représentation d’informations comprendre le fait de colorer ou de faire clignoter un plan de vol concerné par un événement dangereux ou indésirable (ou susceptible de le devenir). Différents moyens de signalisation peuvent être utilisés pour attirer l’attention du pilote (messages prompts à l’écran, témoins lumineux, etc). Des éléments graphiques cliquables, comprenant par exemple des liens peuvent ensuite permettre au pilote d’accéder à des détails complémentaires, de manière à l’assister in fine dans sa prise de décision.

Dans un mode de réalisation, boucle fermée ou mode automatique, le modèle de décision du pilote est internalisé, i.e. traduit en règles logiques manipulant des faits. Les systèmes avioniques et non-avioniques proposent au pilote ce qu’ils considèrent comme la meilleure alternative, selon des critères prédéfinis, ces critères étant par exemple ordonnés par priorité. Les critères pris en compte peuvent comprendre un ou plusieurs des critères comprenant l’évitement de conflits avec les autres avions, l’évitement des perturbations météorologiques, la minimisation de la consommation de carburant, la ponctualité (respect d’un Estimate Time at Arrivai ou ETA), la minimisation du temps de vol total, ou encore le respect de contraintes ATC (comme le suivi de route ATC).

Dans un mode de réalisation, un critère peut être « absolu » ou « impératif », c’est à dire que le critère doit être satisfait pour qu’un ou plusieurs alternatives puissent être proposées. A contrario, un critère peut être « relatif », c’est-à-dire que c’est la meilleure alternative par rapport à toutes celle ayant été évaluées qui sera proposée, même si le critère n’est pas maximal (mais optimal).

Concernant la synchronisation depuis l’avionique, le signalement des meilleures alternatives peut se faire de diverses manières, à l’instar des modalités décrites précédemment (e.g. couleurs, clignotements, etc).

Dans un mode de réalisation, le pilote peut conserver la possibilité de basculer du mode automatique au mode manuel, par exemple pour visualiser le déroulement de ce plan de vol (seul ou avec le déroulement d’autres alternatives).

La figure 4 montre des exemples d’étapes d’un mode de réalisation du procédé selon l’invention.

Il est décrit un procédé pour la gestion d’une route d’un aéronef mis en oeuvre dans un système comprenant un ou plusieurs systèmes de type avionique et un ou plusieurs systèmes de type non-avionique, comprenant les étapes: déterminer une route alternative à la route courante suivie par l’aéronef dans un système de type non-avionique 410; - vérifier la route alternative déterminée dans un système de type non-avionique et/ou dans un système de type avionique.

Un système avionique est associé avec un taux de panne physique inférieur et une vérification logique supérieure à ceux d’un système de type non-avionique.

Une route alternative (latérale et/ou verticale) est déterminée dans ou par un système (avionique ou non-avionique). L’étape de vérification peut être implémentée de diverses manières, dans l’avionique et/ou le monde ouvert (i.e. exclusivement dans l’avionique ; ou exclusivement dans le monde ouvert ; ou en partie dans l’avionique et en partie dans le monde ouvert, avec ou sans recoupements).

Dans un mode de réalisation, l’étape consistant à vérifier la route alternative comprend les étapes consistant à : afficher la route alternative sur un écran d’affichage 441 d’un système non-avionique recevoir depuis le système nonavionique une commande d’avance 440 vers le passé ou vers l’avenir déterminant un point dans le temps et dans l’espace et - afficher des paramètres de vol associés audit point.

Dans un mode de réalisation, l’étape de vérification fait intervenir une boucle de rétroaction, faisant appel au pilote, et est optionnellement réalisée de manière graphique ou visuelle 441.

Les paramètres de vol peuvent être ceux déterminés par le système nonavionique mais aussi par le système avionique. Les paramètres comprennent par exemple des informations 5D (position espace, temps, fuel) et des informations sur l’environnement (météo, trafic environnent, etc), fluctuant au cours du temps.

Le déroulement du temps 440 est possible dans les deux sens.

Dans un mode de réalisation, l’étape consistant à vérifier 410 la route alternative comprend l’application de règles logiques prédéfinies 442.

Ce mode de réalisation ne fait pas intervenir d’interface homme-machine 441.

Dans un mode de réalisation, l’étape consistant à déterminer une route alternative comprend l’étape consistant à sélectionner depuis une interface homme-machine d’un système non-avionique une route alternative.

L’origine de la route alternative peut provenir du pilote ou d’un système tiers dédié. Dans un mode manuel, le pilote fait évoluer le temps 440 manuellement et évalue lui-même les critères. Il choisit lui-même une route. Dans un mode semi-automatique, le pilote fait évoluer le temps manuellement et la machine évalue les différentes alternatives, éventuellement en présélectionne certaines. Le pilote procède à l’exploration des données, ce qui permet de garder une complexité maîtrisée du système. Dans un mode automatique, les manipulations du temps et l’évaluation des alternatives correspondantes sont évaluées par la machine. De grandes capacités de calcul peuvent permettre l’exploration systématique et combinatoire des possibles.

Dans un mode de réalisation, différentes alternatives peuvent être vérifiées en parallèle ou concomitamment, ceci étant permis par l’accès à des ressources de calcul élastiques dans le monde non-avionique.

Dans un mode de réalisation, les routes alternatives peuvent être déterminées dans un système non-avionique, puis le déroulement du temps est activé et mis à disposition du pilote qui peut explorer l’espace des possibles de manière efficace. Le déplacement d’un curseur temps par exemple peut permettre de simuler le déplacement de l’avion, le calcul des caractéristiques du vol et l’évolution de l’environnement de l’avion à l’instant simulé. En retour les différentes routes considérées par le pilote, sélectionnées dans l’espace des possibles, peuvent être continûment évaluées.

Dans un mode de réalisation, le procédé comprend en outre l’étape consistant à insérer 420 et/ou activer 430 la route alternative vérifiée dans le système avionique de gestion de vol.

Le terme insérer se réfère à une révision de plan de vol. Le terme activer signifie que la route va effectivement être volée.

Dans un mode de réalisation, le procédé comprend en outre l’étape consistant à évaluer la route alternative vérifiée et insérée et/ou activée dans le système avionique.

Une fois ingérée par le système avionique, il est possible d’évaluer ou noter de manière certaine la route alternative.

Dans un mode de réalisation, la comparaison est « absolue » et indirecte: la route alternative candidate est évaluée selon des critères prédéfinis qui euxmêmes traduisent les exigences avioniques. Il est sous-entendu que cette étape est effectuée avant l’insertion ou l’activation de ladite route (qui ne peut avoir lieu que si l’évaluation est positive, i.e. excède un seuil prédéfini).

Dans un mode de réalisation, le procédé comprend une étape consistant à évaluer ou vérifier la conformité de la route alternative déterminée avec des critères prédéfinis. L’évaluation peut consister à noter ou attribuer un score à la route candidate.

Cette étape d’évaluation ou de vérification de conformité peut s’effectuer à tout moment (création de la route, soumission via ΙΊΗΜ, y compris après validation par le pilote le cas échéant). Les critères peuvent correspondre à des bornes, limites ou enveloppes, tels que donnés par le système de gestion de vol FMS.

Dans un mode de réalisation, l’évaluation peut être déterministe. Dans un mode de réalisation, l’évaluation peut être probabiliste. Les critères peuvent prendre en compte les risques systémiques d’injection de données.

Les fonctions d’évaluation et de vérification invoquées peuvent être « qualifiées », i.e. vérifier la conformité des calculs avec des seuils de précision cohérents de la précision de navigation requise pour la mission (RNP), et/ou être couplée aux moyens d’affichage interactifs pour permettre une comparaison visuelle des résultats.

Dans un mode de réalisation, le procédé comprend en outre une étape consistant à détecter un paramètre de vol ou événement en fonction de critères prédéfinis et à afficher à l’écran une alerte quant à ce paramètre ou événement.

Le pilote peut personnaliser ses critères d’alerte, afin d’améliorer la prise de décision.

Dans un mode de réalisation, l’étape consistant à déterminer une route alternative dans le système de type non-avionique comprend l’exécution, dans le système non-avionique, d’un code logiciel identique à celui-mis en oeuvre dans le système avionique de gestion de vol.

Dans un mode de réalisation, l’étape consistant à déterminer une route alternative dans le système de type non-avionique comprend l’exécution, dans le système non-avionique, d’un code logiciel fonctionnellement équivalent à celuimis en oeuvre dans le système avionique de gestion de vol.

L’étape consistant à déterminer une route alternative dans le système de type non-avionique peut être effectuée de différentes manières (exécution d’un code logiciel strictement identique à celui exécuté par le FMS, code fonctionnel équivalent, pseudo-code, etc). L’étape d’insertion de ladite route alternative dans le système avionique de gestion de vol peut être effectuée de différentes manières (boucle de validation pilote et/ou machine). Une variante à la mission peut être soumise au pilote pour appréciation (e.g. correction, annotation, validation, modulation). Des systèmes de décision peuvent évaluer (noter, simuler, quantifier, émuler, etc) la criticité de la route alternative, avant réinjection éventuelle. Une fois validée par l’homme et/ou la machine, la route d’origine non-avionique est injectée dans les systèmes de type non-avionique.

Dans un mode de réalisation, le procédé comprend en outre l’étape consistant à modifier la route alternative déterminée.

L’étape de modification de la route peut être itérative (e.g. faire l’objet d’étapes d’optimisation). Elle peut être le fait d’une diversité d’acteurs (e.g. pilote, ATC) et/ou machines. Elle peut être effectuée avant insertion ou activation dans l’avionique. Elle peut résulter d’un ensemble de paramètres prédéfinis et/ou calculés dynamiquement. Des moyens IHM peuvent être utilisés, ou non (modifications déclenchées par des traitements automatiques, sans boucle graphique).

L’opération de modification peut notamment comprendre des opérations visant à présélectionner, filtrer, modifier en partie, valider ou au contraire censurer la route déterminée.

Dans un mode de réalisation, l’interface homme-machine comprend au moins un curseur configuré pour déclencher ou commander l’affichage d’un ou de plusieurs paramètres de vol associés à la route alternative déterminée au cours du temps en fonction du déplacement dudit curseur.

Dans un mode de réalisation, le pilote peut visualiser l’évolution de la situation au cours du temps le long de la route, en agissant sur un paramètre de temps (par exemple en faisant glisser un repère le long d’une échelle de temps de type « slider »), pour visualiser l’état des données contextuelles prédites (traffic, météo, zones de danger ou de perturbation), ainsi que la position prédite de l’aéronef sur chacune des trajectoires.

Dans un mode de réalisation, une ou plusieurs étapes sont déclenchées en fonction du contexte de vol 499.

Dans certains modes de réalisation, une ou plusieurs des étapes du procédé (e.g. type de visualisation, nombre de routes alternatives calculées dans le monde ouvert, précision des calculs, types et nombre de ressources sollicitées, déclenchement d’une mode en boucle ouverte à une boucle fermée, etc) peuvent être asservies au contexte de vol de l'aéronef (e.g. phases de vol).

Le contexte de vol 499 à un moment donné intègre l'ensemble des actions prises par les pilotes (et notamment les consignes de pilotage effectives) et l'influence de l'environnement extérieur sur l'aéronef. Un contexte de vol comprend par exemple une situation parmi des situations prédéfinies ou précatégorisées associées à des données telle que la position, la phase de vol, les points de passage, la procédure en cours (et autres). Par exemple, l'aéronef peut être en phase d'approche pour l'atterrissage, en phase de décollage, en phase de croisière mais également en palier ascendant, palier descendant, etc (une variété de situations peut être prédéfinie). Par ailleurs, le contexte de vol courant peut être associé à une multitude d'attributs ou de paramètres descriptifs (état météorologique courant, état du trafic, statut du pilote comprenant par exemple un niveau de stress tel que mesuré par des capteurs, etc). Un contexte de vol peut donc également comprendre des données, par exemple filtrées par priorité et/ou fondées sur des données de phase de vol, des problèmes météorologiques, des paramètres avioniques, des négociations ATC, des anomalies liées au statut du vol, des problèmes liés au trafic et/ou au relief.

Des exemples de contexte de vol comprennent par exemple des contextes tels que régime croisière / pas de turbulences / stress pilote nominal ou bien encore phase atterrissage / turbulences / stress pilote intense. Ces contextes peuvent être structurés selon divers modèles (e.g. hiérarchisés par exemple en arbre ou selon des dépendances diverses, y compris des graphes). Des catégories de contextes peuvent être définies, de manière à synthétiser les besoins en matière d'interaction homme-machine (e.g. délai d'interaction minimal ou maximal, quantité de mots minimale et maximale, etc). Il peut également subsister des règles spécifiques dans certains contextes, notamment d'urgences ou de situations critiques. Les catégories de contextes peuvent être statiques ou dynamique (e.g. configurables).

Le procédé peut être implémenté dans un système comprenant des moyens pour déterminer un contexte de vol de l'aéronef, lesdits moyens de détermination comprenant en particulier des règles logiques, lesquelles manipulent des valeurs telles que mesurées par des moyens de mesure physique. En d'autres termes, les moyens de détermination du contexte de vol comprennent des moyens de système ou hardware ou physiques/tangibles et/ou des moyens logiques (e.g. des règles logiques, par exemple prédéfinies). Par exemple, les moyens physiques comprennent l'instrumentation avionique au sens propre (radars, sondes, etc) qui permettent d'établir des mesures factuelles caractérisant le vol. Les règles logiques représentent l'ensemble des traitements de l'information permettant d'interpréter (e.g. de contextualiser) les mesures factuelles. Certaines valeurs peuvent correspondre à plusieurs contextes et par corrélation et/ou calcul et/ou simulation, il est possible de départager des contextes candidats, au moyen de ces règles logiques. Une variété de technologies permet d'implémenter ces règles logiques (logique formelle, logique floue, logique intuitionniste, etc)

Il est décrit un produit programme d’ordinateur, ledit programme d’ordinateur comprenant des instructions de code permettant d’effectuer une ou plusieurs étapes du procédé, lorsque ledit programme est exécuté sur un ordinateur.

La présente invention peut s’implémenter à partir d’éléments matériel et/ou logiciel. Elle peut être disponible en tant que produit programme d’ordinateur sur un support lisible par ordinateur. Le support peut être électronique, magnétique, optique ou électromagnétique.

Dans un mode de réalisation, le procédé est mis en œuvre par ordinateur.

Dans un mode de réalisation, le système pour la mise en œuvre de l’invention comprend un support de stockage lisible par ordinateur (RAM, ROM, mémoire flash ou une autre technologie de mémoire, par exemple support à disque ou un autre support de stockage non transitoire lisible par ordinateur) codé avec un programme d'ordinateur (c'est-à-dire plusieurs instructions exécutables) qui, lorsqu'il est exécuté sur un processeur ou plusieurs processeurs, effectue les fonctions des modes de réalisation décrits précédemment. A titre d'exemple d'architecture matérielle adaptée à mettre en œuvre l'invention, un dispositif peut comporter un bus de communication auquel sont reliés une unité centrale de traitement ou microprocesseur (CPU, acronyme de « Central Processing Unit » en anglais), lequel processeur peut être multi-core ou many-core·, une mémoire morte (ROM, acronyme de « Read Only Memory » en anglais) pouvant comporter les programmes nécessaires à la mise en œuvre de l'invention; une mémoire vive ou mémoire cache (RAM, acronyme de « Random Access Memory » en anglais) comportant des registres adaptés à enregistrer des variables et paramètres créés et modifiés au cours de l'exécution des programmes précités ; et une interface de communication ou E/S (I/O acronyme de « Input/ouput » en anglais) adaptée à transmettre et à recevoir des données.

Dans le cas où l'invention est implantée sur une machine de calcul reprogrammable (par exemple un circuit FPGA), le programme correspondant (c'est-à-dire la séquence d'instructions) peut être stocké dans ou sur un médium de stockage amovible (par exemple une carte SD, ou un stockage de masse tel que un disque dur e.g. un SSD) ou non-amovible, volatile ou non-volatile, ce médium de stockage étant lisible partiellement ou totalement par un ordinateur ou un processeur. Le support lisible par ordinateur peut être transportable ou communicable ou mobile ou transmissible (i.e. par un réseau de télécommunication 2G, 3G, 4G, Wifi, BLE, fibre optique ou autre).

La référence à un programme d'ordinateur qui, lorsqu'il est exécuté, effectue l'une quelconque des fonctions décrites précédemment, ne se limite pas à un programme d'application s'exécutant sur un ordinateur hôte unique. Au contraire, les termes programme d'ordinateur et logiciel sont utilisés ici dans un sens général pour faire référence à tout type de code informatique (par exemple, un logiciel d'application, un micro logiciel, un microcode, ou toute autre forme d'instruction d'ordinateur, comme des web services ou SOA ou via des interfaces de programmation API) qui peut être utilisé pour programmer un ou plusieurs processeurs pour mettre en œuvre des aspects des techniques décrites ici. Les moyens ou ressources informatiques peuvent notamment être distribués (Cloud computing'), éventuellement avec ou selon des technologies de pair-à-pair et/ou de virtualisation. Le code logiciel peut être exécuté sur n'importe quel processeur approprié (par exemple, un microprocesseur) ou cœur de processeur ou un ensemble de processeurs, qu'ils soient prévus dans un dispositif de calcul unique ou répartis entre plusieurs dispositifs de calcul (par exemple tels qu’éventuellement accessibles dans l’environnement du dispositif). Des technologies de sécurisation (crypto-processeurs, authentification éventuellement biométrique, chiffrement, carte à puce, etc) peuvent être utilisées.

Il est décrit un système comprenant au moins un système de type avionique et un ou plusieurs systèmes de type non-avionique pour la mise en œuvre d’une ou plusieurs étapes du procédé, un système avionique étant associé avec un taux de panne physique inférieur et une vérification logique supérieure à ceux d’un système de type non-avionique.

Dans un mode de réalisation, un système de type avionique comprend un système de gestion de vol de type avionique F.M.S. et/ou un système de contrôle du traffic de la navigation aérienne. Dans un mode de réalisation, un système de type non-avionique comprend un sac de vol électronique ou E.F.B. ou une tablette numérique. Dans certains modes de réalisation, les différentes étapes de la méthode peuvent être implémentées en tout ou partie sur le FMS et/ou sur un ou plusieurs EFB (sacs ou sacoches de vol électroniques) et/ou tablettes et/ou calculateur de compagnie aérienne ou de mission.

Claims (15)

1. Procédé pour la gestion d’une route d’un aéronef mis en oeuvre dans un système comprenant un ou plusieurs systèmes de type avionique et un ou plusieurs systèmes de type non-avionique, comprenant les étapes:

- déterminer une route alternative à la route courante suivie par l’aéronef dans un système de type non-avionique;

- vérifier la route alternative déterminée dans un système de type non-avionique et/ou dans un système de type avionique.

2. Procédé selon la revendication 1, l’étape consistant à vérifier la route alternative comprenant les étapes consistant à :

- afficher la route alternative sur un écran d’affichage d’un système nonavionique ;

- recevoir depuis le système non-avionique une commande d’avance vers le passé ou vers l’avenir déterminant un point dans le temps et dans l’espace et

- afficher des paramètres de vol associés audit point.

3. Procédé selon la revendication 1, l’étape consistant à vérifier la route alternative comprenant l’application de règles logiques prédéfinies.

4. Procédé selon la revendication 1, l’étape consistant à déterminer une route alternative comprenant l'étape consistant à sélectionner depuis une interface homme-machine d’un système non-avionique une route alternative.

5. Procédé selon l’une quelconque des revendications précédentes comprenant en outre l’étape consistant à évaluer et/ou insérer et/ou activer la route alternative vérifiée dans le système avionique de gestion de vol.

6. Procédé selon la revendication 1, comprenant en outre une étape consistant à détecter un paramètre de vol ou événement en fonction de critères prédéfinis et à afficher à l’écran une alerte quant à ce paramètre ou événement.

7. Procédé selon la revendication 1, l’étape consistant à déterminer une route alternative dans le système de type non-avionique comprenant l’exécution, dans le système non-avionique, d’un code logiciel identique à celui-mis en oeuvre dans le système avionique de gestion de vol.

8. Procédé selon la revendication 1, l’étape consistant à déterminer une route alternative dans le système de type non-avionique comprenant l’exécution, dans le système non-avionique, d’un code logiciel fonctionnellement équivalent à celui-mis en oeuvre dans le système avionique de gestion de vol.

9. Procédé selon l’une quelconque des revendications précédentes, comprenant l’étape consistant à modifier la route alternative déterminée.

10. Procédé selon la revendication 1, l’interface homme-machine comprenant au moins un curseur configuré pour déclencher ou commander l’affichage d’un ou de plusieurs paramètres de vol associés à la route alternative déterminée au cours du temps en fonction du déplacement dudit curseur.

11. Procédé selon l’une quelconque des revendications précédentes, une ou plusieurs étapes étant déclenchées en fonction du contexte de vol.

12. Produit programme d’ordinateur, ledit programme d’ordinateur comprenant des instructions de code permettant d’effectuer les étapes du procédé selon l'une quelconque des revendications 1 à 11, lorsque ledit programme est exécuté sur un ordinateur.

13. Système comprenant au moins un système de type avionique et un ou plusieurs systèmes de type non-avionique pour la mise en œuvre des étapes du procédé selon l’une quelconque des revendications 1 à 11, un système avionique étant associé avec un taux de panne physique inférieur et une vérification logique supérieure à ceux d’un système de type non-avionique.

14. Système selon la revendication 12, un système de type avionique comprenant un système de gestion de vol de type avionique F.M.S. et/ou un système de contrôle du traffic de la navigation aérienne.

15. Système selon la revendication 12 un système de type non-avionique comprenant un sac de vol électronique ou E.F.B. ou une tablette numérique.