WO2010079070A1

WO2010079070A1 - Device for linking digital data between ethernet boards

Info

Publication number: WO2010079070A1
Application number: PCT/EP2009/067343
Authority: WO
Inventors: Hugo Delchini
Original assignee: Commissariat A L'energie Atomique Et Aux Energies Alternatives
Priority date: 2009-01-06
Filing date: 2009-12-16
Publication date: 2010-07-15
Also published as: FR2940871A1; FR2940871B1

Abstract

The invention relates to a device for linking digital data between a transmitter and a receiver comprising a transmission module and a reception module compliant with standard IEEE802.3, respectively, which are connected by a point-to-point digital connection. A first data stream management module arranged at the output of the transmission module has write access to the data typing field of a data packet transmitted according to standard IEEE802.3 in order to write stream management information therein. A second data stream management module arranged at the input of the reception module has write access to the data typing field of a data packet received according to standard IEEE802.3 in order to read stream management information therefrom. The stream management information includes a logic channel for sending the packet, a packet size and the type of data contained in the packet. The invention can be used in robotics.

Description

Digital data link device between Ethernet cards

The present invention relates to a device for linking digital data between Ethernet cards. It applies for example in the field of robotics.

In some robotic tele-manipulation applications, 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. Such 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. Unfortunately, the cost of a "Memory mirror" card is very high and the product reaches the end of its life.

This is again one of the technical problems that the present invention proposes to solve.

Until now, the use of an 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. For this purpose, 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.

In a preferred embodiment, 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. Advantageously, the transmitter can be a master arm and the receiver can be a slave arm of a robotic tele-manipulation application.

In a preferred embodiment, 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.

In a preferred embodiment, 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.

In a preferred embodiment, 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. In a preferred embodiment, 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. In a preferred embodiment, 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.

In addition to acceptable latency at low cost, even at the scale of a robotic application, the main advantages of the invention are that Ethernet cards offer a high level of compatibility with existing systems, which means that it is easy and inexpensive to update.

Other characteristics and advantages of the invention will become apparent with the aid of the following description made with reference to appended drawings which represent:

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.

In one embodiment, 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. Unfortunately, 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. Indeed, 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. A major reason is that, as shown in Figure 1, 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. On the side of the transmitter, 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. All these encapsulation and decapsulation operations generate software latency that can greatly slow down the exchanges. On the one hand, these operations require a lot of memory access and a lot of sums calculations to verify the consistency of the data and possibly detect errors. On the other hand, the implementation of such a protocol stack within some systems, such as VxWorks, is common to all tasks: each task with network activity uses the same code implementing the same stack. However, to ensure coherence In the stack, the VxWorks operating system must have critical sections in which only one task at a time can be located. Therefore, if multiple tasks communicate over TCP / IP under VxWorks, then the latency increases further.

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. In a preferred embodiment, in the two octets theoretically provided for coding the type of the data, 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). These two bytes can advantageously be written or read by a single software operation according to the invention, which can for example be implemented in the form of a software driver directly used in place of the standard Ethernet software driver. To be compatible with different operating systems real-time including VxWorks or ECOS, or even be easily compatible Linux or Windows with minimal adaptations, the driver according to the invention can advantageously implement the programming interface POSIX ("Portable Operating System Interface"). It can thus offer the following 6 system calls: 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. In a preferred embodiment, one stack per task and per card can be implemented, so that there is no critical section and minimum latency is achieved.

In a preferred embodiment, 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. Indeed, in the point-to-point physical connection mode, two entities are in turn transmitting and receiving. Each entity, whether it emits or receives, can only communicate with one other entity. As a result, 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. Thus, in point-to-point physical connection mode, the six bytes of the "source address" field are not used. Thus, 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. After a packet transmission, 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. In addition, 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.

Claims

1. Digital data link device between a transmitter and a receiver, the device comprising a transmission module according to the IEEE802.3 standard and a reception module compliant with the IEEE802.3 standard connected by a digital point-to-point connection, the device comprising:

a first data flow management module arranged at the output of the transmission module, said module accessing in writing the data typing field of a data packet transmitted in accordance with the IEEE802.3 standard for writing information therein flow management;

a second data flow management module arranged at the input of the reception module, said module accessing in read mode the data typing field of a data packet received in accordance with the IEEE802.3 standard for reading information therein flow management; the device being characterized in that the flow management information includes:

a logical channel for sending the packet;

- a packet size; - a type of data contained in the package.

2. Device according to claim 1, characterized in that the transmitting module and / or the receiving module according to the IEEE802.3 standard are implemented in hardware form on electronic cards.

3. Device according to claim 2, characterized in that the point-to-point digital connection is a twisted pair of electrical conductors.

4. Device according to claim 2, characterized in that the first data flow management module and / or the second data flow management module are implemented in the form of control software for electronic cards.

5. Device according to claim 4, characterized in that the control software implements a programming interface including:

- a function to open a logical channel, and / or;

a function for writing data on a logical channel or a function for reading data on a logical channel, and / or;

a function for closing a logical channel, and / or;

a function for controlling the input / output mode of a logical channel, and / or;

- a function to select one of several logical channels.

6. Device according to claim 1, characterized in that the transmitter is a master arm and the receiver is a slave arm of a robotic telemanipulation application.

7. Device according to claim 1, characterized in that the first data flow management module writes to the field containing the address of the issuer of a data packet transmitted in accordance with the IEEE802.3 standard for writing a packet number and the second data flow management module reads the field containing the address of the sender 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.

8. Outgoing digital data flow management module disposed at the output of a data transmission module conforming to the standard

IEEE802.3, the flow management module writing access to the data typing field of a data packet transmitted in accordance with the IEEE802.3 standard for writing flow management information, the module being characterized in that flow management information includes:

a logical channel for sending the packet;

- a packet size;

- a type of data contained in the package.

9. Module according to claim 8, characterized in that the transmitting module according to the IEEE802.3 standard is implemented in hardware form on an electronic card.

10. Module according to claim 9, characterized in that it is implemented in the form of a control software of the electronic card.

11. Module according to claim 10, characterized in that the control software implemented a programming interface including: a function for opening a logical channel, and / or;

a function for writing data on a logical channel, and / or;

a function for closing a logical channel, and / or;

a function for controlling the input / output mode of a logical channel, and / or; - a function to select one of several logical channels.

12. Module according to claim 8, characterized in that it accesses in writing to the field containing the address of the transmitter of a data packet transmitted in accordance with the IEEE802.3 standard to write a packet number, so as to detect transmission errors of the packet.

13. Incoming digital data flow management module disposed at the input of a data receiving module according to the IEEE802.3 standard, the flow management module accessing the data typing field of a data reader in read mode. data packet received in accordance with IEEE802.3 for reading flow management information, the module characterized in that the flow management information includes: - a logical channel for sending the packet;

- a packet size;

- a type of data contained in the package.

14. Module according to claim 13, characterized in that the receiving module according to the IEEE802.3 standard is implemented in hardware form on an electronic card.

15. Module according to claim 14, characterized in that it is implemented in the form of a control software of the electronic card.

16. Module according to claim 15, characterized in that the control software implemented a programming interface including: a function for opening a logical channel, and / or;

a function for reading data on a logical channel, and / or;

a function for closing a logical channel, and / or;

17. Module according to claim 13, characterized in that it 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 a packet number, so as to detect transmission errors of the packet.