[go: up one dir, main page]

WO2010079070A1 - Dispositif de liaison de donnees numeriques entre cartes ethernet - Google Patents

Dispositif de liaison de donnees numeriques entre cartes ethernet Download PDF

Info

Publication number
WO2010079070A1
WO2010079070A1 PCT/EP2009/067343 EP2009067343W WO2010079070A1 WO 2010079070 A1 WO2010079070 A1 WO 2010079070A1 EP 2009067343 W EP2009067343 W EP 2009067343W WO 2010079070 A1 WO2010079070 A1 WO 2010079070A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
packet
module
standard
function
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.)
Ceased
Application number
PCT/EP2009/067343
Other languages
English (en)
Inventor
Hugo Delchini
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.)
Commissariat a lEnergie Atomique et aux Energies Alternatives CEA
Original Assignee
Commissariat a lEnergie Atomique CEA
Commissariat a lEnergie Atomique et aux Energies Alternatives CEA
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 Commissariat a lEnergie Atomique CEA, Commissariat a lEnergie Atomique et aux Energies Alternatives CEA filed Critical Commissariat a lEnergie Atomique CEA
Publication of WO2010079070A1 publication Critical patent/WO2010079070A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4633—Interconnection of networks using encapsulation techniques, e.g. tunneling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/323—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the physical layer [OSI layer 1]
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/30—Nc systems
    • G05B2219/40—Robotics, robotics mapping to robotics vision
    • G05B2219/40195—Tele-operation, computer assisted manual operation

