FR 3046273 A1 20170630 FR 1502677 A 20151223 3046273 ARCHITECTURE OUVERTE POUR SYSTEME DE GESTION DE VOL Domaine de l'invention L'invention se situe dans le domaine technique des systèmes embarqués, et plus particulièrement dans le domaine technique des systèmes avioniques de type FMS (« Flight Management System »). Etat de la Technique Dans le domaine de l'avionique, les architectures sont généralement définies de manière statique. Par exemple, lors de la conception d'un système de gestion de vol FMS, 15 chaque sous-système avionique temps réel est architecturé et développé pour répondre à des exigences de performances (RAM, ROM, taux de panne, CPU, etc) et de Qualité de Service (QoS) fonctionnelle) dans un cadre d'emploi bien défini. Les interactions entre systèmes (« interactions systémiques ») sont définies a priori lors de l'élaboration de l'architecture 20 avion, et les systèmes sont en général développés et ajustés pour répondre au strict besoin d'interaction telle que défini initialement. Lorsqu'il est nécessaire de faire évoluer l'architecture, les équipements dont les fonctions doivent être modifiées doivent être « qualifiés » à 25 nouveau, ce qui engendre des coûts de certification élevés. L'ajout ou la modification d'une « fonction technique » engendre une requalification très coûteuse (il est requis de prouver à nouveau les performances du système global, et ce même lorsqu'aucune « fonction opérationnelle » n'est modifiée). Une reprise de l'architecture et des interfaces est 30 généralement requise. 2 3046273 Ces reprises et coûts de requalification brident actuellement l'évolution des systèmes embarqués en avionique. L'évolutivité des différents systèmes est de fait limitée dans le temps, car les évolutions d'un système (client ou serveur) ne peuvent pas donner lieu à une remise en 5 cause de l'ensemble des systèmes connectés pour des raisons économiques. Plus largement, ces considérations influent sur la gestion des cycles de développement des matériels et des logiciels embarqués, sur la variabilité et la standardisation des composants, etc. Les rebonds correctifs peuvent être coûteux. L'interconnexion avec de nouveaux 10 systèmes avioniques externes (en sus ou en substitution et non directement compatible avec les précédents) peut entraîner des surcoûts, des risques systémiques et l'introduction de délais supplémentaires. Dans ce cadre général, un des problèmes techniques à résoudre consiste 15 notamment à trouver un moyen d'organiser la mise au point d'une architecture de systèmes de gestion de vol, de manière efficace et économique. Le document de brevet FR2841999 intitulé « SYSTEME DE MISE EN 20 RESEAU ORIENTE OBJET D'EQUIPEMENTS AERONAUTIQUES EMBARQUES » divulgue un système de mise en réseau d'équipements aéronautiques embarqués à bord d'un aérodyne comportant, pour chaque équipement, une interface orientée objet avec des moyens dits façade objet lui permettant d'appréhender l'équipement embarqué auquel elle est 25 affectée, en tant qu'un objet, au sens de la programmation orientée objet, capable de communiquer avec d'autres objets au sens de la programmation orientée objet selon un modèle client/serveur orienté objet et avec des moyens dits observateurs recensant les événements résultants du fonctionnement de l'équipement embarqué. Cette approche 30 orientée objet est intéressante mais présente des limitations. 3 3046273 Il existe un besoin pour des architectures de système de gestion de vol FMS flexibles et évolutives. Résumé de l'invention 5 L'invention concerne un procédé de gestion de données avioniques entre un système de gestion de vol FMS et un ou plusieurs clients, le FMS comprenant des ressources accessibles au travers de services avioniques Ci (1,n); l'exécution des Ci (1,n) déterminant une fonctionnalité avionique Fj (1,m); chacune des Fj (1,m) étant associée à un paramètre 10 d'intrusivité lk et un paramètre de criticité Ck; le procédé comprenant les étapes consistant à recevoir une requête spécifiant l'appel à une Fj (1,m); et à déterminer un droit d'exécution prédéfini d'un Ci (1,n), fonction des paramètres d'intrusivité et/ou de criticité prédéfinis et associés à la Fj (1,m). Des développements décrivent notamment la comparaison des droits d'exécution, la notification d'un rejet, différents services et fonctionnalités avioniques, la gestion de plages de criticité, la prise en compte du contexte de vol, etc. Des aspects de logiciel et de système sont décrits (e.g. équipement de type EFB). Avantageusement, l'invention tire parti de techniques informatiques avancées. Si les techniques informatiques sur lesquelles repose l'invention peuvent être connues de manière individuelle, elles ne le sont pas en combinaison, et a fortiori dans le domaine technique de l'avionique. De manière superficielle, la transposition ou l'adaptation de techniques informatiques connues au domaine de l'avionique peut sembler naturelle et ne pas poser de difficulté majeure; en réalité, il n'en est rien. Le contexte d'application, en l'espèce l'avionique, est très exigeant. De très nombreux paramètres influent sur le choix du design d'une architecture informatique mise en oeuvre dans un aéronef. Les contraintes sont notamment de nature réglementaire, c'est-à dire au moins indirectement de nature technique, puisque la sûreté d'un aéronef 4 3046273 transportant potentiellement des centaines de passagers est une matière technique très complexe. En avionique, les systèmes de gestion de vol F.M.S. (« Flight Management System ») sont certifiés par la F.A.A. (« Federal Aviation Administration »). Si les exigences réglementaires 5 délimitent l'espace des possibles techniques, elles requièrent d'être interprétées techniquement parlant (cette tâche en soi requiert l'exercice d'une activité inventive) et les possibilités techniques « résiduelles » restent très nombreuses. Les développements périphériques autour d'un coeur avionique régulé ou certifié rejoignent fréquemment la situation de 10 « invention de problème » (situation dans laquelle bien poser le problème technique constitue le défi inventif principal). Une analyse erronée de l'activité inventive peut également être effectuée a posteriori. Même si les techniques informatiques sont transversales à de nombreux 15 domaines techniques, l'homme du métier de l'avionique n'est pas pour autant omniscient ou omnipotent, c'est-à-dire à l'initiative et/ou capable d'appliquer l'ensemble de ces techniques à son domaine technique spécifique de l'avionique. En conclusion, l'inventivité de l'application de techniques informatiques, éventuellement connues par ailleurs, au 20 contexte spécifique de l'avionique doit être considérée avec un grand soin. Avantageusement, l'architecture décrite selon l'invention permet de renforcer la sécurité informatique de l'avionique (en particulier) et la 25 sûreté du vol de l'aéronef (en général). De manière générale, l'invention permet de contrôler finement l'accès aux fonctionnalités critiques d'un système de gestion de vol. Les menaces notamment contemporaines sont notamment prises en compte (e.g. sabotage, prise de contrôle partiel, autres formes de piratage). La maîtrise des risques de nature 30 systémique est particulière en matière d'avionique et les choix d'architectures décrits présentement répondent également, outre les 5 3046273 impératifs règlementaires, à ces avantages sécuritaires. Avantageusement et de manière contre-intuitive, le procédé selon l'invention ne considère pas le système de gestion de vol FMS certifié 5 comme un système « monolithique » (au sens d'un système rigide et/ou non-modifiable) mais comme un système qui peut être structuré de manière à permettre une certaine granularité d'accès (certains impératifs notamment liés à la certification ou à la réglementation seront respectés tandis que l'identification de marges de manoeuvre pour d'autres 10 exigences seront exploitées de manière à permettre l'ajout de flexibilité en périphérie de ce système « monolithique »). Les modes de réalisation de l'invention appliquent de manière avantageuse, c'est-à-dire de manière spécifique et contextuelle, les approches consistant à considérer un système donné de manière « atomique » ou selon une approche 15 « objet ». Avantageusement, la classification des fonctions du système de gestion de vol selon leur criticité et/ou intrusivité permet une gestion configurable et flexible. 20 Avantageusement, cette organisation par couches (« découplage », « ségrégation ») permet de réutiliser les capacités avioniques fonctionnelles et/ou techniques offertes par le coeur fonctionnel du système de gestion de vol FMS pour réaliser ou implémenter de 25 nouvelles fonctionnalités avioniques opérationnelles, tout en limitant l'effort d'adaptation requis pour l'implémentation du nouveau modèle d'interaction et/ou des nouveaux protocoles d'entrée/sortie (E/S ou I/O en anglais). Les fonctions (ou données) dites « opérationnelles » d'un système désignent les fonctions (ou les données) d'un système qui 30 rendent un « service » opérationnel (e.g. concret, tangible, mesurable) en réponse à une requête communiquée à ce système (que la requête 6 3046273 émane du pilote directement ou indirectement, ou bien encore d'un système tiers). Les fonctions (ou données) dites « techniques » sont les fonctions (ou les données) qui sont nécessaires pour réaliser une ou plusieurs fonctions de support, telles que le paramétrage, la configuration, 5 la supervision, l'observation et l'injection de données, ou qui sont requises pour l'installation, la configuration du système, son démarrage, mais aussi sa mise au point, sa recette ou encore l'analyse des pannes que ce soit en conditions réelles ou simulées. Les données ou les fonctions peuvent être volatiles (entrées et sorties) ou non volatiles (e.g. stockage des 10 informations de configuration, paramétrage, etc.). Avantageusement, la structuration en couches permet de réutiliser les capacités avioniques fonctionnelles et les capacités avioniques techniques offertes par le coeur fonctionnel du système pour réaliser des nouvelles fonctionnalités avioniques opérationnelles en limitant l'effort 15 d'adaptation à l'implémentation du nouveau modèle d'interaction et/ou des nouveaux protocoles E/S requis dans ce cadre. Par exemple, l'ajout d'une nouvelle fonctionnalité avionique consistant à pouvoir opérer sur des capacités existantes du système à travers un nouveau moyen distant aura des impacts confinés « en périphérie » du coeur fonctionnel. De plus, 20 étant donné que ces nouvelles fonctions opérationnelles n'auront pas, pour certaines, le même niveau de criticité (« safety ») que celui du coeur avionique fonctionnel, il est possible d'appliquer un niveau d'assurance qualité de développement variable sur l'implémentation du nouveau modèle d'interaction et/ou des nouveaux protocoles requis dans ce cadre, 25 par exemple en l'hébergeant dans sa propre partition (A653 par exemple), toujours sans impact sur le coeur fonctionnel dans la mesure où peuvent être réutilisées les capacités fonctionnelles ou techniques existantes, et à la condition où l'accès à ces capacités est ouvert. En d'autres termes, une gestion explicite et rigoureuse de cette ségrégation entre les quatre 30 différentes parties généralement constitutives du système selon l'invention permet d'annuler les impacts potentiels sur le coeur fonctionnel 7 3046273 de changements portant sur une ou plusieurs composantes des trois autres aspects du système (modèle d'interaction, protocoles, systèmes connectés, système d'information, de configuration et paramétrage, plateforme hôte). 5 Avantageusement, le procédé permet de configurer une qualité de service (« QoS », acronyme de Quality of Service) et de gérer les privilèges d'accès des clients, par exemple pour optimiser par classe d'équivalence les efforts de recertification du coeur fonctionnel. 10 Avantageusement, les modes de réalisation de l'invention permettent d'assurer d'avantage l'évolutivité des différentes fonctions opérationnelles ou techniques, et ce de manière indépendante. Par ailleurs, les évolutions sur le coeur fonctionnel du système de gestion de vol FMS ne sont 15 introduites qu'en dernier recours et uniquement lorsqu'une nouvelle capacité algorithmique est requise. Avantageusement, dans un mode de réalisation particulier de l'invention (environnement temps réel embarqué), les sous-systèmes peuvent être 20 associés à des niveaux de criticité différents. Dans ce cadre, il est en effet avantageux de modifier le moins possible les systèmes critiques officiant comme serveurs, compte tenu des coûts et des risques de dégradation des dits systèmes. 25 Avantageusement, la création ou la gestion d'un système séparé pour gérer les fonctions techniques permet d'ajuster au mieux la charge processeur du coeur fonctionnel du système de gestion de vol. Avantageusement, la création ou la gestion d'un système séparé pour 30 gérer les fonctions techniques permet de minimiser la reprise du code du coeur fonctionnel du système de gestion de vol le cas échéant. 8 3046273 Avantageusement, les modes de réalisation de l'invention améliorent la sûreté du vol de l'aéronef en filtrant l'intrusivité de clients dont le niveau de qualification est faible (et qui par exemple risquent d'engendrer des erreurs) 5 Avantageusement, les modes de réalisation de l'invention s'appliquent aux différentes fonctions du calculateur de bord FMS. En système ATA, la « gestion du vol » fait partie de la « navigation » et concerne l'ATA 22 et l'ATA 34. Au sens aéronautique, les systèmes de navigation assurent les 10 services et fonctions de localisation, la planification du vol («Flight Planning »), la gestion de la trajectoire, le guidage de l'aéronef (e.g. asservissements), le pilotage de l'aéronef ainsi qu'une variété de systèmes d'aide à la décision ou d'algorithmes permettant d'optimiser la mission (e.g. choix des aéroports de déroutement les plus adéquats, 15 optimisations de la trajectoire latérale ou verticale pour utiliser les vents favorables, etc). Avantageusement, l'architecture modulaire selon l'invention peut être étendue : ses éléments constitutifs peuvent être distribués dans différents 20 dispositifs avioniques afin d'optimiser en aval les efforts de développement et de certification. Certains modes de réalisation de l'invention permettent par exemple l'interconnexion avec d'autres systèmes externes (par exemple en sus ou en substitution d'équipements existants, qui ne seraient éventuellement pas directement compatibles 25 avec l'existant). Certains modes de réalisation de l'invention permettent la mise en oeuvre de nouveaux modèles et protocoles d'interaction avec le coeur fonctionnel. Des modes de réalisation de l'invention permettent l'introduction de nouvelles fonctionnalités opérationnelles. 9 3046273 Description des figures 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 5 lesquels: La figure 1 illustre l'environnement technique global de l'invention; La figure 2 illustre schématiquement la structure et les fonctions d'un 10 système de gestion de vol de type FMS connu; La figure 3 illustre des aspects d'un mode de réalisation de l'invention ; La figure 4 schématise des exemples de degrés d'intrusivité de 15 différentes fonctionnalités du système de gestion de vol, dérivés de leurs degrés de criticité, selon un mode de réalisation de l'invention ; La figure 5 illustre un mode de réalisation avec des exemples spécifiques de droits d'accès aux différentes fonctions avioniques du FMS ; 20 La figure 6 illustre un exemple de classification des droits d'accès par fonctionnalités avioniques opérationnelles ; La figure 7 illustre un exemple de classification des fonctionnalités 25 avioniques opérationnelles en fonction de leur niveau de criticité (allocation des fonctions par criticité) ; La figure 8 présente un exemple de corrélation entre les niveaux de criticité et les droits d'accès aux services avioniques ; 30 La figure 9 illustre certains aspects d'un mode de réalisation du procédé 10 3046273 selon l'invention ; La figure 10 illustre un exemple de déroulement dynamique du procédé pour une architecture donnée ; et 5 La figure 11 illustre des exemples d'étapes du procédé selon l'invention. Description détaillée de l'invention 10 L'invention décrit notamment différents modes de réalisation d'une architecture ouverte. Cette architecture ouverte est notamment exposée au travers d'interfaces de programmation permettant des accès (selon des modalités variables) aux services avioniques du système de gestion de vol certifié et régulé. 15 Dans un mode de réalisation, l'architecture comprend un système de gestion de vol selon l'invention (FMS « ouvert ») qui comprend quatre parties en interaction : a) un coeur avionique fonctionnel, c'est à dire un sous-ensemble de système qui implémente les services fonctionnels et 20 les services avioniques du système de gestion de vol, b) un modèle d'interaction (et ses déclinaisons) ainsi que des protocoles permettant à un opérateur externe de solliciter le coeur fonctionnel, c) un système d'information permettant de gérer les données ou les connexions et d) la plateforme matérielle d'exécution des différents services. 25 La figure 1 illustre l'environnement technique global de l'invention. Des équipements avioniques ou des moyens aéroportuaires 100 (par exemple une tour de contrôle en lien avec les systèmes de contrôle aérien) sont en communication avec un aéronef 110. Un aéronef est un moyen de 30 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 11 3046273 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), comprenant par exemple un ou plusieurs calculateurs de bord (moyens de calcul, de mémorisation et de stockage 5 de données), dont un FMS, des moyens d'affichage ou de visualisation et de saisie de données, des moyens de communication, ainsi que (éventuellement) des moyens de retours haptiques. Une tablette ou un EFB 122 (« Electronic Flight Bag » pour Cartable électronique) peut se trouver à bord, de manière portative ou intégrée dans le cockpit. Un EFB 10 est parfois dénommé ou décrit comme étant un équipement de type « (monde) ouvert » par opposition aux équipements de type « avionique » (certifié par le régulateur). Ledit EFB peut interagir (communication bilatérale 123) avec les équipements avioniques 121. L'EFB peut également être en communication 124 avec des ressources informatiques 15 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 par 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 20 informatiques connectés 125 ne le sont généralement pas (ou dans une moindre mesure). Cette architecture permet d'injecter de la flexibilité du côté de l'EFB 122 en s'assurant d'une sécurité contrôlée du côté de l'avionique embarquée 121. 25 La figure 2 illustre schématiquement la structure et les fonctions avioniques d'un système de gestion de vol de type FMS connu. Le FMS est généralement connecté à de nombreux autres calculateurs (une centaine), lesquels peuvent également mettre en oeuvre une ou 30 plusieurs étapes du procédé selon l'invention (par exemple, la gestion d'accès conditionnels à des services avioniques granulaires peut 12 3046273 avantageusement consolider des ressources avioniques éparses). Dans les architectures actuelles (quel que soit l'avion), la partie « Flight Planning » et « trajectoire optimisée » est en général incluse dans un calculateur dédié appelé « FMS » pour « Flight Management System » 5 (ou calculateur de gestion du vol). Ces fonctions constituent le coeur de métier « Flight Management ». Ce système peut héberger également une partie de la « Localisation » et du « Guidage ». La figure 2 représente un FMS disposant des fonctions avioniques de : 10 - Navigation LOCNAV, 170, pour effectuer la localisation optimale de l'aéronef en fonction des moyens de géolocalisation (GPS, GALILEO, balises radios VHF, centrales inertielles) ; - Plan de vol FPLN, 110, pour saisir les éléments géographiques constituant le squelette de la route à suivre (procédures de départ et 15 d'arrivée, points de passages (waypoints), airways) ; - Base de donnée de navigation NAVDB 130, pour construire des routes géographiques et des procédures à partir de données incluses dans les bases (points, balises, legs d'interception ou d'altitude...) ; - Base de données de performance, PRF DB 150, contenant les 20 paramètres aérodynamiques et moteurs de l'appareil. - Trajectoire latérale TRAJ, 120: pour construire une trajectoire continue à partir des points du plan de vol, respectant les performances avion et les contraintes de confinement (RNAV, RNP ...) ; - Prédictions PRED, 140: pour construire un profil vertical optimisé sur la 25 trajectoire latérale ; - Guidage, GUID 200, pour guider dans les plans latéraux et verticaux l'aéronef sur sa trajectoire 3D, tout en optimisant la vitesse ; - Liaison de donnée numérique DATALINK, 180 pour communiquer avec les centres de contrôle et les autres aéronefs. 30 - Fonctions techniques, 210 pour gérer les aspects non-fonctionnels du FMS : observabilité, DUAL, enregistrement des pannes, démarrage, 13 3046273 mode simulation, flight tests ... - La gestion de l'interface homme machine (pilote) IHM 220. Les fonctions du système de gestion de vol FMS peuvent être classées 5 dans neuf types de fonction (F1 à F9). Dans l'exemple qui est illustré, la fonction F1 (interface Homme Machine) est implémentée au bloc 220 (IHM). La fonction F2 correspond au guidage automatique de l'aéronef et est implémenté dans le bloc 200 (GUIDANCE). La fonction F3 qui correspond à la surveillance et au monitoring du vol et de la trajectoire est 10 implémentée dans le bloc 110 (FPLN), 120 (TRAJ) et 140 (PRED). La fonction F4 qui correspond à la relation avec le trafic aérien et les centres de contrôle opérationnel est implémentée dans le bloc 180 (DATALINK). La fonction F5 qui correspond aux outils d'aide à la décision stratégique, à l'optimisation du vol est implémentée dans les blocs 120 (TRAJ) et 140 15 (PRED). La fonction F6 qui correspond à la simulation de vol est implémentée dans le bloc 210 (TECH FCT). La fonction F7 qui correspond à la maintenance et à la mise en condition opérationnelle est implémentée dans le bloc 210 (TECH FCT). La fonction F8 qui correspond à la mise au point sol & vol est implémentée dans le bloc 210 20 (TECH FCT). La fonction F9 qui correspond à l'analyse de pannes et enregistreur de vol est implémentée dans le bloc 210 (TECH FCT). Différents modes de réalisation de l'invention sont décrits-après. Il est divulgué un procédé de gestion de données avioniques entre un 25 système de gestion de vol FMS et un ou plusieurs clients dudit FMS, le système de gestion de vol FMS comprenant des ressources physiques accessibles au travers de services avioniques Ci (1,n); l'exécution d'un ou de plusieurs services avioniques Ci (1,n) déterminant une fonctionnalité avionique Fj (1,m); chaque fonctionnalité avionique Fj (1,m) étant 30 associée à un paramètre d'intrusivité lk et un paramètre de criticité Ck; le procédé comprenant les étapes consistant à recevoir une requête depuis 14 3046273 un client, ladite requête spécifiant l'appel à une fonctionnalité avionique Fj (1,m); et déterminer un paramètre associé à un droit d'exécution prédéfini d'un service avionique Ci (1,n), ledit paramètre étant fonction des paramètres d'intrusivité et/ou de criticité prédéfinis et associés à ladite fonctionnalité avionique Fj (1,m) Les paramètres d'intrusivité et/ou de criticité sont associés à une fonctionnalité du système de gestion de vol. 10 Le procédé selon l'invention découple le système de gestion de vol des clients de ce système. L'« interface de découplage » se fait par gestion d'une couche intermédiaire entre le FMS et le client, autorisant ou interdisant les appels 15 aux ressources informatiques. Dans un mode de réalisation, la gestion des accès aux ressources est « binaire »: l'accès est autorisé ou il ne l'est pas. 20 Dans un mode de réalisation de l'invention, la gestion des accès régis par une ou plusieurs priorités (prédéfinis ou définies dynamiquement). Dans un mode de réalisation de l'invention, le procédé de permet une gestion active des accès aux ressources. La gestion active peut 25 comprendre un mécanisme d'inhibition (e.g. diminution de la priorité associée, pondération défavorable) et/ou par un mécanisme de promotion (e.g. augmentation de la priorité associée, pondération favorable, etc.) Selon un aspect de l'invention, la définition et la considération de 30 différentes couches d'abstraction permet une gestion optimisée des ressources matérielles et/ou logicielles. Les ressources matérielles 15 3046273 hardware sont accédées par des codes unitaire FMS, lesquels définissent des « fonctionnalités » FMS. Ces fonctionnalités sont appelées par une ou plusieurs requêtes d'un ou de plusieurs clients du système de gestion de vol FMS. 5 Dans un développement, le procédé comprend en outre l'étape consistant à comparer le paramètre de droit d'exécution déterminé avec un ou plusieurs droits d'exécution prédéfinis. 10 Le procédé comprend une étape consistant à déterminer une matrice de droits d'exécution Di d'un service Ci par une fonctionnalité Fi en fonction des paramètres d'intrusivité et/ou de criticité. Lorsqu'un client commande l'exécution d'une fonction à destination du coeur numérique, l'interface de découplage vérifie les droits d'exécution 15 Dans un développement, le procédé comprend en outre une étape consistant à exécuter un ou plusieurs services avioniques et communiquer le résultat au client. 20 Dans un développement, le procédé comprend en outre l'étape consistant à notifier le client du rejet de sa requête. Dans un développement, un service avionique correspondant un service avionique sélectionné parmi un service avionique d'accès au système 25 d'information du coeur fonctionnel du FMS, un service avionique de gestion ou d'administration de plan de vol, un service avionique d'accès aux données d'un plan de vol ou d'une trajectoire de l'aéronef. Dans un développement, un niveau de criticité étant sélectionné parmi une pluralité de plages de criticité prédéfinies. 30 Dans un développement, la pluralité de plages de criticité comprenant quatre plages de criticité prédéfinies, lesquelles comprennent un niveau 16 3046273 de criticité X1 strictement supérieur au niveau de criticité du coeur fonctionnel FMS, le niveau de criticité X2 égale au niveau de criticité du coeur fonctionnel FMS, le niveau de criticité X3 strictement inférieur au niveau de criticité du coeur fonctionnel FMS et le niveau de criticité X4 5 très inférieur au niveau de criticité du coeur fonctionnel FMS. La définition de quatre classes de criticité se révèle avantageuse dans la pratique aéronautique opérationnelle. En d'autres termes, il existe un optimum de quatre clients implémentant les interactions avec des 10 systèmes externes pour réaliser des sous-ensembles de fonctionnalités avioniques homogènes par client, en termes de criticité, comme en termes de droits d'accès. Dans un développement, une fonctionnalité avionique est sélectionnée 15 parmi les fonctionnalités avioniques comprenant une fonctionnalité d'interface Homme Machine FI, une fonctionnalité de Guidage automatique de l'aéronef F2, une fonctionnalité de Surveillance et monitoring du vol et de la trajectoire F3, une fonctionnalité de Relation avec le trafic aérien et les centres de contrôle opérationnel F4, une 20 fonctionnalité de Outils d'aide à la décision stratégique ou à l'optimisation du vol F5, une fonctionnalité de Simulation de vol F6, une fonctionnalité de Maintenance et mise en condition opérationnelle F7, une fonctionnalité de Mise au point sol & vol F8, une fonctionnalité de Analyse de pannes et enregistreur de vol F9. 25 Dans un développement, une fonctionnalité avionique est accédée et/ou exécutée par une ou plusieurs interfaces utilisateurs (ou IHM pour « Interface Homme-Machine ») selon un modèle d'interaction prédéfini. Une fonctionnalité avionique utilise avantageusement un modèle 30 d'interaction exécutant une ou plusieurs interfaces (utilisateur ou IHM au sens large) spécifiquement appelées par un opérateur externe et exploitant un ou plusieurs services avioniques du coeur fonctionnel. 17 3046273 Un modèle d'interaction réalise un ensemble de principes, de règles et de propriétés qui régissent le fonctionnement d'une interface Homme- Machine. Une IHM peut être par exemple une interface graphique, mais pas seulement. Une IHM peut combiner différentes modalités de 5 restitution et d'interactions sonores, visuelles ou autrement sensorielles (toucher, retour de force, Braille, voire olfactif, etc). Une IHM peut être en 2D, en 3D, avec ou sans retours haptiques, etc). Un modèle d'interaction est généralement prédéfini (c'est-à-dire déterminé à la conception de l'interface). Un modèle d'interaction correspond 10 généralement à la généralisation d'une interface utilisateur; les différentes déclinaisons du modèle d'interaction correspondent notamment à des contextes d'utilisation prédéfinis (i.e. succession spécifiques d'écrans d'affichage, types de symboles affichés, priorités spécifiques allouées à certains types d'information, etc), qui peuvent notamment être fonction du 15 contexte de vol. Le modèle d'interaction avionique prédéfini selon l'invention est choisi parmi les modèles d'interactions comprenant un modèle d'interaction homme-machine (de manière générique) et/ou un modèle d'interaction comprenant le guidage automatique de l'aéronef (lequel peut impliquer une interface spécifique) et/ou la surveillance de 20 bord, un modèle interaction dit ATM- Airlines Operation Center et/ou un modèle d'interaction dit Simulation-Maintenance-Mise au point-Analyse de Pannes (lequel correspond à un contexte spécifique comme son nom l'indique). 25 Dans un développement, les paramètres d'intrusivité et/ou de criticité sont configurables. Des droits d'accès sont associés à chacune de ces fonctionnalités opérationnelles. Ces droits autorisent ou non pour la famille concernée 30 l'utilisation d'un sous-ensemble des capacités et la manipulation d'un sous-ensemble des données du coeur fonctionnel. La famille 18 3046273 d'appartenance d'un système connecté est une information configurable (par le pilote et/ou la compagnie et/ou un système avionique tiers) Dans un développement, un ou plusieurs paramètres d'intrusivité et/ou de 5 criticité sont fonction du contexte de vol. Le contexte de vol de l'aéronef comprend notamment les phases de décollage, montée, croisière, approche, descente, etc. Avantageusement, la prise en compte du contexte de vol pour déterminer l'intrusivité et/ou la 10 criticité des accès au coeur avionique permet d'en optimiser l'usage et les performances. Le procédé selon l'invention peut comprendre des procédés logiques ou des étapes permettant de déterminer le "contexte de vol" ou " contexte de 15 vol courant" de l'aéronef. 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 20 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 25 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). 30 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 19 3046273 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 5 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 10 les besoins en matière d'interaction homme-machine (e.g. délai d'interaction minimal ou maximal, quantité de mots minimale et maximale, etc). Il peut également subsister des règles spécifiques dans certains contextes, notamment d'urgences ou de situations critiques. Les catégories de contextes peuvent être statiques ou dynamique 15 (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, 20 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 25 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 30 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 20 3046273 (logique formelle, logique floue, logique intuitionniste, etc) Différentes régulations du système selon l'invention sont possibles, de manière supervisée (par exemple contrôlée par un opérateur) ou de 5 manière non supervisée (par exemple paramétrée initialement). Dans un mode de réalisation, un ou plusieurs mécanismes d'apprentissage (« machine learning ») peuvent réguler les accès au coeur avionique (par exemple par inhibition ou promotion de certaines interactions et/ou clients). Dans certains modes de réalisation, la régulation des accès au 10 coeur avionique FMS peut comprendre des schémas d'interaction actif/passif, des mécanismes de votes (entre pairs), etc. Il est divulgué un produit programme d'ordinateur, ledit programme d'ordinateur comprenant des instructions de code permettant d'effectuer 15 une ou plusieurs des étapes du procédé, lorsque ledit programme est exécuté sur un ordinateur. Il est divulgué un système comprenant des moyens pour mettre en oeuvre les étapes du procédé. 20 Dans un développement, le système comprend un système de gestion de vol FMS et un ou plusieurs clients dudit système de gestion de vol FMS. Dans un développement, le système comprend au moins un sac de vol 25 électronique de type EFB. En effet, dans un développement de l'invention, le système pour la mise en oeuvre du procédé comprend au moins un équipement de type « monde ouvert ». Un équipement du monde ouvert peut être par exemple un sac de vol électronique (EFB ou tablette). Cet équipement de type « monde ouvert » peut d'ailleurs être 30 physiquement en dehors du cockpit : par exemple, le personnel commercial peut accéder à certains services au travers des APIs selon 21 3046273 les modalités de l'invention. Dans d'autres modes de réalisation, des passagers peuvent aussi accéder à certains services (de même que des services au sol). 5 La figure 3 illustre des aspects d'un mode de réalisation de l'invention. Il est divulgué un dispositif de dialogue entre un système de gestion de vol « FMS OPEN » et au moins un client externe audit système de gestion du vol, incluant une « interface de découplage » entre le système 10 de gestion du vol et le client. Un client 320 du FMS « ouvert » 310 comprend au moins une fonctionnalité avionique caractérisée par au moins un paramètre d'intrusivité et un paramètre de criticité. 15 La notion d'"intrusion" témoigne d'une manifestation de volonté de réserver l'accès à des ressources physiques ou logiques à certains systèmes préalablement désignés. La notion d'intrusion présuppose également le franchissement d'une ou de plusieurs limites d'un système 20 prédéfini. Le terme "intrusivité" se réfère à ce terme "intrusion", auquel il associe une quantification (e.g. différentes gradations). En d'autres termes, il n'est pas fait confiance a priori aux différents systèmes tiers connectés au système de gestion de vol. Dans un mode de réalisation de l'invention, tout système tiers connecté est susceptible de compromettre 25 (ou de corrompre ou de causer tout autre type de panne ou de défaillance ou de surcharge) du coeur avionique. Dans un mode de réalisation de l'invention, il est accordé pleine confiance à tout système tiers connecté. Dans des modes de réalisation intermédiaires, la confiance accordée à système tiers connecté est variable; cette confiance et donc les droits 30 d'accès associés pouvant notamment évoluer au cours du temps ("timedriven") et/ou en fonction d'événements ("event-driven") 22 3046273 En mathématiques, la valeur prise par une fonction en un point critique s'appelle une valeur critique. Un point critique sert d'intermédiaire pour la recherche d'extremum d'une fonction. En informatique, un système critique est un système dont la panne peut avoir des conséquences 5 graves, incluant des pannes ou des dégâts matériels significatifs (avec un impact sur la sûreté du vol de l'aéronef). La notion de "criticité" introduit également une quantification de ce caractère critique en y associant différent "étages" ou "stades" ou "attributs" ou "niveaux". 10 Selon l'invention, avantageusement en matière de gestion des risques, le croisement des niveaux de « criticité » et d' « intrusivité » permet d'architecturer un système avionique à la sécurité et à la sûreté améliorée. 15 Le système de gestion du vol (« ouvert ») 310 est constitué d'un coeur numérique avionique 311 (« Coeur fonctionnel »), d'une façade 312 (« OPEN API SERVER »), ladite façade comprenant une liste de services avioniques typés, c'est-à-dire dont la structure et les fonctions sont connues. 20 L'interface de découplage 320 comprend un système d'information 321, un « modèle et protocoles d'interaction » 322 et une plateforme d'exécution 323. 25 Le système d'information 321 offre i) les mécanismes de stockage et le lieu de stockage des informations de configuration (modes et options générales de fonctionnement) et/ou de paramétrage (données fonctionnelles non volatiles), ii) les données fonctionnelles en entrée et/ou en sortie du système (données fonctionnelles volatiles), iii) le type et/ou le 30 nombre de systèmes connectés ainsi que les protocoles d'échange associés et iv) le format physique d'échanges d'information (I/O) entre le 23 3046273 système ou les différents systèmes connectés. Le modèle d'interaction 322 et les protocoles employés par cet opérateur externe permettent de solliciter les fonctions opérationnelles du système 5 et les fonctions de support (paramétrage, téléchargement, observation, injection de données). Par exemple, l'interface utilisateur peut être implémentée localement dans le système avionique ou bien accessible depuis un autre système distant. Par suite, plusieurs interfaces utilisateur sont possibles simultanément (ou bien il peut exister plusieurs instances 10 différentes de la même interface). L'interface de découplage 322 calcule une matrice des droits d'exécution d'un service avionique par une fonctionnalité en fonction des paramètres d'intrusivité et un paramètre de criticité. Lorsqu'un client commande 15 l'exécution d'une fonction avionique à destination du coeur numérique, l'interface de découplage vérifie les droits d'exécution. Si les droits sont accordés, l'interface de découplage commande l'exécution des services avionique par ladite façade, et éventuellement notifie le client du résultat. Si les droits ne sont pas accordés, l'interface de découplage notifie 20 éventuellement le client du rejet. Le coeur avionique fonctionnel 311 implémente les capacités avioniques fonctionnelles et techniques qui sont stables, nécessaires et suffisantes pour les fonctionnalités opérationnelles. Le coeur avionique fonctionnel du 25 système 311 est le sous-ensemble du système qui implémente a) les capacités avioniques fonctionnelles nécessaires pour réaliser les fonctions dites « opérationnelles » (celles qui rendent un service opérationnel à un opérateur externe agissant sur le système, quel que soit le procédé employé pour agir sur le système) et b) les capacités 30 techniques avioniques nécessaires pour réaliser les fonctions de support telles que le paramétrage, la configuration, la supervision, l'observation et 24 3046273 l'injection de données, qui sont requises pour l'installation, la configuration du système, son démarrage, mais aussi sa mise au point, sa recette ou encore l'analyse des pannes (que ce soit en conditions réelles ou simulées). La plateforme d'exécution 323 comprend des aspects de matériel (instructions, gestion des caches, adressage physique des ressources mémoire et I/O) et des aspects de logiciel (système d'exploitation, drivers d'entrées/sorties, adressage logique, etc). Dans un mode de réalisation, le procédé utilise une exposition du coeur avionique fonctionnel 311 du FMS au travers d'une ou de plusieurs interfaces de programmation (APIs) 3121 accessibles depuis un serveur d'APIs 312. 15 En informatique, une interface de programmation (souvent désignée par le terme API pour "Application Programming Interface") est un ensemble normalisé de classes, de méthodes, de fonctions, de types de données et de constantes qui sert de façade par laquelle un logiciel offre des services 20 à d'autres logiciels. Une interface de programmation est généralement offerte par une bibliothèque logicielle ou un service web, le plus souvent accompagnée d'une description qui spécifie comment des programmes consommateurs peuvent se servir des fonctionnalités du programme fournisseur. Une API peut être « privée », c'est-à-dire destiné à un usage 25 de développement informatique réalisé en interne. Une API peut être « ouverte » ou « publique » (« open API » en anglais) : les spécifications de l'interface peuvent être publiées i.e. accessibles au public et notamment à des développeurs tiers. 30 Au sens de l'invention, une « API ouverte » correspond à l'exposition (au moins partielle) d'une fonction (concrète) avionique et/ou d'une 5 10 25 3046273 fonctionnalité (théorique) avionique, dans le contexte particulièrement spécifique de l'avionique, secteur régulée i.e. dont les services sont certifiés. En d'autres termes, une API ouverte selon l'invention est décrite, accédée, exécutée et éventuellement protégée selon des modalités tout à 5 fait particulières et propres au secteur avionique. Selon l'invention, une API (interface de programmation) d'accès au coeur fonctionnel du FMS peut être définie au regard des capacités fonctionnelles et techniques du FMS plutôt qu'au regard du mode 10 opératoire et des scénarios opérationnels. Dans un mode de réalisation, les capacités du coeur fonctionnel FMS sont exposées à travers une ou plusieurs APIs explicites (c'est-à-dire documentées, par exemple publiées) et utilisables par des clients tiers. 15 Selon les modes de réalisation, la documentation ou la description des interfaces de programmation est plus ou moins complète, de manière propre au secteur avionique. En d'autres termes, dans certains modes de réalisation, la description des services avioniques est complète et 20 exhaustive. Dans d'autres modes de réalisation, la description ou la documentation n'est que partielle (certaines commandes non publiées ou chiffrées à dessein permettent d'obtenir certaines informations depuis le FMS, par exemple des informations particulièrement critiques). Dans un mode de réalisation, la description des services avioniques est 25 accessible sur demande. Dans un mode de réalisation, la description complète d'un service avionique est chiffrée c'est-à-dire que l'existence d'une documentation est apparente mais que l'accès à son contenu requiert un secret partagé préalable. Dans un mode de réalisation, la description et/ou l'existence d'un service avionique est dissimulé (à 30 l'instar de la stéganographie). 26 3046273 Concernant l'accès aux interfaces de programmation des services avioniques, les permissions ou restrictions d'accès aux différentes API peuvent être spécifiques. L'accès à un service avionique donné peut être configurable, par exemple en matière de tarif, de quantité d'appels 5 (volumes), de qualité de service (e.g. priorités). Dans un mode de réalisation, les accès peuvent être « gratuits », illimités en volume et sans restrictions d'accès. Dans d'autres situations, l'accès à certaines fonctions du FMS peut être limité (quantité, qualité) par des restrictions d'accès (contrôle d'accès, clefs, chiffrement, priorités absolues et/ou relatives). 10 Certains modes de réalisation de l'invention peuvent combiner l'utilisation d'APIs de type « publique » (e.g. publiées) avec l'utilisation d'APIs de type « privée » (e.g. certains avantages ou privilèges peuvent être réservés au développement interne ou à des partenaires aéronautiques sélectionnés). 15 En particulier, le cycle de vie d'une API peut donner lieu à des développements divers (e.g. la stabilité de certaines APIs peut être garantie tandis que d'autres pourront être dépréciées « deprecated API »). 20 Dans un mode de réalisation, au moins une API est ouverte et accessible depuis une autre partition ou un autre calculateur, pour assurer la distribution des différents éléments constitutifs de l'application FMS, notamment les parties traitant du système d'information et des différents procédés d'interaction avec le coeur fonctionnel. En d'autres termes, la 25 gestion de la redondance propre à l'avionique (système dual, triplication, mécanisme de vote) peut être combinée à la gestion des droits accès. Selon les modes de réalisation, différents sous-ensemble des capacités fonctionnelles et techniques du coeur FMS peuvent être exposés aux 30 clients au travers des « APIs » telles que définies ci-avant. Ces capacités fonctionnelles et techniques de nature avionique 27 3046273 comprennent notamment: - L'accès au système d'information du coeur fonctionnel (C1 a), à savoir a) les données de configuration du système (modes et options de 5 fonctionnement), b) les données de paramétrage (base de données de navigation, ...), c) les données caractéristiques en entrée ainsi que les données et états consolidés par le coeur fonctionnel. - L'accès aux données du plan de vol (C1 b), la trajectoire 3D et les 10 prédictions associées pour tous les plans de vol manipulés par le coeur fonctionnel ; - Les services d'administration de plan de vol (C2a), par exemple la création, suppression, réplication de plans de vol; - Les services d'édition de plan de vol (C2b), suivant une granularité variable, depuis un point de plan de vol « waypoint » jusqu'à un ensemble de points de plan de vol comme une procédure de navigation ou une « company route » La figure 4 schématise des exemples de degrés d'intrusivité de différentes fonctionnalités du système de gestion de vol, dérivés de leurs degrés de criticité, selon un mode de réalisation de l'invention. 25 Le périmètre des fonctionnalités avioniques d'un FMS peut varier durant la vie d'un même aéronef. Ces fonctionnalités avioniques mettent en effet en jeu plusieurs systèmes connectés ainsi que les propriétés de ces systèmes connectés (interface, protocole de communication, modèle d'interaction). A fortiori, les fonctionnalités avioniques du FMS évoluent 30 d'une génération d'aéronef à une autre. Ces fonctionnalités ont un niveau de criticité propre (sûreté) et requièrent des niveaux d'intrusivité dans le 15 20 28 3046273 coeur fonctionnel parfois très différents. Dans un mode de réalisation, la variabilité des différentes fonctionnalités (existantes ou à venir) du coeur fonctionnel est « confinée ». Le coeur 5 fonctionnel est alors « unique » et « réutilisable » (ce qui permet des économies d'échelle significatives). Plus généralement, les différentes générations d'appareils peuvent conduire à des structurations particulières des couples criticité/intrusivité. 10 La classification des fonctions du système de gestion de vol selon leur criticité et/ou intrusivité permet une gestion configurable et flexible. Par exemple, pour utiliser les capacités offertes par une ou plusieurs APIs, les privilèges par client et plus généralement la qualité de 15 service peuvent être configurables (i.e. configurés). Dans un mode de réalisation, les droits d'accès conférés ou associés à un client du FMS peuvent être fonction des fonctionnalités opérationnelles concernées. Ces droits peuvent autoriser - ou non - pour la famille 20 concernée l'utilisation d'un sous-ensemble des capacités du FMS et la manipulation d'un sous-ensemble des données du coeur fonctionnel du FMS. De manière générale, la famille d'appartenance (déterminant les 25 propriétés d'accès) d'un système connecté donné au système de gestion de vol FMS est configurable. Les droits ou propriétés d'accès peuvent être statiques. Les droits d'accès peuvent aussi être dynamiques, c'est-à-dire évolutifs au cours du temps et/ou en fonction d'événements de vol (par exemple en fonction des phases de vol, i.e. du contexte de vol). 30 Dans certains modes de réalisation, des scénarios prédéfinis déterminent au moins partiellement les différents droits d'accès (e.g. décrochage, 29 3046273 situation d'urgence, régime de croisière, décollage/atterrissage). (Élucubration à vérifier, supprimer ou modifier) Les droits d'accès peuvent concerner l'accès aux services avioniques et/ou aux interfaces de 5 programmation desdits services avioniques. En d'autres termes, l'accès à un service avionique proprement dit et l'accès à la documentation de ce même service peuvent être considérées de manière indépendante. Par exemple, un client peut éventuellement avoir accès à tous les services avioniques disponibles mais sans en connaître les descriptions 10 correspondantes de manière détaillée (autrement que ce qui est strictement nécessaire pour l'exécution des services avioniques). A l'inverse un client peut avoir accès un unique service avionique mais en connaître totalement le périmètre (e.g. les limites par exemple en matière de précision de calcul, les capacités en charge, la tolérance en matière de 15 requêtes mal formées, l'existence de commandes spéciales ou d'urgence, etc) Avantageusement, les différents modes de réalisation de l'invention permettent d'obtenir des architectures distribuées, évolutives et optimales 20 en termes d'effort de développement et de certification des différentes fonctionnalités, au regard des différents niveaux de criticité des fonctions opérationnelles implémentées. Dans un mode de réalisation, la criticité des fonctionnalités s'entend au sens de la certification (safety en anglais). Ces fonctionnalités opérationnelles (mettant en jeu plusieurs systèmes 25 dont le FMS) peuvent se décomposer en i) fonctionnalités correspondant à la mise en oeuvre de capacités fonctionnelles ou techniques du coeur fonctionnel ii) fonctionnalités permettant la mise en oeuvre des clients implémentant le ou les modèles d'interaction et les protocoles de communication avec le ou les systèmes connectés, pour une ou plusieurs 30 fonctions opérationnelles. Concernant i), la mise en oeuvre de capacité fonctionnelle ou technique 30 3046273 du coeur fonctionnel est implémentée par le coeur fonctionnel donc hérite du niveau de criticité associé aux capacités fonctionnelles du coeur fonctionnel. 5 Concernant ii), l'implémentation des clients de l'API ou Open API hérite du niveau de criticité de la fonctionnalité opérationnelle devant être réalisée. Dans un mode de réalisation de l'invention, les clients peuvent donc avoir accès à des partitions dédiées. 10 Avantageusement, les coûts de développement sont potentiellement moindres si le niveau de criticité est inférieur à celui du coeur fonctionnel. Des crédits de certification sont maintenus et les coûts de mise en oeuvre demeurent faibles si aucune nouvelle capacité fonctionnelle ne devient requise et/ou si le domaine d'utilisation du coeur fonctionnel est respecté. 15 La figure 5 illustre un mode de réalisation avec des exemples spécifiques de droits d'accès aux différentes fonctions avioniques du FMS. Dans l'exemple, la famille F4 (relations avec le trafic aérien et les centres 20 de contrôle opérationnel) 501 peut éditer le plan de vol au travers de l'accès aux API ouvertes 510, tandis que la famille F9 (analyse de panne et enregistreur de vol) ne le peut pas. La figure 6 illustre un exemple de classification des droits d'accès par 25 fonctionnalités avioniques opérationnelles. Les droits peuvent être: - de lecture ou de simple consultation de données (Dl 601; « READ ONLY »). Dans l'exemple fourni, ce droit de consultation des données en lecture seule est restreinte aux seules capacités FMS Cl a et Cl b ; - d'écriture ou d'édition, par exemple du plan de vol privé (D2 602 ; RD, 30 « WRITE » sur donnée privée). Dans l'exemple fourni, ce droit d'édition est restreint aux capacités Cl a, Cl b et C2b ; 31 3046273 - d'écriture et de lecture, par exemple d'édition et d'administration du plan de vol public (D3 603; « READ/VVRITE » sur les données du coeur fonctionnel). Dans l'exemple fourni, ce droit n'est associé à aucune restriction. 5 Dans un mode de réalisation, chacun des clients de l'API est considéré comme une application élémentaire implémentant le modèle d'interaction et le protocole de communication entre le ou les systèmes externes connectés et le coeur fonctionnel du FMS. Chacun des clients contribue à 10 réaliser une ou plusieurs fonctions avioniques opérationnelles. Une qualité de service QoS de nature avionique peut être définie pour chacun des clients (ou au moins une partie d'entre eux). Cette qualité de service permet de définir des niveaux de privilèges entre les clients dans le traitement de leurs requêtes (services, accès aux données). La qualité de 15 service avionique offerte à chaque client est une variable configurable. Dans un mode de réalisation, deux types d'information permettent de définir le domaine d'utilisation du coeur fonctionnel dans le cadre d'interaction avec des systèmes tiers : a) le quantum de temps alloué, de 20 manière fixe, au coeur fonctionnel pour le traitement de l'ensemble des interactions avec les systèmes connectés et b) le nombre maximal de systèmes connectés par famille de fonctionnalités opérationnelles. Dans un mode de réalisation, ces deux types information permettent de 25 borner « enveloppe » maximale (le périmètre du domaine d'utilisation) à laquelle doit répondre le coeur fonctionnel. Le sous-ensemble des ressources matérielles, logicielles et des données d'E/S associé aux interactions entre chacun des systèmes connectés et le 30 coeur fonctionnel est provisionné au regard de ces deux informations (le terme « provisionner » signifie l'apport des ressources matérielles 32 3046273 adéquates, selon une obligation de moyens voire une obligation de résultat, i.e. selon des niveaux de service garantis ou au moins quantifiés, « Service Level Agreements » en anglais). 5 La validation du coeur fonctionnel, en matière de « comportement » (e.g. ensemble de réponses à des requêtes) et dans ses performances peut être obtenue avec des valeurs fixes pour ces deux types d'information, et pour une plateforme d'exécution donnée. La certification est généralement obtenue (et maintenue) tant qu'il n'est pas nécessaire de 10 faire évoluer un de ces types d'information et/ou la plateforme d'exécution de référence. La figure 7 illustre un exemple de classification des fonctionnalités avioniques opérationnelles en fonction de leur niveau de criticité 15 (allocation des fonctions par criticité). Dans un mode de réalisation de l'invention, le niveau de criticité X1 correspond à un niveau (strictement) supérieur au niveau de criticité du coeur fonctionnel FMS ; le niveau de criticité X2 correspond à un niveau 20 de criticité égale (ou sensiblement égale) à celui du coeur fonctionnel FMS ; le niveau de criticité X3 correspond à un niveau de criticité (strictement) inférieur au niveau de criticité du coeur fonctionnel FMS ; le niveau de criticité X4 correspond à un niveau de criticité très inférieur au niveau de criticité du coeur fonctionnel FMS. 25 Par exemple, les fonctionnalités avioniques opérationnelles F1 concernant l'interface homme machine 701 ont un niveau de criticité égale X2 à celui du FMS. Les fonctionnalités F2 de guidage automatique de l'aéronef 702 ont un niveau de criticité X1 supérieur à celui du FMS. 30 Les fonctionnalités F4 en matière de relations avec le trafic aérien ou les centres de contrôle opérationnel 703 ont un niveau de criticité X3 inférieur 33 3046273 à celui du FMS. Les fonctionnalités F6 présentent un niveau de criticité X4 très inférieur à celui du FMS. La figure 8 présente un exemple de corrélation entre les niveaux de criticité et les droits d'accès aux services avioniques. 5 Dans l'exemple, il se dégage un ensemble de quatre clients « homogènes » (801, 802, 803, 804) implémentant les interactions avec les systèmes externes. Les quatre clients peuvent réaliser des sous- ensembles de fonctionnalités avioniques homogènes, en termes de (i) 10 criticité et de (ii) droits d'accès. Ce nombre est optimum vis à vis de la stabilité de la qualité de service attribuée par client, la stabilité des niveaux DAL (acronyme de l'anglais « Design Assurance Level », qui désigne la qualité de développement d'un système embarqué, établi par la norme internationale RTCA DO-178) contraignant l'implémentation des 15 différents clients et de la stabilité des privilèges d'accès aux interfaces de communication associés à chacun des clients et à la stabilité des tables de configuration et de correspondance (« mapping » selon la terminologie anglaise) des entrées/sorties (E/S) entre clients et coeur fonctionnel. 20 Certains regroupements peuvent être effectués: les fonctionnalités peuvent être réparties en quatre groupes 801, 802., 803 et 804 par exemple. Le premier groupe 801 comprend par exemple les fonctionnalités F1 interface homme-machine, associés à un niveau de criticité X2 et à un droit d'accès D3. Le groupe 802 comprend les 25 fonctionnalités de guidage automatique de l'avion et de sécurisation du vol. Le groupe 803 comprend les fonctionnalités d'échange avec l'autorité sol et d'aide à la décision à bord. Le groupe 804 comprend les fonctionnalités de mise au point et de simulation. 30 La figure 9 illustre certains aspects d'un mode de réalisation du procédé selon l'invention. 34 3046273 Le bloc 910 correspond aux fonctions avioniques opérationnelles candidates selon des catégories prédéfinies (dans l'exemple, neuf catégories déployées sur N systèmes externes). Ces fonctions avioniques opérationnelles peuvent être hébergées dans des systèmes avioniques, 5 et/ou dans des systèmes de type « ouvert » (« monde ouvert ») et/ou des systèmes localisés au sol. Le bloc 920 correspond aux interfaces API ouvertes, au sens de l'invention, fournissant 10 - les services avioniques C1a d'accès au système d'information du coeur fonctionnel (par exemple les données de configuration du système, comme les modes et options de fonctionnement, les données de paramétrage comprenant notamment des bases de données de navigation, des données caractéristiques en entrée ainsi que des 15 données et des états consolidés par le coeur fonctionnel), - les services avioniques C2a (par exemple des services d'administration de plan de vol), - les services avioniques C2b (par exemple d'édition de plan de vol), - les services avioniques C1b (par exemple d'accès aux données du plan 20 de vol, de trajectoire 3D et des prédictions associées pour les plans de vol manipulés par le coeur fonctionnel). Les ressources matérielles et logicielles quant à elles sont provisionnées au regard du domaine d'utilisation du coeur fonctionnel. 25 Le bloc 930 correspond au domaine d'utilisation du coeur fonctionnel (nombre maximal de systèmes externes, fonctions avioniques opérationnelles, provisions de ressources d'entrée/sortie pour chaque système en fonction des droits d'accès requis pour la fonction 30 opérationnelle concernée, quantum de temps fixe et/ou pourcentage de temps processeur pour l'interaction externe, crédits de certification 3046273 associés, etc.) Le bloc 940 correspond à la configuration d'un client. Un client peut regrouper différentes fonctions opérationnelles (de F1 à F9), une ou plusieurs qualités de service associées. Dans un mode de réalisation, le 5 nombre de systèmes réellement connectés est connu (par exemple par fonction ou service avionique). Le bloc 950 désigne des applications spécifiques implémentant le modèle d'interaction et les protocoles avec les systèmes externes de chacune 10 des fonctions opérationnelles. Ces applications peuvent par exemple correspondre à une pluralité de clients qui exploitent les API ouvertes de manière homogène en termes de criticité et/ou en termes de privilèges ou droits d'accès. 15 La figure 10 illustre un exemple de déroulement dynamique du procédé pour une architecture donnée. Dans une première étape 1010, il est reçu (ou déterminé) une action du pilote sur le plan de vol depuis l'interface homme-machine dans le 20 cockpit (F1). Dans une deuxième étape 1020, les capacités avioniques du coeur fonctionnel sont mises en oeuvre pour répondre à l'action opérationnelle (un ou plusieurs services avioniques sont sollicités). Dans une troisième étape 1030, les données du coeur fonctionnel sont récupérées (par exemple dans leur contenu standard C4). Dans une 25 quatrième étape 1040, les données reçues sont traitées (par exemple formatées) puis transmises vers le système d'affichage présent au sein du cockpit (F1). Enfin, dans une cinquième étape 1050, les données traitées sont transmises vers le système d'enregistrement et d'analyse du comportement des essais en vol (« Flight Test Data Recorder », F8). 30 La figure 11 illustre des exemples d'étapes du procédé selon l'invention. 36 3046273 Dans une première étape 1110, le typage des fonctionnalités avioniques par intrusivité et criticité est effectué. Dans un mode de réalisation, il peut être réalisé via un fichier de configuration 1111 embarqué par l'OPEN API, afin qu'un nouveau client puisse se connecter sans avoir à rouvrir le code 5 de l'API. Les sous-étapes correspondant à ce typage (i.e. d'allocation des droits) peuvent être réalisées en temps réel. Ultérieurement, les droits d'accès Di aux services avioniques sont déterminés 1121. En parallèle ou successivement, les niveaux de 10 criticité Xi relatifs par rapport aux FMS sont déterminés 1122. En fonction de la liste des fonctionnalités avioniques 1130 présentes dans l'avion, le typage des fonctionnalités par intrusivité 1131 et/ou par criticité 1132 est déterminé. 15 À l'étape 1140 les droits d'accès sont alloués par fonctionnalités avioniques Fi en fonction de l'intrusivité déterminée, puis à l'étape 1150 le nombre de types de clients est déterminé. L'ensemble des étapes décrites ci-avant peuvent être effectué hors-ligne 20 (« offline », c'est-à-dire pendant la conception du coeur numérique ouvert et de son interface). À l'étape 1160, une requête est reçue ou une interaction est détectée de la part d'un des systèmes connectés, lequel souhaite accéder à un ou 25 plusieurs services avioniques. Les différents droits d'accès sont alors vérifiés à l'étape 1170, en fonction du type de client. Si l'accès est autorisé, le service avionique demandé est exécuté à l'étape 1181 (ou la pluralité de services avioniques le cas échéant). A défaut, si l'accès n'est pas autorisé à l'étape 1182, le client est notifié du rejet de sa requête. 30 37 3046273 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. Le dispositif 5 implémentant une ou plusieurs des étapes du procédé peut utiliser un ou plusieurs circuits électroniques dédiés ou un circuit à usage général. La technique de l'invention peut se réaliser sur une machine de calcul reprogrammable (un processeur ou un micro contrôleur par exemple) exécutant un programme comprenant une séquence d'instructions, ou sur 10 une machine de calcul dédiée (par exemple un ensemble de portes logiques comme un FPGA ou un ASIC, ou tout autre module matériel). Un circuit dédié peut notamment accélérer les performances en matière d'accès et d'exécution des services avioniques. A titre d'exemple d'architecture matérielle adaptée à mettre en oeuvre l'invention, un 15 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 "multicore" ou "many-core"; une mémoire morte (ROM, acronyme de «Read Only Memory» en anglais) pouvant comporter les programmes 20 nécessaires à la mise en oeuvre 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 25 «Input/output» 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, 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 mémoire flash, une carte SD), un 30 moyen de 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 38 3046273 partiellement ou totalement par un ordinateur ou un processeur. Le réseau de télécommunication peut être 2G, 3G, 4G, Wifi, BLE, fibre optique, de type propriétaire ou selon une combinaison de ces réseaux. La référence à un programme d'ordinateur qui, lorsqu'il est exécuté, 5 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, 10 un microcode, ou toute autre forme d'instruction d'ordinateur) 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 être centralisés et/ou être distribués ("Cloud computing"), éventuellement avec ou selon des technologies de 15 pair-à-pair et/ou de virtualisation et/ou de redondance. Le code logiciel peut être exécuté sur n'importe quel processeur approprié (par exemple, un microprocesseur) ou coeur 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. 20 39 REVENDICATIONS1. Procédé de gestion de données avioniques entre un système de gestion de vol FMS et un ou plusieurs clients dudit FMS, - le système de gestion de vol FMS comprenant des ressources physiques accessibles au travers de services avioniques Ci (1,n); - l'exécution d'un ou de plusieurs services avioniques Ci (1,n) déterminant une fonctionnalité avionique Fj (1,m); - chaque fonctionnalité avionique Fj (1,m) étant associée à un paramètre d'intrusivité Ik et un paramètre de criticité Ck; le procédé comprenant les étapes consistant à: - recevoir une requête depuis un client, ladite requête spécifiant l'appel à une fonctionnalité avionique Fj (1,m); - déterminer un paramètre associé à un droit d'exécution prédéfini d'un service avionique Ci (1,n), ledit paramètre étant fonction des paramètres d'intrusivité et/ou de criticité prédéfinis et associés à ladite fonctionnalité avionique Fj (1,m) 2. Procédé selon la revendication 1, comprenant en outre l'étape 20 consistant à comparer le paramètre de droit d'exécution déterminé avec un ou plusieurs droits d'exécution prédéfinis. 3. Procédé selon la revendication 2, comprenant en outre une étape consistant à exécuter un ou plusieurs services avioniques et 25 communiquer le résultat au client. 4. Procédé selon la revendication 2, comprenant en outre l'étape consistant à notifier le client du rejet de sa requête. 30 5. Procédé selon l'une quelconque des revendications précédentes, un service avionique correspondant un service avionique sélectionné parmi un service avionique d'accès au système d'information du coeur 40 3046273 fonctionnel du FMS, un service avionique de gestion ou d'administration de plan de vol, un service avionique d'accès aux données d'un plan de vol ou d'une trajectoire de l'aéronef. 5 6. Procédé selon l'une quelconque des revendications précédentes, un niveau de criticité étant sélectionné parmi une pluralité de plages de criticité prédéfinies. 7. Procédé selon la revendication 6, la pluralité de plages de criticité 10 comprenant quatre plages de criticité prédéfinies, lesquelles comprennent un niveau de criticité X1 strictement supérieur au niveau de criticité du coeur fonctionnel FMS, le niveau de criticité X2 égale au niveau de criticité du coeur fonctionnel FMS, le niveau de criticité X3 strictement inférieur au niveau de criticité du coeur fonctionnel FMS et le niveau de criticité X4 15 très inférieur au niveau de criticité du coeur fonctionnel FMS. 8. Procédé selon l'une quelconque des revendications précédentes, une fonctionnalité avionique étant sélectionnée parmi les fonctionnalités avioniques comprenant une fonctionnalité d'interface Homme Machine F1, une fonctionnalité de Guidage automatique de l'aéronef F2, une fonctionnalité de Surveillance et monitoring du vol et de la trajectoire F3, une fonctionnalité de Relation avec le trafic aérien et les centres de contrôle opérationnel F4, une fonctionnalité de Outils d'aide à la décision stratégique ou à l'optimisation du vol F5, une fonctionnalité de 25 Simulation de vol F6, une fonctionnalité de Maintenance et mise en condition opérationnelle F7, une fonctionnalité de Mise au point sol & vol F8, une fonctionnalité de Analyse de pannes et enregistreur de vol F9. 9. Procédé selon l'une quelconque des revendications précédentes, une 30 fonctionnalité avionique étant exécutée selon un modèle d'interaction prédéfini, le modèle d'interaction avionique prédéfini étant choisi parmi les 41 304 62 73 modèles d'interactions comprenant un modèle d'interaction homme-machine, un modèle d'interaction comprenant le guidage automatique de l'aéronef et ou la surveillance de bord, un modèle interaction dit ATMAirlines Operation Center et/ou un modèle d'interaction dit Simulation- 5 Maintenance-Mise au point-Analyse de Pannes. 10. Procédé selon l'une quelconque des revendications précédentes, les paramètres d'intrusivité et/ou de criticité étant configurables. 10 11. Procédé selon la revendication 1, un ou plusieurs paramètres d'intrusivité et/ou de criticité étant fonction du contexte de vol. 12. Un produit programme d'ordinateur, ledit programme d'ordinateur comprenant des instructions de code permettant d'effectuer les étapes du 15 procédé selon l'une quelconque des revendications 1 à 11, lorsque ledit programme est exécuté sur un ordinateur. 13. Système comprenant des moyens pour mettre en oeuvre les étapes du procédé selon l'une quelconque des revendications 1 à 11. 20 14. Système selon la revendication 13 comprenant un système de gestion de vol FMS et un ou plusieurs clients dudit système de gestion de vol FMS. 15. Système selon la revendication 13 ou 14, comprenant au moins un sac de vol électronique de type EFB.30