FR2812437A1 - Procede et dispositif de communication entre un equipement exterieur a un vehicule automobile et des calculateurs embarques - Google Patents

Abstract

L'invention propose un proc ed e et un dispositif de communication entre un equipement (30) ext erieur à un v ehicule automobile (1) d'une part et des calculateurs embarqu es (10) reli es entre eux par au moins un bus CAN (11) d'autre part, dans lequel l' equipement (30) est connect e à un bus USB (31), dans lequel un module de couplage (20) est connect e au bus CAN (11) de manière à eviter la g en eration de r eflexions electriques sur celui-ci et forme passerelle entre le bus CAN (11) et le bus USB (31), en vue de la transmission de trames CAN entre l' equipement (30) et les calculateurs (10) en sorte qu'un programme d'application s'ex ecutant dans l' equipement (30) est vu sur le bus CAN (11) comme un abonn e CAN.

Description

<Desc/Clms Page number 1>

PROCEDE ET DISPOSITIF DE COMMUNICATION ENTRE UN
EQUIPEMENT EXTERIEUR A UN VEHICULE AUTOMOBILE
ET DES CALCULATEURS EMBARQUES
La présente invention se rapporte à un procédé et à un dispositif de communication entre un équipement extérieur à un véhicule automobile et des calculateurs embarqués.

Elle s'applique au domaine des systèmes électroniques pour l'automobile, et en particulier à celui des systèmes de diagnostic embarqué ou systèmes OBD (de l'anglais On Board Diagnostic ). Les véhicules automobiles comprennent de plus en plus de calculateurs dédiés à la gestion de fonctions déterminées telles que le contrôle moteur, le freinage, la transmission, l'essuyage des vitres, la climatisation ou le chauffage/ventilation, etc... Afin d'alléger les liaisons électriques à bord du véhicule, ces calculateurs sont reliés entre eux par un ou plusieurs bus de données, notamment de type CAN (de l'anglais Controller Area Network ).

La mise en #uvre d'un bus CAN respecte les spécifications de la Norme ISO n 11898 version V2.0A (version standard) ou V2.OB (version étendue) du 15/11/1993 et de son amendement n 1 du 01/04/1995 (ci-après la norme CAN). Sur requête, les calculateurs embarqués peuvent émettre sur le bus CAN des messages de diagnostic embarqué, ci-après messages OBD, selon le protocole du bus CAN, pour signaler des défauts ou des dysfonctionnements.

Dans l'état de la technique, un système de diagnostic embarqué comprend une station de diagnostic distante, comme étant extérieure au véhicule, qui peut être reliée à un calculateur déterminé du véhicule par l'intermédiaire d'une ou de plusieurs liaisons de type série, en général spécifiques du constructeur du véhicule, et proches de la norme RS232C. Ce calculateur, qui est par ailleurs dédié à la gestion d'une fonction déterminée du véhicule, comporte une prise de diagnostic sur laquelle un câble supportant la liaison de type série peut être connecté de manière à relier le calculateur à la station de diagnostic. Il comporte en outre des moyens pour recevoir les messages OBD selon le protocole du bus CAN en provenance de tous les autres calculateurs, et pour émettre des informations de diagnostic vers la station de diagnostic via la liaison de type série, selon un protocole propre à cette liaison.

<Desc/Clms Page number 2>

Toutefois, un tel système n'est pas pleinement satisfaisant dans la mesure où tous les messages OBD doivent être traités par ledit calculateur déterminé, qui doit pour ce faire disposer d'une capacité de traitement adaptée, et est donc complexe et coûteux.

C'est pourquoi il serait avantageux de pouvoir relier la station de diagnostic distante directement au bus CAN afin qu'elle puisse recevoir les messages OBD émis par les calculateurs selon le protocole du bus CAN et non des informations de diagnostic qui en sont dérivées.

Toutefois, le bus CAN est constitué par une ligne différentielle adaptée en impédance à chacune de ses extrémités, à laquelle les abonnés (calculateurs) sont reliés par un tronçon de câble ( Cable Stub , selon la terminologie de la norme CAN). Selon les prescriptions de la norme CAN, la longueur d'un tel tronçon de câble ne doit pas être supérieure à 30 centimètres pour limiter la génération de réflexions électriques sur le bus CAN. Il n'est donc pas possible de relier de cette façon la station de diagnostic au bus CAN, sachant que la longueur de cette liaison est typiquement de l'ordre de 4 mètres. En effet, les réflexions électriques engendrées sur le bus CAN mettraient en cause la fiabilité du transfert des données, en particulier pour les transferts à haut débit (600 Kbits/s) requis pour le diagnostic.

