FR3067802A1 - Gestion de routes alternatives pour 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 sont décrites. Un système avionique est généralement 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. Des développements de l'invention décrivent notamment l'utilisation : de ressources de calcul distantes; d'étapes de comparaison, de tests, de vérification et d'autorisation avant injection de données d'origine non-avionique dans l'avionique ; de modalités d'interaction homme-machine ; de paramètres divers (météorologie, trafic aérien, etc) à des fins d'optimisation combinatoire ; et de sacs de vol électronique E.F.B. et de systèmes de gestion de vol F.M.S.

Description

GESTION DE ROUTES ALTERNATIVES POUR UN AERONEF

Domaine de l’invention

L’invention concerne le domaine de l’avionique. En particulier, l’invention concerne des procédés et des systèmes pour la gestion des routes alternatives d’un aéronef.

Etat de la Technique

Dans les systèmes avioniques existants, des « routes » aériennes alternatives (plans de vols) peuvent être insérées dans le plan de vol d’un gestionnaire de vol, faisant partie de l’avionique (certifiée) de l’aéronef. Cette insertion peut être effectuée de manière manuelle, par exemple en insérant un message de liaison de données air/sol provenant du contrôle aérien (ou de la compagnie aérienne). Le plan de vol est alors chargé dans un plan de vol dit secondaire pour permettre au pilote de le vérifier, de l’ajuster éventuellement, puis de l’insérer comme la nouvelle référence de vol.

Ces techniques de gestion du vol rencontrent des limitations, inhérentes aux systèmes avioniques. Par exemple, les modalités de modification de la route de l’aéronef sont limitées par les capacités offertes par l’équipement avionique (e.g. fonctionnalités d’édition), ainsi que par les limitations en matière de puissance de calcul, de stockage et de bande passante, voire même d’interaction hommemachine (e.g. écrans non tactiles)

De ce fait, de manière opérationnelle, la gestion de la mission de l’aéronef se fonde sur des éléments factuels restreints et limités, par construction, en raison des limitations inhérentes aux systèmes avioniques.

En ce qui concerne la gestion de routes d’évitement (par exemple d’un événement météorologique défavorable), différentes modalités de calcul d’une route d’évitement (latérale ou verticale) sont connues. Par exemple, le document de brevet FR2749686 intitulé « Procédé de pilotage d'un aérodyne pour l'évitement vertical d'une zone » divulgue un système pour l'évitement latéral à partir d'informations fournies périodiquement. Ce type d’approche présente néanmoins des limitations. Les procédés existants reposent en effet généralement sur des traitements relativement simples destinés à être intégrés dans l’avionique. Alternativement, des calculs complexes peuvent être effectués, mais le résultat de ces calculs ne peut pas être inséré directement ou de manière simple dans l’avionique (le chargement dans l’avionique passe soit par une saisie par le pilote, soit au minimum par une vérification par le pilote, pour laquelle les moyens de visualisation embarqués de l’avionique sont peu appropriés). Le problème technique de l’intégration des systèmes avioniques avec les systèmes non-avioniques reste entier.

Il existe un besoin pour des procédés et des systèmes avancés de gestion des routes alternatives 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 sont décrites. Un système avionique est généralement 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. Des développements de l’invention décrivent notamment l’utilisation : de ressources de calcul distantes; d’étapes de comparaison, de tests, de vérification et d’autorisation avant injection de données d’origine non-avionique dans l’avionique ; de modalités d’interaction homme-machine ; de paramètres divers (météorologie, trafic aérien, etc) à des fins d’optimisation combinatoire ; et de sacs de vol électronique E.F.B. et de systèmes de gestion de vol F.M.S.

La solution proposée consiste à proposer des capacités de chargement de données, d’édition manuelle et graphique, et de calcul de la route de l’avion sur des moyens de calcul extérieurs à l’avionique (tablette, ordinateur portable, serveur déporté) ainsi que les moyens d’échange et de vérification avec la route active dans l’avionique, permettant l’évaluation puis l’insertion sécurisée de la route alternative dans l’avionique.

Avantageusement, l’invention permet de déterminer une ou plusieurs routes alternatives, en exploitant des données enrichies (par exemple de contexte), des capacités de calcul et des modalités d’interaction homme-machine présentant des qualités et des performances que ne permettent pas les seuls systèmes de types avioniques.

Avantageusement, l’invention permet de tirer parti des capacités généralement supérieures des systèmes non-avioniques en matière de traitement de l’information (e.g. ordinateurs portables, tablettes et ressources distantes type cloud computing).

Avantageusement, l’invention permet de tirer parti de données nombreuses et diversifiées. Le choix d’une route alternative peut notamment prendre en compte des données externes à l’avionique (e.g. météorologie).

Avantageusement, l’invention permet l’accès à des données sur des réseaux ouverts, en minimisant les risques en matière d’intrusion ou d’injection de données non fiables.

Avantageusement, l’invention permet de tirer parti de méthodes et de systèmes 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).

Avantageusement, l’utilisation d’un ou de plusieurs calculateurs externes permet de bénéficier d’une gestion de mission enrichie, accompagnée de moyens d’échanges sécurisés, et de moyens de comparaison et de vérification, permettant une transition fiable et aisée vers le calculateur de navigation avionique et l’exécution de la mission.

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 centre 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 différents modes de réalisation du calculateur ouvert ;

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

