FR2996976A1 - Arrangement de mesure reparti pour un dispositif d'acquisition de moteur integre avec acceleration tcp - Google Patents

Abstract

Procédé de transmission de données entre deux dispositifs dans une couche client et/ou une couche de transport d'un système de communication selon lequel la transmission des données se fait selon le protocole de contrôle de transport « protocole TCP ». Les données à transmettre sont enregistrées dans une mémoire centrale (12) et le protocole de contrôle de transport TCP (10) traite les références des données transportées et enregistrées dans la mémoire (12) au lieu des données elles-mêmes.

Description

Domaine de l'invention La présente invention se rapporte à un système de me- sure réparti. Dans de tels systèmes le protocole de contrôle de transmission TCP est très largement répandu pour la fiabilité du transport d'une donnée de mesure de calibrage et de diagnostic (MCD) entre les dispositifs d'acquisition, intégrés, reliés aux unités de commande électroniques des moteur (unités ECU) et des outils de programme de développement de moteur fonctionnant sur les ordinateurs personnels (en général INCA de la société ETAS GmbH).

Les dispositifs intégrés, d'acquisition, sont souvent situés dans le dispositif ECU (dispositif en cours d'essai DUT) et fonctionnement dans les mêmes conditions d'environnement brutal que l'unité ECU elle-même. Comme l'alimentation est faite à partir de la batterie du véhicule, la puissance consommée par les dispositifs d'acquisition doit être faible pour tenir en mode de veille sans épuiser la batterie, pour permettre de redémarrer l'unité ECU. Le protocole de contrôle de transmission TCP est l'un des protocoles de base de l'ensemble des protocoles Internet. Le protocole TCP est l'un des deux composants d'origine de l'ensemble complétant le protocole Internet IP et c'est pourquoi l'ensemble est généralement ap- pelé « modèle TCP/IP ». Le protocole TCP assure la délivrance fiable organisée, d'un flux d'octets par un programme exécuté par un ordinateur vers un autre programme d'un autre ordinateur. Le protocole TCP est le protocole utilisé par les principales applications Internet telles que le réseau WWW, le courriel e-mail, l'administration à distance et le trans- fert de dossiers. D'autres applications qui ne nécessitent pas un service de flux de données fiables peuvent utiliser le protocole de datagramme d'utilisateur (protocole UDP) qui assure le service de datagramme avec une fiabilité réduite.

Le protocole correspond à la couche de transport du mo- dèle TCP/IP. Le protocole TCP assure le service de transmission à un niveau intermédiaire entre un programme d'application et le protocole Internet IP. Cela signifie que lorsqu'une application de programme souhaite envoyer un segment important de données par Internet en utili- sant le protocole IP, au lieu de découper les données en des éléments correspondants à la dimension IP et émettre une série de requêtes IP, le programme peut envoyer une unique requête vers le protocole TCP et laisser le protocole TCP traiter les détails du protocole IP. Le protocole IP fonctionne par l'échange de segment d'information appelés paquets. Un paquet est une séquence d'octets et se compose d'une entête suivi par un corps. L'entête décrit la destination du paquet et en option les routeurs à utiliser pour le transférer jusqu'à la destination. Le corps contient les données. Du fait de la convexion des réseaux, de l'équilibrage de charge de trafic et autres comportements imprévisibles du réseau, des paquets IP risquent d'être perdus, dupliqués ou fournis de manière désorganisée. Le protocole TCP détecte ces difficultés, demande la transmission des données perdues, réorganise les données désorganisées et même permet de réduire la congestion du réseau pour réduire la fré- quence des autres difficultés. Dès que le récepteur de protocole TCP a rassemblé les séquences des octets transmis à l'origine, il les envoi au programme d'application. Ainsi, le protocole TCP décharge la communication de l'application des détails subsidiaire du fonctionnement du réseau.

Le protocole TCP est utilisé de manière extensive par de nombreuses applications parmi les plus populaires d'Internet tels que le réseau WWW, le courriel, e-mails, le protocole de transfert de dossiers, l'encapsulage de sécurité, le partage de dossiers de point à point et autres applications de flux de média.

Le protocole TCP est un service de distribution de flux fiable, qui garantit que tous les octets reçus seront identiques aux octets envoyés et dans le bon ordre. Comme le transfert par paquets n'est pas fiable, on peut utiliser une technique connue comme l'accusé de réception positif avec retransmission pour garantir la fiabilité du trans- fert du paquet. Cette technique fondamentale demande au récepteur de répondre par un message de confirmation lorsqu'il reçoit la donnée. L'émetteur enregistre chaque paquet qu'il envoie. L'émetteur conserve également l'heure à laquelle le paquet a été envoyé et retransmet un paquet si le temps expire avant la réception de la confirmation. Le temps est nécessaire en cas de perte de paquet ou de destruction de celui-ci.

Le protocole TCP se compose d'un ensemble de règles : pour le protocole utilisé avec le protocole Internet IP, pour envoyer la donnée « sous la forme d'unités de message » entre les machines par Internet. Pendant que le protocole IP traite la distribution proprement dite de la donnée, le protocole TCP conserve une trace des unités indivi- duelles de transmission de données appelées « segments » selon lesquels un message est divisé pour un routage efficace dans le réseau. Par exemple, lorsqu'un dossier HTML est envoyé par un serveur du réseau, la couche de programme TCP du serveur divise la séquence des octets du dossier en segments et envoie ceux-ci individuellement vers la couche de programme IP (couche Internet). La couche Internet encapsule chaque segment TCP dans un paquet IP en ajoutant une entête qui contient (parmi d'autres données) l'adresse IP de destination. Bien que chaque paquet ait la même adresse de destination, les paquets peuvent être transférés suivant des chemins différents dans le réseau. Lorsque le programme client de l'ordinateur de destination reçoit les paquets, la couche TCP (couche de transport) rassemble les différents segments et garantit leur ordre correct et sans erreur, de leur envoi par l'application. La structure du segment TCP sera décrite ci-après. Le protocole de contrôle de transmission TCP accepte les données d'un flux de données, les fragmente en segments et ajoute une entête TCP en créant ainsi un segment TCP. Le segment TCP est ensuite encapsulé dans un datagramme de protocole Internet IP. Un segment TCP est un « paquet » d'informations que le protocole TCP utilise pour échanger des données pair à pair. L'expression « paquet TCP » bien que souvent utilisée de manière informelle n'est pas concordante avec la terminologie habituelle selon laquelle un segment se rapporte à un datagramme PDU TCP (unité de protocole de données) vers le PDU IP et la trame vers la couche de liaison de données PDU. Le procédé transmet les données le protocole TCP et en les faisant passer par les mémoires tampons de données comme arguments. Le protocole TCP emballe les données de ces mémoires tampons en segments et appelle sur le module Internet (en général IP) pour transmettre chaque segment vers la destination TCP.

Un segment TCP se compose d'un segment d'entête et d'une section de données. L'entête TCP contient dix champs de mandataire et un champ d'extension en option (option, fond orange dans le tableau).