Un bus USB (de l'anglais Universal Sériai Bus ) est un bus de type série qui fait l'objet d'une spécification commune élaborée par les sociétés Compaq Computer Corporation, Intel Corporation, Microsoft Corporation, et NEC Corporation, et dont la dernière révision 1. 1 est datée du 23 septembre 1998 (ci-après la spécification USB). C'est un bus de type maître/esclave, à répartition de bande passante, sans gestion de priorité des messages. Dans la terminologie de la spécification USB, le maître est appelé un hôte ( host en anglais) et les esclaves sont appelés des dispositifs ( devices en anglais) soit de type fonctionnel soit de type répéteur. Selon la terminologie de la spécification USB, les premiers dispositifs sont appelés functions et les seconds sont appelés hub . L'hôte est un ordinateur hôte dans lequel est installée une interface USB ( host contrôler selon la terminologie de la spécification USB). Il comprend une plate-forme matérielle (unité centrale de calcul, bus interne, mémoire vive, etc...) et un système d'exploitation. Un

<Desc/Clms Page number 3>

dispositif fonctionnel assure une fonctionnalité de l'hôte. Il s'agit d'une unité périphérique telle qu'une souris, des hauts parleurs, etc... ou d'une connexion extérieure telle d'une connexion RNIS. Un dispositif répéteur permet la connexion d'autres dispositifs au bus USB. L'unité de données manipulée par le protocole du bus USB est appelée un paquet (ci-après paquet USB). Un paquet USB comporte trois éléments : un en-tête contenant des informations de commande (par exemple la source, la destination et la longueur du paquet), les informations utiles à transmettre, et des bits de détection et de correction d'erreur.

A l'inverse, le bus CAN est de type multi-maître, à temps de latence garanti, avec une gestion de priorité des messages permettant un arbitrage en cas de conflit d'accès. L'unité de données manipulée par le protocole du bus CAN est appelée une trame (ci-après trame CAN).

L'invention a pour objet de permettre à un équipement distant tel qu'une station de diagnostic extérieure au véhicule, de recevoir les messages OBD émis par les calculateurs embarqués selon le protocole du bus CAN, sans encourir le risque de réflexions électriques sur le bus CAN.

Ce but est atteint, conformément à l'invention, grâce à un procédé de communication entre un équipement extérieur à un véhicule automobile d'une part et des calculateurs embarqués reliés entre eux par au moins un bus CAN d'autre part, comprenant les étapes consistant à : - encapsuler, au niveau de l'équipement ou au niveau d'un module de couplage connecté d'une part au bus CAN de manière à éviter la génération de réflexions électriques sur celui-ci et d'autre part à un bus USB, une trame CAN émise selon le protocole du bus CAN par l'équipement ou par un calculateur respectivement, dans au moins un paquet USB selon le protocole du bus USB ; - émettre, via le bus USB, le paquet USB vers le module de couplage ou vers l'équipement respectivement ; - recevoir, au niveau du module de couplage ou au niveau de l'équipement respectivement, le paquet USB et le décapsuler pour en extraire la trame CAN, en sorte qu'un programme d'application s'exécutant dans l'équipement est vu sur le bus CAN comme un abonné CAN.

<Desc/Clms Page number 4>

L'équipement étant par exemple un ordinateur comprenant par construction des moyens de gestion d'un bus USB on peut ainsi réaliser à faible coût un dispositif de communication entre l'équipement et les calculateurs embarqués.

En effet, l'invention propose également un dispositif de communication entre un équipement extérieur à un véhicule automobile d'une part et des calculateurs embarqués reliés entre eux par au moins un bus CAN d'autre part, dans lequel l'équipement est connecté à un bus USB, le dispositif comprenant un module de couplage connecté d'une part audit bus CAN de manière à éviter la génération de réflexions électriques sur celui-ci et d'autre part audit bus USB et comprenant des moyens pour transmettre, via le bus USB, des trames CAN entre l'équipement et les calculateurs de manière qu'un programme d'application s'exécutant dans l'équipement est vu sur le bus CAN comme un abonné CAN.

L'invention propose en outre un système de diagnostic embarqué pour véhicule automobile comprenant : - des calculateurs embarqués, reliés entre eux par au moins un bus CAN et pouvant envoyer ou recevoir par l'intermédiaire dudit bus CAN des messages de diagnostic embarqué sous la forme de trames CAN ; - une station de diagnostic extérieure au véhicule automobile, reliée à un bus USB ; - un dispositif de communication tel que défini ci-dessus, de manière qu'un programme d'application s'exécutant dans la station de diagnostic est vu sur le bus CAN comme un abonné CAN.

D'autres caractéristiques et avantages de l'invention apparaîtront encore à la lecture de la description qui va suivre. Celle-ci est purement illustrative et doit être lue en regard des dessins annexés, sur lesquels on a représenté : - à la figure 1, le schéma d'un système selon l'invention ; - à la figure 2, le schéma de la topologie d'un premier mode de réalisation d'un dispositif selon l'invention ; - à la figure 3, le schéma fonctionnel d'un module de couplage selon l'invention ;

<Desc/Clms Page number 5>

- à la figure 4, le schéma de la topologie d'un second mode de réalisation d'un dispositif selon l'invention.

Dans la présente description et aux figures, les mêmes éléments portent les mêmes références.

A la figure 1, on a représenté le schéma d'un système selon l'invention.

Un véhicule automobile 1 comprend une pluralité de calculateurs embarqués 10 qui assurent respectivement la gestion d'une fonction déterminée telle que le contrôle moteur (par exemple un calculateur pour l'injection d'essence), le freinage (par exemple un calculateur pour un système d'anti-blocage des roues dit ABS de l'anglais Anti-Blocking System ), la climatisation, la transmission automatique, etc... Les calculateurs 10 sont reliés entre eux par un bus CAN portant la référence 11. Plus particulièrement, chaque calculateur est relié au bus CAN par l'intermédiaire d'une prise d'interconnexion 13 et d'un tronçon de câble 14.

Un équipement 30 extérieur au véhicule 1, tel qu'une station de diagnostic, est relié à un bus de type série déterminé portant la référence 31.

En pratique, le bus 31 est supporté par un câble, de préférence protégé des rayonnements électromagnétiques, dont la longueur est supérieure à 30 centimètres et peut atteindre 4 mètres. L'équipement est donc distant du bus CAN et de ses calculateurs. Une station de diagnostic se présente classiquement sous la forme d'un ordinateur de type PC (de l'anglais Personel Computer ) dans lequel est exécuté un programme d'application ad-hoc sous la commande d'un opérateur. C'est pourquoi le bus 31 est de préférence un bus USB. En effet, les matériels et les logiciels permettant la gestion d'un bus USB sont la plupart du temps déjà présents dans les ordinateurs de type PC actuellement disponibles. Le choix d'un bus USB pour le bus 31 est donc avantageux car il permet la réalisation d'un dispositif de communication entre l'équipement 30 et les calculateurs 10 qui soit de faible coût.

Selon l'invention, un tel dispositif comprend un module de couplage 20 connecté au bus CAN de manière à éviter la génération de réflexions électriques sur celui-ci. Le module 20 étant plus particulièrement relié au bus CAN par l'intermédiaire d'un tronçon de câble 28 et d'une prise

<Desc/Clms Page number 6>

d'interconnexion ou prise de diagnostic 21 (voir figure 2), la norme CAN indique que ceci est obtenu en faisant en sorte que la longueur du tronçon de câble 28 soit au plus égale à 30 centimètres. Dit autrement, le module 20 est situé à proximité du bus CAN, cette notion de proximité et celle de distance devant être interprétées à la lumière de la norme CAN. En pratique, le module 20, qui comporte des éléments matériels et des éléments logiciels, est implanté de manière fixe ou amovible à l'intérieur du véhicule 1, par exemple sous le capot moteur, de manière à être facilement accessible. Pour procéder à une opération de diagnostic, la station de diagnostic 30 est approchée du véhicule 1 et le câble 31 est relié à la prise de diagnostic 21. Le programme d'application est alors exécuté dans la station de diagnostic. Celle-ci transmet des messages OBD selon le protocole du bus CAN pour requérir la transmission en réponse, par les calculateurs 10, de messages OBD selon le protocole du bus CAN. Les messages OBD contiennent des informations de diagnostic et sont transmis sous forme de trames CAN entre la station de diagnostic 30 et les calculateurs 10 via le bus USB.

A la figure 2, on a représenté schématiquement la topologie d'un dispositif de communication selon un premier mode de réalisation.

Le bus CAN 11 présente une forme générale rectiligne. Il s'agit en pratique d'une ligne différentielle refermée à chacune de ses extrémités 12 par une impédance de 120 Ohms. De la sorte, l'impédance du bus CAN est, aux défauts d'adaptation près, constante sur toute la ligne et égale à 60 Ohms. Les calculateurs 10 et le module de couplage 20 sont connectés au bus CAN de manière à éviter la génération de réflexions électriques, par l'intermédiaire de tronçons de câble respectivement 14 et 28 et d'une prise d'interconnexion respectivement 13 et 21. La prise 21, aussi appelée prise de diagnostic, peut être située à une des extrémités 12 du bus CAN 31, ou entre ces deux extrémités. Le module de couplage 20 est un abonné du bus CAN, au même titre que les calculateurs 10. Il est aussi un dispositif fonctionnel du bus USB, dont l'hôte est l'équipement 30. Il remplit une fonction de passerelle entre le protocole du bus CAN et celui du bus USB. De préférence, le module de couplage 20 est connecté au bus CAN par l'intermédiaire d'une prise de diagnostic 21 située à une extrémité 12 du bus CAN.

<Desc/Clms Page number 7>

Deux liaisons logiques unidirectionnelles sont établies, via le bus USB, entre le module de couplage 20 et l'équipement 30, à raison d'une pour chaque sens de transmission. Pour décrire ces liaisons logiques, il est nécessaire d'introduire la notion de point terminal.

Un point terminal ( endpoint selon la terminologie de la spécification USB), est une abstraction du protocole du bus USB désignant une portion d'un dispositif USB repérée par une adresse unique, qui délivre ou collecte les informations d'un flot d'informations entre l'hôte et ledit dispositif USB. L'hôte et les dispositifs USB comportent chacun un point terminal bidirectionnel pour la transmission d'informations de contrôle (le endpoint 0 ) et au moins quatre points terminaux unidirectionnels pour la transmission des paquets USB (les endpoints 1 à 4). Dans un exemple le endpoint 1 est utilisé pour le transfert de données, via le bus USB, du module de couplage 20 (dispositif USB) vers l'équipement 30 (hôte), alors que le endpoint 2 est utilisé pour le transfert de données, via le bus USB, de l'équipement 30 (hôte) vers le module de couplage 20 (dispositif).

Dans le cas d'un dispositif selon un second mode de réalisation, dont la topologie est représentée par le schéma de la figure 4, les calculateurs embarqués 10 sont reliés entre eux par l'intermédiaire de deux bus CAN indépendants l'un de l'autre, portant respectivement la référence 11 a et la référence 11 b. Le dispositif comprend alors un premier module de couplage 20a connecté au premier bus CAN 1 la d'une part et à une branche 31 a du bus USB 31 d'autre part, et un second module de couplage 20b connecté au second bus CAN 11 b d'une part et à une autre branche 31 b au bus USB 31 d'autre part. Les branches 31 a et 31 b sont des liaisons point à point entre respectivement le module de couplage 20a ou 20b d'une part, et un dispositif répéteur 33 inclus dans l'équipement 30 d'autre part. En pratique, ces deux liaisons sont associées dans un unique câble à plusieurs fils. Selon la terminologie de la spécification USB, ce dispositif répéteur 33 est appelé répéteur de racine ( root hub ). Chaque module de couplage 20a ou 20b est un abonné du bus CAN 11 a ou 11 b respectivement et d'autre part un dispositif fonctionnel du bus USB 31. Il remplit une fonction de passerelle entre le protocole du bus CAN 1 la ou 11 b respectivement, et celui du bus USB 31.

<Desc/Clms Page number 8>

Dans ce cas, deux liaisons logiques unidirectionnelles sont établies entre une première paire de points terminaux unidirectionnels de l'équipement et la paire de points terminaux unidirectionnels correspondants du premier module de couplage 20a à raison d'une liaison logique unidirectionnelle par sens de transmission. Dans un exemple, la configuration des points terminaux unidirectionnels est la suivante : le endpoint de l'équipement 30 et celui du premier module de couplage 20a sont utilisés pour le transfert de données via le bus USB 31 du premier module de couplage 20a vers l'équipement 30 ; le endpoint 2 de l'équipement 30 et celui du premier module de couplage 20a sont utilisés pour le transfert de données via le bus USB 31 de l'équipement 30 vers le premier module de couplage 20a ; le endpoint 3 de l'équipement 30 et celui du second module de couplage 20b sont utilisés pour le transfert de données via le bus USB 31 du second module de couplage 20b vers l'équipement 30 ; enfin, le endpoint 4 de l'équipement 30 et celui du second module de couplage 20b sont utilisés pour le transfert de données via le bus USB 31 de l'équipement 30 vers le second module de couplage 20b ; bien entendu, le endpoint 0 de l'équipement 30, celui du premier module de couplage 20a et celui du second module de couplage 20b sont utilisés pour le transfert bidirectionnel d'informations de contrôle entre l'équipement 30 d'une part et les modules de couplage respectivement 20a et 20b d'autre part.

La spécification USB prévoit que chaque point terminal unidirectionnel peut être programmé de manière à délivrer ou collecter des paquets USB dont la taille est égale à 8,16, 32 ou 64 octets (pour l'élément comportant les informations utiles). Compte tenu de la taille d'une trame CAN, chaque trame CAN pouvant véhiculer de 0 à 8 octets de données en plus de l'en-tête, la taille optimale d'un paquet USB est égale à 16 octets. C'est pourquoi, selon une caractéristique avantageuse de l'invention, chaque point terminal unidirectionnel du bus USB est de préférence programmé en sorte que la taille des paquets USB qu'il délivre ou collecte soit égale à 16 bits.

Selon une autre caractéristique avantageuse de l'invention, le ou les modules de couplage sont alimentés en énergie électrique par l'intermédiaire du bus USB. Cela évite une alimentation à partir de la batterie du véhicule automobile 1, qui nécessiterait des raccordements spécifiques appropriés. On

<Desc/Clms Page number 9>

notera que les modules de couplage n'intervenant que lors des opérations de diagnostic embarqué, ils n'ont en effet besoin d'être alimentés que lorsque le câble 31 supportant le bus USB est mis en place pour une telle opération de diagnostic embarqué.

La spécification USB définit plusieurs modes de transfert de données sur le bus USB, suivant la nature et le débit des données à transmettre. Dans la terminologie de la spécification USB, il s'agit des modes de transfert dits Control , Isochronous , Interrupt et Bulk . Les données à transmettre étant ici des messages OBD (contenant des données relatives au diagnostic) avec un débit relativement important (de l'ordre de 600 Kbits/s), le mode de transfert qui convient le mieux est le mode dit Bulk . Donc de préférence le mode de transfert sur le bus USB 31 est le mode dit Bulk .

Sur un bus USB, un dispositif fonctionnel ne peut pas prendre l'initiative d'un transfert de données. C'est pourquoi la spécification USB définit un mécanisme de scrutation du bus USB par l'hôte. Ce mécanisme est appelé polling dans la terminologie de la spécification USB. La récurrence de scrutation du bus USB par l'hôte, ici l'équipement 30, dépend de l'implémentation du protocole du bus USB mise en #uvre par l'hôte. Elle résulte d'un compromis entre le temps de latence et la charge du système d'exploitation de l'ordinateur PC qui joue le rôle de l'hôte. Dans la très grande majorité de cas, le système d'exploitation est le système WINDOWS # de la société Microsoft Corporation. Dans un exemple préféré, la récurrence de scrutation du bus USB par l'équipement 30 est au plus de l'ordre de 10 millisecondes.

A la figure 3, on a représenté le schéma fonctionnel d'un module de couplage 20. Il comprend un coupleur USB 23 pouvant être relié au bus USB 31, un coupleur CAN 24 relié à la prise de diagnostic 21 du bus CAN 11, ainsi qu'un microcontrôleur 22. Le microcontrôleur 22 est piloté par un logiciel de traitement. Les coupleurs 23 et 24 peuvent être des composants indépendants, dédiés à la fonction de couplage d'un dispositif ou d'un système électronique quelconque à un bus USB ou à un bus CAN respectivement. Dans le jargon de l'homme du métier, on parle de contrôleur de bus sans unité centrale (dits Stand-Alone en anglais) pour désigner de tels composants. Toutefois, on

<Desc/Clms Page number 10>

peut avantageusement utiliser un microcontrôleur 22 ayant soit un coupleur USB soit un coupleur CAN intégré (de tels microcontrôleurs sont actuellement disponibles sur le marché) et en outre un contrôleur de bus CAN ou un contrôleur de bus USB respectivement. On peut aussi envisager l'utilisation d'un microcontrôleur ayant à la fois un coupleur USB et un coupleur CAN intégrés, bien qu'un tel composant ne soit pas semble-t-il, disponible à ce jour, et doive donc être fabriqué spécifiquement.

Le module de couplage comprend en outre une première mémoire tampon 26 par laquelle transitent les données en provenance ou à destination du bus CAN 11via le coupleur CAN 24, et une seconde mémoire tampon 27 par laquelle transitent les données en provenance ou à destination du bus USB via le coupleur USB 23. Il comporte en outre des moyens de contrôle de flux permettant d'éviter la saturation du module de couplage, soit dans le cas de trames reçues du bus CAN (sens réception CAN), soit dans le cas de trames à envoyer sur le bus CAN (sens émission CAN). Il s'agit de moyens logiciels qui font partie du logiciel de traitement. Ces moyens génèrent le cas échéant des informations de contrôle de flux (champ ROS, ROI, RFS et TFS sur lesquels on reviendra plus loin) qui sont transmises via la liaison bidirectionnelle entre les endpoints 0 respectifs du module de couplage 20 et de l'équipement 30).

Ces mémoires tampon sont par exemple constituées par des registres mémoires du microcontrôleur 22. Leur taille dépend du débit sur le bus CAN et de la récurrence de scrutation du bus USB par l'équipement 30. Avec un débit sur le bus CAN de l'ordre de 600 Kbits/s, et pour une récurrence de scrutation égale à 10 millisecondes, chaque mémoire tampon doit pouvoir stocker un maximum théorique d'environ 500 octets. Le reste de la mémoire du microcontrôleur est disponible pour la mémorisation non volatile du logiciel de traitement.

Une trame CAN est une séquence d'états électriques (récessifs ou dominants) sur la ligne différentielle constituant le bus CAN. Chaque trame CAN possède un en-tête et de 0 à 8 octets de données. Elle a donc une longueur variable. Le nombre d'octets de données est indiqué dans un champ de l'en-tête appelé champ DLC (de l'anglais Data Length Code ). L'origine d'une trame est repérée par un champ particulier de l'en-tête appelé

<Desc/Clms Page number 11>

identificateur et noté ID. La version V2.0A de la norme CAN (version standard) régit les implémentations du protocole du bus CAN avec des identificateurs codés sur 11bits. La version V2.0B de la norme CAN (version étendue) régit les implémentations du protocole du bus CAN avec des identificateurs dont le format peut être étendu de 11bits à 29 bits. La version étendue V2.0B est un sur-ensemble de la version standard V2.0A. Dans la suite, le format d'identificateur sur 11bits sera noté S et le format d'identificateur sur 29 bits sera noté X, sachant que les deux formats peuvent être appelés à cohabiter selon l'implémentation du protocole du bus CAN retenue. Un bit IDE détermine le format S ou X de l'identificateur ID.

Le destinataire d'une trame CAN n'est pas codé. Toutefois il existe un mode de transmission particulier, appelé mode à distance ( remote en anglais) dans la terminologie de la norme CAN, dans lequel un abonné demande la transmission de trame à un autre abonné par l'envoi d'une trame sans données, qui est marquée spécialement. Ce marquage se fait par un bit de l'en-tête, dit bit RTR (de l'anglais Remote Transmission Request ) qui détermine le type de la trame (normal ou remote ). Une trame CAN véhicule des informations qui peuvent être classées en quatre catégories différentes en fonction de leur nature : - des données, c'est à dire des informations applicatives transitant en même temps que les données utiles ; - des commandes, c'est à dire des informations de configuration à destination du dispositif de couplage de chaque abonné, qui ne sont transmises qu'une seule fois à l'initialisation du bus CAN ; - des informations d'état, c'est à dire des informations sur l'état du bus CAN ou du système de coulage des abonnés et qui nécessitent une réaction des autres abonnés.

