WO2009007570A2 - Procédés et dispositifs por la communication de données de diagnostic dans un réseau de communication temps réel - Google Patents

Procédés et dispositifs por la communication de données de diagnostic dans un réseau de communication temps réel Download PDF

Info

Publication number
WO2009007570A2
WO2009007570A2 PCT/FR2008/051104 FR2008051104W WO2009007570A2 WO 2009007570 A2 WO2009007570 A2 WO 2009007570A2 FR 2008051104 W FR2008051104 W FR 2008051104W WO 2009007570 A2 WO2009007570 A2 WO 2009007570A2
Authority
WO
WIPO (PCT)
Prior art keywords
network
node
message
identification
address
Prior art date
Application number
PCT/FR2008/051104
Other languages
English (en)
Other versions
WO2009007570A3 (fr
Inventor
Franck Dessertenne
Original Assignee
Airbus France
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
Application filed by Airbus France filed Critical Airbus France
Priority to BRPI0811800-0A2A priority Critical patent/BRPI0811800A2/pt
Priority to US12/666,447 priority patent/US8868708B2/en
Priority to CN200880022056.XA priority patent/CN101785283B/zh
Priority to EP08806038.9A priority patent/EP2168358B1/fr
Priority to CA2691266A priority patent/CA2691266C/fr
Priority to JP2010514054A priority patent/JP5612468B2/ja
Publication of WO2009007570A2 publication Critical patent/WO2009007570A2/fr
Publication of WO2009007570A3 publication Critical patent/WO2009007570A3/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/10—Mapping addresses of different types
    • H04L61/103—Mapping addresses of different types across network layers, e.g. resolution of network layer into physical layer addresses or address resolution protocol [ARP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H04L67/125—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00—Indexing scheme associated with group H04L61/00
    • H04L2101/60—Types of network addresses
    • H04L2101/618—Details of network addresses
    • H04L2101/659—Internet protocol version 6 [IPv6] addresses

Definitions

  • the present invention provides non-intrusive identification and communication methods and devices between a serving node and multiple client nodes within a real-time switched network.
  • a "switch fabric” type network is based on a switched architecture, that is to say that the terminal equipment responsible for sending and receiving data is organized around the switches responsible for transporting this data, at N inputs and N outputs. Communication is achieved by sending and receiving packets, the latter being sent in parallel.
  • the invention concerns, in a real-time data processing network comprising at least one server and at least one client, the principles governing the communication of diagnostic data between these elements of the network so as to be no intrusive on real-time communication circulating elsewhere on the same network.
  • the invention applies in particular in an aircraft component simulation network in real time, where a diagnosis of these components must be performed without disturbing the simulation network.
  • the simulation of aircraft components is used to ensure the development and integration of electronic and computer systems embedded in aircraft, especially before the first flight.
  • the simulation architecture comprises a plurality of terminals also called nodes of the network, each of these terminals being able to perform the simulation calculations or constituting the electronic interface with the real environment, to verify the operation of the actual equipment of the network. 'aircraft.
  • this architecture notably comprises a simulation terminal able to transmit data in a synchronous sequence according to the request / response principle.
  • Nodes of the network consist of simulation computers and input / output cards of electronic interfaces.
  • the message exchanges generate additional traffic on the network between the diagnostic equipment and the different nodes of the network.
  • the messages exchanged are typically ARP messages (acronym for "Address Resolution Protocol" in English terminology).
  • the present invention aims to remedy at least one of the disadvantages of the techniques and processes of the aforementioned prior art.
  • the invention notably proposes a method and a device for dynamically identifying, in a server node, at least one client node in a communication network and a method and an identification device, in a client node. , a server node in a communication network capable of meeting strong constraints such as the non-disruption of the real-time running of the simulation.
  • the invention thus relates to a method for identifying, in a server node connected to a network, at least one client node connected to the network, the method comprising the following steps, a step of sending an identification message to at least one client node, the identification message comprising the physical address and the Internet address of said server node, and
  • MAC physical address
  • IP Internet address
  • the method according to the invention thus makes it possible to dynamically determine the topology of the network without requiring a point-to-point connection or the prior knowledge of its topological definition.
  • This method makes it possible to respect non-intrusion constraints allowing real-time simulations to take place.
  • said at least one pair of client node addresses is stored statically in a correspondence table between a physical address and an Internet address, such as the ARP table of the operating system, in said server node to control the messages generated by the operating system, that is to say for example to constrain ARP mechanisms.
  • the transmission of said identification message is performed in multicast mode.
  • the invention also relates to a method of exchanging diagnostic data in a network between a node of the network and a diagnostic terminal connected to the network, the method comprising the following steps,
  • the method according to the invention thus makes it possible to exchange diagnostic data without disturbing the real-time operation of the network while retaining standard network characteristics.
  • the invention also relates to a method for identifying, in a client node connected to a network, a server node connected to the network, the method comprising the following steps,
  • MAC physical address
  • IP Internet address
  • said at least one pair of addresses of the server node is stored statically in a correspondence table between a physical address and an Internet address, such as the ARP table of the operating system, in said client node.
  • the subject of the invention is also a method for exchanging diagnostic data, in a client node connected to a network, characterized in that it comprises the following steps,
  • the method according to the invention thus implements priority management services to limit the intrusion of diagnostic operations on simulation operations.
  • the diagnostic data management and simulation tasks use different ports.
  • the invention also relates to a computer program comprising instructions adapted to the implementation of each of the steps of the methods described above.
  • the invention also relates to a device comprising means adapted to the implementation of each of the steps of the methods described above.
  • FIG. 1 illustrates a simulation network architecture integrating a diagnostic terminal in accordance with the invention
  • FIG. 2 shows the programming layers of the system and the interactions with the client and server diagnostic modules in accordance with the invention.
  • the diagnosis of a component simulation network is centralized and integrated. This simulation is based on strong real-time constraints so that it must not be disturbed in order to best simulate the actual behavior of the components.
  • the diagnostic features include the following:
  • the diagnostic system is integrated into the simulation network and only one network connection is necessary.
  • the diagnostic function is centralized.
  • the simulation network illustrated in FIG. 1, comprises a set of network nodes able to work together in order to perform the simulation of components, in particular avionic components connected together in each other. a switch fabric switched network.
  • each of the nodes 10 of the network 5 is connected to a main switch 15.
  • These nodes 10 are in particular calculation nodes, input / output cards, intermediate nodes and concentrators.
  • the network is a broadband network for example a network of hundred mega bits per second or a gigabyte per second.
  • a module in particular a software module (called “plugin” in English terminology) is installed in different nodes of the network to be diagnosed, called diagnostic module client, and in the diagnostic equipment 25, called the server diagnostic module.
  • This software module is a program integrated into the operational application of each node of the electronic interface. According to the invention, a particular implementation of the message layer is carried out relying as much as possible on the POSIX programming layers (acronym for "Portable Operating System").
  • diagnostic server equipment In English terminology, operating system nodes and diagnostic equipment 25.
  • the diagnostic server equipment must perform, at startup, learning the network topology. This learning is dynamic, that is to say that it is obtained by interrogating the various nodes of the network, in particular by issuing a specific identification message and processing the associated response messages.
  • the exchange of messages can be performed in a synchronous mode or an asynchronous mode (also called "TRAP" mode in English terminology).
  • a diagnostic request is sent by the diagnostic terminal (server node) and a response is sent by the diagnosed node (client node) at the end of the processing.
  • a processing is activated by means of a unicast message, that is to say in a point-to-point mode, or a multicast message, that is to say a message. message intended for a group of network nodes.
  • the diagnostic data is obtained periodically and automatically according to a programmable period
  • the intrusion of the diagnosis on the real-time operation of the simulation is controlled, in particular by the control of the emissions of the protocols of the network layer, by the control of concurrent access latency to the network interface of the nodes and by mastering the kernel and application latency induced on the nodes of the network.
  • the software modules use the standard socket application programming interface, in particular for the implementation of the UDP protocol.
  • management by service is carried out as follows:
  • This task has the highest priority; and,
  • This task has the minimum priority.
  • the diagnostic equipment When the diagnostic equipment wishes to send a message, in particular an Ethernet frame destined for a node of the network whose IP address it knows, also known as an IP address, it queries its ARP buffer for an entry corresponding to the IP address of the target machine.
  • An ARP buffer also called an ARP cache, is a set of pairs (IP address, physical address) contained in the memory of a computer using the ARP protocol, ie a memory space in which a table is stored. listing physical address - IP address of network nodes belonging to the same logical network.
  • the physical address is here the MAC address (acronym for "Media Access Control" in English terminology) of the network node.
  • the operating system informs the corresponding destination physical address to send the Ethernet frame.
  • the ARP mechanism stops here in this case.
  • the diagnostic equipment places its transmission on hold and makes an ARP request, notably according to the broadcast mode.
  • This request is of type "What is the physical address corresponding to the address IP addresslP? Answer to Physics address. Since a query flag is broadcast, all nodes connected to the network through the switch receive the request. The node concerned then responds to the originator of the ARP request.
  • the ARP frames automatically generated by the operating system are blocked by inserting permanent (static) entries into the ARP buffer.
  • the buffer ARP is filled by means of permanent inputs, in particular by means of a POSIX programming interface.
  • an identification request is first transmitted in multicast mode by the diagnostic equipment (server), in particular by the server diagnostic module, before any unicast messages are sent to client nodes.
  • This request is sent to an agreed multicast address, on which the different client nodes have subscribed beforehand. From the identification responses of the network nodes present, it consists of the pairs of addresses (physical address, address
  • IP IP
  • each pair (physical address, IP address) is placed as a permanent input, that is to say statically in the ARP cache before sending any diagnostic message, these messages can be requests or some answers. Then, by construction, no ARP type message is issued by the diagnostic equipment or by the nodes.
  • the diagnostic equipment especially the server diagnostics module, sends messages preferably in unicast mode, the multicast mode being nevertheless authorized since it does not generate ARP traffic.
  • the broadcast diagnostic message broadcast is prohibited.
  • addressing in unicast mode is performed by the diagnostic task cyclically on the clients, for example a message for a client per cycle, with a delay between each transmission.
  • an asynchronous end-of-service message must be issued by the diagnostics server before the diagnostic module completes execution to prevent any subsequent transmission of an ICMP (Internet Control Message Protocol) message.
  • ICMP Internet Control Message Protocol
  • the client diagnostic module makes the IGMP layer (acronym for "Internet Group Management” active) Protocol "in English terminology) at initialization so as to manage the multicast.
  • the client diagnostic module issues a subscription request to an agreed specific multicast address, in particular the diagnostic IP address to configure the switch redirection table for the management of multicast groups, so as to avoid the broadcast broadcast by the switch of a multicast packet which it must route and which has no subscriber interface to this address.
  • the pair of addresses (physical address, IP address) of the diagnostic equipment (server) is obtained by the client nodes during the identification request, in particular by explicit duplication of the MAC / IP pair
  • the network nodes including the client diagnostic modules, send messages in unicast mode. These messages are sent, in synchronous mode, on receipt of a request, and are transmitted periodically when the asynchronous communication mode is activated (TRAP mode).
  • TRIP mode asynchronous communication mode
  • the programming layers of the system and the interactions with the client and server diagnostic modules are now described with reference to Figure 2.
  • the programming of the client and server diagnostics modules uses a POSIX programming interface located in the operating system user space.
  • the kernel space includes, at the lower end of the hierarchy of protocol layers, a network driver (called “driver” in English terminology). Saxon) on which a network layer relies, including an IGMP layer, an ICMP layer, an IP layer and an ARP layer.
  • the network layer and based on the ICMP layer or the IP layer is the UDP layer forming part of the transport layer.
  • Reference 21 illustrates the communication between the client diagnostics module and the IGMP layer, via the POSIX interface, in order to subscribe to a multicast IP address.
  • Reference 22 illustrates the communication between the client diagnostic module or the server diagnostic module and the UDP layer, via the POSIX interface, for asynchronous message transmission and reception.
  • Reference 23 illustrates the communication between the client diagnostic module or the server diagnostic module and the ARP layer, via the POSIX interface, in order to add permanent entries to the ARP cache.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Test And Diagnosis Of Digital Computers (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Computer And Data Communications (AREA)

Abstract

L'invention a pour objet des procédés et des dispositifs d'identification et de communication non intrusifs entre un nœud serveur (25) et au moins un nœud client (10) dans un réseau de communication (5). Un message d'identification est tout d'abord émis à destination d'au moins un nœud client, le message d'identification comprenant au niveau applicatif une duplication des données d'adressage (l'adresse physique et l'adresse Internet dudit nœud serveur) par ailleurs contenue dans les couches MAC et IP. La réception d'au moins un couple d'adresses d'au moins un nœud client en réponse à l'émission d'un message d'identification, un couple d'adresses d'un nœud client comprenant une adresse physique et une adresse Internet (selon la même stratégie de duplication), permet d'identifier auprès du serveur le nœud client. De façon similaire, l'invention permet d'identifier, dans un nœud client, au moins un nœud serveur dans un réseau.

Description

Procédés et dispositifs pour la communication de données de diagnostic dans un réseau de communication temps réel
La présente invention concerne des procédés et des dispositifs d'identification et de communication non intrusif entre un nœud serveur et plusieurs nœuds clients au sein d'un réseau commuté temps réel.
Un réseau de type « switch fabric » est basé sur une architecture commutée, c'est-à-dire que les équipements terminaux chargés de l'émission et de la réception des données s'organisent autour des commutateurs chargés du transport de ces données, à N entrées et N sorties. La communication est réalisée par l'envoi et la réception de paquets, ces derniers étant émis en parallèle.
De manière plus générale, l'invention concerne, dans un réseau de traitement de données en temps réel comprenant au moins un serveur et au moins un client, les principes régissant la communication de données de diagnostic entre ces éléments du réseau de sorte à être non intrusif sur la communication temps réel circulant par ailleurs sur ce même réseau.
L'invention s'applique notamment dans un réseau de simulation de composants d'un aéronef en temps réel, où un diagnostic de ces composants doit être effectué sans perturber le réseau de simulation.
La simulation de composants d'un aéronef est utilisée pour assurer le développement et l'intégration des systèmes électroniques et informatiques embarqués dans les aéronefs, en particulier avant le premier vol. L'architecture de simulation comprend une pluralité de terminaux aussi appelés nœuds du réseau, chacun de ces terminaux étant apte à réaliser les calculs de simulation ou constituant l'interface électronique avec l'environnement réel, permettant de vérifier le fonctionnement des équipements réels de l'aéronef. Ainsi, cette architecture comprend notamment un terminal de simulation apte à émettre des données selon une séquence synchrone selon le principe requête / réponse. Des nœuds du réseau sont constitués des calculateurs de simulation et des cartes d'entrée / sortie d'interfaces électroniques.
L'échange des données entre les différents nœuds du réseau est réalisé sur un port UDP (acronyme de « User Datagram Protocol » en terminologie anglo-saxonne) spécifique et en temps réel, c'est-à-dire que la simulation des comportements des équipements est réalisée à la vitesse de leur déroulement réel.
Afin de réaliser des diagnostics sur une telle architecture réseau, il peut être connecté à tout moment au réseau un équipement de diagnostic apte à identifier les dysfonctionnements des différents nœuds du réseau.
Toutefois, sans une phase d'apprentissage spécifique de la topologie du réseau, les échanges de messages génèrent un trafic supplémentaire sur le réseau entre l'équipement de diagnostic et les différents nœuds du réseau. Les messages échangés sont par typiquement des messages ARP (acronyme de « Address Resolution Protocol » en terminologie anglo-saxonne).
Une telle mise en œuvre présente l'inconvénient qu'un grand nombre de messages ARP entre l'équipement de diagnostic et les nœuds du réseau sont transmis ce qui perturbe l'exécution en temps réel de la simulation. La présente invention a pour objet de remédier à au moins un des inconvénients des techniques et processus de l'art antérieur précité. Pour ce faire, l'invention propose notamment un procédé et un dispositif d'identification dynamique, dans un nœud serveur, d'au moins un nœud client dans un réseau de communication et un procédé et un dispositif d'identification, dans un nœud client, d'un nœud serveur dans un réseau de communication aptes à respecter des contraintes fortes telles que la non perturbation du déroulement en temps réel de la simulation.
L'invention a ainsi pour objet un procédé d'identification, dans un nœud serveur connecté à un réseau, d'au moins un nœud client connecté au réseau, le procédé comprenant les étapes suivantes, - une étape d'émission d'un message d'identification à au moins un nœud client, le message d'identification comprenant l'adresse physique et l'adresse Internet dudit nœud serveur, et
- une étape de réception d'au moins un message contenant le couple d'adresses d'au moins un nœud client en réponse à l'étape d'émission d'un message d'identification, un couple d'adresses d'un nœud client comprenant une adresse physique (MAC) et une adresse Internet (IP).
Le procédé selon l'invention permet ainsi de déterminer dynamiquement la topologie du réseau sans nécessiter de connexion point à point ni la connaissance préalable de sa définition topologique. Ce procédé permet de respecter des contraintes de non intrusion permettant le déroulement de simulations en temps réel.
De façon avantageuse, ledit au moins un couple d'adresses de nœud client est mémorisé statiquement dans une table de correspondance entre une adresse physique et une adresse Internet, telle que la table ARP du système d'exploitation, dans ledit nœud serveur pour contrôler les messages générés par le système d'exploitation, c'est-à-dire par exemple pour contraindre les mécanismes ARP.
Selon un mode de réalisation particulier, l'émission dudit message d'identification est réalisée en mode multicast.
L'invention a aussi pour objet un procédé d'échange de données de diagnostic dans un réseau entre un nœud du réseau et un terminal de diagnostic connecté au réseau, le procédé comprenant les étapes suivantes,
- identification d'au moins un nœud du réseau selon le procédé d'identification décrit précédemment ; et,
- transmission d'une commande de diagnostic audit au moins un nœud identifié du réseau.
Le procédé selon l'invention permet ainsi d'échanger des données de diagnostic sans perturber le fonctionnement temps réel du réseau tout en gardant des caractéristiques standard de réseau. L'invention a également pour objet un procédé d'identification, dans un nœud client connecté à un réseau, d'un nœud serveur connecté au réseau, le procédé comprenant les étapes suivantes,
- une étape de réception d'un message d'identification provenant dudit nœud serveur, le message d'identification comprenant l'adresse physique
(MAC) et l'adresse Internet (IP) dudit nœud serveur, et
- une étape d'émission audit nœud serveur d'un message contenant le couple d'adresses dudit nœud client en réponse à l'étape de réception du message d'identification, le couple d'adresses comprenant une adresse physique (MAC) et une adresse Internet (IP) du nœud client.
De façon avantageuse, ledit au moins un couple d'adresses du nœud serveur est mémorisé statiquement dans une table de correspondance entre une adresse physique et une adresse Internet, telle que la table ARP du système d'exploitation, dans ledit nœud client. L'invention a aussi pour objet un procédé d'échange de données de diagnostic, dans un nœud client connecté à un réseau, caractérisé en ce qu'il comprend les étapes suivantes,
- identification d'au moins un nœud serveur selon le procédé d'identification décrit précédemment ; et, - activation d'une tâche de gestion de données de diagnostic à la réception d'une commande de diagnostic selon l'état d'activation d'une tâche de gestion de données de simulation.
Le procédé selon l'invention met ainsi en œuvre une gestion par priorité des services pour limiter l'intrusion des opérations de diagnostic sur des opérations de simulations.
Avantageusement, les tâches de gestion de données de diagnostic et de simulation utilisent des ports différents.
L'invention a aussi pour objet un programme d'ordinateur comprenant des instructions adaptées à la mise en œuvre de chacune des étapes des procédés décrits précédemment. L'invention a également pour objet un dispositif comprenant des moyens adaptés à la mise en œuvre de chacune des étapes des procédés décrits précédemment.
D'autres avantages, buts et caractéristiques de la présente invention ressortent de la description détaillée qui suit, faite à titre d'exemple non limitatif, au regard des dessins annexés dans lesquels:
- la figure 1 illustre une architecture réseau de simulation intégrant un terminal de diagnostic conformément à l'invention ; et
- la figure 2 présente les couches de programmation du système et les interactions avec les modules de diagnostic client et serveur conformément à l'invention.
Conformément à l'invention, le diagnostic d'un réseau de simulation de composants, notamment de composants avioniques, est centralisé et intégré. Cette simulation est basée sur des contraintes temps réel fortes de sorte que celle-ci ne doit nullement être perturbée afin de simuler au mieux le comportement réel des composants.
Les fonctionnalités du diagnostic sont notamment les suivantes :
- détermination des nœuds réseau qui sont présents, notamment de façon centralisée, c'est-à-dire sans avoir une connexion point à point directe avec chacun des équipements d'interface électronique utilisés ;
- surveillance en temps réel avec la possibilité de déporter l'interface graphique de surveillance et de diagnostic ;
- établir la cartographie des nœuds du réseau, notamment la liste des équipements du réseau et leur configuration (logiciels, matériels constitutifs et paramétrage) ;
- consulter ou modifier le paramétrage des nœuds du réseau ;
- surveiller les paramètres internes et élaborer des statistiques ;
- forcer des voies d'entrée/sortie et d'autres paramètres ;
- enregistrer en temps réel des paramètres, notamment en mémoire volatile ; - enregistrer des contextes de panne, notamment en mémoire non volatile ;
- obtenir des tables de paramétrage, de configuration, de contextes de panne et d'enregistrement ; et, - gérer des statistiques avancées, telles que la durée de traitement des messages de simulation, de la pile IP (acronyme de « Internet Protocol » en terminologie anglo-saxonne) et de la pile de messages.
Selon un mode de réalisation particulier, le système de diagnostic est intégré au réseau de simulation et une seule connectique réseau est nécessaire. En outre, la fonction diagnostic est centralisée.
Il n'y a pas de charge des terminaux supplémentaires et l'investigation est réalisée en mode opérationnel sans déconnecter les nœuds. Pour ce faire, selon un mode de réalisation de l'invention, le réseau de simulation, illustré en Figure 1 , comprend un ensemble de nœuds réseau aptes à fonctionner ensemble afin de réaliser la simulation de composants, notamment de composants avioniques connectés entre eux dans un réseau commuté de type switch fabric.
Ainsi, chacun des nœuds 10 du réseau 5 est connecté à un commutateur principal 15. Ces nœuds 10 sont notamment des nœuds de calcul, des cartes d'entrée / sortie, des nœuds intermédiaires et des concentrateurs.
A ce réseau 5 sont connectés un calculateur principal de simulation 20 (« host » en terminologie anglo-saxonne) sur le commutateur principal 15 et un équipement de diagnostic 25. Afin de respecter au mieux le temps réel, le réseau est un réseau haut débit, par exemple un réseau de cent méga bits par seconde ou d'un giga bits par seconde.
Conformément à l'invention, un module, notamment un module logiciel (appelé « plugin » en terminologie anglo-saxonne) est installé dans différents nœuds du réseau à diagnostiquer, appelé module de diagnostic client, et dans l'équipement de diagnostic 25, appelé module de diagnostic serveur.
Ce module logiciel est un programme intégré à l'applicatif opérationnel de chaque nœud de l'interface électronique. Conformément à l'invention, une mise en œuvre particulière de la couche message est réalisée en s'appuyant autant que possible sur les couches de programmation POSIX (acronyme de « Portable Operating System
Interface » en terminologie anglo-saxonne) du système d'exploitation des nœuds et de l'équipement de diagnostic 25. En outre, l'équipement serveur de diagnostic doit réaliser, au démarrage, l'apprentissage de la topologie du réseau. Cet apprentissage est dynamique, c'est-à-dire qu'il est obtenu par interrogation des différents nœuds du réseau, notamment par l'émission d'un message spécifique d'identification et par traitement des messages réponses associées. L'échange de messages peut être réalisée selon un mode synchrone ou un mode asynchrone (aussi appelé mode « TRAP » en terminologie anglo-saxonne).
Selon un mode de réalisation synchrone, une requête de diagnostic est émise par le terminal de diagnostic (nœud serveur) et une réponse est émise par le nœud diagnostiqué (nœud client) à l'issue du traitement.
Selon un mode de réalisation asynchrone, un traitement est activé au moyen d'un message unicast, c'est-à-dire selon un mode point à point, ou d'un message multicast, c'est-à-dire d'un message destiné à un groupe de nœuds réseau. L'obtention des données de diagnostic est dans ce cas réalisée périodiquement et automatiquement selon une période programmable
(émission de messages spontanée et périodique par les nœuds clients configurés dans ce mode).
Conformément à l'invention, l'intrusion du diagnostic sur le fonctionnement temps réel de la simulation est maîtrisé, notamment par le contrôle des émissions des protocoles de la couche réseau, par la maîtrise de la latence d'accès concurrent à l'interface réseau des nœuds et par la maîtrise de la latence noyau et applicative induite sur les nœuds du réseau.
Conformément à l'invention, les modules logiciels utilisent l'interface de programmation d'application socket standard, notamment pour la mise en œuvre du protocole UDP.
En outre, sur chacun des nœuds du réseau, notamment sur les nœuds d'interfaces électroniques, une gestion par service est réalisée de la façon suivante :
- une tâche gérant un port UDP spécifique pour les données de simulation. Cette tâche possède la priorité maximale ; et,
- une tâche gérant un port UDP spécifique pour les données de diagnostic. Cette tâche possède la priorité minimale.
En outre, la fragmentation des paquets IP lors de l'émission de messages vers des nœuds du réseau est interdite. Toute fragmentation de message doit donc être réalisée au niveau de la couche message afin de ne pas charger la pile IP, évitant de la sorte le risque de latence du noyau, ce dernier mettant en œuvre un sémaphore (aussi appelé « mutex » pour
« Mutual Exclusion » en terminologie anglo-saxonne) d'accès à l'unique interface réseau de chaque nœud. De plus, l'émission de messages fragmentés est étalée temporellement, par exemple un message par cycle, soit toutes les 10 ms si la durée d'un cycle est de 10 ms.
Lorsque l'équipement de diagnostic souhaite émettre un message, notamment une trame Ethernet à destination d'un nœud du réseau dont il connaît l'adresse Internet aussi appelée adresse IP, il interroge sa mémoire tampon ARP à la recherche d'une entrée correspondant à l'adresse IP de la machine cible.
Une mémoire tampon ARP, aussi appelée un cache ARP, est un ensemble de couples (adresse IP, adresse physique) contenu dans la mémoire d'un ordinateur utilisant le protocole ARP, c'est à dire un espace mémoire dans lequel est enregistrée une table listant des correspondances adresse physique - adresse IP de nœuds du réseau appartenant au même réseau logique. L'adresse physique est ici l'adresse MAC (acronyme de « Media Access Control » en terminologie anglo-saxonne) du nœud réseau.
Si l'adresse IP du destinataire est présente dans le cache ARP de l'émetteur, le système d'exploitation renseigne l'adresse physique de destination correspondante pour envoyer la trame Ethernet. Le mécanisme ARP s'arrête ici dans ce cas.
Dans le cas contraire, si l'adresse IP est absente de la mémoire tampon de l'émetteur, l'équipement de diagnostic place son émission en attente et effectue une requête ARP, notamment selon le mode broadcast. Cette requête est de type « quelle est l'adresse physique correspondant à l'adresse IP adresselP ? Répondez à adressePhysique ». Puisqu'une teille requête est émise en mode broadcast, tous les noeuds connectés au réseau à travers le commutateur reçoivent la requête. Le nœud concerné répond alors à l'émetteur de la requête ARP.
Cette solution présente l'inconvénient de perturber le réseau de simulation temps réel.
Pour ne pas perturber la communication temps réel des données de simulation, les trames ARP générées automatiquement par le système d'exploitation sont bloquées en insérant des entrées permanentes (statiques) dans la mémoire tampon ARP.
Ainsi, conformément à l'invention, la mémoire tampon ARP est remplie au moyen d'entrées permanentes, notamment au moyen d'une interface de programmation POSIX. Pour ce faire, une requête d'identification est tout d'abord émise en mode multicast par l'équipement de diagnostic (serveur), notamment par le module de diagnostic serveur, avant toute émission de messages unicast à destination de nœuds clients. Cette requête est émise à destination d'une adresse multicast convenue, sur laquelle les différents nœuds clients se sont préalablement abonnés. A partir des réponses d'identification des nœuds du réseau présents, il est constitué des couples d'adresses (adresse physique, adresse
IP). Ceci est réalisé par exemple par duplication explicite des couples (adresse physique, adresse IP) dans la couche message de la réponse d'identification. De la sorte, la topologie du réseau est constituée.
En outre, chaque couple (adresse physique, adresse IP) est placé en tant qu'entrée permanente, c'est-à-dire de façon statique dans le cache ARP avant toute émission de message de diagnostic, ces messages pouvant être des requêtes ou des réponses. Ensuite, par construction, aucun message de type ARP n'est émis par l'équipement de diagnostic ou par les nœuds.
Au cours du diagnostic, l'équipement de diagnostic, notamment le module de diagnostic serveur, émet des messages de préférence en mode unicast, le mode multicast étant néanmoins autorisé puisque ne générant pas de traffic ARP. Toutefois, afin d'éviter l'émission d'un grand nombre de messages pouvant « inonder » le réseau et donc perturber la simulation en temps réel, l'émission de messages de diagnostic en mode broadcast est proscrite.
Selon un mode de réalisation particulier sur le nœud serveur, l'adressage en mode unicast est réalisé par la tâche diagnostic de manière cyclique sur les clients, par exemple un message pour un client par cycle, avec une temporisation entre chaque émission.
En outre, en mode asynchrone, un message de fin du mode asynchrone doit être émis par le serveur de diagnostic avant la fin d'exécution du module de diagnostic pour éviter toute émission ultérieure de message ICMP (acronyme de « Internet Control Message Protocol » en terminologie anglo-saxonne) par les clients concernés (c'est à dire des clients dont le mode TRAP est activé), notamment l'émission de message « ICMP port unreachable ». Ce protocole est mis en œuvre pour véhiculer des messages de contrôle et d'erreur. Du côté des nœuds clients du réseau, le module de diagnostic client rend actif la couche IGMP (acronyme de « Internet Group Management Protocol » en terminologie anglo-saxonne) à l'initialisation de sorte à gérer le multicast.
A l'initialisation, le module de diagnostic client émet une requête d'abonnement à une adresse multicast spécifique convenue, notamment l'adresse IP de diagnostic pour configurer la table de redirection du commutateur pour la gestion des groupes multicast, de sorte à éviter l'émission en mode broadcast par le commutateur d'un paquet multicast qu'il doit router et qui n'a aucune interface abonnée à cette adresse.
En outre, afin d'empêcher toute émission de message ARP, le couple d'adresses (adresse physique, adresse IP) de l'équipement de diagnostic (serveur) est obtenu par les nœuds clients lors de la requête d'identification, notamment par duplication explicite du couple MAC / IP
(adresse physique, adresse IP) dans la couche message de la requête d'identification, puis est placé en tant qu'entrée permanente, c'est-à-dire de façon statique, dans le cache ARP avant toute émission unicast de message de diagnostic.
Au cours du diagnostic, les nœuds du réseau, notamment les modules de diagnostic client, émettent des messages en mode unicast. Ces messages sont émis, en mode synchrone, sur réception d'une requête, et sont émis de façon périodique quand le mode de communication asynchrone est activé (mode TRAP).
Il est maintenant décrit, en référence à la Figure 2, les couches de programmation du système et les interactions avec les modules de diagnostic client et serveur. La programmation des modules de diagnostic client et serveur utilise une interface de programmation POSIX située dans l'espace utilisateur du système d'exploitation.
Cet espace est situé, selon la hiérarchie des couches de communication, au dessus de l'espace noyau. L'espace noyau comprend, au plus bas de la hiérarchie des couches protocolaires, un pilote réseau (appelé « driver » en terminologie anglo- saxonne) sur lequel une couche réseau s'appuie, comprenant notamment une couche IGMP, une couche ICMP, une couche IP et une couche ARP.
Au dessus de la couche réseau et s'appuyant sur la couche ICMP ou sur la couche IP se trouve la couche UDP formant en partie la couche transport.
La référence 21 illustre la communication entre le module de diagnostic client et la couche IGMP, via l'interface POSIX, afin de réaliser l'abonnement à une adresse IP multicast.
La référence 22 illustre la communication entre le module de diagnostic client ou le module de diagnostic serveur et la couche UDP, via l'interface POSIX, pour l'émission et la réception de message asynchrone.
La référence 23 illustre la communication entre le module de diagnostic client ou le module de diagnostic serveur et la couche ARP, via l'interface POSIX, afin de réaliser l'ajout d'entrées permanentes dans le cache ARP.
Naturellement, pour satisfaire des besoins spécifiques, une personne compétente dans le domaine de l'invention pourra appliquer des modifications dans la description précédente.

