FR2927181A1 - Procede et dispositif de commande securises pour terminal de maintenance deporte. - Google Patents

Abstract

L'invention a pour objet un procédé et un dispositif de commande sécurisés pour contrôler un dispositif de maintenance embarqué, par exemple un dispositif de maintenance embarqué d'aéronef, à partir d'un terminal de maintenance déporté. Le dispositif de maintenance est relié au terminal de maintenance déporté par un réseau de communication. Après avoir reçu (600) au moins une donnée représentative d'au moins une commande associée à au moins une instruction, la donnée reçue est filtrée (615) pour déterminer la validité de la commande. Si la donnée reçue est valide, une instruction ou un ensemble d'instructions associé à la commande représentée par cette donnée est identifié (625) pour être exécuté. L'étape de filtrage est de préférence itérative et basée sur le protocole de transmission ainsi que sur le codage de la donnée.

Description

La présente invention concerne les opérations de maintenance et les tests fonctionnels effectués dans les aéronefs et plus particulièrement un procédé et un dispositif de commande sécurisés pour terminal de maintenance déporté permettant d'effectuer des tests fonctionnels depuis un poste distant en ligne d'assemblage ou lors de l'exploitation d'un aéronef.

Pour optimiser la fiabilité des aéronefs et augmenter leur rentabilité, des opérations de maintenance en ligne sont fréquemment mises en oeuvre entre les phases de vol. De façon générale, de telles opérations consistent par exemple, pour des opérateurs de maintenance, à analyser des données mémorisées durant le vol, à modifier certains paramètres de l'aéronef ou certaines données logicielles et/ou à lancer des applications logicielles de test. Les données analysées sont souvent issues de capteurs et mémorisées dans un dispositif central de diagnostic et de stockage accessible à travers une interface homme-machine de type MCDU (sigle de Multi-Control Display Unit en terminologie anglo- saxonne) ou OMT (sigle de Onboard Maintenance Terminal en terminologie anglo-saxonne). Cette interface, à travers laquelle peuvent être lancées des opérations interactives, permet d'analyser les données mémorisées, d'accéder aux paramètres de l'aéronef et plus généralement d'exécuter des fonctions de test et de maintenance. A titre d'illustration, les Airbus A320, A330 et A340 sont dotés de MCDU et l'Airbus A380 est doté d'OMT (Airbus, A320, A330, A340 et A380 sont des marques). L'accès aux systèmes de maintenance des aéronefs est généralement limité aux postes physiques fixes embarqués dans le cockpit. Ainsi, lorsque l'aéronef est au sol, un opérateur de maintenance peut monter dans l'aéronef pour accéder et analyser les données mémorisées, éventuellement modifier les paramètres de celui-ci et lancer des applications de test.

Afin d'assurer l'enchaînement des taches de manière optimisée, les dispositifs actuels exigent en général la présence permanente d'un opérateur pour vérifier que les opérations se sont bien déroulées. De la même façon, lors de l'assemblage des aéronefs, les équipes des chaînes finales d'assemblage s'appuient sur les outils interactifs de maintenance pour réaliser tout ou partie des tests fonctionnels de l'avion. Cependant, malgré les performances des postes de maintenance, il n'existe pas de moyens permettant d'automatiser certains tests. En effet, alors que certains postes de maintenance embarqués à bord des aéronefs peuvent être reliés à un réseau de communication permettant l'échange de données entre l'aéronef et des équipements distants, la connexion réseau ne permet pas de contrôler à distance les applications implémentées à bord de l'aéronef ni de transmettre des applications, pour des raisons de sécurité.

L'invention permet de résoudre au moins un des problèmes exposés précédemment. L'invention a ainsi pour objet un procédé pour exécuter au moins une instruction dans un dispositif de maintenance embarqué à partir d'un système distant relié audit dispositif de maintenance par un réseau de communication, ce procédé comprenant les étapes suivantes, - réception d'au moins une donnée représentative d'au moins une commande associée à ladite au moins une instruction ; - filtrage de ladite au moins une donnée reçue ; et, - si ladite commande filtrée est valide, identification de ladite au moins une instruction. Ainsi, un véhicule tel qu'un aéronef adapté à mettre en oeuvre le procédé selon l'invention dispose de moyens permettant l'accès aux outils de maintenance interactive, de manière distante, sans réduire son niveau de sécurité. De plus, un tel procédé offre un service optimisé aux opérateurs de chaînes finales d'assemblage pour la conduite de tests fonctionnels en leur offrant la possibilité de développer des moyens d'automatisation de tests.