La gestion de mission d’un aéronef, qu’elle concerne un transport de passager, un transport de fret civil ou une mission militaire, est de plus en plus complexe. Cette complexité tient à plusieurs facteurs, tenant notamment à la quantité et à la diversité des données manipulées (ou manipulables) et à la puissance de calcul pouvant être sollicitée.

D’une part, les informations entrant en ligne de compte dans la définition de la mission sont de plus en plus complexes (e.g. évolution des phénomènes atmosphériques dans l’espace et dans le temps, traffic aérien environnant, présent et futur au long du vol, prise en compte de besoins plus élaborés de la clientèle en termes de services ou de disponibilités d’infrastructures, complexité des missions et des menaces tactiques et géostratégiques).

D’autre part, la détermination d’une solution optimale, ou parfois même simplement satisfaisante, repose sur des traitements complexes, et peut nécessiter, en complément de l’automatisation, un ajustement manuel de la solution proposée, ou des hypothèses de calcul, par l’opérateur.

Cette complexité croissante de la gestion de mission est difficilement compatible avec les exigences de robustesse et de fiabilité des systèmes avioniques embarqués, qui peuvent constituer un frein majeur à la mise en œuvre de solutions opérationnellement performantes.

Pourtant, des données opérationnelles de plus en plus élaborées et pertinentes pour l’optimisation de la mission sont ou deviennent disponibles, accessibles par des réseaux de données dont la performance s’accroît régulièrement. La puissance de calcul s’accroît également : des capacités de calcul disponibles sur des tablettes de petit format permettent le développement d’outils d’optimisation performants et élaborés, mais dont la complexité rendrait leur fiabilisation trop coûteuse pour envisager de les intégrer dans l’avionique.

Les procédés et les systèmes selon l’invention réalisent une intégration avantageuse des systèmes avioniques et non-avioniques, dans certains contextes et objectifs spécifiques.

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 »). Dans le cas d’un drone, l’aéronef comprend des équipements avioniques embarqués et les équipements optionnels et les interfaces avec l’opérateur sont déportés au sol.

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, plus 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é.

De manière générale, 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.

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 supé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 faites par le système avionique (par exemple, il peut être vérifié qu’une trajectoire est construite avec des points connus et qu’elle 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, des exemples de systèmes de type non-avionique 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.

Par extension, les systèmes avioniques 121 peuvent comprendre des systèmes accessibles à distance, par exemple de contrôle de traffic aérien 1001 et/ou de centre opérationnel 1002, 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 1002 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.

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 comparateur 231 par exemple de type sécurisé, des équipements d’interface homme-machine et/ou homme-système 232, un ou plusieurs calculateurs de type ouvert 233 et un système passerelle 220.

Principes de régulation

La régulation des interactions entre les systèmes avioniques 121 et systèmes de type non-avionique 122, i.e. les règles de gestion des échanges de données, peuvent être diverses, selon les modes de réalisation. Elles peuvent être peu nombreuses et donc rapides et efficaces. Elles peuvent aussi être complexes et faire intervenir plusieurs acteurs, cad résulter de l’intervention conjointe de l’homme ou de la machine.

Généralement, les modalités de communication entre les deux types de systèmes système avionique et système non-avionique, recouvrent différents aspects ou paramètres:

a) directionalité; la communication entre les deux types de système (e.g. flux de données, passages de messages, etc) peut être unidirectionnelle ou bidirectionnelle. Cette propriété de directionalité peut être statique (invariante ou cours du temps) mais peut aussi évoluer au cours du temps (suivant des intervalles de temps prédéfinis et/ou selon des événements prédéfinis), par exemple selon la phase ou le contexte de vol. Par exemple, la communication peut être bidirectionnelle lorsque l’avion est au sol à sa porte d’embarquement, et unidirectionnelle dès le roulage. Dans cet exemple, lorsque l’avion est au sol, toute modification proposée par le système non-avionique au système avionique peut être vérifiée, et, si elle était erronée, elle ne diminuerait pas la sécurité dans la mesure où cette modification pourrait encore être modifiée et corrigée. Dés le roulage et en vol, la communication intervient dans un premier temps uniquement du système avionique vers le système non-avionique, toute donnée produite par le système non-avionique ne pouvant pas être automatiquement transférée au système avionique.

b) forme (e.g. format de données, type de protocoles, traduction/pontage, etc). Par exemple, un protocole WIFI ou filaire Ethernet peut être le plus optimisé au sol (compte tenu du volume important qui peut être échangé au sol pour initialiser la mission) alors qu’un protocole plus sécurisé mais de moindre débit peut-être préférable en vol, compte tenu des architectures de communications bord (AEEC ARINC 653) qui peuvent nécessiter de garantir de la bande passante et de l’intégrité pour tous les calculateurs critiques et peuvent donc limiter de fait le débit et le type de données échangées avec le système nonavionique.

c) fond (qualité e.g. nature des objets communiqués e.g. points de plan de vol ou trajectoire 3D, etc ; données sur les données i.e. métadonnées ; données brutes ou statiques ; données exécutables i.e. programmes). Un système nonavionique, en sus des plans de vol, peut être le réceptacle de nombreuses données riches dont une partie seulement sera exploitée par le système avionique : cartes aéronautiques, cartes géographiques de résolution maximale, cartes météo complètes. Le système avionique peut utiliser une sous partie des données, filtrées pour ses besoins (par exemple filtrage le long du plan de vol, filtrage de la résolution adaptée à ses limitations mémoires, à ses limitations en puissance de calcul, etc).

