DISPOSITIF D'ASSISTANCE AU PILOTAGE D'AÉRONEFS

Abstract

 La présente invention propose un dispositif d'assistance au pilotage d'un aéronef comprenant :
- un module de compétences comprenant une pluralité de composants applicatifs ou capacités, chaque capacité ayant un domaine de compétence et étant configurée selon un même format logique pour calculer des événements à partir de données acquises de différentes sources de l'avionique certifiée ou de l'avionique noncertifiée et/ou de différentes sources externes ou sources internes à l'aéronef, et pour traiter des requêtes de résolution et générer des propositions de résolution ;
- un module de traitement comprenant des composants configurés pour déterminer l'existence d'un impact sur la mission en cours de l'aéronef, soit à partir d'un évènement calculé, soit à partir d'une proposition de résolution ;
- un module de résolution comprenant des composants configurés pour émettre des requêtes de résolution à partir de l'existence d'un impact, et des composants configurés pour construire une solution d'adaptation de la mission en cours de l'aéronef à partir d'au moins une proposition de résolution; et
- un module de gestion comprenant des composants configurés pour gérer des contentions et des priorités de flux, et des composants configurés pour aiguiller les échanges entre les différents modules du dispositif.

Description

Domaine de l'invention

[0001] L'invention est dans le domaine technique de la gestion de mission d'aéronefs, et concerne plus particulièrement un dispositif d'assistance au pilotage d'aéronefs.

Etat de la Technique