De plus, les opérateurs pouvant connecter un terminal mobile et utiliser tout ou partie des automatismes de tests, le procédé selon l'invention offre la possibilité de réaliser des tests fonctionnels de non régression sur le flux de production jusqu'à la livraison.

Le procédé comprend en outre, avantageusement, une étape de vérification d'une signature de ladite au moins une donnée reçue permettant son authentification. Selon un mode de réalisation particulier, le procédé comprend en outre une étape préalable de mémorisation de ladite correspondance entre ladite au moins une donnée et ladite au moins une instruction. De façon avantageuse, ladite étape de filtrage est une étape de filtrage itératif basé sur au moins deux critères distincts pour optimiser les temps de traitement. Selon un mode de réalisation particulier, au moins l'un desdits au moins deux critères est lié au protocole de transmission de ladite au moins une donnée. De même, selon un mode de réalisation particulier, au moins l'un desdits au moins deux critères est lié au codage de ladite au moins une donnée représentative de ladite au moins une commande. De façon avantageuse, le procédé comprend en outre une étape de transmission d'au moins une information liée à l'exécution de ladite au moins une instruction permettant de transmettre un résultat en réponse à une commande. Pour permettre l'authentification de ladite au moins une information, le procédé comprend en outre, de préférence, une étape de signature de ladite au moins une information.

L'invention a également pour objet un dispositif comprenant des moyens adaptés à la mise en oeuvre de chacune des étapes du procédé décrit précédemment ainsi qu'un aéronef comprenant un tel dispositif. D'autres avantages, buts et caractéristiques de la présente invention ressortent de la description détaillée qui suit, faite à titre d'exemple non limitatif, 30 au regard des dessins annexés dans lesquels : - la figure 1 représente schématiquement un exemple d'environnement dans lequel la présente invention peut être mise en oeuvre ; - la figure 2, comprenant les figures 2a et 2b, illustre deux exemples d'une architecture logicielle pouvant être implémentée dans un aéronef pour mettre en oeuvre l'invention ; - la figure 3 représente partiellement une trame Ethernet utilisée pour transmettre une commande, sur laquelle un filtrage peut être effectué ; -la figure 4 représente une table ASCII et plus particulièrement des caractères pouvant être utilisés pour transmettre une commande à un aéronef sans compromettre sa sécurité ; - la figure 5 illustre un exemple de table de correspondance pouvant être utilisée par un module de conversion pour établir des liens de correspondance entre des commandes et des instructions ; - la figure 6 illustre certaines des étapes mises en oeuvre par un dispositif de maintenance d'un aéronef ou par un dispositif associé pour exécuter des instructions à partir de commandes reçues d'un poste distant ; et, - la figure 7 illustre un exemple de dispositif adapté à mettre en oeuvre l'invention ou une partie de l'invention. La figure 1 représente schématiquement un exemple d'environnement dans lequel la présente invention peut être mise en oeuvre. Il est ici illustré un aéronef 100 comprenant un dispositif 105 de maintenance, contenant par exemple des outils centralisés de diagnostic et de stockage, relié à une prise de connexion réseau 110 accessible, dans cet exemple, depuis l'extérieur de l'aéronef. La prise de connexion réseau 110-1 est ici reliée au réseau 115. Le dispositif 105 est par exemple relié à des capteurs (non représentés) de contrôle des moteurs et des actionneurs des trains d'atterrissage et des gouvernes. Un poste distant 120 de maintenance en ligne, par exemple placé dans un centre de maintenance 125, est relié au dispositif 105 par l'intermédiaire du réseau de communication 115 et de la prise 110-1.

Ainsi, lorsque l'aéronef 100 est au sol, durant son montage ou son exploitation, un opérateur de maintenance peut, à l'aide du poste distant 115, analyser les données de l'aéronef, modifier ses paramètres et/ou contrôler l'exécution des modules applicatifs de maintenance implémentés dans l'aéronef 100. Outre ses fonctions standard, le dispositif 105 comprend des moyens pour mettre en oeuvre l'invention qui repose avantageusement sur une architecture logicielle comprenant essentiellement les trois modules suivants qui peuvent être implémentés au sein d'une même application logicielle ou sous formes de modules indépendants, - un module de communication ; - un module de filtrage ; et, - un module de conversion ou de traduction. Alternativement, ces trois modules ou certains d'entre eux peuvent être implémentés dans un ou plusieurs autres dispositifs. La figure 2, comprenant les figures 2a et 2b, illustre deux exemples d'une architecture logicielle pouvant être implémentée dans un aéronef pour mettre en oeuvre l'invention. Selon le premier exemple illustré sur la figure 2a, l'architecture logicielle adaptée à mettre en oeuvre l'invention est implémentée dans le dispositif de maintenance. Comme illustré, le dispositif de maintenance 200 comprend ici les modules applicatifs de maintenance 205. Bien que tous ces modules soient ici représentés sous la forme d'un seul élément, il faut comprendre qu'il s'agit en général de modules distincts. Les modules applicatifs de maintenance sont reliés au réseau pour recevoir et/ou transmettre des