Claims

REVENDICATIONS
1. Procédé d'identification, dans un nœud serveur (25) connecté à un réseau (5), d'au moins un nœud client (10) connecté au réseau, caractérisé en ce qu'il comprend les étapes suivantes,
- une étape d'émission d'un message d'identification à au moins un nœud client, le message d'identification comprenant l'adresse physique et l'adresse Internet dudit nœud serveur ;
- une étape de réception d'au moins un message contenant le couple d'adresses d'au moins un nœud client en réponse à l'étape d'émission d'un message d'identification, ledit couple d'adresses, comprenant une adresse physique et une adresse Internet, étant explicitement dupliqué dans la partie des données applicatives dudit message reçu ; et
- une étape de mémorisation statique dudit couple d'adresses dans une table de correspondance entre une adresse physique et une adresse Internet dans ledit nœud serveur.
2. Procédé d'identification selon la revendication précédente caractérisé en ce que l'émission dudit message d'identification est réalisée en mode multicast.
3. Procédé d'échange de données de diagnostic dans un réseau entre un nœud du réseau et un terminal de diagnostic connecté au réseau, le procédé étant caractérisé en ce qu'il comprend les étapes suivantes, - identification d'au moins un nœud du réseau selon l'une quelconque des revendications précédentes ; et,
- transmission d'une commande de diagnostic audit au moins un nœud identifié du réseau.
4. Procédé d'identification, dans un nœud client (10) connecté à un réseau (5), d'un nœud serveur (25) connecté au réseau, caractérisé en ce qu'il comprend les étapes suivantes, - une étape de réception d'un message d'identification provenant dudit nœud serveur, le message d'identification comprenant l'adresse physique et l'adresse Internet dudit nœud serveur ;
- une étape de mémorisation statique desdites adresses physique et Internet dudit nœud serveur dans une table de correspondance entre une adresse physique et une adresse Internet dans ledit nœud client ; et
- une étape d'émission audit nœud serveur d'un message contenant le couple d'adresses dudit nœud client en réponse à l'étape de réception du message d'identification, ledit couple d'adresses dudit nœud client, comprenant une adresse physique et une adresse Internet dudit nœud client, étant explicitement dupliqué dans la partie des données applicatives dudit message émis.
5. Procédé d'échange de données de diagnostic, dans un nœud client connecté à un réseau, caractérisé en ce qu'il comprend les étapes suivantes,
- identification d'au moins un nœud serveur selon la revendication précédente ; et,
- activation d'une tâche de gestion de données de diagnostic à la réception d'une commande de diagnostic selon l'état d'activation d'une tâche de gestion de données de simulation.
6. Procédé selon la revendication précédente caractérisé en ce que les tâches de gestion de données de diagnostic et de simulation utilisent des ports spécifiques différents.
7. Procédé selon l'une quelconque des revendications précédentes selon lequel la fragmentation desdits messages échangés est réalisée au niveau de la couche message.
8. Procédé selon l'une quelconque des revendications précédentes mettant en œuvre le protocole de communication UDP et la couche de programmation POSIX.
9. Programme d'ordinateur comprenant des instructions adaptées à la mise en œuvre de chacune des étapes du procédé selon l'une quelconque des revendications précédentes.
10. Dispositif comprenant des moyens adaptés à la mise en œuvre de chacune des étapes du procédé selon l'une quelconque des revendications 1 à 8.
PCT/FR2008/051104 2007-06-28 2008-06-19 Procédés et dispositifs por la communication de données de diagnostic dans un réseau de communication temps réel WO2009007570A2 (fr)