La section de donnée suit l'entête. Son contenu constitué par la donnée payante transportée par l'application. La longueur de la section de donnée n'est pas spécifiée dans le segment d'entête TCP. Il se calcule en soustrayant la longueur combinée de l'entête TCP et de l'entête IP d'encapsulage de la longueur totale du datagramme IP (défi- dans l'entête IP). Segment TCP En bits ( 8 9 U) I I 12 13 14 I 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 Port Source 2 octets Port destination 2 octets Numéro de séquence Numét-o d'acquittement Taille de Résen é ECN URG ACK PSH RST SYN FIN Fenêtre I 'en-tête Somme de contrôle Pointeur cle données urgentes Options Remplissage Données - Port source (16 bits) - Il identifie le port d'émission. - Port de destination (16 bits) - Il identifie le port de destination. - Numéro de séquence (32 bits) - un double rôle. Si le drapeau SYN est mis (1) il s'agit du numéro initial de la séquence. Le numéro initial de séquence du premier octet actuel de données et le numéro de confirmation de ACK correspondant sont alors ce numéro de séquence plus 1. Si le drapeau SYN n'est pas mis (0) alors il s'agit du numéro de séquence cumulé du premier octet de données de ce paquet pour la session courante. Numéro de confirmation (32 bits). Si le drapeau ACK est mis, alors la valeur de ce champ est le numéro de séquence suivant que le récepteur attend. Il confirme la réception de tous les octets antérieurs (s'il y en a eu). Le premier accusé de réception ACK envoyé par chaque terminaison confirme le numéro en lui-même de la séquence initiale de terminaison mais pas de données. * Décalage de données (4 bits) - Il spécifie la taille de l'entête TCP dans le mot à 32 bits. La dimension minimale de l'entête est celle de cinq mots, le maximum correspond à 15 mots, ce qui donne la dimension minimale de 20 octets et le maximum de 60 octets autorisant ainsi jusqu'à 40 octets d'option dans l'entête. Ce champ tient son nom du fait qu'il est également décalé par rapport au début du segment TCP jusqu'aux données actuelles. * Réservé (3 bits) pour la future utilisation et ne doit pas être mis à zéro. * Drapeaux (9 bits) (bits de contrôle ACK) contient 9 drapeaux de 1 bit. * NS (1 bit) - ECN correspond à la protection de confinement (ajouté à l'entête par RFC 3540). * CWR (1 bit) - Drapeau de réduction de fenêtre de congestion (CWR) qui est mis par l'hôte d'émission indiquant quand il a reçu un segment TCP avec le drapeau ECE mis et qu'il a répondu dans le mécanisme de contrôle de congestion (ajouté à l'entête par RFC 3168). * ECE (1 bit) - Indique le retour ECN. * Si le drapeau SYN est mis (1) le pair TCP est capable ECN. * Si le drapeau SYN n'est pas mis (0) un paquet avec un drapeau de congestion dans l'entête IP est mis et reçu pendant la transmission normale (ajouté à l'entête par RFC 3168). * URG (1 bit) indique que le champ de pointeur urgent est signifiant. * ACK (1 bit) indique le champ de confirmation est signifiant. Tous les paquets après le paquet SYN initial envoyé par le client doivent avoir ce drapeau mis. * PSH (1 bit) - Action de pousser. Demande la poussée de la donnée enregistrée en mémoire vers l'application réceptrice. * RST (1 bit) - Remise à l'état de la connexion. * SYN (1 bit) - Synchronise les numéros de la séquence. Seul le premier paquet envoyé par chaque extrémité doit avoir ce drapeau mis. Certains des autres drapeaux changent de signification de ce drapeau et certains sont seulement validés s'ils sont mis et d'autres lorsqu'ils sont effacés. * FIN (1 bit) - Plus de données en provenance de l'émetteur. * Dimension de la fenêtre (16 bits) - La dimension de la fenêtre de réception qui spécifie le nombre d'octets (infé- rieur au numéro de séquence dans l'accusé de réception) indiquant que l'émetteur de ce segment souhaite couramment recevoir (voir contrôle de flux de données est mise à l'échelle de la fenêtre). * Somme de contrôle (16 bits) - Le champ de la somme de contrôle 16 bits est utilisé pour le contrôle d'erreurs dans l'entête et dans les données. * Pointeur urgent (16 bits) - Si le drapeau URG est mis, alors ce champ à 16 bits est décalé par rapport à la sé- quence de nombre indiquant l'octet de données le plus urgent. * Options (variables 0-320 bits, divisible par 32) - La longueur de ce champ est déterminée par le champ de décalage de données. Les options vont jusqu'à trois champs : l'option de type (1 octet), l'option de longueur (1 octet), la donnée d'option (variable). Le champ option type indique le type qui est le seul le champ non facultatif. En fonction des d'option concernées, les deux champs suivants peuvent être mis : champ de longueur d'option indiquant la longueur totale de l'option et champ de données de l'option contenant la valeur de l'option si elle est applicable. Par exemple un octet de type d'option 0x01 indique qu'il s'agit d'une non-option utilisée seulement pour le remplissage et il n'y a pas de longueur d'option ni d'octet de données d'option qui suit. Un octet de type d'option égal à 0 est l'option correspondant à la fin des options et correspond ainsi seulement à un octet. Un octet de type d'option 0x02 indique qu'il s'agit de l'option de taille de segment, maximale et sera suivi par un octet défini sans la longueur du champ MMS (qui devrait être de 0x04). On remarque cette longueur et la longueur totale du champ d'option y compris les octets de type et de longueur d'option. Ainsi, alors que la valeur MMS est exprimée de manière caractéris- tique par deux octets, la longueur du champ sera de 4 octets (+ 2 octets de type et de longueur). En bref, un champ d'option MMS avec une valeur de 0x05B4 aura (0x02 0x04 0x05B4) dans la section des options TCP. * Padding (remplissage) - L'entête padding de TCP est utilisée pour terminer l'entête TCP et que la donnée commence seulement à la frontière de 32 bits. Le padding est composé de zéros. Certaines options peuvent être seulement envoyées si SYN est mis ; elles sont indiquées ci-après par [sYN].

Le type d'option et les longueurs standards sont donnés comme type d'option, longueur d'option. * 0 (8 bits) - Fin de la liste des options. * 1 (8 bits) - Pas d'opération (NOP, Padding). Cela peut servir pour aligner les champs d'options sur des frontières à 32 bits pour de meilleures caractéristiques. * 2,4,SS (32 bits) - Taille maximale de segment [SYN]. * 3,3,S (24 bits) échelle de fenêtre (voir ci-après l'expression échelle de fenêtre pour les détails) [SYN]. * 4,2 (16 bits) - Confirmation sélective autorisée [SYN] (voir confirmation sélective pour les détails). * 5,N,BBBB,EEEE (bits variables N soit égal à 10, 18, 26 ou 34) - Confirmation ACK sélective (SACK).

Ces deux premiers octets sont suivis par une liste de 1-4 blocs qui sont confirmés sélectivement spécifiés comme pointeur de début/fin à 32 bits. * 8,10,7777,EEEE (80 bits) - Mémoire tampon de temps et écho de la mémoire tampon de temps pré- cédent (voir la mémoire tampon de temps TCP pour les détails). * 14,3,S (24 bits) - Requête de somme de contrôle alternative TCP [SYN]. * 15,N,... (bits variables) - Données de somme de contrôle alternative TCP. (Les options restantes sont obsolètes, expérimentales et ne sont pas standardisées ni attribuées). Un nombre d'applications avec un service de qualité diffé- rente QOS nécessite de s'appuyer sur le protocole TCP comme fiable ou UDP comme mécanisme de transport avec latence, lent, sous-jacent : - transport de données de mesure à flux de débit élevé utilisant des protocoles de moteurs spécifiques à l'application avec des taux de données de l'ordre de dizaine de Moctets/sec par une unique connexion TCP. - Transport de données de mesure en flux à faible la- tence et faible gigue pour fonctionner dans les cas d'utilisation de prototype de boucle FIL utilisant UDP. - Service de diagnostique, de calibrage et de contrôle fondé sur la transaction avec des demandes à faible la- tence pour garantir des temps de parcours de faible transaction utilisant soit TCP ou UCP. - Service TCP/IP de meilleur effort standard tel que http, FTP ou émulation sur terminal.