données. Le dispositif de maintenance 200 comprend en outre un module de communication 210, un module de filtrage 215 et un module de conversion 220. Le module de communication 210 est, de préférence, un module de communication sécurisée. Le module de communication 210 est relié au réseau, par l'intermédiaire d'une liaison standard, par exemple une liaison Ethernet, pour recevoir et/ou transmettre des données. Une telle liaison peut être filaire ou non. Le module de communication 210 est également relié au module de filtrage 215 qui est lui-même relié au module de conversion 220.

Selon le second exemple illustré sur la figure 2b, l'architecture logicielle adaptée à mettre en oeuvre l'invention est implémentée dans un dispositif distinct du dispositif de maintenance. Comme illustré, les modules applicatifs de maintenance 205 sont implémentés dans un dispositif de maintenance 225, distinct du dispositif 200' comprenant le module de communication 210', le module de filtrage 215' et le module de conversion 220'. Le module de communication 210 ou 210' a pour objet de recevoir les données transmises via le réseau auquel il est connecté et de transmettre des données sur ce même réseau.

De façon avantageuse, les données échangées sont signées. Il est rappelé ici que la signature permet d'authentifier la source d'une donnée ainsi que l'intégrité des données. Alternativement, seules les données reçues, les données transmises ou certains types de données sont signées.

De façon complémentaire, il est possible de chiffrer les données afin que celles-ci ne soient compréhensibles que par le destinataire. Selon un mode de réalisation particulier, le module de communication et le poste distant comprennent chacun des clés permettant d'ajouter une signature aux données transmises et de vérifier une telle signature. Il est ainsi possible d'authentifier la source des données et de vérifier que les données échangées sont correctes et intègres. Les mécanismes de signature mis en oeuvre sont de préférence des algorithmes standard basés sur des fonctions de hachage telles que les algorithmes MD5 ou SHA-1.

Le module de filtrage 215 ou 215' a pour objet de filtrer les données reçues du réseau afin de ne transmettre que les données correctement formatées au module de conversion, c'est-à-dire que seules les informations compréhensibles du module de conversion lui soient transmises. Le module de filtrage est, de préférence, basé sur le principe du tamis, c'est-à-dire sur un mécanisme itératif, selon lequel plusieurs niveaux de filtres sont utilisés pour optimiser les temps de traitement. Il est ainsi composé de plusieurs éléments permettant de filtrer de plus en plus finement les données reçues afin de ne laisser passer que les données correspondant aux commandes valides générées par des postes distants. Le module de filtrage nécessite qu'un format de commande soit définit afin de ne traiter qu'un certain type de trames réseau. Le format et le protocole de transport associé peuvent être définis sous forme de paramètres, accessibles au module de filtrage. Par exemple, de tels paramètres peuvent préciser que les commandes sont reçues sous forme de trames Ethernet, indiquer les sources autorisées à transmettre de telles commandes, donner une durée de vie maximale des trames au-delà de laquelle les trames ne sont pas prises en compte et indiquer les caractères pouvant être valablement utilisés pour coder une commande dans une trame. A titre d'illustration, le filtrage de trames Ethernet peut s'effectuer en trois étapes. La figure 3 représente partiellement une trame Ethernet 300 sur laquelle un filtrage peut être effectué selon ces trois étapes. Tout d'abord, chaque trame est analysée en vérifiant, par exemple, les adresses physiques source 305 et destination 310, en particulier les adresses MAC (acronyme de Media Access Control en terminologie anglo-saxonne), le type de protocole 315 et la signature 325 de la trame complète.

Les données 320 de la trames ne sont pas analysées dans cette première étape. Si les adresses physiques source 305 et destination 310, le type de protocole 315 et la signature 325 ne sont pas conformes aux paramètres du module de filtrage, la trame est rejetée.

