Brevet FR3118844A1 — publié le 20220715

Système de transfert sécurisé de données numériques d’aéronef, système producteur de données, système consommateur de données, et procédé de transfert associé Ce système comporte un système producteur de données propre à engendrer, à chaque élaboration de données, une capsule de données (40), et un système consommateur de données. Le système consommateur est propre à récupérer chaque capsule (40) pour extraire un identifiant (42), un indicateur de rafraichissement (44), un paquet de données fonctionnelles (46), et un résultat de contrôle d’intégrité (48). Il est propre à contrôler l’intégrité des données de la capsule (40) en établissant un nouveau résultat de contrôle d’intégrité à partir de l’identifiant (42) de l’indicateur de rafraichissement (44) et du paquet de données fonctionnelles (46) récupéré dans la capsule (40) et en comparant le nouveau résultat de contrôle d’intégrité au résultat de contrôle d’intégrité (48) de la capsule (40). La capsule de données (40) est dans un état intègre lorsque le nouveau résultat de contrôle d’intégrité correspond au résultat de contrôle d’intégrité (48) récupéré dans la capsule (40). Figure pour l'abrégé : Figure 2 Système de transfert sécurisé de données numériques d’aéronef, système producteur de données, système consommateur de données, et procédé de transfert associé La présente invention concerne un système de transfert de données d’aéronef, comportant : - un système producteur de données, propre à élaborer, à des instants successifs, des données ; - au moins un système consommateur de données, propre à recevoir et à utiliser les données produites par le système producteur de données ; l’un au moins du système producteur de données et du ou de chaque système consommateur de données étant embarqué au sein d’un aéronef ; - un lien de transfert de données entre le système producteur de données et le ou chaque système consommateur de données. Le système de transfert de données est destiné à assurer un transfert sécurisé de données numériques au sein d’un aéronef, depuis l’aéronef vers au moins un système consommateur de données extérieur à l’aéronef (tel qu’au moins un autre aéronef, une station de contrôle au sol dans le cas d’un drone, etc.), ou/et depuis un système producteur de données extérieur à l’aéronef (par exemple un autre aéronef, un système de préparation de mission, un système de téléchargement de données, etc.) vers l’aéronef. Il est destiné à être utilisé notamment entre un système producteur de données et un ou plusieurs systèmes consommateurs de données situés à distance l’un de l’autre. Le système de transfert de données est aussi utilisable au sein d’un même système avion, notamment entre différents calculateurs d’un même système avion, entre un applicatif producteur d’un équipement tel un capteur et un ou plusieurs calculateurs, entre plusieurs couches applicatives d’un même calculateur, ou encore entre des cœurs différents d’un même processeur. Le système de transfert est destiné à être mis en œuvre indépendamment du nombre de liaisons numériques de transfert de données entre chaque système producteur de données et chaque système consommateur de données et indépendamment de la nature de celles-ci au niveau de l'architecture globale de transmission de données. Dans un aéronef, de nombreux systèmes avions sont propres à engendrer des données fonctionnelles. Ceci est le cas par exemple des systèmes de capteurs de mesure de paramètres, les paramètres étant internes ou externes à l’aéronef, ou des systèmes avioniques, en particulier de systèmes de pilotage, de commande ou de guidage de l’aéronef. Les données fonctionnelles sont par exemple des mesures de paramètres avion, des ordres de commande de systèmes avion, ou des données de suivi de systèmes avion. Les données fonctionnelles sont souvent utilisées par d’autres systèmes avion, ou par d’autres couches applicatives d’un même système avion. Elles sont donc transférées entre un système producteur de données et au moins un système consommateur de données qui peut être situé à distance, voire à l’extérieur de l’aéronef ou dans d’autres couches applicatives. Des protocoles de transfert de données numériques sont largement utilisés au sein des aéronefs. Certains protocoles de « bas niveau » transmettent les données numériques sous forme de mots de données dans chacun desquels sont codés des informations de gestion du protocole et des informations fonctionnelles. Ceci est le cas par exemple du protocole ARINC 429. Des protocoles plus évolués, tels que le protocole GAM-T-101 (Digibus), le protocole MIL-STD-1553B, ou le protocole Ethernet et ses dérivés dits déterministes (ARINC664 Part 7 ou SAE AS6802 ou TSN), mettent en œuvre des messages qui permettent l'émission atomique de plusieurs mots de données, certains contenant exclusivement des informations de gestion du protocole et les autres exclusivement des informations fonctionnelles. Dans tous les cas, il est essentiel dans le domaine aéronautique de s’assurer de l’intégrité des données transmises. Dans l’exemple du protocole ARINC 429, les données fonctionnelles sont transmises sous forme d’une suite de bits via des mots ARINC429, dont la taille est limitée à 32 bits. Chaque mot ARINC 429 comporte un identificateur de données (ID) appelé label, un identifiant de la source ayant émis la donnée (SDI), les données fonctionnelles (D), et un identifiant de validité des données émises par le système producteur (SSM). Le protocole ARINC 429 permet la transmission de données dites fonctionnelles sous la forme de motifs « label-data » et dans ce qui suit, comme communément employé, « label » pourra désigner le mot ARINC 429 complet. Pour vérifier l’intégrité des données fonctionnelles après leur transmission, chaque mot ARINC 429 comporte un outre un bit de vérification de parité (P), résultant de la somme en binaire des bits des données fonctionnelles. Le bit de parité est calculé lors du codage des données en mots ARINC 429 dans la couche de transmission de données Lors de la récupération des données contenues au sein d’un mot ARINC 429, le système consommateur est apte à recalculer la parité des données fonctionnelles qu’il reçoit et à vérifier qu’elle est identique à celle du bit de parité contenu dans le mot ARINC 429. Néanmoins, ce test d’intégrité est souvent un indicateur insuffisant pour constater une perte d’intégrité du paquet de données fonctionnelles au cours du transfert. Ainsi, si deux bits du paquet de données fonctionnelles sont erronés, la somme peut donner une parité correspondant à celle du bit de vérification, alors que le paquet de données fonctionnelles a été doublement corrompu. Un tel protocole peut donc être utilisé lorsque les données transmises sont d’importance moindre, ou ne sont pas critiques pour la sécurité et la conduite de l’aéronef. Si les données sont importantes ou critiques, il est nécessaire d’utiliser des systèmes producteurs redondants, qui élaborent en parallèle des données et de les transmettre en parallèle vers un ou plusieurs systèmes consommateurs. Le ou les systèmes consommateurs reçoivent les données des différents systèmes producteurs et appliquent des stratégies de sélection ou de vote, pour assurer que les données sont intègres. Une telle solution est sûre, mais augmente la masse, le coût et la complexité de l’aéronef. Un but de l’invention est de fournir un système de transfert de données d’aéronef entre un système producteur de données fonctionnelles et au moins un système consommateur de ces données, qui soit simple et facilement adaptable à un protocole de transfert de données existant, et qui soit suffisamment sûr dans le cas où l’erroné de ces données peut avoir des conséquences catastrophiques. À cet effet, l’invention a pour objet un système de transfert de données tel que défini plus haut, caractérisé en ce que le système producteur de données est propre à engendrer, à chaque élaboration de données, une capsule de données, chaque capsule de données comprenant un identifiant du producteur de données, un indicateur de rafraichissement mis à jour à chaque élaboration de données, éventuellement un paquet de données fonctionnelles, et un résultat de contrôle d’intégrité des données portant sur au moins l’identifiant, l’indicateur de rafraichissement et éventuellement le paquet de données fonctionnelles ; chaque capsule de données étant propre à être transférée au ou à chaque système consommateur de données via le lien de transfert ; le ou chaque système consommateur de données étant propre à récupérer chaque capsule de données pour extraire l’identifiant, l’indicateur de rafraichissement, éventuellement le paquet de données fonctionnelles, et le résultat de contrôle d’intégrité, et à contrôler l’intégrité des données de la capsule de données en établissant un nouveau résultat de contrôle d’intégrité à partir d’au moins l’identifiant, l’indicateur de rafraichissement et éventuellement le paquet de données fonctionnelles récupéré dans la capsule de données et en comparant le nouveau résultat de contrôle d’intégrité au résultat de contrôle d’intégrité récupéré dans la capsule de données, la capsule de données étant dans un état intègre lorsque le nouveau résultat de contrôle d’intégrité correspond au résultat de contrôle d’intégrité récupéré dans la capsule de données. Le système selon l’invention peut comprendre l’une ou plusieurs des caractéristiques suivantes, prise(s) isolément ou suivant toute combinaison techniquement possible : - chaque capsule de données comprend un paquet de données fonctionnelles, le résultat de contrôle d’intégrité des données de la capsule portant sur au moins l’identifiant, l’indicateur de rafraichissement et le paquet de données fonctionnelles, le ou chaque système consommateur de données étant propre à extraire le paquet de données fonctionnelles et à contrôler l’intégrité des données de la capsule de données en établissant un nouveau résultat de contrôle d’intégrité à partir d’au moins l’identifiant, l’indicateur de rafraichissement et le paquet de données fonctionnelles ; - le ou chaque système consommateur de données est propre à comparer l’identifiant reçu dans chaque capsule de données à un identifiant prédéfini sur la base d’une sémantique ou d’une table de correspondance pour en déduire au moins une caractéristique de contenu de la capsule de données ; - le système producteur de données émet des capsules de données de taille fixe, le ou chaque système consommateur de données étant propre à déterminer la taille de la capsule de données, la taille et/ou la position de l’identifiant, de l’indicateur de rafraichissement, éventuellement du paquet de données fonctionnelles ou/et du résultat de contrôle d’intégrité dans la capsule de données, à partir d’une sémantique ou d’une table de correspondance reliant l’identifiant prédéfini à la taille de la capsule de données, à la taille et/ou la position de l’identifiant, de l’indicateur de rafraichissement, éventuellement du paquet de données fonctionnelles ou/et du résultat de contrôle d’intégrité dans la capsule de données ; - le ou chaque système consommateur de données est propre, pour chaque capsule de données reçue, à déterminer un incrément de rafraichissement à partir de l’indicateur de rafraichissement de la capsule de données et à partir de l’indicateur de rafraichissement d’une capsule de données précédemment reçue, le ou chaque système consommateur de données étant propre à déterminer un état de rafraichissement de la capsule de données entre un état de rafraichissement attendu et un état de rafraichissement inadéquat en fonction de l’incrément de rafraichissement, et en fonction de la fréquence d’élaboration des capsules, de la fréquence de transfert des capsules, ou/et de la fréquence de réception des capsules ; - le ou chaque système consommateur de données est propre à vérifier, à partir de l’identifiant de capsule, que le système producteur de données ayant émis la capsule de données est un système producteur de données attendu pour émettre la capsule de données, le ou chaque système consommateur de données étant propre à passer la capsule de données dans un état valide permettant l’utilisation des données qu’elle contient lorsque la capsule de données provient du système producteur de données attendu, qu’elle est dans l’état intègre et qu’elle est dans l’état de rafraîchissement attendu ; - le ou chaque système consommateur de données est propre à passer dans l’état invalide une capsule de données qui ne provient pas du système producteur de données attendu, qui n’est pas dans l’état intègre ou qui n’est pas dans l’état de rafraîchissement attendu et à maintenir dans l’état invalide des capsules de données qui suivent une capsule de donnée placée dans l’état invalide, le ou chaque système consommateur de données étant propre à repasser dans l’état valide au moins une capsule de données suivant une pluralité de capsules maintenues dans l’état invalide lorsque les capsules de données maintenues dans l’état invalide proviennent du système producteur de données attendu, qu’elles sont dans l’état intègre et qu’elles sont dans l’état de rafraîchissement attendu pendant une période de réarmement prédéfinie ; - la liaison de transfert met en œuvre un protocole de transfert générant des mots, chaque capsule de données étant émise à l’aide d’une pluralité de mots ; - la pluralité de mots comporte : - au moins un mot d’identification comprenant l’identifiant et/ou l’indicateur de rafraichissement ; - éventuellement au moins un mot de données fonctionnelles contenant des données fonctionnelles du paquet de données fonctionnelles ; - au moins un mot de vérification d’intégrité, contenant le résultat de contrôle d’intégrité ; - la pluralité de mots comprend au moins deux mots distincts de vérification d’intégrité, chaque mot de vérification d’intégrité contenant une partie du résultat de contrôle d’intégrité ; - le système producteur de données est propre à élaborer le résultat de contrôle d’intégrité en adoptant une représentation mémoire à partir des données à répartir dans les mots destinés à transférer la capsule de données, le ou chaque système consommateur de données étant propre à reconstituer la représentation mémoire élaborée par le système producteur de données à partir des données récupérées des mots de la capsule de données, et dans lequel optionnellement, chaque mot comporte des champs caractéristiques du protocole de transfert, au moins une partie des données dans les champs caractéristiques du protocole de transfert étant substituées ou supprimées dans la représentation mémoire ; - la fréquence de transfert des capsules ou la fréquence de réception des capsules est supérieure à la fréquence d’élaboration des capsules, le système consommateur de données étant propre à maintenir au moins une capsule de données dans un état de rafraichissement attendu même si l’incrément de rafraichissement est nul ; - si la fréquence d’élaboration de capsules ou la fréquence de transfert de capsules est supérieure à la fréquence de réception de capsules, le système consommateur de données est propre à placer dans un état de rafraichissement attendu au moins une capsule de données même si l’incrément de rafraichissement est supérieur à 1 ; - le résultat de contrôle d’intégrité est une somme de contrôle ou un code de redondance cyclique. L’invention a également pour objet un système producteur de données destiné à un système de transfert de données d’aéronef, le système producteur de données étant propre à élaborer, à des instants successifs, des données ; caractérisé en ce que le système producteur de données est propre à engendrer, à chaque élaboration de données, une capsule de données, chaque capsule de données comprenant un identifiant du producteur de données, un indicateur de rafraichissement mis à jour à chaque élaboration de données, éventuellement un paquet de données fonctionnelles, et un résultat de contrôle d’intégrité des données portant sur l’identifiant, l’indicateur de rafraichissement et éventuellement le paquet de données fonctionnelles ; chaque capsule de données étant propre à être transférée à un système consommateur de données via un lien de transfert. L’invention a aussi pour objet un système consommateur de données destiné à être utilisé dans un système de transfert de données d’aéronef, le ou chaque système consommateur de données étant propre à recevoir des capsules de données, chaque capsule de données comprenant un identifiant du producteur de données, un indicateur de rafraichissement mis à jour à chaque élaboration de données, éventuellement un paquet de données fonctionnelles, et un résultat de contrôle d’intégrité des données portant sur au moins l’identifiant, l’indicateur de rafraichissement et éventuellement le paquet de données ; chaque capsule de données étant propre à être transférée au système consommateur de données via le lien de transfert ; le ou chaque système consommateur de données étant propre à récupérer chaque capsule de données pour extraire l’identifiant, l’indicateur de rafraichissement, éventuellement le paquet de données fonctionnelles, et le résultat de contrôle d’intégrité, et à contrôler l’intégrité des données de la capsule de données en établissant un nouveau résultat de contrôle d’intégrité à partir d’au moins l’identifiant, l’indicateur de rafraichissement et éventuellement le paquet de données fonctionnelles récupéré dans la capsule de données et en comparant le nouveau résultat de contrôle d’intégrité au résultat de contrôle d’intégrité récupéré dans la capsule de données, la capsule de données étant dans un état intègre lorsque le nouveau résultat de contrôle d’intégrité correspond au résultat de contrôle d’intégrité récupéré dans la capsule de données. L’invention a également pour objet un procédé de transfert de données d’aéronef comprenant les étapes suivantes : - élaboration, à des instants successifs, de données par un système producteur de données ; - transfert des données par un lien de transfert de données entre le système producteur de données et au moins un système consommateur de données ; - réception et, après vérification d’intégrité, utilisation par le ou chaque système consommateur de données, de données produites par le système producteur de données ; l’un au moins du système producteur de données et du ou de chaque système consommateur de données étant embarqué au sein d’un aéronef ; caractérisé par les étapes suivantes : - génération, par le système producteur de données, à chaque élaboration de données, d’une capsule de données, chaque capsule de données comprenant un identifiant du producteur de données, un indicateur de rafraichissement mis à jour à chaque élaboration de données, éventuellement un paquet de données fonctionnelles, et un résultat de contrôle d’intégrité des données portant sur l’identifiant, l’indicateur de rafraichissement et éventuellement le paquet de données fonctionnelles ; - transfert de chaque capsule de données au système consommateur de données via le lien de transfert ; - récupération par le ou chaque système consommateur de données de chaque capsule de données pour extraire l’identifiant, l’indicateur de rafraichissement, éventuellement le paquet de données fonctionnelles, et le résultat de contrôle d’intégrité, et - contrôle d’intégrité des données de la capsule de données, par le ou chaque système consommateur de données en établissant un nouveau résultat de contrôle d’intégrité à partir d’au moins l’identifiant, l’indicateur de rafraichissement et éventuellement le paquet de données fonctionnelles récupéré dans la capsule de données et en comparant le nouveau résultat de contrôle d’intégrité au résultat de contrôle d’intégrité récupéré dans la capsule de données ; - attribution à la capsule de données d’un état intègre lorsque le nouveau résultat de contrôle d’intégrité correspond au résultat de contrôle d’intégrité récupéré dans la capsule de données. Le procédé selon l’invention peut comprendre l’une ou plusieurs des caractéristiques suivantes, prise(s) isolément ou suivant toute combinaison techniquement possible : - le procédé comprend la détermination par le ou chaque système consommateur de données, pour chaque capsule de données reçue, d’un incrément de rafraichissement à partir de l’indicateur de rafraichissement de la capsule de données et à partir de l’indicateur de rafraichissement d’une capsule de données précédemment reçue, et la détermination par le ou chaque système consommateur de données d’un état de rafraichissement de la capsule de données entre un état de rafraichissement attendu et un état de rafraichissement inadéquat en fonction de l’incrément de rafraichissement, et en fonction de la fréquence d’élaboration des capsules, de la fréquence de transfert des capsules, ou/et de la fréquence de réception des capsules ; - le procédé comprend la vérification par le ou chaque système consommateur de données, à partir de l’identifiant de capsule, que le système producteur de données ayant émis la capsule de données est un système producteur de données attendu pour émettre la capsule de données et le passage de la capsule de données dans un état valide permettant l’utilisation des données qu’elle contient lorsque la capsule de données provient du système producteur de données attendu, qu’elle est dans l’état intègre et qu’elle est dans l’état de rafraîchissement attendu. L’invention sera mieux comprise à la lecture de la description qui va suivre, donnée uniquement à titre d’exemple, et faite en se référant aux dessins annexés, sur lesquels : - la est une représentation schématique d’un système de transfert de données d’aéronef selon l’invention; - la est une représentation schématique du contenu d’une capsule utilisée pour transférer des données au sein du système de transfert de la ; - la est une représentation schématique illustrant la structure d’une capsule émise via un protocole de transmission utilisant des mots, dans un exemple où l’identifiant et l’indicateur de rafraichissement sont placés dans le même mot ; - la est une vue détaillée de la représentation d’un mot du protocole ARINC 429 ; - la est une vue d’une représentation mémoire d’une suite de mots formant une capsule, en vue de mettre en œuvre un test d’intégrité ; - la est une vue analogue à la d’une variante de système de transfert de données selon l’invention. Un premier système 10 de transfert de données selon l’invention d’aéronef 12 est illustré schématiquement par la . L’aéronef 12 est par exemple un avion d’affaires, un avion militaire, un avion de transport de passagers ou de marchandises, ou le véhicule aérien d’un drone. Les données transférées par le système 10 sont des données fonctionnelles produites ou reçues dans l’aéronef, par exemple des résultats de mesures physiques de capteurs de l’aéronef, des données d’ordres de commande de systèmes de l’aéronef, des données de suivi d’états de systèmes de l’aéronef, des données avioniques. Ces données fonctionnelles sont transportées et codées en binaire sous forme de chaînes de bits. En référence à la , le système de transfert 10 comporte un système producteur de données 14, au moins un système consommateur de données 16 et un lien 18 de transfert de données entre le système producteur 14 et le ou chaque système consommateur 16. Le système producteur de données 14 et le système consommateur de données 16 sont par exemple deux systèmes avions distincts de l’aéronef 12. Le lien de transfert de données 18 est alors une liaison de transmission présente dans l’aéronef 12, telle qu’une liaison physique de transmission de données à travers un réseau de câbles. En variante, au moins un système consommateur de données 16 est extérieur à l’aéronef 12. Il est par exemple situé dans un autre aéronef, une station de contrôle au sol dans le cas d’un drone, etc. En variante encore, le système producteur de données 14 est extérieur à l’aéronef 12. Il est par exemple situé dans un autre aéronef, dans un système de préparation de mission, dans un système de téléchargement de données. Dans ces deux derniers cas, le lien de transfert de données 18 comporte au moins une liaison de transmission de données sans fil depuis l’aéronef 12 ou/et vers l’aéronef 12. Le système producteur de données 14 et le système consommateur de données 16 comprennent alors chacun au moins une ressource de calcul comportant au moins un processeur et au moins une mémoire contenant des modules logiciels propres à être exécutés par le processeur. En variante, les systèmes 14, 16 sont réalisés au moins partiellement sous forme de composants logiques programmables, ou encore sous forme de circuits intégrés dédiés. Dans une variante (non représentée), le système producteur de données 14 et le système consommateur de données 16 sont situés au sein du même système avion, voire dans la même ressource de calcul du système avion, par exemple au niveau de deux couches applicatives distinctes de la même ressource de calcul avion ou dans deux cœurs différents du même processeur. Le système producteur de données 14 est propre à élaborer des données fonctionnelles à des instants successifs, en les engendrant lui-même ou en les recevant d’une source de données fonctionnelles. Selon l’invention, le système producteur de données 14 est propre à transmettre les données élaborées au système consommateur de données 16 par l’intermédiaire du lien de transfert 18, en encapsulant les données fonctionnelles élaborées aux instants successifs dans des capsules 40 successives, dont le contenu et la structure sont illustrés respectivement par les figures 2 et 3. Comme illustré par la , chaque capsule 40 comporte un identifiant de capsule 42, un indicateur de rafraichissement 44, mis à jour par le système producteur de données 14 à chaque élaboration de données fonctionnelles, indépendamment de la fréquence de transmission des données dans le lien de transfert 18, un paquet 46 de données fonctionnelles élaborées par le système producteur de données 14 lors d’une élaboration fonctionnelle de données, et un résultat 48 de contrôle d’intégrité, calculé à partir de l’identifiant 42, de l’indicateur de rafraichissement 44 et du paquet de données 46 de la capsule 40. L’identifiant de capsule 42 est par exemple une chaine de bits permettant d’identifier le système producteur des données 14 ou/et une entité ayant produit les données fonctionnelles au sein du système producteur de données 14. L’identifiant de capsule 42 permet notamment au ou à chaque système consommateur de données 16, à partir d’une sémantique prédéfinie ou/et d’une table de correspondance, d’identifier le producteur des données et le contenu fonctionnel du paquet de données et ainsi de mettre en œuvre un contrôle d’authentification pour s’assurer que les données ont bien été produites par le système producteur des données 14 attendu. L’identifiant de capsule 42 permet d’associer de manière bijective la capsule 40 à un système de transfert 10 considéré (mis en œuvre dans un aéronef 12, plusieurs aéronefs, un ou plusieurs aéronefs et des moyens externes à l’aéronef 12), indépendamment du nombre de liaisons de transfert 18 et de la nature de celles-ci au niveau de l'architecture globale de transmission. Ainsi, à partir de l’identifiant de capsule 42 associé à la capsule 40, il est possible, à partir d’une sémantique prédéfinie ou/et d’une table de correspondance, d’attribuer la capsule 40 à un système de transfert 10 donné incluant un système producteur de données 14 et au moins un système consommateur de données 16. En outre, si les capsules 40 engendrées par un système producteur de données 14 ou/et par une entité au sein du système producteur de données 14 sont toutes de structures identiques, le système consommateur de données 16 est propre à identifier la position du paquet de données 46 dans la capsule 40, la longueur du paquet de données 46 et la position du résultat de contrôle d’intégrité 48, à partir de l’identifiant de capsule 42. L’indicateur de rafraichissement 44 est une chaine de bits codant un numéro d’ordre d’élaboration des données fonctionnelles à chaque élaboration de données fonctionnelles. L’indicateur de rafraichissement 44 est par exemple un compteur ou un décompteur généralement mis à jour unitairement à chaque élaboration de données fonctionnelles. Il permet d’associer, à chaque capsule 40 transmise, une mesure de rafraîchissement des données. Cette mesure permet de s’assurer que les données fonctionnelles récupérées par le système consommateur de données 16 ont bien été rafraîchies par le système producteur de données 14, constituant un contrôle de rafraichissement. Le paquet de données 46 est une chaine de bits codant les données fonctionnelles générées lors de l’élaboration de données fonctionnelles associée à l’indicateur de rafraichissement 44. Le résultat de contrôle d’intégrité 48 est une chaine de bits codant un nombre de contrôle calculé par un traitement mathématique, à partir d’une représentation fonctionnelle intégrant l’identifiant 42 de la capsule 40, l’indicateur de rafraichissement 44 de la capsule 40, et les données fonctionnelles 46 de la capsule 40. De préférence, le résultat de contrôle d’intégrité 48 est le résultat d’une somme de contrôle, ou d’un code de redondance cyclique (CRC). Le traitement mathématique est par exemple un algorithme choisi en fonction des objectifs de sécurité à atteindre, de la longueur minimale/maximale du paquet de données 46, de l’identifiant 42, de l’indicateur de rafraichissement 44, et de la fiabilité de la liaison de données, en terme de taux d’erreur de bits (en anglais BER, pour « Bit Error Rate »). Des exemples d’algorithmes utilisés sont décrits dans le document DOT/FA/TC-14/49 de l’Administration Fédérale d’Aviation des Etats-Unis d’Amérique, mars 2015, disponible à l’adresse suivante : https://www.faa.gov/aircraft/air_cert/design_approvals/air_software/media/TC-14-49.pdf. Dans l’exemple représenté sur la , le lien de transfert de données 18 est une liaison mettant en œuvre un protocole de transfert de données utilisant des mots 50 contenant des informations de gestion du protocole de transmission et des informations fonctionnelles, vues de ce protocole. Dans une variante, qui sera décrite plus bas, le lien de transfert de données 18 est une liaison mettant en œuvre un protocole de transfert de données utilisant des messages qui permettant l'émission atomique de plusieurs mots 50, certains contenant exclusivement des informations de gestion du protocole de transmission et les autres exclusivement des informations fonctionnelles, vues de ce protocole. Un exemple de protocole de transfert de données utilisant des mots 50 est représenté sur la . Ce protocole est avantageusement mis en œuvre dans une liaison ARINC 429. Chaque mot 50 est défini par une suite de bits, présentant un nombre prédéfini de bits. Le mot 50 pour l’ARINC 429, comporte trente-deux bits. Comme expliqué plus haut, il est communément désigné par le terme « mot ARINC 429 », voire « label ». Le mot 50 est découpé en des champs distincts. Dans l’exemple représenté sur la , le mot 50 comporte un champ 52 d’identification du mot (ID), et avantageusement, un champ 54 d’identification du récepteur ou/et du sous-système ayant émis la donnée (champ optionnel SDI dans la norme ARINC 429). Le mot 50 comprend en outre un champ 56 contenant les données (D) transportées par le mot, un champ 58 de validité de données (SSM) ou de signe/sens (ex : +/- ou Nord/Sud, Est/Ouest), et un champ (P) de parité 60. Le champ 52 contient une identification du mot, avec une sémantique normalisée définie lors de l’élaboration du mot. Le champ 54 (optionnel) est destiné généralement à définir à quel récepteur de la donnée est destiné le mot, ou quel sous-système de l’émetteur a émis la donnée. Le champ 56 contient les données devant être transmises par le mot 50. Dans cet exemple il comporte dix-neuf bits. Le champ 58 contient un identifiant de validité des données, engendré par le système producteur de données 14, pouvant permettre d’identifier si le système producteur de données 14 considère que les données sont valables ou si au contraire il considère qu’elles ne sont plus valables. Le champ de parité 60 est d’un calcul de la somme binaire de tous les bits des champs 52, 54, 56 et 58 pour déterminer la parité de la somme. Dans le cas où le lien de transfert 18 est une liaison mettant en œuvre des mots 50, la taille de la capsule 40 est généralement supérieure à la taille du champ 56 des données transportées par un mot 50. Comme illustré par la , la capsule 40 est ainsi émise sur une pluralité de mots distincts 50A à 50F en répartissant l’identifiant 42, l’indicateur de rafraichissement 44, les données fonctionnelles 46 et le résultat de contrôle d’intégrité 48 dans les champs 56 de plusieurs mots 50A à 50F. De préférence, au moins un premier mot 50A d’identification contient l’identifiant 42 de la capsule 40 et éventuellement, l’indicateur de rafraichissement 44. Avantageusement, le mot 50A contient à la fois l’identifiant 42 de la capsule 40, et l’indicateur de rafraichissement 44. De préférence, pour limiter la bande passante consommée, l’identifiant 42 de la capsule 40 est formé par le champ 52 d’identification du mot 50A, et par le champ 54 d’identification du récepteur ou/et du sous-système ayant émis la donnée. Ceci est possible en établissant une table de correspondance entre chaque capsule 40 et les identifiants successifs des mots 50A à 50F utilisés pour émettre la capsule 40. Par exemple, si chaque capsule 40 correspondant à une élaboration de données fonctionnelle est émise sur N mots 50, les N identifiants successifs des N mots 50 sont associés à la capsule 40. L’indicateur de rafraichissement 40 est codé sous forme binaire dans le champ 56 du mot 50A, par exemple en utilisant 16 des 19 bits disponibles dans le champ 56. Dans une variante (non représentée), le mot 50A contient l’identifiant 42 de la capsule 40, par exemple dans le champ 56 et un autre mot d’identification (non représenté) distinct du mot 50A contient l’indicateur de rafraichissement 44 dans le champ 56. En fonction de la taille du paquet de données fonctionnelles 46 produit à chaque élaboration de données fonctionnelles, le paquet de données fonctionnelles 46 est émis sur au moins un mot de données fonctionnelles 50B à 50D, généralement sur plusieurs mots de données fonctionnelles 50B à 50D. Les données du paquet de données fonctionnelles 46 sont réparties sur les champs 56 du ou des mots 50B à 50D qui contiennent uniquement des données fonctionnelles. Les mots 50B à 50D de données fonctionnelles ne contiennent pas l’indicateur de rafraichissement 44 ou le résultat du test d’intégrité 48. L’identifiant de chaque mot 50B à 50D permet d’identifier à quelle capsule 40 appartiennent les données fonctionnelles contenues dans le champ 56 du mot 50B à 50D. Le résultat de contrôle d’intégrité 48 de chaque capsule 40 est émis sur au moins un mot de vérification d’intégrité 50E, 50F, avantageusement sur deux mots de vérification d’intégrité 50E, 50F, lorsqu’il comporte trente-deux bits, alors que le champ 56 de chaque mot 50E, 50F contient uniquement 19 bits. La capsule 40 ainsi créée est ensuite transférée via le lien de transfert 18 en la répartissant sur plusieurs mots 50A à 50F, pour s’adapter au protocole de transfert présent dans l’aéronef 12. A cet effet, en référence à la , le système producteur de données 14, comporte un module 70 d’élaboration de données fonctionnelles 46 et d’association avec un identifiant 42 de capsule 40 et avec un indicateur de rafraichissement 44, un module 72 de calcul d’un résultat de contrôle d’intégrité 48, établi sur l‘identifiant 42, l’indicateur de rafraichissement 44, et le paquet de données 46, à chaque élaboration de données fonctionnelles, et un module 74 de mise en forme pour le transfert de données via la liaison de transfert 18. Le module d’élaboration de données 70 est propre à engendrer des données fonctionnelles telles que définies plus haut, ou à récupérer des données fonctionnelles applicatives d’autres systèmes avion, via une couche applicative. Les données fonctionnelles sont élaborées à des instants successifs, sur requête ou à une fréquence d’élaboration de données fonctionnelles prédéfinie. Les données fonctionnelles sont distinctes des données de transport (par exemple identifiant de mot) nécessaires pour mettre en œuvre la liaison de transfert 18. Le module d’élaboration de données 70 est ainsi propre à créer un paquet de données fonctionnelles 46 à chaque élaboration de données, de taille généralement identique pour chaque élaboration de données. Il est propre à associer à chaque paquet de données fonctionnelles 46 élaboré, un identifiant 42, permettant d’identifier le contenu fonctionnel du paquet de données fonctionnelles 46, son producteur, et l’appartenance du paquet de données fonctionnelles 46 à une capsule 40, à l’aide d’une table de correspondance. Comme indiqué plus haut, l’identifiant 42 définit en outre avantageusement la taille de la capsule 40, la taille du paquet de données 46 et la position de la somme de contrôle d’intégrité 48, à l’aide de la table de correspondance. Le module d’élaboration de données 70 est en outre propre à associer, à chaque élaboration fonctionnelle de données, indépendamment de la fréquence de transmission via le lien 18, un indicateur de rafraichissement 44. L’indicateur de rafraichissement 44 garantit que les données transmises via le lien de transfert 18 sont bien des données valables ayant été rafraîchies. L’indicateur de rafraichissement 44 est codé sur un nombre déterminé de bits par exemple compris entre 8 et 32 . Dans le cas d’un compteur incrémenté, l’indicateur de rafraichissement 44 est propre à se remettre à zéro, lorsque le maximum de l’indicateur de rafraichissement a été atteint. Le module de calcul d’un résultat de contrôle d’intégrité 72 est propre à élaborer une représentation mémoire 80 de l’identifiant 42, de l’indicateur de rafraichissement 44 et du paquet de données 46 au niveau de la couche applicative, indépendamment des couches de transport. Un exemple de représentation mémoire 80 est illustré sur la . Cette représentation mémoire correspond à un transport sous forme de mots 50. En référence à la , les bits destinés au mot 50A d’identifiant ou/et d’indicateur de rafraichissement et aux mots de données 50B à 50D sur lesquels la capsule 40 est émise sont répartis sous forme de lignes, chaque ligne correspondant à un mot (mot ARINC 429 par exemple dans le cas d’une liaison ARINC 429) dans un tableau ayant un nombre de colonnes correspondant au nombre de bits de chaque mot. Les bits spécifiques au protocole de transmission dans chaque mot 50A à 50D sont volontairement forcés dans la représentation mémoire 80 à un bit choisi, par exemple à un bit nul. Par exemple, sur la première ligne 82A du tableau de la représentation mémoire 80 correspondant au mot 50A d’identifiant ou/et d’indicateur de rafraichissement, seuls les bits de l’identifiant 42 et de l’indicateur de rafraichissement 44 sont conservés à leur valeur. Il en est de même pour chaque mot 50B à 50D de transport de données fonctionnelles, correspondant aux lignes 82B à 82D, dans lesquelles les bits correspondant à l’identifiant du mot, au champ SDI, et au calcul de parité, sont forcés volontairement à un bit choisi, ici un bit nul. Seules les données fonctionnelles 46, l’identifiant 42 et l’indicateur de rafraichissement 44 sont conservés dans la représentation mémoire 80. Ainsi, la représentation mémoire 80 permet de tester l’intégrité de l’identifiant 42, et de l’indicateur de rafraichissement 44, grâce à la première ligne 82A de la représentation, et également l’intégrité du paquet de données fonctionnelles 46 réparties sur les lignes 82B à 82D, en intégrant les champs 58 de validité des données. Une fois cette représentation mémoire 80 construite, le module de calcul de résultat d’intégrité 72 est apte à mettre en œuvre un calcul de somme de contrôle, ou/et de code de redondance cyclique tels que défini plus haut. Par exemple, pour assurer une bonne fiabilité de la vérification d’intégrité, le résultat de calcul d’intégrité 48 est obtenu par une somme de contrôle MIL-STD-1760. Le résultat de contrôle est codé dans cet exemple sur trente-deux bits. Le module de mise en forme 74 est alors propre à émettre chaque capsule 40 correspondant à une élaboration de données fonctionnelles, sous forme d’une pluralité de mots 50A à 50F, comme décrit précédemment, et en accord avec le protocole de transmission de données choisi. Dans le cas notamment d’une liaison de type ARINC 429, les identifiants des mots 50A à 50F correspondant à une capsule donnée 40 sont générés avantageusement suivant une sémantique prédéfinie, de sorte que si les mots 50A à 50F sont émis dans le désordre, ou que d’autres mots 50G n’appartenant pas à la capsule 40 sont intercalés entre les mots 50A à 50F de la capsule 40 de manière discontinue, la capsule 40 peut être reconstituée par le système consommateur de données 16 en se fondant sur la sémantique prédéfinie. Le système consommateur de données 16 comporte un module 90 de réception et de traitement de chaque capsule 40, un module de vérification d’intégrité 92 de la capsule 40 et un module 94 de vérification de validité des données de la capsule 40. Le module de réception de capsules 90 est propre à reconstituer chaque capsule 40, notamment en identifiant les différents mots 50A à 50F de la capsule 40 reçus via le lien de transfert 18 via leur champ d’identification 52. Une fois la capsule 40 reconstituée, il est propre à extraire l’identifiant 42, l’indicateur de rafraichissement 44 et le paquet de données 46 correspondant à la capsule 40. Le module de réception de capsules 90 est propre à effectuer un contrôle d’authentification du système producteur de données 14 en vérifiant, à partir de l’identifiant 42, si les données reçues proviennent bien du système producteur de données 14 attendu. Également à partir de l’identifiant 42 de capsule 40, et dans le cas d’une capsule 40 de taille fixe, le module de réception de capsules 90 est apte, à l’aide de la même table de correspondance que celle du système producteur de données 14, de connaître la taille de la capsule 40, la position de l’indicateur de rafraichissement 44, du paquet de données fonctionnelles 46 et de la somme de contrôle d’intégrité 48 au sein de la capsule 40. Le module de vérification d’intégrité 92 est propre à reconstituer la même représentation mémoire 80 que celle élaborée par le système producteur de données 14, à partir des données récupérées de la capsule 40 qui ont été transférées par le lien de transfert 18. Il est propre à appliquer le même algorithme que celui mis en œuvre par le module de calcul de résultats d’intégrité 72 du système producteur de données 14 pour calculer un nouveau résultat de contrôle d’intégrité portant sur les données reçues, incluant l’identifiant 42 de capsule 40, l’indicateur de rafraichissement 44 et le paquet de données fonctionnelles 46. Le module de vérification d’intégrité 92 est propre à déterminer que la capsule 40 comprenant l’identifiant 42, l’indicateur de rafraichissement 44 et le paquet de données 46 est dans un état intègre, si le nouveau résultat de contrôle d’intégrité qu’il a calculé à partir des données reçues est identique au résultat de contrôle d’intégrité 48 calculé par le système producteur de données 14, extrait de la capsule 40. Il est propre à déterminer que la capsule 40 incluant l’identifiant 42, l’indicateur de rafraichissement 44 et le paquet de données 46 est dans un état corrompu, si le nouveau résultat de contrôle d’intégrité qu’il a calculé à partir des données reçues est différent du résultat de contrôle d’intégrité 48 calculé par le système producteur de données 14 Une fois l’intégrité de l’indicateur de rafraichissement 44 confirmée, le module de vérification de validité 94 est propre à évaluer le rafraichissement des données contenues dans la capsule 40 en effectuant un contrôle de rafraichissement sur la base de l’indicateur de rafraichissement 44. À cet effet, il est propre à comparer l’indicateur de rafraichissement 44 de chaque capsule 40 reçue au compteur 44 reçu d’une capsule 40 précédente pour vérifier que l’indicateur de rafraichissement 44 s’est rafraichi, par exemple en s’étant incrémenté, ou décrémenté, ou en ayant suivi une évolution attendue de rafraichissement. Le module de vérification de validité 94 est propre par exemple à calculer l’incrément de rafraichissement entre l’indicateur de rafraichissement 44 de la capsule 40 reçue, et l’indicateur de rafraichissement 44 de la capsule 40 reçue juste avant. Dans le cas notamment d’un compteur ou d’un décompteur, si l’incrément est unitaire en valeur absolue, le module de vérification de validité 94 est propre à déterminer que les données fonctionnelles présentes dans la capsule 40 sont bien des données rafraîchies et à placer la capsule 40 dans un état de rafraichissement attendu. Dans le cas d’une fréquence de transmission via le lien 18 ou d’acquisition des données par le système consommateur de données 16 plus élevée que la fréquence d’élaboration des données fonctionnelles par le système producteur de données 14, le module de vérification de validité 94 est propre à autoriser un incrément de rafraichissement nul sur un nombre de capsules 40 déterminé, calculé par exemple en fonction des fréquences d’élaboration, de transmission ou d’acquisition des capsules 40. Au-delà du nombre de capsules 40 déterminé, si l’indicateur de rafraichissement 44 reste identique, il est apte à passer la capsule 40 dans un état de rafraichissement inadéquat, car ses données n’ont pas été rafraichies. Par ailleurs, lorsque la fréquence d’élaboration ou/et de transmission des capsules 40 est supérieure à la fréquence d’acquisition des capsules 40, le module de vérification de validité 94 est propre à autoriser un incrément de rafraichissement soit supérieur à un. Dans tous les cas, le module de vérification de validité 94 est propre à mémoriser l’indicateur de rafraichissement de chaque capsule 40 venant d’être reçue, pour permettre un calcul d’incrément lors de la réception de la capsule 40 suivante. Il est également propre à tenir compte de la mise à zéro de l’indicateur de rafraichissement 44, lorsque celui-ci atteint sa valeur maximale. Ainsi, en fonction de l’incrément calculé entre les compteurs 44 de deux capsules 40 successives, le module de vérification de validité 94 est propre à déterminer si les données fonctionnelles présentes dans la capsule 40 sont bien des données rafraîchies pouvant être utilisées par le système consommateur 16, et à passer la capsule 40 dans un état de rafraîchissement attendu. Si au contraire, les données ne sont pas rafraichies ou s’il manque des données intermédiaires non reçues, il est propre à passer la capsule 40 dans un état de rafraichissement inadéquat. Lorsque la capsule 40 provient du système producteur de données 14 attendu, qu’elle est dans l’état intègre et qu’elle est dans l’état de rafraîchissement attendu, les données fonctionnelles qu’elle contient sont considérées valides et sont alors propres à être utilisées par le système consommateur 16, ou à être transmises à un autre système avion pour être utilisées. Lorsqu’une capsule 40 ne provient pas du système producteur de données 14 attendu, ou qu’elle est dans l’état corrompu ou encore dans un état de rafraîchissement inadéquat, le module de vérification de validité 94 est propre à exclure les données provenant de la capsule 40, qui sont considérées invalides. Le module de vérification de validité 94 est avantageusement propre à mettre en œuvre une phase de réarmement, pendant une durée de réarmement donnée correspondant par exemple à la réinitialisation d’un calculateur ou à l’arrêt d’une panne transitoire. Dans ce cas, dès qu’une nouvelle capsule 40 est reçue, en provenant du système producteur de données 14 attendu et en étant dans l’état intègre, le module de vérification de validité 94 est propre à mémoriser la nouvelle valeur de l’indicateur de rafraichissement 44 de cette capsule 40. Ensuite, il est propre à récupérer l’indicateur de rafraichissement 40 de chaque nouvelle capsule 40 arrivant, pour déterminer un incrément de rafraichissement. Si l’incrément de rafraichissement traduit un état de rafraichissement attendu, le module de vérification de validité 94 est propre, après la durée prédéfinie de réarmement, à passer à nouveau les capsules 40 dans l’état valide. Dans certains cas, si la panne d’intégrité ou de rafraîchissement affectant les données contenues dans les capsules 40 est battante, c’est-à-dire qu’elle se produit régulièrement ou de manière arbitraire, le module de vérification de validité 94 est propre à stopper de manière définitive le réarmement et à déclarer le système de transfert de données 10 en défaut. Grâce à l’invention qui vient d’être décrite, il est donc possible d’encapsuler des données fonctionnelles en les sécurisant au niveau applicatif, lors de chaque élaboration de données et non au niveau de la transmission de données, en intégrant dans chaque capsule 40 un identifiant 42, un indicateur de rafraichissement 44, et un résultat de contrôle d’intégrité 48 qui tient compte de l’identifiant 42, de l’indicateur de rafraichissement 44, et des données fonctionnelles sans tenir compte des couches de transmission. Les données fonctionnelles ainsi encapsulées sont donc très sécurisées, indépendamment du ou des protocoles de transmission utilisés. Ceci empêche que la perte ou l’erroné de ces données ne produise des conséquences critiques. De telles capsules 40 peuvent être transférées via un lien de transfert de données 18 qui utilise des mots 50, sans affecter la syntaxe des mots 50, et en répartissant le contenu de la capsule 40 sur différents mots 50A à 50F. La mise à jour de l’indicateur de rafraichissement 44 à chaque élaboration de données fonctionnelles assure qu’un rafraîchissement des données s’est produit, et non simplement qu’une nouvelle transmission de données s’est produite. Il est ainsi possible de transmettre de manière très sûre, des données numériques d’aéronef, sans risque de perte ou d’erroné des données. Dans la variante illustrée par la , les capsules 40 contenant les données transitent par un système intermédiaire 100 entre le système producteur de données 14 et le système consommateur 16. Un premier lien de transfert de données 18A s’étend entre le système producteur 14 et le système intermédiaire 100, et un deuxième lien 18B de transfert de données s’étend entre le système intermédiaire 100 et le système consommateur 16. Eventuellement, les capsules 40 sont transférées suivant un premier protocole de transfert à travers le premier lien 18A, et selon un deuxième protocole de transfert, à travers le deuxième lien 18B. Cependant, quel que soit le protocole de transfert utilisé sur les liens 18A, 18B respectifs, l’identifiant 42, l’indicateur de rafraichissement 44, le paquet de données fonctionnelles 46 et le résultat d’intégrité 48 restent transmis depuis le système producteur 14 jusqu’au système consommateur 16, permettant d’assurer le contrôle de l’intégrité et du rafraîchissement des données par le système consommateur 16. Dans une variante, non représentée, la capsule 40 est transmise à travers un protocole de transmission utilisant des messages constitués de plusieurs mots 50 consécutifs, généralement émis sous forme atomique, les uns à la suite des autres. Généralement, au moins un mot 50 de chaque message contient juste des informations de gestion du protocole de transmission. La capsule 40 est alors répartie sur plusieurs mots 50 du même message ne contenant pas d’informations de gestion du protocole de transmission, contrairement au protocole décrit plus haut dans lequel chaque mot 50 contient des d’informations de gestion du protocole de transmission. Un ou plusieurs mots du même message contiennent alors l’identifiant de capsule 42 et l’indicateur de rafraîchissement 44, un ou plusieurs mots du même message contiennent les données fonctionnelles 46 et un ou plusieurs mots du même message contiennent le résultat 48 de contrôle d’intégrité, calculé à partir de l’identifiant 42, de l’indicateur de rafraichissement 44 et du paquet de données 46 de la capsule 40. Dans encore une autre variante (non représentée), chaque capsule 40 est répartie sur une pluralité de messages en répartissant l’identifiant de capsule 42, l’indicateur de rafraîchissement 44, les données fonctionnelles 46 et le résultat 48 de contrôle d’intégrité sur des mots de la pluralité de messages. Dans une autre variante (non représentée), la capsule 40 est dépourvue de données fonctionnelles 46. La capsule 40 en tant que telle comprenant alors l’identifiant de capsule 42, l’indicateur de rafraîchissement 44, et le résultat 48 de contrôle d’intégrité portant sur l’identifiant 42 et sur l’indicateur de rafraîchissement 44 est alors l’équivalent d’un signal pour déclencher ou valider une action. La donnée transmise par la capsule 40 est alors la présence ou non de la capsule 40. Système (10) de transfert de données d’aéronef (12) comportant : - un système (14) producteur de données, propre à élaborer, à des instants successifs, des données ; - au moins un système (16) consommateur de données, propre à recevoir et à utiliser les données produites par le système producteur de données (14) ; l’un au moins du système producteur de données (14) et du ou de chaque système consommateur de données (16) étant embarqué au sein d’un aéronef (12) ; - un lien (18) de transfert de données entre le système producteur de données (14) et le ou chaque système consommateur de données (16) ; caractérisé en ce que le système producteur de données (14) est propre à engendrer, à chaque élaboration de données, une capsule de données (40), chaque capsule de données (40) comprenant un identifiant (42) du producteur de données, un indicateur de rafraichissement (44) mis à jour à chaque élaboration de données, éventuellement un paquet de données fonctionnelles (46), et un résultat (48) de contrôle d’intégrité des données portant sur au moins l’identifiant (42) l’indicateur de rafraichissement (44) et éventuellement le paquet de données fonctionnelles (46) ; chaque capsule de données (40) étant propre à être transférée au ou à chaque système consommateur de données (16) via le lien de transfert (18) ; le ou chaque système consommateur de données (16) étant propre à récupérer chaque capsule de données (40) pour extraire l’identifiant (42), l’indicateur de rafraichissement (44), éventuellement le paquet de données fonctionnelles (46), et le résultat de contrôle d’intégrité (48), et à contrôler l’intégrité des données de la capsule de données (40) en établissant un nouveau résultat de contrôle d’intégrité à partir d’au moins l’identifiant (42) l’indicateur de rafraichissement (44) et éventuellement le paquet de données fonctionnelles (46) récupéré dans la capsule de données (40) et en comparant le nouveau résultat de contrôle d’intégrité au résultat de contrôle d’intégrité (48) récupéré dans la capsule de données (40), la capsule de données (40) étant dans un état intègre lorsque le nouveau résultat de contrôle d’intégrité correspond au résultat de contrôle d’intégrité (48) récupéré dans la capsule de données (40). Système de transfert (10) selon la revendication 1, dans lequel chaque capsule de données (40) comprend un paquet de données fonctionnelles (46), le résultat (48) de contrôle d’intégrité des données de la capsule portant sur au moins l’identifiant (42), l’indicateur de rafraichissement (44) et le paquet de données fonctionnelles (46), le ou chaque système consommateur de données (16) étant propre à extraire le paquet de données fonctionnelles (46) et à contrôler l’intégrité des données de la capsule de données (40) en établissant un nouveau résultat de contrôle d’intégrité à partir d’au moins l’identifiant (42), l’indicateur de rafraichissement (44) et le paquet de données fonctionnelles (46). Système de transfert (10) selon la revendication 1 ou 2, dans laquelle le ou chaque système consommateur de données (16) est propre à comparer l’identifiant (42) reçu dans chaque capsule de données (40) à un identifiant prédéfini sur la base d’une sémantique ou d’une table de correspondance pour en déduire au moins une caractéristique de contenu de la capsule de données (40). Système de transfert selon la revendication 3, dans laquelle le système producteur de données (14) émet des capsules de données (40) de taille fixe, le ou chaque système consommateur de données (16) étant propre à déterminer la taille de la capsule de données (40), la taille et/ou la position de l’identifiant (42), de l’indicateur de rafraichissement (44), éventuellement du paquet de données fonctionnelles (46) ou/et du résultat de contrôle d’intégrité (48) dans la capsule de données (40), à partir d’une sémantique ou d’une table de correspondance reliant l’identifiant prédéfini, à la taille de la capsule de données (40), à la taille et/ou la position de l’identifiant (42), de l’indicateur de rafraichissement (44), éventuellement du paquet de données fonctionnelles (46) ou/et du résultat de contrôle d’intégrité (48) dans la capsule de données (40). Système de transfert (10) selon l’une quelconque des revendications précédentes, dans lequel le ou chaque système consommateur de données (16) est propre, pour chaque capsule de données (40) reçue, à déterminer un incrément de rafraichissement à partir de l’indicateur de rafraichissement (44) de la capsule de données (40) et à partir de l’indicateur de rafraichissement (44) d’une capsule de données (40) précédemment reçue, le ou chaque système consommateur de données (16) étant propre à déterminer un état de rafraichissement de la capsule de données (40) entre un état de rafraichissement attendu et un état de rafraichissement inadéquat en fonction de l’incrément de rafraichissement, et en fonction de la fréquence d’élaboration des capsules, de la fréquence de transfert des capsules, ou/et de la fréquence de réception des capsules. Système de transfert (10) selon la revendication 5, dans lequel le ou chaque système consommateur de données (16) est propre à vérifier, à partir de l’identifiant de capsule (42), que le système producteur de données (14) ayant émis la capsule de données (40) est un système producteur de données attendu pour émettre la capsule de données (40), le ou chaque système consommateur de données (16) étant propre à passer la capsule de données (40) dans un état valide permettant l’utilisation des données qu’elle contient lorsque la capsule de données (40) provient du système producteur de données (14) attendu, qu’elle est dans l’état intègre et qu’elle est dans l’état de rafraîchissement attendu. Système de transfert (10) selon la revendication 5 ou 6, dans lequel le ou chaque système consommateur de données (16) est propre à passer dans l’état invalide une capsule de données (40) qui ne provient pas du système producteur de données (14) attendu, qui n’est pas dans l’état intègre ou qui n’est pas dans l’état de rafraîchissement attendu et à maintenir dans l’état invalide des capsules de données (40) qui suivent une capsule de donnée (40) placée dans l’état invalide, le ou chaque système consommateur de données (16) étant propre à repasser dans l’état valide au moins une capsule de données (40) suivant une pluralité de capsules maintenues dans l’état invalide lorsque les capsules de données (40) maintenues dans l’état invalide proviennent du système producteur de données (14) attendu, qu’elles sont dans l’état intègre et qu’elles sont dans l’état de rafraîchissement attendu pendant une période de réarmement prédéfinie. Système de transfert (10) selon l’une quelconque des revendications précédentes, dans lequel la liaison de transfert (18) met en œuvre un protocole de transfert générant des mots (50), chaque capsule de données (40) étant émise à l’aide d’une pluralité de mots (50A à 50F). Système de transfert (10) selon la revendication 8, dans lequel la pluralité de mots (50A à 50F) comporte : au moins un mot (50A) d’identification comprenant l’identifiant (42) et/ou l’indicateur de rafraichissement (44) ; éventuellement au moins un mot (50B à 50D) de données fonctionnelles contenant des données fonctionnelles du paquet de données fonctionnelles (46) ; au moins un mot (50E, 50F) de vérification d’intégrité, contenant le résultat de contrôle d’intégrité (48). Système de transfert (10) selon la revendication 9, dans lequel la pluralité de mots (50A à 50F) comprend au moins deux mots distincts (50E, 50F) de vérification d’intégrité, chaque mot de vérification d’intégrité (50E, 50F) contenant une partie du résultat de contrôle d’intégrité (48). Système de transfert (10) selon l’une quelconque des revendications précédentes, dans lequel le système producteur de données (14) est propre à élaborer le résultat de contrôle d’intégrité (48) en adoptant une représentation mémoire (80) à partir des données à répartir dans les mots (50A à 50F) destinés à transférer la capsule de données (40), le ou chaque système consommateur de données (16) étant propre à reconstituer la représentation mémoire (80) élaborée par le système producteur de données (14) à partir des données récupérées des mots (50A à 50F) de la capsule de données (40), et dans lequel optionnellement, chaque mot (50A à 50F) comporte des champs (52, 54, 60) caractéristiques du protocole de transfert, au moins une partie des données dans les champs (52, 54, 60) caractéristiques du protocole de transfert étant substituées ou supprimées dans la représentation mémoire (80). 1 2 . Système producteur de données (14), destiné à un système de transfert de données (10) d’aéronef (12), le système producteur de données (14) étant propre à élaborer, à des instants successifs, des données ; caractérisé en ce que le système producteur de données (14) est propre à engendrer, à chaque élaboration de données, une capsule de données (40), chaque capsule de données (40) comprenant un identifiant (42) du producteur de données, un indicateur de rafraichissement (44) mis à jour à chaque élaboration de données, éventuellement un paquet de données fonctionnelles (46), et un résultat (48) de contrôle d’intégrité des données portant sur l’identifiant (42), l’indicateur de rafraichissement (44) et éventuellement le paquet de données fonctionnelles (46) ; chaque capsule de données (40) étant propre à être transférée à un système consommateur de données (16) via un lien de transfert (18). 1 3 . Système consommateur de données (16), destiné à être utilisé dans un système de transfert de données (10) d’aéronef (12), le ou chaque système consommateur de données (16) étant propre à recevoir des capsules de données (40), chaque capsule de données comprenant un identifiant (42) du producteur de données, un indicateur de rafraichissement (44) mis à jour à chaque élaboration de données, éventuellement un paquet de données fonctionnelles (46), et un résultat de contrôle d’intégrité des données portant sur au moins l’identifiant (42), l’indicateur de rafraichissement (44) et éventuellement le paquet de données (46) ; chaque capsule de données (40) étant propre à être transférée au système consommateur de données (16) via le lien de transfert (18) ; le ou chaque système consommateur de données (16) étant propre à récupérer chaque capsule de données (40) pour extraire l’identifiant (42), l’indicateur de rafraichissement (44), éventuellement le paquet de données fonctionnelles (46), et le résultat de contrôle d’intégrité (48), et à contrôler l’intégrité des données de la capsule de données (40) en établissant un nouveau résultat de contrôle d’intégrité à partir d’au moins l’identifiant (42), l’indicateur de rafraichissement (44) et éventuellement le paquet de données fonctionnelles (46) récupéré dans la capsule de données (40) et en comparant le nouveau résultat de contrôle d’intégrité au résultat de contrôle d’intégrité (48) récupéré dans la capsule de données (40), la capsule de données (40) étant dans un état intègre lorsque le nouveau résultat de contrôle d’intégrité correspond au résultat de contrôle d’intégrité (48) récupéré dans la capsule de données (40). 1 4 . Procédé de transfert de données d’aéronef (12) comprenant les étapes suivantes : - élaboration, à des instants successifs, de données par un système producteur de données (14) ; - transfert des données par un lien de transfert de données (18) entre le système producteur de données (14) et au moins un système consommateur de données (16) ; - réception et, après vérification d’intégrité, utilisation par le ou chaque système consommateur de données (16), de données produites par le système producteur de données (14) ; l’un au moins du système producteur de données (14) et du ou de chaque système consommateur de données (16) étant embarqué au sein d’un aéronef (12); caractérisé par les étapes suivantes : - génération, par le système producteur de données (14), à chaque élaboration de données, d’une capsule de données (40), chaque capsule de données (40) comprenant un identifiant (42) du producteur de données (14), un indicateur de rafraichissement (44) mis à jour à chaque élaboration de données, éventuellement un paquet de données fonctionnelles (46), et un résultat de contrôle d’intégrité des données (48) portant sur l’identifiant (42), l’indicateur de rafraichissement (44) et éventuellement le paquet de données fonctionnelles (46) ; - transfert de chaque capsule de données (40) au système consommateur de données via le lien de transfert (18) ; - récupération par le ou chaque système consommateur de données (16) de chaque capsule de données (40) pour extraire l’identifiant (42), l’indicateur de rafraichissement (44), éventuellement le paquet de données fonctionnelles (46), et le résultat de contrôle d’intégrité (48), et - contrôle d’intégrité des données de la capsule de données (40), par le ou chaque système consommateur de données (16) en établissant un nouveau résultat de contrôle d’intégrité à partir d’au moins l’identifiant (42), l’indicateur de rafraichissement (44) et éventuellement le paquet de données fonctionnelles (46) récupéré dans la capsule de données (40) et en comparant le nouveau résultat de contrôle d’intégrité au résultat de contrôle d’intégrité (48) récupéré dans la capsule de données (40) ; - attribution à la capsule de données (40) d’un état intègre lorsque le nouveau résultat de contrôle d’intégrité correspond au résultat de contrôle d’intégrité (48) récupéré dans la capsule de données (40). 1 5 . Procédé selon la revendication 14, comprenant la détermination par le ou chaque système consommateur de données (16), pour chaque capsule de données (40) reçue, d’un incrément de rafraichissement à partir de l’indicateur de rafraichissement (44) de la capsule de données (40) et à partir de l’indicateur de rafraichissement (44) d’une capsule de données (40) précédemment reçue, et la détermination par le ou chaque système consommateur de données (16) d’un état de rafraichissement de la capsule de données (40) entre un état de rafraichissement attendu et un état de rafraichissement inadéquat en fonction de l’incrément de rafraichissement, et en fonction de la fréquence d’élaboration des capsules, de la fréquence de transfert des capsules, ou/et de la fréquence de réception des capsules. 1 6 . Procédé selon la revendication 15, comprenant la vérification par le ou chaque système consommateur de données (16), à partir de l’identifiant de capsule (42), que le système producteur de données (14) ayant émis la capsule de données (40) est un système producteur de données attendu pour émettre la capsule de données (40) et le passage de la capsule de données (40) dans un état valide permettant l’utilisation des données qu’elle contient lorsque la capsule de données (40) provient du système producteur de données (14) attendu, qu’elle est dans l’état intègre et qu’elle est dans l’état de rafraîchissement attendu.