On va maintenant décrire la façon dont une trame CAN est encapsulée dans un ou plusieurs paquets USB selon l'invention. La norme CAN ne concerne que les couches 1 et 2 du modèle de référence pour l'interconnexion des systèmes ouverts (modèle OSI). Toutes les autres couches de ce modèle font partie du niveau utilisateur. C'est pourquoi, on s'attachera dans un premier temps à mettre en évidence les informations qui sont nécessaires à la

<Desc/Clms Page number 12>

constitution d'une liaison selon le protocole du bus CAN entre l'équipement 30 et les autres abonnés du bus CAN à savoir les calculateurs 10. Puis, dans un deuxième temps, on présentera un exemple d'encapsulation de ces informations dans des paquets USB qui est proposée dans un mode de réalisation préféré.

Dans ce qui suit, on présente de manière succincte, à l'aide de tables, les champs d'information des trames CAN, chaque table regroupant des champs d'information relatifs à des fonctionnalités respectives du protocole du bus CAN. Dans chaque table, la première colonne (celle de gauche) indique le nom d'un champ, la deuxième colonne indique le type d'information porté par ce champ, la troisième colonne indique la nature de cette information, la quatrième colonne indique les valeurs possibles que peut prendre ce champ alors que la dernière colonne indique le nombre de bits alloués à ce champ.