Priority Applications (6)

Application Number Priority Date Filing Date Title
BRPI0811800-0A2A BRPI0811800A2 (pt) 2007-06-28 2008-06-19 "processo de identificação em um nó servidor conectado a uma rede, processo de trocas de dados de diagnóstico em uma rede, processo de identificação em um nó cliente conectado a uma rede, processo de troca de dados de diagnóstico em um nó cliente conectado a uma rede, programa de computador e dispositivo de identificação"
US12/666,447 US8868708B2 (en) 2007-06-28 2008-06-19 Methods and devices for communicating diagnosis data in a real time communication network
CN200880022056.XA CN101785283B (zh) 2007-06-28 2008-06-19 实时通信网络中用于诊断数据的通信的方法及设备
EP08806038.9A EP2168358B1 (fr) 2007-06-28 2008-06-19 Procédés et dispositifs por la communication de données de diagnostic dans un réseau de communication temps réel
CA2691266A CA2691266C (fr) 2007-06-28 2008-06-19 Procedes et dispositifs por la communication de donnees de diagnostic dans un reseau de communication temps reel
JP2010514054A JP5612468B2 (ja) 2007-06-28 2008-06-19 リアルタイム通信ネットワークにおける診断データの通信のための方法と装置

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0756129A FR2918232B1 (fr) 2007-06-28 2007-06-28 Procedes et dispositifs pour la communication de donnees de diagnostic dans un reseau de communication temps reel
FR0756129 2007-06-28

