le protocole can - jonaheintz.com · le bit rtr (remote transmission request) indique la fin...

jonaheintz.com Le protocole CAN Jonathan HEINTZ

sur 13

Le protocole CAN

1. Introduction Le protocole CAN (Controller Aera Network) est un protocole de bus en série répandu dans

l'industrie, notamment dans l'automobile.

Il a été créé en 1983 par la société BOSCH avec la collaboration de l'université de Karlsruhe pour

l'industrie automobile. Les véhicules étant équipés de plus en plus de systèmes électroniques, il a

fallu trouver une solution de câblage, jusqu'alors effectuée en point à point. Pour des questions

d'économies de câblage, une approche de multiplexage a été mise en application qui consiste avec

un seul câble (bus) de permettre à plusieurs calculateurs de communiquer entre eux à tour de rôle.

Le protocole ne fut standardisé par l'ISO qu'au début des années 1990. En 1992, des entreprises se

sont réunies pour créer CAN Automation, une association qui a pour but de gérer et promouvoir le

protocole CAN.

Le protocole CAN est un protocole de basse couche n'utilisant que les 2 premières couches du

modèles OSI.

Application CANopen, DeviceNet, ...

Présentation

Session

Transport

Réseau

Liaison Protocole CAN

Physique


sur 13

2. Couche Physique

CAN utilise la topologie du bus de données série bidirectionnel half-duplex :

Données échangées via 1 câble (bus)

Données découpées en plusieurs morceaux de taille fixe (série). La segmentation est effectuée si les données d'informations sont supérieures à 8 octets.

L'échange peut être effectué dans les 2 sens (bidirectionnel)

L'échange ne peut être effectué que dans un sens à la fois (half-duplex)

Pour un bus CAN low-speed, le nombre d'équipements est limité à 20 alors que pour un bus CAN high-speed, il est limité à 30.

Chaque équipement se connecte sur le bus via une paire torsadée. Signaux codés en NRZ (Non return to zero) avec deux niveaux 0 (dominant) et 1 (récessif).


sur 13

Un des problèmes du codage en NRZ est le maintien du niveau lorsqu'un grand nombre de bits identiques se succèdent. Pour pallier à ce problème, on utilise la technique du Bit Stuffing qui impose le rajout automatique d'un bit de valeur opposée lorsque 5 bits consécutifs sont à transmettre.

Pour savoir quand il faut effectuer la lecture d'un bit et quand on considère qu'on passe au bit suivant, on utilise une horloge définie sur le bus CAN. Toutefois, étant donné que chaque nœud possède une horloge interne qui leur est propre, il faut construire le "Time Quantum", c'est à dire l'unité de temps d'oscillation pour le bus CAN qui sera commun pour tous les nœuds.

Segment Durée en « Time Quantum »

Synchronisation 1

Propagation 1 à 8

Phase buffer 1 1 à 8

Phase buffer 2 1 à 8


sur 13

Il existe 2 types de synchronisation :

la hard-synchronisation qui consiste à se resynchroniser brutalement dès qu'une transition est détectée dans le segment de synchronisation, notamment lors du SOF (Start Of Frame) d'une nouvelle trame.

la resynchronisation qui consiste à allonger le segment de phase buffer n°1 ou à diminuer le

segment de buffer phase n°2, ce qui a 2 effets :

déplacer le point d'échantillonnage,

diminuer ou augmenter la durée du bit et ainsi améliorer la synchronisation du bit

suivant.

Il existe 2 normes :

ISO 11898-3 (2006) anciennement ISO 11519-2 (1994) : CAN « low-speed, fault tolerant » (de 0kbits/s à 125kbits/s inclus),

ISO 11898-2 (2003) : CAN « high-speed » (de 125kbits/s à 1Mbits/s maximum).

CAN Low-Speed

Niveau dominant : CAN H = 4V et CAN L = 1V Niveau récessif : CAN H = 1,75V et CAN L = 3,25V


sur 13

CAN High-speed

Niveau dominant : Vcan_H - Vcan_L = 0V Niveau récessif : Vcan_H - Vcan_L = 2V