[0002] Dans les aéronefs de complexité croissante, la gestion stratégique de la mission d'un aéronef, qu'il soit civil ou militaire, implique une charge de travail des pilotes de plus en plus importante, en particulier lorsqu'un évènement survient, qu'il soit interne à l'appareil (tel que par exemple une défaillance d'un système, un problème médical d'un passager) ou externe à celui-ci (tel que par exemple un changement de météo, une dégradation d'une installation), ou alors opérationnel (par exemple une modification de la mission telle que prévue à l'origine).

[0003] La gestion d'aéronef et de son environnement repose actuellement sur trois types de systèmes avioniques connus : des systèmes de type Alerte ou « Flight Warning System » (FWS), des systèmes de type Gestion ou « Flight Management System » (FMS), et des systèmes de type Surveillance.

[0004] Les systèmes de type Alerte (FWS) sont actuellement implémentés sur tous les types d'aéronefs. Leur utilité est double : alerter le pilote lorsqu'une situation anormale survient, et le cas échéant lui présenter les procédures permettant de traiter la défaillance pour revenir à une situation sous contrôle, garantissant la sécurité du vol et le retour au sol de l'appareil.

[0005] Sur certains systèmes plus élaborés, le FWS propose également une liste des systèmes inopérants (« INOP SYS ») ainsi que des actions, à traiter ultérieurement, pour couvrir les répercussions de la défaillance sur le reste de la mission (« DEFERRED PROCEDURE / LIMITATIONS »). Dans les aéronefs actuels, les systèmes sont de plus en plus interconnectés, et le nombre de défaillances qui peuvent être générées par le système peut s'avérer relativement important. Dans ce cas, c'est le pilote qui doit gérer et interpréter le cumul des informations et des limitations qui peuvent être applicables à sa situation.

[0006] Par ailleurs, il faut également noter que dans les systèmes FWS actuels, les informations à présenter à l'équipage sont déterminées de manière statique par une analyse qui est faite lors du design du système et de l'appareil. Cette analyse est faite en considérant l'intégralité des missions de l'aéronef incluant le pire cas, ce qui n'est pas forcément le cas de la mission en cours.

[0007] Il est également connu plusieurs systèmes de gestion du vol (FMS), comme ci-après.

[0008] Des dispositifs de type « Route Solver » selon l'anglicisme consacré, qui visent à calculer une route sécurisée vis-à-vis du relief, de la météo. Ce calcul ne prend pas en compte l'état de l'appareil et ses restrictions.

[0009] Des dispositifs de guidage qui visent à calculer une route pour effectuer le guidage de l'appareil. Ces dispositifs guident l'appareil, éventuellement tout en vérifiant la trajectoire active et en déclenchant une alerte vers l'équipage ou une reconfiguration lorsque la situation se dégrade. Ce type de dispositif ne couvre que le plan de vol en cours qui est calculé par le dispositif et non des plans de vol alternatifs.

[0010] Des dispositifs de sécurisation de la trajectoire qui visent à sécuriser la trajectoire selon certaines menaces. Là aussi, ces dispositifs ne prennent généralement pas en compte l'état de l'appareil et ses restrictions.

[0011] Il est aussi connu plusieurs systèmes de type Surveillance, que sont les systèmes d'alerte de trafic et d'évitement de collision (TCAS) pour « Traffic Collision Avoidance System », les systèmes d'avertissement et d'alarme d'impact vis-à-vis du terraine et des obstacles (TAWS) pour « Terrain Awareness and Warning System », les systèmes radar méteo « Weather Radar » ou (ISS) pour « International Space Station ». Ces systèmes ont pour objectif de déclencher des alertes si un aéronef est trop proche d'une situation dangereuse du point de vue respectivement, du trafic, du terrain et de la météo. Ils adressent donc davantage une situation tactique plutôt que stratégique et ils ne permettent pas notamment de traiter une trajectoire/un plan de vol alternatif.

[0012] Avec les différents systèmes de l'état de l'art, lorsqu'un changement de l'état de l'appareil ou un évènement extérieur survient, le pilote doit analyser les informations fournies et déterminer une stratégie d'adaptation de la mission qui lui parait être la meilleure.

[0013] La plupart du temps, le pilote doit se contenter d'analyser un sous-ensemble de données qui lui parait pertinent, car il n'a ni le temps, ni la capacité de reconsidérer le contexte dans sa globalité, les informations étant trop nombreuses. Aussi, le pilote se contente généralement de considérer que, les seuls changements vis-à-vis de la situation initiale, sont ceux ayant déclenché l'analyse. Cependant, cela n'est pas forcément le cas. Par exemple, la météo sur un des aéroports de déroutement possible, peut avoir évoluée entre la préparation du vol et son exécution, et alors rendre la solution de déroutement sur cet aéroport inopérante.

[0014] Enfin, parmi les moyens à sa disposition, outre les systèmes d'alerte ou de surveillance évoqués précédemment, le pilote peut s'appuyer sur la documentation avion de type (QRH) (« Quick Reference Handbook »), soit sous forme papier, soit digitalisée au travers d'un (EFB) (« Electonic Flight Bag »), en vue de chercher les principaux éléments et informations à prendre en compte et à croiser pour faire son analyse de la situation.

[0015] Ainsi, les systèmes d'assistance connus visent à apporter des aides au pilote pour lui permette une analyse de l'impact d'un changement de contexte sur une mission en cours.

[0016] Les approches connues sont en priorité focalisées sur la présentation d'informations à l'équipage. Les brevets, U.S. 10, 096, 253 intitulé "Methods and systems for presenting diversion destinations" et U.S. 10,109, 203 intitulé "Methods and systems for presenting en route diversion destinations", proposent de telles approches. Cependant, elles ne fournissent pas de propositions qui soient basées sur des multicritères.

[0017] De plus, les solutions d'assistance connues sont plutôt basées sur la définition d'un score qui permet au pilote de voir le statut de différents aéroports de déroutement possible, mais elles ne décrivent pas comment réaliser la solution.

[0018] Enfin, les systèmes existants sont soit des systèmes purement avioniques soumis aux contraintes de certification sur le matériel et le logiciel, soit des systèmes dits du « monde ouvert », encore appelés systèmes non-avioniques, c'est-à-dire des systèmes non certifiés (non soumis aux mêmes contraintes de certification que les systèmes certifiés). Les systèmes du mode ouvert couvrent du matériel pouvant accueillir du logiciel non certifié mais soumis à l' « OPS-Approval » par l'opérateur. Le monde ouvert a pour bénéfice d'avoir moins de contraintes de développement, avec des processus de développement et de déploiement plus courts et enfin une possible connexion à des serveurs de type « cloud » pouvant partager des données via les réseaux internet. Dit autrement, en se référant au standard Arinc 811, l'« Avionique » se trouve dans la catégorie « CLOSED », et en opposition le « Monde Ouvert » n'est pas dans la catégorie « CLOSED ».

[0019] Les systèmes avioniques traitent avant tout des aspects tactiques et de sécurité d'un changement de contexte, c'est-à-dire orientés vers une réaction immédiate que le pilote doit avoir, et ils n'analysent pas les conséquences à moyens/longs termes. Même si ces systèmes évoluaient afin d'intégrer des capacités de suggestions, ils se trouveraient vite limités en termes de puissance de calcul et également en termes de capacités de collecte de nouvelles données, notamment du fait que leurs cycles de développement et d'évolution sont des cycles longs, du fait notamment des contraintes de certification.

[0020] Les systèmes monde ouvert (donc non certifiés) ne sont pas connectés à l'avionique. Ils ont donc une vision parcellaire d'une situation courante car ils n'intègrent pas de manière continue l'état de l'appareil et l'évolution de la mission prévue.

[0021] Ainsi, pour permettre à un pilote de prendre une décision, les systèmes actuels ne tiennent pas compte ni de l'ensemble des données provenant de l'aéronef, ni de divers services provenant du monde ouvert. Les informations que le pilote récupère sont alors parcellaires et ne lui permettent pas de prendre une décision avec une vision globale du contexte de vol et du contexte environnemental.

[0022] Aussi, il existe alors un besoin pour des systèmes et des procédés d'assistance avancés qui permettent d'aider un pilote à analyser l'impact d'un changement de contexte sur la mission en cours de l'aéronef.

[0023] De tels systèmes et procédés doivent permettre de corréler l'intégralité des informations qui sont disponibles et permettre de fournir à un pilote, à un équipage, les meilleures options afin de lui/leur permettre de prendre une décision.

Résumé de l'invention

[0024] Un objet de la présente invention est un dispositif d'assistance à un équipage ou « Assistant pilote » qui comprend des moyens permettant d'analyser puis de corréler de manière fiable l'intégralité d'informations pertinentes concernant un appareil, ainsi que son environnement, afin de déterminer si une adaptation d'une situation courante doit être réalisée et, le cas échéant, de proposer des solutions qui apparaissent les plus pertinentes pour cette adaptation.

[0025] Un autre objet de l'invention est un procédé d'assistance au pilotage qui comprend des étapes permettant de récupérer des données de contexte de différentes sources (i.e. avionique de l'appareil, données sol, données monde ouvert) ; de construire un contexte global cohérent ; d'identifier des écarts entre ce contexte et le contexte initial de la mission tel que prévu ; et de résoudre ces écarts en proposant différentes alternatives, afin de permettre au pilote de choisir parmi les alternatives proposées ou d'en étudier d'autres.

[0026] De manière générale, la solution proposée réalise un « Assistant pour équipage » (un ou plusieurs pilotes), afin :

• d'aider à prendre en compte des changements de l'environnement impactant une mission ;
• de réduire le temps passé à mener des activités récurrentes sans grande valeur ajoutée, en préparant et en anticipant certaines tâches ;
• de réduire les erreurs humaines, par la mise en place de rappels et d'une assistance contextualisée ;
• d'aider à répondre aux attentes des passagers et des opérateurs.

[0027] Avantageusement, le dispositif de l'invention est apte à s'adapter à n'importe quelle avionique, sans que les principes et les concepts décrits et utilisés dans les mécanismes de suggestion ne soient affectés.

[0028] Pour obtenir les résultats recherchés, il est proposé un dispositif d'assistance au pilotage d'un aéronef comprenant :

• un module de compétences comprenant une pluralité de composants applicatifs ou capacités, chaque capacité ayant un domaine de compétence et étant configurée selon un même format logique pour calculer des évènements à partir de données acquises de différentes sources de l'avionique certifiée ou de l'avionique non-certifiée et/ou de différentes sources externes ou sources internes à l'aéronef, et pour traiter des requêtes de résolution et générer des propositions de résolution ;
• un module de traitement comprenant des composants configurés pour déterminer l'existence d'un impact sur la mission en cours de l'aéronef, soit à partir d'un évènement calculé, soit à partir d'une proposition de résolution ;
• un module de résolution comprenant des composants configurés pour émettre des requêtes de résolution à partir de l'existence d'un impact, et des composants configurés pour construire une solution d'adaptation de la mission en cours de l'aéronef à partir d'au moins une proposition de résolution;

et

• un module de gestion comprenant des composants configurés pour gérer des contentions et des priorités de flux, et des composants configurés pour aiguiller les échanges entre les différents modules du dispositif.

[0029] Selon des modes de réalisation alternatifs ou combinés :

• Le dispositif comprend de plus un registre de capacités et une base de données de capacités pour enregistrer et stocker le domaine de compétence de chaque capacité.
• Le module de traitement comprend :
  • un composant de contexte configuré pour soit calculer un contexte courant de la mission en cours pour un évènement qui est analysé, soit calculer un contexte résultant de la mission en cours pour une proposition de résolution qui est analysée ;
  • un composant d'écarts configuré pour identifier tout écart entre le contexte initial de la mission de l'aéronef et, le contexte courant ou le contexte résultant ; et
  • un composant d'impact configuré pour déterminer en fonction du ou des écarts identifiés, un impact sur la mission en cours, de l'évènement analysé ou de la proposition de résolution analysée.
• Les composants du module de traitement sont configurés pour effectuer une analyse selon une ontologie.
• Les composants du module de traitement sont configurés pour effectuer une analyse selon des règles prédéfinies.
• Le module de résolution comprend de plus un module de tri pour évaluer et sélectionner des propositions de résolution.
• Le module de tri est configuré pour évaluer et sélectionner des propositions de résolution selon des critères de pondération.
• Le module de compétences comprend au moins une capacité dont le domaine de compétence est celui de la gestion des systèmes avioniques, une capacité dont le domaine de compétence est celui de la gestion de la mission de l'aéronef, et une capacité dont le domaine de compétence est celui de la gestion de l'environnement.
• Le dispositif comprend de plus une interface homme-machine configurée pour gérer les interactions d'un ou plusieurs opérateurs avec les différents modules du dispositif.

[0030] L'invention couvre de plus :

• une plateforme de calcul de l'avionique certifiée, comprenant un dispositif d'assistance au pilotage d'aéronef selon l'invention.
• une plateforme de calcul de l'avionique non certifiée, comprenant un dispositif d' assistance au pilotage d'aéronef selon l'invention.
• une plateforme de calcul comprenant un dispositif d'assistance au pilotage d'aéronef selon l'invention, dans laquelle les modules du dispositif d'assistance au pilotage d'aéronef sont répartis entre l'avionique certifiée, l'avionique non certifiée et une infrastructure sol connectée à l'avionique par une liaison de donnée.

Description des figures

[0031] D'autres caractéristiques et avantages de l'invention apparaîtront à l'aide de la description qui suit et des figures des dessins annexés dans lesquels :

La [FIG. 1] est une illustration simplifiée de l'architecture du dispositif d'assistance au pilotage selon l'invention ;

La [FIG. 2] illustre la structure des composants applicatifs du module de compétence du dispositif d'assistance au pilotage de l'invention ;

La [FIG. 3] illustre les éléments du dispositif d'assistance au pilotage de l'invention mis en œuvre pour déterminer l'existence d'un impact sur la mission d'un aéronef ;

La [FIG. 4] illustre les éléments du dispositif d'assistance au pilotage de l'invention mis en œuvre pour déterminer et générer une suggestion d'adaptation de la mission d'un aéronef;

Les [FIG. 5a], [FIG. 5b], [FIG. 5c] illustrent des variantes d'implémentation du dispositif d'assistance au pilotage de l'invention.

Description détaillée de l'invention

[0032] La figure 1 illustre un exemple d'architecture d'un système d'assistance au pilotage selon l'invention. Le dispositif (100) d'assistance au pilotage d'un aéronef de l'invention comprend généralement au moins un module de compétences (102), un module de gestion (104), un module de traitement (106) et un module de résolution (108).

[0033] Le module de gestion (104) est configuré pour gérer des contentions et des priorités de flux transitant entre différents modules et pour aiguiller les échanges entre les différents modules du dispositif.

[0034] Le dispositif d'assistance au pilotage de l'invention comprend de plus une interface homme-machine IHM (110) configurée pour gérer les différentes interactions homme-machine dans le cadre de l'utilisation du dispositif d'assistance au pilotage de l'invention.

[0035] L'IHM est configurée (i.e. comporte différentes interfaces adaptées au type d'interaction) pour permettre à un ou plusieurs opérateurs d'interagir avec différents modules du dispositif d'assistance ou « Assistant », et avec différents services et/ou composants de l'avionique et/ou du monde ouvert, à bord et/ou au sol.

[0036] Les interactions et informations échangées se font via différentes configurations d'interface que sont, a minima :

• une interface configurée « Opérateur (pilote) / Assistant » pour solliciter l'Assistant de différentes manières (multimodalité): langage naturel, tactile, « Eyes tracking », son/alarme sonore, microgesture, mais également au travers de sollicitations informatiques (notifications).
• une interface configurée « MRO » (« Maintenance Repair & Overhaul ») pour interagir avec un service de maintenance, réparation et révision :
  • Dans le sens MRO → Assistant :
    • Echange des capacités de maintenance par aéroport.
    • « Spare » disponibles par centres.
  • Dans le sens Assistant → MRO :
    • Envoi des pannes détectées.
• une interface configurée « ATC » (« Air Traffic Control ») pour interagir avec le contrôle du trafic aérien :
  • Dans le sens ATC → Assistant, envoi de :
    • « D-NOTAM » de l'anglais « Digital Notice To AirMen » ou format numérique de l'information qui est un message publié par les agences gouvernementales de contrôle de la navigation aérienne dans le but d'informer les pilotes d'évènements (évolutions, fermetures, pannes, travaux, zone interdite, ...) sur les infrastructures. Lors de la préparation d'un vol, le pilote doit les consulter pour assurer la sécurité de sa mission.
    • Consignes ATC.
    • « D-ATIS » de l'anglais « Digital Automatic Terminal Information Service » qui est un service automatique de diffusion permettant aux pilotes de recevoir en continu (nouvel enregistrement généralement toutes les demies heures) des informations sur les aéroports les plus fréquentés. Ces messages peuvent notamment contenir les données Météo, les pistes en service, l'approche disponible, ...
  • Dans le sens Assistant → ATC, envoi de :
    • Signalement de situations météo dangereuses (« windshear » ou vent cisaillant, turbulences, conditions givrantes).
• une interface configurée « Environnement » pour interagir avec des services de météorologie aptes à fournir des données environnementales :
  • Dans le sens Sol → Assistant, envoi de :
    • Météo (« wind », « windshear », temperature, convections, « icing », « ASHTAM » qui est un NOTAM spécial permettant de décrire le statut de l'activité d'un volcan quand celui-ci est de nature à impacter le déroulement/la sécurité des vols, « SNOWTAM » qui est un NOTAM spécial relatif aux conditions d'enneigement des pistes d'un aérodrome, ...).
    • « Weather uplink » (enroute), qui est un message transmis via le Datalink (liaison sol/bord) contenant les informations météo (vents, températures) sur les points de la trajectoire planifiée.
    • « METAR » pour « METeorogical Aerodrome Report » qui est un rapport sur les conditions météorologiques telles qu'observées au sol sur un aérodrome, « TAF » pour « Terminal Aerodrome Forecast » qui est une prévision météorologique valide pour 6 à 30h pour un aérodrome, utilisant un encodage similaire au format METAR, sur les aéroports.
    • Conditions météo sur l'aéroport d'arrivée et les aéroports de déroutement possibles.
    • Etats des pistes d'atterrissage prévues et possibles (niveau de contamination, présence de pluie, neige...).
    • Trafic autour de l'appareil (air + sol).
• une interface configurée « Mission » pour interagir avec des systèmes aptes à fournir des données relatives à la mission de l'aéronef :
  • Dans le sens Avionique → Assistant, envoi de :
    • Plan de vol actif
    • Capacités opérationnelles requises pour la réalisation de la mission (type de décollage, type d'approche...).
    • Temps de vol restant.
    • Fuel à bord
    • Poids
    • Modifications du plan de vol depuis l'avionique
    • Position avion courante
  • Dans le sens Assistant → Avionique, envoi de :
    • Plan de vol suggéré par l'Assistant et choisi par le pilote
    • Facteur de surconsommation carburant (« Perf Factor »)
    • Facteur de dégradation de performances (pertes de poussée, trainée aérodynamique, distance de freinage).
• une interface configurée « Systèmes » pour interagir avec des systèmes aptes à fournir des données relatives à l'état des systèmes de l'aéronef :
  • Dans le sens Avionique → Assistant, envoi de :
    • Liste des systèmes inopérants.
    • Alertes détectées.
    • Actions pilotes sur les procédures « FWS » (« Flight Warning System ».
    • Etats / position de certains systèmes (position des becs et volets, « anti-ice » actif ou non).
  • Dans le sens Application monde ouvert → Assistant, envoi de :
    • Limitations / restrictions identifiées dans le « e-Logbook ».
    • « MEL ».
  • Dans le sens Assistant → Application monde ouvert :
    • Défaillances détectées pour l'e-Logbook.
  • Dans le sens Assistant → Avionique :
    • Restriction du domaine de vol (vitesse, altitude)
    • Actions sur les commandes et timing associé (activation dégivrage...).

[0037] Les données requises par le dispositif de l'invention sont :

• Base de données aéroportuaire (position des aéroports, caractéristiques des pistes, procédures de décollage et d'atterrissage, classification en termes de difficulté (liée au terrain, au trafic)).
• Base de données contenant les altitudes de sécurité.
• Infrastructures associées à l'aéroport (hôtel, centre de réparation, moyens de transport)
• Carte géopolitique et contraintes associées (visa).
• Base de données contenant les associations systèmes inopérant <-> limitations opérationnelles.
• Base de données performances à l'atterrissage / au décollage.
• Base de données consommation.

[0038] Les données échangées avec le sol pour les besoins du dispositif de l'invention sont :

• Suggestions réalisées
• Choix des pilotes
• Contextes associés
• Requêtes pilotes
• Modifications pilotes réalisées sur les suggestions
• Ecart entre suggestions et vol réalisé / données de vol
• Données algorithmiques internes (par exemple, suggestions réalisées sur une version N+1 de l'Assistant « mode ghost »).

[0039] Le module de compétences (102) comprend une pluralité 'n' de composants applicatifs aussi désignés comme capacités (capacité₁, ... capacité_i, ..., capacité_n). Chaque capacité est configurée selon un même format logique pour opérer au moins trois types de fonctions, illustrées sur la figure 2, à savoir :

• déclarer un domaine de compétence (202) ;
• calculer des évènements (204) ;
• traiter des requêtes de résolution et générer des propositions de résolution (206).

[0040] Le module de compétences (102) comprend au moins une capacité « Gestion des systèmes avioniques, une capacité « Gestion de la mission », et une capacité « Gestion de l'environnement ».

[0041] La capacité « Gestion des systèmes avioniques » a pour fonction générale de connaitre le statut de l'aéronef, et ainsi :

• de collecter l'état des systèmes avions depuis la partie avionique.
• de déterminer les limitations opérationnelles en fonction de l'état (réel ou soumis par le pilote après une simulation « what if ») des systèmes avioniques. Un test « what-if » est une simulation de ce qui arriverait si un évènement se produisait.
• de vérifier la compatibilité entre un changement de situation (par exemple : une modification de plan de vol requis par le pilote / induit par un changement de contexte environnemental) et l'état (réel ou soumis par le pilote) de la machine.
• de transmettre des consignes/des objectifs sur les systèmes de l'appareil (changement d'état d'un système, action sur le système).
• de monitorer la bonne exécution de la consigne/la réalisation des objectifs.

[0042] Dans un mode d'implémentation, l'architecture de la capacité « Gestion des systèmes avioniques » s'appuie sur plusieurs composants fonctionnels que sont un « System Management Driver », un « System Management Service » et un « System Management Skill ».

[0043] Le « System Management Driver » est configuré pour exercer le rôle / la fonction d'abstraire l'architecture des utilitaires des systèmes afin de « banaliser » le lien entre un système inopérant et les limitations qui en résultent. En effet, des analyses de FCOM « Flight Crew Operating Manual » menées sur différents porteurs montrent que les limitations opérationnelles sont peu ou prou du même type quel que soit le porteur. Néanmoins, l'architecture des systèmes différant d'un porteur à l'autre, les limitations peuvent être déclenchées par des causes racines différentes (par exemple une panne simple ou double). Par ailleurs, les composants des systèmes ont rarement les mêmes appellations d'un porteur à l'autre. Aussi avantageusement, le module « System Management Driver » permet de s'abstraire de cette problématique en absorbant la variabilité associée. Pour ce faire, chaque système inopérant est associé à une famille de panne et une famille de limitation banalisée, par fichier de configuration.

[0044] Un exemple non limitatif est donné pour la famille de panne moteur « Famille = Engine », pour laquelle il peut être associé une cause racine « Faute = Engine 1 System » et une limitation résultante « Delay Take Off », où les paramètres ne sont plus associés à un aéronef spécifique, et deviennent des paramètres génériques.

[0045] Le composant de « banalisation » permet ainsi d'acquérir toutes les données utiles tout en s'affranchissant des contraintes inhérentes au porteur (nom des données, logiques de sélection de source). C'est le cas par exemple pour des données comme la masse avion, le cap, les fréquences radio, le fuel flow...

[0046] Le « System management Service » est configuré pour exercer plusieurs rôles/fonctions, qui sont :

• de stocker l'état des différents systèmes et données reçus de l'avionique ainsi que différentes autres données. Cet état peut être soit reçu directement d'un FWS (i.e. une liste des systèmes inopérants), soit déduit des actions pilotes sur les procédures (i.e. un système peut par exemple fonctionner correctement mais être coupé pour réduire la consommation électrique, ce qui peut engendrer des limitations). Ce stockage est rendu nécessaire par le fait que les informations reçues peuvent refléter non pas l'état de l'appareil mais les modifications qui lui sont apportées et évoluer dans le temps (par exemple, le fuel à bord qui peut être utilisé en plus de l'information de défaillance pour évaluer l'ampleur/l'évolution d'une fuite carburant. En situation normale, ces informations permettent par exemple de savoir que le pilote a sélectionné une commande particulière qui n'est pas directement retrouvée dans les données d'état de systèmes (un dégivrage activé par exemple)).
• de consolider et calculer l'impact des limitations. A partir de la liste des systèmes inopérants, il établit une liste de limitations (par ex, si deux systèmes en panne génèrent une limitation sur la même capacité - longueur de piste par ex - il produit un résultat global). Pour ce faire, ce composant embarque une mécanique de calcul de logiques/valeurs configurable permettant de définir le traitement à apporter sur des limitations de même nature. Une solution possible est celle fournie par le composant « Détection » du FWS. Suivant les cas, par exemple, les limitations en vitesse peuvent se cumuler ou bien il peut être nécessaire de juste prendre la plus pénalisante.

[0047] Ainsi, sont par exemple identifiés les services suivants (liste non exhaustive) :

• Facteur de surconsommation. Ce facteur permet de dire en fonction de la panne détectée de combien l'appareil va surconsommer par rapport à la normale.
• Longueur de piste nécessaire: Cette information permet de déterminer la longueur nécessaire pour l'appareil pour se poser en fonction de son état, de sa masse et des conditions météo.
• Minimas d'approche: Cette information permet de dire, en fonction de l'état de l'appareil, quel minima est atteignable.
• Réduction de l'enveloppe de vol: Cette information permet d'identifier si, en fonction de son état, l'appareil est limité en altitude, vitesse, roulis et configuration de décollage/atterrissage.

[0048] Le « System management Skill » a pour rôles / fonctions :

• de consolider l'état de l'appareil : A partir des informations produites par le « System Management Service », et une fois qu'il a déterminé que l'appareil est dans un état stabilisé, il génère une notification pour informer des modifications réalisées/subies par l'appareil.
• de vérifier à partir des informations sur l'état des systèmes, si une modification de contexte est compatible du point de vue de l'état de l'appareil (« Check System State Compliance »), comme par exemple une modification du plan de vol pour passer d'un atterrissage CAT3a à une procédure LPV : est-ce que l'appareil peut faire du LPV ? Ce mécanisme est nécessaire pour s'assurer de prendre en compte de manière rétroactive des limitations n'ayant pas eu d'impact ou ayant eu un impact différent lorsqu'elles sont survenues. Par exemple, la perte de la capacité LPV est sans impact si cette capacité n'est pas prévue dans la mission initiale mais rend une modification de plan de vol impossible si celle-ci est requise dans la modification prévue.
• d'interroger la capacité pour évaluer l'impact d'une dégradation fictive soumise par le pilote de l'état de la machine ( « Simulate What If »).

[0049] Le composant « Gestion de l'environnement » a pour fonction de :

• de collecter, capturer, consolider et mémoriser la situation environnementale, les données environnementales via la connectivité sol/bord :
  • venant de l'ATC : D-NOTAM (états des moyens de guidage et de communication, Restrictions de vol), Consignes ATC, D-ATIS (états des pistes, airport services), traffic autour de l'appareil ;
  • venant des services météo : Meteo (wind, windshear, temperature, convections, icing, ASHTAM, SNOWTAM...), météo « enroute », METAR, TAF et états des pistes sur les aéroports de destination et de déroutement possible.
• de vérifier la compatibilité entre un changement de situation (par exemple : une modification de plan de vol requis par le pilote / induit par un changement de l'état de la machine) et le contexte environnemental (vent cisaillant, NOTAMS, etc.)

[0050] La capacité « Gestion de la mission » est en lien avec les applications fournissant les données météo relatives au vol et ainsi a pour fonction :

• de collecter les données mission depuis la partie avionique.
• de vérifier la compatibilité entre un changement de situation (ex : modification de plan de vol requis par le pilote/induit par un changement de contexte environnemental ou bien appareil) et les caractéristiques de la mission (destination, quantité de carburant, profil de vol).
• de déterminer des modifications de la mission susceptibles d'être compatibles avec l'environnement et l'état de l'appareil (réels ou soumis par le pilote : « what if »).
• de transférer les modifications de mission sélectionnées par l'équipage à la partie avionique.

[0051] Dans un mode d'implémentation, l'architecture de la capacité « Gestion de la mission » s'appuie sur plusieurs composants fonctionnels que sont un « FMS Driver », un « Leg Services », un « Mission Skill ».

[0052] Le « FMS Driver » a pour rôle d'abstraire le système de gestion de mission (par exemple un FMS) de l'appareil, et il permet :

• de récupérer des informations sur la mission en cours comme par exemple le plan de vol de la mission en cours, le type d'approche ainsi que la quantité de carburant à bord de l'appareil.
• de transférer des modifications de plan de vol issues des suggestions proposées. Pour ce faire, il convertit les requêtes de résolution reçues au format protocolaire attendu par le FMS présent à bord.

[0053] Le « Leg Services » a pour rôle :

• de stocker le plan de vol courant et de diffuser l'information. Par ce biais, il permet aux différentes capacités et services d'accéder aux données du plan de vol en gérant les accès concurrents aux informations.
• de promouvoir et transmettre vers l'avionique des modifications de mission issues des suggestions. Pour ce faire, le composant s'interface avec le « FMS Driver ».

[0054] Le « Mission Skill » a pour rôle :

• de produire une notification une fois que l'état de la mission est stabilisé. de s'assurer de la conformité de la mission (« Check Mission Compliance ») à un changement de contexte lié à l'environnement (par exemple un détour pour éviter une situation météo dégradée) ou à l'état de la machine (par exemple une surconsommation). Pour s'assurer de la conformité, une simple comparaison est réalisée entre ce qui est prévu et le contexte courant augmenté d'une marge. Aussi, l'accès aux données suivantes de la mission est nécessaire:
  • Temps de vol restant (cas de fuite carburant, dépressurisation par ex).
  • Quantité de carburant, quantité prévue à l'arrivée (fuite de carburant)
  • Catégorie de décollage et d'approche prévue (ILS, GLS, LPV, RNP AR...)
  • Piste prévue et Longueur associée.
  • Altitude de croisière (limitation du domaine de vol)
  • Vitesse horizontale et verticale max (limitation du domaine de vol).
• d'évaluer et de proposer une solution en cas d'évolution du contexte (« Compute Mission Update »). Les éléments non sécurisés (infrastructures sol par exemple) sont utilisés comme critères de tri entre différentes suggestions. Les services suivant sont identifiés comme nécessaires :
  • Ajout d'un délai additionnel: permet d'évaluer la faisabilité (arrivée dans les délais, risque météo) et le coût induit (surconsommation) par un retard.
  • Définition d'un aéroport de diversion en fonction de :
    • Durée de vol maximale (cas de fuite carburant, dépressurisation par ex).
    • De la quantité de carburant (fuite)
    • Des catégories d'approche disponibles (limitation empêchant de réaliser une approche ILS, GLS, LPV, RNP AR...)
    • De la distance d'atterrissage requise (limitations sur le système de freinage).
  • Définition d'un évitement latéral en fonction de :
    • La météo
    • Le fuel à bord
    • L'heure d'arrivée visée
    • Définition d'une modification de plan de vol (vertical ou horizontal) en fonction des restrictions du domaine de vol (vitesse, altitude).

[0055] Selon des variantes de réalisation, le module de compétences peut comprendre d'autres capacités, comme par exemple, de manière non limitative :

• une capacité « ATC » en charge (i.e. son domaine de compétence, sa fonction) de décoder des messages « datalink ATC » ;
• une capacité multimodalité traduisant des consignes ATC - voix ;
• une capacité dont le domaine de compétence (sa fonction) est de récupérer des informations de maintenance ;
• une capacité dont le domaine de compétence (sa fonction) est de capturer les sélections pilotes et de les suivre dans le temps en monitorant les paramètres associés.

[0056] Revenant à la figure 2, avantageusement, le dispositif de l'invention permet, via un registre de capacités (208) couplé à une base de données de capacités (210), l'ajout et/ou le retrait de composants d'applicatifs au module de compétences (102). Chaque composant une fois enregistré selon son domaine de compétence, peut organiser les appels aux différents services et systèmes (avionique ; non-avionique ; sol) respectifs permettant de réaliser les fonctions de calcul d'événement (204) et de traitement de requêtes (206).

[0057] Le domaine de compétence d'une capacité est déclaré dans le registre de capacités (208) et enregistré dans la base de données de capacités (210) afin d'indiquer le domaine fonctionnel du composant applicatif, la nature des données relative à ce domaine fonctionnel, le type/format de données dont la capacité va avoir besoin pour exercer les fonctions de calcul d'événement (204) et de traitement de requêtes (206), et le type/format de données que la capacité va produire.

[0058] La fonction « calcul d'évènement » (204) d'un composant applicatif se charge de consolider les informations reçues avant l'envoi et la sollicitation d'événement à l'Assistant. Il est configuré pour empêcher les sollicitations massives et assurer l'envoi de notifications plus pertinentes. En effet, il faut s'assurer que le contexte conduisant à la notification correspond bien à un état stable. Par exemple, une panne moteur va engendrer la perte de plusieurs systèmes. Cette perte n'est pas simultanée. Il faut donc attendre que la situation soit stable avant de notifier. Le risque si ce n'est pas fait est de déclencher des calculs et des suggestions non pertinentes vers le pilote car prenant en compte seulement une partie de la situation qui n'est pas stabilisée.

[0059] Pour le composant « Gestion des systèmes avioniques », la fonction de calcul d'évènement consiste essentiellement à calculer des limitations opérationnelles de l'aéronef.

[0060] Pour le composant « Gestion de la mission », la fonction de calcul d'évènement consiste essentiellement à générer des données de mission.

[0061] Pour le composant « Gestion de l'environnement », la fonction de calcul d'évènement consiste essentiellement à calculer des évènements météorologiques.

[0062] La fonction « Traiter des requêtes » (206) d'un composant applicatif consiste à recevoir via le module de gestion (104) des requêtes de résolution émises par le module de résolution (108), puis à traiter ces requêtes en sollicitant les services et systèmes appropriés pour récupérer des données, et renvoyer une réponse au module de résolution via le module de gestion.

[0063] Pour le composant « Gestion des systèmes avioniques », la fonction de traitement de requête consiste essentiellement à vérifier l'état des systèmes et faire une simulation « what if » (par exemple quels seraient les impacts sur l'avion si tel système avionique était en panne ? : « j'ai perdu le système 1, j'ai une suggestion de route alternative qui repose sur l'utilisation du système 2, que ce passe t'il si je perds le système 2 ? Si j'ai une autre alternative plus robuste en cas de perte du système 2, il vaut peut-être mieux privilégier celle-ci »).

[0064] Pour le composant « Gestion de la mission », la fonction de traitement de requête consiste essentiellement à vérifier la conformité de la mission, à calculer une mise à jour de la mission et à promouvoir le plan de vol, i.e. fournir le plan de vol vers les systèmes avioniques (FMS notamment) pour acceptation.

[0065] La vérification de la conformité de la mission consiste essentiellement à vérifier que toutes les informations minimales nécessaires au déroulement d'une mission (ex : type d'avion, aéroport de départ et d'arrivée, données de masse et de carburant...) sont disponibles et que la mission est réalisable du point de vue de l'environnement et de l'état de l'appareil, i.e. l'aéronef ne va pas atterrir sur un aéroport avec des vents violents à l'arrivée si l'appareil n'en est pas capable, ni aller se dérouter sur un aéroport qu'on ne peut atteindre faute de fuel suffisant ou en raison d'une altitude trop élevée compte tenu des performances.

[0066] Pour le composant « Gestion de l'environnement », la fonction de traitement de requête consiste essentiellement à vérifier la conformité de la météo, i.e. vérifier que la météo est compatible avec la mission (la mission est réalisable dans les conditions météo prévues sur son trajet, sur les aéroports).

[0067] Revenant à la figure 1, comme indiqué le dispositif de l'invention comprend un module de traitement (106). Le module de traitement est configuré d'une part pour déterminer quels sont les éventuels impacts sur la mission en cours à partir des évènements qui sont calculés par les composants applicatifs (illustré en figure 3), et d'autre part pour effectuer des vérifications de pertinence de solutions qui sont générées par les composants applicatifs pour adapter la mission en cours (illustré en figure 4).

[0068] La figure 3 illustre la configuration des composants du module de traitement (106) mis en œuvre lors du traitement d'un événement, pour déterminer si l'évènement a un impact ou non sur la mission.

[0069] Pour des raisons de simplification de la description et de clarté, un exemple est pris pour la description du traitement d'un événement, qui correspond à la défaillance d'un système par la capacité « Gestion des systèmes ». L'homme du métier généralisera les mécanismes décrits à d'autres évènements et à d'autres composants applicatifs. Ainsi, un autre exemple est celui d'un événement calculé par la capacité « Gestion de l'environnement » correspondant à un changement de météo (le traitement de cet évènement engendrant une proposition de contournement de zone).

[0070] Le module de traitement reçoit en entrée les données routées par le module de gestion (104). Le module de gestion transmet les informations calculées ou émises par les différents modules de compétences, soit lors du calcul d'un évènement (par exemple les valeurs de vents mises à jour dans le cas d'une notification d'évènement météo par la capacité « gestion de l'environnement »), soit lors du traitement d'une requête de résolution (par exemple les impacts sur les capacités de l'avion dans le cas d'une défaillance). Les informations fournies au module de gestion sont calculées à partir de données acquises de différentes sources de l'avionique certifiée et/ou de l'avionique non-certifiée, de sources externes et/ou internes à l'aéronef. Les données sont mises dans un format utilisable par les systèmes du monde ouvert (non avionique).

[0071] Comme illustré sur la figure 3, la capacité « Gestion des systèmes » calcule un évènement à partir d'informations sur l'état des systèmes avions qui sont collectées depuis la partie avionique, et dans l'exemple choisi remontant une « défaillance d'un système ».

[0072] De manière générale, le module de traitement (106) comprend :

• un composant de contexte (302) configuré pour calculer un contexte courant global de la mission en cours sur un évènement qui est analysé ;
• un composant d'écarts (304) configuré pour identifier tout écart / toute différence entre le contexte courant global fourni par le composant de calcul de contexte (302) et le contexte initial de la mission de l'aéronef ; et
• un composant d'impact (310) configuré pour déterminer quel est l'impact de l'évènement sur la mission, en fonction du/des écarts identifiés par le composant d'identification d'écarts (304).

[0073] Dans un mode de réalisation, les traitements réalisés par le module de traitement (106) sont basés sur une analyse selon une ontologie.

[0074] Dans un mode de réalisation, les traitements réalisés par le module de traitement (106) sont basés sur une analyse selon des règles prédéfinies.

[0075] Dans l'exemple choisi, l'impact qui est déterminé consiste en ce qu'un déroutement de l'aéronef est requis ou recommandé.

[0076] La figure 4 illustre les éléments mis en œuvre pour déterminer une suggestion d'adaptation d'une mission. En particulier, la figure 4 illustre les composants du module de résolution (108) et la configuration des composants du module de traitement (106) pour effectuer des vérifications de pertinence de propositions de résolution pour adapter la mission en cours.

[0077] De manière générale, le module de résolution (108) comprend :

• un composant de requêtes de résolution (402) configuré pour construire et émettre des requêtes de résolution pour interroger des composants applicatifs selon leur domaine de compétence et en fonction de l'impact qui a été calculé;
• un composant de tri (410) configuré pour trier des propositions de résolution ; et
• un composant de suggestion (412) configuré pour construire une solution d'adaptation de la mission en cours de l'aéronef selon l'évaluation des propositions de résolution.

[0078] A partir des informations d'impact sur la mission en cours, par exemple un déroutement requis, le composant de requêtes de résolution (402) génère des requêtes correspondantes.

[0079] Les requêtes sont routées vers les capacités devant les traiter via le module de gestion (104), en s'appuyant sur les informations disponibles dans le registre de capacités (208).

[0080] Ainsi, dans l'exemple choisi, des requêtes sont établies pour interroger au moins la capacité « Gestion de la mission » de manière à obtenir des propositions de déroutement vers les aéroports pouvant le proposer. L'homme du métier comprend que l'exemple est simplifié mais que des requêtes de résolution plus ou moins complexes peuvent être adressées à une ou plusieurs capacités selon la nature de l'impact qui a été calculé.

[0081] Les requêtes sont traitées par les capacités respectives à partir de données acquises de différentes sources de l'avionique certifiée ou de l'avionique non-certifiée, de sources externes ou internes à l'aéronef.

[0082] Les propositions de résolution d'impact reçues sont évaluées via le module traitement (106). L'évaluation d'une proposition met en œuvre successivement les fonctionnalités du composant de contexte (404) en calculant un contexte résultant de la mission si la solution de la proposition était implémentée, du composant d'écarts (406) entre le contexte résultant et le contexte initial, et du composant d'impact (408) en déterminant quel serait l'impact sur la mission si la solution de la proposition était implémentée.

[0083] Dans un mode de réalisation, les traitements réalisés par le module de traitement (106) sont basés sur une analyse selon une ontologie.

[0084] Dans un mode de réalisation, les traitements réalisés par le module de traitement (106) sont basés sur une analyse selon des règles prédéfinies.

[0085] Avantageusement, le composant de requête de résolution (402) peut générer de nouvelles requêtes en fonction de l'impact qui a été calculé, et recevoir de nouvelles propositions de solutions qui sont évaluées par le module de traitement (106).

[0086] Le composant de tri (410) est configuré pour pondérer les solutions trouvées, en fonction de critères de tri adaptés à la situation et aux problématiques équipage.

[0087] Avantageusement, en enregistrant les choix pilotes qui sont faits et le contexte associé, les critères de pondération peuvent être adaptés a postériori afin de coller de mieux en mieux à la situation au fil du temps. De plus, en capturant les alternatives effectivement sélectionnées/réalisées, cela permet d'enrichir les connaissances du dispositif en post analyse.

[0088] Le composant de suggestion (412) est configuré pour structurer les suggestions retenues, de manière à pouvoir notifier l'équipage et lui présenter (110) les éléments avec le rationnel associé.

[0089] Dans un mode de réalisation, pour éviter les erreurs, un minimum de trois suggestions est proposé à l'équipage. Avantageusement, l'enregistrement de ces informations permet d'enrichir la recherche de solution qui devient plus performante au fil du temps.

[0090] Une fois l'alternative choisie validée, le dispositif de l'invention permet de transférer les éléments de cette alternative côté avionique, voire côté sol, afin qu'elle devienne la nouvelle référence mission.

[0091] Le dispositif permet de suivre l'exécution de la nouvelle référence afin de détecter les écarts.

[0092] Avantageusement, le dispositif permet de contextualiser l'utilisation des différents services en fonction des politiques des compagnies aériennes et des utilisateurs du système (pilotes).

[0093] La figure 5a illustre un exemple d'implémentation du dispositif d'assistance au pilotage de l'invention où tous les modules sont intégrés sur une plateforme de calcul de l'avionique certifiée.

[0094] La figure 5b illustre un autre exemple d'implémentation du dispositif d'assistance au pilotage de l'invention où tous les modules sont intégrés sur une plateforme de calcul de l'avionique non-certifiée.

[0095] La figure 5c illustre un autre exemple d'implémentation du dispositif d'assistance au pilotage de l'invention où les modules sont repartis entre des plateformes de calcul de l'avionique certifiée, des plateformes de calcul de l'avionique non-certifiée et des plateformes de calcul d'une infrastructure sol. Dans cette implémentation, les composants de traitement et de résolution sont implémentés sur une plateforme de calcul de l'avionique non-certifiée. La plateforme de l'infrastructure sol est connectée à la plateforme avionique par une liaison de données.

Revendications

1. Un dispositif (100) d'assistance au pilotage d'un aéronef comprenant :

- un module de compétences (102) configuré pour enregistrer selon un même format logique des composants applicatifs dits capacités, chaque capacité ayant un domaine de compétence caractérisant son domaine fonctionnel, la nature et le format des données relatives à ce domaine fonctionnel, et étant configurée pour opérer dans son domaine de compétence au moins des fonctions consistant à :

- calculer des évènements à partir de données relatives audit domaine fonctionnel acquises de différentes sources de l'avionique certifiée ou de l'avionique non-certifiée et/ou de différentes sources externes ou sources internes à l'aéronef ;

- traiter des requêtes de résolution d'évènements impactant la mission en cours d'un aéronef, lesdits évènements étant calculés par ladite capacité et/ou par d'autres capacités, lesdites requêtes étant traitées à partir de données relatives audit domaine fonctionnel de ladite capacité acquises de différentes sources de l'avionique certifiée ou de l'avionique non-certifiée et/ou de différentes sources externes ou sources internes à l'aéronef ;

- générer des propositions de résolution d'évènements ;

- un module de traitement (106) comprenant des composants configurés pour déterminer l'existence d'un impact sur la mission en cours de l'aéronef, soit pour un évènement calculé par une capacité , soit pour une proposition de résolution d'évènements générée par une capacité ;

- un module de résolution (108) comprenant des composants configurés pour :

- émettre des requêtes de résolution vers une ou plusieurs capacités du module de compétence,

- évaluer des propositions de résolution d'évènements ;

- construire des solutions d'adaptation de la mission en cours de l'aéronef à partir d'au moins une proposition de résolution d'évènements ; et

- un module de gestion (104) comprenant des composants configurés pour gérer des contentions et des priorités de flux, et des composants configurés pour aiguiller les échanges entre les différents modules du dispositif.

2. Le dispositif selon la revendication 1 comprenant de plus un registre de capacités (208) et une base de données de capacités (210) pour enregistrer et stocker le domaine de compétence de chaque capacité.

3. Le dispositif selon la revendication 1 ou 2 dans lequel le module de traitement (106) comprend :

- un composant de contexte (302, 404) configuré pour calculer soit un contexte courant de la mission en cours de l'aéronef pour un évènement analysé, soit un contexte résultant de la mission en cours de l'aéronef pour une proposition de résolution d'évènements analysée ;

- un composant d'écarts (304, 406) configuré pour identifier tout écart entre le contexte initial de la mission de l'aéronef et, le contexte courant ou le contexte résultant qui est calculé ; et

- un composant d'impact (310, 408) configuré pour déterminer en fonction du ou des écarts identifiés, l'existence d'un impact sur la mission en cours de l'aéronef.

4. Le dispositif selon l'une quelconque des revendications 1 à 3 dans lequel les composants du module de traitement (106) sont configurés pour effectuer une analyse selon une ontologie.

5. Le dispositif selon l'une quelconque des revendications 1 à 4 dans lequel les composants du module de traitement (106) sont configurés pour effectuer une analyse selon des règles prédéfinies.

6. Le dispositif selon l'une quelconque des revendications 1 à 5 dans lequel le module de résolution comprend de plus un module de tri (410) pour sélectionner des propositions de résolution.

7. Le dispositif selon la revendication 6 dans lequel le module de tri (410) est configuré pour sélectionner des propositions de résolution selon des critères de pondération.

8. Le dispositif selon l'une quelconque des revendications 1 à 7 dans lequel le module de compétences comprend au moins une capacité dont le domaine de compétence est celui de la gestion des systèmes avioniques, une capacité dont le domaine de compétence est celui de la gestion de la mission de l'aéronef, et une capacité dont le domaine de compétence est celui de la gestion de l'environnement.

9. Le dispositif selon l'une quelconque des revendications 1 à 8 comprenant de plus une interface homme-machine (110) configurée pour gérer les interactions d'un ou plusieurs opérateurs avec les différents modules du dispositif.

10. Plateforme de calcul de l'avionique certifiée, comprenant un dispositif d'assistance au pilotage d'aéronef selon l'une quelconque des revendications 1 à 9.

11. Plateforme de calcul de l'avionique non certifiée, comprenant un dispositif d'assistance au pilotage d'aéronef selon l'une quelconque des revendications 1 à 9.

12. Plateforme de calcul comprenant un dispositif d'assistance au pilotage d'aéronef selon l'une quelconque des revendications 1 à 9, dans laquelle les modules du dispositif d'assistance au pilotage d'aéronef sont répartis entre l'avionique certifiée, l'avionique non certifiée et une infrastructure sol connectée à l'avionique par une liaison de donnée.

Dessins