Concernant la fonctionnalité de description des trames CAN, les champs d'information pertinents sont donnés par la table I ci-dessous. Ces champs ont été introduits plus haut et il n'est pas utile de s'étendre plus longuement sur leur description.

<tb>
<tb>

Nom <SEP> Information <SEP> Nature <SEP> Valeurs <SEP> possibles <SEP> Nbre <SEP> de <SEP>
<tb> bits
<tb> IDE <SEP> Format <SEP> de <SEP> donnée <SEP> S <SEP> ou <SEP> X <SEP> 1
<tb> l'identificateur
<tb> RTR <SEP> Format <SEP> de <SEP> trame <SEP> donnée <SEP> normale <SEP> ou <SEP> <SEP> remote <SEP> <SEP> 1
<tb> DLC <SEP> Nbre <SEP> d'octets <SEP> de <SEP> donnée <SEP> 0 <SEP> à <SEP> 8 <SEP> 4
<tb> données
<tb>

ID Identificateur donnée 7FFh S /1 FFFFFFh X 11 (S)/29(X)

<tb>
<tb> D1#D8 <SEP> Données <SEP> utiles <SEP> donnée <SEP> quelconques <SEP> 'DLC'x <SEP> 8
<tb>

TABLE
Concernant la fonctionnalité de filtrage des trames, les champs d'information pertinents sont donnés par la table Il ci-dessous. La norme CAN introduit des possibilités de filtrage des trames à partir des valeurs des identificateurs. Le mécanisme de filtrage consiste à comparer l'identificateur d'une trame reçue à un code d'acceptation pré-programmé, puis à éliminer les

<Desc/Clms Page number 13>

bits non pertinents grâce à un masque d'acceptation. Des paires code/masque d'acceptation peuvent être mises en série pour augmenter la capacité de filtrage. Dans la table II, on admet la possibilité de quatre telles paires au maximum. Il existe donc quatre champs AC1 à AC4 de huit bits chacun pour coder les codes d'acceptation, et quatre champs AM1 à AM4 de huit bits chacun pour coder les quatre masques d'acceptation. La correspondance entre les bits du code et les bits de la trame est dépendante de l'implémentation.

<tb>
<tb>

Nom <SEP> Information <SEP> Nature <SEP> Valeurs <SEP> Nbre <SEP> de <SEP>
<tb> possibles <SEP> bits
<tb> ACB <SEP> Contrôle <SEP> de <SEP> commande <SEP> dépend <SEP> de <SEP> 8
<tb> l'acceptation <SEP> l'implémentation
<tb> AC1#4 <SEP> Codes <SEP> d'acceptation <SEP> commande <SEP> dépend <SEP> de <SEP> 4 <SEP> x <SEP> 8 <SEP>
<tb> l'implémentation
<tb> AM1#4 <SEP> Masques <SEP> commande <SEP> dépend <SEP> de <SEP> 4 <SEP> x <SEP> 8 <SEP>
<tb>

d acceptation j'implémentation

<tb>
<tb> AH <SEP> N <SEP> d'acceptation <SEP> donnée <SEP> 0 <SEP> à <SEP> 7 <SEP> 3
<tb>

TABLE Il
Concernant la fonctionnalité de gestion des erreurs, les champs d'information pertinents sont donnés par la table III ci-dessous.

Les états d'erreurs d'un abonné CAN sont hiérarchisés en quatre catégories qui induisent des comportements de moins en moins actifs pour l'abonné. Selon la terminologie de la norme CAN, on distingue ainsi l'état error active , l'état error warning , l'état error passive , et l'état bus off dans lequel l'abonné est déconnecté du bus CAN. Les transitions entre ces états se font par comparaison de la valeur d'un compteur d'erreurs à des seuils. Pour chaque abonné CAN, Il y a un compteur d'erreurs en émission et un compteur d'erreurs en réception. Ainsi, un abonné CAN se trouve dans l'état error active pour les valeurs du compteur comprises entre 0 et 95, dans l'état error warning pour les valeurs du compteur comprises entre 96 et 127, dans l'état error passive pour les valeurs du compteur comprises entre 128 et 255, et dans l'état bus off pour les valeurs du compteur supérieures à 255.

<Desc/Clms Page number 14>