Publications (2)

Publication Number Publication Date
WO2009007570A2 true WO2009007570A2 (fr) 2009-01-15
WO2009007570A3 WO2009007570A3 (fr) 2009-11-05

Family

ID=39166671

Family Applications (2)

Application Number Title Priority Date Filing Date
PCT/FR2008/051104 WO2009007570A2 (fr) 2007-06-28 2008-06-19 Procédés et dispositifs por la communication de données de diagnostic dans un réseau de communication temps réel
PCT/IB2008/002242 WO2009001218A2 (fr) 2007-06-28 2008-08-28 Carte électronique apte á exécuter une commande provenant d'un système de simulation et une commande provenant d'un module de diagnostic et procédé de simulation associé

Family Applications After (1)

Application Number Title Priority Date Filing Date
PCT/IB2008/002242 WO2009001218A2 (fr) 2007-06-28 2008-08-28 Carte électronique apte á exécuter une commande provenant d'un système de simulation et une commande provenant d'un module de diagnostic et procédé de simulation associé

Country Status (9)

Country Link
US (2) US8868708B2 (fr)
EP (2) EP2168358B1 (fr)
JP (1) JP5612468B2 (fr)
CN (2) CN101785283B (fr)
BR (1) BRPI0811800A2 (fr)
CA (2) CA2691266C (fr)
FR (1) FR2918232B1 (fr)
RU (1) RU2010102716A (fr)
WO (2) WO2009007570A2 (fr)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8236082B2 (en) 2009-06-19 2012-08-07 Hollingsworth & Vose Company Flutable fiber webs with high dust holding capacity
DE102009041599A1 (de) 2009-09-15 2011-04-14 Airbus Operations Gmbh Steuervorrichtung, Ein-/Ausgabevorrichtung, Verbindungsschaltevorrichtung und Verfahren für ein Flugzeug-Steuersystem
US9158788B2 (en) * 2009-12-16 2015-10-13 International Business Machines Corporation Scalable caching of remote file data in a cluster file system
CA2852080C (fr) * 2013-05-22 2018-02-20 Air China Limited Appareil d'essai et procede d'essai fonde sur une unite d'acquisition des donnees numeriques en vol
CN104184758B (zh) * 2013-05-22 2017-12-12 中国国际航空股份有限公司 一种航空器报文触发逻辑的测试平台和测试方法
JP6168247B2 (ja) * 2015-01-29 2017-07-26 フーベイ ユニバーシティ フォー ナショナリティズ 光起電力発電システムおよびその故障検出方法
EP3144757A1 (fr) * 2015-09-18 2017-03-22 Siemens Aktiengesellschaft Procede de simulation d'une commande reelle pour un processus industriel, installation ou machine et systeme de simulation destine a executer un tel procede de simulation
CN106713142B (zh) * 2015-11-17 2019-12-24 陕西重型汽车有限公司 在can总线上传输ip报文的方法及利用can总线网络构建的ip局域网
CN112532410B (zh) * 2019-09-18 2023-10-31 无锡江南计算技术研究所 大规模互连网络Trap快速响应方法
JP7237176B2 (ja) * 2019-10-08 2023-03-10 日立Astemo株式会社 通信システム、電子制御装置及び通信方法

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH08237285A (ja) 1995-02-24 1996-09-13 Mitsubishi Electric Corp インターネットプロトコルアドレスの自動設定方法

