FR 3067803 A1 20181221 FR 1700650 A 20170616 SYNCHRONISATION D'UN SYSTEME DUAL AVIONIQUE ET NON- AVIONIQUE 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 de gestion de vol, de type avionique (e.g. « Flight Management System », FMS) ou non-avionique (e.g. « Electronic Flight Bag », EFB). Etat de la Technique L'expression « monde avionique » désigne des systèmes avioniques certifiés qui apportent des garanties en matière de développement. Le monde dit « non-avionique » ou « ouvert » s'oppose, complémente et interagit avec ce monde avionique. Il désigne notamment les sacs de vol électroniques ou autres tablettes et calculateurs, situés au sol ou embarqués à bord de l'avion. Dès lors qu'il y a la possibilité de mettre un système de calcul qui traite des éléments du vol à l'extérieur de l'avionique (i.e. dans le monde ouvert, e.g. par des EFBs), il peut se poser plusieurs problèmes techniques spécifiques. Il peut notamment se poser un problème technique relatif à la communication et à la mise à jour de ce système par rapport au système de gestion du vol dans l'avionique, et vice-versa. Cette mise à jour, c'est-à-dire cette interaction (communication bidirectionnelle) entre les deux types d'équipements peut poser des problèmes critiques en termes de sécurité (« security ») et/ou de sureté (« safety »), en particulier en matière de la certification des équipements et de l'ouverture vers d'autres systèmes interconnectés à Internet. Par ailleurs, le développement accéléré d'outils comme les EFBs (par exemple 2 en matière de capacités de calcul, de flexibilité ou de fiabilité) rend de plus en plus pressant la mise au point de procédés de gestion avancés de ces interactions. La communication entre les deux mondes doit surmonter nombre de difficultés, en apporter des garanties, protections et des précautions 5 spécifiques. Dans les systèmes existants, les EFBs et leurs applications ne sont généralement pas connectés à l'avionique. L'équipage est donc contraint d'effectuer un travail double, puisqu'il doit analyser les résultats dans le monde 10 ouvert et reporter manuellement les éléments qui sont utilisables et utiles dans les systèmes l'avionique. L'apport des EFBs et de leurs applications peut par suite avoir un effet contraire à l'effet escompté, qui est d'aider l'équipage et d'en réduire la charge de travail. 15 La littérature brevet adresse rarement les problèmes techniques précités, et n'en donne pas de solutions satisfaisantes. Par exemple, le document de brevet FR3029619 intitulé « SYSTEME DE GESTION, EN PARTICULIER SYSTEME DE GESTION DE VOL, POUR UN 20 AERONEF » divulgue un système de gestion qui comporte un coeur avionique, mettant en oeuvre des fonctionnalités dites génériques de gestion de l'aéronef et la fourniture de services liés au moins à ces fonctionnalités génériques, au moins une fonctionnalité déportée (F1, F2, Fn) dans une partie monde ouvert (4), dite fonctionnalité déportée, réalisant une fonction d'interfaçage entre le 25 coeur avionique et des applications (API, AP2, APm) de type monde ouvert, qui ont besoin de communiquer avec le coeur avionique, en assurant une homogénéité et une cohérence de données échangées et en garantissant une intégrité et une sécurité des échanges de données, et une interface d'échanges entre le coeur avionique et la fonctionnalité monde ouvert (F1, F2, Fn), 30 supportant les échanges de données. Cette approche présente des limitations. En particulier, les mises à jour des données de part et d'autre ne sont pas gérées, pas plus que ne sont adressés des considérations relatives à la sécurité et à la sûreté. Certaines approches comme celle décrit dans US9583008 prévoient des systèmes FMS étendus « extended FMS », soit par exemple un FMS réparti par 3 construction sur les deux mondes avionique et monde ouvert, c'est-à-dire requérant un système FMS modifié par rapport à l'existant. Cette approche est limitée en ce qu'elle interdit la réutilisation de FMS non - modifiés. 5 Il existe un besoin pour des procédés et des systèmes permettant des interactions, contrôlées (e.g. sécurisées et/ou sûres), entre des systèmes avioniques et les systèmes non-avioniques. Résumé de l'invention 10 Différentes modalités de régulation et/ou d'intégration de systèmes de type avionique avec des systèmes de type non-avionique ou ouverts sont décrites. Des développements de l'invention décrivent notamment différentes modalités de synchronisation des données via un espace de partage, des modalités de 15 modification des données, des interactions homme-machine, des étapes d'optimisation des calculs et de la bande passante, de détermination d'alertes concernant des risques associés à des différences de calcul, et des mécanismes pour sécuriser l'espace de stockage sécurisé. Des aspects de logiciel et de système sont décrits (E.F.B. et F.M.S.) 20 Avantageusement, la connexion ou la mise en relation entre les deux mondes permet de préserver ou garantir les critères requis en matière se sécurité et de sûreté aéronautique. 25 Dans un mode de réalisation, une communication à sens unique de l'avionique vers le monde ouvert peut être établie (les données sont « évadées » des systèmes certifiés vers les systèmes ouverts pour traitement). Dans un mode de réalisation, une communication à double sens peut être 30 établie (les données des systèmes certifiés manipulées par les systèmes ouverts sont réinjectées dans les systèmes avioniques). Cette interaction bidirectionnelle permet avantageusement l'accès à de nombreuses sources de données dans le monde ouvert qui décuplent les 35 assistances possibles pour la conduite du vol. Le monde ouvert n'est pas contraint en termes de ressource (puissance de calcul, mémoire), et d'évolution 4 technologique (accès à toutes les dernières évolutions en permanence) en raison des moindres contraintes de certification. L'utilisabilité (« usability ») des interfaces homme-machine du monde ouvert est enfin généralement supérieure (e.g. accessible, robuste, non-ambigüe, etc) aux interfaces utilisateur en vigueur 5 dans l'avionique (à tout le moins elles correspondent aux pratiques généralisées dans l'informatique grand public). Avantageusement, les procédés et systèmes selon l'invention permettent de « déporter » vers le monde ouvert un grand nombre de fonctions de type 10 avionique puis de réimporter les résultats ou les données manipulées et enrichies dans l'avionique. Dans un mode de réalisation, l'import ou le ré-import de données, de données sur les données (métadonnées), de fonctions ou de programmes (données 15 modifiant des données) peut être vérifiées, contrôlées ou modifiées par le pilote (boucle ouverte). La communication ou la synchronization est alors « asymétrique », au sens où les données de la mission gérée dans l'avionique ne peuvent pas être remplacées sans l'accord du pilote. 20 Dans d'autres modes de réalisation (type boucle fermée), les interactions entre monde ouvert et avionique sont effectuées de manière intégrée (e.g. sûre et/ou sécurisée). Avantageusement, certains modes de réalisation permettent de conduire une 25 communication transparente entre les deux mondes, tout en préservant le monde avionique des altérations que peut apporter une communication avec le monde ouvert. Dans un mode de réalisation, le pilote n'intervient pas dans l'interaction (par exemple la synchronisation) des deux types de système à l'exception d'opérations en lien avec la sécurité. 30 Avantageusement, en lien avec la mise à contribution d'outils modernes et évolutifs du monde ouvert, les procédés et systèmes selon l'invention permettent des améliorations quantitatives et/ou qualitatives du vol (e.g. en matière de performances, coûts opérationnels e.g. consommation de carburant, prédictibilité 35 et fiabilité de la mission), une charge de travail réduite pour le pilote et donc une meilleure gestion de la charge cognitive de ce dernier, ainsi que des impacts 5 positifs en matière de sécurité et sûreté aéronautique. Selon un mode de réalisation avantageux, l'interface homme-machine déployée dans le cockpit comprend une page et/ou une commande dédiée à la vérification 5 et/ou acceptation et/ou modification de données issues du monde ouvert non avionique dans la gestion de la mission gérée dans l'avionique. Avantageusement, l'invention peut être mise en oeuvre au sein d'avions contemporains comprenant des systèmes de gestion de vol FMS de dernière ou 10 de nouvelle génération. Ces systèmes de gestion de vol FMS, par exemple les FMS de type « Open Capacity » (à capacités ouvertes) offrent par défaut des liens de communication avec des systèmes non-avioniques. Ces liens de communication peuvent être utilisés par l'invention. Des FMS d'ancienne génération peuvent être adressés de différentes manières, notamment au 15 travers de liens de communication existants (data link, liens sol-bord détaillés ci- après). Avantageusement selon l'invention, des trajectoires et des prédictions du plan de vol peuvent être calculées dans le monde ouvert, donc plus rapidement (et ce 20 de manière fiable). Avantageusement selon l'invention, l'emploi d'un espace de stockage tampon entre monde ouvert et monde avionique permet de diminuer, globalement et/ou ponctuellement la quantité de données à échanger, et par suite permettent 25 d'accélérer les calculs (tout en restant fiable). Dans un mode de réalisation, des librairies de calcul exécutées dans le monde ouvert permettent de déterminer les parties manquantes (données, fonctions, résultats de calcul) pour traitement par l'avionique. Des mécanismes de 30 synchronisation sophistiqués peuvent être mis en oeuvre du fait de l'existence de l'espace de stockage. Dans certains modes de réalisation, la synchronisation des données entre les deux mondes peut être incomplète, et peut donc résulter en un surcroît de travail 35 engendré pour le pilote (qui doit compléter la synchronisation). Cette étape consistant à vérifier, compléter ou modifier manuellement la synchronisation est 6 détectable car visible à l'écran. Dans certains modes de réalisation avantageux, des « patterns » ou motifs ou schémas ou gabarits d'échanges de données peuvent être utilisés et peuvent 5 optimiser la bande passante (soulageant la bande passante du coté du réseau avionique, qui peut être limitée). Dans certains modes de réalisation avantageux, des techniques de compression de données peuvent être utilisées pour minimiser encore plus la taille des 10 données synchronisées sur le réseau avionique. Avantageusement selon l'invention, le périmètre des fonctions avioniques (périmètre fonctionnel) peut être étendu par les fonctions du monde ouvert. 15 Avantageusement selon l'invention, la synchronisation entre les deux types de système peut être contrôlée et/ou optimisée en minimisant les risques relatifs à la sécurité et/ou la sûreté aéronautiques. Avantageusement selon l'invention, les données du monde non-avionique 20 (potentiellement riches, e.g. diverse et variées) peuvent être adaptées (e.g. détectées, formatées, modifiées, sélectionnées) puis prises en compte dans le domaine avionique. Cette adaptation peut également être contextuelle, c'est-à-dire être effectuée en fonction du contexte de vol (e.g. phase de vol, événement de vol, contrainte ou objectif opérationnel, etc). 25 Avantageusement, les modes de réalisation de l'invention permettent une synchronisation entre deux types de systèmes (associés à des caractéristiques de sécurité et/ou de sûreté différentes). Les communications peuvent être de type client/serveur. Dans un mode de réalisation, la synchronisation peut être 30 qualifiée d'asymétrique, en privilégiant l'intégrité et la vérification des données du monde avionique. Avantageusement, la charge (cognitive) du pilote est diminuée ou minimisée. Toute action d'un côté ou de l'autre (avionique versus non-avionique) n'a besoin d'être effectuée qu'à un seul endroit. 35 Avantageusement, l'espace de stockage sécurisé et/ou fiabilisé permet d'assurer une validation des données et un contrôle/validation de ce qui est 7 injecté dans la mission opérationnelle du monde avionique. Description des figures 5 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 figure 1 illustre l'environnement technique global de l'invention ; 10 La figure 2 schématise de manière générale l'intégration ou les interactions entre le(s) système(s) avionique(s) et non-avionique(s) 122; La figure 3 illustre un mode de régulation spécifique selon un mode de réalisation avantageux de l'invention ; La figure 4 illustre d'autres exemples de modes de réalisation de l'invention ; La figure 5 illustre des exemples d'étapes du procédé selon un mode de réalisation de l'invention. Description détaillée de l'invention Un aéronef au sens de l'invention est un moyen de transport capable d'évoluer au sein de l'atmosphère terrestre. Par exemple, un aéronef peut être un avion ou 25 un hélicoptère (ou bien encore un drone). Par extension, les modes de réalisation de l'invention sont applicables à tout type de transport terrestre, naval, aérien, aérospatial (optimisation de trajectoires orbitales). L'invention décrit différentes interactions entre un ou plusieurs systèmes de type 30 avionique et un ou plusieurs systèmes de type non-avionique. Les deux types de systèmes sont des systèmes techniques. Les systèmes avioniques sont des systèmes répondant à des exigences particulières, notamment techniques, telles qu'éditées par la réglementation aéronautique. 15 20 35 Un « système avionique » (ou « système de type avionique ») est un système présentant des caractéristiques techniques spécifiques en comparaison d'un 8 système « non-avionique » (ou « système de type non-avionique » ou « monde ouvert »), ces caractéristiques techniques étant certifiées administrativement par une autorité de confiance (en l'occurrence le régulateur aéronautique). Techniquement, des délégations d'autorités peuvent permettre à l'avenir une gestion de nature technique de cette gestion de type administrative (e.g. crypto ledgers). Concernant les caractéristiques techniques distinctives d'un système avionique, un système - de manière générale, i.e. avionique ou non-avionique - peut 10 présenter ou être associé avec un taux de défaillance prédéfini (parmi une plage de taux de défaillance prédéfinie), un taux de défaillance comprenant ou déterminant un taux d'erreur d'exécution prédéfini. Dans un mode de réalisation, le taux de défaillance d'un système de type avionique est inférieur au taux de défaillance d'un système de type non-avionique. Dans un mode de réalisation, le 15 taux de défaillance d'un système avionique est significativement ou substantiellement inférieur à celui d'un système non-avionique. Un système avionique désigne un système fiabilisé (ou à fiabilité garantie). C'est un système dont la défaillance a des conséquences excédant des limites 20 acceptées ou acceptables, donc redoutées. Une défaillance peut se caractériser par la perte de la fonction considérée, ou par la production de données erronées, avec ou sans détection d'une erreur. Selon le niveau de criticité des conséquences redoutées, la probabilité d'occurrence doit être maintenue inférieure à un seuil d'acceptabilité. Ainsi, plus la conséquence est critique, pour 25 la probabilité d'occurrence acceptable est faible. Par exemple, en aéronautique, un événement catastrophique (décès multiples) devra avoir une probabilité d'occurrence inférieure à 10^-9 par heure de vol, alors qu'un incident majeur (réduction des marges de sécurité et des capacités opérationnelles, inconfort ou blessures légères) devra avoir une probabilité d'occurrence inférieure à 10^-5 30 par heure de vol. Pour assurer ces objectifs, l'architecture du système avionique (fiabilisé) ainsi que la conception de chaque composant garantissent cette probabilité d'occurrence par des garanties de taux de panne de chaque équipement (pannes physiques) et des niveaux de vérification (couverture fonctionnelle et structurelle de test) des logiciels. 35 Ces exigences imposent un effort important de conception et de vérification, et 9 imposent une limitation dans la complexité des traitements mis en oeuvre. A l'inverse, la défaillance d'un système non-fiabilisé, ou à la fiabilité non garantie (système non-avionique) a des conséquences jugées tolérables, non critiques, 5 ou même sans impact opérationnel significatif. Les exigences sur l'architecture, les composants physiques ou les traitements logiciels sont donc moindres, et autorisent des traitements plus complexes, et un effort de développement et de vérification réduits par rapport à un système fiabilisé. 10 Afin d'utiliser lors des opérations en vol des données issues d'un calculateur non fiabilisé, du fait que la fiabilité des données n'est pas garantie (ou garanti avec un taux d'erreur inférieur aux exigences du système fiabilisé), il est avantageux d'utiliser le procédé selon l'invention. Les étapes du procédé permettent notamment de s'assurer qu'aucune donnée erronée ne soit utilisée 15 opérationnellement par le système fiabilisé. Les étapes peuvent comprendre la vérification par l'opérateur humain, suite à une saisie manuelle ou une transmission automatique, ou encore divers moyens de vérification des données transmises. Dans certains modes de réalisation, il est également possible d'avoir des étapes de calcul ou de vérification de la cohérence des données du système 20 non-avionique faite par le monde système avionique (par exemple, il peut être vérifié qu'une trajectoire est construite avec des points connus et qu'elle volable). La défaillance d'un système peut être appréhendée de manière déterministe mais également de manière probabiliste. 25 Dans un mode de réalisation, un critère additionnel d'exhaustivité permet de nuancer le critère du taux de défaillance. Ce critère d'exhaustivité désigne la couverture des tests (excitations, challenges sans nécessairement de réponse connue) et/ou des vérifications (e.g. comparaison de la réponse produite avec celle qui est connue et attendue) qui ont été préalablement effectués sur le 30 système avionique ou système non-avionique dans la détermination du taux de défaillance. Dans un mode de réalisation, l'exhaustivité des tests et/ou vérifications effectuées est supérieure dans un système avionique en comparaison d'un système non-avionique. 35 Dans un mode de réalisation, additionnellement au taux de défaillance global du système avionique ou système non-avionique, les taux de défaillance propres 10 aux composants du système avionique ou système non-avionique peuvent être pris en compte, ainsi que la propagation des défaillances. Différents modes de réalisation de l'invention décrivent différents types 5 d'échanges (e.g. données fonctionnelles et dynamiques d'échange), différentes protections (e.g. mécanismes de sécurité, espaces dédiés, etc.) et différents exemples de mécanismes de synchronisation qui peuvent être mis en oeuvre afin que les deux mondes soient le plus synchronisés possible. Dans un mode de réalisation, une référence principale est préservée dans l'avionique. 10 Le terme « consulter » fait référence à des données ou des calculs issus de l'avionique. Le terme « modifier » fait généralement référence à une donnée proposée par le monde ouvert dans son « bac à sable ». Le terme « injecter » désigne un échange du monde ouvert ou de son « bac à sable » vers les 15 données de mission gérées par le système avionique. La synchronisation des données concerne tout type de données (plan de vol, mais aussi données de la base navigation, des états de l'avion (exemple phase de vol) et des commandes (exemple :insert waypoint)/ Différents types d'objets 20 sont calculés, communiqués et comparés, de part et d'autre (avionique versus non-avionique). Pour la partie consultation, ces objets comprennent notamment des bases de données de navigation (permanente et utilisateur), des bases de données de variation magnétique, des caractéristiques statiques de l'avion, des éléments de la base de données de performance de l'avion, les états du 25 système avionique, les données du plan de vol, les données de trajectoire et les données de prédiction. Pour la partie modification, les objets comprennent notamment les bases de données de navigation utilisateur et les données de plan de vol. Pour la partie injection, les objets comprennent notamment les bases de données de navigation utilisateur et les données de plan de vol. 30 La figure 1 illustre l'environnement technique global de l'invention. Un aéronef 110 est un moyen de transport capable d'évoluer au sein de l'atmosphère terrestre. Par exemple, un aéronef peut être un avion ou un 35 hélicoptère (ou bien encore un drone). L'aéronef comprend une cabine de pilotage ou un cockpit 120. Au sein du cockpit se trouvent des équipements de 11 pilotage 121 (dits équipements avioniques, certifiés par le régulateur aéronautique) et des équipements optionnels (dits non-avioniques ou « monde ouvert »). 5 Les équipements avioniques 121 (ci-après « l'avionique ») comprennent par exemple un ou plusieurs calculateurs de bord (moyens de calcul, de mémorisation et de stockage de données), dont un système de gestion de vol (« Flight Management System », acronyme FMS), des moyens d'interface homme-machine, comme des moyens d'affichage (e.g. des écrans incorporés 10 aux équipements avioniques) et/ou de saisie de données (e.g. claviers, boutons, curseurs, rotacteurs, etc), des moyens de communication ou de retours haptiques. Par extension, les systèmes avioniques peuvent comprendre des systèmes accessibles à distance, par exemple de contrôle de traffic aérien 100 et/ou de centre opérationnel, qui peuvent être en communication (bilatérale) via 15 les liaisons sol-bord. Par ailleurs, les systèmes de contrôle de traffic aérien 1001 et/ou de centre opérationnel peuvent accéder (e.g. recevoir, collecter, sélectionner, croiser, déterminer) à des sources de données de type ouvert (e.g. données météorologique de type non-règlementaire), par exemple accessible depuis le réseau Internet et dont la couverture et la profondeur couvre la totalité 20 du vol de l'aéronef. Des systèmes non-avioniques 122 désignent des dispositifs embarqués ou au sol qui peuvent par exemple comprendre une ou plusieurs tablettes informatiques ou EFB (« Electronic Flight Bag » pour Cartable électronique), de 25 manière portative ou intégrée dans le cockpit, des moyens de visualisation (e.g. des écrans additionnels, des lunettes connectées, des visées tête haute, des projecteurs, des systèmes holographiques, des casques de réalité virtuelle et/ou augmentée dits « wearable computers » ou « head-mounted displays », etc), ainsi que des moyens d'interaction (e.g. des claviers à projection laser, 30 dépliables, déroulables; des systèmes haptiques, à retour de force, mécaniques, pneumatiques, électriques ; des moyens de dictée ou de reconnaissance vocale avec suppression de bruit etc). Un EFB non-avionique est parfois dénommé ou décrit comme étant un 35 équipement de type « (monde) ouvert » par opposition aux équipements de type « avionique » (certifié par le régulateur). Un EFB peut interagir (communication 12 unidirectionnelle ou bilatérale 123) avec les équipements avioniques 121. L'EFB peut également être en communication 124 avec des ressources informatiques externes, accessible par le réseau (par exemple informatique en nuage ou "Cloud computing" 125. En particulier, les calculs peuvent s'effectuer localement 5 sur l'EFB ou de manière partielle ou totale dans les moyens de calculs accessibles via ou par ou dans le réseau. Les équipements de bord 121 sont généralement certifiés et régulés tandis que l'EFB 122 et les moyens informatiques connectés 125 ne le sont généralement 10 pas (ou dans une moindre mesure). Selon les modes de réalisation (types d'intégration), les architectures pouvant être implémentées permettent d'injecter de la flexibilité et des capacités fonctionnelles du côté du monde ouvert (e.g. via l'EFB 122) en s'assurant d'une sécurité (contrôlée) du côté de l'avionique embarquée 121. 15 La figure 2 schématise de manière générale l'intégration ou les interactions entre le(s) système(s) avionique(s) 121 et non-avionique(s) 122. La régulation 210 des interactions entre les systèmes avioniques 121 et 20 systèmes de type non-avionique 122 peut être de fait, i.e. via des règles de gestion des échanges de données, implémentées de part et d'autre. La régulation 210 peut aussi prendre la forme d'un organe ou d'une entité de régulation dédiée. Dans certains modes de réalisation, le pilote 200 peut contrôler 211 (modifier, influencer, réguler, stopper, amorcer, initialiser, etc ; 25 directement ou indirectement) les échanges entre les systèmes 121 et 122 (e.g. en nature, volume, qualité etc). Le pilote peut notamment utiliser une ou plusieurs interfaces homme-machines. Les règles de régulation peuvent notamment résulter de l'intervention de l'homme et/ou de la machine (donc en particulier résulter de décisions conjointes homme et machine). 30 Généralement, les modalités de communication entre les deux types de systèmes système avionique et système non-avionique, recouvrent différents aspects ou paramètres: 35 a) directionalité; la communication entre les deux types de système (e.g. flux de données, passages de messages, etc) peut être unidirectionnelle ou 13 bidirectionnelle. Cette propriété de directionalité peut être statique (invariante ou cours du temps) mais peut aussi évoluer au cours du temps (suivant des intervalles de temps prédéfinis et/ou selon des événements prédéfinis, par exemple selon la phase ou le contexte de vol. Par exemple, la communication 5 peut être bidirectionnelle lorsque l'avion est au sol à sa porte d'embarquement, et unidirectionnelle dès le roulage. Dans cet exemple, lorsque l'avion est au sol, toute modification proposée par le système non-avionique au système avionique peut être vérifiée, et, si elle était erronée, elle ne diminuerait pas la sécurité dans la mesure où cette modification pourrait encore être modifiée et corrigée. Dés le 10 roulage et en vol, la communication intervient dans un premier temps uniquement du système avionique vers le système non-avionique, toute donnée produite par le système non-avionique ne pouvant pas être automatiquement transférée au système avionique. 15 b) forme (e.g. format de données, type de protocoles, traduction/pontage, etc). Par exemple, un protocole WIFI ou filaire Ethernet peut être le plus optimisé au sol (compte tenu du volume important qui peut être échangé au sol pour initialiser la mission) alors qu'un protocole plus sécurisé mais de moindre débit peut-être préférable en vol, compte tenu des architectures de communications 20 bord (AEEC ARINC 653) qui peuvent nécessiter de garantir de la bande passante et de l'intégrité pour tous les calculateurs critiques et peuvent donc limiter de fait le débit et le type de données échangées avec le système non-avionique. 25 c) fond (qualité e.g. nature des objets communiqués e.g. points de plan de vol ou trajectoire 3D, etc ; données sur les données i.e. métadonnées ; données brutes ou statiques ; données exécutables i.e. programmes). Un système non-avionique, en sus des plans de vol, peut être le réceptacle de nombreuses données riches dont une partie seulement sera exploitée par le système 30 avionique : cartes aéronautiques, cartes géographiques de résolution maximale, cartes météo complètes. Le système avionique peut utiliser une sous partie des données, filtrées pour ses besoins (par exemple filtrage le long du plan de vol, filtrage de la résolution adaptée à ses limitations mémoires, à ses limitations en puissance de calcul, etc). 35 d) quantité (ou volumes). Un système non-avionique peut utiliser des données 14 riches (il n'existe pas de limitation réelle en matière de processeur, de mémoire et de stockage; des processeurs multi-coeurs puissants peuvent être utilisés, alors que les calculateurs système avionique ont une architecture matérielle très robuste mais beaucoup plus limitée pour garantir la testabilité de la performance 5 requise, par exemple avec des propriétés de résistance aux évènements de particules à haute énergie lors du vol (SEU, NSEU), de résistance aux vibrations ou aux températures extrêmes. Les calculateurs système avionique ont en général significativement moins de puissance que les calculateurs non-avioniques. 10 e) privilèges ou priorités (e.g. des priorités globales peuvent être allouées ; par exemple le système avionique « maitre » sera associé à une priorité en tout temps supérieure au système non-avionique « esclave » ; des privilèges « administrateur » ou en « lecture/écriture » seront allouées aux différentes 15 parties par exemple en matière d'accès, de lecture et/ou d'écriture dans l'un ou l'autre type de système. La régulation des échanges de données peut régir chacun de ces aspects de manière différente et les combiner d'une manière particulière. Selon les modes 20 de réalisation, il sera obtenu des systèmes maitres/esclaves (évolutifs ou non) ou des réseaux de pairs-à-pairs (évolutifs ou non), comprenant des rétroactions diverses et variées (e.g. feedforward, etc) La référence à des interfaces homme-machine désigne un ensemble varié 25 d'équipements. Les dispositifs d'affichage peuvent comprendre ou mettre en oeuvre un ou plusieurs dispositifs sophistiqués tels que des casques de réalité virtuelle et/ou des lunettes de réalité augmentée (e.g. "head-mounted display", "wearable computer", des "glasses" ou un visiocasque) et/ou des dispositifs de projection (e.g. holographique). Un casque de réalité virtuelle porté par le pilote 30 peut être opaque ou semi transparent ou à transparence configurable). L'affichage peut être à « visée haute ». Le casque peut comprendre un ou plusieurs dispositifs de calcul et de communication, de projection, d'acquisition audio, de projection et/ou d'acquisition vidéo (par exemple pour la capture ou le "scraping" de données accessibles de manière analogique depuis le cockpit ou 35 la cabine de pilotage de l'aéronef). Le cockpit de l'hélicoptère peut également comprendre des dispositifs de commande vocale. L'instrumentation embarquée 15 peut avantageusement permettre au pilote de visualiser son plan de plan de vol ou sa trajectoire en 3D, notamment les différents points de passage selon l'invention. Le pilote pourra par exemple visualiser - par exemple en surimpression de son environnement réel - les différentes approches de la 5 plateforme cible, les rejointes de trajectoire quand ces dernières sont encore possibles (passer d'un type d'approche à une autre). La distance de sécurité pourra être visualisée par des enveloppes graphiques (cônes, polyèdres volumiques, murs virtuels, corridors virtuels, etc), ainsi que des paramètres locaux (par exemple vitesse du vent, mesures réelles par anémométrie laser des 10 vents ou turbulences locales, ou des simulations numériques de ces dernières. Enfin des dispositifs de retour haptique incorporés dans le système pour la mise en oeuvre de l'invention pourront enrichir le guidage/pilotage (vibrations spécifiques lors du franchissement effectif d'un point de passage, etc). 15 Concernant l'affichage, les informations peuvent être affichées dans un ou plusieurs casque(s) de réalité virtuelle et/ou augmentée. Les informations peuvent donc être entièrement virtuelles (affichées dans un casque individuel), entièrement réelles (par exemple projetées sur les surfaces planes disponibles 20 dans l'environnement réel du cockpit de l'hélicoptère) ou une combinaison des deux (en partie un affichage virtuel superposé ou fusionné avec la réalité et en partie un affichage réel via des projecteurs). L'affichage peut également se caractériser par l'application de règles d'emplacements et de règles d'affichage prédéfinies. Par exemple, les interfaces homme-machine (ou les informations) 25 peuvent être "distribuées" (segmentées en portions distinctes, éventuellement partiellement redondantes, puis réparties) entre les différents écrans virtuel ou réels. Dans un mode de réalisation, système avionique et système non-avionique 30 utilisent des supports physiques matériels (processeur, mémoires, etc) entièrement distincts (e.g. mutuellement exclusifs). Par exemple, système avionique et système non-avionique interagissent via des liens de données (nature logique) 35 Dans un mode de réalisation, les fonctions sont réparties entre les systèmes avioniques et non-avioniques. Dans un mode de réalisation, un organe de 16 communication sécurisé peut faire le lien entre les deux types de systèmes. Le transport de données peut par exemple être de nature IP ou IP sécurisés. Dans ce mode, système avionique et système non-avionique échangent des commandes et des données, mais la complétude des données dans les deux 5 mondes est assurée par un calcul indépendant dans chaque système. Un système non-avionique peut faire significativement plus de calculs grâce à des ressources en mémoire et CPU d'un ordre supérieur à celui du système avionique. Un système non-avionique peut donc effectuer des calculs en 10 dichotomie jusqu'à approcher une solution optimale qui sera affinée et confirmée par le monde système avionique en utilisant de façon optimale les ressources beaucoup moins abondante dans ce type de système. Par ailleurs, les supports physiques matériels des systèmes non-avionique évoluent beaucoup plus rapidement que les systèmes avioniques. 15 Dans un mode de réalisation, système avionique et système non-avionique partagent une partie des ressources matérielles (processeur, mémoires, etc). Par exemple, au moins une unité mémoire est accessible à la fois par le système avionique et par le système non-avionique. Dans un mode de 20 réalisation, une partie des ressources du système avionique peuvent être dédiées au système non-avionique afin de pouvoir faire calculer et vérifier par le système avionique des hypothèses de calculs élaborées/construites dans le monde système non-avionique. Les propriétés du système avionique peuvent ainsi exportées dans le système non-avionique. Bien que disponibles pour le 25 système non-avionique, ces ressources système avionique peuvent être protégées et leur utilisation ne peut pas propager au reste du système avionique des erreurs qui auraient pour origine les requêtes et les données du monde système non-avionique. Il existe donc un intérêt à solliciter de manière parcimonieuse les ressources avioniques. 30 Dans un mode de réalisation, un système avionique et un système non-avionique partagent la totalité des ressources matérielles (processeur, mémoires, etc). Deux modes de réalisation particuliers peuvent être décrits. Par exemple, un FMS système avionique est entièrement virtualisé sur une machine 35 hôte qui héberge à la fois un système avionique et un système non-avionique. Dans un mode de réalisation, la plateforme matérielle du système non-avionique 17 est élevée à un niveau de certification égal à celui du système avionique. D'un point de vue administratif, cette contrainte est couteuse en matière de qualification, mais conduit avantageusement à une optimisation en matière de transfert de données d'un monde à l'autre. Dans un mode de réalisation, un 5 FMS non-avionique est entièrement virtualisé sur le support matériel qui héberge (principalement) le système avionique. Ce mode de réalisation est limité du fait du manque d'évolutivité et de ressources des supports matériels du système avionique mais les contraintes réglementaires peuvent être satisfaites. 10 Dans un mode de réalisation, les systèmes système avionique et système non- avionique sont reliées par des connections exclusivement filaires, i.e. en excluant de toute communication sans-fil interceptable. La connexion filaire des systèmes peut rendre plus difficile la compromission des attaques de sécurité (e.. compromissions, interceptions ou injections malveillantes rendues possibles 15 dans les modes de réalisation sans-fil). Dans un mode de réalisation, les systèmes avioniques et les systèmes non-avionique sont reliées par des connections de type sans fil, mais sécurisées avec un chiffrement suffisant (clés complexes renouvelées plus fréquemment 20 que le temps minimum de cryptanalyse, ce dernier étant par exemple évalué compte tenu des moyens disponibles pour un passager de l'aéronef). En particulier, la régulation 210 (de fait ou d'après un organe de régulation) entre système avionique et système non-avionique - en tant que composant critique à 25 l'interface des deux types de systèmes - peut faire l'objet de mesures de sécurité dédiées (par exemple de manière indépendante des autres systèmes). Les mécanismes de sécurité peuvent comprendre un ou plusieurs des mécanismes comprenant le chiffrement des données (par exemple à clefs asymétriques), des mécanismes d'authentification (par exemple biométrique), 30 des mécanismes d'auto-surveillance (e.g. machine à états, « watchdog »), des mécanismes anti-intrusion (e.g. IDS), des mécanismes de vérification continue de l'intégrité des données manipulées dans le serveur passerelle, le partage d'un secret préalable, etc. 35 Dans un mode de réalisation, la régulation entre système avionique et système non-avionique peut être agréé (ou reconnu ou accepté ou autorisé) par les 18 systèmes non-avioniques d'une part et les systèmes avioniques d'autre part, de manière intermittente, régulière ou à la demande. Les mécanismes de sécurité peuvent comprendre un ou plusieurs mécanismes 5 et/ou étapes sélectionnés dans le groupe comprenant une étape consistant à contrôler l'intégrité de tout ou partie des données et/ou résultats (e.g. initiales, intermédiaires, finales) ; une étape consistant à authentifier une machine et/ou le pilote (e.g. PKI, biométrie, etc); une étape consistant à chiffrer tout ou partie des données; une étape consistant à compter les communications ou les données 10 ou les types de données échangées entre système avionique et système non-avionique, une étape consistant à classer des comportements protocolaires (« behaviour ») normaux ou anormaux, etc. Le contrôle d'intégrité peut comprendre une étape de vérification CRC ou 15 checksum. Le contrôle d'intégrité des données peut comprendre l'utilisation de chaines de hash (e.g. de type blockchain, par exemple pour garantir l'intégrité des données et/ou l'historique des révisions du plan de vol. L'accès aux données et à leurs révisions peut être effectuée à tout moment et par n'importe quelle partie (« permissionless ledgers») ou selon des enregistrements préalables 20 (« permissioned ledgers ») Le chiffrement peut être symétrique (clef privée). Le chiffrement peut être asymétrique (clef privée et clef publique) ; par exemple le système avionique peut conserver secrète sa clef privée pour déchiffrer les communications 25 chiffrées au moyen de sa clef publique par les systèmes non-avionique. Le décompte des échanges désigne le contrôle quantitatif des échanges, qui peut être différencié par types de données. Par exemple, la mise en place de compteurs peut permettre de contraindre (limiter, plafonner, freiner, ralentir, etc 30 de manière binaire, affine ou exponentielle) le nombre des imports et/ou exports de données entre système avionique et système non-avionique. La régulation des communications entre système avionique et système non-avionique peut être effectuée en boucle ouverte, cad nécessiter une validation 35 humaine, laquelle peut mobiliser un rendu graphique (visuel) pour la prise de décision. 19 L'authentification peut comprendre une pluralité de mécanismes pris en combinaison (e.g. authentification biométrique, par carte, par code, ou par test logique e.g. test de Turing type captcha afin de s'assurer de l'origine humaine de 5 la décision d'injection de données dans le système avionique). La figure 3 illustre un mode de régulation spécifique selon un mode de réalisation avantageux de l'invention. 10 Les données issues du monde ouvert sont communiquées 316 à l'avionique et sont reçues et stockées dans un « bac à sable » 322 (« sandbox » en anglais), le contenu duquel est accessible au pilote 200 et qui le cas échéant valide ou autorise, éventuellement après modification, l'injection des données dans le système de gestion de vol FMS ou de gestion de mission 321. L'avionique 15 calcule la trajectoire de manière précise et optionnellement une boucle retour 316 peut communiquer les donnés calculées au système non-avionique 122. Avec plus de détails, les flèches 315 et 316 symbolisent des communications de données, par exemple via des appels à des fonctions ou à des services. Les 20 données sont reçues (et isolées) dans le bac à sable 322 (« sandbox ») puis communiquées de manière sécurisée au module de mission avionique. La communication ou transfert des données peut optionnellement être modulée ou autorisée par le pilote 200. En effet, le pilote peut valider les données synchronisées lors de l'injection dans la mission opérationnelle. Après traitement 25 par le système avionique 122, des données sont fournies en retour 316 au système non-avionique. Le bac à sable 322 peut être implémenté matériellement de diverses manières. L'exemple de la figure 3 place cet espace de stockage sécurisé dans l'avionique, 30 mais dans d'autres modes de réalisation, il peut être implémenté à d'autres endroits physiques et/ou logiques (e.g. clef USB sécurisée, partition logique, EFB dédié, serveur dans le Cloud etc), la sécurité et l'intégrité des données étant assurées par un ou plusieurs mécanismes décrits ci-après. 35 Dans un mode de réalisation, le bac à sable 322 est un espace de stockage passif. Il enfiche (mise en file d'attente) les éléments calculés par les systèmes 20 non-avioniques et les transmet in fine aux systèmes avioniques. Le serveur passerelle sert alors de mémoire tampon (« buffer ») entre les deux types de systèmes. Dans un mode de réalisation, le bac à sable 322 peut ordonner la file d'attente, par exemple selon la priorité associée aux différents objets mis en file 5 d'attente, selon le contexte de vol et/ou l'utilisation des ressources avioniques qui peuvent être selon les cas sous-sollicitées ou sur-sollicitées, etc. Dans un mode de réalisation, le bac à sable 322 entre système avionique et système non-avionique est un espace de stockage actif, i.e. qui ajoute des 10 traitements logiques aux données reçues. Le bac à sable 322 peut effectuer une ou plusieurs des actions suivantes : effectuer ses propres vérifications sur la conformité d'une route par rapport aux critères avioniques, recevoir des instructions d'un système tiers, etc. Dans un mode de réalisation, le bac à sable 322 peut vérifier la conformité entre la trajectoire calculée dans l'avionique et la 15 trajectoire issue du calcul hors avionique. Dans un mode de réalisation illustré à la figure 3, le système dual hiérarchisé (maître-esclave) comprend un système avionique maître et système non-avionique esclave. Dans ce cadre, plusieurs modalités d'interaction (e.g. 20 mécanismes de synchronisation) sont décrites. Dans un mode de réalisation, il y a échange partiel de données et recalcul de part et d'autre pour reproduire une situation fonctionnellement équivalente. Dans un mode de réalisation, le système maître a des données particulières (exemple 25 position réelle de l'avion) qui permettent d'imposer le résultat. La vérification de l'intégrité ou de la viabilité des données produites est possible grâce à une aide montrant les différences entre les deux calculs. Dans un mode de réalisation cette vérification est effectuée par l'humain (via une interface IHM). Dans un mode de réalisation cette vérification est effectuée par la machine (via un 30 système de règles logiques manipulant des faits quantifiés. Dans un mode de réalisation, la vérification est conjointe homme-machine (e.g. pondérée ou pas, dernier mot pour le pilote ou non, etc). Dans un mode de réalisation, il y a échange complet des données et des états 35 de l'avion. Les données de la partie esclave ou asservie sont remplacées en intégralité par les données par la partie maître. Le système avionique impose 21 ses états et ses données. Dans un mode de réalisation interviennent des échanges complémentaires de données avec chaque partie (qui peut endosser un rôle de maitre pour certains 5 types de données ou d'objets manipulés), les autres données restantes étant recalculées localement par chaque partie. Dans un mode de réalisation, chaque partie peut en effet être spécialisée i.e. endosser le rôle de maître pour certaines données et le rôle asservi pour d'autres données. Certaines données peuvent être fournies par une partie ou par l'autre (par exemple, des données saisies 10 depuis les interfaces homme-machine). Dans un mode de réalisation, l'intégration entre systèmes 121 et systèmes 122 peut être effectuée de manière discrète, cad déterminée selon des intervalles de temps prédéfinis. Dans un mode de réalisation, chaque système peut recevoir 15 les mêmes données en entrée, recalculer tous les états, des points de synchronisation temporels prédéfinis (e.g« périodiques ou intermittents) et/ou effectués à la demande et/ou en fonction de l'occurrence d'un événement prédéfini peuvent conduire à vérifier que les états de sortie de chaque système restent dans une fourchette donnée (i.e. que les systèmes ne divergent pas. SI 20 les systèmes divergent, le système maître peut imposer son état pour resynchroniser le système esclave. Dans un mode de réalisation, l'intégration entre systèmes 121 et 122 peut être effectuée continuellement ou de manière quasi-continue, e.g. les résultats de 25 calculs intermédiaires sont comparés (et non plus les résultats finaux, comme dans les modes de réalisation décrits ci-avant). Avantageusement, une éventuelle divergence des systèmes sera détectée plus tôt que dans le cas d'une intégration ponctuelle. 30 Dans un mode de réalisation les rôles entre systèmes 121 et 122 sont prédéfinis, asymétriques et généralement invariants au cours du temps. Dans un mode de réalisation, l'allocation des rôles peut être évolutive (en tout ou partie, e.g. de manière réactive, en fonction de multiples paramètres, etc). 35 Dans un mode de réalisation, un ou plusieurs mécanismes de vote peuvent permettre de répudier ou rejeter sur demande la régulation projetée ou en cours 22 qui serait considéré comme corrompue ou risquée (par exemple si au moins un des systèmes avioniques le détermine comme tel, etc). La figure 4 illustre d'autres exemples de modes de réalisation de l'invention. 5 Dans un mode de réalisation, un système de type non-avionique peut comprendre une librairie de calcul de gestion de vol 400. La librairie de calcul de gestion de vol 400 désigne du code logiciel exécuté sur du matériel. Ce bloc logique, selon les modes de réalisation, peut effectuer des calculs de prédiction 10 de trajectoire identiques, ou fonctionnellement équivalents, à ceux effectués dans le système avionique. Les calculs menés reproduisent autant que possible les traitements tels qu'ils seront appliqués par le système avionique (le code logiciel est structurellement identique, éventuellement recompilé, ou il est fonctionnellement équivalent). Ce module de calcul peut aussi implémenter 15 diverses étapes d'optimisation (e.g. heuristiques, algorithmes A-star, algorithmes génétiques, algorithmes à base de champs de potentiels, etc). Le bloc 233 peut aussi traduire ou transcrire les données sortantes dans un format fonctionnellement équivalent à celui manipulé par le système avionique1213. 20 Dans un mode de réalisation, le FMS avionique 121 présente des interfaces prévues pour la communication vers des systèmes tiers (FMS dit « Open Capacity »). Le cas échéant, le calcul de la gestion du vol peut être mis à disposition par le système de gestion de vol FMS NG et sa capacité « Open Capacity ». 25 Dans un mode de réalisation, le module de calcul 400 peut effectuer des étapes de recherche et d'optimisation, des étapes de transcription (adaptation, traduction, etc) en route avionique, lesquels peuvent conduire à des calculs et prédictions de trajectoires. Les trajectoires produites sont enfin manipulées dans 30 le comparateur (éventuellement sécurisé 231). Matériellement, le calculateur 233 peut être implémenté sur tablette ou ordinateur portable (ou sur tout autre moyen de calcul externe à l'avionique, par exemple via des accès distants) permettant de déterminer (e.g. rechercher, 35 évaluer, sélectionner, etc) des routes alternatives. 23 Dans un mode de réalisation, les échanges entre les systèmes 121 et 122 (ces échanges peuvent être désignés par le terme « synchronisation ») se poursuivent de la manière suivant : l'avionique 121 effectue des calculs et les communique 316 au système ouvert 122 ou 400 qui mobilise des calculs 5 redondants mais aussi potentiellement complémentaires (par exemple en croisant les informations avec des données d'origine non-avionique à la couverture plus étendue) ; le système ouvert 122 ou 400 peut également démultiplier les calculs, e.g. conduire de manière parallèle l'analyse de très nombreuses variantes du calcul-pivot ou au moins initial effectuée par 10 l'avionique. Le(s) système(s) ouvert(s) communiquent 315 le résultat des calculs, par exemple optimisé, au bac à sable 322, lequel est architecturé pour servir de tampon avant la réinjection effective des données. Le bac à sable peut être figuré comme un sas de sécurité ou de décontamination ou de quarantaine (d'un rôle de tampon passif il peut être sophistiqué en un espace contenu 15 incorporant une batterie de tests logiques, la vérification d'intégrité et/ou de conformité pouvant notamment être compartimentalisée e.g. effectuée de manière indépendante des autres entités présentes dans l'architecture, etc). Dans un mode de réalisation à boucle ouverte, le pilote contrôle 211 les données 20 et peut les modifier, ce qui aboutit à « compléter » la synchronisation entre les deux types de systèmes. Dans un mode de réalisation à boucle fermée, le pilote n'intervient pas car ses critères de décision ont été modélisés, quantifiées par l'entremise de règles 25 logiques et de faits objectifs ou objectivables. Dans un mode de réalisation semi-ouvert, les boucles de rétroaction sont généralement fermées mais le pilote conserve la possibilité d'intervenir sur demande (par exemple, il peut être maintenu une visualisation des flux de 30 données, d'une part avioniques et d'autre part modifiées par le monde ouvert, laissant l'opportunité au pilote d'intervenir comme super-régulateur quand il le souhaite). Une fois validées (non-modifiées ou modifiées par l'homme et/ou la machine), 35 les données sont réinjectées 321 dans l'avionique 121. 24 Dans un mode de réalisation, les données ou parties de données (i.e. les modifications) sont tagguées comme tel. Dit autrement, dans certains modes de réalisation, des données sur les données (ou métadonnées) sont produites et conservées au sein de l'avionique, ce qui permet avantageusement une certaine 5 traçabilité des couples (modifications introduites - conséquences mesurées ultérieurement). Dans certains modes de réalisation, des tâches de plus en plus en plus haut niveau étant allouées au pilote (les tâches de routine étant automatisées), des 10 mécanismes divers, par exemple de sécurité, de test, de vérification ou de visualisations, conduites localement sur des aspects prédéfinis (des points de contrôle, de divergences, etc) peuvent permettre de superviser l'intégration globale. Des aspects de la régulation peuvent en particulier être évolutifs et en particulier être programmées pour dépendre des phases de vol. Certaines 15 phases de vol critiques nécessitent en effet le contrôle actif et entier du pilote tandis que d'autres peuvent se satisfaire d'une attention moins soutenue. La figure 5 illustre des exemples d'étapes du procédé selon un mode de réalisation de l'invention. 20 Dans un mode de réalisation, il est décrit un procédé de gestion de données de vol d'un aéronef mis en oeuvre dans un système comprenant un système de type avionique 121 et un système de type non-avionique 122, le procédé comprenant les étapes consistant à: déterminer des données de vol dans le 25 système non-avionique 122; stocker 510 lesdites données dans un espace de stockage; déterminer des données de vol correspondantes dans le système avionique 121; comparer 520 les données déterminées d'une part par le système avionique et d'autre part par le système non-avionique selon un schéma temporel prédéfini 580. 30 Dans un mode de réalisation, le système selon l'invention comprend un système de type avionique et un système de type non-avionique. Les échanges de données (la « synchronisation ») se fait par échanges de données. 35 Dans un mode de réalisation, les systèmes avioniques et non-avioniques calculent de part et d'autre les différents objets avioniques (par exemple une 25 route ou une trajectoire alternative, un déroutement, etc). Ces calculs peuvent se recouper, en totalité ou en partie. Des calculs généralement non-avioniques, issus de calculs plus optimisés et notamment à 5 l'aide de données à couverture plus étendue, peuvent compléter les calculs avioniques. Les données calculées de part et d'autre sont comparées 520 au sein d'un espace de stockage partagé. Le terme « correspondant » signifie que les 10 mêmes objets (routes, trajectoires, paramètres de vol, etc) sont manipulés de part et d'autre. L'espace de stockage temporaire 322 peut être un espace « privé » au sein de l'avionique et dédié au monde ouvert. Dans un mode de réalisation, l'espace de 15 stockage temporaire est un « bac à sable » (« sandbox » en anglais) qui permet au monde ouvert de pouvoir proposer, modifier, faire calculer des données au monde avionique avant de les injecter dans la mission gérée par l'avionique. Dans un mode de réalisation, des mécanismes de comparaison 520 surveillent 20 les évolutions de part et d'autre. Dans certains modes de réalisation, des écarts peuvent en effet persister entre les calculs réalisés du côté du monde ouvert d'une part et du monde avionique d'autre part. Par exemple, le pilote de manière erronée peut penser que l'aéronef est guidé sur un plan de vol modifié, alors que la modification correspondante n'a été faite que du côté monde ouvert (et est 25 peut-être perdue pour le pilote). Les comparaisons peuvent être effectuées selon les schémas temporels 580 de manière continue, de manière intermittente, à intervalles réguliers ou non (e.g. selon des événements au cours du déroulement du vol). 30 Dans un mode de réalisation, l'espace de stockage avionique est implémenté dans le système avionique. Dans ce mode de réalisation, l'espace de stockage est partagé donc accessible aux deux types de systèmes, mais avantageusement hérite des caractéristiques de fiabilité (taux de défaillance 26 physique et niveau de vérification logique) associé à des systèmes de type avionique (dont le degré de fiabilité est supérieur à celui associé à un système de type non-avionique). 5 Dans un mode de réalisation, l'espace de stockage avionique est implémenté dans un système de type non-avionique fiabilisé, dont le taux de panne physique et la vérification logique sont respectivement inférieure et supérieure à ceux d'un système de type non-avionique. Dans un mode de réalisation, un système intermédiaire peut être utilisé. Si un système de gestion de vol FMS existant ne 10 peut pas être modifié pour intégrer l'espace de stockage, un système fiabilisé peut être utilisé. Dans un mode de réalisation, le procédé comprend en outre les étapes consistant à détecter la présence de données critiques prédéfinies dans les 15 données déterminées d'une part par le système avionique et d'autre part par le système non-avionique ; comparer ces données critiques ; afficher les données critiques qui diffèrent via l'interface homme-machine. Des « objets » i.e. une ou plusieurs données « critiques » (ou « essentielles ») 20 peuvent en effet être prédéfinies. Un objet critique (ou essentiel) peut être associé à un risque systémique. Un risque qualifié de «systémique» implique qu'il existe une probabilité (pas seulement non nulle, i.e. non négligeable par rapport à des seuils d'acceptation 25 prédéfinis) de dysfonctionnements majeurs, affectant la sécurité et/ou la sûreté aéronautique. Un événement local, même limité, peut avoir des conséquences globales catastrophiques. Certains objets peuvent entraîner, directement ou risquer d'entraîner indirectement, des risques « systémiques ». 30 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 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). 35 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". 27 Dans un mode de réalisation, un objet peut donc être associé à des métadonnées traduisant niveau de risque local et/ou global, lesquels peuvent être quantifiés ou discrétisés. 5 Les risques peuvent être seuillés (la criticité d'un objet peut être déterminée en excès d'un seuil ou une plage de seuils prédéfinis) Ces objets critiques ou essentiels peuvent être déterminés de différentes 10 manières. Dans un mode de réalisation (« bottom up »), l'historique des différences, modifications et conséquences est enregistré et des analyses de données, exécutées à la main et donc prédéfinies « arbitrairement » et/ou effectuées par 15 apprentissage (e.g. supervisé, non supervisé, big data, approches statistiques, etc) déterminent ces objets, qu'il est possible de qualifier de « critique » ou d' « essentiels »). Dans un mode de réalisation (« top-down »), lesdits objets sont déterminés a 20 priori. Une expertise métier, une expérience du pilotage ou une analyse des risques peut en effet permettre d'identifier des objets particulièrement risqués. Dans un mode de réalisation, les données critiques sont déterminées en temps réel. Dans un mode de réalisation, le caractère essentiel et/ou critique est 25 calculé de fait : les divergences à moyen et long terme sont déterminées et comparées. Par exemple, une modification sur des données concernant un aéroport de déroutement dans un contexte météorologique défavorable conjugué à un niveau de carburant limite peut conduire à évaluer que les conséquences à long terme de ladite modification excède un seuil acceptable. 30 Dans un mode de réalisation, les données considérées comme critiques peuvent être différentes suivant la phase de vol (par exemple une donnée peut être critique à un moment donné et pas à un autre). 35 Dans un mode de réalisation, le caractère essentiel ou critique est déterminé en raison de la présence de données intrusives. La notion d"intrusion" se réfère à 28 une manifestation d'une volonté d'accéder à des ressources physiques ou logiques réservées ou protégées. Certaines ressources avioniques sont plus sollicitées ou plus sensibles que d'autres. Des modifications qui sollicitent ces ressources peuvent être qualifiées d'intrusives. Les ressources protégées 5 peuvent évoluer au cours du temps ("time-driven") et/ou en fonction d'événements ("event-driven"). Dans un mode de réalisation, la détermination de la présence de telles données critiques ou essentielles peut déclencher une alerte. Cette alerte peut prendre la 10 forme d'une boucle de rétroaction avec le pilote (notamment via des validations via l'interface homme-machine, qui peuvent consister en des affichages en mode texte, pour ne pas complexifier outre mesure les interfaces, jusqu'à des présentations détaillées des divergences à terme. 15 Dans le cas d'une divergence (une ou plusieurs différences entre les données critiques), le procédé peut comprendre une étape consistant à montrer au pilote ces différences afin de décider si les données déterminées par le système non-avionique peuvent être conservées et validées. 20 Dans un mode de réalisation, le procédé comprend en outre l'étape consistant à déterminer des risques 535 associés aux différences entre les données comparées. Optionnellement, une aide au pilote peut être proposée pour identifier les différences et/ou les risques sur les données critiques (par exemple, les données dont il est connu des effets systémiques, i.e. dont les effets en 25 cascade peuvent diminuer la sécurité et/ou la sûreté aéronautique). Dans un mode de réalisation, le procédé comprend en outre l'étape consistant à afficher 540 tout ou partie des différences entre les données comparées et/ou des risques associés à ces différences via une interface homme-machine. Le 30 pilote peut visualiser les différences et intervenir le cas échéant. La synchronisation du monde ouvert vers l'avionique et en particulier, l'espace mission de l'avionique dédié au pilote peut être sous contrôle manuel du pilote (au moins dans un premier temps, puis éventuellement sous contrôle automatique à terme). Une variété de dispositifs d'interface homme-machine a 35 été précédemment décrite. 29 Dans un mode de réalisation, le procédé comprend en outre l'étape consistant à modifier 550 tout ou partie des données déterminées dans le système non-avionique. Les modifications peuvent être effectuées à tout moment : après les premiers calculs du monde ouvert et avant la comparaison, après la 5 comparaison, avant l'insertion desdites données (par exemple à des fins de validation), avant activation effective (dans le plan de vol). Depuis le système ouvert vers le système avionique, il est possible d'ajouter, de supprimer, de modifier, d'insérer, de fusionner, et de remplacer des données. Il 10 est possible de montrer les différences qui vont être injectées. Certaines confirmations peuvent être optionnelles, d'autres peuvent être requises (notamment en fonction du type d'objet). Concernant la synchronisation depuis l'avionique, les données peuvent être remplacées en tout ou partie. Les données qui ont été insérées peuvent être affichées. 15 Dans un mode de réalisation, le schéma temporel 580 prédéfini comprend des intervalles de temps prédéfinis, comprenant des instants temporels et des durées, pour comparer et/ou modifier les données. 20 Dans un mode de réalisation, les instants de ces échanges et les durées de ces échanges (la fréquence ou les intervalles temporels de la synchronisation) se font de manière à ce qu'une désynchronisation transitoire des deux types de systèmes ne gêne pas opérationnellement le pilote (typiquement les deux systèmes peuvent rester indépendants pendant une durée maximale d'environ 5 25 secondes). Dans d'autres modes de réalisation, la fréquence des échanges est bien supérieure et le temps de désynchronisation maximal est inférieur à une seconde. Dans d'autres modes de réalisation, des mécanismes de mise en cache permettent d'endurer des pertes d'échanges sur des durées de temps supérieures. 30 Les échanges de données (la synchronisation, dans un sens ou dans l'autre) peut être faite automatiquement de façon périodique, automatiquement sur changement de données, ou encore manuellement, sur action du pilote. Le mode de synchronisation (automatique ou manuel) peut être différent dans un 35 sens et dans l'autre. Dans un mode de réalisation, le mode automatique peut être privilégié (de l'avionique vers le monde ouvert) et le mode manuel peut être 30 privilégié du monde ouvert vers l'avionique. Le type de pattern d'échange proposé peut notamment être optimisé pour minimiser les échanges sur le réseau. De même, des étapes de compression de 5 données peuvent permettre de minimiser la taille des données synchronisées sur le réseau avionique. Dans un mode de réalisation, le procédé comprend en outre l'étape consistant à recevoir une autorisation 560 pour insérer et/ou activer 570 dans le système 10 avionique les données déterminées par le système non-avionique et modifiées le cas échéant. Dans un mode de réalisation, la confirmation ou autorisation peut émaner du pilote. Dans un mode de réalisation, la confirmation peut émaner d'un système tiers, par exemple en lien avec l'homme et/ou la machine (équipe ATC, etc). Finalement le transfert des données de cet espace dédié du monde 15 ouvert vers le domaine avionique est autorisé ou pas par le pilote ou copilote. Le pilote peut être aidé pour cette demande d'autorisation du transfert par une mise en exergue des données critiques qui ont changé et/ou une vérification que le vol proposé est volable par l'avion. 20 Dans un mode de réalisation, l'espace de stockage est sécurisé par un ou plusieurs mécanismes 590 sélectionnés parmi les mécanismes comprenant le chiffrement des données, le contrôle d'intégrité des données ou des mécanismes d'authentification. 25 Dans un mode de réalisation, une ou plusieurs étapes sont déclenchées ou sont fonction du contexte de vol 599. Une ou plusieurs étapes du procédé (type de synchronisation, nature des éléments synchronisés, moments de la synchronisation, etc) peuvent être 30 notamment asservies au contexte de vol 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 vol" comprend par 35 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 31 passage, la procédure en cours (et autres). Par exemple, l'aéronef peut être en phase d'approche pour l'atterrissage, en phase de décollage, en phase de croisière mais également en palier ascendant, palier descendant, etc (une variété de situations peut être prédéfinie). Par ailleurs, le "contexte de vol" 5 courant peut être associé à une multitude d'attributs ou de paramètres descriptifs (état météorologique courant, état du trafic, statut du pilote comprenant par exemple un niveau de stress tel que mesuré par des capteurs, etc). Un contexte de vol peut donc également comprendre des données, par exemple filtrées par priorité et/ou fondées sur des données de phase de vol, des 10 problèmes météorologiques, des paramètres avioniques, des négociations ATC, des anomalies liées au statut du vol, des problèmes liés au trafic et/ou au relief. Des exemples de "contexte de vol" comprennent par exemple des contextes tels que "régime croisière / pas de turbulences / stress pilote nominal" ou bien encore "phase atterrissage / turbulences / stress pilote intense". Ces contextes 15 peuvent être structurés selon divers modèles (e.g. hiérarchisés par exemple en arbre ou selon des dépendances diverses, y compris des graphes). Des catégories de contextes peuvent être définies, de manière à synthétiser les besoins en matière d'interaction homme-machine (e.g. délai d'interaction minimal ou maximal, quantité de mots minimale et maximale, etc). Il peut 20 également subsister des règles spécifiques dans certains contextes, notamment d'urgences ou de situations critiques. Les catégories de contextes peuvent être statiques ou dynamique (e.g. configurables). Le procédé peut être implémenté dans un système comprenant des moyens 25 pour déterminer un contexte de vol de l'aéronef, lesdits moyens de détermination comprenant en particulier des règles logiques, lesquelles manipulent des valeurs telles que mesurées par des moyens de mesure physique. En d'autres termes, les moyens de détermination du "contexte de vol" comprennent des moyens de système ou "hardware" ou physiques/tangibles 30 et/ou des moyens logiques (e.g. des règles logiques, par exemple prédéfinies). Par exemple, les moyens physiques comprennent l'instrumentation avionique au sens propre (radars, sondes, etc) qui permettent d'établir des mesures factuelles caractérisant le vol. Les règles logiques représentent l'ensemble des traitements de l'information permettant d'interpréter (e.g. de contextualiser) les mesures 35 factuelles. Certaines valeurs peuvent correspondre à plusieurs contextes et par corrélation et/ou calcul et/ou simulation, il est possible de départager des 32 "contextes" candidats, au moyen de ces règles logiques. Une variété de technologies permet d'implémenter ces règles logiques (logique formelle, logique floue, logique intuitionniste, etc) 5 Il est décrit un système comprenant des moyens pour mettre en oeuvre une ou plusieurs des étapes du procédé. Dans un mode de réalisation, le système de type avionique comprend un système de gestion de vol FMS. Dans un mode de réalisation privilégié de l'invention, le système avionique est 10 un système avionique FMS de type NG nouvelle génération communiquant via le composant « Open Capacity ». Cette fonction Open Capacity offre la possibilité d'utiliser l'espace de stockage (« sandbox ») selon l'invention. Les ressources de cet espace de stockage sandbox sont alors limitées mais réservées en terme de CPU, espace mémoire, de façon à ne pas gêner l'activité 15 mission opérationnelle du pilote. La fonction Open Capacity fournit plusieurs types de services, selon plusieurs schémas d'échanges, notamment a) du type requête-réponse qui permet de consulter tout type d'information dans les domaines mentionnés ou b) pour modifier, insérer des données dans la l'espace de stockage, c) pour souscrire à des évènements pour être informé de 20 changements dans le monde avionique. Ces évènements peuvent par exemple indiquer quels types de données ont changé et permettent au monde ouvert d'émettre la requête pour obtenir une mise à jour des données et d) pour diffuser périodiquement les principaux changements d'état du système opérés dans le monde avionique. Cette diffusion est disponible pour qui veut bien l'écouter. Il 25 n'est pas nécessaire de s'abonner. Enfin, la fonction d'Open Capacity fournit la possibilité d'injecter les données arrivant du monde ouvert dans la mission opérationnelle après un passage et recalcul via l'espace de stockage. Dans un mode de réalisation, un système de type non-avionique comprend un 30 sac de vol électronique EFB ou une interface homme-machine non-avionique. Dans un mode de réalisation, le système avionique est un système maître et le système non-avionique est un système esclave asservi au système maître. 35 Dans certains modes de réalisation, le système non-avionique et le système avionique sont égaux en termes de privilèges (droits d'accès, de lecture et/ou 33 d'écriture). Dans certains modes de réalisation, le système avionique et le système non-avionique n'endossent pas des rôles à égalité égaux en termes de privilèges 5 (droits d'accès, de lecture et/ou d'écriture). Par exemple, l'un ou l'autre système aura des prérogatives supérieures (e.g. en fonction des données et/ou dans le temps). L'un ou l'autre des systèmes pourra être prioritaire (soit de manière générale, soit pour des fonctions et/ou des données particulières). Par exemple, le système de gestion du vol pourra être considéré comme « le système maître » 10 tandis que le système non avionique pourra endosser le rôle de système asservi (« système esclave »). Il est décrit un produit programme d'ordinateur, ledit programme d'ordinateur comprenant des instructions de code permettant d'effectuer une ou plusieurs 15 des étapes du procédé, lorsque ledit programme est exécuté sur un ordinateur. La présente invention peut s'implémenter à partir d'éléments matériel et/ou logiciel. Elle peut être disponible en tant que produit programme d'ordinateur sur un support lisible par ordinateur. Le support peut être électronique, magnétique, 20 optique ou électromagnétique. Dans un mode de réalisation, le procédé est mis en oeuvre par ordinateur. Dans un mode de réalisation, le système pour la mise en oeuvre de l'invention 25 comprend un support de stockage lisible par ordinateur (RAM, ROM, mémoire flash ou une autre technologie de mémoire, par exemple support à disque ou un autre support de stockage non transitoire lisible par ordinateur) codé avec un programme d'ordinateur (c'est-à-dire plusieurs instructions exécutables) qui, lorsqu'il est exécuté sur un processeur ou plusieurs processeurs, effectue les 30 fonctions des modes de réalisation décrits précédemment. A titre d'exemple d'architecture matérielle adaptée à mettre en oeuvre l'invention, un dispositif peut comporter un bus de communication auquel sont reliés une unité centrale de traitement ou microprocesseur (CPU, acronyme de « Central Processing Unit » en anglais), lequel processeur peut être "multi-core" ou "many-core"; une 35 mémoire morte (ROM, acronyme de « Read Only Memory » en anglais) pouvant comporter les programmes nécessaires à la mise en oeuvre de l'invention; une 34 mémoire vive ou mémoire cache (RAM, acronyme de « Random Access Memoty » 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 5 de « lnput/ouput » en anglais) adaptée à transmettre et à recevoir des données. Dans le cas où l'invention est implantée sur une machine de calcul reprogrammable (par exemple un circuit FPGA), le programme correspondant (c'est-à-dire la séquence d'instructions) peut être stocké dans ou sur un médium 10 de stockage amovible (par exemple une carte SD, ou un stockage de masse tel que un disque dur e.g. un SSD) ou non-amovible, volatile ou non-volatile, ce médium de stockage étant lisible partiellement ou totalement par un ordinateur ou un processeur. Le support lisible par ordinateur peut être transportable ou communicable ou mobile ou transmissible (i.e. par un réseau de 15 télécommunication 2G, 3G, 4G, Wifi, BLE, fibre optique ou autre). La référence à un programme d'ordinateur qui, lorsqu'il est exécuté, effectue l'une quelconque des fonctions décrites précédemment, ne se limite pas à un programme d'application s'exécutant sur un ordinateur hôte unique. Au contraire, 20 les termes programme d'ordinateur et logiciel sont utilisés ici dans un sens général pour faire référence à tout type de code informatique (par exemple, un logiciel d'application, un micro logiciel, un microcode, ou toute autre forme d'instruction d'ordinateur, comme des web services ou SOA ou via des interfaces de programmation API) qui peut être utilisé pour programmer un ou plusieurs 25 processeurs pour mettre en oeuvre des aspects des techniques décrites ici. Les moyens ou ressources informatiques peuvent notamment être distribués ("Cloud computing"), éventuellement avec ou selon des technologies de pair-à-pair et/ou de virtualisation. Le code logiciel peut être exécuté sur n'importe quel processeur approprié (par exemple, un microprocesseur) ou coeur de 30 processeur ou un ensemble de processeurs, qu'ils soient prévus dans un dispositif de calcul unique ou répartis entre plusieurs dispositifs de calcul (par exemple tels qu'éventuellement accessibles dans l'environnement du dispositif). Des technologies de sécurisation (crypto-processeurs, authentification éventuellement biométrique, chiffrement, carte à puce, etc) peuvent être 35 utilisées. 35 Dans certains modes de réalisation, les différentes étapes de la méthode peuvent être implémentées en tout ou partie sur le FMS et/ou sur un ou plusieurs EFB (sacs ou sacoches de vol électroniques) et/ou tablettes et/ou REVENDICATIONS1. Procédé de gestion de données de vol d'un aéronef mis en oeuvre dans un système comprenant un système de type avionique et un système de type non- avionique, le procédé comprenant les étapes consistant à: - déterminer des données de vol dans le système non-avionique ; - stocker lesdites données dans un espace de stockage; - déterminer des données de vol correspondantes dans le système avionique ; - comparer les données déterminées d'une part par le système avionique et d'autre part par le système non-avionique selon un schéma temporel prédéfini. 2. Procédé selon la revendication 1, l'espace de stockage avionique étant implémenté dans le système avionique. 3. Procédé selon la revendication 1, l'espace de stockage avionique étant implémenté dans un système de type non-avionique fiabilisé, dont le taux de panne physique et la vérification logique sont respectivement inférieure et supérieure à ceux d'un système de type non-avionique. 4. Procédé selon la revendication 1, comprenant en outre les étapes consistant à - détecter la présence de données critiques prédéfinies dans les données déterminées d'une part par le système avionique et d'autre part par le système non-avionique ; - comparer ces données critiques ; - afficher les données critiques qui diffèrent via l'interface homme-machine. 5. Procédé selon la revendication 1, comprenant en outre l'étape consistant à déterminer des risques associés aux différences entre les données comparées. 6. Procédé selon la revendication 1, comprenant en outre l'étape consistant à afficher tout ou partie des différences entre les données comparées et/ou des risques associés à ces différences via une interface homme-machine. 7. Procédé selon l'une quelconque des revendications précédentes, comprenant en outre l'étape consistant à modifier tout ou partie des données déterminées 37 dans le système non-avionique. 8. Procédé selon l'une quelconque des revendications précédentes, le schéma temporel prédéfini comprenant des intervalles de temps prédéfinis, comprenant 5 des instants temporels et des durées, pour comparer et/ou modifier les données. 9. Procédé selon l'une quelconque des revendications précédentes, comprenant en outre l'étape consistant à recevoir une autorisation pour insérer et/ou activer dans le système avionique les données déterminées par le système non- 10 avionique et modifiées le cas échéant. 10. Procédé selon l'une quelconque des revendications précédentes, l'espace de stockage étant sécurisé par un ou plusieurs mécanismes sélectionnés parmi les mécanismes comprenant le chiffrement des données, le contrôle d'intégrité 15 des données ou des mécanismes d'authentification. 11. Procédé selon l'une quelconque des revendications précédentes, une ou plusieurs étapes étant déclenchées en fonction du contexte de vol. 20 12. Un produit programme d'ordinateur, ledit programme d'ordinateur comprenant des instructions de code permettant d'effectuer les étapes du procédé selon l'une quelconque des revendications 1 à 11, lorsque ledit programme est exécuté sur un ordinateur. 25 13. Système comprenant des moyens pour mettre en oeuvre les étapes du procédé selon l'une quelconque des revendications 1 à 11. 14. Système selon la revendication 13, un système de type avionique comprenant un système de gestion de vol FMS et un système de type non-30 avionique comprenant un sac de vol électronique EFB ou une interface homme-machine non-avionique. 15. Système selon l'une des revendications 13 à 14, le système avionique étant un système maître et le système non-avionique étant un système esclave 35 asservi au système maître.