FR 2920055 A1 20090220 FR 0757064 A 20070814 Système et procédé de transmission de données entre au moins un écran d'affichage et un système client La présente invention concerne un système et un procédé de transmission de données entre au moins un écran d'affichage et un système client distant. 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 système client. 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 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. Néanmoins, le niveau d'intégrité sur une commande erronée ou intempestive d'un système client ne dépasse pas le niveau de criticité "MAJEUR" sur la classification de sûreté établie par le constructeur AIRBUS. Cette classification qui définit des règles de correspondance entre l'occurrence d'un événement et la criticité des pannes générées suite à cet événement, comporte quatre niveaux de criticité ("MINEUR", "MAJEUR", "HASARDEUX" et "CATASTROPHIQUE"). Le niveau de criticité d'une panne va définir le niveau de redondance nécessaire sur les architectures pour s'assurer du niveau de fiabilité requis des différents équipements et des fonctions associées. Au niveau de criticité "MAJEUR", une panne ayant des effets majeurs sur l'aéronef et ses passagers ne doit pas survenir avant au moins 100 000 heures de vol (Occurrence : 10-5). Or, certains systèmes clients d'aéronef comme le système FUEL dédié au ravitaillement en carburant en vol sont amenés à utiliser des commandes interactives nécessitant des taux de fiabilité importants (niveau de criticité "HASARDEUX"). Ce niveau de fiabilité peut être atteint, par exemple, par l'affichage à l'écran de visualisation d'une commande de confirmation d'une modification de donnée. Ce système implique, par conséquent, deux actions de la part du pilote de l'aéronef, à savoir la modification de la donnée elle-même et la confirmation de cette modification. L'écran de visualisation envoie deux événements ARINC 661 successifs au système client afin que ce dernier prenne en compte l'ordre du pilote. Avec ce niveau de criticité, une panne ayant des effets critiques sur l'aéronef et ses passagers est seulement susceptible de survenir toutes les 10 millions d'heures de vol (Occurrence : 10-7). Or, pour des raisons de sécurité, un système client à bord d'un aéronef est contrôlé par une unité de contrôle de type calculateur, afin de contrôler les échanges de données ARINC 661 entre ce système client et l'écran de visualisation. L'utilisation d'une communication point à point entre l'écran de visualisation et le système client ne permet toutefois pas de garantir la réception des notifications ARINC 661 par cette unité de contrôle. En conséquence, le niveau de fiabilité requis n'est pas atteint, ce qui peut mettre en danger l'aéronef et ses passagers. L'objectif de la présente invention est donc de proposer une méthode et un système 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 de s'assurer de la prise en compte des messages issus des requêtes affichées à l'écran d'affichage par l'unité de contrôle afin d'obtenir un niveau de fiabilité plus élevé que ceux couramment atteints. A cet effet, l'invention concerne un système de transmission de données entre au moins un écran d'affichage et un système client distant, ce système client distant étant relié à l'écran d'affichage par une liaison, une unité de contrôle contrôlant le système client distant, l'écran d'affichage étant apte à présenter au moins un moyen d'indication interactif qui indique une requête d'envoi de message dans un premier protocole de communication. Selon l'invention, le système comporte 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'unité de contrôle. Le moyen d'indication interactif 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 système de transmission de données, chacun ayant ses avantages particuliers et susceptibles de nombreuses combinaisons techniques possibles: - la liaison entre l'écran d'affichage et le système client distant étant une liaison point à point, l'interface de communication est placée dans l'écran d'affichage, - l'interface de communication est apte à recevoir et émettre des messages de données brutes vers le système client distant et/ou l'unité de contrôle, 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. - l'écran d'affichage étant relié par une liaison point à multipoints au système client distant et à l'unité de contrôle, l'interface de communication est placée dans l'unité de contrôle, 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 système 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 être choisi dans le groupe comprenant une boule de commande, un manche à balai, un bloc à effleurement. - le système 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. L'invention concerne également un procédé de transmission de données entre au moins un écran d'affichage et un système client distant 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 au système client distant dans un second protocole de communication, une unité de contrôle contrôlant le système client distant. Selon l'invention, on provoque la génération et l'affichage sur ledit écran d'affichage d'une requête de confirmation 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'unité de contrôle. 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 deux zones sensibles correspondant respectivement à la Confirmation ou l' Annulation de la première requête. L'invention concerne encore un procédé de transmission de données entre au moins un écran d'affichage et un système client distant 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 au système client distant dans un second protocole de communication, une unité de contrôle contrôlant le système client distant. Selon l'invention, le procédé comporte les étapes suivantes : - envoyer par le système client distant un message de données brutes à une interface de communication placée dans ledit écran d'affichage, cette interface de communication étant apte à recevoir et générer des messages dans le premier protocole de communication, - suite à la réception de ce message de données brutes par l'interface de communication, provoquer la génération d'une deuxième requête d'envoi de message dans le premier protocole de communication pour confirmer ou annuler la première requête, ladite requête étant affichée sur ledit écran d'affichage, - suite à la réception du message dans le premier protocole de communication par l'interface de communication, provoquer l'envoi d'un message de données brutes à la fois au système client distant et à l'unité de contrôle afin d'informer ces derniers de la confirmation ou de l'annulation de la première requête. De préférence, suite à la réception du message de la première requête par le système client, l'unité de contrôle envoie un message de données brutes à l'écran d'affichage ou à un autre écran d'affichage pour faire afficher une information liée à la première requête afin de permettre un contrôle 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. 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 de l'unité de contrôle 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 enfin un aéronef comprenant au moins un système client distant et un poste de pilotage comportant au moins un écran d'affichage, une unité de contrôle contrôlant le système client distant. Selon l'invention, l'aéronef comporte un système de transmission de données entre ledit au moins un écran d'affichage et le système client distant tel que décrit précédemment. 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 le système client distant 8 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 le système client distant 8 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 soit d'acquitter ou 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 Confirmation ou au contraire 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 une notification de confirmation, 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 une unité de contrôle 10 telle qu'un calculateur indépendant. 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 9 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 au système distant 8 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 de cette interface de communication 11 qui est locale au CDS. 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. 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 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 première requête a correctement été prise en compte par le système client distant 8 et va confirmer son exécution. Le noyau 7 transmet l'événement, c'est-à-dire la confirmation ou l'annulation de la valeur modifiée, par un message dans le protocole ARINC 661 à 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 la confirmation ou 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. REVENDICATIONS 1. Système de transmission de données entre au moins un écran d'affichage (5, 6) et un système client distant (8), ledit système client distant (8) étant relié audit écran d'affichage (5, 6) par une liaison, une unité de contrôle (10) contrôlant ledit système client distant (8), ledit écran d'affichage (5, 6) étant apte à présenter au moins un moyen d'indication interactif qui indique une requête d'envoi de message dans un premier protocole de communication, caractérisé en ce que le système comporte 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 ladite unité de contrôle (10). 2. Système selon la revendication 1, caractérisé en ce que ladite liaison entre ledit écran d'affichage (5, 6) et ledit système client distant (8) étant une liaison point à point (9), ladite interface de communication (11) est placée dans ledit écran d'affichage (5, 6). 3. Système selon la revendication 2, caractérisé en ce que ladite interface de communication (11) est apte à recevoir et émettre des messages de données brutes vers ledit système client distant (8) et/ou ladite unité de contrôle (10). 4. Système selon la revendication 1, caractérisé en ce que ledit écran d'affichage (5, 6) étant relié par une liaison point à multipoints audit système client distant (8) et à ladite unité de contrôle (10), ladite interface de communication (11) est placée dans ladite unité de contrôle (10), ladite interface de communication (11) ayant une adresse de destination et étant destinée à recevoir ledit message dans ledit premier protocole de communication. 5. Procédé de transmission de données entre au moins un écran d'affichage (5, 6) et un système client distant (8) 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 système client distant (8) dans un second protocole de communication, une unité de contrôle (10) contrôlant ledit système client distant (8), caractérisé en ce qu'on provoque la génération et l'affichagesur ledit écran d'affichage (5, 6) d'une requête de confirmation de la 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 ladite unité de contrôle (10). 6. Procédé selon la revendication 5, caractérisé en ce qu'on réalise pour cela les étapes suivantes : - envoyer par ledit système client distant (8) un message de données brutes à une interface de communication (11) placée dans ledit écran d'affichage (5, 6), ladite interface de communication (11) étant apte à recevoir et générer des messages dans ledit premier protocole de communication, - suite à la réception dudit message de données brutes par ladite interface de communication (11), provoquer la génération d'une deuxième requête d'envoi de message dans ledit premier protocole de communication pour confirmer ou annuler ladite première requête, ladite requête étant affichée sur ledit écran d'affichage (5, 6), - suite à la réception du message dans ledit premier protocole de communication par ladite interface de communication (11), provoquer l'envoi d'un message de données brutes à la fois audit système client distant (8) et à l'unité de contrôle (10) afin d'informer ces derniers de la confirmation ou de l'annulation de la première requête. 7. Procédé selon la revendication 6, caractérisé en ce que suite à la réception du message de ladite première requête par ledit système client, ladite unité de contrôle (10) envoie un message de données brutes audit écran d'affichage (5, 6) ou à un autre écran d'affichage (5, 6) pour faire afficher une information liée à ladite première requête afin de permettre un contrôle de ladite première requête. 8. Procédé selon l'une quelconque des revendications 5 à 7, caractérisé en ce que le premier protocole de communication est le Protocole ARINC 661. 9. Procédé selon la revendication 8, caractérisé en ce que le second protocole de communication est le Protocole simplifié de transfert de fichier (TFTP). 10. Aéronef comprenant au moins un système client distant (8) et un poste de pilotage comportant au moins un écran d'affichage (5, 6), une unité de contrôle (10) contrôlant ledit système client distant (8), caractérisé en ce qu'il comporte un système de transmission de données entre ledit au moins un écran d'affichage (5, 6) et ledit système client distant (8) selon l'une quelconque des revendications 1 à 4.