Brevet FR3031822A1 — publié le 20160722

TÉLÉCHARGEMENT DE DONNÉES SUR UN ÉQUIPEMENT DISTANT DESCRIPTION DOMAINE DE L'INVENTION La présente invention se rapporte au domaine de téléchargement déporté de données sur un équipement distant via une passerelle et, plus particulièrement, concerne un téléchargement déporté de données sur un équipement téléchargeable d'un aéronef via une plateforme modulaire. Dans différents domaines industriels comme par exemple l'aéronautique, le ferroviaire, le naval ou l'automobile, il est souvent nécessaire de mettre à jour des calculateurs ou équipements téléchargeables. En particulier, dans le domaine aéronautique, sur les anciennes générations d'aéronefs, chaque système d'action ou de commande (par exemple, le train d'atterrissage, le système d'alimentation, etc.) développait son propre calculateur appelé « équipement remplaçable en escale» LRU (Line Replaceable Unit) et administrait différents éléments (les périphériques, les câbles, les entrées, les sorties, les capteurs, les actionneurs, etc.). Chaque calculateur ou unité LRU comportait une partie matérielle et une partie logicielle. Actuellement, afin de réduire les coûts et d'optimiser la masse d'un aéronef, les parties matérielles ont été séparées des parties logicielles pour former une architecture avionique intégrée et modulaire appelée IMA (Integrated Modular Avionics). Ce système modulaire IMA permet de diminuer le nombre d'équipements dans un aéronef et, par conséquent, de réduire les coûts de développement et de qualification. Dans le cadre d'une architecture modulaire de type IMA, on désigne par téléchargement déporté le téléchargement d'un logiciel, des tables de configuration, d'une partie d'un logiciel ou de toutes autres données dans un équipement distant à travers une passerelle. Le téléchargement déporté fournit ainsi des capacités de téléchargement à des équipements qui ne pourraient pas en bénéficier à moins d'être démontés. Le principe de téléchargement déporté, selon l'art antérieur, consiste pour un utilisateur à sélectionner sur un serveur ou ordinateur de téléchargement HDL (Host Data Loader), les données à télécharger et l'équipement distant pour lequel ces données sont destinées. L'opération de téléchargement déporté est alors initialisée par le HDL et les données sont envoyées à une passerelle, cette passerelle étant en particulier implémentée sur une plateforme IMA. En effet, les données doivent d'abord passer par la passerelle avant d'atteindre l'équipement distant à télécharger. Une application de téléchargement hébergée sur la passerelle reçoit en provenance du HDL, à travers un premier media, les données ainsi que l'adresse de l'équipement. La passerelle traite ces données pour pouvoir les envoyer sur un autre média utilisé par l'équipement destinataire. Enfin, l'application de téléchargement transfère les données à l'équipement distant en utilisant un protocole spécifié par le propriétaire de la passerelle. Ainsi, grâce au téléchargement déporté, il est possible de télécharger directement un équipement distant via une passerelle et à travers différents médias. Toutefois, le téléchargement déporté induit certaines limitations qui peuvent être intrinsèques à l'architecture et, en particulier, au fait d'avoir différents intervenants. En effet, si un équipementier veut mettre à jour le logiciel de son équipement, il est obligé de passer par le HDL et la passerelle qui sont fournis par d'autres équipementiers. Par conséquent, il n'est pas maître du début à la fin de la communication et des protocoles pour mettre à jour son équipement comme ça serait le cas lors d'une mise à jour directe lorsque l'on démonte l'équipement. Ainsi, dans le téléchargement déporté on se trouve avec différents intervenants, différents protocoles et différentes spécifications. En particulier, on se trouve avec un protocole entre le HDL et la passerelle avec le besoin de définir une spécification d'interface entre eux. De plus, on a autant de protocoles que de type de bus entre la passerelle et les différents équipements distants pour lesquels il faut aussi définir des spécifications d'interfaces. En outre, il est nécessaire pour chaque intervenant d'être conforme avec la spécification du téléchargement déporté ainsi qu'avec les normes utilisées et, en particulier, l'équipement qui doit recevoir les données doit être en conformité avec le protocole spécifié par le propriétaire de la passerelle. Or, dans le cas où plusieurs fournisseurs de systèmes n'utilisent pas le même protocole, on doit avoir deux niveaux de spécification d'interface. Au premier niveau, il convient de spécifier l'interface entre le HDL et la passerelle sachant que le nombre de spécifications est multiplié dans le cas de différents types de passerelles. Il convient de spécifier également les interfaces entre chaque équipement distant et le HDL. Chaque fournisseur ou équipementier doit prendre en compte le problème de protocole et de compatibilité de l'équipement avec l'HDL. Au deuxième niveau, il convient de spécifier les interfaces entre la passerelle et chaque équipement en tenant compte des différents médias utilisés. De plus, il convient de prévoir dans chaque passerelle un ensemble de moteurs de téléchargement correspondant à tous les différents protocoles susceptibles d'être utilisés entre la passerelle et les équipements. En effet, cette architecture impose d'avoir pour chaque passerelle une application de téléchargement déporté qui doit pouvoir prendre en compte tous les différents protocoles à la disposition des utilisateurs (A429 (pour ARINC 429), CAN (Controller Area Network), MIL 1553 etc.). Plus particulièrement, pour offrir un maximum de souplesse aux équipements distants connectés sur la passerelle, cette passerelle doit avoir la possibilité de gérer tous les protocoles, ce qui induit un développement supplémentaire et une perte de ressource de calcul et de mémoire (PROM, CPU, RAM, ...) pour d'autres fonctions sur la passerelle. De plus, cela augmente les coûts et temps de développement, de configuration, de test, complique la maturité de la passerelle et contrarie le concept d'une plateforme modulaire générique du fait de devoir développer autant de protocoles que de bus ou protocoles utilisés par les équipements ayant besoin d'être mis à jour via la passerelle implémentée sur une plateforme modulaire IMA. L'intégration de bout à bout devient également complexe et doit être réalisée par le maître d'ceuvre (par exemple le constructeur d'aéronefs ou de trains) car c'est le seul à avoir la vision globale de tous les intervenants durant la phase d'intégration ou d'assemblage. En plus, il existe un risque de découvrir tardivement dans le développement des non-conformités entre les différents intervenants (fournisseur de la plateforme IMA, fournisseur du LRU, fournisseur du HDL) sachant que ces derniers n'ont que très tardivement la possibilité de tester l'application de téléchargement déporté car ils doivent attendre le développement et la disponibilité des HDL et de la plateforme IMA complète. Ils sont donc dépendants de deux autres intervenants. Toutes ces limitations et contraintes peuvent causer des incompréhensions dans les spécifications d'interfaces ou de protocoles qui peuvent générer une perte de temps dans le développement et un coût supplémentaire pour cause de mise à jour de la spécification. L'objet de la présente invention est par conséquent, de remédier aux inconvénients précités en proposant un procédé et un système de téléchargement déporté de données sur un équipement distant via une passerelle permettant à chaque intervenant de s'affranchir des protocoles et connexions spécifiés par les autres intervenants. OBJET ET RÉSUMÉ DE L'INVENTION La présente invention vise à mettre à jour un équipement distant en s'affranchissant des protocoles et connexions et concerne un procédé et un système de téléchargement déporté de données sur un équipement distant, le système comportant une passerelle adaptée pour recevoir un ensemble de données comprenant des données opérationnelles adressées audit équipement distant ainsi qu'un moteur temporaire de téléchargement, ladite passerelle étant en outre adaptée pour télécharger les données opérationnelles dans ledit équipement distant en lançant l'exécution dudit moteur de téléchargement. BRÈVE DESCRIPTION DES DESSINS D'autres particularités et avantages du système et du procédé selon l'invention ressortiront mieux à la lecture de la description faite ci-après, à titre indicatif mais non limitatif, en référence aux dessins annexés sur lesquels : - la Fig. 1 illustre de manière schématique un système de téléchargement déporté de données sur un équipement distant, selon un mode de réalisation de l'invention; - les Figs. 2A et 2B illustrent de manière schématique un système et un procédé de téléchargement déporté de données sur un équipement distant, selon un premier mode de réalisation préféré de l'invention ; et - la Fig. 3 illustre de manière schématique un système de téléchargement déporté de données sur un équipement distant, selon un deuxième mode de réalisation préféré de l'invention. DESCRIPTION DÉTAILLÉE DE MODES DE RÉALISATION Le principe de l'invention consiste notamment à inclure un moteur temporaire de téléchargement dans les données destinées à l'équipement distant. La Fig. 1 illustre de manière schématique un système 1 de téléchargement déporté de données sur un équipement distant 3, selon un mode de réalisation de l'invention. Le système 1 de téléchargement comporte une passerelle 5 adaptée pour recevoir depuis un serveur ou un ordinateur 7 de téléchargement (HDL) un ensemble 9 de données comprenant un sous-ensemble de données opérationnelles 9a, 9b adressées à l'équipement distant 3 ainsi qu'un moteur protocolaire 9c temporaire de téléchargement. On notera que l'ensemble 9 de données est fourni par l'intervenant responsable de l'équipement distant 3 à télécharger et les données opérationnelles 9a, 9b adressées à l'équipement distant comportent l'adresse de cet équipement. La passerelle 5 est en outre adaptée pour télécharger les données opérationnelles dans l'équipement distant 3 en lançant l'exécution du moteur protocolaire de téléchargement 9c. Plus particulièrement, la passerelle 5 comporte un module de gestion 11 adapté pour récupérer et traiter l'ensemble 9 de données afin d'envoyer les données opérationnelles 9b à l'équipement distant 3 grâce au moteur protocolaire de téléchargement 9c. Ainsi, le moteur de téléchargement 9c relatif à la partie protocolaire entre la passerelle 5 et l'équipement distant 3 est récupérée par la passerelle 5 en même temps que les données opérationnelles 9b destinées à l'équipement distant 3. La partie protocolaire est alors laissée sous la responsabilité du fournisseur qui possède cet équipement distant 3 lui permettant de s'affranchir de toutes les spécifications d'interface entre la passerelle 5 et l'équipement distant 3. À titre d'exemple, l'ensemble 9 de données est une couche d'encapsulation configurée selon un format normé et concaténant trois parties. La première partie 9a est un entête de téléchargement relatif à l'équipement distant, la deuxième partie 9b est relative aux données opérationnelles de l'équipement (par exemple, un logiciel ou une partie de celui-ci, une table de configuration, ou toutes autres données) et la troisième partie 9c est le moteur permettant de réaliser le téléchargement de l'équipement distant. Grâce au format normé et à l'entête de téléchargement 9a, le module de gestion 11 hébergé sur la passerelle 5 (type CPIOM (Core Processing Input Output Module) ou CRDC (Common Remote Data Concentrator)) est capable de reconnaitre qu'il doit gérer un téléchargement déporté et utilise le moteur de téléchargement 9c pour télécharger les données opérationnelles 9b dans l'équipement distant 3. Le moteur de téléchargement 9c peut être exécuté comme un binaire classique. Ainsi, le procédé de téléchargement est réalisé en trois étapes. La première étape concerne le téléchargement de l'ensemble 9 de données depuis l'ordinateur de téléchargement 7 vers la passerelle 5 à travers un premier réseau ou média 13a de communication, par exemple de type AFDX (Avionics Full Duplex Switched Ethernet). On notera que les trames dédiées au téléchargement peuvent s'insérer de façon tout à fait classique dans le trafic existant comme un téléchargement point-à-point entre l'ordinateur de téléchargement 7 et la passerelle 5. Il n'est nul besoin de faire une quelconque adaptation de protocole. Cela signifie qu'au niveau de l'ordinateur de téléchargement 7, il est possible d'utiliser un protocole déjà existant en y ajoutant la couche d'encapsulation de l'ensemble 9 de données. La deuxième étape concerne le traitement de l'ensemble 9 de données par la passerelle 5 et finalement, la troisième étape concerne le téléchargement des données opérationnelles 9b depuis la passerelle 5 vers l'équipement distant 3 à travers un deuxième média 13b de communication (par exemple A429, CAN, MIL 1553, etc.). Avantageusement, après la fin du téléchargement, la partie exécutable (i.e. le moteur de téléchargement 9c) est supprimée pour laisser des ressources à d'autres 30 téléchargements. Par ailleurs, la progression du téléchargement peut être avantageusement reportée sur l'interface homme-machine de l'ordinateur de téléchargement 7. Le suivi de l'avancement est réalisé selon les trois étapes de téléchargement. Le suivi de la première étape de téléchargement se déroule de la même manière qu'un téléchargement classique. L'avancement des deuxième et troisième étapes est reporté à l'ordinateur de téléchargement 7 par le module de gestion 11. L'avancement de la deuxième étape est effectué en fonction de la progression du traitement de données par le module de gestion 11. L'avancement de la troisième étape est rapporté par le module de gestion 11 selon un échange protocolaire entre ce dernier et le moteur de téléchargement 9c via par exemple des mémoires de mise en file d'attente du média de communication. Ainsi le moteur de téléchargement 9c peut écrire cycliquement une valeur de l'avancement du téléchargement et cette valeur peut être utilisée par le module de gestion 11 pour construire l'avancement global du téléchargement déporté à l'ordinateur de téléchargement 7. Le système et procédé de téléchargement selon l'invention permet ainsi de gérer tous les protocoles de téléchargement sans augmenter le nombre de ressources. En effet, le module de gestion 11 de la passerelle 5 permet de manière générique de récupérer et de gérer les données à télécharger au cas par cas. De la même façon on diminue les coûts de développement car il n'est plus nécessaire de prévoir tous les cas possibles sur tous les types de passerelles. Il n'y a plus besoin de spécifications d'interfaces entre la passerelle et les équipements distants. Le nombre de spécifications d'interfaces étant drastiquement diminué, les problèmes d'intégration, de développement, et de mise à jour de ces spécifications sont éliminés. En outre, les évolutions protocolaires ne sont plus imputables au maître d'ceuvre. L'intégration passe ainsi sous la responsabilité de l'équipementier qui utilise et développe l'équipement distant, c'est justement lui qui est le mieux placé pour intégrer son système. Les équipementiers sont ainsi totalement libres de choisir leur protocole de téléchargement pour répondre au mieux à leurs besoins ce qui permet de diminuer les coûts de leur côté et de simplifier le développement. La Fig. 2A illustre de manière schématique un système de téléchargement déporté de données sur un équipement distant 3, selon un premier mode de réalisation préféré de l'invention. Le système 1 de téléchargement selon ce mode de réalisation comporte une passerelle 5 comprenant un module de gestion 11 adapté pour gérer ou créer une partition dynamique au sein de la passerelle. Par partition dynamique on entend une application logicielle de téléchargement qui s'efface une fois le téléchargement est terminé. Avantageusement, on utilise une passerelle du type CPIOM qui dispose déjà d'une capacité de partitionnement. Dans ce cas, parmi les partitions existantes, il suffit de réserver une partition qui sera dédiée à un hébergement temporaire de l'ensemble 9 de données et en particulier du moteur de téléchargement 9c permettant de gérer le téléchargement des données opérationnelles 9b vers l'équipement distant 3. D'un point de vue de la passerelle, cela se passe comme si l'on avait une partition dédiée pour cette fonction. Comme indiqué précédemment, l'ensemble 9 de données ou plus particulièrement, les données opérationnelles 9b possèdent un entête de téléchargement 9a. Cet entête respecte le même standard que les entêtes utilisés pour télécharger les autres partitions de la passerelle. Cela permet de ne pas prendre en compte une spécification d'interface dédié à cet équipement. La même spécification peut être utilisée pour toutes les partitions. Cela évite également de devoir définir une spécification d'interface du côté de la passerelle 5 et par conséquent, déjoue les problèmes de développement, d'intégration et les risques d'incompatibilité. Dès que la passerelle reconnait que c'est un chargement à destination de la partition, alors l'ensemble 9 de données est chargé dans cette partition. Le moteur protocolaire de téléchargement 9c créé par le fournisseur transfère alors les données opérationnelles 9b dans l'équipement distant 3. L'exemple de la Fig. 2A montre que le module de gestion 11 comporte un module d'acquisition 21, un routeur 23, un gestionnaire de partitions 25, un gestionnaire de rapport de progression 27 et une mémoire tampon 29. Le module d'acquisition 21 est adapté pour acquérir l'ensemble 9 de données transmis par l'ordinateur de chargement 7 à travers le premier média 13a. Le routeur 23 est adapté pour déterminer grâce au format et à l'entête de l'ensemble 9 de données si ces données doivent être téléchargées sur un équipement distant 3 ou rester sur la passerelle 5 (ou plateforme IMA). Le gestionnaire de partitions 25 est adapté pour créer une partition dynamique P4 et pour lancer l'exécution du moteur protocolaire 9c permettant le transfert des données opérationnelles 9b vers l'équipement distant 3 à travers un deuxième media de communication 13b. Par ailleurs, le gestionnaire de rapport 27 de progression est adapté pour rapporter à l'ordinateur de téléchargement 7, le statut d'avancement du téléchargement. Finalement, la mémoire tampon 29 est une zone mémoire d'échange entre la partition P4 et le gestionnaire de rapport de progression 27 qui indique à ce dernier l'état de progression. La Fig. 2B illustre de manière schématique le déroulement du téléchargement en relation avec les partitions comprises dans la passerelle. La passerelle 5 comporte un nombre N de partitions et en particulier, cet exemple montre qu'a l'instant initial tO, la passerelle 5 comporte trois partitions P1-P3 qui s'exécutent et une quatrième partition P4 vide dédiée au téléchargement. Lorsque le fabricant ou fournisseur de l'équipement distant commence à télécharger un ensemble 9 de données depuis l'ordinateur de téléchargement 7, ces données sont reçues par la passerelle 5. En effet, à l'instant t1, la passerelle 5 reçoit l'ensemble 9 de données depuis l'ordinateur de téléchargement 7 à travers le premier média de communication 13a (par exemple de type AFDX ou ARINC 629 dans le domaine aéronautique). On notera que le fournisseur de l'équipement distant est responsable non seulement des données opérationnelles à télécharger mais également du moteur protocolaire correspondant. Ainsi, à l'instant tl, l'ensemble 9 de données est récupéré par le module de gestion 11 qui lui est en charge de le mettre sur la partition dynamique P4. Plus particulièrement, le module d'acquisition 21 récupère l'ensemble 9 de données transmis par l'ordinateur de chargement 7 et l'envoie ensuite au routeur 23. Selon cet exemple, le routeur 23 transmet l'ensemble de données au gestionnaire de partitions 25 après avoir déterminé que les données sont destinées à être téléchargées. Le gestionnaire de partitions 25 crée alors une partition dynamique P4 et lance l'exécution du moteur de téléchargement. A l'instant t2, la récupération des données par la partition dynamique P4 depuis le gestionnaire de partitions 25 est terminée. Après la fin de récupération de l'ensemble 9 de données, la partition dynamique P4 exécute le moteur de téléchargement 9c permettant le transfert des données opérationnelles 9b vers l'équipement distant 3 à travers le deuxième media de communication 13b (par exemple A429, CAN, MIL 1553, etc.). La partition P4 est générée de la même façon que les partitions P1-P3, à la différence que le téléchargement des données opérationnelles dans l'équipement distant commence automatiquement après que le transfert des données dans la partition P4 ait été terminé. Finalement, à l'instant t3 la partition dynamique P4 est supprimée ou son contenu est effacé après que le téléchargement des données opérationnelles est terminé afin de libérer les ressources de la passerelles pour un autre téléchargement. Ainsi, une nouvelle partition P4 sera disponible pour télécharger un autre équipement d'un autre fournisseur ou du même fournisseur mais selon un autre protocole. On notera que la partition dynamique P4 permet de gérer le téléchargement sans séparer les données opérationnelles et le moteur de téléchargement. Ceci offre plus de souplesse à l'utilisateur. En plus des avantages énoncés précédemment, ce premier mode de réalisation permet d'avoir un protocole simplifié entre l'ordinateur de téléchargement 7 et la passerelle 5. L'équipementier ou le fournisseur est libre de gérer le téléchargement entre la passerelle 5 et l'équipement distant 3 bien évidemment sous réserve qu'il soit compatible avec la norme du bus (A429, CAN etc.) qu'il utilise. Cette solution peut aussi être utilisée sur des équipements existants avec peu de modifications en utilisant une partition libre. Les coûts de développement sur une passerelle ou une plateforme IMA s'en retrouveraient réduits. La Fig. 3 illustre de manière schématique un système de téléchargement déporté de données sur un équipement distant 3, selon un deuxième mode de réalisation préféré de l'invention. Le système 1 de téléchargement selon ce deuxième mode de réalisation comporte une passerelle 5 comprenant un module de gestion 11 et une mémoire 31 pour recevoir la charge (i.e., l'ensemble de données) qui s'adresse à l'équipement distant 3 et d'utiliser directement la mémoire vive de la passerelle 5 afin d'exécuter directement le moteur de téléchargement 9c permettant de gérer le téléchargement déporté. Ce mode de réalisation n'utilise pas de partition mais une mémoire 31 temporaire (dédiée ou non suivant les capacités de la passerelle) afin de gérer le téléchargement. En effet, dans le cas où la passerelle 5 ou la plateforme IMA dispose des ressources de traitement et de mémoire et ne dispose pas de capacité de partitionnement suffisantes, il est alors possible de se passer d'une partition dynamique et d'utiliser des zones de mémoire pour recevoir l'ensemble de données. La différence par rapport au premier mode de réalisation réside dans le fait qu'une mémoire remplace la partition et elle se partage en deux zones et le module de gestion 11 a pour but de gérer les données dans les zones mémoire. Selon ce mode de réalisation, la passerelle 5 comporte un module de gestion 11 et des première et seconde zones mémoires 31a, 31b. Le module de gestion 11 est adapté pour extraire les données opérationnelles 9b et le moteur protocolaire temporaire de téléchargement 9c et pour stocker les données opérationnelles et le moteur de téléchargement dans les première et deuxième zones mémoires 31a, 31b respectivement. En outre, la deuxième zone mémoire 31b est adaptée pour exécuter le moteur de téléchargement 9c permettant ainsi le téléchargement des données opérationnelles 9b dans l'équipement distant 3. Comme pour la solution proposée selon le premier mode de réalisation de la Fig. 2A, il est possible d'utiliser le moteur protocolaire de téléchargement standard. Dans ce cas, c'est le module de gestion 11 qui traite d'une façon différente la charge grâce aux informations contenues dans l'entête de la charge. Plus particulièrement, selon l'exemple de la Fig. 3, la passerelle 5 comporte un module de gestion 11 et les première et seconde zones mémoires 31a, 31b. Les zones mémoires peuvent être du type RAM ou des mémoires flash EEPROM ou autres. Le module de gestion 11 comporte un module d'acquisition 27, un routeur 23, un module d'extraction 24, un gestionnaire de mémoires 26 et un gestionnaire de rapport de progression 27. Comme dans le premier mode de réalisation de la Fig. 2A, le module d'acquisition 27 est adapté pour acquérir l'ensemble 9 de données transmis par l'ordinateur de chargement 7. En outre, le routeur 23 est adapté pour déterminer grâce au format et à l'entête de l'ensemble de données si ces donnes doivent être téléchargées sur un équipement distant 3 ou rester sur la passerelle 5. En revanche, le module d'extraction 24 est adapté pour extraire les données opérationnelles 9b et le moteur protocolaire temporaire de téléchargement 9c et de les transmettre au gestionnaire de mémoires 26. En outre, le gestionnaire de mémoires 26 envoie la partie « données opérationnelles» 9b vers la première zone mémoire 31a qui a pour but de stocker temporairement ces données. En outre, le gestionnaire de mémoires 26 envoie la partie « moteur protocolaire de téléchargement » 9c dans la deuxième zone mémoire 31b qui a pour but d'exécuter ce code afin de gérer le téléchargement des données opérationnelles. Ainsi, selon ce mode de réalisation, l'ensemble 9 de données (qui est sous la responsabilité de l'équipementier) est configuré en deux parties distinctes pouvant être interprétées par les zones mémoires 31a, 31b et exploitées par le module de gestion 11. Ici, l'équipementier est un peu plus contraint que dans la solution du premier mode de réalisation, mais cette contrainte permet de s'affranchir d'une partition. Le gestionnaire de rapport de progression 27 est comme précédemment adapté pour rapporter à l'ordinateur de téléchargement 7, le statut d'avancement du téléchargement. En outre, le contenu des première et seconde zones mémoires 31a, 31b est effacé une fois le téléchargement des données opérationnelles est terminé. La présente invention vise également un aéronef comportant une architecture avionique intégré et modulaire IMA ainsi qu'un système de téléchargement selon l'un quelconque des modes de réalisation relatifs aux Figs. 1-3. Par ailleurs, tout équipement distant (par exemple, calculateurs dans l'aéronautique, le ferroviaire, l'automobile, etc.) ayant besoin d'être mis à jour par l'intermédiaire de différents protocoles peut bénéficier des modes de réalisation de la présente invention. REVENDICATIONS1. Système de téléchargement déporté de données sur un équipement distant (3), caractérisé en ce qu'il comporte une passerelle (5) adaptée pour recevoir un ensemble (9) de données comprenant des données opérationnelles (9b) adressées audit équipement distant (3) ainsi qu'un moteur temporaire de téléchargement (9c), ladite passerelle étant en outre adaptée pour télécharger les données opérationnelles dans ledit équipement distant en lançant l'exécution dudit moteur de téléchargement. 2. Système selon la revendication 1, caractérisé en ce que la passerelle (5) comporte un module de gestion (11) adapté pour gérer une partition dynamique (P4) au sein de la passerelle, ladite partition dynamique étant adaptée pour héberger ledit ensemble (9) de données et pour exécuter le moteur de téléchargement (9c) permettant ainsi de télécharger lesdites données opérationnelles (9b) sur ledit équipement distant (3). 3. Système selon la revendication 2, caractérisé en ce que ledit module de gestion (11) est adapté pour supprimer ladite partition dynamique (P4) une fois le téléchargement desdites données opérationnelles terminé. 4. Système selon la revendication 1, caractérisé en ce que la passerelle (5) comporte un module de gestion (11) et des première et seconde zones mémoires (31a, 31b), ledit module de gestion étant adapté pour extraire les données opérationnelles (9b) et le moteur temporaire de téléchargement (9c) et pour stocker les données opérationnelles et le moteur de téléchargement dans lesdites première et deuxième zones mémoires (31a, 31b) respectivement, ladite deuxième zone mémoire (31b) étant adaptée pour exécuter le moteur de téléchargement permettant ainsi le téléchargement des données opérationnelles dans ledit équipement distant. 5. Système selon la revendication 4, caractérisé en ce que ledit module degestion (11) est adapté pour effacer le contenu desdites première et seconde zones mémoires (31a, 31b) une fois le téléchargement desdites données opérationnelles terminé. 6. Système selon l'une quelconque des revendications précédentes, caractérisé en ce que ladite passerelle (5) comporte un gestionnaire de rapport (27) adapté pour rapporter le statut d'avancement du téléchargement des données opérationnelles (9b) sur ledit équipement distant (3). 7. Système selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comporte un ordinateur de téléchargement (7) adapté à télécharger l'ensemble (9) de données vers la passerelle (5) à travers un premier media (13a) de communication et en ce que la passerelle est adaptée pour télécharger les données opérationnelles (9b) vers ledit équipement distant (3) à travers un second média (13b) de communication. 8. Système selon la revendication 7, caractérisé en ce que les premier et second medias (13a-13b) sont deux médias parmi les médias suivants : AFDX, ARINC 629, CAN, MIL 1553 et ARINC 429. 9. Aéronef comportant un système de téléchargement selon l'une quelconque des revendications précédentes. 10. Procédé de téléchargement déporté de données sur un équipement distant, caractérisé en ce qu'il comporte les étapes suivantes : -téléchargement d'un ensemble (9) de données depuis un ordinateur de téléchargement (7) vers une passerelle (5) à travers un premier média (13a) de communication, ledit ensemble de données comprenant des données opérationnelles (9b) adressées à un équipement distant (3) ainsi qu'un moteur temporaire de téléchargement (9c),-exécution dudit moteur de téléchargement (9c) par ladite passerelle (5), et -téléchargement desdites données opérationnelles (9b) depuis la passerelle (5) vers ledit équipement distant (3) à travers un deuxième média de communication (13b).