d) quantité (ou volumes). Un système non-avionique peut utiliser des données riches (il n’existe pas de limitation réelle en matière de processeur, de mémoire et de stockage; des processeurs multi-cœurs puissants peuvent être utilisés, alors que les calculateurs système avionique ont une architecture matérielle très robuste mais beaucoup plus limitée pour garantir la testabilité de la performance requise, par exemple avec des propriétés de résistance aux évènements de particules à haute énergie lors du vol (SEU, NSEU), de résistance aux vibrations ou aux températures extrêmes. Les calculateurs système avionique ont en général significativement moins de puissance que les calculateurs nonavioniques.

e) privilèges ou priorités (e.g. des priorités globales peuvent être allouées ; par exemple le système avionique « maître » sera associé à une priorité en tout temps supérieure au système non-avionique « esclave » ; des privilèges « administrateur » ou en « lecture/écriture » seront allouées aux différentes parties par exemple en matière d’accès, de lecture et/ou d’écriture dans l’un ou l’autre type de système.

La régulation des échanges de données peut régir chacun de ces aspects de manière différente et les combiner d’une manière particulière. Selon les modes de réalisation, il sera obtenu des systèmes maitres/esclaves (évolutifs ou non) ou des réseaux de pairs-à-pairs (évolutifs ou non), comprenant des rétroactions diverses et variées (e.g. feedforward, etc)

A titre d’exemple d’une combinaison 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).

Serveur passerelle

Dans un mode de réalisation, une tierce entité (organe régulateur) établit le lien entre le(s) système(s) avionique(s) et le(s) système(s) non avionique(s).

Par exemple, une entité intermédiaire ou « serveur passerelle » 220 peut réguler les échanges.

Dans un mode de réalisation, le serveur passerelle 220 (e.g. des techniques, des étapes, un ou plusieurs systèmes dédiés, etc) permet le chargement de la route alternative d’origine non-avionique dans le calculateur de type avionique (calculateur de navigation), par exemple via le serveur passerelle 220.

Dans un mode de réalisation, un serveur passerelle est un espace de stockage passif. Il enfiche (mise en file d’attente) les éléments calculés par les systèmes non-avioniques et les transmet in fine aux systèmes avioniques. Le serveur passerelle sert alors de mémoire tampon (« buffer ») entre les deux types de systèmes. Dans un mode de réalisation, le serveur passerelle peut ordonner la file d’attente, par exemple selon la priorité associée aux différents objets mis en file d’attente, selon le contexte de vol et/ou l’utilisation des ressources avioniques qui peuvent être selon les cas sous-sollicitées ou sur-sollicitées, etc.

Dans un mode de réalisation, le serveur passerelle entre système avionique et système non-avionique est un espace de stockage actif, i.e. qui ajoute des traitements logiques aux données reçues. Le serveur passerelle peut effectuer une ou plusieurs des actions suivantes : effectuer ses propres vérifications sur la conformité d’une route par rapport aux critères avioniques, intégrer par redondance une ou plusieurs des fonctionnalités dévolues aux blocs de comparaison 231, d’IHM 232, ou de calcul FMS 233 (aux fins de double vérification par exemple), recevoir des instructions d’un système tiers, etc. Dans un mode de réalisation, le serveur passerelle 220 peut vérifier la conformité entre la trajectoire calculée dans l’avionique et la trajectoire issue du calcul hors avionique.

En particulier, le serveur passerelle entre système avionique et système nonavionique - en tant que composant critique à l’interface des deux types de systèmes - peut faire l’objet de mesures de sécurité dédiées (par exemple de manière indépendante des autres systèmes). Le serveur passerelle peut être sécurisé par différents moyens, comprenant notamment 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’auto-surveillance (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, le serveur passerelle entre système avionique et système non-avionique 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).

Comparateur

Dans un mode de réalisation, la fonction du comparateur 231 (ou fonction ou étape de comparaison) vise à comparer la route alternative d’une part et la route présente dans le calculateur de navigation avionique d’autre part.

Dans un mode de réalisation, le comparateur vise à identifier les gains opérationnels et/ou de vérifier la conformité de la route chargée dans l’avionique.

Le comparateur 231 et/ou les interfaces 232 et/ou le calculateur de type ouvert 233 et le système passerelle 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 le calculateur 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 comparateur 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 le serveur passerelle 220.

Interfaces homme-machine

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 œuvre 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 cés 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). Dans un mode de réalisation, la visualisation des différentes routes alternatives peut s’enrichir d’une interaction sur le temps prédit, de manière à faire évoluer la situation prédite de l’aéronef et du contexte au cours du temps, du début à la fin de la mission. L’interaction sur le temps prédit peut se faire par exemple par interaction tactile, dispositif de pointage, ou dispositif mécanique tel qu’un rotacteur.

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.

Données ouvertes

Dans un mode de réalisation, le calculateur ouvert 133 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 ouvertes 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.

