Brevet FR2940871A1 — publié le 20100709

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. II 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. II 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. Avantageusement, les informations de gestion de flux peuvent inclure 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 ethernet. 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. 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 1 o écrire des informations de gestion de flux. Avantageusement, les informations de gestion de flux peuvent inclure 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 15 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 20 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. 25 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 30 lire des informations de gestion de flux. Avantageusement, les informations de gestion de flux peuvent inclure 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 35 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. 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 20 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. 25 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 30 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. II faut savoir par exemple que, pour des calculs distribués sur plusieurs ordinateurs, la latence est le 35 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. II 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 ethernet. 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 oeuvre 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), 11 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 open() pour ouvrir un canal logique, une fonction read() 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 ioctl() pour commander le mode d'entrée-sortie d'un canal logique, une fonction select() 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. 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 ~o ou topologie en hypercube de 16 machines avec 4 cartes réseau par machine par exemple. REVENDICATIONS1. 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 étant caractérisé en ce qu'il comporte : - 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. 2. Dispositif selon la revendication 1, 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. 3. 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. 4. Dispositif selon la revendication 3, caractérisé en ce que la connexion numérique point à point est une paire torsadée de conducteurs électriques. 5. Dispositif selon la revendication 3, 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.30 6. Dispositif selon la revendication 5, 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. 7. 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. 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 étant caractérisé en ce qu'il 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. 9. Module selon la revendication 8, 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. 10. Module selon la revendication 8, caractérisé en ce que le module 30 d'émission conforme à la norme IEEE802.3 est implémenté sous forme matérielle sur une carte électronique. 11. Module selon la revendication 10, caractérisé en ce qu'il est implémenté sous la forme d'un logiciel de pilotage de la carte électronique. 35 12. Module selon la revendication 11, caractérisé en ce que le logiciel de pilotage implémente 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. 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 étant caractérisé en ce qu'il 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. 14. Module selon la revendication 13, 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. 15. 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. 16. Module selon la revendication 15, caractérisé en ce qu'il est implémenté sous la forme d'un logiciel de pilotage de la carte électronique. 17. Module selon la revendication 16, caractérisé en ce que le logiciel de pilotage implémente 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.