Au contraire, si les adresses physiques source 305 et destination 310, le type de protocole 315 et la signature 325 sont conformes aux paramètres du module de filtrage, une deuxième étape de filtrage est mise en oeuvre. Il convient de remarquer ici que la première étape de filtrage peut porter sur d'autres données que celles citées ou, au contraire, sur moins de données.

La deuxième étape consiste par exemple à analyser l'entête des données 320. En particulier, cette deuxième étape de filtrage peut consister à vérifier la version IP (sigle de Internet Protocol en terminologie anglo-saxonne) 325, la longueur 330 de l'en-tête, le type de service 335, la longueur totale 340 des données, l'identification 345 utilisée pour reconstituer les fragments, la durée de vie 350, aussi appelée TTL (sigle de Time To Live en terminologie anglo-saxonne), le protocole 355 et les adresses source 360 et destination 365. A nouveau, si toutes ces informations ne sont pas conformes aux paramètres du module de filtrage, la trame est rejetée. Au contraire, si toutes ces informations sont conformes aux paramètres du module de filtrage, une troisième étape de filtrage est mise en oeuvre. Il convient de remarquer ici aussi que la seconde étape de filtrage peut porter sur d'autres données que celles citées ou, au contraire, sur moins de données.

La troisième étape consiste ici à analyser les caractères des données utiles 370 de la trame. Cette étape permet ainsi de vérifier que les caractères nécessaires à la construction de la commande ne peuvent pas être utilisés pour construire du code exécutable. De façon avantageuse, tous les caractères des données utiles doivent être choisis dans la table ASCII, dans les valeurs comprises entre 032 et 090, comme illustré sur la figure 4. Si un caractère des données utiles 370 n'appartient pas à la table ASCII, entre les valeurs 032 et 090, la trame est rejetée. Au contraire, si tous les caractères des données utiles 370 appartiennent à la table ASCII, entre les valeurs 032 et 090, la trame est transmise au module de conversion 220 ou 220'. Naturellement, la troisième étape de filtrage peut porter sur d'autres critères, en particulier des critères plus restrictifs. Le module de conversion 220 ou 220' a pour objet d'établir une interface entre les modules applicatifs 205 du dispositif de maintenance et le réseau. Ce module est développé, de préférence, de manière à ce que seules les commandes liées à des instructions correspondant à des types d'applications hébergées sur la plateforme de maintenance logicielle de l'aéronef aient une action. Ceci signifie que ce module connaît les instructions qui peuvent être exécutées par chaque application. En d'autres termes, une liste d'instructions ou de séquence d'instructions est, de préférence, préalablement mémorisée. Une telle liste définit un ensemble de configurations d'enchaînements possibles d'instructions. Cette liste peut également définir des combinaisons interdites. Cette configuration est construite de telle sorte que l'enchaînement des instructions d'une application est connu a priori. Ceci permet au module de conversion de vérifier que les commandes qu'il reçoit et l'enchaînement des instructions associées est conforme à ce que l'application est supposée exécuter. Cette vérification permet au module de conversion de rejeter tout enchaînement non attendu et assure ainsi que des opérations dangereuses ne peuvent pas être exécutées.

Dans un mode de réalisation particulier, le module de conversion utilise une table de correspondance entre des noms des commandes et les fonctions effectives, c'est-à-dire des séquences d'instructions, afin d'associer une ou plusieurs instructions aux noms de commandes reçus du poste distant. Il convient de noter ici que les instructions peuvent prendre plusieurs formes. Il s'agit par exemple de pointeurs vers des fonctions ou de commandes interfacées avec le système d'exploitation du dispositif de maintenance. Les instructions permettent notamment de simuler une action entrée par un utilisateur sur l'interface du dispositif de maintenance. La figure 5 illustre un exemple de table de correspondance 500 pouvant être utilisé par le module de conversion 220 ou 220'. La table de correspondance 500 comprend ici deux colonnes : une colonne 505 contenant les noms des commandes et une colonne 510 contenant la liste des instructions associées à chaque commande. La ligne 515 illustre un exemple d'une commande de test d'un dispositif de gestion de vol, appelé FMU (sigle de Flight Management Unit en terminologie anglo-saxonne). Le nom de la commande utilisable par un opérateur de maintenance à partir d'un poste distant est ici TEST : FMU.