<tb>
<tb> Nom <SEP> Information <SEP> Nature <SEP> Valeurs <SEP> Nbre <SEP> de
<tb> possibles <SEP> bits
<tb> REC <SEP> Compteur <SEP> d'erreurs <SEP> en <SEP> réception <SEP> état <SEP> quelconque <SEP> 8
<tb> TEC <SEP> Compteur <SEP> d'erreurs <SEP> en <SEP> émission <SEP> état <SEP> quelconque <SEP> 8
<tb> WT <SEP> Seuil <SEP> d'avertissement <SEP> commande <SEP> 1#127 <SEP> 8
<tb> RWS <SEP> Etat <SEP> d'avertissement <SEP> en <SEP> état <SEP> normal <SEP> / <SEP> warning <SEP> 1
<tb> réception
<tb> TWS <SEP> émission <SEP> en <SEP> état <SEP> normal <SEP> / <SEP> warning <SEP> 1
<tb> émission
<tb> RPS <SEP> Etat <SEP> <SEP> Error <SEP> passive <SEP> <SEP> en <SEP> état <SEP> normal <SEP> / <SEP> error <SEP> 1
<tb> réception <SEP> passive
<tb> TPS <SEP> Etat <SEP> <SEP> Error <SEP> passive <SEP> <SEP> en <SEP> état <SEP> normal <SEP> / <SEP> error <SEP> 1
<tb> émission <SEP> passive
<tb> BOS <SEP> Etat <SEP> bus <SEP> déconnecté <SEP> état <SEP> normal <SEP> / <SEP> bus <SEP> off <SEP> 1
<tb> EPS <SEP> Etat <SEP> de <SEP> position <SEP> d'erreur <SEP> état <SEP> dépend <SEP> de <SEP> 8
<tb> l'implémentation
<tb> RWI <SEP> Alerte <SEP> avertissement <SEP> en <SEP> alerte <SEP> normal <SEP> / <SEP> warning <SEP> 1
<tb> réception
<tb> TWI <SEP> Alerte <SEP> avertissement <SEP> en <SEP> alerte <SEP> normal <SEP> warning
<tb>

TWI 1 émission alerte normal warning émission

<tb>
<tb> RPI <SEP> Alerte <SEP> passive <SEP> en <SEP> réception <SEP> alerte <SEP> normal <SEP> / <SEP> passive <SEP> 1
<tb> TPI <SEP> Alerte <SEP> passive <SEP> en <SEP> émission <SEP> alerte <SEP> normal <SEP> / <SEP> passive <SEP> 1
<tb> BOI <SEP> Alerte <SEP> bus <SEP> déconnecté <SEP> alerte <SEP> normal <SEP> / <SEP> bus <SEP> off <SEP> 1
<tb>

TABLE III
Concernant les fonctionnalités liées aux caractéristiques temporelles du protocole, les champs d'information sont donnés par la table IV ci-dessous.

Il faut distinguer d'une part le cadencement des bits, la définition du point d'échantillonnage, et la resynchronisation, d'autre part la vitesse de transfert, et enfin le marquage temporel.

D'après la norme CAN, la durée d'un bit est divisée en quatre segments, appelés, synchro , propagation , phase 1 , et phase 2 . L'état du bus est échantillonné entre les segments phase 1 et phase 2 . La durée des segments est programmable (champs TS1 et TS2) comme un multiple d'une durée de base appelée quantum. En cas de dérive d'horloge d'un abonné à l'autre, un saut de resynchronisation a lieu sur les segments phase 1 et/ou phase 2 . Ce saut a une largeur programmable (champ RJW) comme un multiple du quantum.

<Desc/Clms Page number 15>

La vitesse de transfert est définie par la durée du quantum. Celle-ci dépend du nombre de quanta programmé dans un bit. Cette durée est dérivée de la fréquence d'horloge du système, à travers un pré-diviseur programmable (champ PSR) réduisant la fréquence. La norme CAN permet d'atteindre des débits allant jusqu'à 1 Mbit/s. Cependant la grande majorité des applications nécessite actuellement des vitesses de transfert comprises entre 125 Kbit/s et 500 Kbit/s.

Dans certaines applications, il est nécessaire de dater l'arrivée des trames CAN par rapport à un chronomètre local. On parle de marquage temporel car chaque trame CAN reçue est alors marquée par la valeur du chronomètre au moment de sa réception. L'unité de temps du marquage temporel (champ TSU) dépend de l'implémentation. Cette fonctionnalité est repérée par un bit déterminé appelé bit TSC.

<tb>
<tb>

Nom <SEP> Information <SEP> Nature <SEP> Valeurs <SEP> Nbre <SEP> de
<tb> possibles <SEP> bits
<tb> PSR <SEP> Valeur <SEP> de <SEP> prédivision <SEP> commande <SEP> dépend <SEP> de
<tb> l'implémentation
<tb> TS1 <SEP> Durée <SEP> du <SEP> segment <SEP> phase <SEP> commande <SEP> dépend <SEP> de
<tb> 1 <SEP> l'implémentation
<tb> TS2 <SEP> Durée <SEP> du <SEP> segment <SEP> phase <SEP> commande <SEP> dépend <SEP> de
<tb> 2 <SEP> l'implémentation
<tb> SYS <SEP> Etat <SEP> de <SEP> synchronisation <SEP> état <SEP> synchro <SEP> / <SEP> non <SEP> 1
<tb> synchro
<tb> SN <SEP> Nombre <SEP> d'échantillon <SEP> commande <SEP> simple <SEP> / <SEP> multiple <SEP> 1
<tb> RJW <SEP> Largeur <SEP> du <SEP> saut <SEP> commande <SEP> dépend <SEP> de
<tb> resynchronisation <SEP> l'implémentation
<tb> TSC <SEP> Contrôle <SEP> de <SEP> marquage <SEP> commande <SEP> normal <SEP> 1
<tb> temporel <SEP> marquage
<tb> TSU <SEP> Unité <SEP> de <SEP> marquage <SEP> commande <SEP> ,. <SEP> dépend <SEP> de
<tb> l'implémentation
<tb> TS1#4 <SEP> Valeur <SEP> du <SEP> chronomètre <SEP> donnée <SEP> quelconque <SEP> 32(S)/24(X)
<tb>

TABLE IV
Concernant la fonctionnalité de connexion/déconnexion au bus CAN les champs d'information pertinents sont donnés dans la table V ci-dessous.

On distingue plusieurs commandes, notamment une demande de déconnexion du bus CAN ou de mise en sommeil (bit SR) et une demande de

<Desc/Clms Page number 16>

connexion au bus CAN (bit RST). Il est possible de détecter le démarrage d'un trafic sur le bus CAN par réveil automatique, grâce à la surveillance des transitions sur le bus CAN. Ces transitions peuvent être filtrées suivant l'implémentation du protocole du bus CAN, grâce à une commande de filtrage du réveil (bit WF). Dans certaines applications, et notamment pour le diagnostic embarqué, il est nécessaire de capturer les trames circulant sur le bus CAN sans intervenir activement dans le processus de transmission, c'est à dire sans émission ni acquittement explicite. Ceci est réalisé par une commande de lecture seule (bit LO).

Chaque abonné du bus CAN doit être en mesure de vérifier par lui-même sa connexion au bus CAN. Pour cela, on prévoit un mécanisme de rebouclage transmission sur réception. On réalise ainsi une fonction d'autotest grâce à une demande de boucle locale (bit LLR).

<tb>
<tb>

Nom <SEP> Information <SEP> Nature <SEP> Valeurs <SEP> possibles <SEP> Nbre <SEP> de
<tb> bits
<tb> RST <SEP> Demande <SEP> de <SEP> connexion <SEP> commande <SEP> normal <SEP> / <SEP> reset <SEP> 1
<tb> SR <SEP> Demande <SEP> de <SEP> déconnexion <SEP> commande <SEP> normal <SEP> / <SEP> sommeil <SEP> 1
<tb> WF <SEP> 1 <SEP> Filtrage <SEP> du <SEP> réveil <SEP> commande <SEP> normal <SEP> / <SEP> filtrage <SEP> 1
<tb> LO <SEP> Lecture <SEP> seule <SEP> commande <SEP> normal <SEP> / <SEP> lecture <SEP> 1
<tb> LLR <SEP> Demande <SEP> de <SEP> boucle <SEP> locale <SEP> commande <SEP> normal <SEP> / <SEP> rebouclage <SEP> 1
<tb> SLS <SEP> Etat <SEP> de <SEP> déconnexion <SEP> état <SEP> normal <SEP> / <SEP> sommeil <SEP> 1
<tb> Wl <SEP> Alerte <SEP> de <SEP> réveil <SEP> alerte <SEP> normal <SEP> réveil <SEP> 1
<tb>