Un autre exemple de données ouvertes concerne la structure de l’espace aérien. Dans un mode de réalisation, le calculateur dit ouvert 233 peut prendre en compte la structure des secteurs de contrôle aérien, comme les TMA (de l’anglais « Terminal Manoeuvring Area ») de différents aéroports, les secteurs de contrôle en route définis par des limites géographiques ou des niveaux d’altitude, ainsi que les frontières entre Centres en Route de Navigation Aérienne (CRNA en France) ou entre pays, de manière à permettre la définition d’une route qui s’intégre au mieux à la circulation aérienne, et qui soit susceptible d’être accepté par le contrôle aérien local.

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 figure 3 illustre différents modes de réalisation du calculateur ouvert 233.

La figure présente avec plus de détails des exemples de composants du calculateur 233. Le calculateur ouvert 233 comprend du matériel et du code logiciel exécuté sur ce matériel, implémentant des étapes de détermination d’une ou de plusieurs routes alternatives.

Plusieurs types de traitement complémentaires peuvent généralement être distingués au sein de ce calculateur. Ces types ou classes de traitement sont symbolisés par des blocs de recherche et d’optimisation 310, des étapes de transcription 320 (adaptation, traduction, etc) en route avionique, lesquels conduisent à des calculs et prédictions de trajectoires 330. Les trajectoires produites sont enfin manipulées dans le comparateur (éventuellement sécurisé 231).

Le calculateur 233 effectue des traitements (complexes) de recherche ou d’optimisation de trajectoires 310. Les espaces de recherche peuvent être de grandes dimensions, les méthodes de recherche variées, déterministes ou non, globales ou locales, avec des formes de modélisation de la trajectoire adaptées à la méthode de recherche.

Le calculateur 233 peut effectuer des calculs de prédiction de trajectoire identiques, ou fonctionnellement équivalents, à ceux effectués dans le système avionique. Les traitements de calcul et de prédiction sont notamment destinés à permettre la comparaison avec les calculs de trajectoire du système avionique, soit à des fins d’estimation de bénéfices, soit à des fins de vérification de conformité. Ils reproduisent donc autant que possible les traitements tels qu’ils seront appliqués par le système avionique. Afin de reproduire fidèlement les calculs, plusieurs modes de réalisation sont décrits.

Dans un mode de réalisation, un code structurellement identique (même code source) est exécuté (éventuellement recompilé ou transcrit pour le calculateur non avionique).

Dans un mode de réalisation, un code fonctionnellement équivalent est exécuté. Le résultat de l’exécution ce code est représentatif de celui produit par le système avionique.

Les étapes d’optimisation du bloc 310 peuvent utiliser, de manière non limitative, des étapes de recherche opérationnelle comprenant des heuristiques, comme des algorithmes A-star, ou des étapes de méthodes probabilistes (comme les algorithmes génétiques). Certains traitements peuvent faire appel à des traitements massifs de données de type « big data », ou s’appuyer sur des architectures de traitements fortement parallèles. Des ressources de calcul accédées à distance ou embarquées (e.g. calcul hautes performances GPU) peuvent être sollicitées, par exemple en appoint. Une méthode de recherche globale, éventuellement imprécise, peut être complétée par une optimisation locale, appliquant des techniques d’optimisation non-linéaires, ou des algorithmes à base de champs de potentiels. Ces méthodes se caractérisent par une combinatoire, et parfois un non-déterminisme, ou des propriétés de convergence, qui ne permettraient pas de garantir la fiabilité requise par le système avionique. De plus, ces traitements de recherche et d’optimisation prennent en compte une grande variété et une forte complexité de données d’entrée issues de provenances diverses et non garanties : informations en temps réel, prédictives ou statistiques, concernant la météorologie, le trafic aérien ou tout autre élément de contexte opérationnel. Une telle variabilité des données d’entrée rendrait très complexe, sinon inatteignable, une garantie de fiabilité sur le résultat.

Pour permettre le passage des traitements de recherche et d’optimisation, aux traitements de calcul et de prédiction à l’identique de l’avionique, les résultats de recherche et d’optimisation sont transcrits (bloc 320) dans un format fonctionnellement équivalent à celui manipulé par le système avionique.

Matériellement, le calculateur 233 peut être implémenté sur tablette ou ordinateur portable (ou sur tout autre moyen de calcul externe à l’avionique, par exemple via des accès distants) permettant de déterminer (e.g. rechercher, évaluer, sélectionner, etc) des routes alternatives. Il peut également reposer sur des infrastructures de calcul au sol, reposant sur des architectures distribuées ou massivement parallèles.

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 système de type avionique et un système type non-avionique, comprenant les étapes: - déterminer une route alternative à la route courante dans le système de type non-avionique; - recevoir une autorisation d’insertion de ladite route dans le système avionique de gestion de vol ; - insérer ladite route 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).

Le terme « insérer » se réfère à une révision de plan de vol. Le terme « activer » signifie que la route devient la référence d’asservissement et va effectivement être volée. Une insertion est donc le préalable à une activation, la toute première opération pour la prise en compte du calcul d’origine non-avionique.

L’étape consistant à recevoir une autorisation 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 l’étape consistant à insérer et/ou activer la route alternative vérifiée dans le système avionique de gestion de vol. Dans un mode de réalisation, il peut y avoir une insertion préalable dans le système avionique, puis une vérification, puis enfin une activation de la route comme référence 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 identique à celui-mis en œuvre 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 comprenant l’exécution, dans le système non-avionique, d’un code logiciel fonctionnellement équivalent à celui-mis en œuvre dans le système avionique de gestion de vol.