Comme représenté, cette commande correspond à l'exécution de la séquence d'instructions comprenant les instructions Set_Param(a, b, c), AutoTest_FMU1 et AutoTest_FMU2. Après qu'une commande ait été analysée et déclarée conforme, le module de conversion transmet les instructions correspondantes à l'application concernée. L'application exécute les instructions et retourne, généralement, une réponse. Cette réponse est reçue par le module de conversion qui construit un message de réponse, de préférence signé. A titre d'illustration, en reprenant l'exemple illustré sur la figure 5, le mode opératoire pour l'exécution des instructions correspondant à la commande TEST : FMU est le suivant, - l'opérateur entre la commande TEST : FMU sur le poste distant ; - la commande TEST : FMU est signée puis transmise à l'aéronef à travers un réseau de communication ; -la signature de la commande reçue par l'aéronef est vérifiée ; - la commande est filtrée ; - la séquence d'instructions correspondant à la commande filtrée est identifiée, ici les instructions Set_Param(a, b, c), AutoTest_FMU1 et AutoTest_FMU2 ; - ces instructions sont transmises par une couche logicielle de type API (sigle de Application Programming Interface en terminologie anglo-saxonne) aux applications visées (comme si la commande avait été générée par des sélections de touches sur un poste fixe) ; - les applications visées exécutent les instructions conformément à la 25 commande et transmettent les résultats au module de conversion via la couche logicielle de type API ; et, - le module de conversion forme un message de réponse, par exemple en construisant une page d'écran ou une partie de page d'écran comprenant les résultats, signe le message de réponse pour attester de 30 l'origine et de l'intégrité de l'information fournie et transmet le message de réponse au poste distant via le réseau de communication.

Il est également possible, dans le cas de tests automatiques, d'utiliser une application logicielle implémentée sur le poste distant pour générer un enchaînement de commandes afin de créer un scénario de test complet.

La figure 6 illustre certaines des étapes mises en oeuvre par un dispositif de maintenance d'un aéronef ou par un dispositif associé pour exécuter des instructions à partir de noms de commandes reçus d'un poste distant. Après avoir reçu des données pouvant correspondre à un ou plusieurs noms de commandes (étape 600), la signature des données reçues est vérifiée (étape 605) selon un algorithme standard. La validité des données est ensuite testée (étape 610). Si les données sont valides, une étape de filtrage est mise en oeuvre (étape 615) et un nouveau test de validité est mis en oeuvre (étape 620). Si les données sont valides, les instructions correspondant aux données sont identifiées (étape 625). Les instructions identifiées sont ensuite exécutées par les applications associées (étape 630) et le résultat de l'exécution de ces instructions est mis en forme et signé (étape 635) avant d'être transmis au poste distant (étape 640).

Si les données ne sont pas valides, un message d'erreur est de préférence transmis au poste distant (étape 645). Un dispositif adapté à mettre en oeuvre l'invention ou une partie de l'invention est illustré sur la figure 7. Le dispositif 700 est par exemple un calculateur ou un micro-ordinateur.

Le dispositif 700 comporte ici un bus de communication 702 auquel sont reliés : - une unité centrale de traitement ou microprocesseur 703 (CPU, Central Processing Unit) ; - une mémoire morte 704 (ROM, acronyme de Read Only Memory 30 en terminologie anglo-saxonne) pouvant comporter les programmes "Prog", "Prog1" et "Prog2" ; - une mémoire vive ou mémoire cache 706 (RAM, acronyme de Random Access Memory en terminologie anglo-saxonne) comportant des registres adaptés à enregistrer des variables et paramètres créés et modifiés au cours de l'exécution des programmes précités ; et, - une interface de communication 718 adaptée à transmettre et à recevoir des données. Optionnellement, le dispositif 700 peut également disposer : - d'un écran 708 permettant de visualiser des données et/ou de servir d'interface graphique avec l'utilisateur qui pourra interagir avec les programmes selon l'invention, à l'aide d'un clavier et d'une souris 710 ou d'un autre dispositif de pointage tel qu'un crayon optique, un écran tactile ou une télécommande ; - d'un disque dur 712 pouvant comporter les programmes "Prog", "Prog1" et "Prog2" précités et des données traitées ou à traiter selon l'invention ; et, - d'un lecteur de cartes mémoires 714 adapté à recevoir une carte mémoire 716 et à y lire ou à y écrire des données traitées ou à traiter selon l'invention. Le bus de communication permet la communication et l'interopérabilité entre les différents éléments inclus dans le dispositif 700 ou reliés à lui. La représentation du bus n'est pas limitative et, notamment, l'unité centrale est susceptible de communiquer des instructions à tout élément du dispositif 700 directement ou par l'intermédiaire d'un autre élément du dispositif 700.

