FR2899050A1 - Procede de communication de donnees entre des sytemes de traitement heterogenes connectes en reseau local et systeme de communication mettant en oeuvre ce procede - Google Patents

Procede de communication de donnees entre des sytemes de traitement heterogenes connectes en reseau local et systeme de communication mettant en oeuvre ce procede Download PDF

Info

Publication number
FR2899050A1
FR2899050A1 FR0650971A FR0650971A FR2899050A1 FR 2899050 A1 FR2899050 A1 FR 2899050A1 FR 0650971 A FR0650971 A FR 0650971A FR 0650971 A FR0650971 A FR 0650971A FR 2899050 A1 FR2899050 A1 FR 2899050A1
Authority
FR
France
Prior art keywords
data
network
message
file
processing systems
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR0650971A
Other languages
English (en)
Other versions
FR2899050B1 (fr
Inventor
Stephane Garay
Philippe Herry
Dominique Pronto
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Airbus Operations SAS
Original Assignee
Airbus Operations SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to FR0650971A priority Critical patent/FR2899050B1/fr
Application filed by Airbus Operations SAS filed Critical Airbus Operations SAS
Priority to US12/293,647 priority patent/US8977715B2/en
Priority to JP2009500899A priority patent/JP5016664B2/ja
Priority to RU2008141703/08A priority patent/RU2473957C2/ru
Priority to CA002646351A priority patent/CA2646351A1/fr
Priority to BRPI0709055-2A priority patent/BRPI0709055A2/pt
Priority to PCT/FR2007/050969 priority patent/WO2007107674A2/fr
Priority to EP07731784A priority patent/EP1997295A2/fr
Publication of FR2899050A1 publication Critical patent/FR2899050A1/fr
Application granted granted Critical
Publication of FR2899050B1 publication Critical patent/FR2899050B1/fr
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/12Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/60Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/63Routing a service request depending on the request content or context
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/08Protocols for interworking; Protocol conversion
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/18Multiprotocol handlers, e.g. single devices capable of handling multiple protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/131Protocols for games, networked simulations or virtual reality
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/40Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Small-Scale Networks (AREA)
  • Computer And Data Communications (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention concerne un procédé de communication de données dans un aéronef entre au moins un premier système de traitement de données (H) et un second système de traitement de données (H) connectés en réseau local, chaque système de traitement étant apte à exécuter au moins une application (A), dans lequel les données à échanger sont organisées dans des messages (M), ces messages ainsi que les systèmes de traitement et les applications étant définis dans des fichiers mémorisés dans une unité de sauvegarde (2) connectée au réseau et accessible par les systèmes de traitement de données.

Description

Procédé de communication de données entre des systèmes de traitement
hétérogènes connectés en réseau local et système de communication mettant en oeuvre ce procédé Domaine de l'invention L'invention concerne un procédé de communication de données entre plusieurs systèmes de traitement de données hétérogènes, connectés en réseau local, dans lequel la configuration des communications est mémorisée dans un moyen de stockage, relié au réseau et accessible depuis chaque système de traitement. L'invention concerne également un système de communication mettant en oeuvre ce procédé. L'invention trouve des applications dans le domaine de la communication de données par réseau, notamment par réseau Ethernet, avec des systèmes de traitement distants ou co-localisés sur une même machine. En particulier, l'invention trouve des applications dans le domaine de l'aéronautique et, notamment, de la simulation aéronautique et de la transmission d'informations à bord d'un aéronef ou destinées à être installées à bord d'un aéronef. Etat de la technique Dans le domaine de la communication de données, il est fréquent de connecter ensemble différents systèmes de traitement de données par l'intermédiaire d'un réseau local, tel qu'un réseau Ethernet. Cette liaison par réseau local permet aux différents systèmes de traitement d'échanger des données entre eux, en toute sécurité, c'est-à-dire sans que des systèmes extérieurs puissent avoir accès à ces données. Dans certains domaines, et en particulier en aéronautique, ces systèmes sont souvent installés peu à peu, au fur et à mesure des besoins et de l'évolution de ces besoins. Généralement, chacun de ces systèmes a été installé ou modifié pour résoudre un ou plusieurs problème(s) particulier(s).
Par conséquent, chaque système est souvent mis au point dans un contexte particulier, avec un moyen de communication qui lui est propre. En particulier, dans le domaine de l'aéronautique, différents systèmes tels que les calculateurs, les applications informatiques, les simulateurs, etc., sont réalisés par différents équipementiers, à des périodes différentes, donc avec une évolution technique différente. Ces différents systèmes sont destinés à être installés sur un même aéronef, par exemple dans le cas de la transmission d'informations à bord d'un aéronef, ou mis en relation les uns avec les autres, par exemple dans le cas où des moyens de simulation sont couplés avec des calculateurs de l'aéronef. Chaque système est donc mis en place avec un moyen de communication qui lui est propre et qui dépend du type de données à traiter, du contexte économique et du contexte technique de la période à laquelle le système a été installé. Ainsi, initialement, chaque système est étudié pour travailler individuellement et résoudre des problèmes spécifiques. Cependant, certaines données peuvent être utiles à plusieurs systèmes de traitement. Aussi, par économie de ressources matérielles et de temps de traitements, il est fréquent de relier plusieurs systèmes de traitement entre eux par l'intermédiaire d'un réseau local, du type réseau Ethernet, pour former un seul système de communication, appelé aussi réseau de communication. Un tel système de communication offre alors une architecture globale hétérogène. Du fait de cette hétérogénéité des systèmes de traitement, la mise en réseau de ces systèmes nécessite une adaptation de chacun des systèmes au moyen de communication afin de rendre les données compréhensibles par chacun des systèmes susceptibles d'émettre ou de recevoir ces données. En d'autres termes, un système non adapté ne pourrait comprendre les données transmises depuis un autre système. De même, les données envoyées par ce système seraient incompréhensibles, donc inexploitables, par les autres systèmes du réseau. Cette adaptation des systèmes nécessite la mise en place de moyens de traduction permettant de traduire une donnée produite dans le format d'un système dans le format d'un autre système. On comprend donc que, plus le nombre de systèmes connectés au réseau est élevé, plus la mise au point de ces moyens de traduction est complexe et plus le temps d'intégration de ces moyens est long.
En outre, chaque fois qu'un nouveau système est installé et connecté sur le réseau, il est nécessaire d'adapter les moyens de traduction déjà en place pour adapter le nouveau système à l'ensemble de communication. La traduction du format des données du nouveau système doit donc être incorporée dans les moyens de traduction existants afin que les données de ce nouveau système puissent être compréhensibles par les systèmes déjà en place sur le réseau. De plus, la maintenance de l'ensemble du système de communication est difficile et délicate puisque chaque système de traitement nécessite une maintenance différente avec des solutions différentes. En outre, si un système est momentanément défaillant, il est impossible de substituer, à ce système, un autre système du réseau pour réaliser certains au moins de ses traitements, puisque chaque système a son propre format. Un tel système de communication à architecture hétérogène présente donc les inconvénients cités précédemment, avec les conséquences que cela entraîne sur son coût de fonctionnement qui dépend directement de la durée de mise au point de la traduction des données et de la recherche des pannes. Exposé de l'invention L'invention a justement pour but de remédier aux inconvénients des techniques exposées précédemment. A cette fin, l'invention propose un procédé de communication de données entre plusieurs systèmes de traitement, dans lequel une même configuration des données est adaptable à tous les systèmes. Pour cela, le procédé de l'invention propose de stocker les informations de base relatives aux données et à la topologie du réseau sous une forme simple, homogène et non équivoque, dans un moyen de stockage centralisé, accessible par tous les systèmes de traitement. Ce procédé propose ainsi de mémoriser toutes les informations nécessaires à tous les systèmes de traitement du réseau de communication, sous une forme identique, dans un lieu accessible par chacun. Les données sont échangées entre les systèmes sous la forme de messages ayant une configuration unique et comportant un nombre d'informations limité au strict minimum. Ces informations permettent au système récepteur du message de retrouver, dans le moyen de stockage centralisé, toutes les données correspondant à ce message. De façon plus précise, l'invention propose un procédé de communication de données entre au moins un premier et un second systèmes de traitement de données connectés en réseau local, chaque système de traitement étant apte à exécuter au moins une application. Ce procédé se caractérise par le fait que les données à échanger sont organisées dans des messages, ces messages ainsi que les systèmes de traitement et les applications étant définis dans des fichiers mémorisés dans une unité de sauvegarde connectée au réseau et accessible depuis les systèmes de traitement de données.
Le procédé de l'invention peut comporter également une ou plusieurs des caractéristiques suivantes : - un des fichiers mémorisés est un fichier machine comportant une liste de tous les systèmes de traitement avec une adresse sur le réseau de chaque système, définissant une topologie du réseau. - un des fichiers mémorisés est un fichier application comportant une liste de toutes les applications et des systèmes sur lesquels chaque application peut être exécutée. - un des fichiers mémorisés est un fichier message comportant toutes les données pouvant être échangées ainsi que des chemins à emprunter entre les applications pour transmettre ces données. -un des fichiers mémorisés est un fichier utilisateur comportant un nom. -le fichier machine, le fichier application et le fichier message sont des fichiers partagés par tous les utilisateurs. - le fichier utilisateur est spécifique à chaque utilisateur. - les fichiers sont réalisés au format XML. - chaque message comporte au moins trois champs de données. - un premier champ contient un identifiant du message, un deuxième champ contient une longueur des données du message et un troisième champ contient des paramètres à échanger. - le réseau de communication reliant les systèmes de traitement est un réseau Ethernet. L'invention concerne également un système de communication de données comportant une pluralité de systèmes de traitement reliés en réseau local, caractérisé en ce qu'il met en oeuvre le procédé selon l'une quelconque des revendications précédentes. Ce système de communication peut comporter une unité de stockage centralisée, installée sur le réseau et accessible par tous les systèmes de traitement.
Brève description des figures La figure 1 représente schématiquement un système de communication selon l'invention. La figure 2 représente un exemple de message échangé dans le système de communication de la figure 1, ayant la configuration du procédé de l'invention. La figure 3 représente un tableau décrivant des exemples de types de paramètres d'un message de la figure 2. Les figures 4, 5, 6 et 7 représentent des exemples de fichiers 10 enregistrés dans le moyen de stockage centralisé du système de communication de l'invention. Les figures 8A et 8B représentent, respectivement, un exemple de communication de messages dans un système de communication selon l'invention et un tableau résumant cet échange de. 15 Description détaillée de modes de réalisation de l'invention L'invention concerne un procédé de communication de données, ou protocole de communication, permettant un échange de données homogènes entre plusieurs systèmes de traitement de données reliés par l'intermédiaire d'un réseau local. Ces systèmes peuvent être installés à bord 20 de l'aéronef ; ils peuvent être également au sol, en particulier lorsque ces systèmes sont des moyens de simulation couplés avec des calculateurs avions afin de valider lesdits calculateurs avant le premier vol. Dans la suite de la description, on parlera d'un protocole de communication dans un aéronef, étant entendu qu'il concerne également des systèmes au sol, 25 relatifs à l'aéronef. Ce réseau local peut être un réseau Ethernet, ou tout autre réseau local fonctionnant au moyen d'un protocole de transmission de données par paquets. La transmission sur le réseau local des données est donc réalisée suivant un processus de transmission standard tel que celui du réseau Ethernet ou du réseau Internet. Les données sont transmises, sur ce 30 réseau, sous la forme de messages ayant une configuration particulière, décrite ultérieurement. Le procédé de l'invention consiste à utiliser une topologie simple, unique et homogène qui permet de décrire toutes les informations utiles aux systèmes de traitement de données avec une même configuration et 35 d'enregistrer la définition de ces informations sur un même et unique moyen de stockage centralisé, appelé aussi unité de stockage. Cette unité de stockage fonctionne en utilisant un format connu tel que le format XML. Le format XML est un langage informatique adapté à la gestion de documents longs et complexes, comme on en trouve dans les réseaux intranets, et qui permet à l'utilisateur de sélectionner le type d'information qu'il souhaite consulter. La configuration des communications peut aussi être répartie au niveau de chaque utilisateur, la cohérence étant assurée par le protocole de l'invention.
Selon l'invention, les informations utiles à mémoriser dans l'unité de stockage concernent l'identification des utilisateurs du réseau de communication, à savoir les applications exécutées par les systèmes de traitement du réseau ainsi que l'identification des différentes données à échanger. L'invention propose aussi d'identifier les mécanismes de formatage et de distribution des données de chaque système de traitement. Pour cela, le procédé de l'invention propose de décrire toutes ces informations dans des fichiers enregistrés dans le moyen de stockage centralisé. Chaque fichier regroupe des informations relatives à un même type d'élément, par exemple les systèmes de traitement, les applications, etc. En particulier, dans le mode de réalisation préféré de l'invention, quatre fichiers permettent de définir toutes les informations utiles à tous les systèmes de traitement. Comme expliqué plus en détails par la suite, un premier fichier, appelé fichier machine, décrit la topologie du réseau de communication avec la liste de tous les systèmes et leur adresse respective sur le réseau. Un second fichier, appelé fichier application, définit toutes les applications pouvant être exécutées sur le réseau avec toutes les informations relatives à chaque application. Un troisième fichier, appelé fichier message, décrit toutes les données pouvant être échangées sur le réseau avec toutes les informations relatives à ces données. Un quatrième fichier, appelé fichier utilisateur, identifie tous les utilisateurs du réseau, c'est-à-dire le nom de chaque application du réseau. Un exemple d'un réseau de communication mettant en oeuvre le procédé de l'invention est représenté sur la Figure 1. Ce réseau de communication 1 comporte plusieurs systèmes de traitement de données.
Ces systèmes de traitement sont distants les uns des autres ou co-localisés sur une même machine. Dans l'exemple de la figure 1, un système 111 est installé sur une machine 11, un système 101 et un système 102 sont installés sur une machine 10, un système 131 est installé dans une machine 13 et un système 121 est installé dans une machine 12. Ces machines peuvent être, par exemple, le calculateur de bord d'un aéronef, un simulateur de vol ou tout autre ordinateur permettant de déterminer des paramètres de vol de l'aéronef. Ces systèmes de traitement sont reliés les uns aux autres par un réseau local. A ce réseau, est également connectée une unité de stockage 2 de toutes les informations utiles à ces systèmes. L'unité de stockage est une unité de sauvegarde dédiée uniquement à la configuration des données susceptibles d'être utilisées par les systèmes de traitement de données. Cette unité de stockage telle que représentée sur la figure 1 correspond à la configuration des communications. Cette représentation de la configuration des communications n'est qu'un exemple. La figure 1 n'est pas limitative quant à la topologie du réseau. L'unité de stockage 2 comporte plusieurs fichiers, par exemple le fichier machine 21, le fichier application 22, le fichier message 23 et le fichier utilisateur 24, décrits en détails ultérieurement. La caractéristique particulière de cette unité de stockage 2 est d'être sauvegardée de façon permanente ou quasi permanente. Tous les systèmes de traitement de données du réseau 1 ont accès à cette unité de stockage 2. Cette unité de stockage constitue ainsi un moyen centralisé de sauvegarde des informations. Cette unité de stockage 2 permet d'assurer une homogénéité parfaite du réseau de communication, car toutes les informations y sont décrites de la même façon. Ainsi, tout système de traitement accédant à une information est sûr d'avoir la même information que celle reçu ou émise par un autre système du réseau. Ceci permet au réseau de communication d'être cohérent puisque toutes les informations nécessaires sont rassemblées en un lieu unique avec une configuration unique. Les informations ne peuvent ainsi être comprises que d'une seule et unique façon par tous les systèmes de traitement du réseau. Il n'y a donc aucune mauvaise interprétation possible. Le protocole de communication selon l'invention est donc non équivoque. Un avantage supplémentaire de cette unité de stockage centralisé 2 35 est que chaque modification de donnée peut être connue de tous les systèmes de traitement. La modification est apportée uniquement dans le ou les fichiers contenant cette donnée et elle est répercutée aux systèmes lorsque ceux-ci la recherche dans l'unité de stockage. En outre, si le procédé de l'invention a choisit un format classique, tel que le format XML, alors la configuration du réseau est évolutive, aussi bien en nombre d'objets qu'en attributs caractérisant chaque objet. Il permet ainsi une rapidité d'intégration et de couplage d'un système puisque seuls les fichiers de l'unité de stockage doivent être modifiés lors de l'intégration d'un nouveau système. En aucun cas, les utilisateurs du réseau ne voient leur interface de communication évoluer. Dans ce réseau de commutation selon l'invention, les données sont échangées entre les systèmes de traitement au moyen de messages circulant sur le réseau. Un message est un élément de base dans la transmission sur le réseau. Pour assurer l'homogénéité du réseau, les messages ont tous une configuration unique. Sur la figure 2, on a représenté un exemple de message ayant une configuration conforme à l'invention. Ce message comporte un premier champ chi, appelé champ identifiant et correspondant à l'identification du message concerné. Il comporte un second champ ch2, appelé champ longueur et donnant la taille du message exprimée en octets. Il comporte un troisième champ ch3, appelé champ paramètre, qui contient tous les paramètres, ou données, à transmettre sur le réseau. Ainsi, chaque message circulant sur le réseau local est identifié par un numéro unique. Les messages étant les éléments de base échangés entre les utilisateurs, c'est-à-dire entre les applications exécutées par les systèmes de traitement, chaque message contient : - l'identité du message, cette identité se présentant sous le forme d'un nombre entier, - la longueur du message, ce qui permet à l'utilisateur récepteur du message de retrouver le type des données transmises, - les paramètres, c'est-à-dire les données qui doivent être transmises à un autre utilisateur. Le système récepteur du message, ou utilisateur receveur, est capable, à partir des informations fournies dans le message, de retrouver, dans les fichiers de l'unité de stockage, les données qui lui sont nécessaires. En particulier, à partir de la longueur du message, le système récepteur est capable de retrouver le type des données et, à partir des paramètres du message, il est capable de déterminer la valeur de ces données. La figure 3 représente, sous la forme d'une table, des exemples de types de paramètres, ou types de données, qui peuvent être contenus dans un message. Cette table comporte une liste des types avec la longueur, en octets, qui leur correspond. C'est cette valeur en octet qui est transmise dans le message. A réception d'un message, le système récepteur regarde, dans la configuration des communications, les caractéristiques du message qu'il vient de recevoir en se basant sur l'identité du message (premier champ). Il compare la longueur (deuxième champ) avec la longueur théorique trouvée dans la configuration, à des fins de vérification de la bonne santé des communications, puis découvre l'ensemble des paramètres qui composent le message (troisième champ) afin de pouvoir assurer le décodage. Ces paramètres peuvent être, par exemple, un nombre entier, un octet, un nombre réel, un tableau ou encore un paramètre à taille variable. Dans le cas où le type élémentaire est un paramètre à taille variable, le procédé de l'invention permet de minimiser la bande passante en ne transportant que le strict nécessaire.
L'avantage de transmettre la longueur est de diminuer la taille du message, ce qui facilite son transfert. En effet, en réduisant la taille du message à son strict minimum, cela permet d'économiser la bande passante et d'assurer une transmission plus rapide du message. Le fait de connaitre les débits exacts et les volumes d'informations transportées permet de maîtriser la bande passante et donc d'anticiper des éventuels problèmes d'engorgement. L'ensemble de la configuration du message qui vient d'être décrite permet de limiter la taille des messages au strict minimum. Ainsi, chaque message circulant sur le réseau est réduit à son minimum, ce minimum étant toutefois suffisant pour que le message puisse être compris par le système récepteur. On comprendra, cependant, que d'autres configurations de message peuvent aussi être utilisées. Comme expliqué précédemment, toutes les données susceptibles d'être utilisées dans le réseau de communication de l'invention sont définies 35 et enregistrées dans une unité de stockage unique et centralisée ou répartie au niveau de chaque acteur. Ces données sont réparties dans plusieurs fichiers de configuration, chaque fichier étant associé à une fonction particulière ou un élément particulier du réseau. Les données sont ainsi dissociées en plusieurs fichiers, ce qui permet de faciliter la description physique du réseau de communication, des applications ainsi que des caractéristiques statiques et dynamiques des données. Dans un mode de réalisation préféré de l'invention, les données sont réparties dans quatre fichiers, déjà cités précédemment : - le fichier machine décrit la topologie du réseau. Un exemple de ce fichier est représenté sur la figure 4. Ce fichier décrit toutes les informations et caractéristiques relatives à chacun des systèmes de traitement de données du réseau. Ce fichier liste notamment les machines sur lesquelles les différents systèmes sont implantés. Ce fichier liste également les adresses de ces systèmes sur le réseau, sous le nom d'adresses IP. Ce fichier machine est partagé par tous les utilisateurs, c'est-à-dire que toutes les applications peuvent y avoir accès depuis n'importe quel système de traitement du réseau. - le fichier application identifie toutes les applications susceptibles d'être exécutées dans les systèmes de traitement du réseau. Un exemple d'un tel fichier est représenté sur la figure 5. Ce fichier application liste toutes les applications du réseau. Il décrit, pour chaque application, les systèmes de traitement sur lesquelles l'application peut être exécutée. Il décrit également, pour chaque application, les liens entre les différents paramètres. Ces liens définissent des chemins de communication, appelées canaux de communication (channel en termes anglo-saxons). Ces canaux sont définis par leur nom, leur adresse IP, le type de formatage (endianness, en termes anglosaxons) et leur numéro de port au sens UDP/TCP. Les ports TCP et UDP sont des modes de synchronisation des données avec, respectivement, une garantie ou non que l'arrivée et l'ordre d'arrivée des données soit respecté. Le fichier application Ce fichier application est partagé par tous les utilisateurs. - le fichier message identifie toutes les données, ou paramètres, susceptibles d'être échangées. Un exemple d'un tel fichier est représenté sur la figure 7. Ce fichier message liste tous les messages et décrit, pour chaque message, le type du message, le type de communication ainsi que la période de communication. Le fichier message décrit aussi, pour chaque message, l'application émettrice du message, l'application réceptrice ainsi que les canaux à emprunter pour aller de l'application émettrice à l'application réceptrice. Il contient également l'identification du message ainsi que la longueur du message à transmettre. Finalement, il définit les paramètres contenus dans chaque message ainsi que le type et la taille de ces paramètres. Le fichier message est un fichier partagé par tous les utilisateurs. - le fichier utilisateur identifie l'utilisateur lui-même, c'est-à-dire l'application concernée. Un exemple d'un tel fichier utilisateur est représenté sur la figure 6. Ce fichier utilisateur comporte le nom de l'application dont les communications doivent être prises en compte. Ce fichier permet de substituer à un premier utilisateur, un second utilisateur, simplement en changeant le nom de l'utilisateur dans ledit fichier. Ce fichier utilisateur est spécifique à chaque utilisateur. Il ne peut être consulté par les autres utilisateurs. Sur les figures 8A et 8B, on a représenté un exemple de réseau de communication selon l'invention, dans lequel trois systèmes de traitement de données H1, H2, H3 sont reliés par un réseau Ethernet. Le système H1 et le système H3 utilisent des processeurs du type Little. Le système H2 utilise un processeur travaillant suivant le mode Big. Les types Little et Big sont deux façons différentes et non compatibles de représenter des données en mémoire. Le système H1 héberge plusieurs applications, à savoir les applications Al et A2. Le système H2 héberge l'application A3 et le système H3 héberge l'application A4. Chacune de ces applications utilise un canal C pour transmettre ses informations sur le réseau. Par exemple, l'application Al transmet ses messages M1 et M2 par le canal Cl vers l'application A3 et son message M4 par le canal C2vers l'application A4. L'application A3 transmet son message M3 par le canal C4 vers l'application Al. L'application A4 transmet son message M6 par le canal C5 vers les applications A2 et A1. L'application A2 transmet son message M5 par le canal C3 vers l'application A4. Chaque canal C1, C2, C3, C4 ou C5 est repéré par une adresse IP et un port TCP ou UDP. Des exemples d'adresses de ces canaux sont notés 35 sous chaque système H1, H2 et H3.
Les échanges de messages entre ces trois systèmes H1, H2 et H3 sont résumés dans le tableau de la figure 8B. Ce tableau regroupe ainsi les informations relatives aux différents messages émis sur le réseau local, dans l'exemple de réseau de la figure 8A. Par exemple, la première émission de message identifiée 1 envoie le message M1 depuis l'application Al par le canal Cl vers l'application A3 par le canal C4. Les paramètres transmis par le message M1 sont le paramètre 132 et le paramètre F64. Ce paramètre F64 est une donnée de type réel de 64 bits avec 5 réels. Le paramètre 132 est un entier de 32 bits.
Chaque application et chaque message étant préalablement définis dans l'unité de stockage, un message échangé entre deux systèmes de traitement prend directement en compte les différences de format des deux systèmes, sans adaptation nécessaire. En effet, les fichiers de description des informations prennent en compte les caractéristiques de chaque système, ce qui a pour effet que le système lui-même n'a pas de formatage ou de déformatage à gérer ; il a simplement à réceptionner le message et à regarder dans le fichier à quoi correspond ce message. Le changement de format est transparent. Dans l'exemple de la figure 8A, le changement de format, pour passer d'un mode Little ou à un mode Big (qui sont deux modes différents de rangement des données en mémoire), est transparent pour les systèmes H1, H2 et H3.

Claims (8)

REVENDICATIONS
1 ù Procédé de communication de données dans un aéronef entre au moins un premier système de traitement de données (H) et un second système de traitement de données (H) connectés en réseau local, chaque système de traitement étant apte à exécuter au moins une application (A), caractérisé en ce que les données à échanger sont organisées dans des messages (M), ces messages ainsi que les systèmes de traitement et les applications étant définis dans des fichiers mémorisés dans une unité de sauvegarde (2) connectée au réseau et accessible par les systèmes de traitement de données.
2 ù Procédé selon la revendication 1, caractérisé en ce qu'un des fichiers mémorisés est un fichier machine (21) comportant une liste de tous les systèmes de traitement avec une adresse sur le réseau de chaque système, définissant une topologie du réseau.
3 ù Procédé selon la revendication 1 ou 2, caractérisé en ce qu'un des fichiers mémorisés est un fichier application (22) comportant une liste de toutes les applications et des systèmes sur lesquels chaque application peut être exécutée.
4 ù Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce qu'un des fichiers mémorisés est un fichier message (23) comportant toutes les données pouvant être échangées ainsi que des chemins à emprunter entre les applications pour transmettre ces données.
5 ù Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce qu'un des fichiers mémorisés est un fichier utilisateur (24) comportant un nom.
6 ù Procédé selon les revendications 2, 3 et 4, caractérisé en ce que le fichier machine, le fichier application et le fichier message sont des fichiers partagés par tous les utilisateurs.
7 ù Procédé selon la revendication 5, caractérisé en ce que le fichier utilisateur est spécifique à chaque utilisateur.
8 ù Procédé selon l'une quelconque des revendications 1 à 7, caractérisé en ce que les fichiers sont réalisés au format XML.9 ù Procédé selon l'une quelconque des revendications 1 à 8, caractérisé en ce que chaque message comporte au moins trois champs de données. 10 ù Procédé selon la revendication 9, caractérisé en ce qu'un premier champ contient un identifiant du message (chi), un deuxième champ contient une longueur des données du message (ch2) et un troisième champ contient des paramètres à échanger (ch3). 11 ù Procédé selon l'une quelconque des revendications 1 à 10, caractérisé en ce que le réseau de communication reliant les systèmes de traitement est un réseau Ethernet. 12 ù Système de communication de données comportant une pluralité de systèmes de traitement reliés en réseau local, caractérisé en ce qu'il met en oeuvre le procédé selon l'une quelconque des revendications précédentes. 13 ù Système de communication selon la revendication 12, caractérisé en ce qu'il comporte une unité de stockage centralisée (2), installée sur le réseau (1) et accessible par tous les systèmes de traitement (H). 14 ù Aéronef caractérisé en ce qu'il met en oeuvre le procédé de communication selon l'une quelconque des revendications 1 à 11. 15 ù Aéronef caractérisé en ce qu'il comporte un système de communication selon l'une quelconque des revendications 12 et 13.
FR0650971A 2006-03-21 2006-03-21 Procede de communication de donnees entre des sytemes de traitement heterogenes connectes en reseau local et systeme de communication mettant en oeuvre ce procede Expired - Fee Related FR2899050B1 (fr)

Priority Applications (8)

Application Number Priority Date Filing Date Title
FR0650971A FR2899050B1 (fr) 2006-03-21 2006-03-21 Procede de communication de donnees entre des sytemes de traitement heterogenes connectes en reseau local et systeme de communication mettant en oeuvre ce procede
JP2009500899A JP5016664B2 (ja) 2006-03-21 2007-03-20 ローカルエリアネットワークで接続される異機種環境にある処理システム間のデータ通信方法およびこの方法を利用する通信システム
RU2008141703/08A RU2473957C2 (ru) 2006-03-21 2007-03-20 Способ передачи данных между неоднородными системами обработки, соединенными в локальную сеть, и система передачи, использующая этот способ
CA002646351A CA2646351A1 (fr) 2006-03-21 2007-03-20 Procede de communication de donnees entre des systemes de traitement heterogenes connectes en reseau local et systeme de communication mettant en oeuvre ce procede
US12/293,647 US8977715B2 (en) 2006-03-21 2007-03-20 Method for communicating data between locally networked heterogeneous processing systems and communication system using said method
BRPI0709055-2A BRPI0709055A2 (pt) 2006-03-21 2007-03-20 processo de comunicação de dados entre os sistemas de tratamento heterogêneos conectados em rede local e sistema de comunicação utilizando este processo
PCT/FR2007/050969 WO2007107674A2 (fr) 2006-03-21 2007-03-20 Procede de communication de donnees entre des systemes de traitement heterogenes connectes en reseau local et systeme de communication mettant en oeuvre ce procede
EP07731784A EP1997295A2 (fr) 2006-03-21 2007-03-20 Procede de communication de donnees entre des systemes de traitement heterogenes connectes en reseau local et systeme de communication mettant en oeuvre ce procede

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0650971A FR2899050B1 (fr) 2006-03-21 2006-03-21 Procede de communication de donnees entre des sytemes de traitement heterogenes connectes en reseau local et systeme de communication mettant en oeuvre ce procede

Publications (2)

Publication Number Publication Date
FR2899050A1 true FR2899050A1 (fr) 2007-09-28
FR2899050B1 FR2899050B1 (fr) 2008-09-19

Family

ID=37311883

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0650971A Expired - Fee Related FR2899050B1 (fr) 2006-03-21 2006-03-21 Procede de communication de donnees entre des sytemes de traitement heterogenes connectes en reseau local et systeme de communication mettant en oeuvre ce procede

Country Status (8)

Country Link
US (1) US8977715B2 (fr)
EP (1) EP1997295A2 (fr)
JP (1) JP5016664B2 (fr)
BR (1) BRPI0709055A2 (fr)
CA (1) CA2646351A1 (fr)
FR (1) FR2899050B1 (fr)
RU (1) RU2473957C2 (fr)
WO (1) WO2007107674A2 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2930697A1 (fr) * 2008-04-29 2009-10-30 Airbus France Sas Procede et dispositif de configuration dynamique d'un reseau de communication pour la simulation temps reel de l'integration de composants electroniques dans un vehicule
FR2938092A1 (fr) * 2008-11-03 2010-05-07 Eurocopter France Procede de controle de l'integrite d'un systeme avionique et dispositif de controle pour mettre en oeuvre ledit procede

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9494933B1 (en) * 2009-06-19 2016-11-15 The Boeing Company Processing packets in an aircraft network data processing system
KR101035303B1 (ko) 2010-12-02 2011-05-19 삼성탈레스 주식회사 항공기 컴퓨팅 디바이스 간의 다중화 통신방법
US8755953B2 (en) * 2012-05-21 2014-06-17 The Boeing Company Aircraft information management system
CN104303456B (zh) * 2012-06-29 2018-04-03 哈曼(中国)投资有限公司 用于统一访问机载设备的方法和装置

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0451897A2 (fr) * 1990-04-09 1991-10-16 The Boeing Company Appareil et méthode pour fournir une interface adaptable entre ordinateurs
US20030229603A1 (en) * 2002-06-07 2003-12-11 Childress Jeremy D. Behavioral translation of datalink messages between different protocols and platforms
US6789126B1 (en) * 2000-05-09 2004-09-07 Sun Microsystems, Inc. Addressing message gates in a distributed computing environment
US20040187095A1 (en) * 2003-03-19 2004-09-23 International Business Machines Corporation Installation of data-driven business integration adapters

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5778203B1 (en) * 1996-10-01 2000-02-08 Honeywell Emical Aircraft display and control system with virtual backplane architecture
AU4481600A (en) * 1999-04-22 2000-11-10 Qode.Com, Inc. System and method for providing electronic information upon receipt of a scannedbar code
US20030093798A1 (en) * 2000-07-10 2003-05-15 Michael Rogerson Modular entertainment system configured for multiple broadband content delivery incorporating a distributed server
US6963993B1 (en) * 2000-09-28 2005-11-08 The United States Of America As Represented By The Administrator Of The National Aeronautics And Space Administration Fail-over file transfer process
NO20011022D0 (no) * 2001-02-28 2001-02-28 Hans Gude Gudesen FremgangsmÕte ved overføring av informasjon
US20030069990A1 (en) * 2001-10-05 2003-04-10 D'annunzio Michael A. Router discovery protocol on a mobile internet protocol based network
US6944788B2 (en) * 2002-03-12 2005-09-13 Sun Microsystems, Inc. System and method for enabling failover for an application server cluster
US7739365B2 (en) * 2002-12-19 2010-06-15 Converged Data Solutions, Inc. Methods for providing a report database for a plurality of localized devices using an abstraction layer and atomic error handling
US7523184B2 (en) * 2002-12-31 2009-04-21 Time Warner Cable, Inc. System and method for synchronizing the configuration of distributed network management applications
US6801769B1 (en) * 2003-03-12 2004-10-05 The Boeing Company Modular aircraft information network system and an associated method of packaging the same
US7631068B1 (en) * 2003-04-14 2009-12-08 Symantec Operating Corporation Topology for showing data protection activity
US7873684B2 (en) * 2003-08-14 2011-01-18 Oracle International Corporation Automatic and dynamic provisioning of databases

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0451897A2 (fr) * 1990-04-09 1991-10-16 The Boeing Company Appareil et méthode pour fournir une interface adaptable entre ordinateurs
US6789126B1 (en) * 2000-05-09 2004-09-07 Sun Microsystems, Inc. Addressing message gates in a distributed computing environment
US20030229603A1 (en) * 2002-06-07 2003-12-11 Childress Jeremy D. Behavioral translation of datalink messages between different protocols and platforms
US20040187095A1 (en) * 2003-03-19 2004-09-23 International Business Machines Corporation Installation of data-driven business integration adapters

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2930697A1 (fr) * 2008-04-29 2009-10-30 Airbus France Sas Procede et dispositif de configuration dynamique d'un reseau de communication pour la simulation temps reel de l'integration de composants electroniques dans un vehicule
FR2938092A1 (fr) * 2008-11-03 2010-05-07 Eurocopter France Procede de controle de l'integrite d'un systeme avionique et dispositif de controle pour mettre en oeuvre ledit procede
EP2204713A1 (fr) * 2008-11-03 2010-07-07 Eurocopter Procédé de contrôle de l'intégrité d'un systéme avionique et dispositif de contrôle pour mettre en oevre ledit procédé
US8224503B2 (en) 2008-11-03 2012-07-17 Eurocopter Method of inspecting the integrity of an avionics system, and an inspection device for implementing said method

Also Published As

Publication number Publication date
EP1997295A2 (fr) 2008-12-03
FR2899050B1 (fr) 2008-09-19
JP2009530942A (ja) 2009-08-27
RU2473957C2 (ru) 2013-01-27
JP5016664B2 (ja) 2012-09-05
WO2007107674A3 (fr) 2007-11-08
US20100312835A1 (en) 2010-12-09
BRPI0709055A2 (pt) 2011-06-28
CA2646351A1 (fr) 2007-09-27
WO2007107674A2 (fr) 2007-09-27
US8977715B2 (en) 2015-03-10
RU2008141703A (ru) 2010-04-27

Similar Documents

Publication Publication Date Title
EP1835411B1 (fr) Systeme sur puce a controle semi-distribue
FR2923969A1 (fr) Procede de gestion de trames dans un reseau global de communication, produit programme d'ordinateur, moyen de stockage et tete de tunnel correspondants
FR2773935A1 (fr) Procedes de communication entre systemes informatiques et dispositifs les mettant en oeuvre
EP1962215B1 (fr) Dispositif de connexion sélective permettant la connexion d'au moins un périphérique à un ordinateur cible et système de controle sélectif comportant un tel dispositif
FR2899050A1 (fr) Procede de communication de donnees entre des sytemes de traitement heterogenes connectes en reseau local et systeme de communication mettant en oeuvre ce procede
FR3001849A1 (fr) Procede pour router des donnees, programme d'ordinateur, controleur de reseau et reseaux associes
FR2998748A1 (fr) Dispositif et procede de retransmission de donnees dans un commutateur reseau
EP2751959B1 (fr) Procédé d'échange de données entre noeuds d'une grappe de serveurs et grappe de serveurs mettant en oeuvre ce procédé
WO2008012273A1 (fr) Procede de synchronisation entre un equipement mobile et une carte a puce
FR2860616A1 (fr) Unite de commande de dispositif de memorisation et procede de commande de celui-ci
FR2737372A1 (fr) Dispositif et procede d'interconnexion de reseaux, routeur ip comprenant un tel dispositif
FR3019340A1 (fr) Composant electronique a reponse determeniste
EP3373558B1 (fr) Procédé de communication pour assurer le maintien d'une session applicative entre un terminal et un serveur d'application
EP2979222B1 (fr) Procédé de stockage de données dans un système informatique effectuant une deduplication de données
EP3122005B1 (fr) Système de routage permettant le filtrage de données pour l'intégration et le test d'équipements opérationnels
EP3709185A1 (fr) Procédé d'optimisation d'échanges de données dans une infrastructure d'objets connectés
WO2006045918A1 (fr) Procede, systeme et dispositif d'administration reseau
FR3091100A1 (fr) Procédé D’IDENTIFICATION DE nœud DE COMMUNICATION
FR2999368A1 (fr) Dispositif d'entrees sorties transferant et/ou recevant des donnees a un dispositif de controle.
WO2000042526A1 (fr) Interfonctionnement et systeme de caches cooperants et caches repartis
FR3071374A1 (fr) Procede et systeme pour distribuer un contenu multimedia a des terminaux informatiques
FR2788398A1 (fr) Interfonctionnement de caches cooperants et caches repartis
FR2835674A1 (fr) Deploiement des regles par un dispositif de gestion de services, en fonction d'informations sur les equipements du reseau
FR3066340A1 (fr) Procede pour la creation de comptes d'acces au reseau internet
FR2930700A1 (fr) Procedes et dispositifs pour l'echange temps reel de donnees dans un reseau de communication commute

Legal Events

Date Code Title Description
CA Change of address

Effective date: 20110916

CD Change of name or company name

Owner name: AIRBUS HOLDING, FR

Effective date: 20110916

CJ Change in legal form

Effective date: 20110916

TP Transmission of property

Owner name: AIRBUS HOLDING, FR

Effective date: 20110913

PLFP Fee payment

Year of fee payment: 10

ST Notification of lapse

Effective date: 20161130