Definitions

  • the present invention relates to a device for linking digital data between Ethernet cards. It applies for example in the field of robotics.
  • a master arm controls the movements of a slave arm. No latency between the manual control of the master arm and the response of the slave arm must be felt by the operator: the synchronization between the two arms must be at the millisecond. This is one of the technical problems that the present invention proposes to solve.
  • One current solution is to establish a digital communication link between the two arms by a system based on cards of the type "memory mirror" according to an English expression.
  • a system comprises two memory mirror cards connected by optical fiber.
  • the typical latency of such a system i.e., the transfer time of a zero-size data packet from one card to another, is of the order of 55 microseconds, which is excellent.
  • the cost of a "Memory mirror" card is very high and the product reaches the end of its life.
  • Ethernet link that is to say in accordance with the IEEE802.3 standard, to establish a digital link between the two arms was totally excluded. Because even if such a link is relatively inexpensive, it offers on the other hand typical latency times of the order of a millisecond! Even the most advanced current Ethernet solutions to reduce latency, which implement the standard Ethernet protocol but reserving times or distributing time slots, do not allow to go below 400 microseconds. This is again one of the technical problems that the present invention proposes to solve.
  • the invention aims in particular to overcome the aforementioned drawbacks by using an Ethernet link to establish a digital link between the two arms. Since Ethernet links are best known for the indeterminacy of their latency, the use of an Ethernet link in a robotic application is therefore quite unexpected.
  • the subject of the invention is a digital data link device between the transmitter and a receiver respectively comprising a transmission module and a reception module compliant with the IEEE802.3 standard, connected by a digital connection point to point.
  • a first data flow management module disposed at the output of the transmission module writes the data typing field of a data packet transmitted in accordance with the IEEE802.3 standard to write flow management information therein .
  • a second data flow management module disposed at the input of the receiving module reads the data typing field of a data packet received in accordance with the IEEE802.3 standard to read the flow management information therein.
  • the flow management information includes a logical channel for sending the packet, a packet size and a type of data contained in the packet.
  • the transmission module and / or the reception module compliant with the IEEE802.3 standard can be implemented in hardware form on electronic cards, that is to say ethernet cards.
  • the point-to-point digital connection can then be a twisted pair of electrical conductors.
  • the data flow management modules can be implemented in the form of electronic card management software, implementing a programming interface that can include a function to open a logical channel, a function to write data on a logical channel, function for reading data on a logical channel, a function for closing a logical channel, a function for controlling the input / output mode of a logical channel and a function for selecting one of several logical channels.
  • the transmitter can be a master arm and the receiver can be a slave arm of a robotic tele-manipulation application.
  • the first data flow management module can also write access to the field containing the address of the sender of a data packet transmitted in accordance with the IEEE802.3 standard to write a number therein. of the packet and the second data flow management module can also read access to the field containing the address of the transmitter of a data packet received in accordance with the IEEE802.3 standard to read the packet number, so as to detect transmission errors of the packet.
  • the invention also relates to an outgoing digital data flow management module disposed at the output of a data transmission module compliant with the IEEE802.3 standard.
  • the outgoing data flow management module writes the data typing field of a data packet transmitted in accordance with the IEEE802.3 standard to write flow management information thereon.
  • the flow management information includes a logical channel for sending the packet, a packet size and a type of data contained in the packet.
  • the transmission module compliant with the IEEE802.3 standard can be implemented in hardware form on an electronic card, that is to say an ethernet card.
  • the outgoing data flow management module can then be implemented in the form of control software for the electronic card, which can implement a programming interface notably including a function for opening a logical channel, a function for writing data on a logical channel, a function for closing a logical channel, a function for controlling the input / output mode of a logical channel and a function for selecting one of several logical channels.
  • the outgoing digital data flow management module can write access to the field containing the address of the sender of a data packet transmitted in accordance with the IEEE802.3 standard to write a number therein. packet, so as to detect transmission errors of the packet.
  • the invention also relates to an incoming digital data flow management module disposed at the input of a data receiving module according to the IEEE802.3 standard.
  • the incoming data flow management module reads the data typing field of a received data packet in accordance with the IEEE802.3 standard to read flow management information therein.
  • the flow management information includes a logical channel for sending the packet, a packet size and a type of data contained in the packet.
  • the receiving module compliant with the IEEE802.3 standard can be implemented in hardware form on an electronic card, that is to say an ethernet card.
  • the incoming data flow management module can then be implemented in the form of control software for the electronic card, which can implement a programming interface notably including a function for opening a logical channel, a function for reading data on a logical channel, a function for closing a logical channel, a function for controlling the input / output mode of a logical channel and a function for selecting one of several logical channels.
  • the incoming digital data flow management module can read access to the field containing the address of the sender of a data packet received in accordance with the IEEE802.3 standard to read a number therein. packet, so as to detect transmission errors of the packet.
  • Ethernet cards offer a high level of compatibility with existing systems, which means that it is easy and inexpensive to update.
  • FIG. 1 by a diagram, an illustration of a conventional TCP / IP protocol stack according to the prior art
  • FIG. 2 by a diagram, an illustration of an exchange protocol stack according to the invention.
  • a synchronous digital communication link between two entities generally requires the use of specific electronic cards in each entity, a physical link medium between the two cards and a data exchange protocol.
  • Link latency is commonly defined as the transfer time of a data packet of zero size. Latency is the parameter that most limits the frequency of synchronization of exchanges on the link. For example, for distributed computing on multiple computers, latency is the most limiting setting even before bandwidth. Latency has a material origin: cards and physical media introduce delays. It also has a software origin: the exchange protocol also introduces deadlines. The latency is expected fixed and the lowest possible. We speak of "deterministic latency" when it is bounded.
  • the present invention proposes, for example, the use of two standard Ethernet cards interconnected by a direct physical link, such as a twisted pair of electrical conductors, for example, to synchronize the master arm and the slave arm with one another.
  • robotic tele-manipulation application It should be noted that, unlike a computer network like the Internet where routers are interposed between the communicating entities, the physical topology of the network is here very simple. In particular, it does not include intermediate equipment between the two cards.
  • the prior art Ethernet cards communicate by managing a data stream in accordance with the Transmission Control Protocol / Internet Protocol (TCP / IP), which poses the triple disadvantage of slow communication and unreliability. and indeterminacy of latency.
  • TCP / IP Transmission Control Protocol / Internet Protocol
  • the minimum latency characteristic for exchanges between Ethernet cards using the TCP / IP protocol is of the order of a millisecond, which allows to obtain an overall synchronization only several hundred milliseconds. This is not acceptable as part of a robotic application.
  • the TCP / IP protocol uses a stack of data encapsulation and de-encapsulation processes, which contributes significantly to the latency of the exchanges.
  • FIG. 1 illustrates in a diagram a conventional TCP / IP protocol stack according to the prior art.
  • software encapsulation operations at the level of an application that produces the data then at TCP / UDP (Transmission Control Protocol / User Datagram Protocol) level, then at IP level , then at the level of an Ethernet software driver, globally aim to package the data into packets that can be manipulated to send on the ethemet link.
  • the Ethernet protocol itself is implemented at the hardware level on an electronic card, commonly called "Ethernet card", for sending on a physical link.
  • An Ethernet card receives the data from the receiver side, reverse-encapsulation software operations generally aim to unpack the data after reception to deliver them to an application that consumes the data.
  • FIG. 2 diagrammatically illustrates an exchange protocol stack according to the invention that can be used to manage the communication link between the two Ethernet cards.
  • the protocol according to the invention is reduced to the extreme, not having software operations equivalent to the encapsulation and de-encapsulation operations of the TCP / IP protocol. Only the Ethernet protocol implemented at the hardware level is kept, in order to get down to the hardware latency. To achieve this, the invention proposes to use the data typing field of the Ethernet packet header to encode the necessary minimum flow control information. It must be understood that this is possible because the two Ethernet cards are connected by a point-to-point connection, which considerably reduces the risk of transmission errors. If checks are necessary, then they can be done at the level of the application that consumes the data.
  • the Ethernet protocol provides packet headers containing a 6-byte field indicating the destination address of the packet, a 6-byte field indicating the address of the packet sender, a 2-byte field for encoding the type. data contained in the packet and a 1500-byte field to hold the data itself.
  • 4 bits can advantageously be used to code a logical channel to send the packet (16 possible logical channels on a physical channel), 1 1 bits can be used to encode the packet size (2048 bytes maximum) and 1 bit can be used to encode the data type (data type or control type).
  • the driver according to the invention can advantageously implement the programming interface POSIX ("Portable Operating System Interface").
  • an openQ function to open a logical channel a readQ function to read data on a channel
  • a write () function to write data on a channel a close function to close a channel logic
  • an ioctIQ function to control the input-output mode of a logical channel
  • a selectQ function to select one of several logical channels.
  • one stack per task and per card can be implemented, so that there is no critical section and minimum latency is achieved.
  • the invention in addition to the clever use of the two bytes of the data typing field, the invention also proposes, in order to mitigate packet loss or transmission errors, to advantageously use the six bytes.
  • the field containing the address of the sender in the Ethernet header.
  • two entities are in turn transmitting and receiving. Each entity, whether it emits or receives, can only communicate with one other entity.
  • a minimal Ethernet header is sufficient, consisting only of the address of the recipient, the address of the recipient being strictly necessary for the Ethernet layer hardware works.
  • the six bytes of the "source address" field are not used.
  • the invention proposes to use the field containing the address of the transmitter to number the packets.
  • the process can then be the following: the transmitting packets can be numbered in sequence.
  • the transmitter can wait for an acknowledgment from the receiver.
  • the acknowledgment contains the number of the acknowledged packet. If the number of the acknowledged packet is the same as the number of the transmitted packet, then the transmission is correct.
  • the receiver can send an acknowledgment to each received packet with the number retrieved therein. If the transmitted packet is not acknowledged within a limited time, the packet can be reissued and an acknowledgment can be expected again. This transmission process with waiting for acknowledgment can be repeated as many times as necessary, until the transmission is considered correct.
  • the invention provides a latency of 10 to 15 microseconds with a rate of up to 10 gigabits per second. This level of latency is quite acceptable in the context of a robotic application. This corresponds substantially to the hardware latency introduced by the two Ethernet cards themselves.
  • the invention described above still has the main advantages that it offers a multi-channel solution for multiplexing the physical channel.
  • it can be used in more complex network topologies than a robotic application, as long as the links forming the network are always between 2 cards: star topology or hypercube topology of 16 machines with 4 network cards by machine for example.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Small-Scale Networks (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

La présente invention concerne un dispositif de liaison de données numériques entre en émetteur et un récepteur comportant respectivement un module d'émission et un module de réception conformes à la norme IEEE802.3, reliés par une connexion numérique point à point. Un premier module de gestion de flux de données disposé à la sortie du module d'émission accède en écriture au champ de typage des données d'un paquet de données émis conformément à la norme IEEE802.3 pour y écrire des informations de gestion de flux. Un deuxième module de gestion de flux de données disposé à l'entrée du module de réception accède en lecture au champ de typage des données d'un paquet de données reçu conformément à la norme IEEE802.3 pour y lire les informations de gestion de flux. Les informations de gestion de flux incluent un canal logique pour envoyer le paquet, une taille de paquet et un type de données contenues dans le paquet. Application : robotique

Description

Dispositif de liaison de données numériques entre cartes Ethernet
La présente invention concerne un dispositif de liaison de données numériques entre cartes Ethernet. Elle s'applique par exemple dans le domaine de la robotique.
Dans certaines applications de télé-manipulation robotique, un bras maître pilote les déplacements d'un bras esclave. Aucun temps de latence entre la commande manuelle du bras maître et la réponse du bras esclave ne doit se faire sentir par l'opérateur : la synchronisation entre les deux bras doit être à la milliseconde près. Il s'agit là de l'un des problèmes techniques que la présente invention se propose de résoudre.
Une solution actuelle consiste à établir une liaison de communication numérique entre les deux bras par un système à base de cartes de type « Memory mirror » selon une expression anglo-saxonne. Un tel système comporte deux cartes « Memory mirror » reliées par fibre optique. La latence typique d'un tel système, c'est-à-dire le temps de transfert d'un paquet de données de taille nulle d'une carte à l'autre, est de l'ordre de 55 microsecondes, ce qui est excellent. Malheureusement, le coût d'une carte « Memory mirror » est très élevé et le produit arrive en fin de vie.
Il s'agit là encore de l'un des problèmes techniques que la présente invention se propose de résoudre.
Jusqu'à présent, l'utilisation d'une liaison Ethernet, c'est-à-dire conforme à la norme IEEE802.3, pour établir une liaison numérique entre les deux bras était totalement exclue. Car même si une telle liaison est relativement peu onéreuse, elle offre par contre des temps de latence typiques de l'ordre de la milliseconde ! Même les solutions Ethernet actuelles les plus abouties pour diminuer les temps de latence, qui implémentent le protocole Ethernet standard mais en réservant les durées ou en distribuant des tranches de temps, ne permettent pas de descendre en dessous de 400 microsecondes. Il s'agit là encore de l'un des problèmes techniques que la présente invention se propose de résoudre. L'invention a notamment pour but de pallier les inconvénients précités en utilisant une liaison Ethernet pour établir une liaison numérique entre les deux bras. Les liaisons Ethernet étant surtout connues pour l'indéterminisme de leurs temps de latence, l'utilisation d'une liaison Ethernet dans une application robotique est par conséquent tout à fait inattendue. A cet effet, l'invention a pour objet un dispositif de liaison de données numériques entre en émetteur et un récepteur comportant respectivement un module d'émission et un module de réception conformes à la norme IEEE802.3, reliés par une connexion numérique point à point. Un premier module de gestion de flux de données disposé à la sortie du module d'émission accède en écriture au champ de typage des données d'un paquet de données émis conformément à la norme IEEE802.3 pour y écrire des informations de gestion de flux. Un deuxième module de gestion de flux de données disposé à l'entrée du module de réception accède en lecture au champ de typage des données d'un paquet de données reçu conformément à la norme IEEE802.3 pour y lire les informations de gestion de flux. Les informations de gestion de flux incluent un canal logique pour envoyer le paquet, une taille de paquet et un type de données contenues dans le paquet.
Dans un mode de réalisation préférentiel le module d'émission et/ou le module de réception conformes à la norme IEEE802.3 peuvent être implémentés sous forme matérielle sur des cartes électroniques, c'est-à-dire des cartes ethemet. La connexion numérique point à point peut alors être une paire torsadée de conducteurs électriques. Les modules de gestion de flux de données peuvent être implémentés sous la forme de logiciels de pilotage des cartes électroniques, implémentant une interface de programmation pouvant notamment inclure une fonction pour ouvrir un canal logique, une fonction pour écrire des données sur un canal logique, une fonction pour lire des données sur un canal logique, une fonction pour fermer un canal logique, une fonction pour commander le mode entrée/sortie d'un canal logique et une fonction pour sélectionner un canal logique parmi plusieurs. Avantageusement, l'émetteur peut être un bras maître et le récepteur peut être un bras esclave d'une application de télé-manipulation robotique.
Dans un mode de réalisation préférentiel, le premier module de gestion de flux de données peut aussi accéder en écriture au champ contenant l'adresse de l'émetteur d'un paquet de données émis conformément à la norme IEEE802.3 pour y écrire un numéro de paquet et le deuxième module de gestion de flux de données peut aussi accéder en lecture au champ contenant l'adresse de l'émetteur d'un paquet de données reçu conformément à la norme IEEE802.3 pour y lire le numéro de paquet, de sorte à détecter les erreurs de transmission du paquet.
L'invention a également pour objet un module de gestion de flux de données numériques sortantes disposé à la sortie d'un module d'émission de données conforme à la norme IEEE802.3. Le module de gestion de flux de données sortantes accède en écriture au champ de typage des données d'un paquet de données émis conformément à la norme IEEE802.3 pour y écrire des informations de gestion de flux. Les informations de gestion de flux incluent un canal logique pour envoyer le paquet, une taille de paquet et un type de données contenues dans le paquet.
Dans un mode de réalisation préférentiel, le module d'émission conforme à la norme IEEE802.3 peut être implémenté sous forme matérielle sur une carte électronique, c'est-à-dire une carte ethernet. Le module de gestion de flux de données sortantes peut alors être implémenté sous la forme d'un logiciel de pilotage de la carte électronique, pouvant implémenter une interface de programmation incluant notamment une fonction pour ouvrir un canal logique, une fonction pour écrire des données sur un canal logique, une fonction pour fermer un canal logique, une fonction pour commander le mode entrée/sortie d'un canal logique et une fonction pour sélectionner un canal logique parmi plusieurs.
Dans un mode de réalisation préférentiel, le module de gestion de flux de données numériques sortantes peut accéder en écriture au champ contenant l'adresse de l'émetteur d'un paquet de données émis conformément à la norme IEEE802.3 pour y écrire un numéro de paquet, de sorte à détecter les erreurs de transmission du paquet. L'invention a encore pour objet un module de gestion de flux de données numériques entrantes disposé à l'entrée d'un module de réception de données conforme à la norme IEEE802.3. Le module de gestion de flux de données entrantes accède en lecture au champ de typage des données d'un paquet de données reçu conformément à la norme IEEE802.3 pour y lire des informations de gestion de flux. Les informations de gestion de flux incluent un canal logique pour envoyer le paquet, une taille de paquet et un type de données contenues dans le paquet. Dans un mode de réalisation préférentiel, le module de réception conforme à la norme IEEE802.3 peut être implémenté sous forme matérielle sur une carte électronique, c'est-à-dire une carte ethernet. Le module de gestion de flux de données entrantes peut alors être implémenté sous la forme d'un logiciel de pilotage de la carte électronique, pouvant implémenter une interface de programmation incluant notamment une fonction pour ouvrir un canal logique, une fonction pour lire des données sur un canal logique, une fonction pour fermer un canal logique, une fonction pour commander le mode entrée/sortie d'un canal logique et une fonction pour sélectionner un canal logique parmi plusieurs. Dans un mode de réalisation préférentiel, le module de gestion de flux de données numériques entrantes peut accéder en lecture au champ contenant l'adresse de l'émetteur d'un paquet de données reçu conformément à la norme IEEE802.3 pour y lire un numéro de paquet, de sorte à détecter les erreurs de transmission du paquet.
Outre des temps de latence acceptables à coût minime, ceci même à l'échelle d'une application robotique, l'invention a encore pour principaux avantages que les cartes Ethernet offrent un haut niveau de compatibilité avec les systèmes existant, qu'il est donc facile et peu coûteux de mettre à jour.
D'autres caractéristiques et avantages de l'invention apparaîtront à l'aide de la description qui suit faite en regard de dessins annexés qui représentent :
- la figure 1 , par un diagramme, une illustration d'une pile de protocole TCP/IP classique selon l'art antérieur ;
- la figure 2, par un diagramme, une illustration d'une pile de protocole d'échange selon l'invention.
Une liaison de communication numérique synchrone entre deux entités requiert généralement l'utilisation de cartes électroniques spécifiques dans chaque entité, d'un support physique de liaison entre les deux cartes et d'un protocole d'échange des données. La latence de la liaison se définit couramment comme étant le temps de transfert d'un paquet de données de taille nulle. La latence est le paramètre qui limite le plus la fréquence de synchronisation des échanges sur la liaison. Il faut savoir par exemple que, pour des calculs distribués sur plusieurs ordinateurs, la latence est le paramètre le plus limitant avant même la bande passante. La latence a une origine matérielle : les cartes et le support physique introduisent des délais. Elle a également une origine logicielle : le protocole d'échange introduit aussi des délais. La latence est espérée fixe et la plus faible possible. On parle de « latence déterministe » lorsqu'elle est bornée.
Dans un mode de réalisation, la présente invention propose par exemple d'utiliser deux cartes Ethernet standards reliées entre elles par un lien physique direct, comme une paire torsadée de conducteurs électriques par exemple, pour synchroniser le bras maître et le bras esclave d'une application de télé-manipulation robotique. Il faut noter que, à la différence d'un réseau informatique comme Internet où des routeurs sont interposés entre les entités communicantes, la topologie physique du réseau est ici très simple. Elle ne comporte notamment pas d'équipement matériel intermédiaire entre les deux cartes. Malheureusement, les cartes Ethernet de l'art antérieur communiquent en gérant un flux de données conformément au protocole TCP/IP (« Transmission Control Protocol / Internet Protocol »), ce qui pose le triple inconvénient de la lenteur des communications, du manque de fiabilité et de l'indéterminisme des temps de latence. En effet, la latence minimum caractéristique pour des échanges entre cartes Ethernet utilisant le protocole TCP/IP est de l'ordre de la milliseconde, ce qui ne permet d'obtenir une synchronisation globale qu'à plusieurs centaines de millisecondes. Ceci n'est pas acceptable dans le cadre d'une application robotique. Une raison majeure est que, comme illustré à la figure 1 , le protocole TCP/IP utilise une pile de processus d'encapsulation et de désencapsulation des données, qui contribue fortement à la latence des échanges.
La figure 1 illustre par un diagramme une pile de protocole TCP/IP classique selon l'art antérieur. Du côté d'un l'émetteur, des opérations logicielles d'encapsulation des données au niveau d'une application qui produit les données, puis au niveau TCP/UDP (« Transmission Control Protocol / User Datagram Protocol »), puis au niveau IP, puis au niveau d'un pilote logiciel Ethernet, visent globalement à emballer les données en paquets manipulables pour envoi sur la liaison ethemet. Le protocole Ethernet lui-même est implémenté au niveau matériel sur une carte électronique, communément appelée « carte Ethernet », pour envoi sur une liaison physique. Une carte Ethernet reçoit les données du côté d'un récepteur, des opérations logicielles de désencapsulation des données en sens inverse visent globalement à déballer les données après réception pour les délivrer à une application qui consomme les données. Toutes ces opérations d'encapsulation et de désencapsulation sont génératrices de latence logicielle qui peut fortement ralentir les échanges. D'une part, ces opérations nécessitent beaucoup d'accès mémoire et beaucoup de calculs de sommes pour vérifier la cohérence des données et éventuellement détecter des erreurs. D'autre part, l'implémentation d'une telle pile de protocole au sein de certains systèmes, comme VxWorks par exemple, est commune à toutes les tâches : chaque tâche ayant une activité réseau utilise le même code mettant en œuvre la même pile. Or, pour assurer la cohérence interne de la pile, le système d'exploitation VxWorks doit avoir des sections critiques dans lesquelles une seule tâche à la fois peut se trouver. Par conséquent, si plusieurs tâches communiquent via TCP/IP sous VxWorks, alors la latence augmente encore.
La figure 2 illustre par un diagramme une pile de protocole d'échange selon l'invention, pouvant être utilisée pour gérer la liaison de communication entre les deux cartes Ethernet. Le protocole selon l'invention est réduit à l'extrême, ne comportant pas d'opérations logicielles équivalentes aux opérations d'encapsulation et de désencapsulation du protocole TCP/IP. Seul le protocole Ethernet implémenté au niveau matériel est conservé, afin justement de descendre jusqu'à la latence du matériel. Pour parvenir à cela, l'invention propose d'utiliser le champ de typage des données de l'en-tête de paquet Ethernet pour coder les informations de contrôle de flux minimales nécessaires. Il faut bien comprendre que cela est possible parce que les deux cartes Ethernet sont reliées par une connexion point à point, ce qui diminue considérablement le risque d'erreur de transmission. Si des vérifications sont nécessaires, alors elles peuvent se faire au niveau de l'application qui consomme les données. Le protocole Ethernet prévoit des en-têtes de paquets contenant un champ sur 6 octets indiquant l'adresse du destinataire du paquet, un champ sur 6 octets indiquant l'adresse de l'émetteur du paquet, un champ sur 2 octets pour coder le type des données contenues dans le paquet et un champ sur 1500 octets pour contenir les données elles-mêmes. Dans un mode de réalisation préférentiel, dans les deux octets théoriquement prévus pour coder le type des données, 4 bits peuvent avantageusement être utilisés pour coder un canal logique pour envoyer le paquet (16 canaux logiques possibles sur un canal physique), 1 1 bits peuvent être utilisés pour coder la taille du paquet (2048 octets maximum) et 1 bit peut être utilisé pour coder le type des données (type donnée ou type contrôle). Ces deux octets peuvent avantageusement être écrits ou lus par une seule opération logicielle selon l'invention, qui peut par exemple être implémentée sous la forme d'un pilote logiciel directement utilisé en lieu et place du pilote logiciel Ethernet standard. Pour être compatible avec différents systèmes d'exploitation temps-réel dont VxWorks ou ECOS, ou même être facilement compatible de Linux ou Windows moyennant des adaptations minimes, le pilote selon l'invention peut avantageusement implémenter l'interface de programmation POSIX (« Portable Operating System Interface »). Il peut ainsi proposer les 6 appels systèmes suivants : une fonction openQ pour ouvrir un canal logique, une fonction readQ pour lire des données sur un canal, une fonction write() pour écrire des données sur un canal, une fonction closeβ pour fermer un canal logique, une fonction ioctIQ pour commander le mode d'entrée-sortie d'un canal logique, une fonction selectQ pour sélectionner un canal logique parmi plusieurs. Dans un mode de réalisation préférentiel, une pile par tâche et par carte peut être implémentée, de telle sorte qu'il n'y a pas de section critique et que la latence minimale est obtenue.
Dans un mode de réalisation préférentiel, outre l'utilisation astucieuse des deux octets du champs de typage des données, l'invention propose également, afin de pallier aux pertes de paquets ou aux erreurs de transmission, d'utiliser de façon avantageuse les six octets du champ contenant l'adresse de l'émetteur dans l'en-tête Ethernet. En effet, dans le mode de connexion physique point à point, deux entités sont tour à tour émettrice puis réceptrice. Chaque entité, qu'elle émette ou qu'elle reçoive, ne peut communiquer qu'avec une seule autre entité. Du coup, un entête Ethernet minimale suffit, constitué uniquement de l'adresse du destinataire, l'adresse du destinataire étant le strict nécessaire pour que la couche Ethernet matérielle fonctionne. Ainsi, dans le mode de connexion physique point à point, les six octets du champ "adresse source" ne sont pas utilisés. Ainsi, l'invention propose d'utiliser le champ contenant l'adresse de l'émetteur pour numéroter les paquets. Le processus peut alors être le suivant : les paquets en émission peuvent être numérotés en séquence. Après une émission de paquet, l'émetteur peut attendre un acquittement en provenance du récepteur. L'acquittement contient le numéro du paquet acquitté. Si le numéro du paquet acquitté est le même que le numéro du paquet émis, c'est que la transmission est correcte. Le récepteur peut envoyer un acquittement à chaque paquet reçu avec le numéro récupéré dans ce dernier. Si le paquet émis n'est pas acquitté dans un temps limité, le paquet peut être réémis et un acquittement peut être attendu à nouveau. Ce processus d'émission avec attente d'acquittement peut être répété autant de fois que nécessaire, jusqu'à ce que la transmission soit considérée comme correcte.
L'invention permet d'obtenir une latence de 10 à 15 microsecondes avec un débit pouvant atteindre 10 gigabits à la seconde. Ce niveau de latence est tout à fait acceptable dans le cadre d'une application robotique. Cela correspond sensiblement à la latence matérielle introduite par les deux cartes Ethernet elles-mêmes.
L'invention décrite précédemment a encore pour principaux avantages qu'elle offre une solution multi-canal permettant de multiplexer le canal physique. Par ailleurs, elle peut être utilisée dans des topologies de réseau plus complexes que celle d'une application robotique, tant que les liaisons formant le réseau se font toujours entre 2 cartes : topologie en étoile ou topologie en hypercube de 16 machines avec 4 cartes réseau par machine par exemple.

Claims

REVENDICATIONS
1 . Dispositif de liaison de données numériques entre en émetteur et un récepteur, le dispositif comportant un module d'émission conforme à la norme IEEE802.3 et un module de réception conforme à la norme IEEE802.3 reliés par une connexion numérique point à point, le dispositif comportant :
- un premier module de gestion de flux de données disposé à la sortie du module d'émission, ledit module accédant en écriture au champ de typage des données d'un paquet de données émis conformément à la norme IEEE802.3 pour y écrire des informations de gestion de flux ;
- un deuxième module de gestion de flux de données disposé à l'entrée du module de réception, ledit module accédant en lecture au champ de typage des données d'un paquet de données reçu conformément à la norme IEEE802.3 pour y lire les informations de gestion de flux; le dispositif étant caractérisé en ce que les informations de gestion de flux incluent:
- un canal logique pour envoyer le paquet ;
- une taille de paquet ; - un type de données contenues dans le paquet.
2. Dispositif selon la revendication 1 , caractérisé en ce que le module d'émission et/ou le module de réception conformes à la norme IEEE802.3 sont implémentés sous forme matérielle sur des cartes électroniques.
3. Dispositif selon la revendication 2, caractérisé en ce que la connexion numérique point à point est une paire torsadée de conducteurs électriques.
4. Dispositif selon la revendication 2, caractérisé en ce que le premier module de gestion de flux de données et/ou le deuxième module de gestion de flux de données sont implémentés sous la forme de logiciels de pilotage des cartes électroniques.
5. Dispositif selon la revendication 4, caractérisé en ce que les logiciels de pilotage implémentent une interface de programmation incluant :
- une fonction pour ouvrir un canal logique, et/ou ;
- une fonction pour écrire des données sur un canal logique ou une fonction pour lire des données sur un canal logique, et/ou ;
- une fonction pour fermer un canal logique, et/ou ;
- une fonction pour commander le mode entrée/sortie d'un canal logique, et/ou ;
- une fonction pour sélectionner un canal logique parmi plusieurs.
6. Dispositif selon la revendication 1 , caractérisé en ce que l'émetteur est un bras maître et le récepteur est un bras esclave d'une application de télémanipulation robotique.
7. Dispositif selon la revendication 1 , caractérisé en ce que le premier module de gestion de flux de données accède en écriture au champ contenant l'adresse de l'émetteur d'un paquet de données émis conformément à la norme IEEE802.3 pour y écrire un numéro de paquet et le deuxième module de gestion de flux de données accède en lecture au champ contenant l'adresse de l'émetteur d'un paquet de données reçu conformément à la norme IEEE802.3 pour y lire le numéro de paquet, de sorte à détecter les erreurs de transmission du paquet.
8. Module de gestion de flux de données numériques sortantes disposé à la sortie d'un module d'émission de données conforme à la norme
IEEE802.3, le module de gestion de flux accédant en écriture au champ de typage des données d'un paquet de données émis conformément à la norme IEEE802.3 pour y écrire des informations de gestion de flux, le module étant caractérisé en ce que les informations de gestion de flux incluent:
- un canal logique pour envoyer le paquet ;
- une taille de paquet ;
- un type de données contenues dans le paquet.
9. Module selon la revendication 8, caractérisé en ce que le module d'émission conforme à la norme IEEE802.3 est implémenté sous forme matérielle sur une carte électronique.
10. Module selon la revendication 9, caractérisé en ce qu'il est implémenté sous la forme d'un logiciel de pilotage de la carte électronique.
11. Module selon la revendication 10, caractérisé en ce que le logiciel de pilotage implémenté une interface de programmation incluant : - une fonction pour ouvrir un canal logique, et/ou ;
- une fonction pour écrire des données sur un canal logique, et/ou ;
- une fonction pour fermer un canal logique, et/ou ;
- une fonction pour commander le mode entrée/sortie d'un canal logique, et/ou ; - une fonction pour sélectionner un canal logique parmi plusieurs.
12. Module selon la revendication 8, caractérisé en ce qu'il accède en écriture au champ contenant l'adresse de l'émetteur d'un paquet de données émis conformément à la norme IEEE802.3 pour y écrire un numéro de paquet, de sorte à détecter les erreurs de transmission du paquet.
13. Module de gestion de flux de données numériques entrantes disposé à l'entrée d'un module de réception de données conforme à la norme IEEE802.3, le module de gestion de flux accédant en lecture au champ de typage des données d'un paquet de données reçu conformément à la norme IEEE802.3 pour y lire des informations de gestion de flux, le module étant caractérisé en ce que les informations de gestion de flux incluent: - un canal logique pour envoyer le paquet ;
- une taille de paquet ;
- un type de données contenues dans le paquet.
14. Module selon la revendication 13, caractérisé en ce que le module de réception conforme à la norme IEEE802.3 est implémenté sous forme matérielle sur une carte électronique.
15. Module selon la revendication 14, caractérisé en ce qu'il est implémenté sous la forme d'un logiciel de pilotage de la carte électronique.
16. Module selon la revendication 15, caractérisé en ce que le logiciel de pilotage implémenté une interface de programmation incluant : - une fonction pour ouvrir un canal logique, et/ou ;
- une fonction pour lire des données sur un canal logique, et/ou ;
- une fonction pour fermer un canal logique, et/ou ;
- une fonction pour commander le mode entrée/sortie d'un canal logique, et/ou ; - une fonction pour sélectionner un canal logique parmi plusieurs.
17. Module selon la revendication 13, caractérisé en ce qu'il accède en lecture au champ contenant l'adresse de l'émetteur d'un paquet de données reçu conformément à la norme IEEE802.3 pour y lire un numéro de paquet, de sorte à détecter les erreurs de transmission du paquet.
PCT/EP2009/067343 2009-01-06 2009-12-16 Dispositif de liaison de donnees numeriques entre cartes ethernet Ceased WO2010079070A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0900027 2009-01-06
FR0900027A FR2940871B1 (fr) 2009-01-06 2009-01-06 Dispositif de liaison de donnees numeriques entre cartes ethernet

Publications (1)

Publication Number Publication Date
WO2010079070A1 true WO2010079070A1 (fr) 2010-07-15

Family

ID=40873465

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2009/067343 Ceased WO2010079070A1 (fr) 2009-01-06 2009-12-16 Dispositif de liaison de donnees numeriques entre cartes ethernet

Country Status (2)

Country Link
FR (1) FR2940871B1 (fr)
WO (1) WO2010079070A1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6438128B1 (en) * 2001-05-08 2002-08-20 International Business Machines Corporation Alternate use of data packet fields to convey information
US20020199021A1 (en) * 2001-06-26 2002-12-26 Niels Beier Method and apparatus for using the type/length field in an ethernet mac header for carrying generic tags/labels
WO2008003218A1 (fr) * 2006-06-30 2008-01-10 Huawei Technologies Co., Ltd. Procédé, dispositif et système de transmission d'informations entre des appareils dans éthernet

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6438128B1 (en) * 2001-05-08 2002-08-20 International Business Machines Corporation Alternate use of data packet fields to convey information
US20020199021A1 (en) * 2001-06-26 2002-12-26 Niels Beier Method and apparatus for using the type/length field in an ethernet mac header for carrying generic tags/labels
WO2008003218A1 (fr) * 2006-06-30 2008-01-10 Huawei Technologies Co., Ltd. Procédé, dispositif et système de transmission d'informations entre des appareils dans éthernet

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
CHEN ET AL: "The workspace mapping with deficient-DOF space for the PUMA 560 robot and its exoskeleton arm by using orthogonal experiment design method", ROBOTICS AND COMPUTER INTEGRATED MANUFACTURING, ELSEVIER SCIENCE PUBLISHERS BV., BARKING, GB, vol. 23, no. 4, 29 March 2007 (2007-03-29), pages 478 - 487, XP022003829, ISSN: 0736-5845 *

Also Published As

Publication number Publication date
FR2940871B1 (fr) 2012-12-14
FR2940871A1 (fr) 2010-07-09

Similar Documents

Publication Publication Date Title
US8804504B1 (en) System and method for reducing CPU load in processing PPP packets on a SSL-VPN tunneling device
US20040233904A1 (en) Universal plug-and-play mirroring device, system and method
WO2001057684A1 (fr) Transport d'unites de protocole d'objet electronique portable par protocole pour peripheriques de micro-ordinateur
US20070086448A1 (en) Integrated pseudo-wire and virtual routing and forwarding on a single provider edge router
FR2929789A1 (fr) Procede de gestion de mecanismes d'amelioration de transmission de flux de donnees sur un tunnel, produit programme d'ordinateur, moyen de stockage et tete de tunnel correspondants
CN115834733A (zh) 基于apl技术的以太网多协议通信装置和方法
US20100296519A1 (en) Ethernet Physical Layer Repeater
CA2770391A1 (fr) Systeme et procede de partage de donnees utiles entre des reseaux a double connexion
CN114205149B (zh) 网络通信方法及装置
US7088737B1 (en) Method and apparatus for combining packets having different protocol encapsulations within a circuit
Amin et al. An Introduction of Open System Interconnection (OSI) Model and its Architecture
WO2010079070A1 (fr) Dispositif de liaison de donnees numeriques entre cartes ethernet
US20060114892A1 (en) Method and apparatus to transmit state information through a communication link
WO2018204214A1 (fr) Procédés, appareils et supports d'informations lisibles par ordinateur destinés à une communication par l'intermédiaire d'une plateforme de services utilisateurs
Jasud The OSI model: Overview on the seven layers of computer networks
Banzal Data and computer network communication
JP2009094778A (ja) 高速ネットワークシステム及び関連装置
CN106385418B (zh) 一种传输私有数据的方法及装置
CA2949332A1 (fr) Commutateur de trames numeriques
Salvi et al. Mode of data flow in the OSI model
EP3829134B1 (fr) Procede de transfert de grandes quantites de donnees a travers un reseau telematique de maniere efficace et fiable et a haute vitesse
EP4622226A1 (fr) Procédé de transmission de données et appareil associé
RU2768799C1 (ru) Телекоммуникационный программно-аппаратный комплекс и способ для обеспечения бесшовной интеграции сетей связи через ip сеть (варианты)
EP2652628B1 (fr) Dispositif de connexion ethernet multiple a une unite informatique et ensemble unite informatique et equipements relies ensemble
UGWUMBA Computer Networking in the Cloud Era: A Guide to Modern Communication

Legal Events

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

Ref document number: 09796700

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 09796700

Country of ref document: EP

Kind code of ref document: A1