Family Cites Families (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5111402A (en) * 1990-01-19 1992-05-05 Boeing Company Integrated aircraft test system
US5023791A (en) * 1990-02-12 1991-06-11 The Boeing Company Automated test apparatus for aircraft flight controls
US5260874A (en) * 1990-09-05 1993-11-09 The Boeing Company Aircraft flight emulation test system
IL112660A (en) * 1994-03-31 1998-01-04 Minnesota Mining & Mfg System integrating active and simulated decision- making processes
US5493672A (en) 1994-05-16 1996-02-20 Sun Microsystems, Inc. Concurrent simulation of host system at instruction level and input/output system at logic level with two-way communication deadlock resolution
US5546562A (en) * 1995-02-28 1996-08-13 Patel; Chandresh Method and apparatus to emulate VLSI circuits within a logic simulator
JPH08263415A (ja) * 1995-03-22 1996-10-11 Sumitomo Metal Ind Ltd データ処理システム
US5812824A (en) * 1996-03-22 1998-09-22 Sun Microsystems, Inc. Method and system for preventing device access collision in a distributed simulation executing in one or more computers including concurrent simulated one or more devices controlled by concurrent one or more tests
FI103544B1 (fi) * 1996-03-25 1999-07-15 Nokia Telecommunications Oy Menetelmä osoitteiden määrittämiseksi tietoliikenneverkon solmuissa
GB2330034A (en) * 1997-10-01 1999-04-07 Northern Telecom Ltd A narrowband to broadband interface for a communications system
US7392431B2 (en) * 1999-02-19 2008-06-24 Texas Instruments Incorporated Emulation system with peripherals recording emulation frame when stop generated
US7020697B1 (en) * 1999-10-01 2006-03-28 Accenture Llp Architectures for netcentric computing systems
CA2333495A1 (fr) * 2000-01-31 2001-07-31 Telecommunications Research Laboratory Service de reseau informatique a protocole internet
US7047176B2 (en) * 2000-05-05 2006-05-16 Fujitsu Limited Method and system for hardware simulation
US20030051026A1 (en) * 2001-01-19 2003-03-13 Carter Ernst B. Network surveillance and security system
US8218555B2 (en) * 2001-04-24 2012-07-10 Nvidia Corporation Gigabit ethernet adapter
US7260517B2 (en) * 2001-06-17 2007-08-21 Brian Bailey Synchronization of multiple simulation domains in an EDA simulation environment
US7340740B2 (en) 2003-04-22 2008-03-04 International Business Machines Corporation Cooperatively multitasking in an interrupt free computing environment
WO2005032073A1 (fr) * 2003-09-24 2005-04-07 Mitsubishi Denki Kabushiki Kaisha Systeme de reseau etendu et reseau mobile a 2 couches
JP2005168863A (ja) 2003-12-12 2005-06-30 Aruze Corp 遊技機
CA2457368C (fr) * 2004-02-11 2013-01-08 Solutioninc Limited Serveur, systeme et methode offrant l'acces a un reseau public par l'intermediaire d'un reseau interne d'un operateur multisystemique
JP2006020157A (ja) * 2004-07-02 2006-01-19 Hitachi Ltd ノード情報収集装置
JP2006048402A (ja) 2004-08-05 2006-02-16 Yokogawa Electric Corp コントローラ
JP4661520B2 (ja) * 2005-10-24 2011-03-30 セイコーエプソン株式会社 ウェブサーバ機能を有するネットワークデバイスを介したネットワークデバイスの検索
FR2894694A1 (fr) * 2005-12-09 2007-06-15 St Microelectronics Sa Procede et dispositif de mise au point d'un programme execute par un processeur multitache

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH08237285A (ja) 1995-02-24 1996-09-13 Mitsubishi Electric Corp インターネットプロトコルアドレスの自動設定方法

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
NARTEN ET AL.: "Neighbor discovery for IP version 6 (IPv6", INTERNET ENGINEERING TASK FORCE, IETF, CH, vol. IPV6, no. 11, March 2007 (2007-03-01)
WIGET ET AL.: "Dynamic VPLS solution over multicast enabled IP backbone", IETF STANDARD WORKING DRAFT, INTERNET ENGINEERING TASK FORCE, IETF, CH, December 1999 (1999-12-01)

Also Published As

Publication number Publication date
EP2160682A2 (fr) 2010-03-10
CN101715577A (zh) 2010-05-26
US8402315B2 (en) 2013-03-19
CN101785283A (zh) 2010-07-21
BRPI0811800A2 (pt) 2014-11-11
JP5612468B2 (ja) 2014-10-22
FR2918232B1 (fr) 2010-11-26
WO2009001218A3 (fr) 2009-11-26
US8868708B2 (en) 2014-10-21
EP2168358B1 (fr) 2013-04-17
CA2691266A1 (fr) 2009-01-15
CA2691266C (fr) 2016-05-10
WO2009007570A3 (fr) 2009-11-05
EP2160682B1 (fr) 2012-04-25
RU2010102716A (ru) 2011-08-10
EP2168358A2 (fr) 2010-03-31
CA2691565A1 (fr) 2008-12-31
CN101785283B (zh) 2014-06-11
WO2009001218A2 (fr) 2008-12-31
JP2010531602A (ja) 2010-09-24
US20100257407A1 (en) 2010-10-07
US20100198576A1 (en) 2010-08-05
FR2918232A1 (fr) 2009-01-02

Similar Documents

Publication Publication Date Title
EP2168358B1 (fr) Procédés et dispositifs por la communication de données de diagnostic dans un réseau de communication temps réel
EP2137836B1 (fr) Procede et dispositif de gestion de canaux de communication pour des echanges de donnees a partir d'un aeronef
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
US7430584B1 (en) Data forwarding storage
CN101999120B (zh) 用于启用直接访问和安全评估共享的硬件接口
EP0951155A1 (fr) Procédé et système d'administration de réseaux et de systèmes
Femminella et al. An enabling platform for autonomic management of the future internet
WO2017050591A1 (fr) Equipement pour offrir des services de résolution de noms de domaine
EP2791798B1 (fr) Bus logiciel
Ayyalasomayajula et al. {LocAP}: Autonomous millimeter accurate mapping of {WiFi} infrastructure
EP1303812B1 (fr) Procede de transmission d'un agent mobile dans un reseau; emetteur, recepteur, et agent mobile associes
WO2021152262A1 (fr) Procede de surveillance de donnees echangees sur un reseau et dispositif de detection d'intrusions
WO2019086783A1 (fr) Procédé d'application d'un correctif sur une fonction réseau virtualisée à mettre à jour
FR2918233A1 (fr) Procede et dispositif d'echange de donnees de diagnostic pour la simulation de reseaux d'ordinateurs d'aeronefs
FR2737372A1 (fr) Dispositif et procede d'interconnexion de reseaux, routeur ip comprenant un tel dispositif
FR2979512A1 (fr) Procede d'echange de donnees entre nœuds d'une grappe de serveurs et grappe de serveurs mettant en œuvre ce procede
EP1652346B1 (fr) Procede de localisation d'objets mobiles communicants au sein d'un reseau de communications
WO2020008126A1 (fr) Gestion de la mise en application d'une politique dans un environnement sdn de réseau de communication
FR2930700A1 (fr) Procedes et dispositifs pour l'echange temps reel de donnees dans un reseau de communication commute
EP3471346B1 (fr) Procede de generation de requetes pour la segmentation de la surveillance d'un reseau d'interconnexion et materiel associe
EP2790355B1 (fr) Procédé de caractérisation d'un réseau informatique
EP3314818B1 (fr) Procédé de notification relatif à au moins une opération mise en oeuvre par un dispositif formant noeud d'un réseau
FR2930697A1 (fr) 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
FR3084550A1 (fr) Procede de traitement d'un paquet de donnees, dispositif, equipement de communication et programme d'ordinateur associes
FR2988251A1 (fr) Procede de gestion des echanges de flux de donnees dans un reseau de telecommunication autonomique

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 200880022056.X

Country of ref document: CN

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08806038

Country of ref document: EP

Kind code of ref document: A2

WWE Wipo information: entry into national phase

Ref document number: 2691266

Country of ref document: CA

WWE Wipo information: entry into national phase

Ref document number: 12666447

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 2010514054

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2008806038

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2010102716

Country of ref document: RU

ENP Entry into the national phase

Ref document number: PI0811800

Country of ref document: BR

Kind code of ref document: A2

Effective date: 20091223