TABLE V
Concernant la fonctionnalité de contrôle de flux, les champs d'information pertinents sont donnés par la table VI ci-dessous.

Des signaux de contrôle de flux sont mis en place pour détecter une éventuelle saturation ( overrun en anglais) d'un abonné CAN soit dans le sens réception (bits ROS, ROI et RFS) soit dans le sens émission (bit TFS). Dans le sens réception, il est en effet possible que des trames CAN arrivent plus rapidement que la capacité de lecture du coupleur CAN de l'abonné. Il y a alors saturation car aucun mécanisme n'est prévu par la norme CAN pour ralentir l'émission des trames. Dans le sens émission, le problème de régulation ne se pose qu'au niveau du coupleur CAN de l'abonné. En effet l'arrivée des messages

<Desc/Clms Page number 17>

à émettre ne doit pas se faire plus rapidement que la capacité d'émission sur le bus CAN par le coupleur CAN de l'abonné.

<tb>
<tb> Nom <SEP> Information <SEP> Nature <SEP> Valeurs <SEP> Nbre <SEP> de
<tb> possibles <SEP> bits
<tb> ROS <SEP> Etat <SEP> <SEP> overrun <SEP> <SEP> en <SEP> réception <SEP> état <SEP> normal <SEP> / <SEP> overrun <SEP> 1
<tb> ROI <SEP> Alerte <SEP> <SEP> overrun <SEP> <SEP> en <SEP> réception <SEP> alerte <SEP> normal <SEP> / <SEP> overrun <SEP> 1
<tb> RFS <SEP> Etat <SEP> du <SEP> flot <SEP> de <SEP> données <SEP> en <SEP> état <SEP> normal <SEP> / <SEP> saturation <SEP> 1
<tb> réception
<tb> TFS <SEP> Etat <SEP> du <SEP> flot <SEP> de <SEP> données <SEP> en <SEP> état <SEP> normal <SEP> / <SEP> saturation <SEP> 1
<tb> émission
<tb>

TABLE VI
On va maintenant donner un exemple d'une manière d'encapsuler les champs d'information ci-dessus d'une trame CAN quelconque, dans au moins un paquet USB. De préférence, lors de cette encapsulation on regroupe les champs d'information de la trame CAN selon la nature des informations qu'ils véhiculent, parce que ces informations sont transmises sur le bus CAN à des instants équivalents. On distingue ainsi des paquets de données, des paquets de commandes, des paquets d'états, et des paquets d'alertes. Dans ce qui suit, on ne s'intéresse qu'aux huit octets de données d'un paquet USB, et non à l'en-tête ni aux bits de détection ou de correction d'erreur de celui-ci.

Concernant les paquets de données, il faut distinguer selon le format (standard ou étendu) des identificateurs des trames CAN. Ces paquets circulent sur les liaisons logiques entre les points terminaux unidirectionnels 1 à 4. Leur longueur dépend du format de l'identificateur de la trame CAN, et du nombre d'octets véhiculés. L'octet 0 du paquet USB contient les champs dont les valeurs déterminent le format de la trame. Il est indépendant du format de l'identificateur de la trame CAN. Son contenu peut donc être décodé de la même façon pour le format standard et pour le format étendu. C'est le bit IDE de cet octet qui identifie le format de l'identificateur de la trame CAN. Le champ DLC fournit le nombre d'octets de données de l'en-tête de la trame CAN. Le bit TSC indique la présence (TSC = 1) ou l'absence (TSC = 0) des octets de marquage temporel (champs TS1 à TS4).

<Desc/Clms Page number 18>

Pour une trame CAN avec un identificateur au format standard (bit IDE = 0) dont la longueur est comprise entre 3 et 11octets suivant le nombre d'octets de données (hors octets de marquage temporel) de l'en-tête de la trame CAN, le contenu des octets de données d'un paquet USB est décrit dans la table VII cidessous :

<tb>
<tb> bits <SEP> 7 <SEP> 4 <SEP> 0
<tb> Octet <SEP> 0 <SEP> : <SEP> format <SEP> de <SEP> trame <SEP> 0 <SEP> RTR <SEP> IDE <SEP> TSC <SEP> DLC.3 <SEP> DLC.0
<tb> Octet <SEP> 1 <SEP> : <SEP> identificateur <SEP> ID.10 <SEP> ID.3
<tb> Octet <SEP> 2 <SEP> : <SEP> identificateur <SEP> + <SEP> ID.2 <SEP> ID.0 <SEP> AH.2 <SEP> AH.3
<tb> succès <SEP> d'acceptation
<tb> Octet <SEP> 3 <SEP> -.10: <SEP> data <SEP> 1 <SEP> # <SEP> 8 <SEP> On.7 <SEP> Dn.0
<tb> 1
<tb> Octet <SEP> 11 <SEP> : <SEP> marquage <SEP> TS.31 <SEP> TS.24
<tb> temporel <SEP> 1 <SEP> 2
<tb> Octet <SEP> 12 <SEP> : <SEP> marquageTS.23 <SEP> TS.16
<tb> temporel <SEP> 2 <SEP> 2 <SEP> Tus"23 <SEP> Tus'16
<tb> Octet <SEP> 13 <SEP> : <SEP> marquageTS.15 <SEP> TS.8
<tb> temporel <SEP> 3 <SEP> 2
<tb> Octet <SEP> 14 <SEP> : <SEP> marquageTS.7 <SEP> TS.0
<tb> temporel <SEP> 4 <SEP> 2
<tb>
(1) dépend du champ DLC (2) présents si bit TSC = 1
TABLE VII
Pour une trame CAN avec un identificateur au format étendu (bit IDE = 1), dont la longueur est comprise entre 5 et 13 octets suivant le nombre d'octet de données (hors octets de marquage temporel) le contenu des octets de données d'un paquet USB est décrit dans la table VIII ci-dessous :

<Desc/Clms Page number 19>

<tb>
<tb> bits <SEP> 7 <SEP> 6 <SEP> 5 <SEP> 4 <SEP> 3 <SEP> 2 <SEP> 1 <SEP> 0
<tb> Octet <SEP> 0 <SEP> : <SEP> format <SEP> de <SEP> 1 <SEP> RTR <SEP> IDE <SEP> TSC <SEP> DLC.3 <SEP> DLC.O
<tb> trame
<tb> Octet <SEP> 1 <SEP> : <SEP> I <SEP> D.28 <SEP> I <SEP> D.21 <SEP>
<tb> identificateur
<tb> Octet <SEP> 2 <SEP> : <SEP> ID.20 <SEP> ID.13
<tb> identificateur
<tb> Octet <SEP> 3 <SEP> : <SEP> ID.12 <SEP> ID.5
<tb> identificateur
<tb> Octet4 <SEP> :
<tb> identificateur <SEP> + <SEP> ID.4 <SEP> ID.0 <SEP> AH.2 <SEP> AH.O
<tb> succès
<tb> d'acceptation
<tb> Octet <SEP> 5 <SEP> # <SEP> 12 <SEP> : <SEP> On.? <SEP> Dn.0
<tb> données <SEP> 5 <SEP> --> <SEP> 8 <SEP> (1)
<tb> Octet <SEP> 13 <SEP> : <SEP> marquage <SEP> TS.23 <SEP> TS.16
<tb> temporel <SEP> 1 <SEP> (2)
<tb> Octet <SEP> 14 <SEP> : <SEP> marquage <SEP> TS.15 <SEP> TS.8
<tb> temporel <SEP> 2 <SEP> (2)
<tb> Octet <SEP> 15 <SEP> : <SEP> marquage <SEP> TS.7 <SEP> TS.0
<tb> temporel <SEP> 3 <SEP> (2) <SEP> jets-7
<tb>
(1) dépend du champ DLC (2) présents si bit TSC = 1
TABLE VIII
Les paquets de commande circulent sur les liaisons entre les points terminaux unidirectionnels 2 et/ou 4. Ils peuvent contenir des informations de programmation du module de couplage. Ils sont donc transmis à l'initialisation du système. On notera que le champ ML, codé sur quatre bits, qui est présent dans l'octet 0, détermine le nombre d'octets du paquet USB. Le contenu des octets d'un tel paquet USB est décrit par la table IX ci-dessous :