Dans de nombreux cas, ces applications coexistent sur un seul dispositif d'acquisition intégré et chaque protocole spécifique à une application et pour le service de moteur nécessite sa propre connexion TCP. TCP/IP est généralement implémenté dans un pro- lo gramme et s'exécute dans le mode superviseur de l'unité CPU (espace de coeur) comme service de système de fonctionnement. Toutefois, les implémentations de protocole font des sur-programmes, souffrent principalement de l'absence de limitation de vitesse de trame à cause de la grande quantité de commutateurs de contexte et de la quantité de tra- 15 vail à exécuter pour chaque trame reçue ou transmise. Cela est particu- lièrement vrai pour des petits systèmes intégrés avec une caractéristique CPU limitée et qui sont reliés à une liaison Ethernet Gigabits à fort débit et faible latence avec une vitesse de trame très élevée. Différents procédés ont été proposés selon l'art antérieur 20 pour améliorer le rapport de la puissance de traitement consommée par l'unité CPU par trame. Les plus populaires de ces méthodes sont les suivantes : - moteur hors charge : o des moteurs hors charge cherchent à réduire le 25 nombre d'opérations à effectuer par trame IP en général en calculant l'entête et la somme de contrôle des données dans un circuit. o Cette approche réduit la puissance de traitement par évènement mais ne réduit pas la vitesse de 30 trame pour le programme. Le problème des trop nombreux commutateurs de contexte subsiste. - Etranglement d'interruptions ou concaténation d'interruptions : o le nombre de commutateurs de contexte est réduit 35 par concaténation du traitement des arrivées de trames multiples dans une seule action de service d'interruption. o L'étranglement d'interruptions permet de réduire dans un lot, le nombre de commutations de con- texte par unité de temps. Toutefois, comme il fonc- tionne sur le niveau de la couche de liaison (Ethernet) il ne fournit pas de service et introduit une latence gênante dans tous les services. - L'utilisation de mégatrames : o les mégatrames sont des trames Ethernet de lon- gueur étendue de façon caractéristique allant jus-q u 'à 9 600 octets au lieu de 1 518 octets classiques. Cela suppose de réduire la vitesse de trame en autorisant des plus grandes dimensions de segment TCP. o Les mégatrames n'ont jamais été standardisées par la norme IEEE 801.3 et sont rarement utilisées dans les réseaux locaux LAN et pratiquement jamais utilisées avec TCP. Ces trames doivent être supportées aux deux extrémités de la liaison et ne garantissent pas le passage Ethernet ou le routage IP. Le récepteur TCP peut même forcer un émetteur TCP de mégatrames, d'envoyer des segments TCP plus petits en utilisant l'option de taille de segment maximal TCP correspondante. - Technique multicoeur : o traitement en paquets parallèles sur une unité CPU multicoeur améliore globalement et de façon considérable le débit de paquets d'un ordinateur. o Cette technique est seulement intéressante dans le cas de conversations par paquets indépendants. Une unique conversation telle qu'une connexion TCP ne bénéficie pas des multicoeur car ils doivent respecter la séquence des paquets qui finalement conduit à un traitement en série de paquets sur des multicoeurs et qui même se détériorent du fait des sauts de conversations entre les coeurs ; l'utilisation d'une mémoire cache de niveau 1 de coeur CPU et performances du système sont détériorés. - Implémentation de circuits TCP isolés (ASIC ou FPGA IP) : o des implémentations de circuits TCP isolés réalisent une implémentation complète mais non monolithique de piles TCP et IP dans le circuit. Une telle implémentation présente de façon caractéristique une forte intégration de TCP et de fonctionnalités IP vis-à-vis du protocole de résolution d'adresses comprenant le réseau (ARP). Il offre un simple flux de données d'interface vers la couche client et une base telle qu'une interface de contrôle vers la gestion de connexion. o Les données de la couche client traversent ces composants en valeur. Pour traiter un nombre raisonnable de connexions TCP seule dans des implémentations de circuits nécessite une mémoire de données privées, suffisante et une gestion de mémoire correspondante pour la retransmission et les mémoires de réorganisation. Comme la mémoire de données et la gestion de mémoire ne sont pas accessibles de l'extérieur, toutes les couches de client pour le service (en général XCP sur Ethernet) doivent implémenter leur propre schéma de mise en mise en mémoire. Cela se traduit par une augmentation du besoin de capacité, de mémoire. Un débit de déclenchement de bits élevé se traduit par une plus forte consommation de puissance dans le système. L'intégration serrée de TCP, IP et ARP en un composant monolithique complique le multiplexage du trafic par paquets, fondé sur le circuit et sur le programme. La couche client est l'une des nombreuses couches d'application auxquelles l'utilisateur accède dans une application. Une application peut demander n'importe quel type de client. Par exemple la communication de données entre l'unité ECU et un dispositif (en général un dispositif d'acquisition intégré) se fait dans la couche client. La couche de transport assure les services de communication de bout en bout pour les applications avec une architecture en couches des corn- u) posants de réseau et des protocoles. Par exemple, la communication de données entre un dispositif (en général un dispositif d'acquisition intégré) et un ordinateur personnel externe se fait dans la couche de transport. Le protocole de contrôle de transport standardisé (proto- 15 cole TCP) est un composant de base dans les modules d'interface néces- saires pour le transport fiable de données de mesure, de calibrage et de diagnostic (données MCD) échangées entre l'unité ECU et le programme d'application MCD. Des exigences de débit de données clients sortants ne peuvent être satisfaites par le paradigme courant de programme fon- 20 dé sur les fonctions de transport dans des modules d'interface d'unités ECU intégrées classiques avec des caractéristiques CPU nécessairement limitées. Les mêmes restrictions s'appliquent aux unités ECU elles-mêmes avec l'introduction de "l'Ethernet automotive". But de l'invention 25 La discussion des solutions disponibles pour l'accélération TCP montre qu'aucune des solutions connues ne résout le problème TCP spécifique dans les circuits d'un dispositif intégré d'acquisition de données moteur. C'est pourquoi la présente invention a pour but de développer une transmission de données, rapide et fiable 30 entre deux dispositifs d'une couche client et/ou d'une couche de trans- port d'un système de communication dans lequel la transmission des données se fait selon le protocole TCP. En particulier, l'invention a pour but de développer une transmission de données MCD rapide et fiable entre une unité ECU d'un moteur et un outil de programme de dévelop- 35 pement appliqué par exemple sur un ordinateur personnel.

Exposé et avantages de l'invention A cet effet, l'invention a pour objet un procédé de trans- mission de données entre deux dispositifs dans une couche client et/ou une couche de transport d'un système de communication selon lequel la transmission de données se fait selon le protocole de contrôle de transport appelé ci-après « protocole TCP », les données à transmettre sont enregistrées dans une mémoire centrale et en ce que le protocole de contrôle de transport TCP traite les références sur les données transportées et enregistrées dans la mémoire au lieu de la donnée elle- même. L'invention a également pour objet un système de communication pour la transmission de données entre deux dispositifs quelconques dans une couche client et/ou une couche de transport d'un système de communication selon lequel la transmission de don- nées se fait selon le protocole de contrôle de transport (protocole TCP) comprenant une mémoire centrale pour enregistrer les données à transmettre et un bloc de fonctionnement de protocole TCP pour traiter les références des données transportées enregistrées dans la mémoire à la place de la donnée elle-même.

Enfin, l'invention a pour objet un dispositif d'acquisition intégré, situé entre deux dispositifs quelconques d'un système de communication entre lesquels des données sont transmises dans une couche client et/ou une couche de transport du système de communication, le dispositif d'acquisition exécutant une transmission de don- nées selon le protocole de contrôle de transport (protocole TCP), caractérisé en ce qu'il comprend un bloc de traitement de protocole TCP pour traiter des références des données à transmettre et qui sont enregistrées dans une mémoire centrale du système de communication au lieu des données elles-mêmes.