Dans un mode de réalisation, l’autorisation d’insertion de ladite route alternative étant reçue d’une interface homme-machine et/ou étant autorisée par un système de type avionique.

Le pilote a un rôle privilégié en ce qu’il est responsable de l’injection de données d’origine non-avionique dans les systèmes avioniques. L’autorisation peut résulter d’une action conjointe homme-machine selon différentes configurations (pré- évaluation machine et validation humaine, ou l’inverse, mécanismes de vote, etc).

Dans un mode de réalisation, l’autorisation d’insertion est conditionnée à une étape consistant à comparer la route alternative déterminée dans ou par le système de type non-avionique avec la route courante déterminée dans ou par le système de type avionique.

Dans un mode de réalisation, la comparaison est relative, et « sûre » car directe: la nouvelle route (candidate) est comparée avec la route actuelle ou courante (validée par l’avionique).

La comparaison, graphique ou non, permet d’évaluer les gains (ou les pertes) opérationnels et donc la pertinence d’insérer la route dans le système avionique.

Les critères peuvent comprendre un ou plusieurs des critères comprenant un gain ou une perte opérationnel en matière de temps de vol, de consommation de fuel, de distance à une perturbation météorologique, l’exposition en durée et/ou en intensité à une perturbation météorologique.

Dans un mode de réalisation, le procédé comprend l’étape consistant à évaluer ou vérifier la route alternative déterminée selon des critères prédéfinis.

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. II 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 l’IHM, 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 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’étape consistant à modifier la route alternative déterminée comprend une ou plusieurs étapes d’optimisation combinatoire et/ou d’optimisation multiobjectif, en fonction d’un ou de plusieurs paramètres sélectionnés parmi les paramètres comprenant les conditions météorologiques présentes et prédites dans lesquelles évolue l’aéronef, le trafic aérien environnant, la structuration de l’espace aérien, les services aéroportuaires de l’aéroport de destination ou de déroutement, le facteur de charge et/ou le confort passager estimé et associé à ladite route, le coût de carburant, le temps de vol, la ponctualité du vol, le coût de vol opérationnel, la disponibilité du personnel naviguant, la disponibilité du matériel de maintenance, des critères environnementaux, le respect des règles compagnies AOC et réglementaires ATC, la probabilité d’acceptation de la route alternative en matière de négociation AOC et/ou ATC.

L’optimisation effectuée par le procédé selon l’invention peut être de différentes natures. L’optimisation peut être « combinatoire » (optimisation discrète), consistant à trouver dans un ensemble discret un parmi les meilleurs sousensembles (ou solutions) réalisables, la notion de meilleure solution étant définie par une (seule) fonction objectif. L’optimisation peut également être « multiobjectif » (i.e. chercher à optimiser simultanément plusieurs objectifs d'un même problème).

Les critères peuvent être variés. D’autres paramètres additionnels peuvent aussi concerner la prise en compte des messages NOTAM, l’évaluation de la charge cognitive pour le pilote, et plus généralement de l’infrastructure de services dans et autour de l’aéroport.

Le nombre des paramètres ou contraintes peut par exemple progressivement incrémenté ou décrémenté, les paramètres peuvent être d’égale importance ou hiérarchisés (e.g. pondérés).

Dans un mode de réalisation, l’interface homme-machine affiche en les juxtaposant la route alternative déterminée et la route courante de l’aéronef.

Dans un mode de réalisation, la route de référence issue de l’avionique et la route alternative en cours d’élaboration sont affichées simultanément.

Dans un mode de réalisation, l’interface homme-machine comprend au moins un curseur configuré pour déclencher 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, le procédé comprend l’étape consistant à recevoir des données d’origine non-avionique pour déterminer une route alternative à la route courante dans le système de type non-avionique

Les mêmes remarques quant à la nature avionique versus non-avionique s’appliquent aux données. Une donnée qu’elle soit d’origine avionique ou nonavionique reste une donnée. L’origine ou la source de la donnée traduit néanmoins la confiance mesurée en terme de fiabilité et/ou de précision associée à ladite donnée (attribut de la donnée, donnée sur la donnée i.e. métadonnée).

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

Par exemple, la présence ou l’absence d’une interaction IHM à des fins d’autorisation d’insertion et/ou d’activation peuvent être conditionnées à une phase de vol considérée comme critique. L’étape d’optimisation peut elle aussi être asservie à la phase de vol (plus ou moins de critères peuvent être pris en compte). Plus généralement, chacune des étapes mentionnées précédemment peut être modulée ou influencée ou paramétrée en fonction de la phase ou du contexte de vol.

Contexte de vol

Dans certains modes de réalisation, une ou plusieurs des étapes du procédé (e.g. type de test effectué pour accorder ou refuser les autorisations d’insertion et/ou d’activation, moment sélectionné pour demander au pilote un avis consultatif ou une autorisation formelle, sélection d’un ou de plusieurs critères pris en compte pour la détermination de la route alternative, etc) peuvent être asservies au contexte de vol de l'aéronef (e.g. phases de vol).

Le contexte de vol à 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). II 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 système pour la gestion d’une route d’un aéronef comprenant - un système de type non-avionique configuré pour déterminer une ou plusieurs routes alternatives à la route courante de l’aéronef;- un système passerelle configuré pour recevoir une autorisation d’insertion d’une route alternative dans un système avionique;- ledit système avionique comprenant un système de gestion de vol configuré pour insérer ladite route dans le système avionique de gestion de vol ;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 et un système de type non-avionique comprend un sac de vol électronique E.F.B. ou une tablette numérique.