<Desc/Clms Page number 20>

bits 7 1 6 1 5 1 4 1 37 2 1 1 0

<tb>
<tb> Octet <SEP> 0 <SEP> : <SEP> format <SEP> de <SEP> trame <SEP> 1 <SEP> 0 <SEP> 1 <SEP> 1 <SEP> ML3 <SEP> MLO
<tb> Octet <SEP> 1 <SEP> : <SEP> divers <SEP> SN <SEP> WF <SEP> LO <SEP> LLR <SEP> TSC <SEP> O <SEP> SR <SEP> RST
<tb> Octet <SEP> 2 <SEP> : <SEP> valeur <SEP> de <SEP> PSR.7 <SEP> PSR.0
<tb> rédivision
<tb> Octet <SEP> 3 <SEP> : <SEP> du <SEP> TS1.7 <SEP> TS1.0
<tb> se <SEP> ment <SEP> 1 <SEP> hase <SEP> loi. <SEP> / <SEP> lol. <SEP> U
<tb> Octet <SEP> 4 <SEP> : <SEP> du <SEP> TS2.7 <SEP> TS2.0
<tb> se <SEP> ment <SEP> 2 <SEP> hase
<tb> Octet <SEP> 5 <SEP> : <SEP> largeur <SEP> du <SEP> saut <SEP> RJW.7 <SEP> RJW.O
<tb> de <SEP> resynchronisation
<tb> Octet <SEP> 6 <SEP> : <SEP> seuil <SEP> WT.7 <SEP> WT.0
<tb> d'avertissement
<tb> Octet <SEP> 7 <SEP> : <SEP> de <SEP> TSU.7 <SEP> TSU.O
<tb> marquage <SEP> temporel
<tb>

TABLE IX
Un paquet de commande peut aussi contenir des informations de filtrage des trames CAN. Dans ce cas, le contenu de ces octets est décrit dans la table X ci-dessous :

<tb>
<tb> bits <SEP> 7 <SEP> 6 <SEP> 5 <SEP> 4 <SEP> 3 <SEP> 2 <SEP> 1 <SEP> 0
<tb> Octet <SEP> 0 <SEP> : <SEP> format <SEP> de <SEP> 1 <SEP> 0 <SEP> 1 <SEP> 1 <SEP> ML3 <SEP> MLO
<tb> trame
<tb> Octet <SEP> 1 <SEP> : <SEP> octet <SEP> de <SEP> ACB.7 <SEP> ACB.O
<tb> contrôle <SEP> d'acceptation
<tb> Octet <SEP> 2 <SEP> : <SEP> code <SEP> AC1.7 <SEP> AC1. <SEP> 0
<tb> d'acceptation <SEP> 1
<tb> Octet <SEP> 3 <SEP> : <SEP> masque <SEP> AM1.7 <SEP> AM1.0
<tb> d'acceptation <SEP> 1
<tb> Octet <SEP> 4 <SEP> : <SEP> codeAC2.7 <SEP> AC2.0
<tb> d'acceptation <SEP> 2 <SEP> AUX7 <SEP> AC2Q
<tb> Octet <SEP> 5 <SEP> : <SEP> masque <SEP> AM2.7 <SEP> AM2. <SEP> 0
<tb> d'acceptation <SEP> 2
<tb> Octet <SEP> 6 <SEP> : <SEP> code <SEP> AC3. <SEP> 7 <SEP> AC3.0
<tb> d'acceptation <SEP> 3
<tb> Octet <SEP> 7 <SEP> : <SEP> masque <SEP> AM3.7 <SEP> AM3. <SEP> 0
<tb> d'acceptation <SEP> 3
<tb> Octet <SEP> 8 <SEP> : <SEP> code <SEP> AC4.7 <SEP> AC4. <SEP> 0
<tb> d'acceptation <SEP> 4
<tb> Octet <SEP> 9 <SEP> : <SEP> masque <SEP> AM4.7 <SEP> AM4. <SEP> 0
<tb> d'acceptation <SEP> 4
<tb>
TABLE X

<Desc/Clms Page number 21>

Un paquet de commande USB peut encore contenir des informations d'interrogation du module de couplage. Un paquet d'état sera alors transmis par celui-ci en réponse à ce paquet d'interrogation. Un tel paquet d'interrogation ne contient qu'un octet, à savoir l'octet 0 dont le contenu est décrit par la table XI ci-dessous :

<tb>
<tb> ~~~~~~~~~~~~~~~~bits <SEP> 7 <SEP> 6 <SEP> 5 <SEP> 4 <SEP> 3 <SEP> 2 <SEP> 1
<tb> Octet <SEP> 0 <SEP> : <SEP> format <SEP> de <SEP> trame <SEP> 1 <SEP> 0 <SEP> 1 <SEP> 0 <SEP> ML. <SEP> 3 <SEP> ML.0
<tb>

TABLE XI
Un message d'état circule sur les liaisons entre les points de terminaison unidirectionnels 1 et/ou 3. Il contient des informations sur l'état du module de couplage. Il est envoyé en réponse au message d'interrogation décrit ci-dessus.

Le contenu des octets d'un paquet USB pour la transmission d'un tel message est donné par la table XII ci-dessous :

<tb>
<tb> bits <SEP> 7 <SEP> 6 <SEP> 5 <SEP> 4 <SEP> 3 <SEP> 2 <SEP> 1 <SEP> 0
<tb> Octet <SEP> 0 <SEP> : <SEP> format <SEP> de <SEP> 1 <SEP> 0 <SEP> 1 <SEP> 1 <SEP> ML3 <SEP> MLO
<tb> trame
<tb> Octet <SEP> 1 <SEP> : <SEP> divers <SEP> RWS <SEP> TWS <SEP> RPS <SEP> TPS <SEP> BOS <SEP> OVS <SEP> SYS <SEP> SLS
<tb> Octet <SEP> 2 <SEP> : <SEP> compteur <SEP> REC.7 <SEP> REC.O
<tb> d'erreurs <SEP> de <SEP> réception.
<tb>

Octet <SEP> 3 <SEP> : <SEP> compteur <SEP> TEC.7 <SEP> TEC.O
<tb> d'erreurs <SEP> d'émission
<tb> Octet <SEP> 4 <SEP> : <SEP> position <SEP> erreur <SEP> EPS. <SEP> 7 <SEP> EPS.O
<tb>

TABLE XII
Enfin, un message d'alerte circule entre les points de terminaison unidirectionnels 1 et/ou 3. Il contient des informations sur des événements asynchrones survenant dans le module du couplage. Le contenu des octets d'un paquet USB pour la transmission d'un tel message d'alerte est donné par la table XIII ci-dessous :

<Desc/Clms Page number 22>

<tb>
<tb> bits <SEP> 7 <SEP> 6 <SEP> 5 <SEP> 4 <SEP> 3 <SEP> 2 <SEP> 1 <SEP> 0 <SEP>
<tb> Octet <SEP> 0: <SEP> format <SEP> de <SEP> 1 <SEP> 1 <SEP> 0 <SEP> 0 <SEP> ML.3 <SEP> ML.0
<tb> trame
<tb> Octet <SEP> 1 <SEP> : <SEP> alertes <SEP> RWI <SEP> TWI <SEP> RPI <SEP> TPI <SEP> BOI <SEP> OVI <SEP> 0 <SEP> WI
<tb> Octet <SEP> 1 <SEP> : <SEP> états <SEP> RWS <SEP> TWS <SEP> RPS <SEP> TPS <SEP> BOS <SEP> OVS <SEP> SYS <SEP> SLS
<tb>

TABLE XIII
Au point de vue du protocole d'échange, la scrutation du bus USB par l'équipement 30 se fait à intervalles de temps réguliers tant qu'il n'y a pas de données transmises sur le bus. Lorsque la transmission d'un flot de données sur le bus USB est amorcée, la scrutation est interrompue jusqu'à ce que la mémoire tampon de réception de l'équipement 30 soit vide.