En particulier, l'invention propose un procédé de trans- mission de données entre deux dispositifs quelconques d'une couche client et/ou d'une couche de transport d'un système de communication. La transmission des données se fait selon le protocole de contrôle de transport (protocole TCP), caractérisé en ce que les données à trans- mettre sont mémorisées dans une mémoire centrale et le bloc de traite- ment de protocole TCP traite les références des données transportées, références enregistrées dans la mémoire et non les données. De plus, le système de communication pour transmettre les données entre deux dispositifs quelconques dans d'une couche client et/ou une couche de transport d'un système de communication. La transmission de la donnée se fait selon le protocole de contrôle de transport (protocole TCP). Le système de communication est caractérisé en ce qu'il comprend une mémoire centrale pour enregistrer provisoirement les données à transmettre ainsi qu'un bloc de traitement de proto- cole TCP pour traiter les références des données à transporter, enregistrées dans la mémoire au lieu de traiter la donnée elle-même. Enfin, l'invention a pour objet un dispositif d'acquisition, intégré, situé entre deux dispositifs quelconques d'un système de communication entre lesquels s'échangent les données dans une couche client et/ou une couche de transport du système de communication. Le dispositif d'acquisition qui exécute la transmission des données selon le protocole de contrôle de transport (protocole TCP) est caractérisé en ce qu'il comporte un bloc de traitement de protocole TCP pour traiter les références des données à transmettre et qui sont enregistrées provisoi- rement dans une mémoire centrale du système de communication au lieu de s'appliquer aux données elles-mêmes. Dans le cadre de la présente description, les expressions « transmettre » ou « transmission » ou « transmis » sont des termes utilisés dans le sens de l'émission comprenant la transmission de données dans les deux directions (échange de données) et qui se compose de l'émission de données (ou de trames) dans une première direction et la réception de données (ou de trame) dans la direction opposée. Selon un développement préférentiel de l'invention, les données de mesure, de calibrage et de diagnostic sont transmises dans le système de communication entre d'une part une unité de commande électronique de moteur et d'autre part un outil de programme de développement de moteur fonctionnant sur un ordinateur personnel externe. La transmission des données est faite dans le dispositif d'acquisition TCP qui traite les références des données à transmettre et qui sont stockées provisoirement dans une mémoire centrale du système de communication. La solution présentée par l'invention réalise un débit TCP à la vitesse du câble sur une liaison Ethernet Gigabits et dépasse la res- triction spécifique liée aux petits systèmes intégrés. La terminaison du protocole TCP proposé est implémentée complètement dans un circuit et appelé TCP HW (protocole TCP en circuit). La conception est fondée sur les idées de base suivantes et les paradigmes : - Segmentation de la charge de données de la couche client : o la charge de données de la couche client est segmentée en tronçons de données de dimensions limitées. Les tronçons de données des différentes couches client sont imbriquées, ce qui permet à de multiples couches client d'utiliser une unique in- terface de données multi-canal vers la terminaison TCP PHW. Cela simplifie l'implémentation de moteur de protocole TCP fonctionnant virtuellement en parallèle traitant de multiples connexions simul- tanément pour de multiples applications de couches client. - Segmentation de la couche réseau de charge de données : o Les trames de la couche de réseau IP et de la couche de liaison Ethernet sont également segmen- tées en fragments de données de taille limitée. Les connexions terminées par le circuit TCP HW et autres connexions qui se terminent dans des piles de programmes peuvent facilement utiliser la même interface multi-canal vers le réseau. - Traitement de paquets par des protocoles concurrents : o les segments de charge de données de réseau et de client en série simplifient le traitement par des pro- tocoles concurrents pour de multiples connexions.

Les segments appartenant à différentes connexions sont traités en multiplex dans le temps en utilisant des techniques de sur-échantillonnage. o En implémentant un support de circuit pour éco- nomiser des états de traitement on peut éliminer le chapeau de commutation de contexte. Cette conception garantit que la puissance de traitement est disponible instantanément pour chaque paquet reçu à tout instant. o Comme chaque évènement de segment et de pa- quets est traité instantanément, on évite l'étranglement des évènements et la latence qu'elle entraîne. - Travail sur les références de données plutôt que sur les données elles-mêmes. o Les points d'extrémité TCP communiquent par des numéros de séquence TCP qui peuvent se dériver facilement des indicateurs de longueur de segment de données ; il n'est pas nécessaire que la fonction TCP compte en elle-même les octets de charge de données. o Les mémoires tampons de retransmission et d'enregistrement stockent les références de données plutôt que les valeurs des données elles-mêmes. Par exemple, en utilisant des descripteurs à huit octets pour les segments 228 ou de 256 octets ont diminue la quantité de stockage de données par un coefficient allant jusqu'à 32. Cela permet d'implémenter les mémoires tampons de base pour de multiples applications TCP utilisant en interne FPGA RAM qui économise de nombreuses de caractéristiques de trai- tement et de l'énergie. o La vitesse de déclenchement de bits sur les interfaces est largement réduite avec la transmission des références de données à la place des valeurs de données.

Cela est particulièrement vrai pour les interfaces externes avec de fortes capacités de broches. - Isolation par rapport à la couche réseau : o La fonctionnalité TCP est isolée de UDP, IP et ARP. o L'implémentation TCP devient plus légère et évite de multiples étapes de multiplexage de paquets vers la couche de liaison. Cela simplifie la coexistence de circuits et de piles de programmes. Dessins lo La présente invention sera décrite ci-après de manière plus détaillée à l'aide d'exemples de procédé de transmission de données entre deux dispositifs, ainsi que de systèmes de communication mettant en oeuvre ce procédé, représentés dans les dessins annexés dans lesquels : 15 - la figure 1 est un schéma d'un TCP standard réalisé par circuit connu selon l'état de la technique, - la figure 2 est un schéma d'un circuit TCP selon la présente invention, - la figure 3 montre un TCP intégré dans un composant 20 de circuit implémenté dans la solution selon la présente invention, - la figure 4 est un mode de réalisation de la structure logique d'une mémoire tampon de retransmission, - la figure 5 est un mode de réalisation de la structure logique d'une mémoire tampon de réorganisation, et 25 - la figure 6 est le TCP en circuit selon la présente in- vention en liaison avec un plan de données de circuits (circuits processeurs). Description de modes de réalisation de l'invention La figure 1 montre un TCP standard sous forme de cir- 30 cuit, connu selon l'état de la technique. En particulier, la figure montre une vue globale du système d'un dispositif d'acquisition 1, intégré avec un TCP seul dans un composant de circuit 2. Cette solution peut être implémentée sous la forme ASIC ou FPGAIP. La solution connue assure une implémentation complète mais monolithique de pile TCP/IP sous la 35 forme d'un circuit. Une telle implémentation présente de manière carac- téristique une intégration serrée des fonctionnalités TCP et IP vers le réseau de couche de liaison y compris le protocole de résolution d'adresse ARP. Il offre une simple interface de données en flux vers la couche client et une interface de contrôle de type base vers la gestion de connexion. Toutefois, les données de la couche client traversent ces composants en valeur qui est la donnée brute actuelle traitée. Pour traiter un nombre raisonnable de connexions TCP seules dans des implémentations sous forme de circuit, il faut suffisamment de mémoire de données privée (en général une mémoire tampon de base 3) et une ges- tion de mémoire tampon correspondante pour la retransmission et les mémoires tampons de réorganisation. Comme la mémoire de données 3 et la gestion de mémoire tampon ne sont pas accessibles de l'extérieur, toute couche client nécessitant le service (en général XCP sur Ethernet) doit implémenter ses propres schémas d'enregistrement provisoire. Cela conduit à une augmentation du besoin en mémoire. Une vitesse élevée de déclenchement de bits se traduit par une forte consommation de puissance par le système. L'intégration serrée de TCP, IP et ARP dans un composant monolithique complique le multiplexage et le démultiplexage du trafic par paquets fondé sur des circuits et des programmes.

A la figure 1, la référence 4 désigne les multi- plexeurs/démultiplexeurs de la couche client ; la référence 5 désigne un multiplexeur/démultiplexeur de paquets. La référence 6 désigne les services de sortie, élevés échangés entre le TCP dans le composant de circuit 2 et l'un des multiplexeurs/démultiplexeurs 4 de la couche client pour TCP; la référence 7 désigne les services à faible latence entre le TCP dans le composant de circuit 2 et l'un des multiplexeurs/démultiplexeurs 4 de la couche client pour UDP. La figure 2 montre un mode de réalisation préférentiel de la solution selon la présente invention. Il assure un débit TCP à la vi- tesse du câble sur une liaison Ethernet Gigabits et remédie à la restric- tion spécifique liée à de petits systèmes intégrés. Le terminal de protocole TCP proposé est complètement implémenté dans un circuit et c'est pourquoi il est appelé composant ou module TCP HW (TCP dans un circuit). La conception est fondée sur les idées de base et les para- digmes suivants : client. - Segmentation de la charge de données de la couche seau. - Segmentation de la charge de données ou couche ré- rents. - Traitement des paquets par des protocoles concur- - Traitement des références des données plutôt que des données elles-mêmes. - Isolation par rapport à la couche de réseau pour UDP, IP et ARP. A la figure 2, la référence 4 désigne le multiplexeur/démultiplexeur de la couche client ; la référence 11 désigne un multiplexeur/démultiplexeur multicouches. Le composant TCP HW (dispositif d'acquisition intégré) selon la présente invention porte la réfé- rence 10. La référence 6 se rapporte à des services à fort débit entre le composant TCPHW 10 et le multiplexeur/démultiplexeur 4 de la couche client. La référence 7 désigne des services à faible latence entre le bloc de données de protocole du moteur et le multiplexeur/démultiplexeur multicouches 11. La référence 12 désigne un tampon central (encore appelé : mémoire tampon) utilisé généralement dans toutes les couches de communication et servant à enregistrer les données brutes actuelles. Le tampon central 12 selon la présente invention remplace le tampon sur socle 3 et l'ensemble des tampons client de l'état de la technique selon la figure 1. Le composant TCPHW 10 selon la présente invention traite et manipule seulement les références des données enregistrées dans le tampon central 12 au lieu de traiter les données brutes actuelles. Les données brutes actuelles sont échangées directement entre IP/UDP et le bloc d'accès média Ethernet et le tampon central 12 sans jamais atteindre le composant TCPHW 10. Les traits interrompus entre les blocs fonctionnels de la figure 2 désignent une interface par réfé- rence avec une vitesse de déclenchement faible. Les traits pleins entre les blocs fonctionnels désignent une interface par sa valeur avec un coefficient de déclenchement bas. Enfin, les traits accentués entre les blocs fonctionnels désignent une interface par la valeur de son taux de déclenchement élevé.