D’autres modes de réalisation ou aspects de l’invention sont décrits ci-après.

A l’étape 410, une route alternative ou candidate (ou plus généralement un objet) est déterminée (ou créée ou élaborée) par un ou plusieurs calculateurs 233 dont le matériel est de type non-avionique (i.e. non préalablement certifié).

Dans un mode de réalisation, un calculateur 233 permet un calcul de prédiction de la trajectoire de l’aéronef, pour une route choisie, qui s’appuie sur les mêmes algorithmes et les mêmes modèles de performance de vol que le calculateur de navigation de l’avionique. Avantageusement, la comparaison des résultats est de cette manière fiable et significative.

Dans un mode de réalisation, un calculateur 233 exécute (exactement) le même code logiciel (code source) que celui qui est implémenté dans le système certifié avionique. Dans un mode de réalisation, le matériel est également identique. Dans un mode de réalisation, une machine virtuelle est utilisée (e.g. hyperviseur).

Dans un mode de réalisation, un calculateur 233 exécute un code logiciel « fonctionnellement équivalent » (code compilé) à celui qui est implémenté dans le système certifié avionique. Dans un mode de réalisation, les pseudo-codes (non-avionique d’une part, avionique d’autre part) sont identiques. Dans un mode de réalisation, ils sont similaires (les différences portant sur des éléments non-critiques).

A l’étape optionnelle 420, les routes A (selon le système non avionique) et B (selon l’avionique, à partir des mêmes données en entrée) sont comparées et le résultat de la comparaison conditionne si une boucle de vérification par le pilote est requise ou seulement optionnelle La comparaison peut s’effectuer à l’identique ou modulo des tolérances (fonction du contexte de vol, de la présence de paramètres critiques, etc).

Dans un mode de réalisation, la route (ou l’objet) peut être comparée à la référence présente dans l’avionique pour en évaluer les gains opérationnels et la pertinence.

Dans un mode de réalisation, les variantes à la mission (plans de vols, trajectoires, etc) peuvent être soumises au pilote pour appréciation (e.g. correction, annotation, validation, modulation), qui peut en évaluer la pertinence.

Le cas échéant, une étape de vérification et/ou de modification 430 de la route (ou de l’objet) peut être effectuée (boucle ouverte), par exemple par le pilote (ou un collectif de personnes) et/ou un système de décision machine (e.g. système tiers, ATC etc).

La vérification d’une ou de plusieurs conditions peut s’accompagner d’une autorisation 460 (e.g. code, signal, requête, etc) si un sous-ensemble prédéterminé de ces conditions est satisfait (selon un modèle et des seuils ou plages de seuils prédéfinis).

Dans un mode de réalisation, la route (ou l’objet) est modifiée 430 en un ou plusieurs de ses points, à l’aide d’une interface homme-machine 461.

A l’étape 430, la route inchangée, ou éventuellement modifiée, peut être explicitement validée (ou autorisée) par le pilote. Cette route ou objet d’origine non-avionique est alors enfichée (communiquée, stockée, manipulée) dans le serveur passerelle 220.

Dans un mode de réalisation, le serveur passerelle 220 est un espace de stockage passif. Il enfiche (mise en file d’attente) les éléments calculés par les systèmes non-avioniques et les transmet in fine aux systèmes avioniques. Le serveur passerelle sert alors de mémoire tampon (« buffer ») entre les deux types de systèmes. Dans un mode de réalisation, le serveur passerelle peut ordonner la file d’attente, par exemple selon la priorité associée aux différents objets mis en file d’attente, selon le contexte de vol et/ou l’utilisation des ressources avioniques qui peuvent être selon les cas sous-sollicitées ou sursollicitées, etc.

Dans un mode de réalisation, le serveur passerelle 220 est un espace de stockage actif, i.e. qui ajoute des traitements logiques aux données reçues. Le serveur passerelle peut effectuer une ou plusieurs des actions suivantes : effectuer ses propres vérifications sur la conformité d’une route par rapport aux critères avioniques, intégrer par redondance une ou plusieurs des fonctionnalités dévolues aux blocs de comparaison 231, d’IHM 232, ou de calcul FMS 233 (aux fins de double vérification par exemple), recevoir des instructions d’un système tiers, etc.

Dans un mode de réalisation, le serveur passerelle 220 peut vérifier la conformité entre la trajectoire calculée dans l’avionique et la trajectoire issue du calcul hors avionique.

En particulier, le serveur passerelle 220 - en tant que composant critique à l’interface des deux types de systèmes - peut faire l’objet de mesures de sécurité dédiées (par exemple de manière indépendante des autres systèmes). Le serveur passerelle peut être sécurisé par différents moyens, comprenant notamment 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’auto-surveillance (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, le serveur passerelle 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).

Les données transmises ou manipulées ou modifiées par le serveur passerelle 220 sont alors communiquées aux systèmes avioniques.

