FR 3074007 A1 20190524 FR 1701211 A 20171121 Procédé d'émission d'un message de données à destination d'un dispositif électronique récepteur, dispositif électronique émetteur et programme d'ordinateur associés La présente invention concerne un procédé d'émission d'un message de données à destination d'au moins un dispositif électronique récepteur, le procédé étant mis en oeuvre par un dispositif électronique émetteur, le dispositif émetteur et le ou les dispositifs récepteurs étant reliés via un réseau avionique embarqué à bord d'un aéronef, au moins un dispositif parmi le dispositif émetteur et le dispositif récepteur étant un dispositif avionique embarqué à bord de l'aéronef. Le procédé d'émission comprend la génération d'un message de données, le message comprenant un en-tête de message et un ou plusieurs paquets de données, et l'émission du message généré à destination du dispositif récepteur. La présente invention concerne aussi un programme d'ordinateur comportant des instructions logicielles qui, lorsqu'elles sont exécutées par un ordinateur, mettent en oeuvre un tel procédé d'émission. La présente invention concerne également un dispositif électronique émetteur configuré pour émettre un message de données à destination d'un ou plusieurs dispositifs électronique récepteur, le dispositif émetteur et le ou les dispositifs récepteurs étant aptes à être reliés via un réseau avionique embarqué à bord d'un aéronef, au moins un dispositif parmi le dispositif émetteur et le dispositif récepteur étant un dispositif avionique destiné à être embarqué à bord de l'aéronef. La présente invention concerne le domaine de la communication de données et de l'interfaçage fonctionnel à travers un réseau avionique entre deux dispositifs électroniques, au moins un dispositif étant destiné à être embarqué à bord d'un aéronef. Un dispositif électronique est par exemple un serveur fonctionnel, configuré pour mettre en oeuvre une fonction, telle qu'une fonction avionique, tel qu'un système de gestion de vol ou FMS (de l'anglais Flight Management System), un système de gestion de radio ou RMS (de l'anglais Radio Management System), un système d'alerte terrain ou TAWS (de l'anglais Terrain Awareness and Warning System), un système radar de météorologie, un récepteur AIS (de l'anglais Avionics Interface Systems), ou encore un système de préparation de mission, et l'autre dispositif électronique est par exemple un système d'affichage, tel qu'un système d'affichage dans le cockpit ou CDS (de l'anglais Cockpit Display System) ou un dispositif d'affichage tête haute ou HUD (de l'anglais Head-Up Display), ou un cartable de vol électronique ou EFB (de l'anglais Electronic Flight Bag), ou encore un autre serveur fonctionnel, l'autre dispositif étant alors un serveur mettant en 2 oeuvre une autre fonction. L'invention concerne alors par exemple un échange de données entre un système de gestion de vol ou FMS et un système de gestion de radio ou RMS. 5 Les réseaux de communication les plus utilisés pour interfacer les systèmes des aéronefs actuels sont des réseaux de communication conformes au protocole ARINC 429 qui offre une faible bande passante, avec un débit jusqu'à 100 kbit/s, et des réseaux de communication conformes à la partie 7 du protocole ARINC 664 qui sont des réseaux commutés avec un débit jusqu'à 100 Mbit/s. 10 On connait également des réseaux de communication conformes au protocole ARINC 661 ou au protocole ARINC 739. Ces protocoles ARINC 661 et ARINC 739 permettent de supporter l'interface entre un système avionique fonctionnel et un système d'affichage. Avec le protocole ARINC 661, les échanges se font sur des objets graphiques qui sont hébergés dans le système d'affichage et pilotés par le système avionique 15 fonctionnel. Le protocole ARINC 661 permet de limiter significativement le volume de données échangées car seules les données requises à un instant donné sont fournies par le système avionique fonctionnel. Avec le protocole ARINC 739, les informations échangées sont des appuis clavier et des caractères à afficher. Toutefois, ces protocoles ne sont pas adaptés pour gérer efficacement des 20 échanges de données, en particulier des échanges fonctionnels, entre tous les systèmes avioniques dont au moins un est embarqué à bord de l'aéronef, ces échanges se caractérisant principalement par un nombre important de données différentes et de nombreuses occurrences. 25 Le but de l'invention est alors de proposer un procédé d'émission et un dispositif électronique émetteur associé, qui permettent de s'adapter plus facilement aux différents types de données à échanger à bord de l'aéronef. A cet effet, l'invention a pour objet un procédé d'émission d'un message de données à destination d'au moins un dispositif électronique récepteur, le procédé étant 30 mis en oeuvre par un dispositif électronique émetteur, le dispositif émetteur et le ou les dispositifs récepteurs étant reliés via un réseau avionique embarqué à bord d'un aéronef, au moins un dispositif parmi le dispositif émetteur et le dispositif récepteur étant un dispositif avionique embarqué à bord de l'aéronef, le procédé comprenant : - la génération d'un message de données, le message comprenant un en-tête de 35 message et un ou plusieurs paquets de données, et - l'émission du message généré à destination du ou des dispositifs récepteurs, 3 chaque paquet comportant un ou plusieurs agrégats de données, chaque agrégat contenant un champ d'identifiant, un champ de taille et un champ de données utiles, et chaque agrégat étant adapté pour inclure un ou plusieurs autres agrégats de données, le ou les autres agrégats de données formant alors le champ de données utiles dudit 5 agrégat. Avec le procédé d'émission selon l'invention, la structuration des messages émis en agrégats de données, chaque agrégat contenant un champ d'identifiant, un champ de taille et un champ de données utiles, et chaque agrégat étant adapté pour inclure un ou plusieurs autres agrégats de données, le ou les autres agrégats de données formant alors 10 le champ de données utiles dudit agrégat, permet une évolutivité de la transmission des données. Le procédé d'émission selon l'invention permet également de limiter la bande passante utilisée en émettant les seuls agrégats nécessaires. Chaque agrégat de données correspond à une information fonctionnelle, et la structuration de l'information est déterminée par le dispositif émetteur. 15 Suivant d'autres aspects avantageux de l'invention, le procédé d'émission comprend une ou plusieurs des caractéristiques suivantes, prises isolément ou suivant toutes les combinaisons techniquement possibles : - à chaque agrégat est associé un unique domaine fonctionnel avionique, chaque domaine fonctionnel avionique correspondant de préférence à un chapitre 20 ATA ou à un sous-chapitre ATA ; - lorsque le domaine fonctionnel avionique est identique pour l'ensemble d'agrégat(s) compris dans le message, l'en-tête de message comporte un champ de domaine fonctionnel contenant un identifiant du domaine fonctionnel avionique ; - lorsque le domaine fonctionnel avionique n'est pas identique pour l'ensemble 25 d'agrégat(s) compris dans le message, le champ d'identifiant de chaque agrégat contient un identifiant du domaine fonctionnel avionique associé audit agrégat ; - chaque agrégat est identifié de manière unique pour l'ensemble des dispositifs électroniques reliés au réseau avionique, le champ d'identifiant de chaque agrégat présentant de préférence une structure 30 identique d'un agrégat à l'autre ; - l'en-tête de message comporte un champ d'identification de l'émetteur contenant un identifiant du dispositif émetteur qui est unique pour l'ensemble des dispositifs électroniques reliés au réseau avionique ; - l'en-tête de message comporte un champ d'identification du récepteur (56) 35 contenant un identifiant du dispositif récepteur qui est unique pour l'ensemble des dispositifs électroniques reliés au réseau avionique ; et 4 - chaque paquet comprend un en-tête de paquet et un corps de paquet, chaque corps de paquet comportant alors le ou les agrégats de données, chaque paquet présentant un type choisi parmi le groupe consistant en : paquet de requête, paquet de réponse et paquet de publication. 5 L'invention a également pour objet un programme d'ordinateur comportant des instructions logicielles qui, lorsqu'elles sont exécutées par un ordinateur, mettent en oeuvre un procédé d'émission tel que défini ci-dessus. L'invention a également pour objet un dispositif électronique émetteur configuré pour émettre un message de données à destination d'au moins un dispositif électronique 10 récepteur, le dispositif émetteur et le ou les dispositifs récepteurs étant aptes à être reliés via un réseau avionique embarqué à bord d'un aéronef, au moins un dispositif parmi le dispositif émetteur et le dispositif récepteur étant un dispositif avionique destiné à être embarqué à bord de l'aéronef, le dispositif électronique émetteur comprenant : - un module de génération configuré pour générer un message de données, le 15 message comprenant un en-tête de message et un ou plusieurs paquets de données, et - un module d'émission configuré pour émettre le message généré à destination du ou des dispositifs récepteurs, chaque paquet comportant un ou plusieurs agrégats de données, chaque agrégat contenant un champ d'identifiant, un champ de taille et un champ de données utiles, et 20 chaque agrégat étant adapté pour inclure un ou plusieurs autres agrégats de données, le ou les autres agrégats de données formant alors le champ de données utiles dudit agrégat. Ces caractéristiques et avantages de l'invention apparaîtront plus clairement à la 25 lecture de la description qui va suivre, donnée uniquement à titre d'exemple non limitatif, et faite en référence aux dessins annexés, sur lesquels : - la figure 1 est une représentation schématique d'un système de communication comprenant au moins deux équipements électroniques reliés entre eux par un réseau avionique de communication, au moins l'un des équipements électroniques comportant un 30 dispositif électronique émetteur selon l'invention ; - la figure 2 est un organigramme d'une transmission de données au sein du système de communication de la figure 1, avec la mise en oeuvre d'un procédé d'émission d'un message de données selon l'invention, puis d'un procédé de réception du message émis ; et 35 - la figure 3 est une vue schématique représentant la structure d'un message de de données émis par le dispositif électronique émetteur selon l'invention. 5 Sur la figure 1, un système de communication 10 comporte au moins deux équipements électroniques 12 reliés entre eux par un réseau avionique de communication 14, tel qu'un réseau de communication Ethernet. Au moins l'un des équipements 5 électroniques 12 et le réseau avionique de communication 14 sont embarqués à bord d'un aéronef 16. L'aéronef 16 est de préférence un avion. En variante, l'aéronef 16 est un hélicoptère, ou encore un drone piloté à distance par un pilote. Le système de communication 10 comporte plusieurs équipements électroniques 12, tels que des équipements avioniques comme dans l'exemple de la figure 1 où le 10 système de communication 10 est embarqué à bord de l'aéronef 16. Le système de communication 10 comprend un dispositif électronique émetteur 18 et au moins un dispositif électronique récepteur 20 reliés entre eux par le réseau avionique de communication 14. Au moins un dispositif parmi le dispositif émetteur 18 et le ou les dispositifs récepteurs 20 est un dispositif avionique embarqué à bord de l'aéronef 15 16. En variante, non représentée, au moins un dispositif parmi le dispositif émetteur 18 et le ou les dispositifs récepteurs 20 est un dispositif électronique externe à un domaine de communication sécurisé au sein de l'aéronef 16, ce dispositif étant par exemple un dispositif externe à l'aéronef 16, tel qu'un dispositif électronique installé au 20 sol. Ce dispositif électronique externe est alors relié à chaque autre dispositif du système de communication 10 via une passerelle de communication, non représentée, embarquée à bord de l'aéronef 16 et connectée au réseau avionique de communication 14. Le domaine externe à ce domaine de communication sécurisé est également appelé monde ouvert. Le dispositif électronique externe appartient alors au monde ouvert, et la 25 passerelle de communication qui est une passerelle sécurisée, en incluant notamment un pare-feu informatique (de l'anglais firewall), assure l'interface entre le domaine sécurisé et le monde ouvert. Dans l'exemple de la figure 1, chaque équipement électronique 12 est de préférence configuré, d'une part, pour émettre des données à destination d'autre(s) 30 équipement(s) électronique(s) 12, et d'autre part, pour recevoir des données de la part d'autre(s) équipement(s) électronique(s) 12. Chaque équipement électronique 12 comprend alors de préférence le dispositif émetteur 18 et le dispositif récepteur 20. L'homme du métier comprendra bien entendu qu'un équipement électronique 12 qui ne serait destiné qu'à émettre des données et pas à en recevoir, comportera alors le 35 dispositif émetteur 18, mais pas le dispositif récepteur. Inversement, un équipement électronique 12 qui ne serait destiné qu'à recevoir des données de la part d'autre(s) 6 équipement(s) électronique(s) 12 comportera alors le dispositif récepteur 20, mais pas le dispositif émetteur. Dans l'exemple de la figure 1, chaque équipement électronique 12 comprend une unité de traitement d'informations 22 formée par exemple d'une mémoire 24 associée à 5 un processeur 26. Dans l'exemple de la figure 1, un seul équipement électronique 12 est représenté en détail avec les différents dispositifs et modules qu'il contient, par souci de simplification du dessin. Le réseau avionique de communication 14 comprend au moins un commutateur 10 réseau 28 et au moins une liaison bidirectionnelle 30, chaque commutateur réseau 28 étant connecté à un ou plusieurs équipements électroniques 12 via des liaisons bidirectionnelles 30 respectives. Le réseau de communication avionique 14 comprend de préférence plusieurs commutateurs réseau 28, comme dans l'exemple de la figure 1 où le réseau avionique de communication 14 comprend deux commutateurs réseau 28 reliés 15 entre eux par une liaison bidirectionnelle 30. L'homme du métier comprendra que, lorsque le réseau avionique de communication 14 est un réseau de communication Ethernet, chaque commutateur réseau 28 est un commutateur réseau Ethernet, et chaque liaison bidirectionnelle 30 est une liaison bidirectionnelle Ethernet. 20 En complément facultatif, le réseau avionique de communication 14 est un réseau de communication redondant et comporte au moins deux réseaux élémentaires indépendants, redondants l'un de l'autre. Dans ce cas, deux équipements électroniques 12, un équipement source et un équipement destinataire, communiquent par l'intermédiaire d'au moins deux réseaux élémentaires indépendants. De façon connue, la 25 redondance est réalisée trame par trame sur chacun desdits réseaux. Chaque dispositif électronique émetteur 18 est configuré pour émettre, à destination du ou des dispositifs électroniques récepteurs 20, au moins un message 35 de données. Chaque dispositif émetteur 18 comprend un module de génération 40 configuré 30 pour générer un message de données 35 respectif, le message 35 comprenant un en-tête de message 42 et un ou plusieurs paquets 44 de données. Chaque dispositif émetteur 18 comprend un module d'émission 46 configuré pour émettre le message généré 35 à destination du ou des dispositifs récepteurs 20. Chaque dispositif électronique récepteur 20 est configuré pour recevoir des 35 données, en particulier des messages de données 35, via le réseau de communication 14. Chaque dispositif récepteur 20 comprend un module de réception 50 configuré pour 7 recevoir via le réseau de communication 14 au moins un message de données 35 et un module de traitement 52 configuré pour traiter chaque message reçu 35. Dans l'exemple de la figure 1, le module de génération 40, le module d'émission 46, le module de réception 50 et le module de traitement 52 sont réalisés chacun sous 5 forme d'un logiciel exécutable par le processeur 26. La mémoire 24 est alors apte à stocker un logiciel de génération configuré pour générer un message de données 35 respectif, un logiciel d'émission configuré pour émettre le message généré 35 à destination du ou des dispositifs récepteurs 20. La mémoire 24 est également apte à stocker un logiciel de réception configuré pour recevoir via le réseau de communication 10 14 au moins un message de données 35 et un logiciel de traitement configuré pour traiter chaque message reçu 35. Le processeur 26 de l'unité de traitement d'informations 22 est alors apte à exécuter le logiciel de génération et le logiciel d'émission dans le cas du dispositif émetteur 18, ou bien à exécuter le logiciel de réception et le logiciel de traitement dans le cas du dispositif récepteur 20. 15 En variante non représentée, le module de génération 40, le module d'émission 46, le module de réception 50 et le module de traitement 52 sont réalisés chacun sous forme d'un composant logique programmable, tel qu'un FPGA (de l'anglais Field Programmable Gate Array), ou encore sous forme d'un circuit intégré dédié, tel qu'un ASIC (de l'anglais Application Specific lntegrated Circuit). 20 Un message de données 35, ou encore une trame de données, est défini comme un ensemble de données envoyé en une seule fois sur le réseau de communication 14, depuis un dispositif émetteur 18 vers un ou plusieurs dispositifs récepteurs 20. Chaque message 35 comprend un en-tête de message 42 respectif, également noté BH (de l'anglais Batch Header), et un ou plusieurs paquets 44 de données, chaque 25 paquet 44 étant également noté PA (du français PAquet ou de l'anglais PAcket), comme représenté sur la figure 3. Sur la figure 3, à chaque paquet 44 est associé un indice i, de valeur comprise entre 1 et N, où N est un nombre entier supérieur ou égal à 1 représentant le nombre de paquets 44 formant le message 35. L'ensemble de N paquet(s) 44, également appelé lot de paquet(s) 44, forme le corps du message 35 et est 30 noté BB (de l'anglais Batch Body). L'en-tête de message 42 comporte un champ de taille de l'en-tête, noté BH_S (de l'anglais Batch Header Size), contenant la taille de l'en-tête de message 42, exprimée par exemple en bits ou en octets. Ce champ de taille BH_S permet de gérer une évolutivité et une variabilité du contenu de l'en-tête 42. 35 L'en-tête de message 42 comporte un champ de taille du corps, noté BB_S (de l'anglais Batch Body Size), contenant la taille du corps de message BB, exprimée par 8 exemple en octets. Chaque corps de message BB est de préférence constitué de l'ensemble de N paquet(s) 44. L'en-tête de message 42 inclut aussi un champ d'identification du message, noté B ID (de l'anglais Batch IDentifier), contenant un identifiant du message 35. Cet 5 identifiant est par exemple implémenté sous forme d'un compteur entier sur un nombre prédéfini de bits, le compteur étant incrémenté d'une unité à chaque émission. Le nombre de bits est par exemple égal à 32, ce qui permet alors d'avoir un identifiant unique pour l'ensemble des messages 35 émis sur le réseau avionique 14 de communication au cours d'une période de fonctionnement de plusieurs heures. Ainsi, même si l'identifiant du 10 message 35 n'est pas unique dans l'absolu, il est unique au cours d'une période temporelle suffisamment longue par rapport aux cas de fonctionnement du système de communication 10. L'en-tête de message 42 inclut aussi un champ de nombre de paquets, noté PA Nb (du français PAquet Nombre ou de l'anglais PAcket Number), contenant la valeur 15 du nombre N paquet(s) 44 formant le corps du message 35. En complément facultatif, l'en-tête de message 42 comporte un champ d'identification de l'émetteur 54, également noté Em_ID (du français Emetteur IDentifiant ou de l'anglais Emitter IDentifier), contenant un identifiant du dispositif émetteur 18 qui est unique pour l'ensemble des dispositifs électroniques reliés au réseau avionique 14 de 20 communication. En complément facultatif, l'en-tête de message 42 comporte un champ d'identification du récepteur 56, également noté Rec_ID (du français Récepteur IDentifiant ou de l'anglais Receiver IDentifier), contenant un identifiant du dispositif récepteur 20 qui est unique pour l'ensemble des dispositifs électroniques reliés au réseau avionique 14 de 25 communication. L'homme du métier comprendra que, dans le cas d'une émission de message en mode multi-diffusé (de l'anglais multicast), le champ d'identification du récepteur 56 est rempli par une valeur prédéfinie, par exemple égale à 0 avec tous les bits de ce champ à 0. Selon ce complément facultatif, l'ajout du champ d'identification de l'émetteur 54 et 30 du champ d'identification du récepteur 56 dans l'en-tête de message 42 permet d'échanger cette information entre le dispositif émetteur 18 et le dispositif récepteur 20, c'est-à-dire entre le serveur et le client, quelles que soient la position de ceux-ci par rapport au réseau avionique 14 de communication, ainsi que les caractéristiques du réseau avionique 14 choisi. 35 Chaque paquet 44 comporte un ou plusieurs agrégats de données 60, chaque agrégat 60 étant également noté DC (de l'anglais Data Cluster), comme représenté sur la 9 figure 3. Sur la figure 3, à chaque agrégat 60 est associé un indice j, de valeur comprise entre 0 et P, où P est un nombre entier supérieur ou égal à 0 représentant le nombre d'agrégat(s) 60 inclus dans le paquet 44. Chaque agrégat 60 contient un champ d'identifiant 62, également noté DC_ID (de l'anglais Data Cluster IDentifier), un champ de 5 taille 64, également noté DC_B_S (de l'anglais Data Cluster Body Size), et un champ de données utiles 66, également noté DC_V (de l'anglais Data Cluster Value) et contenant les données utiles de l'agrégat 60 correspondant. Dans l'exemple de la figure 3, chaque paquet 44 comprend un en-tête de paquet 70, également noté PA_H (de l'anglais PAcket Header), et un corps de paquet 72, 10 également noté PA_B (de l'anglais PAcket Body), chaque corps de paquet 72 comportant alors le ou les agrégats de données 60. Chaque corps de paquet 72 comporte en outre un en-tête fonctionnel 74, également noté HF (de l'anglais Header Functional). Chaque corps de paquet 72 est de préférence constitué de l'en-tête fonctionnel 74 et de l'ensemble de P agrégat(s) 60. L'homme du métier comprendra que, lorsque l'indice j précité est égal à 0, 15 le corps de paquet 72 comprend seulement l'en-tête fonctionnel 74, et ne comporte pas d'agrégat. Chaque agrégat 60 est adapté pour inclure un ou plusieurs autres agrégats de données 60, le ou les autres agrégats de données 60 formant alors le champ de données utiles 66 dudit agrégat 60. Autrement dit, un agrégat 60, dit parent, est adapté pour inclure 20 un ou plusieurs autres agrégats de données 60, dits fils, le ou les agrégats fils formant alors le champ de données utiles 66 de l'agrégat parent. A chaque agrégat 60 est associé un unique domaine fonctionnel avionique. Chaque domaine fonctionnel avionique correspond de préférence à un chapitre ATA ou à un sous-chapitre ATA. Les chapitres ou sous-chapitres ATA concernés sont, par exemple, 25 le chapitre ATA 22 relatif au pilote automatique, le chapitre ATA 22-70 relatif au système de gestion du vol, le chapitre ATA 31 relatif au système d'indication / d'enregistrement, le chapitre ATA 31-53 relatif au système d'alarme le chapitre ATA 23 relatif aux communications, le chapitre ATA 27 relatif aux commandes de vol, le chapitre ATA 28 relatif au système de fuel, le chapitre ATA 34 relatif à la navigation. 30 Lorsque le domaine fonctionnel avionique est identique pour l'ensemble de P agrégat(s) 60 compris dans le message 35, l'en-tête de message 42 comporte de préférence en outre un champ de domaine fonctionnel, non représenté, contenant un identifiant dudit domaine fonctionnel avionique. Lorsque le domaine fonctionnel avionique n'est pas identique pour l'ensemble de 35 P agrégat(s) 60 compris dans le message 35, le champ d'identifiant 62 de chaque agrégat contient un champ de domaine fonctionnel, noté Sys_Dom (de l'anglais System Domain) 10 et visible sur la figure 3, le champ de domaine fonctionnel Sys_Dom comportant un identifiant du domaine fonctionnel avionique associé audit agrégat 60. Chaque agrégat 60 est identifié de manière unique pour l'ensemble des dispositifs électroniques 18, 20 reliés au réseau avionique de communication 14. Cette unicité de 5 l'identification de l'agrégat 60 permet notamment de garantir, au dispositif récepteur 20, l'interprétation du contenu de l'agrégat 60. Le champ d'identifiant 62 de chaque agrégat présente de préférence une structure identique d'un agrégat 60 à l'autre. Le champ d'identifiant 62 est par exemple codé sur une taille fixe, telle qu'un mot de 4 octets. En variante, le champ d'identifiant 62 est codé 10 avec une taille auto-adaptative en utilisant un ou plusieurs bits de poids fort pour indiquer sa propre taille. Par exemple, si le premier bit de poids fort est 0, alors le codage est sur 4 octets ; si le premier bit de poids fort est 1 et le deuxième bit de poids fort est 0, alors le codage est sur 8 octets ; etc. La taille du champ d'identifiant 62 est connue du dispositif récepteur 20, ce qui permet au dispositif récepteur 20 de lire ce champ d'identifiant 62, 15 même si sa valeur est inconnue. Le champ d'identifiant 62 comporte par exemple un champ GP (de l'anglais Growth Potentiel) avec un bit de poids fort pour tenir compte d'une croissance potentielle de la taille de l'identifiant de l'agrégat 60. Le champ d'identifiant 62 comporte ensuite le champ de domaine fonctionnel Sys_Dom contenant un code permettant d'identifier le 20 domaine fonctionnel au niveau de l'aéronef 16. Cette identification du domaine fonctionnel est typiquement exprimée en termes de chapitres ou sous-chapitres ATA, en utilisant par exemple les 7 bits suivants du premier octet du champ GP. Le champ d'identifiant 62 comporte un champ Std_Dom (de l'anglais Standard Domain) contenant un code permettant de distinguer un identifiant d'agrégat faisant partie 25 du domaine public, c'est-à-dire partagé par tous les industriels, d'un identifiant d'agrégat faisant partie du domaine privé, c'est-à-dire spécifique à un industriel ou à un aéronef 16. La taille et les valeurs de ce code sont spécifiques au domaine fonctionnel concerné. En complément, le champ d'identifiant 62 comporte un champ DS_ID (de l'anglais Data Set 1Dentifier) avec un identifiant des données contenues dans l'agrégat 60 30 correspondant. Le champ de taille 64, également noté DC_B_S, est typiquement sous forme d'octets. Le champ de taille 64 est par exemple codé sur une taille fixe, telle qu'un mot de 4 octets. En variante, le champ de taille 64 est codé avec une taille auto-adaptative en utilisant un ou plusieurs bits de poids fort pour indiquer sa propre taille. A titre d'exemple, 35 si le premier bit de poids fort est 0, alors le codage de la taille est sur un octet et les 7 autres bits permettent de coder une taille de 0 à 127. Si le premier bit de poids fort est 1 11 et le deuxième bit de poids fort est 0, alors le codage est sur deux octets, et les 14 autres bits permettent de coder une taille de 0 à 16 383. Si les deux premiers bits de poids fort sont 1 et le troisième bit de poids fort est 0, alors le codage est sur trois octets, et les 21 autres bits permettent de coder une taille de 0 à 2 097 151 ; et ainsi de suite de façon 5 récurrente jusqu'au nombre d'octets nécessaires. L'homme du métier observera que, lorsque la plupart des agrégats 60 présente une taille inférieure à 127 octets, ceci afin de limiter l'occupation du réseau avionique 14, il est préférable d'utiliser le codage avec une taille auto-adaptative pour coder le champ de taille 64. 10 Le champ de taille 64 permet alors au dispositif récepteur 20 d'ignorer un agrégat 60 inconnu ou inutile, et de poursuivre son traitement du message 35 en sautant à l'agrégat 60 suivant, sans rupture de compatibilité entre le dispositif émetteur 18 et le dispositif récepteur 20. Le champ de taille 64 permet également de faire évoluer la définition de l'agrégat 15 60 au niveau du dispositif émetteur 18 en ajoutant des paramètres en fin d'agrégat, tout en permettant à un dispositif récepteur 20 n'ayant pas connaissance de ces nouveaux paramètres de les ignorer et de poursuivre son traitement du message 35 en sautant à l'agrégat 60 suivant, ceci donc sans rupture de compatibilité entre le dispositif émetteur 18 et le dispositif récepteur 20. 20 Le champ de taille 64 permet encore de faire évoluer la définition de l'agrégat 60 au niveau du dispositif récepteur 20 en anticipant l'ajout de paramètres en fin d'agrégat, tout en permettant à un dispositif émetteur 18 n'ayant pas connaissance de ces nouveaux paramètres d'émettre la version précédente de l'agrégat 60. Dans ce cas, le dispositif récepteur 20 ne traitera que les paramètres présents et appliquera une sanction aux 25 paramètres absents, sans rupture de compatibilité entre le dispositif émetteur 18 et le dispositif récepteur 20. La sanction est par exemple choisie au cas par cas, telle qu'une invalidation desdits paramètres, ou bien l'application d'une valeur par défaut, ou encore l'invalidation complète de l'agrégat 60 concerné. L'en-tête de paquet 70 comporte un champ de type, noté PA_Typ (du français 30 PAquet Type ou de l'anglais PAcket Type), chaque paquet 44 présentant de préférence un type choisi parmi le groupe consistant en : paquet de requête, paquet de réponse et paquet de publication. L'en-tête de paquet 70 comporte un champ de taille de l'en-tête, noté PA_H_S (de l'anglais PAcket Header Size), contenant la taille de l'en-tête de paquet 70, exprimée par 35 exemple en bits ou en octets. Ce champ de taille PA_H_S permet de gérer une évolutivité et une variabilité du contenu de l'en-tête 70. 12 L'en-tête de paquet 70 comporte un champ de taille du corps, noté PA_B_S (de l'anglais PAcket Body Size), contenant la taille du corps de paquet 72, également noté PA B, cette taille étant exprimée par exemple en octets. L'en-tête de paquet 70 inclut aussi un champ d'identification du paquet, noté 5 PA_ID (de l'anglais PAcket IDentifier), contenant un identifiant du paquet 44 qui est unique pour le message 42 correspondant. Le couple formé du champ d'identification du message B_ID et du champ d'identification du paquet PA_ID permet alors d'identifier de manière unique le paquet 44 parmi l'ensemble des paquets 44 émis sur le réseau avionique 14 de communication au 10 cours d'une période temporelle qui est suffisamment longue par rapport au fonctionnement du système de communication 10. En effet, de par le champ d'identification du message B_ID et le champ d'identification du paquet PA_ID, même si l'identification n'est pas unique dans l'absolu, elle l'est au cours d'une période temporelle bien plus longue qu'une durée maximale possible entre l'émission d'une requête et la 15 réception de la ou les réponses associées, l'identification étant unique typiquement au cours d'une période temporelle de plusieurs minutes. En complément facultatif, l'en-tête de paquet 70 inclut un champ de complément, noté PA_H_Compl (de l'anglais PAcket Header Complement), comportant certains champs additionnels, dont la nature varie selon le type de paquet. Pour les paquets 44 de 20 type publication, le champ additionnel est par exemple un champ de version permettant d'indiquer une condition minimale de mise à disposition de données requises. Pour les paquets 44 de type requête, le champ additionnel est par exemple un identifiant de session. Pour les paquets 44 de type réponse, les champs additionnels sont par exemple un champ d'identification de la requête permettant de faire la corrélation avec la requête 25 et le champ de version. L'en-tête fonctionnel 74 définit une grammaire de communication entre le dispositif émetteur 18 et le dispositif récepteur 20. L'en-tête fonctionnel 74, également noté HF, comporte un champ d'identification de type d'action 76, également noté Action_ID (du français Action IDentifiant ou de l'anglais Action IDentifier), contenant un identifiant d'un 30 type d'action demandée par le dispositif émetteur 18 ou par le dispositif récepteur 20. Le type d'action est par exemple une requête de consultation, une requête de modification, une requête de calcul, une requête de création, une requête d'activation, ou encore une publication. L'homme du métier comprendra alors que, lorsque le type d'action est une requête, celle-ci correspond par exemple à une commande avionique, cette requête étant 35 alors contenue dans un message émis à destination du dispositif qui, parmi le dispositif émetteur 18 et le dispositif récepteur 20, est un dispositif avionique, afin que ce dernier 13 effectue la commande avionique associée à la requête. Lorsque le message généré est émis à destination d'un dispositif qui, parmi le dispositif émetteur 18 et le dispositif récepteur 20, n'est pas un dispositif avionique, l'action associée, contenue dans le champ d'identification de type d'action Action_ID, est typiquement une publication (de l'anglais 5 publish). L'en-tête fonctionnel 74 comporte en outre un champ d'élément 78, également noté Element, contenant l'élément sur lequel porte l'action demandée par le dispositif émetteur 18 ou par le dispositif récepteur 20. Le champ d'élément 78 présente une structure identique à celle de l'agrégat 60, 10 décrite précédemment, et contient alors un champ d'identifiant 80, également noté Element_ID (de l'anglais Element IDentifier), un champ de taille 82, également noté Element_B_S (de l'anglais Element Body Size), et un champ de données utiles 84, également noté Element_V (de l'anglais Element Value) et contenant les données utiles de l'élément. 15 La structure et le codage du champ d'identifiant 80, noté Element_ID, sont alors identiques à ceux décrits précédemment pour le champ d'identifiant 62, noté DC_ID. De manière analogue, la structure et le codage du champ de taille 82, noté Element_B_S, sont alors identiques à ceux décrits précédemment pour le champ de taille 64, noté DC B S. 20 Le fonctionnement du système de communication 10 selon l'invention va désormais être expliqué à l'aide de la figure 2 représentant un organigramme d'un procédé de transmission de données au sein du système de communication 10 depuis un dispositif émetteur 18 à destination de dispositif(s) récepteur 20 via le réseau avionique de communication 14. 25 Lors d'une étape initiale 100, le dispositif émetteur 18 génère, via son module de génération 40, un ou plusieurs messages de données 35, chaque message 35 comprenant un en-tête de message 42 et un ou plusieurs paquets de données 44. Selon l'invention, chaque paquet 44 comporte un ou plusieurs agrégats de données 60, chaque agrégat parent 60 étant adapté pour inclure un ou plusieurs autres 30 agrégats fils 60, le ou les autres agrégats fils 60 formant alors le champ de données utiles 66 de l'agrégat parent 60. Le dispositif émetteur 18 émet ensuite, lors de l'étape suivante 110 et via son module d'émission 46, le ou les messages de données 35 générés sur le réseau avionique de communication 14 à destination du ou des dispositifs récepteurs 20. 14 Lors de l'étape 120, chaque dispositif récepteur 20 destinataire reçoit, via le réseau avionique de communication 14 et son module de réception 50, le ou les messages de données 35 émis à son attention. Chaque dispositif récepteur 20 ayant reçu au moins un message 35 traite alors, 5 lors de l'étape suivante 130 et via son module de traitement 52, le ou les messages reçus 35, ceci en ayant connaissance de la structuration de chaque message 35, telle que décrite dans l'exemple de la figure 3, et notamment de la possibilité pour un agrégat parent 60 d'inclure un ou plusieurs autres agrégats fils 60. En complément, pour la transmission de données entre le dispositif émetteur 18 et 10 le ou les dispositifs récepteurs 20, différents motifs de transmission sont envisagés. Un motif de publication en mode multi-diffusé est prévu pour une émission de données génériques, d'un dispositif émetteur 18 vers tous les dispositifs récepteurs 20 reliés au réseau avionique de communication 14. Cette émission en mode multi-diffusé est effectuée sur événement, de manière périodique, ou encore sur requête. Par exemple, 15 dans le cas d'une interface entre un système de gestion du vol et une visualisation, l'émission en mode multi-diffusé doit être déclenchée sur un événement du dispositif émetteur 18 pour maintenir un affichage à jour, et est optionnellement complétée par une émission périodique pour surveiller une éventuelle perte de transmission. Un motif uni-diffusé (de l'anglais unicast) est prévu pour une notification d'un 20 dispositif émetteur 18 vers un dispositif récepteur 20, ce motif étant également appelé motif de notification. Ceci permet à un dispositif émetteur 18 d'envoyer des informations de manière unitaire, c'est-à-dire non récurrente, vers un dispositif récepteur 20 particulier. Le motif de notification permet de limiter l'utilisation du réseau avionique de communication 14 au strict nécessaire. 25 Un motif uni-diffusé est prévu pour une requête d'un dispositif récepteur 20 vers un dispositif émetteur 18, ce motif étant également appelé motif de requête. Dans ce cas, la requête sera suivie d'un acquittement du dispositif émetteur 18 pour informer le dispositif récepteur 20 de la prise en compte de sa requête. Un motif uni-diffusé bidirectionnel d'abonnement/réponse est une combinaison 30 d'un motif de requête, à savoir une requête d'abonnement, suivi de son acquittement qui va déclencher automatiquement, chez le dispositif émetteur 18, un motif de notification des agrégats 60 auxquels le dispositif récepteur 20 s'est abonné. L'émission de l'abonnement est effectuée sur événement, de manière périodique ou encore sur requête. Par exemple, dans le cas d'une interface entre un système de gestion du vol et une 35 visualisation, l'émission de l'abonnement est effectuée sur un événement du dispositif émetteur 18, suite à la réception de la requête d'abonnement puis sur changement d'un 15 contexte du dispositif émetteur 18, ceci pour maintenir une bonne réactivité. Dans cet exemple, l'émission de l'abonnement est optionnellement complétée par une émission périodique pour surveiller une éventuelle perte de transmission. Ainsi, le dispositif émetteur 18 selon l'invention permet de générer un message de 5 données 35 avec un agrégat 60 offrant une structure hiérarchisée, au sens où un agrégat parent 60 est adapté pour inclure un ou plusieurs autres agrégats fils 60, le ou les autres agrégats fils 60 formant alors le champ de données utiles 66 de l'agrégat parent 60. Les agrégats 60 ne sont alors pas uniquement des regroupements de paramètres, mais sont également adaptés pour regrouper d'autres agrégats 60. A titre d'exemple, dans le cas 10 d'un système de gestion du vol, les contraintes associées à un leg seront regroupées au sein d'un agrégat 60 associé à un point du plan de vol qui sera lui-même l'un des agrégats 60 associés à une portion du plan de vol, qui sera lui-même l'un des agrégats 60 associés au plan de vol complet. Cette structuration hiérarchisée permet alors d'offrir une évolutivité et une 15 flexibilité, sans générer d'incompatibilité avec le dispositif récepteur 20. Par exemple, le dispositif émetteur 18 peut introduire dans ses messages émis 35 une structure hiérarchisée nécessaire à destination d'un de ses dispositifs récepteurs 20, pendant que d'autres dispositifs récepteurs 20 ne connaissant pas cette structure pourront la sauter d'un bloc, lors du traitement du message reçu. 20 En outre, dans le cas d'une transmission au sein d'un aéronef 16 donné, il est facile d'adapter par configuration les émissions au juste besoin en ne mettant dans des structures de messages 35 prédéfinies que les agrégats 60 nécessaires. A titre d'exemple, si un système de gestion du vol embarque une capacité de recherche et sauvetage (de l'anglais Search and Rescue), mais que celle-ci n'est pas utilisée sur un 25 aéronef 16 donné, il est, avec la structuration du message 35 selon l'invention, beaucoup plus facile de ne pas émettre les données relatives à cette capacité, incluant tous ses fils, et de réduire ainsi l'occupation du réseau avionique de communication 14. En outre, pour assurer une meilleure cohérence fonctionnelle entre agrégats 60, à un agrégat 60 est associé un indicateur de référence qui se trouve déjà dans d'autres 30 agrégats 60. Par exemple, dans le cas d'un système de gestion du vol, un identifiant de point du plan de vol est inclus dans plusieurs agrégats 60 distincts. De plus, la structuration du message 35 selon l'invention, comme représentée sur la figure 3, permet d'offrir une interface de communication efficace entre le dispositif émetteur 18 et le dispositif récepteur 20. Elle permet en particulier, de par la structure 35 d'agrégat 60 et via le module de génération 40, d'effectuer un regroupement de données fonctionnelles en agrégats 60 selon plusieurs critères. 16 Un premier critère est, par exemple, une cohérence fonctionnelle de l'agrégat 60. Selon ce premier critère, les données d'un même agrégat 60 concernent alors une même fonction ou sous-fonction du dispositif émetteur 18, et leurs valeurs correspondent au même contexte du dispositif émetteur 18. Par exemple, pour un système de gestion du 5 vol, des données relatives à la procédure de départ d'un plan de vol seront regroupées ainsi que celle relatives à la procédure d'arrivée. Un deuxième critère est, par exemple, une isolation de l'évolutivité dans les agrégats 60. Les paramètres d'un même genre, sujets à évolution, sont regroupés afin de permettre un incrément cohérent. Par exemple, pour un système de gestion du vol, des 10 données de prédiction seront regroupées pour permettre des évolutions futures, sans se retrouver avec un patchwork de paramètres. De même, une structure de taille variable sera isolée afin de permettre son évolution, sans impacter le traitement des autres paramètres. Un troisième critère est, par exemple, une isolation de données optionnelles au 15 sein d'un agrégat 60 donné, afin de pouvoir gérer efficacement leur présence ou leur absence. Par exemple, pour un système de gestion du vol, les contraintes d'altitude et/ou de vitesse susceptibles d'être associées à un point du plan de vol constitueront un agrégat 60 qui sera présent seulement si ce type de contrainte(s) est défini sur le point en question. 20 Un quatrième critère est, par exemple, une spécialisation des agrégats 60 selon les besoins. Par exemple, pour les affichages de premier niveau correspondant à un motif de publication en mode multi-diffusé, l'agrégat 60 contiendra seulement les paramètres principaux, ceci essentiellement afin de limiter la consommation des ressources du réseau avionique 14 de communication. En revanche, pour un affichage détaillé 25 correspondant à un motif d'abonnement, l'agrégat 60 du même élément fonctionnel inclura les paramètres détaillés, même s'ils ne sont pas tous requis par un dispositif récepteur 20 donné, ceci pour faciliter la polyvalence. En effet, le mécanisme d'abonnement permet à un dispositif récepteur 20 de choisir un ensemble particulier d'agrégats 60, la consommation des ressources du réseau avionique 14 de 30 communication étant alors moins importante. On conçoit ainsi que le procédé d'émission et le dispositif électronique émetteur 18 selon l'invention permettent de s'adapter plus facilement aux différents types de données à échanger à bord de l'aéronef REVENDICATIONS1. Procédé d'émission d'un message de données (35) à destination d'au moins un dispositif électronique récepteur (20), le procédé étant mis en oeuvre par un dispositif électronique émetteur (18), le dispositif émetteur (18) et le ou les dispositifs récepteurs (20) étant reliés via un réseau avionique (14) embarqué à bord d'un aéronef (16), au moins un dispositif parmi le dispositif émetteur (18) et le dispositif récepteur (20) étant un dispositif avionique embarqué à bord de l'aéronef (16), le procédé comprenant : - la génération (100) d'un message de données (35), le message (35) comprenant un en-tête de message (42) et un ou plusieurs paquets de données (44), et - l'émission (110) du message généré à destination du ou des dispositifs récepteurs (20), caractérisé en ce que chaque paquet (44) comporte un ou plusieurs agrégats de données (60), chaque agrégat (60) contenant un champ d'identifiant (62), un champ de taille (64) et un champ de données utiles (66), et chaque agrégat (60) est adapté pour inclure un ou plusieurs autres agrégats de données (60), le ou les autres agrégats de données (60) formant alors le champ de données utiles (66) dudit agrégat (60). 2. Procédé selon la revendication 1, dans lequel à chaque agrégat (60) est associé un unique domaine fonctionnel avionique, chaque domaine fonctionnel avionique correspondant de préférence à un chapitre ATA ou à un sous-chapitre ATA. 3. Procédé selon la revendication 2, dans lequel, lorsque le domaine fonctionnel avionique est identique pour l'ensemble d'agrégat(s) (60) compris dans le message (35), l'en-tête de message (42) comporte un champ de domaine fonctionnel contenant un identifiant du domaine fonctionnel avionique. 4. Procédé selon la revendication 2, dans lequel, lorsque le domaine fonctionnel avionique n'est pas identique pour l'ensemble d'agrégat(s) (60) compris dans le message (35), le champ d'identifiant (62) de chaque agrégat (60) contient un identifiant du domaine fonctionnel avionique associé audit agrégat (60). 18 5. Procédé selon l'une quelconque des revendications précédentes, dans lequel chaque agrégat (60) est identifié de manière unique pour l'ensemble des dispositifs électroniques (18, 20) reliés au réseau avionique (14), le champ d'identifiant (62) de chaque agrégat (60) présentant de préférence une 5 structure identique d'un agrégat (60) à l'autre. 6. Procédé selon l'une quelconque des revendications précédentes, dans lequel l'en-tête de message (42) comporte un champ d'identification de l'émetteur (54) contenant un identifiant du dispositif émetteur (18) qui est unique pour l'ensemble des dispositifs 10 électroniques (18, 20) reliés au réseau avionique (14). 7. Procédé selon l'une quelconque des revendications précédentes, dans lequel l'en-tête de message (42) comporte un champ d'identification du récepteur (56) contenant un identifiant du dispositif récepteur (20) qui est unique pour l'ensemble des dispositifs 15 électroniques (18, 20) reliés au réseau avionique (14). 8. Procédé selon l'une quelconque des revendications précédentes, dans lequel chaque paquet (44) comprend un en-tête de paquet (70) et un corps de paquet (72), chaque corps de paquet (72) comportant alors le ou les agrégats de données (60), 20 chaque paquet (44) présentant un type choisi parmi le groupe consistant en : paquet de requête, paquet de réponse et paquet de publication. 9. Programme d'ordinateur comportant des instructions logicielles qui, lorsqu'elles sont exécutées par un ordinateur, mettent en oeuvre un procédé selon l'une quelconque 25 des revendications précédentes. 10. Dispositif électronique émetteur (18) configuré pour émettre un message de données à destination d'au moins un dispositif électronique récepteur (20), le dispositif émetteur (18) et le ou les dispositifs récepteurs (20) étant aptes à être reliés via un réseau 30 avionique (14) embarqué à bord d'un aéronef (16), au moins un dispositif parmi le dispositif émetteur (18) et le dispositif récepteur (20) étant un dispositif avionique destiné à être embarqué à bord de l'aéronef (16), le dispositif électronique émetteur (18) comprenant : - un module de génération (40) configuré pour générer un message de données (35), le message (35) comprenant un en-tête de message (42) et un ou plusieurs paquets de données (44), et 19 - un module d'émission (46) configuré pour émettre le message généré (35) à destination du ou des dispositifs récepteurs (20), caractérisé en ce que chaque paquet (44) comporte un ou plusieurs agrégats de données (60), chaque agrégat (60) contenant un champ d'identifiant (62), un champ de 5 taille (64) et un champ de données utiles (66), et chaque agrégat (60) est adapté pour inclure un ou plusieurs autres agrégats de données (60), le ou les autres agrégats de données (60) formant alors le champ de données utiles (66) dudit agrégat (60).