La présente invention résout les problèmes de l'état de la technique en changeant le paradigme antérieur de l'implantation de protocole fondée sur un programme par une implémentation conséquente de circuits en parallèle, fondée sur des fonctions de transport.

La présente invention décrit les procédés des principes d'intégration à faible poids, qui peuvent être mis à l'échelle et à caractéristiques élevées pour des composants TCP fondés uniquement sur des circuits dans l'unité ECU 8, même, supportant l'Ethernet du moteur de véhicule (encore appelé automotive Ethernet). Ces principes et procédés sont la clé des différences par rapport à des TCP peut fiables, lourds dans les solu- tions avec circuits du marché dont aucun ne satisfait les exigences particulières des dispositifs intégrés dans des moteurs automobiles. Le protocole de contrôle de transport TCP répond aux exigences des clients pour un transport fiable des données de mesure, de calibrage et de diagnostic MCD entre un dispositif d'interface ECU, intégré et les ordinateurs personnels (PC) externe traitant un outils de programme d'application de mesure à l'état neuf en général mais le programme INCA de ETAS GmbH. Selon l'art antérieur, le protocole TCP est fourni fonction- nellement par le programme du système de fonctionnement sous-jacent soit QNX (marque déposée) par Research In Motion Corp (RIM) ou Linux intégré avec le dispositif intégré de Microsoft window (marque déposée) dans l'ordinateur PC. Les applications de mesure pour la génération suivante des unités ECU de moteur 8 exigent des vitesses de transport de don- nées de mesure d'au moins 30 Moctet/s ou plus. Les applications de prototype à faible latence et faible gigue doivent pouvoir coexister. On a constaté qu'une telle augmentation de débit de données selon un coefficient de 5 à 10 par rapport aux solutions cou- rantes peut uniquement se résoudre en supprimant le taux de trame à enlever, du programme et en implémentant la pile de protocoles dans un circuit. Le protocole TCP disponible sous la forme d'un circuit a été étudié et les résultats sont les suivants : - La seule solution ASIC existante (un maximum de 12,5 Moctet/sec) de WIZNET Corée ne peut recevoir une carte routière pour Ethernet Gigabits et il n'y a pas de seconde source. - Tous les réseaux FPGA fondés sur TCP en solution circuit sont des implémentations séparées nécessitant la mise en tam- pon de données, de façon privée pour TCP, ce qui augmente considérablement la complexité, le coût et la puissance consommée. Aucun d'eux n'assure un support étendu pour le service de multiplexage du côté client ou du côté réseau. La quantité de connexion à supporter est soit trop élevée soit trop faible. Certaines implémentations ont des caracté- ristiques qui font défaut ou ne sont même pas compatibles de façon standard. De plus, on ne peut contrôler la mise à l'échelle. La présente invention remédie à ces inconvénients par la réalisation d'une ou plusieurs des caractéristiques suivantes : - utiliser un tampon de données, unique, partagé avec les multiplexeurs client et côté couche de réseau ce qui réduit la consommation d'énergie et le coût. - Assurer une caractéristique à la vitesse du câble jusqu'à 125 Moctet/sec. - Réduire encore plus la consommation d'énergie en travaillant des pointeurs de données plutôt que les données brutes, ce qui réduit le taux de déclenchement du système par un coefficient allant jusqu'à 16. - Fournir des moyens ou une intégration sans disconti- nuité de TCP dans la solution circuit entre les protocoles de la couche supérieure (couche client) et le protocole de la couche inférieure (côté réseau). - Ne pas ajouter de latence ou de gigue pour les prototypes. - Autoriser la coexistence de circuits et de programmes fondés sur des piles de protocoles. - Avoir une mise à l'échelle contrôlable. La présente invention concerne des procédés d'intégration et des principes permettant une implémentation optimisée de TCP dans un circuit. Les éléments internes des fonctions TCP ont été développés à l'extérieur et c'est pourquoi ils ne font pas partie de l'invention. Le TCP dans le composant de circuit TCPHW 10 est pré- senté à la figure 3. Le composant 10 effectue une fonction standard compatible avec le protocole TCP. Il se branche sur la couche client 20 et le réseau 21 du plan de données et du plan de contrôle en utilisant les interfaces bien définies suivantes : - Interface de couche client 27. - Interface de couche réseau 28. - Interface de contrôle 29. - Interface de groupe de descripteurs 30. Ces interfaces sont traitées par les blocs principaux suivants : - Emetteur TCP 22 avec un retransmission 23. - Récepteur TCP 24 avec le réorganisation 25, et - Commande 26. Les blocs de construction sont interconnectés par les in- terfaces internes suivantes : - Interfaces commandes/état cmdstat. - Interfaces de connexion TCP tcpcon. Un descripteur est un conteneur pour transporter et stocker des références vers des tampons de données externes, par exemple le tampon central 12. Chaque descripteur décrit un unique segment client ou données de couche réseau de taille limitée. Il transporte l'information suivante : - Index du tampon. o un index défini par l'utilisateur vers un tampon de données externe. TCP transporte cette information de manière transparente. - Longueur du segment : o la longueur des données valables contenues dans ce segment. TCP utilise cette information pour cal- culer le nombre de séquences TCP. de construction tampon de tampon de - Décalage dans le segment : o Un décalage pointant vers le premier octet de charge de données valide dans la mémoire tampon. TCP transporte cette information de manière trans- parente. - Longueur du mot d'extension : o Longueur du mot d'extension défini par l'utilisateur. TCP transporte cette information de manière transparante. - Mot d'extension : o La couche client ou la couche réseau sont définies dans le mot d'extension. TCP transporte cette information de manière transparante. Les interfaces externes seront décrites ci-après.