Du point du vue de l'équipement 30, le contrôle de flux est réalisé de la façon suivante. En réception, le champ RFS indique l'état normal ou saturé de l'équipement 30. Si l'équipement 30 est saturé, le flot de données transmis depuis le module de couplage 20 vers l'équipement 30 doit être momentanément suspendu par le module de couplage 20. Les messages OBD sont alors stockés dans la mémoire tampon 27 du module de couplage 20. En émission, la valeur du champs TFS indique l'état normal ou saturé du module de couplage 20. Si celui-ci est saturé, le flot de données transmis depuis l'équipement 30 doit être momentanément suspendu. Les message OBD sont alors stockés dans une mémoire tampon de l'équipement 30. Les champs RFS et TFS sont transmis par des messages ad-hoc dans des paquets USB sur la liaison entre les points terminaux bi-directionnels 0.

Pour un débit sur le bus CAN égal à 600 Kbits/s environ, le taux de transfert utile maximum est de 35,2 Ko/s en format standard et de 29,8 Ko/s en format étendu. Compte tenu de la taille des paquets USB (sans les octets de marquage temporel), le taux de transfert brut maximum théorique devient égal à 48,4 Ko/s, quel que soit le format de l'identificateur des trames CAN. Ce taux de transfert ne représente qu'une charge très faible pour le bus USB (de l'ordre de 3,3 % de la charge maximale théorique du bus USB).

Claims (18)

REVENDICATIONS

1. Procédé de communication entre un équipement (30) extérieur à un véhicule automobile (1) d'une part et des calculateurs embarqués (10) reliés entre eux par au moins un bus CAN (11) d'autre part, comprenant les étapes consistant à : - encapsuler, au niveau de l'équipement (30) ou au niveau d'un module de couplage (20) connecté d'une part au bus CAN (11) de manière à éviter la génération de réflexions électriques sur celui-ci et d'autre part à un bus USB (31), une trame CAN émise selon le protocole du bus CAN par l'équipement (30) ou par un calculateur respectivement, dans au moins un paquet USB selon le protocole du bus USB ; - émettre, via le bus USB (31), le paquet USB vers le module de couplage (20) ou vers l'équipement (30) respectivement ; - recevoir, au niveau du module de couplage (20) ou au niveau de l'équipement (30) respectivement, le paquet USB et le décapsuler pour en extraire la trame CAN, en sorte qu'un programme d'application s'exécutant dans l'équipement (30) est vu sur le bus CAN (11 ) comme un abonné CAN.

2. Procédé selon la revendication 1 ou la revendication 2 dans lequel, lors de l'encapsulation, on regroupe les champs d'information de la trame CAN selon la nature des informations qu'ils véhiculent.

3. Procédé selon la revendication 1, dans lequel, du point de vue du bus USB, l'équipement (30) est l'hôte alors que le module de couplage (20) est un dispositif fonctionnel.

4. Procédé selon l'une des revendications précédentes, dans lequel le mode de transfert sélectionné sur le bus USB (31) est le mode dit "bulk".

<Desc/Clms Page number 24>

5. Procédé selon l'une des revendications précédentes, dans lequel la récurrence de scrutation du bus USB (31) par l'équipement (30) est au plus de l'ordre de 10 millisecondes.

6. Dispositif de communication entre un équipement (30) extérieur à un véhicule automobile (1) d'une part et des calculateurs embarqués (10) reliés entre eux par au moins un bus CAN (11) d'autre part, dans lequel l'équipement (30) est connecté à un bus USB (31), le dispositif comprenant un module de couplage (20) connecté d'une part audit bus CAN (11) de manière à éviter la génération de réflexions électriques sur celui-ci et d'autre part audit bus USB (31), et comprenant des moyens pour transmettre, via le bus USB, des trames CAN entre l'équipement (30) et les calculateurs (10) de manière qu'un programme d'application s'exécutant dans l'équipement (30) est vu sur le bus CAN (11) comme un abonné CAN.

7. Dispositif selon la revendication 6, dans lequel le module de couplage comprend des moyens pour la mise en oeuvre d'un procédé selon l'une des revendications 1 à 5.

8. Dispositif selon la revendication 6 ou la revendication 7, dans lequel, du point de vue du bus USB (31), l'équipement (30) est l'hôte alors que le module de couplage (20) est un dispositif fonctionnel.

9. Dispositif selon l'une des revendications 6 à 8, dans lequel le mode de transfert sur le bus USB (31) est le mode dit "bulk".

10. Dispositif selon l'une des revendications 6 à 9, dans lequel la récurrence de scrutation du bus USB (31) par l'équipement (30) est au plus de l'ordre de 10 millisecondes.

11. Dispositif selon l'une des revendications 6 à 10, dans lequel le module de couplage (20) est connecté au bus CAN (11) par l'intermédiaire d'une prise de diagnostic (21) située à une extrémité (12) du bus CAN.

<Desc/Clms Page number 25>

12. Dispositif selon l'une quelconque des revendication 6 à 11, dans lequel le module de couplage (20) est connecté au bus USB (31) de manière à établir deux liaisons logiques entre une paire de points terminaux unidirectionnels de l'équipement (30) et la paire de points terminaux unidirectionnels correspondante du module de couplage (20).

13. Dispositif selon l'une quelconque des revendications 6 à 11, dans lequel les calculateurs (10) sont reliés par deux bus CAN (11 a ; 11 b), et dans lequel un premier module de couplage (20a) est connecté d'une part au premier bus CAN (11a) et d'autre part au bus USB (31 ) de manière à établir deux liaisons logiques entre une première paire de points terminaux unidirectionnels de l'équipement (30) et la paire de points terminaux unidirectionnels correspondantes du premier module de couplage (20a) à raison d'une liaison par sens de transmission, alors que le second module de couplage (20b) est connecté d'une part au second bus CAN (11b) et d'autre part au bus USB (31 ) de manière à établir deux autres liaisons logiques entre une seconde paire de points terminaux unidirectionnels de l'équipement (30) et la paire de points terminaux unidirectionnels correspondantes du second module de couplage (20b) à raison d'une liaison par sens de transmission.

14. Dispositif selon la revendication 13, dans lequel chaque point terminal unidirectionnel est programmé en sorte que la taille des paquets USB qu'il délivre ou collecte soit égale à 16 octets.

15. Dispositif selon l'une quelconque des revendications 6 à 14, dans lequel le module de couplage (20 ; 20a ; est alimenté par l'intermédiaire du bus USB (31 ;31 a ; 31 b).

16. Dispositif selon l'une quelconque des revendications 6 à 15, dans lequel le module de couplage (20) comprend une première mémoire tampon (26) par laquelle transitent les données en provenance ou à destination du bus CAN (11) et une seconde mémoire tampon (27) par laquelle transitent les

<Desc/Clms Page number 26>

données en provenance ou a destination du bus USB (31), et des moyens de contrôle de flux pour éviter la saturation de l'un et l'autre bus.

17. Dispositif selon l'une quelconque des revendications 6 à 16, dans lequel le module de couplage (20) comprend un microcontrôleur (22) contenant un coupleur USB (23) et/ou un coupleur CAN (24) intégrés.

18. Système de diagnostic embarqué pour véhicule automobile (1) comprenant - des calculateurs embarqués (10), reliés entre eux par au moins un bus CAN (11 ; 11 a 11 b) et pouvant envoyer ou recevoir par l'intermédiaire dudit bus CAN (11 ; 11 a ;11b) des messages de diagnostic embarqué sous la forme de trames CAN ; - une station de diagnostic (30) extérieure au véhicule automobile (1), reliée à un bus USB (31); - un dispositif de communication selon l'une quelconque des revendications 6 à 17, de manière qu'un programme d'application s'exécutant dans la station de diagnostic (30) est vu sur le bus CAN (11 ; 11a ;11b) comme un abonné CAN.