Le brochage sur le bus CAN est normalisé et utilise un connecteur DB-9 :

Broche Description

1 (Réservé)

2 CAN_L 3 Masse

4 (Réservé) 5 Blindage (optionnel)

6 Masse

7 CAN_H 8 (Réservé)

9 Alimentation (Optionnel)

http://commons.wikimedia.org/wiki/File:CAN_Connecteur.svg


sur 13

3. Couche Physique Il existe également 2 standards pour la couche de liaison de données :

ISO 11898 part A → CAN 2.0A « standard frame format » (identification sur 11bits),

ISO 11898 part B → CAN 2.0B « extended frame format » (identification sur 29bits).

Il existe plusieurs types de trame :

Trame de données

Trame de requête

Trame de surcharge

Trame d'erreur

Entre 2 trames, les émetteurs doivent respecter une pause (période d'inter-trame) équivalente à la durée de 3 bits pendant laquelle le bus est maintenu à l'état récessif.

Trame de données :

Champ d'arbitrage : principe de priorité Chaque nœud doit posséder un numéro d'identification unique.


sur 13

Le bit RTR (remote transmission request) indique la fin d'une requête de transmission et permet donc de signaler qu'un nœud transmet maintenant des données "utiles". Champ de commande : Le champ de commande permet de renseigner quel type de trame est transmise (trame en 2.0A ou en 2.0B) ainsi que le nombre d'octets présents dans le champ de données. Champ de données : Le champ de données contient tout simplement les informations utiles transmises par un noeud. Champ de CRC (Cyclic Redundancy Code) : Ce champ permet tout simplement de vérifier la cohérence de l'intégrale des données transmises. Il permet donc de voir si des erreurs non pas été rajoutées via des phénomènes de perturbations extérieures. Champ d'acquittement : Il est composé de 2 bits, l'ACK Slot et le ACK Delimiter (1 bit récessif).

un nœud en train de transmettre envoie un bit récessif pour le ACK Slot.

un nœud ayant reçu correctement un message en informe le transmetteur en envoyant un bit dominant pendant le ACK Slot : il acquitte le message.

Champ EOF (End Of Trame) : Ce champ est constitué de 7 bits récessifs (à 1). C'est le seul moment où il est possible d'avoir 7 bits consécutifs identiques, le bit stuffing n'étant pas appliqué durant cette séquence.


sur 13

Trame de requête :

Cette trame permet à un nœud de demander à un autre nœud de lui envoyer des données.

Dans le cas d'une trame de requête, le bit RTR est récessif (à 1). Donc dans le cas d'une demande de

requête et d'une demande d'envoi de données, la trame de données est prioritaire sur la trame de

requête.

Trame de surcharge : Cette trame indique qu'une station est surchargée pendant un certain laps de temps. Il y a deux sortes de conditions de surcharge :

les conditions internes d'un récepteur qui nécessitent un certain temps (un retard) pour accepter la prochaine trame de données ou trame de requête.

la détection d'un bit dominant durant la phase intermission. Dans ce cas le démarrage de la trame de surcharge a lieu juste après la détection du bit dominant.

Une trame de surcharge se compose de 2 champs différents :

Le drapeau de surcharge composé de 6 bits dominants,

Le délimiteur composé de 8 bits récessifs.

Lorsqu'un nœud émet une trame de surcharge pour demander un délai (condition n°1), il écrase les 3 bits récessifs de la période d'inter-trame, les autres nœuds détectent la surcharge, et elles émettent elles-mêmes des trames de surcharge (condition n°2).


sur 13

Le nombre de bits dominants d'affilée ne doit pas dépasser 12 bits. Au-delà les nœuds n'ayant pas émis leur trame de surcharge ne doivent pas le faire. Le dernier nœud à émettre fournit le délimiteur (8 bits récessifs) et met fin à la cacophonie.

Trame d'erreur : Dès qu'un nœud détecte une erreur, il envoie directement une trame d'erreur, même si celle-ci peut

couper une trame en cours.

Plusieurs types d'erreurs peuvent être détectés :

Bit error : Le nœud émetteur remarque que le bit sur le bus n'est pas le bit qu'il vient d'émettre

Stuff error : si un noeud lit 6 bits consécutifs de même polarité. Signifie que le mécanisme du bit stuffing n'a pas été respecté

CRC error : Si la valeur calculée par le nœud récepteur est différente du CRC dans la trame

CRC delimiter : Si le bit n'est pas récessif (à 0)

ACK Error : Si le bit ACK n'a pas été écrasé par un bit dominant. Signifie qu'aucun nœud ne l'a reçu

ACK Delimiter : Si le bit n'est pas récessif (à 0)

Une trame d'erreur se compose de 2 champs différents : Le drapeau d'erreur composé de 6 bits, Le délimiteur composé de 8 bits récessifs


sur 13

Un nœud peut se trouver dans 3 modes d'erreurs différents

mode error active

mode error passive

mode error bus off

Le mode d'erreur est déterminé en fonction de 2 compteurs d'erreur : le compteur d'erreur de

transmission (TEC) et le compteur d'erreur de réception (REC).

Règles de modification des compteurs d'erreur :

Lorsqu’un récepteur détecte une erreur, son Receive error count est augmenté de 1. Lorsqu’un transmetteur envoie un Error flag, son Transmit error count est augmenté de 8. Après une transmission réussie, le Transmit error count est diminué de 1. Après une réception réussie, le Receive error count est diminué de 1.

Règles de passage des modes d'erreur

Lorsqu'un nœud est dans le mode d'erreur active, il envoie des trames d'erreurs suivantes :

Dans ce cas, les bits du flag error sont dominants : la trame écrase la trame qui est entrain d'être

transmise.


sur 13

Lorsqu'un nœud est dans le mode d'erreur active, il envoie des trames d'erreurs suivantes :

Dans ce cas, les bits du flag error sont récessifs : la trame est ignorée si une autre trame est entrain

d'être transmise. Dans ce mode d'erreur, on considère le nœud comme nœud à problèmes et on

"ignore" ses erreurs pour ne pas couper les communications sur le bus.

Lorsqu'un nœud est en mode d'erreur bus off, il n'est plus autorisé à intervenir sur le bus et le nœud

se déconnecte du bus.

Tout comme dans le cas de la surcharge, le cas d'une trame d'erreur provoque un enchaînement de

trames d'erreur étant donné qu'une trame d'erreur brise la règle du bit stuffing.

Dans ce cas, le nombre de bit du "Flag error" d'une trame d'erreur active ne doit pas excéder 12 bits. Au-delà les nœuds n'ayant pas émis leur trame d'erreur ne doivent pas le faire. Le dernier nœud à émettre fournit le délimiteur (8 bits récessifs) , met fin à la trame d'erreur et libère le bus

.


sur 13

Topologies :

Bus standard

Facile à calculer la longueur du bus, la longueur du stubs étant négligeable (< 30 cm) Résistances de terminaison de ligne facile à placer : sur les 2 extrémités du câble Pas toujours pratique pour des lignes de production avec un câblage complexe : rajout de

longueur inutile pour le cheminement du câble.

Bus étoile

Longueur du bus plus compliquée à déterminer La ligne en stubs rajoute des perturbations sur le tronc principal Terminaison de ligne plus compliquée à positionner Plus adapté pour des systèmes avec un câblage complexe


sur 13

Bus étoile optimisé (1ère façon : utilisation de répéteurs)

Différenciation des segments -> Création de plusieurs troncs principaux :

Terminaison de ligne plus simple à positionner

Longueur du bus plus simple à calculer Même domaine pour le temps réel

Bus étoile optimisé (2ème façon : utilisation de bridges)

Différenciation des réseaux -> Création de plusieurs bus CAN

Longueur simple à calculer : addition de la longueur de chaque bus

Terminaison simple à positionner (2 extrémités de chaque réseau bus) Disparition du temps réel : on est plus sur un réseau commun Possibilité de filtrage des messages suivant le réseau : lignes moins surchargées Possibilité d'utiliser des vitesses différentes selon le réseau

le protocole can - jonaheintz.com · le bit rtr (remote transmission request) indique la fin...

Documents