Dans un mode de réalisation, la route modifiée (ou non) et validée/vérifiée/autorisée est «insérée» 440 dans le système avionique 121, c’est-à-dire qu’à cet instant précis des données externes sont prises en compte dans le système de gestion de vol certifié (avec un risque résiduel d’injection malveillante de données). Ultérieurement, les données peuvent être activées dans le plan de vol de référence.

Dans un mode de réalisation, des variantes de la mission peuvent donc être injectées ou réintégrées dans les systèmes avioniques.

Concernant les interfaces homme-machine IHM ou homme-système IHS 232, différents modes de réalisation sont envisageables. Avantageusement, le pilote peut en effet évaluer la pertinence de la solution proposée par le calculateur, mais aussi peut aussi modifier ou ajuster la solution selon ses propres critères opérationnels, ou pour prendre en compte des contraintes opérationnelles non prises en compte par le calcul automatique. Pour cela, des modifications apportées aux écrans d’affichage graphique existants peuvent être mises en oeuvre.

Dans un mode de réalisation, la route de référence issue de l’avionique, et la route alternative en cours d’élaboration sont juxtaposées et affichées simultanément.

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 l’état prédit de l’aéronef sur chacune des trajectoires.

Dans un mode de réalisation, il peut être fourni au pilote des critères additionnels pour améliorer la prise de décision. Par exemple, pourront être affichés des gains opérationnels, en matière de temps de vol ou de consommation de carburant, la distance minimale à la perturbation, ou l’exposition maximale en durée ou en intensité à une perturbation traversée.

Dans un mode de réalisation, une même interface graphique affiche la route en cours d’élaboration sur le calculateur ouvert et la route définie dans le système avionique.

Les équipements d’interface peuvent recevoir directement de l’avionique les données de trajectoire à afficher pour les comparer à la route alternative ou bien disposer d’une importation (fiabilisée) de la trajectoire issue de l’avionique, de manière à les gérer et les afficher ensuite depuis le calculateur de route alternative.

Selon les modes de réalisation, l’opérateur peut agir directement sur les points de la route proposée, pour - ajouter, supprimer, déplacer un point de la route ; afficher et faire passer la route par les points et les routes aériennes publiés dans la base de données de navigation ; - afficher les secteurs de contrôle aérien et les rails de navigation océanique pour ajuster la route en conséquence; - afficher ou modifier un cap ou une distance de vol sur un segment de la route proposée ; - ou bien encore proposer l’ajustement d’un cap ou d’une distance de la route selon un critère choisi (temps de vol, pente jusqu’à une contrainte, capacité de descente et de stabilisation avant la piste).

Concernant les échanges de données entre les systèmes non-avioniques 122 et les systèmes avioniques 121, les échanges d’information de route avec l’avionique peuvent permettre de disposer dans le calculateur ouvert 233 d’une information fiable sur la route de référence actuelle, et d’exporter de manière fiable la solution de route alternative vers l’avionique pour permettre sa prise en compte et son exécution ultérieure.

Concernant l’insertion de la route alternative déterminée par les systèmes de type non-avionique, différents modes de réalisation sont décrits ci-après.

Dans un mode de réalisation, l’insertion de la route alternative dans les systèmes avioniques est effectuée par liaison de données, par exemple au moyen de liaisons sol-bord 1211 (des protocoles de requêtes de route par les centres de contrôle aérien 1001 ou par les centres opérationnels 1002 compagnie peuvent être utilisés). Ces requêtes permettent en particulier de charger une nouvelle route dans le calculateur de navigation 1213/1214, ce qui peut permettre de charger la route alternative, qui est alors chargée dans un plan de vol secondaire, et peut devenir la référence de navigation après validation par l’opérateur. D’autres requêtes permettent d’exporter la route chargée dans le calculateur de navigation, et donc de la fournir au le calculateur de route alternative.

Dans la mesure où le calculateur de route alternative peut intégrer les mêmes algorithmes et les mêmes modèles de performance de vol que le calculateur de navigation, la trajectoire recalculée sur cette route peut être considérée comme étant conforme à celle présente dans l’avionique. Cependant, la conformité de la route ne peut pas être systématiquement garantie, a priori. C’est une fois la route alternative chargée dans l’avionique que le pilote pourra en vérifier la conformité, évaluer les gains opérationnels attendus, et enfin activer le vol de l’aéronef sur cette nouvelle référence.

Dans certains modes de réalisation, le procédé peut comprendre une étape consistant à afficher (à destination du pilote) un guide de saisie interactif de la route, présentant par exemple des interfaces de saisie manuelle et différentes valeurs à saisir, pour le guider pas à pas dans la saisie de la route alternative, sur les interfaces de navigation disponibles dans le cockpit.

Différents modes de réalisation d’import et/ou d’export d’une route sont décrits ci-après.

Dans un mode de réalisation, la passerelle sécurisée 220 permet de transmettre vers l’extérieur («d’exporter ») des données issues de l’avionique, sans compromettre en rien la sécurité du vol.

Dans un mode de réalisation, la passerelle sécurisée 220 peut exporter (ou transférer ou communiquer) à l’extérieur (i.e. vers des systèmes non-avioniques) le résultat du calcul de trajectoire réalisé par le calculateur de navigation avionique. A l’aide du calcul réalisé, il peut être obtenu une représentation fidèle de la trajectoire de navigation, qui peut être affichée à l’opérateur (et servir de référence ultérieure).

