FR 2931329 A1 20091120 FR 0853178 A 20080516 Procédé de transmission de données entre au moins un écran d'affichage d'un poste de pilotage et au moins un ensemble client distant La présente invention concerne un procédé de transmission de données entre au moins un écran d'affichage d'un poste de pilotage d'aéronef et au moins un système client distant. L'invention concerne également un poste de pilotage d'un aéronef pour la mise en oeuvre de ce procédé. Elle est notamment adaptée à la transmission de données selon le protocole ARINC 661 entre le poste de pilotage d'un aéronef et un ensemble client distant en s'assurant de la prise en compte effective de ces données par l'ensemble distant. Le protocole ARINC 661 a été développé par l'industrie aéronautique pour définir une norme industrielle, d'une part, de l'interface graphique des écrans de visualisation du poste de pilotage (CDS ù "Cockpit display system") et d'autre part, du protocole de communication entre un système client et le poste de pilotage. Ce protocole de communication permet notamment d'envoyer des événements, tels que la sélection d'un bouton, du poste de pilotage au système client. Selon le protocole ARINC 661, le système d'exploitation du poste de pilotage doit comporter un noyau ("kernel") susceptible de générer la structure hiérarchisée de l'interface graphique à partir d'un fichier de définition (DF ù "définition file") durant la phase d'initialisation, ou phase de définition, du CDS. Ce noyau permet également l'émission d'événements. Le fichier de définition est un fichier binaire qui comporte ainsi la liste d'objets graphiques ("widgets") qui sera nécessaire au système client pour générer ses pages HMI devant être affichées sur le poste de pilotage. Un fichier de définition donné est associé à un seul système client (UA û "User application"), toutefois ce système client peut mettre en oeuvre plusieurs fichiers de définition. Les widgets sont stockés dans une bibliothèque gérée par le CDS. Les widgets peuvent être interactifs, c'est-à-dire qu'ils peuvent accepter et réagir à des actions de l'équipage. Ces commandes interactives sont très pratiques puisqu'elles permettent au pilote de l'aéronef de travailler, à titre purement illustratif, à partir d'un même support, à savoir son écran de visualisation, pour exécuter et suivre une tâche telle que la livraison de carburant en vol. Elles contribuent donc à la réduction de la charge de travail du pilote et de son stress. On peut observer, cependant, des disfonctionnements ponctuels de ces systèmes tels que la mise à jour spontanée d'une donnée par un système client sans action du pilote de l'aéronef. Par conséquent, il est impératif de renforcer la fiabilité des commandes interactives du poste de pilotage afin d'éviter toute commande intempestive ou corruption de commande par le système qui pourrait avoir des effets néfastes pour l'aéronef et ses passagers. Afin de sécuriser les échanges de données ARINC 661, la communication entre le CDS 1 et le système client distant 2 s'appuie sur un protocole de communication point à point tel que le protocole de transfert de données TFTP (Protocole simplifié de transfert de fichier) (Figure 1). La sécurisation de la communication repose alors sur la transmission d'acquittement 3 de réception des données 4 ARINC 661 par le système client 2. Or, il est connu de relier ce système client distant 2 à un calculateur chargé de contrôler ce système client distant afin de lui conférer le critère de sécurité intégrée ("Fail Safe") nécessaire au domaine aéronautique. Cependant, la mise en oeuvre d'une communication point à point entre le CDS 1 et l'ensemble client distant comprenant le système client distant 2 et son calculateur de contrôle ne permet pas de s'assurer de la réception des données ou notifications ARINC 661 par le calculateur de contrôle. Il s'ensuit que le niveau de fiabilité offert par un écran de visualisation à commandes interactives d'un poste de pilotage est insuffisant pour certains systèmes clients distants de l'aéronef comme le système FUEL dédié au ravitaillement en carburant en vol. La demande de brevet Français n°07 57064 au nom de la présente demandeuse décrit un système et un procédé de transmission de données entre au moins un écran d'affichage mettant en oeuvre une commande interactive et un système client. Ce système permet d'obtenir un niveau de fiabilité élevée par l'affichage à l'écran de visualisation d'une requête de confirmation des nouvelles données entrées par l'équipage de l'aéronef. Ce système implique, par conséquent, deux actions de la part du pilote de l'aéronef, à savoir l'entrée de la nouvelle donnée elle-même, et par conséquent la modification d'une donnée précédemment enregistrée, et la confirmation de cette modification. Avec ce procédé de transmission de données, on s'assure de la prise en compte des bonnes valeurs ou modifications par l'ensemble client distant. Bien que ce système donne des résultats très satisfaisants en termes de sécurisation des données ou commandes transmises du poste de pilotage vers un système client distant, il peut encore être amélioré. En effet, certaines fonctions offertes par le CDS d'un avion pour en faciliter le pilotage, telles que la mise à jour de la masse de l'avion pour un vol à basse altitude, le recalage de la position avion ou encore l'insertion d'un senseur TRN ("Terrain Reference Navigation"- Référentiel sol) dans le calcul de la position hybride de l'avion en vol à basse altitude, mettent en oeuvre des commandes interactives avec des conséquences sur la sécurité de cet avion telles que ces fonctions nécessitent une indépendance totale entre les voies d'acquisition de la donnée ou de la commande par le système client distant et les voies de confirmation de cette donnée ou de la commande par l'équipage. Or, le système décrit plus haut ne permet pas d'atteindre l'indépendance totale requise. Les éléments de commande du système d'affichage que constituent le clavier, la souris, l'écran d'affichage, la liaison permettant la transmission des données, ... , sont autant de points communs puisqu'ils permettent non seulement la mise à jour des paramètres mais également la confirmation de ces mises à jour. Les conséquences d'une éventuelle défaillance de ces points communs sont bien entendu alors critiques non seulement pour l'aéronef mais également pour l'équipage et les passagers. L'objectif de la présente invention est donc de proposer un procédé de transmission de données entre au moins un écran de visualisation et un système client distant, simple dans leur conception et dans leur mode opératoire, permettant non seulement de s'assurer de la prise en compte des messages issus des requêtes affichées à l'écran d'affichage par le ou les calculateurs de l'ensemble client distant afin d'obtenir un niveau de fiabilité plus élevé que ceux couramment atteints mais également de permettre une validation, ou confirmation, de ces messages par une ligne de cheminement de messages indépendante des moyens techniques (écran d'affichage, protocole ARINC 661, liaison de communication entre l'écran d'affichage et l'ensemble client distant,...) mis en oeuvre pour requérir la modification d'une donnée ou commande et transmettre cette modification à l'ensemble client distant. A cet effet, l'invention concerne un procédé de transmission de données entre au moins un écran d'affichage d'un poste de pilotage d'aéronef et au moins un ensemble client distant, cet ensemble client distant comprenant au moins un calculateur, dans lequel on fait apparaître sur cet écran d'affichage une première requête d'envoi de message dans un premier protocole de communication, le message étant transmis à l'ensemble client distant par l'intermédiaire d'une première liaison en utilisant un second protocole de communication. Selon l'invention, - on provoque la génération et l'affichage sur l'écran d'affichage d'une requête de confirmation du message de la première requête par l'intermédiaire d'une interface de communication destinée d'une part à recevoir et générer des messages dans le premier protocole de communication et d'autre part à recevoir et générer des messages aptes à être reçus par l'ensemble client distant, - on valide la requête de confirmation du message de la première requête en actionnant un organe de confirmation distinct dudit au moins un écran d'affichage, l'actionnement de cet organe de confirmation envoyant un message de confirmation par l'intermédiaire d'un ensemble routeur à l'ensemble distant en attente de cette confirmation, le message de confirmation, non généré dans le premier protocole de communication, étant apte à être reçu par cet ensemble client distant en attente de la confirmation, l'ensemble routeur comprenant au moins une deuxième liaison distincte de la première liaison. Cet organe de confirmation va permettre au pilote de finaliser la mise à jour de la donnée ou commande introduite par l'affichage de la première requête sur son écran du poste de pilotage. Cet organe confirmation est de préférence un organe à actionnement manuel destiné à générer un message de confirmation. De préférence, la requête de confirmation se présente sous la forme d'un moyen d'indication interactif tel qu'une fenêtre affichée à l'écran d'affichage proposant une zone sensible correspondant à l'� Annulation � du message de la première requête et une zone de texte demandant au pilote d'actionner ledit organe de confirmation placé sur le poste de pilotage pour valider le message (donnée ou commande) issu de la première requête. L'annulation n'ayant pas de conséquence critique sur la sécurité de l'aéronef, elle est effectuée classiquement par l'intermédiaire de l'écran d'affichage en utilisant le protocole de communication ARINC A661. Dans différents modes de réalisation particuliers de ce procédé de transmission de données, chacun ayant ses avantages particuliers et susceptibles de nombreuses combinaisons techniques possibles: - l'organe de confirmation est directement relié à l'ensemble distant par cette deuxième liaison, Dans ce mode de réalisation, un seul ensemble distant est relié à l'organe de confirmation qui peut être un bouton ou un commutateur, les deux étant à actionnement manuel. - cet ensemble routeur comprend une unité centrale de confirmation reliée d'une part à l'organe de confirmation par cette deuxième liaison et d'autre part à des ensembles distants par d'autres liaisons distinctes, on envoie un message de données brutes vers l'unité centrale en parallèle à l'envoi de la requête de confirmation du message de la première requête, le message de données brutes étant destiné à permettre à l'unité centrale d'identifier l'ensemble client distant en attente d'une confirmation du message de la première requête parmi les ensembles clients distants, La validation du message de la première requête étant réalisée par l'actionnement de l'organe de confirmation, l'organe de confirmation envoie un message via la deuxième liaison vers l'unité centrale de confirmation, après réception de ce message par l'unité centrale, cette unité centrale envoie le message de confirmation vers l'ensemble distant en attente de la confirmation. Cette unité centrale qui peut être un calculateur indépendant, est distincte des utilisateurs finaux de la confirmation, c'est-à-dire des ensembles de client distants. Par "données brutes", on entend des données non-ARINC 661 telles que des données booléennes, des nombres ou encore des chaînes de caractères. Ces données sont transmises sans protocole TFTP. - la validation du message de la première requête conduisant à l'envoi par l'organe de confirmation d'un message de confirmation par l'intermédiaire de la deuxième liaison vers l'unité centrale de confirmation, cette dernière vérifie après réception de ce message qu'une seule requête de confirmation du message de la première requête a été reçue par ledit au moins un écran d'affichage avant d'envoyer ce message de confirmation vers l'ensemble distant en attente de ladite confirmation, L'unité centrale de confirmation est en charge de router le message de confirmation au bon ensemble client distant. Cette unité centrale s'assure ainsi qu'une seule requête est effectuée simultanément. En effet, il ne routera le message de confirmation que s'il n'y a qu'une seule requête de confirmation ouverte. Dans un cas contraire, aucun message n'est envoyé au groupe d'ensembles client distants lors de l'actionnement par le pilote de l'organe de confirmation. Ce mécanisme prévient, en particulier, toute confirmation de requête intempestive simultanée d'une requête réellement faite par l'équipage. - on laisse afficher la requête de confirmation par ledit au moins un écran d'affichage pendant une durée de sollicitation de réponse r, après quoi sans réception du message de confirmation par l'ensemble client distant en attente d'une confirmation du message de ladite première requête, ce dernier envoie un message d'annulation de la requête de confirmation au moins à l'écran d'affichage, Lorsqu'aucune confirmation ou annulation par l'équipage n'est reçue, l'ensemble client distant va annuler automatiquement sa requête de confirmation après l'écoulement d'un certain laps de temps, par exemple 30 secondes. Les conséquences pour l'affichage sont équivalentes à une annulation manuelle par l'équipage. - le premier protocole de communication est le Protocole ARINC 661, - le deuxième protocole de communication est un protocole de transfert de données tel que le Protocole simplifié de transfert de fichier (TFTP), - ledit ensemble client distant comprend un système client distant relié à l'écran d'affichage par la première liaison et un calculateur pour contrôler ce système client distant en étant relié à ce dernier par une troisième liaison distincte des première et deuxième liaisons, et suite à la réception du message de la première requête par ce système client, le calculateur envoie un message de données brutes pour faire afficher une information liée au message de la première requête sur ledit écran d'affichage, ou sur un autre écran d'affichage par une liaison distincte des première et troisième liaisons, afin de permettre un contrôle de ce message. Bien entendu, ce message de données brutes envoyé par le calculateur nécessite sa réception intermédiaire par une interface de communication, laquelle est seule apte à générer un message dans le premier protocole de communication afin que l'écran d'affichage affiche cette information liée au message de la première requête. Cette étape est avantageusement réalisée en parallèle à l'envoi par le système client distant d'un message de données brutes à l'interface de communication pour faire afficher la requête de confirmation du message de la première requête. La commande ou la valeur saisie par l'équipage lors de la première requête peut ainsi être réaffichée sur le même écran d'affichage par l'intermédiaire du calculateur contrôlant le système client distant afin de permettre un contrôle par l'équipage. Alternativement, pour des raisons d'homogénéité des procédures pilotes de double vérification, la valeur est réaffichée sur un autre écran d'affichage. L'invention concerne également un poste de pilotage d'un aéronef pour la mise en oeuvre du procédé de transmission de données tel que décrit précédemment, ce poste de pilotage comprenant au moins un écran d'affichage apte à présenter un moyen d'indication interactif pour afficher une première requête d'envoi de message dans un premier protocole de communication et à transmettre ce message à un ensemble client distant par l'intermédiaire d'une première liaison en utilisant un second protocole de communication, cet ensemble client distant comprenant au moins un calculateur. Selon l'invention, le poste de pilotage comprend une interface de communication destinée d'une part à recevoir et générer des messages dans le premier protocole de communication et d'autre part à recevoir et générer des messages aptes à être reçus par l'ensemble client distant. De plus, l'ensemble client distant étant en attente d'une confirmation du message de la première requête, le poste de pilotage comporte un organe de confirmation à actionnement manuel destiné à générer un message de confirmation et un ensemble routeur pour transmettre le message de confirmation à cet ensemble client distant en attente d'une confirmation de message, ce message de confirmation, non généré dans le premier protocole, étant apte à être reçu par l'ensemble distant, l'ensemble routeur comprenant au moins une deuxième liaison distincte de la première liaison. A titre purement illustratif, ce message de confirmation apte à être reçu par l'ensemble distant en attente d'une confirmation du message de la première requête est un message de données brutes. Le moyen d'indication interactif de la première requête peut être une fenêtre affichée à l'écran d'affichage et proposant la modification d'une valeur par l'intermédiaire d'une zone combinée, c'est-à-dire un élément d'une boîte de dialogue regroupant une zone de texte et une zone de liste ouverte, ou d'un champ permettant la saisie d'une valeur. Dans différents modes de réalisation particuliers de ce poste de pilotage, chacun ayant ses avantages particuliers et susceptibles de nombreuses combinaisons techniques possibles: - l'organe de confirmation est directement relié audit ensemble distant par ladite deuxième liaison, - l'ensemble routeur comprend une unité centrale de confirmation distincte des ensembles client distants, cette unité centrale étant reliée d'une part à l'organe de confirmation par la deuxième liaison et d'autre part aux ensembles distants par d'autres liaisons distinctes, - la liaison entre l'écran d'affichage et l'ensemble client distant étant une liaison point à point, l'interface de communication est placée dans l'écran d'affichage, - l'écran d'affichage étant relié par une liaison point à multipoints à l'ensemble client distant, l'interface de communication est placée dans le calculateur, cette interface de communication ayant une adresse de destination et étant destinée à recevoir le message dans le premier protocole de communication, - le premier protocole de communication est le Protocole ARINC 661, - le poste de pilotage comporte un dispositif de sélection et de commande pour sélectionner dans un ensemble de données présentées à l'écran d'affichage sous forme d'une requête une donnée particulière, A titre purement illustratif, ce dispositif de sélection et de commande peut 25 être choisi dans le groupe comprenant une boule de commande, un manche à balai, un bloc à effleurement. - le poste de pilotage comporte un clavier permettant d'entrer dans un champ d'une fenêtre affichée sur l'écran d'affichage une donnée particulière. 30 L'invention concerne encore un aéronef équipé d'un poste de pilotage tel que décrit précédemment. De préférence, cet aéronef comprenant des ensembles client distants reliés au poste de pilotage, ces ensembles client distants sont choisis dans le groupe comprenant un triplet de calculateurs identiques, 35 ladite unité centrale de confirmation étant relié à chacun de ces calculateurs ; un système client distant et un calculateur pour contrôler ledit système client distant, ledit calculateur étant relié audit système client distant par une troisième liaison distincte desdites première et deuxième liaisons, et une combinaison de ces éléments. Dans le cas du calculateur contrôlant le système client distant, l'architecture est de type COM-MON, c'est-à-dire que l'ensemble client distant comporte deux parties, COM et MON, fonctionnellement identiques mais réalisées différemment. Un accord entre les sorties de ces deux parties COM et MON est alors nécessaire pour émettre les données de sortie vers l'extérieur. Alternativement, cette architecture de type COM-MON peut être avantageusement remplacée dans l'ensemble client distant par un triplet de calculateurs identiques. Ces calculateurs sont à titre purement illustratif de type système de référence inertielle GPS (GADIRU). Les conséquences ne sont alors critiques que si 2 calculateurs sur les 3 reçoivent une valeur erronée ou une confirmation intempestive. L'invention sera décrite plus en détail en référence aux dessins annexés dans lesquels: - la figure 1 montre un exemple de transmission de données entre un écran de visualisation et un système client de l'art antérieur; - la figure 2 est une représentation schématique d'une étape de transmission de données modifiées selon un mode de réalisation préféré du procédé de l'invention; - la figure 3 montre schématiquement l'étape ultérieure de celle de la Figure 2, de transmission par l'interface de communication de la confirmation des données modifiées au système client distant et à l'unité de contrôle; Les Figures 2 et 3 montrent le système et le procédé de transmission de données selon un mode de réalisation préféré de l'invention. Ce système comporte deux écrans d'affichage 5, 6 possédant chacun un noyau 7. A titre purement illustratif, ces écrans d'affichage intérieurs 5, 6 sont des écrans LCD couleurs. Les affichages réalisés par ces écrans d'affichage 5,6, notamment lorsqu'ils sont appliqués à un écran de pilotage tête basse, utilisent des signes élémentaires tels que des caractères numériques, des caractères alphanumériques, des segments rectilignes, ... et éventuellement des couleurs distinguables. Les écrans d'affichage 5, 6 sont placés sur le poste de pilotage en faisant face à un pylône placé entre les sièges des pilotes (non représenté). Ce pylône comporte un ensemble de commandes. Ces commandes comportent notamment un clavier AZERTY et une boule de commande pour chaque pilote. Chaque boule de commande comporte des boutons spéciaux tels que � cliquer �, � Menu �, � Plus/Moins �, ... Les écrans d'affichage 5, 6 permettent au pilote de dialoguer avec l'ensemble client distant comprenant un système client distant 8 et un calculateur pour contrôler ce système client distant, en vue d'une révision d'une tâche ou de l'exécution d'une tâche particulière. Les claviers, boules de commande et boutons spéciaux participent également à ce dialogue entre le pilote et l'ensemble client distant en lui permettant soit d'introduire des données dans un champ texte, soit de sélectionner une valeur dans une zone combinée affichée à l'écran 5, 6. Ils peuvent permettre également de refuser une confirmation de valeur ou de commande. Dans ce dernier cas, les boules de commande peuvent permettre de déplacer à l'écran un curseur généré à l'écran d'affichage pour sélectionner une zone sensible d'une boîte de dialogue affichée à l'écran et symbolisant une � Annulation � et de cliquer cette zone sensible. Le noyau 7 de l'écran d'affichage 5 permet, par exemple, d'envoyer des événements tels que la sélection d'une valeur ou d'une commande, de cet écran d'affichage au système client distant 8 ayant une adresse de destination. L'écran d'affichage 5 et le système client distant 8 sont reliés par une liaison 9 qui est ici une liaison point à point. Le protocole de communication entre l'écran d'affichage 5 et le système client distant 8 est le protocole de communication ARINC 661. Le système client distant 8 est contrôlé de manière usuelle par un calculateur indépendant 10. Une interface de communication 11 est placée dans l'écran d'affichage 5 et est apte d'une part à recevoir et générer des messages dans le protocole ARINC 661 et d'autre part à recevoir et émettre des messages de données brutes vers le système client distant 8 et le calculateur 10 pour s'assurer de la prise en compte des événements par ce dernier. Selon un mode de réalisation préféré du procédé de l'invention, on assure la confirmation d'une commande ou d'une valeur modifiée à l'ensemble client distant 8, 10 par la réalisation des étapes décrites ci-dessous. On fait tout d'abord apparaître à l'écran d'affichage 5 une première requête d'envoi de message dans le protocole de communication ARINC 661. Cette requête peut se présenter, par exemple, sous la forme de l'affichage d'un champ texte à compléter, le système client distant 8 demandant l'entrée d'une valeur modifiée. Une fois la valeur saisie par le pilote, le noyau 7 adresse un message dans le protocole ARINC 661 au système client distant 8 ayant une adresse de destination, en utilisant un protocole de transfert de données tel que le Protocole simplifié de transfert de fichier (TFTP). Ce protocole TFTP assure également la réception de codes erreur dans l'hypothèse où le système client distant 8 ne serait pas susceptible d'accepter ce transfert. A réception de ce message comportant la valeur modifiée entrée par le pilote, le système client distant 8 envoie un message de données brutes à l'interface de communication 11. Ce message vise à faire confirmer la valeur modifiée par l'intermédiaire d'un organe de confirmation 12 qui est situé sur le poste de pilotage en étant rendu accessible au pilote pour un actionnement manuel. Cet organe de confirmation 12 est relié par une liaison 13 telle qu'une liaison discrète, directement à cet ensemble client distant 8, 10 en attente d'une confirmation du message issu de la première requête. Le message de données brutes constitue ainsi une requête écrite du système client distant 8 demandant à l'interface de communication 11 l'ouverture d'une fenêtre de confirmation de la valeur modifiée. Le message de données brutes est par exemple encapsulé dans un message AFDX pour son transfert. Alternativement, un autre support de communication aéronautique peut être mis en oeuvre pour transmettre ce message de données brutes, par exemple un bus CAN, un lien A429, une liaison série ou autre. A réception de cette requête, l'interface de communication 11 envoie un message dans le protocole de communication ARINC 661 au noyau 7 pour obtenir l'affichage d'une deuxième requête d'envoi de message. Cette deuxième requête apparaît à l'écran d'affichage 5 sous la forme d'une fenêtre de confirmation. Cette fenêtre peut comprendre une zone de texte invitant le pilote à confirmer le message de la première requête en actionnant l'organe de confirmation 12 ou à annuler ce message par l'appui sur une zone sensible symbolisant l' "Annulation" de ce message. En parallèle, le calculateur 10 envoie un message de données brutes à l'autre écran d'affichage 6 pour faire afficher une information liée à la première requête, ici la valeur modifiée, afin de permettre un contrôle du message de la première requête. Ce message de données brutes peut également être encapsulé dans un message AFDX. L'équipage peut alors vérifier que la valeur entrée lors de la 15 première requête a correctement été prise en compte par l'ensemble client distant 8, 10. Si le pilote confirme la modification de la valeur en actionnant l'organe de confirmation 12, cette action résulte en l'envoi par ce dernier d'un message de confirmation tel qu'un message de données brutes via la 20 liaison discrète 13. On s'assure ainsi par un moyen de communication complètement indépendant de la prise en compte de la modification de la valeur ou de la commande par l'ensemble client distant 8, 10. Lorsque la valeur entrée par la première requête est erronée, le 25 pilote peut annuler cette modification de valeur ou de commande en appuyant sur zone sensible de l'écran d'affichage symbolisant l' "Annulation". Le noyau 7 transmet alors l'événement, c'est-à-dire l'annulation de la valeur modifiée, par un message dans le protocole ARINC 661 à 30 l'interface de communication 11 (Figure 3). La réception de ce message par l'interface de communication 11, provoque l'envoi par cette dernière d'un message de données brutes à la fois au système client distant 8 et au calculateur 10 afin d'informer ces derniers de l'annulation de la première requête. Selon un mode de réalisation préféré du procédé de l'invention, la fermeture de la fenêtre de confirmation est pilotée par le système client distant 8. Le système client distant demande la fermeture de la fenêtre de confirmation en envoyant un message de données brutes à l'interface de communication 11. A la réception de cette requête, l'interface de communication 11 envoie un message dans le protocole de communication ARINC 661 au noyau 7 afin d'obtenir la fermeture de cette fenêtre de confirmation. REVENDICATIONS1. Procédé de transmission de données entre au moins un écran d'affichage d'un poste de pilotage d'aéronef et au moins un ensemble client distant (8, 10), ledit ensemble client distant (8, 10) comprenant au moins un calculateur (10), dans lequel on fait apparaître sur ledit écran d'affichage (5, 6) une première requête d'envoi de message dans un premier protocole de communication, ledit message étant transmis audit ensemble client distant (8, 10) par l'intermédiaire d'une première liaison (9) en utilisant un second protocole de communication, caractérisé en ce que - on provoque la génération et l'affichage sur ledit écran d'affichage (5, 6) d'une requête de confirmation du message de ladite première requête par l'intermédiaire d'une interface de communication (11) destinée d'une part à recevoir et générer des messages dans ledit premier protocole de communication et d'autre part à recevoir et générer des messages aptes à être reçus par l'ensemble client distant (8, 10) comprenant au moins un calculateur (10), - on valide la requête de confirmation dudit message de la première requête en actionnant un organe de confirmation (12) distinct dudit au moins un écran d'affichage (5, 6), l'actionnement dudit organe de confirmation (12) envoyant un message de confirmation par l'intermédiaire d'un ensemble routeur à l'ensemble distant (8, 10) en attente de ladite confirmation, ledit message de confirmation, non généré dans ledit premier protocole, étant apte à être reçu par ledit ensemble client distant (8, 10) en attente de ladite confirmation, ledit ensemble routeur comprenant au moins une deuxième liaison (13) distincte de ladite première liaison (9). 2. Procédé selon la revendication 1, caractérisé en ce que ledit organe de confirmation (12) est directement relié audit ensemble distant (8, 10) par ladite deuxième liaison (13). 3. Procédé selon la revendication 1, caractérisé en ce que ledit ensemble routeur comprenant une unité centrale de confirmation reliée d'une part audit organe de confirmation (12) par ladite deuxième liaison (13) et d'autre part auxdits ensembles distants (8, 10) par d'autres liaisons distinctes, on envoie un message de données brutes vers ladite unité centrale en parallèle à l'envoi de la requête de confirmation du message deladite première requête, ledit message de données brutes étant destiné à permettre à ladite unité centrale d'identifier ledit ensemble client distant (8, 10) en attente d'une confirmation du message de ladite première requête parmi lesdits ensembles clients distants. 4. Procédé de transmission selon la revendication 3, caractérisé en ce que la validation du message de ladite première requête conduisant à l'envoi par ledit organe de confirmation (12) d'un message de confirmation par l'intermédiaire de ladite deuxième liaison (13) vers ladite unité centrale de confirmation, ladite unité centrale de confirmation vérifie après réception dudit message qu'une seule requête de confirmation du message de ladite première requête a été reçue par ledit au moins un écran d'affichage (5, 6) avant d'envoyer ledit message de confirmation vers ledit ensemble distant (8, 10) en attente de ladite confirmation. 5. Procédé de transmission selon l'une quelconque des revendications 1 à 4, caractérisé en ce que ledit ensemble client distant (8, 10) comprend un système client distant relié audit écran d'affichage (5, 6) par ladite première liaison (9) et un calculateur pour contrôler ledit système client distant en étant relié à ce dernier par une troisième liaison distincte desdites première et deuxième liaisons, et en ce que suite à la réception du message de la première requête par ledit système client, ledit calculateur envoie un message de données brutes pour faire afficher une information liée au message de ladite première requête sur ledit écran d'affichage (5), ou sur un autre écran d'affichage (6) par une liaison distincte desdites première et troisième liaisons, afin de permettre un contrôle dudit message. 6. Procédé de transmission selon l'une quelconque des revendications 1 à 5, caractérisé en ce qu'on laisse afficher ladite requête de confirmation par ledit au moins un écran d'affichage (5, 6) pendant une durée de sollicitation de réponse r, après quoi sans réception dudit message de confirmation par ledit ensemble distant (8, 10) en attente d'une confirmation du message de ladite première requête, ledit ensemble (8, 10) envoie un message d'annulation de ladite requête de confirmation au moins audit écran d'affichage (5, 6). 7. Poste de pilotage d'un aéronef pour la mise en oeuvre du procédé de transmission de données selon l'une quelconque des revendications 1 à6, ledit poste de pilotage comprenant au moins un écran d'affichage (5, 6) apte à présenter un moyen d'indication interactif pour afficher une première requête d'envoi de message dans un premier protocole de communication et à transmettre ledit message à un ensemble client distant (8, 10) par l'intermédiaire d'une première liaison (9) en utilisant un second protocole de communication, ledit ensemble client distant (8, 10) comprenant au moins un calculateur, caractérisé en ce que ledit poste de pilotage comprend une interface de communication (11) destinée d'une part à recevoir et générer des messages dans le premier protocole de communication et d'autre part à recevoir et générer des messages aptes à être reçus par l'ensemble client distant (8, 10), et en ce que - ledit ensemble client distant (8, 10) étant en attente d'une confirmation du message de ladite première requête, ledit poste de pilotage comporte un organe de confirmation (12) à actionnement manuel destiné à générer un message de confirmation et un ensemble routeur pour transmettre ledit message de confirmation audit ensemble client distant (8, 10) en attente d'une confirmation de message, ledit message de confirmation, non généré dans ledit premier protocole, étant apte à être reçu par ledit ensemble distant (8, 10), ledit ensemble routeur comprenant au moins une deuxième liaison distincte de ladite première liaison (9). 8. Poste selon la revendication 7, caractérisé en ce que ledit ensemble routeur comprend une unité centrale de confirmation distincte desdits ensembles client distants, ladite unité centrale étant reliée d'une part audit organe de confirmation (12) par ladite deuxième liaison et d'autre part auxdits ensembles distants par d'autres liaisons distinctes. 9. Aéronef équipé d'un poste de pilotage selon la revendication 7 ou 8. 10. Aéronef selon la revendication 9, ledit aéronef comprenant des ensembles clients distants reliés audit poste de pilotage, caractérisé en ce que lesdits ensembles client distants (8, 10) sont choisis dans le groupe comprenant un triplet de calculateurs identiques, ladite unité centrale de confirmation étant relié à chacun de ces calculateurs ; un système client distant (8) et un calculateur (10) pour contrôler ledit système client distant, ledit calculateur (10) étant relié audit système client distant (8) par unetroisième liaison distincte desdites première et deuxième liaisons, et une combinaison de ces éléments.