L'interface de la couche client 27 est une interface bidi- rectionnelle, multicanaux reliant (n) fonctions TCP (connexions) du mo- dule TCPHW 10 avec les couches client. Et il se compose d'une interface de transmission de couche client 27.1 et d'une interface de réception de couche client 27.2. L'interface 27 transporte la charge payante client sous la forme de descripteur vers les segments de données de taille limi- tée. Chaque canal représente une connexion TCP fonctionnant indé- pendamment et chaque canal est imbriqué avec d'autres canaux sur un segment de base. L'interface de la couche client 27 est une interface maître/esclave. Le module TCPHW 10 est l'esclave. L'émetteur TCP 22 autorisé à refouler le trafic de l'interface réceptrice de la couche client 27.2 sur une base de canal. Ce refoulement peut être activé pour différentes raisons. La fenêtre de transmission de l'émetteur proche se ferme parce qu'il n'a pas reçu d'accusé de réception pour les trames perdues. - le récepteur de l'extrémité éloignée ferme la fenêtre TCP parce que les données reçues n'ont pas été traitées par l'extrémité éloignée, couche client. - La connexion TCP ralentit à cause de la congestion avec d'autres services ou d'autres connexions de l'interface Ethernet. - La connexion TCP réduit sa vitesse de traitement in- terne. Le récepteur TCP 24 doit tenir compte du refoulement par la couche client en ne vidant pas son tampon de réorganisation 25 et en réduisant la taille de la fenêtre de réception représenté à l'émetteur TCP à l'extrémité éloignée. L'interface de la couche réseau 28 est une interface mul- ticanaux bidirectionnelle reliant (n) fonctions TCP (connexions) du module TCPHW 10 à la couche réseau IP à l'interface Ethernet. Elle comprend une interface de transmission de couche réseau 28.1 et une interface de réception de couche réseau 28.2. L'interface 28 fonctionne par référence en transportant le segment de charge de données TCP sous la forme de descripteur de segments de données de taille limitée. Chaque canal représente une connexion TCP fonctionnant indépen- damment et il est imbriqué avec les autres canaux sur un segment pair de base. La segmentation et la classification du trafic TCP par l'adresse IP et le numéro de port ainsi que la cartographie des directions vers les canaux se font à l'extérieur du module TCPHW 10. Il est à remarquer que le module TCPHW 10 fait passer les segments reçus de la couche client (par l'interface couche client 27) vers la couche réseau (par l'interface de couche réseau 28) sans aucune modification, c'est-à-dire sans traiter les segments. La charge de données du segment TCP est transférée sui- vant sa référence. L'entête du segment TCP (entête de protocole TCP) est générée ou consommée par la fonction de protocole TCP et doit être transférée selon sa valeur. L'interface de couche réseau 28 est une interface maître- esclave dans laquelle le module TCPHW 10 fonctionne comme esclave. Il est à remarquer qu'il est différent des implémentations seules (voir fi- gure 1) dans lesquelles la couche IP est liée étroitement à la couche TCP et fonctionne comme un maître vis-à-vis de la couche de liaison fonctionnant comme esclave. L'émetteur TCP 22 doit répondre au refoulement tel qu'établi par la couche réseau sur une base par canal.