Lorsqu’une route alternative a été chargée dans le calculateur de navigation avionique et que la trajectoire « avionique » associée a été calculée, l’export fiable de cette trajectoire permet son affichage à l’opérateur et sa vérification de conformité avec la trajectoire alternative calculée et affichée par le calculateur de route alternative hors avionique.

Concernant, l’import de données, les opérations peuvent être sécurisées par différents mécanismes.

Dans un mode de réalisation, la passerelle sécurisée peut permettre de charger directement une nouvelle route, qui peut être chargée dans le calculateur de navigation avionique. Une telle requête en général ne compromet en rien la sécurité du vol, car la route est chargée dans un plan de vol alternatif, qui doit être validé par le pilote avant d’être adoptée ou validée ou autorisés comme nouvelle référence active du vol.

Cette validation peut être facilitée par une vérification de conformité, sécurisée, effectuée hors de l’avionique mais fiabilisée pour être affichée au pilote et faciliter la validation de la nouvelle trajectoire.

Concernant la comparaison entre route alternative et route courante de l’aéronef, plusieurs modes de réalisation sont décrits ci-après.

La comparaison de trajectoires permet d’évaluer les gains opérationnels d’une manière fiable et significative, non biaisée par des variabilités dans le mode de calcul des trajectoires.

Durant la phase de prise en compte (ou d’import ou d’intégration) de la route alternative, la trajectoire calculée sur cette nouvelle route par le calculateur de navigation avionique peut être comparée à la trajectoire calculée dans le calculateur de route alternative. Cette comparaison par une fonction fiabilisée permet d’assurer la conformité de la route avant sa validation par l’opérateur en tant que nouvelle référence de vol.

Dans un mode de réalisation, la fonction de vérification invoquée peut être « qualifiée », 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, et/ou être couplée aux moyens d’affichage interactifs pour permettre une comparaison visuelle des résultats.

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.

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

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

Dans un mode de réalisation, le système pour la mise en oeuvre 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 oeuvre 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 oeuvre 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.

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. Revendications

   1. Procédé pour la gestion d’une route d’un aéronef mis en œuvre dans un système comprenant un système de type avionique et un système de type nonavionique, comprenant les étapes:

   - déterminer une route alternative à la route courante dans le système de type non-avionique;

   - recevoir une autorisation d’insertion de ladite route dans le système avionique de gestion de vol ;

   - insérer ladite route dans le système avionique de gestion de vol.
2. 2. 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 œuvre dans le système avionique de gestion de vol.
3. 3. 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 œuvre dans le système avionique de gestion de vol.
4. 4. Procédé selon la revendication 1, l’autorisation d’insertion de ladite route alternative étant reçue d’une interface homme-machine et/ou étant autorisée par un système de type avionique.
5. 5. Procédé selon la revendication 1, l’autorisation d’insertion étant conditionnée à une étape consistant à comparer la route alternative déterminée dans ou par le système de type non-avionique avec la route courante déterminée dans ou par le système de type avionique.
6. 6. Procédé selon l’une quelconque des revendications précédentes, comprenant l’étape consistant à évaluer ou vérifier la route alternative déterminée selon des critères prédéfinis.
7. 7. Procédé selon l’une quelconque des revendications précédentes, comprenant l’étape consistant à modifier la route alternative déterminée.
8. 8. Procédé selon la revendication 7, l’étape consistant à modifier la route alternative déterminée comprenant une ou plusieurs étapes d’optimisation combinatoire et/ou d’optimisation multiobjectif, en fonction d’un ou de plusieurs paramètres sélectionnés parmi les paramètres comprenant les conditions météorologiques présentes et prédites dans lesquelles évolue l’aéronef, le trafic aérien environnant, la structuration de l’espace aérien, les services aéroportuaires de l’aéroport de destination ou de déroutement, le facteur de charge et/ou le confort passager estimé et associé à ladite route, le coût de carburant, le temps de vol, la ponctualité du vol, le coût de vol opérationnel, la disponibilité du personnel naviguant, la disponibilité du matériel de maintenance, des critères environnementaux, le respect des règles compagnies AOC et réglementaires ATC, la probabilité d’acceptation de la route alternative en matière de négociation AOC et/ou ATC.
9. 9. Procédé selon la revendication 2, l’interface homme-machine affichant en les juxtaposant la route alternative déterminée et la route courante de l’aéronef.
10. 10. Procédé selon la revendication 2, l’interface homme-machine comprenant au moins un curseur configuré pour déclencher 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. 11. Procédé selon la revendication 1, comprenant l’étape consistant à recevoir des données d’origine non-avionique pour déterminer une route alternative à la route courante dans le système de type non-avionique
12. 12. 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.
13. 13. 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 à 12, lorsque ledit programme est exécuté sur un ordinateur.
14. 14. Système pour la gestion d’une route d’un aéronef comprenant

    - un système de type non-avionique configuré pour déterminer une ou plusieurs routes alternatives à la route courante de l’aéronef;

    - un système passerelle configuré pour recevoir une autorisation d’insertion d’une route alternative dans un système avionique;

    - ledit système avionique comprenant un système de gestion de vol configuré pour insérer ladite route dans le système avionique de gestion de vol ;

    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.
15. 15. Système selon la revendication 14, 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 et un système de type non-avionique comprenant un sac de vol électronique E.F.B. ou une tablette numérique.