Le code exécutable de chaque programme permettant au dispositif programmable de mettre en oeuvre les processus selon l'invention, peut être stocké, par exemple, dans le disque dur 712 ou en mémoire morte 704. Selon une variante, la carte mémoire 716 peut contenir des données, notamment des clés de signature, ainsi que le code exécutable des programmes précités qui, une fois lu par le dispositif 700, sera stocké dans le disque dur 712.

Selon une autre variante, le code exécutable des programmes pourra être reçu, au moins partiellement, par l'intermédiaire de l'interface 718, pour être stocké de façon identique à celle décrite précédemment. De manière plus générale, le ou les programmes pourront être 5 chargés dans un des moyens de stockage du dispositif 700 avant d'être exécutés. L'unité centrale 703 va commander et diriger l'exécution des instructions ou portions de code logiciel du ou des programmes selon l'invention, instructions qui sont stockées dans le disque dur 712 ou dans la 10 mémoire morte 704 ou bien dans les autres éléments de stockage précités. Lors de la mise sous tension, le ou les programmes qui sont stockés dans une mémoire non volatile, par exemple le disque dur 712 ou la mémoire morte 704, sont transférés dans la mémoire vive 706 qui contient alors le code exécutable du ou des programmes selon l'invention, ainsi que des registres pour 15 mémoriser les variables et paramètres nécessaires à la mise en oeuvre de l'invention. L'appareil de communication comportant le dispositif selon l'invention peut également être un appareil programmé. Cet appareil contient alors le code du ou des programmes informatiques par exemple figé dans un circuit intégré à 20 application spécifique (ASIC). Il convient de remarquer que les modules applicatifs de maintenance, comme toutes les applications logicielles embarquées dans les aéronefs, sont développés suivant des normes aéronautiques strictes permettant de garantir un certain niveau de sécurité et de démontrer un niveau 25 de prédiction du comportement du système. A titre d'illustration, la plateforme d'hébergement des modules applicatifs de maintenance dont le niveau d'assurance qualité logiciel ciblé est DAL C, peut être développée de manière à ce que le niveau de maîtrise du code embarqué assure, en particulier, l'intégrité des informations générées (la 30 plateforme d'hébergement est, par exemple, développée suivant la norme aéronautique DO-178B).

Ainsi, la mise en oeuvre de l'invention dans un tel contexte permet de garantir un certain niveau d'intégrité des données et des résultats transmis au poste distant. Naturellement, pour satisfaire des besoins spécifiques, une personne 5 compétente dans le domaine de l'invention pourra appliquer des modifications dans la description précédente.

Claims (10)

REVENDICATIONS

1. Procédé pour exécuter au moins une instruction dans un dispositif de maintenance embarqué (200, 225) à partir d'un système distant (120) relié audit dispositif de maintenance par un réseau de communication (115), ce procédé étant caractérisé en ce qu'il comprend les étapes suivantes, -réception (600) d'au moins une donnée représentative d'au moins une commande associée à ladite au moins une instruction ; - filtrage (615) de ladite au moins une donnée reçue ; et, - si ladite commande filtrée est valide, identification (625) de ladite au moins une instruction.

2. Procédé selon la revendication 1 comprenant en outre une étape de vérification (605) d'une signature de ladite au moins une donnée reçue.

3. Procédé selon la revendication 1 ou la revendication 2 comprenant en outre une étape préalable de mémorisation de ladite correspondance entre ladite au moins une donnée et ladite au moins une instruction.

4. Procédé selon l'une quelconque des revendications précédentes selon lequel ladite étape de filtrage (615) est une étape de filtrage itératif basé sur au moins deux critères distincts.

5. Procédé selon la revendication 4 selon lequel au moins l'un desdits au moins deux critères est lié au protocole de transmission de ladite au 25 moins une donnée.

6. Procédé selon la revendication 4 ou la revendication 5 selon lequel au moins l'un desdits au moins deux critères est lié au codage de ladite au moins une donnée représentative de ladite au moins une commande.

7. Procédé selon l'une quelconque des revendications précédentes 30 comprenant en outre une étape de transmission (640) d'au moins une information liée à l'exécution de ladite au moins une instruction.

8. Procédé selon la revendication précédente comprenant en outre une étape de signature (635) de ladite au moins une information.

9. Dispositif (200, 200') comprenant des moyens adaptés à la mise en oeuvre de chacune des étapes du procédé selon l'une quelconque des 5 revendications précédente.

10. Aéronef (100) comprenant le dispositif selon la revendication précédente.