Le TCP 24 est autorisé à maintenir la pression vers la couche réseau soit pour le canal soit en commun pour tous les canaux. Pour éviter les interférences entre les mécanismes de commande des flux multiples (contrôle du flux de la couche de liaison avec des trames PAUSE Ethernet, la pression sur l'interface de couche réseau et la commande de flux de terminaison à terminaison TCP) il est recommandé de ne pas se fonder sur la pression en retour exercée sur l'interface de réception de la couche réseau 28.2. Le module TCPHW 10 doit être suffisamment rapide pour accepter n'importe quelle donnée de l'interface de la couche réseau 28 fonctionnant à la vitesse du câble. L'interface de commande 29 est une interface de registre de cartographie de mémoire vers le programme. Cette interface assure les services suivants : - activer/désactiver (de manière globale) o Le programme active ou désactive globalement tout le module TCPHW10. Défaut : désactivé. - Remise à l'état (mode global) o Le programme remet à l'état un module TCPHW 10 en fonctionnement à son état d'alimentation. Tous les registres sont chargés avec leurs valeurs par défaut. - Configuration de port local TCP (par connexion) o Met le port local TCP/IP sur une connexion don- née - Configuration de port TCP éloigné (par connexion) o Ouvert actif (client) met le numéro de port éloigné TCP. o Ouvert passif (serveur) : recueille le numéro de port TCP éloigné. - Commandes envoyées vers les protocoles TCP des moteurs (par connexion) o Le programme envoie l'un des ordres suivants vers le module TCPHW: * « ouvert passif » : met la machine d'état TCP en LISTEN. * « ouvert actif » : met la machine d'état TCP dans l'état SYN SENT. * « fermé » : ferme localement la connexion ; se traduit par une transition vers FIN WAIT1, CLOSE _WATT ou LAST ASK. * « supprimer Tcb » : remet immédiatement à l'état, la connexion et transfère la machine d'état TCP locale à l'état CLOSED. Si la connexion n'était pas déjà à l'état CLOSED ou TIME WAIT, cette action envoie également la commande TCP RST vers l'hôte éloigné. o Les ordres sont explicitement confirmés par le programme. - Etat du protocole TCP des moteurs (par connexion) o Le programme « lis » l'état courant de chaque connexion. Les états possibles sont les suivants : CLOSED, LISTEN, SYN RCVD, SYN SENT, ESTABLISHED, CLOSE WAIT, LAST ACK, FIN WAIT1, FIN WAIT2, CLOSING, TIME WAIT. - Maximum du segment envoyé (par connexion) o Le programme fixe la taille maximale du segment TCP envoyé par connexion. Défaut : 356 octets - Taille maximale du segment de réception (par connexion) o Le programme fixe la taille maximale du segment TCP de réception par connexion. Cette valeur est annoncée à l'extrémité éloignée pendant l'établissement de la connexion. Défaut : 1 480 octets. - Algorithme de Nagle : autoriser! interdire (par connexion) o Le programme neutralise l'algorithme de Nagle pour la connexion donnée autorisée. - Configurer l'algorithme d'accusé de réception retardé (par connexion) o Le programme utilise deux valeurs pour comman- der l'algorithme d'accusé de réception retardé : * Comptage d'accusé de réception (par connexion) définit le nombre de segments qui doivent avoir été reçus avant qu'un accusé de réception im- médiat ne soit envoyé. * Retard maximum (par connexion) définit le retard maximum d'attente de l'émetteur pour envoyé un accusé réception. - Notification et interruption courriels o Le module TCPHW envoie les notifications à syn- chrone suivantes vers des interruptions utilisant le programme : * Changement de l'état TCP par la commande hôte éloigné. * Changement de l'état TCP par un évènement de l'horloge. * Le TCP éloigné envoie FIN. * Le TCP éloigné envoie RST * L'horloge de retransmission lente commande une retransmission. * Retransmission rapide déclenchée. L'interface de descripteur de tampon 30 (ou inscripteur de descripteur global) : l'émetteur TCP 22 doit enregistrer les descrip- teurs jusqu'à ce que le segment correspondant a été confirmé par le ré- cepteur éloigné. Dès que l'accusé de réception est reçu, l'émetteur TCP 22 retourne les descripteurs (références) associés aux segments d'accusé de réception un descripteur commun externe par l'interface 30. Le récepteur TCP 24 ne doit pas, par ailleurs, envoyer deux fois le contenu TCP vers la couche client. Ainsi, le segment TCP reçu en double doit être dégagé en retournant les descripteurs associés vers le descripteur global externe. Il est à remarquer que ni le récepteur TCP 24 ni l'émetteur TCP 22 n'attribuent des descripteurs du descripteur global.

Dans tous les cas, lorsqu'une connexion est fermée soit par l'extrémité proche soit par l'extrémité éloignée, tous les descripteurs associés à cette description doivent être renvoyés au descripteur global externe. L'interface de descripteur tampon 30 est une simple in- terface de poignée de main synchrone qui assure l'unique service «tam- pon libre » avec deux paramètres associés : le tampon global et l'index du tampon dans ce tampon global. Le module TCPHW 10 se compose de trois blocs princi- paux. - L'émetteur TCP 22 et le tampon de retransmission 23. - Le récepteur TCP 24 et le tampon de réorganisation 25, et - Commande 26. Une brève description de « boîte noire » de ces blocs est donnée ci-après. La conception interne détaillée de ces blocs n'entre pas dans le cadre de l'invention. Toutefois les interfaces externes 27-30 sont des lignes de conduite définies de base pour la réalisation comme décrit ci-dessus. L'émetteur TCP 22 et le tampon de retransmis- sion 23 : L'émetteur TCP 22 applique le protocole TCP standard de traitement de connexions multiples selon la norme IETF (Internet Engineering Task Force). Les connexions se font simultanément. L'émetteur TCP 22 maintient un tampon de retransmission 23 pour chaque connexion. Le tampon 23 enregistre les segments TCP. Dans chaque segment TCP est formé une liste de références vers les tampons de données situés dans un stockage de données externe, par exemple un tampon central 12 qui ne fait pas partie du module TCPHW 10. Ces références viennent de la couche client et sont encapsulées dans une structure de descripteur comme décrit ci-dessus.

Le tampon de retransmission 23 tel que présenté à la figure 4 a trois zones de base : - Tampon libre 40 (partie avec des hachures de traits continus) qui n'a pas encore été rempli par la couche client. - Tampon occupé 41 (en pointillé) avec des segments TCP déjà envoyés et attendant l'accusé de réception par le récepteur TCP à l'extrémité éloigné. Ces segments TCP sont conservés jusqu'à leur retransmission ou l'accusé de réception. L'élément SN attendu (ExpectedSN), variable de l'émetteur TCP correspond au début de cette zone. Cet élément est mis à jour à la réception d'un nouveau nu- méro de séquence d'accusé de réception. Les segments TCP dont la réception a été accusée, changent leur couleur qui passe à « des hachures » à la « forme ombrée avec ligne continue » et deviennent libres. Toutes les références associées à un segment TCP doivent être renvoyées aussi rapidement que possibles au descripteur global externe en utilisant l'interface de descripteur global pour servir de nouveau ultérieurement. - Tampon occupé 42 (hachuré par des traits en pointil- lés) avec des données qui, si disponibles, sont autorisées à être émises.

Le début de cette zone est marqué par NextSN, variable, de l'émetteur TCP. L'indication NextSN est incrémentée après l'envoi du segment TCP vers la couche réseau. La couleur du segment TCP change et passe de l'état « ombrée avec des lignes interrompues » à l'état « en pointillés ». Toutes les références appartenant au segment TCP correspondant ap- partiennent maintenant au module TCPHW jusqu'à ce qu'il soit confir- mé et libéré. La figure 4 montre la structure logique du tampon de re- transmission 23. Les entrées su tampon 23 sont indexés par les numéros de séquence TCP. L'émetteur TCP 22 construit des numéros de séquence en ajoutant les indicateur de longueur, reçus dans les des- cripteurs de la couche client jusqu'à la taille maximale de segments MMS d'un segment TCP ou de cette longueur pratiquement atteinte. Le comportement détaillé dépend des réglages de l'algorithme Nagle. Si l'algorithme est activé, les données sont collectées comme décrit ci- dessus. Si l'algorithme est coupé, l'émetteur TCP peut ou non collecter les données du client dans des segments TCP en fonction de la vitesse. Il est à remarquer qu'il n'est pas possible de remplir de manière optimale un segment TCP car en additionnant la longueur du segment suivant reçu Si de la couche client, on peut dépasser la taille maximum de segment MMS. Toutefois, la couche client peut fragmenter des segments Si virtuellement en sous-segments Si et Si2. Les deux sous-segments transportent le même index de tampon mais utilisent un indice différent dans le même tampon externe de données, en général le tampon central 12. La taille physique du tampon de retransmission 23 doit être suffisamment grande pour contenir suffisamment de références de données pour la taille de fenêtre TCP utilisée allant de 0 à un minimum (cwnd, rwnd) ; cwnd est la fenêtre de congestion TCP et rwnd désigne la taille de la fenêtre de réception annoncée par le récepteur TCP à l'extrémité éloignée. En supposant qu'il n'y a pas de congestion, un petit ré- seau local avec une faible erreur de bits dimensionne la taille minimum du tampon de retransmission à supporter pour être dominé par un temps de retour de boucle R77' relativement faible et le débit souhaité R pour la connexion TCP: Beff = R * RTT Exemple : Avec R = (30-125) Octet/s, RTT = (0.5 à 1) ms, il faut une taille de Beff = (15-125) kOctet. La demande en capacité de mémoire pour le descripteur physique dépend de la taille maximum du segment de la couche TCP mss et de la longueur minimum du segment de la couche client ms/: Beff mss =- 31 - * k mss ms/ Dans cette formule k est la taille d'un descripteur. La valeur de k diffère d'un segment TCP à l'autre. La fragmentation est faite par la couche client. Exemple : Pour mss = 1 460 octets, ms/ = 64-256 octets et k = 64 bits, le stockage physique pour les références varie entre 480 et 16 000 octets pour la plage calculée ci-dessus de la taille effective de tampon. On peut réduire considérablement par un coefficient allant jusqu'à 24. Le récepteur TCP 24 et le tampon de réorganisation 25 : le récepteur TCP 24 effectue le traitement de protocole TCP classique pour les connexions multiples selon le standard IETF. Les connexions fonctionnent en parallèles. Le récepteur TCP 24 maintient un tampon de réorganisation 25 pour chaque connexion. Ce tampon enregistre les segments TCP. Chaque segment TCP est composé d'une liste de réfé- rences pour les tampons de données situés dans une mémoire de don- nées, externe, par exemple le tampon central 12 ne faisant par partie du module TCPHW 10. Ces références viennent de la couche réseau et sont encapsulées dans une structure de descripteur comme indiqué ci-dessus.

Le tampon de réorganisation 25 tel que représenté à la fi- gure 5 comporte trois zones de base : - Tampon libre 50 (en hachures continues) qui dépasse la taille définie du tampon de réception de base et qui n'est pas utilisé normalement. - Tampon occupé 51 (en pointillés) avec des segments TCP déjà reçus. Les données n'ont pas encore été consommées par la couche client. Ce tampon 51 contient les segments attendant d'être consommés par le client. Ces segments TCP sont conservés jusqu'à la fin de la réorganisation. Un pointeur de lecture oldSN marque le début de cette zone 51. Il avance lorsque la couche client lit les données en changeant la couleur des segments (en hachures entrée continue). - Tampon libre 52 (en hachures à traits interrompus) qui reçoit les nouvelles données du réseau. Un pointeur d'inscription newSN marque le début de cette zone. Il est incrémenté à la réception des segments TCP de la couche réseau en changeant la couleur des segments pour passer des hachures en traits interrompus à des hachures sous forme de pointillés. L'enregistrement des trames se fait dans la zone hachu- rée en pointillés. Le pointeur lit oldSN seulement lorsqu'il avance et seulement s'il n'y a pas de numéros de séquence manquants entre la position courante et la position suivante possible. La figure 9 montre la structure logique du tampon de réorganisation 25. Le tampon 25 reçoit en entrée les adresses par les numéros de séquence TCP. Ces numéros de séquence sont reçus dans l'entête TCP qui est transférée en valeur. Avant d'entrer dans le récepteur TCP, le segment TCP est fragmenté en tronçons de données de taille limitée. Les références au stockage externe de données correspondant par exemple le tampon central 12 sont encapsulées dans des descripteurs.

La taille du tampon de réorganisation 25 doit être suffi- samment grande pour enregistrer les références correspondant à la taille maximale de la fenêtre de réception (taille du tampon de réception de base). La taille de la fenêtre de réception est dimensionnée suivant la zone hachurée par des pointillés.

En supposant une taille de fenêtre de réception (tampon de base) de 16-64 kOctets et une longueur caractéristique de segments de 128 octets pour le trafic réseau se terminant sur TCT, jusqu'à 128 ou 512 descripteurs ayant chacun par exemple 64 bits à enregistrer dans le tampon de réorganisation 25 ce qui se traduit par un espace de stockage physique de descripteur d'une capacité de 1 à 4 kOctets. Le bloc de commande assure une interface de programmation basée sur un registre pour le programme. Le registre contrôlé par programme fournit en sortie les fonctions spécifiques de contrôle à l'émetteur TCP et hors récepteur TCP en général la remise à l'état, l'initialisation d'une connexion sortant et la notification de connexion entrant ou de signaux d'erreurs. Il réalise également l'interface pour collecter les valeurs statistiques des fonctions de plans de données du module TCPHW (émetteur TCP et récepteur TCP). Pour capturer un jeu cohérent de va- leurs statistiques au même instant exact, le programme lance d'abord un cycle de capture en mettant à l'état une entrée de registre appropriée. La fonction de commande répartit cet ordre comme impulsion de capture dans les fonctions de plan de données. Les fonctions de plan de données capturent les valeurs de comptage courantes en utilisant cette impulsion de capture dans les registres cachés correspondants, qui sont visibles dans le programme par la fonction de contrôle. Les interfaces internes comportent un ordre d'état d'interface cmdstat et de connexion TCP d'interface tcpcon. L'ordre d'état d'interface cmdstat transporte un ordre et une information d'état entre les registres de contrôle des fonctions de contrôle et l'émetteur TCP et le récepteur. Il fournit également des moyens pour capturer un ensemble cohérent de valeurs statistiques comme décrit ci-dessus. L'interface de connexion tcpcon transporte toutes les informations locales émetteur/récepteur : - Les numéros de séquences d'accusés de réception du récepteur vers l'émetteur. - L'avertissement de taille de fenêtre de réception envoyé par le récepteur à l'émetteur. - L'information nécessaire à implémenter une machine d'état de connexion TCP, répartie, concernant à la fois l'émetteur TCP et le récepteur TCP. La figure 6 montre comment le module TCPHW 10 coo- père avec un plan de données de circuits multicouches (processeur de données) dans le sens de l'émission TCP. Le plan de données de circuits multicouches exécute les fonctions de multiplexage côté client et côté réseau au-dessus et en-dessous du module TCPHW 10 selon la figure 2. Le multiplexage côté client de la figure 2 se fait dans un premier chemin de traitement (chemin 1) et la fonction de multiplexage multicouche de la figure 2 se fait dans un second chemin de traitement (chemin 2).

La donnée client actuelle est inscrite EARLY dans le tam- pon central 12 avant le traitement TCP et il lit LATE dans le tampon central 12 après le traitement TCP. Le multiplexage et le traitement de protocole TCP sont ef- fectués sur les pointeurs (descripteurs) plutôt que sur les données elles- mêmes. A la figure 6 la référence 60 désigne un noeud d'application. La référence 61 désigne un module d'interface ECU et un noeud de transport ; la référence 62 désigne un noeud de simulation. En outre à la figure 6, les flèches en traits continus indiquent un transfert de données, par exemple 128 octets par intervalles de temps T et en général 128 oc- tets/0,2 ps = 640 MOctet/s. Les flèches en traits interrompus désignent le traitement de pointeur, par exemple (8...10) Octet par intervalle de temps T en général 8 octets/0,2 ps = 40 MOctet. Cela se traduit par une réduction par un coefficient 16 de la vitesse de traitement. Enfin, il y a une liste d'idées clés sur lesquelles est fondée l'invention. Le module TCHW selon la présente invention réalise une ou plusieurs des idées clés suivantes : - Usage commun du tampon de données dans toutes les couches de communication o Les autres solutions communes implémentent une gestion dédiée de tampons pour TCP. o Economise du coût et de l'énergie. - Isolation de la couche transport TCP par rapport à la couche réseau IP o Les autres solutions connues relient TCP à HW étroitement à la couche réseau IP et à la couche liaison (Ethernet). o Autorise/simplifie la coexistence d'un circuit et d'une pile de protocole de programmes. o Autorise/simplifie la coexistence des différentes couches de transport au-dessus de la couche ré- seau commune. - Travail sur les références des données plutôt que sur les données brutes à elles-mêmes. o Les autres solutions connues basculent avec chaque octet de données. o Réduction de la vitesse de déclenchement logique d'un facteur allant jusqu'à 16 (déclenchement avec un segment de données). - Segmentation de la couche client et des trames de la couche réseau o Les autres solutions connues fonctionnent sur des blocs de données plus grands (trames) conduisant à une gigue plus importante sur le trafic non TCP en temps réel. o Réduction de la gigue du système. - Le tampon de retransmission TCP et de réorganisation rétrécit en enregistrant les références des données transportées plutôt que les données elles-mêmes. lo o Les autres solutions connues enregistrent les don- nées brutes. o Economise de la mémoire en utilisant des ressources dédiées plus efficacement. - Interfaces en coopération (en série). 15 o Simplifie l'implémentation coopération de multiples instances. - Utilisation d'un descripteur global externe par de multiples couches de protocole. o Economise la mémoire en partageant la ressource 20 avec d'autres fonctions. - Gestion du numéro de séquence fondé sur des indications de longueur plutôt que sur le comptage de la longueur des données. o Plus grande transparence pour l'implémentation du 25 protocole client. - Sous fragmentation de la couche client en option, pour optimiser l'utilisation du segment TCP.

Claims (9)

1. REVENDICATIONS1°) Procédé de transmission de données entre deux dispositifs dans une couche client et/ou une couche de transport d'un système de communication selon lequel la transmission de données se fait selon le proto- cole de contrôle de transport « protocole TCP », procédé caractérisé en ce que les données à transmettre sont enregistrées dans une mémoire centrale (12) et le protocole de contrôle de transport TCP (10) traite les références des données transportées et enregistrées dans le moyen de mémoire (12) au lieu des données elles-mêmes.
2. 2°) Procédé selon la revendication 1, caractérisé en ce que les données de mesure, de calibrage et de diagnostic sont transmises dans le système de communication entre d'une part une unité de com- mande électronique du moteur (8) et d'autre part un outil de programme de développement de moteur (9) qui s'exécute sur un ordinateur personnel externe.
3. 3°) Procédé selon la revendication 1 ou 2, caractérisé en ce que la mémoire centrale (12) est utilisée dans toutes les couches de communication.
4. 4°) Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que les données sont transmises dans des trames de données et en ce que les trames de couche client et les trames de couche réseau sont segmentées en fragments de données plus petits, avant d'être transmises.
5. 5°) Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que le bloc de contrôle de transport TCP (10) comporte une mémoire de retransmission (23) et les références des données transportées sont enre-gistrées dans la mémoire de retransmission (23) au lieu des données elles-mêmes.
6. 6°) Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que le bloc de contrôle de protocole TCP (10) comporte une mémoire de réorganisation (25) et les références des données transportées sont enregistrées dans la mémoire de réorganisation (25) à la place des données elles-mêmes.
7. 7°) Système de communication pour la transmission de données entre deux dispositifs quelconques dans une couche client et/ou une couche de transport d'un système de communication selon lequel la transmission des données se fait selon le protocole de contrôle de transport « protocole TCP », système caractérisé en ce qu' il comprend une mémoire centrale (12) pour enregistrer les données à transmettre et un bloc de fonctionnement protocole TCP (10) pour traiter les références des données transportées enregistrées dans la mé- moire (12) à la place des données elles-mêmes.
8. 8°) Système de communication selon la revendication 7, caractérisé en ce que les données de mesure, de calibrage et de diagnostic sont transmises dans le système de communication entre d'une part une unité de com- mande électronique du moteur (8) et d'autre part un outil de programme de développement de moteur (9) qui s'exécute sur un ordinateur personnel externe.
9. 9°) Système de communication selon la revendication 8, caractérisé en ce qu' il comprend un dispositif d'acquisition intégré (1) situé entre l'unité de commande électronique du moteur (8) et l'outil de programme de développement (9) et le bloc de traitement de protocole TCP (10) fait partie du dispositif d'acquisition, intégré (1).10°) Système de communication selon la revendication 8 ou 9, caractérisé en ce que le système de communication est en particulier un dispositif d'acquisition intégré (1) situé entre l'unité de commande électronique du moteur (8) et l'outil de programme de développement (9) et il comprend un moyen pour appliquer le programme selon l'une des revendications 3 à 6. 11°) Dispositif d'acquisition intégré (1) situé entre deux dispositifs quel- conques d'un système de communication entre lesquels des données sont transmises dans une couche client et/ou une couche de transport du système de communication, selon lequel le dispositif d'acquisition (1) exécute une transmission de données selon le protocole de contrôle de transport « protocole TCP », dispositif d'acquisition (1) caractérisé en ce qu'il comprend un bloc de traitement de protocole TCP (10) pour traiter les références des données à transmettre et qui sont enregistrées dans une mémoire centrale (12) du système de communication au lieu des données elles-mêmes. 12°) Dispositif d'acquisition, intégré (1) selon la revendication 11, caractérisé en ce que les données de calibrage et de diagnostic sont transmises dans le système de communication et le dispositif d'acquisition (1) est situé entre d'une part une unité de commande électronique du moteur (8) et d'autre part un outil de programme de développement du moteur (9), et qui est exécuté par un ordinateur personnel externe. 13°) Dispositif d'acquisition, intégré (1) selon la revendication 11 ou 12, caractérisé en ce que le dispositif d'acquisition (1) comprend des moyens adaptés pour exécu- ter le procédé selon l'une des revendications 3 à 6.