FR 3038805 A1 20170113 FR 1501436 A 20150707 1 GESTION DE BASES DE DONNÉES EN AVIONIQUE Domaine de l'invention L'invention concerne le domaine de l'avionique en général. L'invention concerne en particulier des procédés et des systèmes pour le partage de données entre des bases de données de type avionique de formats différents. Etat de la Technique Les systèmes avioniques existants possèdent généralement leurs propres bases de données et doivent échanger des informations relatives à des données élémentaires (par exemple de type point géolocalisé) de ces bases de données. Pour des besoins de navigation ou d'affichage, ils doivent généralement interroger les bases de données des autres systèmes et parfois choisir parmi de nombreux doublons afin d'adresser la donnée adéquate, puisque chaque système peut posséder sa propre manière de gérer en mémoire et organiser lesdites données élémentaires. Dans le cas des bases de données de navigation de type AEEC ARINC 424, ce problème technique se pose fréquemment. Les systèmes avioniques existants doivent nécessairement interroger les bases de données des systèmes tiers avant d'utiliser une donnée 25 élémentaire, de type ARINC 424 par exemple, en particulier pour être certain qu'il s'agit bien de la même donnée élémentaire. Les systèmes doivent alors effectuer des requêtes additionnelles (requête base de données) avant de mener à bien toute action opérationnelle 3038805 2 utilisant une donnée élémentaire, ce qui peut diminuer les performances. Ce problème technique se rencontre dans de nombreuses situations. 5 Par exemple, afin d'améliorer les performances d'interaction avec des systèmes d'affichage de navigation, le FMS (pour « Flight Management System ») et le HSI (pour « Human System Interface ») peuvent chacun embarquer leur propre base de données ARINC 424. Le format et le contenu des bases de données peuvent différer. Par exemple, le HSI peut 10 embarquer des données graphiques qui ne sont pas utiles au FMS et de ce fait non présentes dans la base de données du FMS, mais ces deux systèmes vont avoir dans leur base de données des données élémentaires ARINC 424 (par exemple des éléments de type point géolocalisé utilisé pour construire des structures complexes telles que 15 des procédures de départ/arrivée,..). Un problème technique consiste alors à être certain - ou raisonnablement sûr - qu'une donnée élémentaire identifiée sur le HSI puis transmise au FMS sera correctement interprétée par ce dernier, c'est-à-dire de manière 20 non ambiguë. Un système de gestion de vol FMS peut avoir à se connecter à des systèmes portables externes tels que des cartables électroniques EFB (pour « Electronic Flight Bag », e.g. de type tablette). De tels systèmes possèdent généralement leur propre implémentation de la base de données de navigation (e.g. dans un format spécifique). Dans le cas où le plan de vol du FMS doit être préparé ou mis à jour depuis l'EFB, le problème technique précédent peut se renouveler. Lors du transfert du plan de vol de l'EFB vers le FMS, les éléments constitutifs de ce plan de vol, qui sont généralement des données élémentaires ARINC 424 ou des données élémentaires utilisateur, doivent être correctement interprétés 3038805 3 par le système de gestion de vol FMS. Dans le cadre de la CMU (« Communication management Unit »), par exemple pour la communication numérique sol-air (tel que le « datalink » 5 via AOC/ATC), des incohérences peuvent survenir concernant les échanges en vue de modifications du plan de vol (les données de plan de vol étant constituées de données élémentaires de navigation ARINC 424), puisque les formats des bases de données diffèrent entre AOC (Centre opérationnel de la compagnie aérienne) / ATC (centre de contrôle aérien) 10 et le FMS. Ces incohérences ou inconsistances sont actuellement gérées par des mécanismes comprenant l'envoi de messages d'erreur ou de rejet de transmission lorsqu'une donnée élémentaire n'est pas comprise de 15 manière non ambigüe, mais cette approche présente des limitations ou des désavantages. En appelant "BDD Server System" le système hébergeant la base de données de navigation au format ARINC 424 et "Client System" le 20 système client qui se connecte à ladite base de données, le système client formule des requêtes utilisant le nom alphanumérique de l'élément recherché et il lui est retourné une liste de réponses correspondantes au nom présent dans la requête. Il existe typiquement des dizaines de résultats avec ce même nom dans une base de données mondiale, étant 25 donné que le standard AEEC ARINC 424 requiert généralement deux caractères alphanumériques pour la radionavigation (e.g. NDBs), parfois trois caractères (e.g. VOR, ILS, DMEs) ou bien encore cinq caractères pour nommer les points de passage dits « waypoints ». (e.g. « idents »). Par suite, le système client doit analyser la liste des doublons, et 30 déterminer l'élément approprié (par exemple à l'aide d'informations supplémentaires. Ces analyses génèrent de nombreux calculs lesquels 3038805 4 ont un impact négatif sur la performance générale du système. Il existe un besoin pour des systèmes et procédés permettant de gérer des échanges de données élémentaires entre des systèmes avioniques 5 différents ou hétérogènes. Résumé de l'invention Il est divulgué un procédé mis en oeuvre par ordinateur comprenant les 10 étapes consistant à communiquer une clef d'identification lors d'une requête d'interrogation d'une base de données, ladite clef d'identification comprenant au moins trois sous-parties, une première sous-partie étant associée à un ou plusieurs codes avioniques sélectionnés parmi plusieurs codes prédéfinis, une seconde sous-partie comprenant des informations 15 d'identification d'une donnée élémentaire de ladite base de données et une troisième sous-partie comprenant des informations d'identification subsidiaires de ladite donnée élémentaire; recevoir la clef d'identification et en fonction de ladite clef déterminer la donnée élémentaire. Des développements décrivent l'utilisation de notifications, de calculs de 20 similarité, de communication de la clef au cours du temps, de codes de type ARINC 424 ou propriétaire, de sous parties de clefs prédéfinies ou configurables. Des aspects de logiciel et de système (e.g. FMS, HSI, EFB, AOF, TAXI, ATM/ATC) sont décrits. 25 La présente invention permet à tout système tiers de type "BDD Server System", possédant sa propre base de données AEEC ARINC 424 ou utilisateur, de manipuler ou prendre en compte sans ambiguïté une donnée élémentaire de base de données en communiquant avec d'autres systèmes au moyen d'une seule et unique requête. 30 3038805 5 Avantageusement, la présente invention permet à tout système tiers possédant sa propre base de données de navigation d'identifier et de communiquer avec d'autres systèmes de manière non ambiguë ou non équivoque toute donnée élémentaire (par exemple de type point 5 géolocalisé) d'une base de données de navigation de type ARINC 424, ou plus généralement d'une base de données utilisateur. Selon un aspect de l'invention, la solution technique proposée comprend l'utilisation par le « BDD Server System » d'une clef appelée 10 « Fix Marker » permettant d'identifier de manière unique c'est-à-dire directement et sans ambiguïté chaque donnée élémentaire contenue dans la base de données ARINC 424 ou utilisateur. Cette clef unique comprend notamment des informations (ou des références) relatives aux caractéristiques supplémentaires associées aux données élémentaires. 15 Ladite clef peut être utilisée par tout système en association avec une base de données d'utilisateur ou de navigation ARINC 424 en communication avec un système avionique tiers. Selon un aspect de procédé de l'invention, chaque système client 20 émettant une requête utilisant une donnée élémentaire de base de données à destination d'un système tiers peut identifier ladite donnée élémentaire au moyen de cette clef « Fix Marker ». La définition de ladite clef peut par exemple être partagée entre les différents systèmes. En se fondant sur la définition partagée de cette clef, le système tiers peut 25 déterminer quelle est la donnée élémentaire concernée au sein de sa propre base de données. Dans une situation où une clef serait incorrecte ou fausse ou incohérente, le système tiers peut résoudre le conflit soit par l'envoi d'un message dédié pointant sur ladite incohérente et/ou proposer une alternative à ladite clef Fix Marker, par exemple avec une version qui 30 est cohérente avec ses propres données. 3038805 6 Dans un mode de réalisation, tous les systèmes communiquant de l'information comprenant des données élémentaires envoient concomitamment les clefs Fix Marker correspondantes (par exemple lors des procédures d'arrivée ou de départ, lors de l'édition des plans de vol, 5 etc). Avantageusement, la clé selon l'invention peut être mise en oeuvre au démarrage des systèmes avionique ou pendant l'exécution desdits systèmes (par exemple pendant le vol). 10 Avantageusement, le procédé selon l'invention permet d'éviter les requêtes non nécessaires. Avantageusement, le procédé selon l'invention optimise le stockage des 15 informations, en évitant la création et le maintien d'informations dupliquées. Avantageusement, le procédé selon l'invention permet la coexistence fonctionnelle de différents systèmes ayant des formats de base de 20 données différents. Avantageusement, le temps de réponse du système global est amélioré ou optimisé ou réduit dans la mesure où des requêtes de bases de données pour gérer les doublons sont évitées. 25 Avantageusement, l'invention permet d'établir un langage commun entre différentes bases de données, a priori sans relations préalables les unes avec les autres. Par la définition d'une structure de clef et du contenu de ces différentes clefs (e.g. après analyse de l'ensemble des bases de 30 données présentes dans le système), un « langage commun » (« une colle » ou un « liant ») selon les modalités présentement divulguées 3038805 7 permet avantageusement de tirer parti des différentes informations présentes au sein des bases de données. Un exemple précis permet de saisir l'intérêt opérationnel et concret de l'invention. Dans un système avionique pour l'exemple, une IHM peut être interfacée avec un système 5 FMS qui accède et gère des données de navigation et ce système IHM peut également être en interaction avec un système d'évitement de collision TAWS. En croisant les données, au moyen des procédés et/ou systèmes selon l'invention, l'IHM peut être en mesure de restituer au pilote une vue globale de la situation de l'aéronef, ayant de fait « brisé » 10 les silos de données. Les systèmes et/ou procédés selon l'invention trouveront avantageusement application dans différents environnements, notamment dans le cadre d'un système de gestion de vol FMS embarquant sa propre 15 base de données de navigation AEEC ARINC 424, dans le cadre d'interfaces homme-machine de type HMI ou d'interfaces homme-système de type HSI, pour des cartables de vol électronique de type EFB « Electronic Flight Bag » (par exemple préparation de mission), pour des systèmes de roulage sol AOF (pour « Airport Onboard Function », ou 20 TAXI), pour des systèmes de communication, de radio (e.g. balises radio), de surveillance météorologique (e.g. WxR pour « Weather Radar » ou radar météo, WIMS pour « Weather Information Management system »), de connaissance terrain et de système d'alerte vis à vis du relief (TAWS ou « Terrain Awareness and Warning System »), des systèmes 25 d'évitement de collisions entre aéronefs (TCAS ou « Traffic collision avoidance system ») ou bien encore des systèmes de contrôle de trafic (AT M/ATC). Avantageusement, l'invention s'applique dans des contextes variés 30 (militaire, civil, industriel, etc) et pour des objets variés (avionique mais aussi maritime, drone, etc) 3038805 8 Description des figures Différents aspects et avantages de l'invention vont apparaitre en appui de la description d'un mode préféré d'implémentation de l'invention mais non 5 limitatif, avec référence aux figures ci-dessous : La figure 1 montre un exemple de structure de clef selon l'invention; La figure 2 illustre des exemples de création de clefs selon la norme 10 internationale ARINC 424 ; La figure 3 illustre des exemples d'étapes d'un mode de réalisation du procédé selon l'invention. 15 Description détaillée de l'invention La norme aéronautique internationale ARINC 424 spécifie le format des données de navigation et comprend notamment des données élémentaires telles que les points de passage (waypoints), les aéroports 20 ou les pistes d'atterrissage. Les données brutes sont fournies par les états membre de l'Organisation de l'Aviation civile Internationale (OACI) et correspondent aux procédures aéronautiques applicables dans leur pays. Les données brutes sont 25 utilisées à la fois par les acteurs sol (ATC : Centre de contrôle aérien, AOC pour « compagnie aérienne ») et bord (systèmes de navigation embarquées de type FMS, systèmes de roulage AOF, interfaces homme-machine IHM). Pour les systèmes de gestion du vol, une norme internationale d'interchangeabilité a été définie pour permettre aux 30 avionneurs et aux constructeurs d'équipements avioniques d'utiliser un 303 8 805 9 format cohérent et partagé. Il s'agit de l'AEEC ARINC 424. Cette norme explicite la manière d'encoder les données brutes des états, dans un format défini. 5 Pour d'autres équipements, d'autres normes ont été parfois déployées, comme la norme AEEC ARINC 816 qui définit la manière d'encoder les données brutes pour un système de roulage sur surface aéroportuaire (AOF). Un autre format d'échange standard a été proposé pour un « serveur de bases de données de navigation autonome » (qui ne serait 10 plus par exemple inclus dans un FMS) sous la forme de la norme d'encodage AEEC ARINC 829 (Navigation Data Base Open Standard). En complément des données issues de bases de donnée de navigation A424 issue des données étatiques, les systèmes de gestion du vol (ou 15 autres) comportent également une ou plusieurs bases de données utilisateur, qui regroupe des données créées soit par la compagnie aérienne pour ses propres besoins, soit par le pilote lorsqu'il doit manipuler un élément géographique qui n'existe pas dans sa base de donnée A424. Les bases de données utilisateur (connues sous les noms 20 de « Pilot NAVDB » « User Database » par exemple) comprennent à la fois des données élémentaires utilisateur et des structures de données complexes regroupant des données élémentaires de type ARINC 424 et des données élémentaires de type utilisateur. Les données élémentaires de type utilisateur sont généralement similaires aux données 25 élémentaires de type ARINC 424. Dans certains cas, les données élémentaires de type utilisateur comprennent moins d'informations, étant créés par l'utilisateur soit sur un système de gestion de vol FMS ou par un système au sol de la compagnie aérienne (par exemple leur définition ou contenu est spécifique au système considéré). 30 Les données élémentaires sont appelées « fix » (pluriel « fixes »). Des 3038805 10 données complexes peuvent utiliser ou être dérivées de ces données élémentaires. Par exemple des procédures d'arrivée ou de départ de l'aéronef identifiées par leur nom sont constituées d'une succession d'éléments de base (« fix ») comme l'indique la norme A424. Les 5 « Airways » (couloirs aériens ou routes aériennes) sont également identifiées par leur nom, et constituées également d'une succession d'éléments de base (« fix »). Les données sont contenues dans différents enregistrements ou « records » selon la terminologie A424. La structure des enregistrements peut être spécifique à chaque type de donnée. Un 10 enregistrement comprend généralement des informations parmi lesquelles le « Customer Area » (appelé ICAO), spécifiant la zone géographique de l'élément, un code spécifiant le type de données élémentaires (par exemple le type de balise), et également un identifiant. D'autres données peuvent être associées aux éléments de la base de 15 données de navigation A424, comme le décrit la norme. Par exemple la position géographique en Lat/Long de l'élément, une contrainte d'altitude sur l'élément, un moyen de radionavigation associé à l'élément etc. Différents modes de réalisation sont décrits ci-après. 20 Il est divulgué un procédé mis en oeuvre par ordinateur comprenant les étapes consistant à communiquer une clef d'identification lors d'une requête d'interrogation d'une base de données, ladite clef d'identification comprenant au moins trois sous-parties, une première sous-partie étant 25 associée à un ou plusieurs codes avioniques sélectionnés parmi plusieurs codes prédéfinis, une seconde sous-partie comprenant des informations d'identification d'une donnée élémentaire de ladite base de données et une troisième sous-partie comprenant des informations d'identification subsidiaires de ladite donnée élémentaire; recevoir la clef d'identification 30 et en fonction de ladite clef déterminer la donnée élémentaire. 3038805 11 Structurée selon un mode de réalisation de l'invention, la clef d'identification permet avantageusement de lever une ou plusieurs ambiguïtés d'identification de ladite donnée élémentaire lors d'opérations de comparaison entre bases de données hétérogènes (e.g. formats de 5 données différents et/ou sources ou contextes ou données différentes, etc). La clé (généralement unique, variable/configurable ou prédéfinie/configurée) permet l'identification, de manière non univoque, d'une ou de plusieurs données élémentaires présentes au sein des bases de données. 10 La première sous-partie permet d'effectuer un pré-tri rapide dans les bases de données. Une fois déterminée, cette sous-partie (« fix type ») est invariable. 15 La seconde sous-partie est de taille variable. Une fois initialisée, cette seconde sous-partie est déterminée. Elle permet - généralement à elle-seule - d'identifier la donnée élémentaire considérée, i.e. de désambiguer les résultats. 20 Dans la plupart des situations, ces deux premières sous-parties peuvent être nécessaires et suffisantes pour l'identification correcte d'une donnée élémentaire recherchée. Toutefois, dans certains cas, une troisième sous-partie de clef est mise à contribution pour lever une ou plusieurs ambiguïtés qui seraient résiduelles : les informations de « réserve » sont 25 mises à contribution. Dans certains modes de réalisation, cette troisième sous-partie sert de « mémoire »; les informations utiles aux identifications par exemple s'accumulant au cours du temps. Par exemple, peuvent s'accumuler des informations relatives aux mises à jour ARINC 424, des clarifications d'identification pour désambiguer certains conflits ou 30 collisions d'identification, etc. L'accumulation peut s'effectuer au fur et à mesure que la clef est transmise de proche en proche ou de pair à pair. 3038805 12 Dans un mode de réalisation, la seconde sous-partie comprend des informations prédéfinies permettant l'identification de ladite donnée élémentaire lors d'opérations de comparaison de données entre lesdites 5 bases de données de formats différents, lesdites informations prédéfinies d'identification étant partagées entre les bases avioniques et la troisième sous-partie qui est configurable comprend des informations additionnelles subsidiaires permettant de lever une ou plusieurs ambiguïtés d'identification de ladite donnée élémentaire qui seraient résiduelles. 10 Les différents modes de réalisation permettent avantageusement d' «unifier» les bases de données considérées. La clef (e.g. fichier, vecteur, données, chaîne de caractères, métadonnées, etc) possède plusieurs « niveaux internes » (i.e. les différentes sous-parties selon les 15 définitions fournies) dont la hiérarchisation se révèle avantageuse, car elles permettent un tri d'abord rapide (vitesse de tri algorithmique), puis une identification efficace et enfin une solution de clarification résiduelle ou ultime le cas échéant. 20 Dans un développement, le procédé comprend en outre une étape consistant à émettre une notification si l'existence et/ou le contenu de la donnée élémentaire ne sont pas déterminés. L'existence de la donnée élémentaire peut être déterminée sans que son 25 contenu soit accessible, ou établi, ou vérifié ou autrement déterminé. Si la donnée élémentaire n'est pas déterminée (existence ou bien contenu non déterminé) ou est indéterminée (par exemple son absence est positivement déterminée ou son existence ne peut pas être positivement affirmée), un retour d'information est néanmoins utile et avantageux pour 30 le pilote et plus généralement pour le pilotage de l'aéronef (e.g. intégration de systèmes). 3038805 13 Dans un développement, le procédé comprend en outre une étape consistant à déterminer une clef similaire d'identification si la donnée élémentaire est indéterminée. 5 Différents mécanismes pour déterminer une similarité entre les clefs sont possibles: méthode soustractive, calcul de distance, etc. Ce mode de réalisation permet de toujours fournir une réponse (i.e. au moins une réponse, a minima « la plus proche ») dans le cas où mêmes les 10 informations de la sous-partie ne parviendraient pas à lever une ambigüité résiduelle. Si une somme de contrôle peut être utilisée (CRC ou fonction de hachage MD5 ou SHA1) pour des identifications rapides et sûres, une recherche 15 « par similarité » permet a contrario d'identifier des ensembles de « candidats » (clefs et/ou données élémentaires). Dans un développement, le procédé comprend en outre une étape consistant à déterminer une donnée élémentaire similaire si la donnée 20 élémentaire est indéterminée. A l'instar ou en correspondance avec la détermination d'une clef similaire, une réponse (i.e. une donnée élémentaire) similaire peut être déterminée. Le cas échéant, des métadonnées accompagnent la restitution de la 25 donnée élémentaire (par exemple un intervalle de confiance statistique est indiqué si la similarité est effectuée selon une approche probabiliste, etc). Dans un développement, l'étape consistant à communiquer la clef 30 d'identification est répétée au cours du temps et/ou est associée à des événements de vol prédéfinis. 3038805 14 La communication peut être effectuée à la demande du pilote mais elle peut aussi être automatique (e.g. préemptive). Un événement de vol prédéfini peut être par exemple une étape particulière d'une procédure 5 d'arrivée ou de départ, une action d'édition d'un plan de vol, etc. En d'autres termes, la communication d'une ou de plusieurs clefs peut être déclenchée manuellement (requête du pilote) mais également de manière automatique (e.g. intervalle régulier, intermittent, périodique, etc). 10 Dans un développement, le code prédéfini de la première sous-partie étant un code de type ARINC 424. Ce mode de réalisation permet de manière concrète et opérationnelle de consolider (e.g. faire dialoguer) des bases de données avioniques 15 hétérogènes, ce qui améliore la gestion du vol de l'aéronef (e.g. profondeur de perspective quant au pilotage, flexibilité des missions, optimisations des trajectoires, économies de carburant, sécurité du vol améliorée, etc). 20 Dans un développement, le code prédéfini de la première sous-partie étant un code configurable de type propriétaire. Ce mode de réalisation de l'invention permet d'obtenir un système de gestion de données ouvert et flexible. Une mission de vol de type civil 25 saura par exemple coexister avec une mission de type militaire. Par exemple, le pilote peut définir ou prendre en compte des points de largage de parachutistes. Concernant la configuration proprement dite, une convention de 30 nommage, si elle est contrainte et/ou si elle évite les collisions ou des conflits permettra d'établir des passerelles entre bases de données 3038805 15 hétérogènes ou a priori sans rapport les unes avec les autres. L'usage des clefs selon l'invention permet alors d'établir une vision unificatrice ou globale de la situation de l'aéronef. 5 Dans un développement, la troisième sous-partie est prédéfinie. Dans un mode de réalisation, la troisième sous partie est spécifique ou adaptée ou personnalisée selon la donnée élémentaire considérée de la base de données ARINC 424. 10 Dans un développement, la troisième sous-partie est configurable. Dans un autre mode de réalisation, la troisième sous partie est configurable. La possibilité de configurer la troisième sous-partie permet 15 par exemple de gérer les mises à jour par exemple (e.g. de mettre à jour les clefs d'identification, pour désambiguer l'identification ou la détection des données élémentaires). La possibilité de configurer la troisième sous-partie de chaque clef, ou d'au moins une clef, par exemple à tout moment, signifie notamment que cette clef est globalement de taille 20 variable. Il est divulgué un système de gestion de données de type avionique comprenant des moyens pour mettre en oeuvre une ou plusieurs des étapes du procédé. 25 Dans un développement, le système comprend une ou plusieurs bases de données de type avionique, lesdites bases de données étant hétérogènes et/ou de formats différents ; au moins une clef d'identification unique associée à une donnée élémentaire, ladite clef comprenant au 30 moins trois sous-parties, une première sous-partie étant associée à un ou plusieurs codes avioniques sélectionnés parmi plusieurs codes prédéfinis, 3038805 16 une seconde sous-partie comprenant des informations d'identification d'une donnée élémentaire et une troisième sous-partie comprenant des informations d'identification subsidiaires de la donnée élémentaire; un ou plusieurs serveurs pour le traitement de données élémentaires, au moins 5 un des serveurs ayant accès à l'au moins une clef d'identification. La définition de la clef, c'est-à-dire la connaissance de la structure de la clef (sa « documentation »), par exemple en trois sous-parties, est au moins accessible à une entité physique du système qui en a besoin. Dans 10 certains modes de réalisation, les serveurs possèdent chacun ou partagent la connaissance de la structure de la clef. Dans un mode de réalisation, cette documentation est accessible à la demande d'une entité système qui en ressentirait le besoin. Un serveur au sens de l'invention est une entité physique adaptée à traiter les données et à communiquer 15 les données entrantes et sortantes (I/O). Une base de données, selon une définition particulière est un entrepôt de données ; il n'est pas nécessaire qu'une base de données possède la connaissance de la structure de la clef d'unification. En revanche, il doit exister au moins un serveur disposant de la connaissance de la structure de la clef et ce 20 serveur doit pouvoir informer de proche en proche, directement ou indirectement d'autres serveurs composant le système selon l'invention. Dans un développement du système, le code prédéfini de la première sous-partie est un code de type ARINC 424. 25 Dans un développement du système, le code prédéfini de la première sous-partie est un code configurable de type propriétaire. Dans un développement du système, la troisième sous-partie est prédéfinie. Dans un développement du système, la troisième sous-partie est configurable. 30 3038805 17 Dans un mode de réalisation d'un système selon l'invention, la troisième sous partie est configurable. La possibilité de configurer la troisième sous-partie permet par exemple de gérer les mises à jour par exemple (e.g. de mettre à jour les clefs d'identification, pour désambiguer l'identification ou 5 la détection des données élémentaires). La possibilité de configurer la troisième sous-partie de chaque clef, ou d'au moins une clef, par exemple à tout moment, signifie notamment que cette clef est globalement de taille variable. 10 Dans un développement, le système comprend un système avionique de gestion de vol de type FMS pour Flight Management System. Dans un développement, le système comprend en outre un ou plusieurs systèmes choisis parmi un système avionique de type HSI pour Human System 15 Interface, un cartable de vol électronique EFB, un système de roulage sol AOF ou TAXI, un système de communication, de radio, de surveillance météorologique, de connaissance terrain, de système d'alerte collision ou relief ou un système de contrôle de trafic ATM ou ATC. Les données peuvent être des données avioniques, par exemple des données de navigation ou bien 20 encore des données de radiocommunication. La figure 1 montre un exemple de structure de clef selon l'invention. Dans un mode de réalisation, l'invention procède à la combinaison 25 d'informations accessibles afin d'obtenir une clef 100 unique pour chaque donnée élémentaire de bases de données de type ARINC 424. Dans un mode de réalisation, la clef selon l'invention comprend deux parties distinctes. 30 La première partie 110 identifie le type du « fix », par exemple en 303 8 805 18 association avec un code ou un sous code ARINC 424 (ou selon une alternative, en association avec un code propriétaire utilisé dans une base de données d'utilisateur). L'identifiant du type peut être codé sur 2 octets, 1 octet pour coder un sous-champ appelé « section » dans la norme et un 5 octet pour coder un sous-champ appelé « subsection ». La seconde partie de la clef 120 comprend deux sous-parties 121 et 122. La sous-partie 121 comprend une partie de l'identification de l'objet. Pour toutes les données élémentaires de l'ARINC 424, la sous-partie 121 10 contient l'identification de cette donnée élémentaire au sens ARINC 424 (« Ident » dans le record ARINC). Pour les données élémentaires des bases de données de type « user », chaque système peut définir sa propre règle pour « 121 » (et plus généralement sa propre décomposition la sous-partie 120 en sous-parties 121 et 122. 15 La sous-partie 122 comprend des informations complémentaires permettant de lever toute ambiguïté résiduelle; par exemple, ICAO code pour des points de plan de vol « waypoints », les pistes d'atterrissage d'aéroport, etc..). Dans un mode de réalisation particulier, cette seconde 20 partie de clef 120 peut être prédéterminée. De la sorte, au moyen de l'agrégation des deux parties 110 et 120, les données élémentaires des bases de données sont ou peuvent être identifiées par une clef unique « Fix Marker» 100 et la manipulation de 25 doublons est évitée. Dans un mode de réalisation, au moins une des deux sous parties est spécifique ou adaptée ou personnalisée selon la donnée élémentaire considérée de la base de données ARINC 424. 30 La figure 2 illustre un exemple de création de clefs « Fix Marker » selon 3038805 19 l'invention pour des données élémentaires de bases de données de type ARINC 424 et des données élémentaires de type utilisateur. En ce qui concerne les bases de données utilisateur, elles comprennent à 5 la fois (a) des données élémentaires utilisateur et (b) des structures de données complexes lesquelles comprennent (i) des données élémentaires de type ARINC 424 et (ii) des données élémentaires de type utilisateur. Les données élémentaires de type utilisateur (ii) sont généralement similaires aux données élémentaires de type ARINC 424 10 (i). Dans certains cas, les données élémentaires de type utilisateur (ii) comprennent moins d'information, étant créées par l'utilisateur soit sur un système de gestion de vol FMS ou par un système au sol (par exemple leur définition ou contenu peut être spécifique au système considéré). 15 En ce qui concerne les données de type navigation ARINC 424, le champ indiqué « réserve » correspond à 1 bit d'information non utilisé, puisque toutes les informations spécifiées dans le tableau contribuent à garantir l'unicité de chaque donnée élémentaire de la base de données. Si des mises à jour de la base de données ARINC 424 infirment cette assertion, 20 la « réserve » peut par suite être utilisée afin de rétablir ladite unicité. En ce qui concerne les données élémentaires de type utilisateur, les champs « type » et « identification » sont indiquées sous le statut «réserve» dans l'exemple présenté; chaque système peut en réalité spécifier ses propres champs. Par exemple, ces spécifications peuvent constituer des sous- 25 ensembles de données équivalentes de type ARINC 424 ou bien des clefs définies et utilisables par chaque système «BDD Server System ». Les figures 3A, 3B et 3C illustrent différents exemples et les étapes correspondantes du procédé selon l'invention. 30 La figure 3A montre un exemple en matière de gestion de fréquence d'un 3038805 20 aéroport. Dans cet exemple, la base de données 341 peut ne pas disposer des fréquences de la tour de contrôle d'un aéroport donné, au contraire de la 5 base de données 342. L'application 330 fournit alors la liste des aéroports issus de la base 341 et l'application 310 va pouvoir extraire de la base 342 les fréquences radios des aéroports identifiés par l'application 330. L'utilisation de clefs 10 d'identification permet de garantir que la liste des aéroports est non ambiguë. La figure 3B montre un exemple en matière de gestion des plans de vol. 15 Dans cet exemple, l'application 330 émet à destination de l'application 310 un simple plan de vol. L'application 310 affiche alors le plan de vol reçu de l'application 330 ainsi que, le cas échéant, des données élémentaires situées soit autour de la 20 position avion, soit autour d'une position décentrée correspondant à la position d'un curseur sur l'affichage par exemple. Ces données élémentaires peuvent provenir de la base 342 par exemple. L'application 310 émet à destination de 320 ces données élémentaires. 25 Ensuite, l'application 310 peut émettre une requête de modification de plan de vol (par exemple des insertions de points) à destination de l'application 330 en utilisant des données élémentaires affichées par l'application 310: L'application 310 va alors « fabriquer » la clé de ces 30 données élémentaires grâce à la définition partagée et envoyer les requêtes de modification avec ces clés à l'application 330. L'application 3038805 21 310 pourra afficher des informations sur un point du plan de vol émis par l'application 330 en utilisant la clé de cet élément et en allant chercher dans sa propre base de données 342 les informations à afficher. 5 A son tour, l'application 320 pourra émettre une requête de modification de plan de vol (par exemple des insertions de points) à destination de l'application 330 en utilisant la clé des « nearests » (dans ce cas, nul besoin de fabrication de clé, uniquement d'utilisation des clés des données élémentaires reçues) et l'application pourra afficher des 10 informations sur un point du plan de vol, ou une donnée élémentaire, émis par l'application 330 en envoyant une requête d'informations à 310 ou 330 utilisant la clé de cet élément. La figure 3C montre une application de système de gestion de vol FMS 15 330 hébergeant une base de données de navigation de type ARINC 424 (341), selon un premier format; une première application 310 (par exemple d'affichage) connectée au système de gestion de vol FMS hébergeant une base de données de navigation de type ARINC 424 (342), selon un second format; et une seconde application 320 (par 20 exemple d'affichage) connectée au système de gestion de vol FMS et n'hébergeant pas de base de données. Les bases de données 341 et 342 sont deux instances de bases A424 portées par deux équipements différents, le format et le contenu de ces 25 deux bases peuvent être différents (les deux équipements peuvent ne pas avoir les mêmes besoins). Dans une première étape, le système de gestion de vol FMS communique le plan de vol en utilisant entre autres l'information de clef 30 Fix Marker (par exemple en provenance de sa base de données 341 ARINC 424 ou utilisateurs), et ce pour chaque segment du plan de vol. La 303 8 805 22 première application d'affichage 310 affiche le plan de vol ainsi que les données élémentaires additionnelles (342) de type ARINC 424 (par exemple les « waypoints », et/ou balises de radionavigation et/ou aéroports etc à proximité du plan de vol). La seconde application 5 d'affichage 320 affiche également le plan de vol. Dans une seconde étape, l'utilisateur final (e.g. le pilote) sélectionne une donnée élémentaire affichée sur le système d'affichage 320 (e.g. correspondant à une donnée additionnelle de type ARINC 424 telle 10 qu'affichée et issue de 342) et émet une requête en vue d'ajouter cette donnée élémentaire au plan de vol courant. Par suite, une requête d'insertion dans le plan de vol comprenant la clef Fix Marker est communiquée au système de gestion de vol FMS 330. Ledit FMS identifie de manière non univoque la donnée élémentaire de type ARINC 424 qui 15 doit être insérée dans le plan de vol au moyen de l'information contenue dans la clef Fix Marker. Le système de gestion de vol FMS 330 valide puis insère la donnée élémentaire issue de 342 dans le plan de vol puis met à jour le plan de vol et finalement renvoie le résultat à la première application et à la seconde application, pour affichage du résultat à 20 l'écran. Dans une troisième étape, l'utilisateur final sélectionne un segment du plan de vol et une donnée élémentaire de terminaison de ce segment via l'application d'affichage 2 et requiert de l'information concernant la 25 sélection. Une requête en ce sens et donc envoyée au système de gestion de vol FMS accompagné de la clef Fix Marker correspondante. En retour, le système de gestion de vol FMS identifie la donnée élémentaire de type ARINC 424 utilisateur appropriée puis communique l'information détaillée associée avec ladite donnée élémentaire. 30 De manière générale, chaque "BDD Server System" peut communiquer 3038805 23 de l'information comprenant une clé Fix Marker chaque fois qu'une donnée élémentaire est manipulée (par exemple lors de la communication d'un plan de vol) ; le système client recevant cette information peut par la suite répondre audit "BDD Server System" en utilisant cette information 5 de clef Fix Marker. Avantageusement selon l'invention, il est défini une clef servant de « langage commun » entre bases de données hétérogènes. Cette clef est structurée d'une manière permettant son évolutivité. 10 Selon un mode de réalisation de l'invention, une clef selon l'invention est obtenue par une agrégation qui est spécifique suivant l'objet manipulé dans la base de données A424. Il en résulte un nouvel objet i.e. « la clé » qui permet l'identification. Des clés peuvent être également générées pour des bases non 15 A424 ou propriétaire réservant au niveau système une plage de valeur dans la partie « 110 » qui spécifie le type d'objet manipulé. Les communications entre bases de données s'effectuent au moyen de cette clé d'identification unique. Les bases de données ne communiquent plus via des 20 paramètres qui diffèrent suivant les objets manipulés. En d'autres termes, la communication s'effectue via une clé d'identification au format unique en lieu et place d'une communication via des paramètres qui diffèrent suivant l'objet manipulé dans la base A424. 25 En général, les états ou l'identification des bases de données peuvent être vérifiés de diverses manières (e.g. au chargement des données, au démarrage du système, de manière dynamique pour une communication particulière vers un système distant, dans le cas d'une reconfiguration etc). 30 La clef selon l'invention permet d'identifier un objet d'une base de données sans information temporelle (à l'instar d'un numéro de sécurité 3038805 24 sociale qui identifie un individu tout au long de sa vie). Un objet (par exemple un aéroport, une balise VOR, une balise DME, ILS, une procédure, etc) est identifié par une clé, laquelle va servir de lien pour tous les équipements et pour toutes les bases de données du système 5 considéré. La définition de la clé est partagée avec tous les systèmes de type « BDD Server System » afin qu'ils puissent la construire à chaque fois qu'ils en ont besoin. Concernant les systèmes de type « Client System », ils 10 utilisent la clé qui leur a été fournie pour interagir avec cet élément, sans avoir besoin de comprendre sa définition. Le « Client System » conserve donc en mémoire la clé associée à chaque donnée reçue d'un « BDD Server System » tant que cette donnée est valide. Par exemple, lorsqu'un équipement fournit la liste des aéroports autour de la position de l'avion, il 15 émet dans cette liste pour chaque aéroport sa clé d'identification (Fix marker) plus d'autres éléments, par exemple son nom et sa position. Les équipements qui reçoivent cette liste vont se servir de la clé d'identification (Fix marker) pour effectuer d'autres traitements. Par exemple demander à un autre équipement « BDD Server System » des 20 informations liées telles que les fréquences de la tour ou les « charts » pour les approches de cet aéroport. 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 25 d'ordinateur sur un support lisible par ordinateur. Le support peut être électronique, magnétique, optique, électromagnétique ou être un support de diffusion de type infrarouge. 30 REVENDICATIONS1. Procédé mis en oeuvre par ordinateur comprenant les étapes consistant à : - communiquer une clef d'identification lors d'une requête d'interrogation d'une base de données, ladite clef d'identification comprenant au moins trois sous-parties, une première sous-partie 110 étant associée à un ou plusieurs codes avioniques sélectionnés parmi plusieurs codes prédéfinis, une seconde sous-partie 121 comprenant des informations d'identification d'une donnée élémentaire de ladite base de données et une troisième sous-partie 122 comprenant des informations d'identification subsidiaires de ladite donnée élémentaire; - recevoir la clef d'identification et en fonction de ladite clef déterminer la donnée élémentaire. 2. Procédé selon la revendication 1, comprenant en outre une étape consistant à émettre une notification si l'existence et/ou le contenu de la donnée élémentaire ne sont pas déterminés. 3. Procédé selon l'une quelconque des revendications précédentes, comprenant en outre une étape consistant à déterminer une clef similaire d'identification si la donnée élémentaire est indéterminée. 4. Procédé selon l'une quelconque des revendications précédentes, 25 comprenant en outre une étape consistant à déterminer une donnée élémentaire similaire si la donnée élémentaire est indéterminée. 5. Procédé selon l'une quelconque des revendications précédentes, l'étape consistant à communiquer la clef d'identification étant répétée au 30 cours du temps et/ou étant associée à des événements de vol prédéfinis. 3038805 26 6. Procédé selon la revendication 1, le code prédéfini de la première sous-partie 110 étant un code de type ARINC 424. 7. Procédé selon la revendication 1, le code prédéfini de la première 5 sous-partie 110 étant un code configurable de type propriétaire. 8. Procédé selon l'une quelconque des revendications précédentes, la troisième sous-partie 122 étant prédéfinie. 10 9. Procédé selon l'une quelconque des revendications précédentes, la troisième sous-partie 122 étant configurable. 10. Système de gestion de données de type avionique comprenant des moyens pour mettre en oeuvre l'une quelconque des revendications 1 à 9. 15 11. Système selon la revendication 10, comprenant : - une ou plusieurs bases de données de type avionique, lesdites bases de données étant hétérogènes et/ou de formats différents ; - au moins une clef d'identification unique associée à une donnée 20 élémentaire, ladite clef comprenant au moins trois sous-parties, une première sous-partie 110 étant associée à un ou plusieurs codes avioniques sélectionnés parmi plusieurs codes prédéfinis, une seconde sous-partie 121 comprenant des informations d'identification d'une donnée élémentaire et une troisième sous-partie 122 comprenant des informations d'identification subsidiaires de la donnée élémentaire; - un ou plusieurs serveurs pour le traitement de données élémentaires, au moins un des serveurs ayant accès à l'au moins une clef d'identification. 12. Système la revendication 10, le code prédéfini de la première sous-30 partie 110 étant un code de type ARINC 424. 3038805 27 13. Système selon la revendication 10, le code prédéfini de la première sous-partie 110 étant un code configurable de type propriétaire. 14. Système selon l'une quelconque des revendications 10 à 13, la 5 troisième sous-partie 122 étant prédéfinie. 15. Système selon l'une quelconque des revendications 10 à 14, la troisième sous-partie 122 étant configurable. 10 16. Système selon l'une quelconque des revendications 10 à 15, comprenant un système avionique de gestion de vol de type FMS pour Flight Management System. 17. Système la revendication 16, comprenant en outre un ou plusieurs systèmes 15 choisis parmi un système avionique de type HSI, un cartable de vol électronique EFB, un système de roulage sol AOF ou TAXI, un système de communication, de radio, de surveillance météorologique, de connaissance terrain, de système d'alerte collision ou relief ou un système de contrôle de trafic ATM ou ATC. 20 2530