Aucun titre de diapositive

Protocole CAN
Tutoriel
Protocole CAN : Controller Area Network
Historique
Début du développement d ’un projet interne chez Bosch, destiné à
développer un réseau embarqué dans les véhicules
Présentation officielle du protocole CAN
Premiers puces de contrôleurs CAN, disponibles chez Intel et Philips
Semiconductors
Publication par Bosch de la spécification CAN 2.0
Introduction par Kvaser de CAN Kingdom,
protocole de haut niveau basé sur CAN
Création du groupement international de constructeurs et d ’utilisateurs CiA
( CAN in Automation )
Publication par le CiA du protocole CAL (CAN Application Layer)
Division - Name - Date - Language
2
Protocole CAN : Controller Area Network
Historique
Premières voitures à utiliser le réseau CAN chez Mercedes-Benz
Publication de la norme ISO 11898
Première Conférence Internationale CAN (iCC) organisée par le CiA
Introduction par Allen-Bradley du protocole DeviceNet
Publication d ’un amendement à la norme ISO 11898
(format de trame étendu)
Publication par le CiA du protocole CANopen
Développement du protocole de communication TTCAN :
Time-Triggered communication protocol for CAN
Division - Name - Date - Language
3
Protocole CAN : Controller Area Network
Protocoles de Haut Niveau
 On fait appel à des modèles pour comprendre et
expliquer les problématiques de communication, pour
décrire les objets de communication , de même que
pour décrire les services applicables sur ces objets
 Les modèles en couches sont communs dans les
technologies de la communication
 Le modèle OSI (Open Systems Interconnect) de l ’ISO
(International Standardization Organization) est
largement utilisé pour décrire la fonctionnalité des
systèmes de communication : il est fondé sur une
approche hiérarchisée de couches
Division - Name - Date - Language
4
Protocole CAN : Controller Area Network
Protocoles de Haut Niveau
 L ’implémentation matérielle actuelle de CAN couvre
aujourd’hui les 2 couches inférieures de ce modèle; les
couches 3 à 7 étant couvertes par différentes approches
logicielles
 Il existe un grand nombre de protocoles de haut niveau,
basés sur CAN, et qui ont été développés pour différents
domaines d ’application, et en fonction de différents
besoins utilisateur
Division - Name - Date - Language
5
Protocole CAN : Controller Area Network
Protocoles de Haut Niveau
 Pour comprendre le modèle de référence CAN, on peut recourir à une
analogie
 On peut en effet considérer que la fonctionnalité offerte par le réseau
CAN est semblable à des lettres de l ’alphabet dans les communications
écrites humaines : c ’est la base pour l ’écriture d ’une langue, mais ce
n ’est pas suffisant pour entreprendre une communication efficace
 Pour spécifier une langue, il est en outre nécessaire de disposer d ’un
stock de mots disponibles, en même temps que d ’une grammaire qui va
régir la constitution des phrases
Division - Name - Date - Language
6
Protocole CAN : Controller Area Network
Protocoles de Haut Niveau
 Les utilisateurs de CAN peuvent ainsi spécifier leur propre langue. En
termes techniques, il s ’agit alors d ’un protocole de haut niveau, qui
peut être conforme à la couche 7 du modèle OSI de référence
 Ou bien l ’utilisateur peut décider d ’utiliser un protocole standardisé de
haut niveau, basé sur CAN.
 Dans le monde CAN, il existe différents protocoles standardisés sur la
couche application
 Certains sont très spécifiques, et relatifs à des domaines d ’application
spécifiques
 La seule couche application qui soit pure et indépendante d ’une
quelconque application des réseaux CAN est définie par le protocole
CAN Application Layer (CAL), spécifié et maintenu par le CiA
Division - Name - Date - Language
7
Protocole CAN : Controller Area Network
Protocoles de Haut Niveau
 Si l ’on en revient à notre précédente analogie, l ’utilisation d ’un
dictionnaire et d ’une grammaire n ’est pas très pratique, si l ’on a
comme seul propos de commander une boisson dans un pays étranger
 Pour des tâches simples comme celles-là, il existe des guides de
conversation. Ceux-i ne font appel qu ’à un sous-ensemble de la langue,
et proposent des phrases prédéfinies qui correspondent à des situations
particulières, par exemple au restaurant ou à l ’hôpital.
 Dans le monde des systèmes de communication techniques, ces guides
de conversation sont dénommés des « profils »
 Ainsi CANopen recouvre-t ’il une famille de profils basés sur CAN
 CANopen est également spécifié et maintenu par le CiA
Division - Name - Date - Language
8
Protocole CAN : Controller Area Network
Protocoles de Haut Niveau
 On peut répartir ces profils basés sur CAN entre un certain
nombre de profils de communication qui s ’acquittent des
spécifications que tout équipement doit être à même de
fournir, et un certain nombre d ’autres profils
d’équipements qui définissent chacun les caractéristiques
particulières à une classe d ’équipements
 Un système de communication, basé sur CAN peut se
diviser en quatre couches
 La couche physique est implémentée dans un certain nombre de contrôleurs CAN
 Les autres parties sont assurées au moyen de boîtiers transceivers
 La couche application, comme les profils basés sur CAN sont implémentés par logiciel
 Dans un certain nombre de cas, couche application et profils ne sont pas toujours très
clairement dissociés
Division - Name - Date - Language
9
Protocole CAN : Controller Area Network
Norme ISO 11898
 La spécification du protocole CAN est normalisée par l ’ISO
(International Organization for Standardization) dont le siège est à
Genève
 Le document de l ’ISO 11898 est en cours de révision, et sera publié
selon différentes parties :

Partie 1 pour la définition du protocole CAN

Partie 2 pour la spécification de la couche physique haute vitesse
(sans tolérance de panne)

Partie 3 pour la description de la couche physique basse vitesse, à
tolérance de panne

Partie 4, en cours de développement, pour la spécification du
protocole de communication TTCAN : Time-Triggered CAN
Division - Name - Date - Language
10
Protocole CAN : Controller Area Network
Norme ISO 11898
 Outre ces spécifications de base, différents travaux sont engagés au
plan international, au sein des organismes officiels de normalisation,
ainsi que dans les associations à but non lucratif, pour ce qui est des
protocoles de haut niveau pour réseaux CAN
 Certaines de ces spécifications sont très liées à une nature
d’application, tandis que d ’autres sont davantage génériques
 Dans les applications du secteur automobile, on trouvera les
spécification OSEK-COM et OSEK-NM, qui sont destinés à être
normalisées sous le numéro ISO 17356
 En ce qui concerne les communications sur les camions et gros engins,
l ’ISO a développé la norme ISO 11992, qui est basée sur le profil
d’application J1939. Ce profil d’application SAE J1939-71 définit les
communications basées sur CAN sur les camions et bus
Division - Name - Date - Language
11
Protocole CAN : Controller Area Network
Norme ISO 11898
 Pour ce qui est des réseaux intégrés, les membres du CiA ont
développé la famille des profils CANopen
 La couche application CANopen ainsi que les profils de communication
CANopen sont soumis à la Normalisation Européenne sous le numéro
prEN 50325-4
 DeviceNet, de son côté, se voulant dédié pour les applications
manufacturières et de process, est déjà normalisé sous le numéro
EN 50325-2
 De même en ce qui concerne les Smart Distributed Systems basés sur
CAN : EN 50325-3
Division - Name - Date - Language
12
Protocole CAN : Controller Area Network
Principes des échanges de données
 Le protocole CAN est défini par la norme internationale ISO 11898
 Outre le protocole lui-même, les tests de conformité avec le protocole
CAN sont spécifiés par la norme ISO 16845, qui garantit l ’inter-
opérabilité des chips CAN
Division - Name - Date - Language
13
Protocole CAN : Controller Area Network
Principes des échanges de données
 CAN est basé sur le mécanisme de
communication dît de diffusion (broadcast)
 Cette communication en broadcast est
réalisée par le biais de l ’utilisation d ’un
protocole de transmission orienté
messages
 De sorte que ce protocole ne définit que des messages, sans s ’intéresser aux stations, ni
aux adresses de ces stations
 Ces messages sont identifiés par le biais d ’un Identificateur de Message
 Un tel Identificateur de Message se doit donc d ’être unique sur l ’ensemble du réseau;
il définit non seulement le contenu, mais également la priorité du message
 Ceci trouvera toute son importance lorsque plusieurs stations seront en concurrence pour
l ’accès au réseau
Division - Name - Date - Language
14
Protocole CAN : Controller Area Network
Principes des échanges de données
 Le haut niveau de souplesse atteint, tant au
niveau système qu’au niveau configuration,
est le résultat d ’un schéma d ’adressage
orienté contenu
 Il est très facile d’ajouter des nœuds à un
réseau CAN existant, sans pour cela avoir à
faire de modification, ni matérielle, ni logicielle
aux nœuds existantes, si ces nœuds ne se comportent que comme des récepteurs purs
 Ceci autorise un concept d ’électronique modulaire, et permet également des réceptions
multiple, ainsi que la synchronisation de processus distribués : les informations requises par
plusieurs nœuds peuvent être transmises par le réseau, sans qu’il ne soit nécessaire que
chaque nœuds connaisse le producteur de ces données
 Ceci facilite aussi la mise en service et la mise à jour du réseau, dans la mesure où les
échanges de données ne sont pas liés à la disponibilité de types particuliers de stations
Division - Name - Date - Language
15
Protocole CAN : Controller Area Network
Principes des échanges de données
 En traitement temps réel, l’urgence des messages à échanger sur le
réseau peut différer de façon significative : ainsi, une grandeur évoluant
rapidement, par exemple une charge de moteur, devra être transmise plus
fréquemment, et de ce fait avec moins de retard que d’autres grandeurs,
par exemple la température du moteur
 La priorité avec laquelle un message est émis, par comparaison ave un
autre message d ’urgence moindre, est indiquée par l ’identificateur
embarqué au sein de chaque message
 Ces priorités sont consignées lors de la conception du système, sous la
forme de valeurs binaires, et ne peuvent être modifiées de façon
dynamique. Les identificateurs possédant la valeur la plus faible disposent
de la priorité la plus forte
 Les conflits d ’accès au bus sont réglés par le biais d ’un arbitrage
s ’effectuant sur le champ Identificateur posté par chacune des stations en
concurrence, et en observant bit à bit le niveau de tension du bus
Division - Name - Date - Language
16
Protocole CAN : Controller Area Network
Principes des échanges de données
 Ceci met en jeu un mécanisme implicite de
"ET câblé", par l ’intermédiaire duquel un état
dominant écrase un état récessif
 La compétition pour l’allocation du bus est
perdue par les nœuds en situation simultanée
d ’émission d ’un bit dominant, et d’
observation d ’un bit récessif
 Tous ces "perdants" deviennent automatiquement des "receveurs" des messages disposant de
la priorité la plus haute, comparativement; et dès lors ne re-tente pas de nouvelle émission,
tant que le bus n ’est pas de nouveau disponible
 Les demandes d ’émission sont gérées comme un tout, selon l’ordre d’importance des
messages pour le système. Ceci s ’avère particulièrement avantageux dans les situations de
surcharge. Etant donné que les accès au bus sont priorisés en fonction des messages, il est
possible de garantir de temps de latence individuels courts sur des systèmes temps réel
Division - Name - Date - Language
17
Protocole CAN : Controller Area Network
Formats des trames des messages
 Le protocole CAN admet deux formats de trame de message
 la seule différence essentielle entre ces deux formats réside dans le
longueur du champ Identificateur
 Le format de trame CAN dit format standard, également appelé
CAN 2.0 A, admet un identificateur d ’une longueur de 11 bits
 Le format de trame CAN dit format étendu, également appelé
CAN 2.0 B, admet un identificateur d ’une longueur de 29 bits
Division - Name - Date - Language
18
Protocole CAN : Controller Area Network
Format de trame standard
 Un message sur le format de trame CAN standard commence sur le bit
de Start appelé "Start Of Frame (SOF)"
 Il est suivi d ’un champ appelé "Champ d’Arbitrage", constitué de
l ’Identificateur et du bit RTR "Remote Transmission Request (RTR)",
auquel il est fait appel pour opérer la distinction entre une trame de
données et une trame de demande de ces données, et que l’on nomme
"Remote Frame"
 Le champ suivant, nommé "Champ de Contrôle" comporte un bit nommé
Extension d ’Identificateur ["IDentifier Extension (IDE)" ], qui permet
d ’effectuer la distinction entre une trame CAN standard et yune trame
CAN étendue
Division - Name - Date - Language
19
Protocole CAN : Controller Area Network
Format de trame standard
 Le champ suivant, nommé Code de Longueur des Données ["Data
Length Code (DLC)"] sert à indiquer la quantité des octets de données
qui fait suite, sur le champ "Données" ["Data field" ]
 Si le message considéré est utilisé comme une "Remote Frame", le
champ DLC comporte alors le nombre des octets de données qui sont
demandés
 Le champ "Données" qui vient ensuite est capable de copter à
concurrence de 8 octets de données
Division - Name - Date - Language
20
Protocole CAN : Controller Area Network
Format de trame standard
 L ’intégrité de la trame est garantie par le checksum ["Cyclic Redundant
Check (CRC)"] qui fait suite.
 Le champ Acquit ["ACKnowledge (ACK)"] est un compromis entre Bit
d’Acquit et un Délimiteur d ’Acquit : le bit résidant sur cette position ACK
est émis comme un bit récessif; et il est positionné en dominant par les
récepteurs ayant à ce moment-là correctement réceptionné les
données. Les messages corrects sont acquittés par les récepteurs
indépendamment des résultats du test d ’acceptation
Division - Name - Date - Language
21
Protocole CAN : Controller Area Network
Format de trame standard
 La fin d ’un message est signifiée par un champ "End Of Frame (EOF)"
 Le champ suivant : "Intermission Frame Space (IFS)" caractérise le
nombre minimal de bits séparant deux messages consécutifs
 S ’il n ’y a pas d ’accès au bus, venant à la suite, de la part d ’une autre
station, le bus se place dans l ’état "idle"
Division - Name - Date - Language
22
Protocole CAN : Controller Area Network
Format de trame étendue
 Un message répondant au format étendu de trame CAN est à peu de
choses près le même qu ’un message répondant au format standard de
trame CAN
 La différence tient dans la longueur du champ Identificateur utilisé
 L ’Identificateur est réalisé à partir des 11 bits de l’Identificateur existant
sur le format Standard (dénommé Identificateur de Base), auxquels se
rajoute une extension sur 18 bits ( dénommée Extension
d ’Identificateur)
Division - Name - Date - Language
23
Protocole CAN : Controller Area Network
Format de trame étendue
 La distinction entre format standard et format étendu de trame CAN est
réalisée au moyen du bit IDE. Ce bit est émis comme un bit dominant si
la trame répond au format standard, et comme un bit récessif si la trame
répond au format étendu
 Comme les deux formats se doivent de pouvoir cohabiter sur un même
bus, cela détermine le message qui dispose de la priorité la plus haute
sur le bus, dans le cas d’une collision lors de l’accès au bus, lorsque les
trames en collision présentent un format différent pour un identificateur
de base identique : le message décliné sous le format CAN standard a
toujours la priorité sur le message décliné sous le format CAN étendu
Division - Name - Date - Language
24
Protocole CAN : Controller Area Network
Format de trame étendue
 Les contrôleurs CAN qui admettent les messages en format étendu sont
également capables d’émettre et de recevoir des messages au format
CAN standard
 Lorsque sur un réseau apparaissent des contrôleurs CAN qui ne
connaissent que le format de trame standard, seuls alors sont émis par
l ’ensemble des contrôleurs présents sur l’ensemble de ce réseau des
messages au format CAN standard : dans le cas contraire, les messages
au format CAN étendu ne seraient en effet pas compris par les premiers
 Toutefois, on pourra trouver des contrôleurs n’admettant que le format de
trame CAN standard, tout en reconnaissant, mais en ignorant le format
étendu (version 2.0 B passive)
Division - Name - Date - Language
25
Protocole CAN : Controller Area Network
Détection et signalisation d’erreur
 A la différence des autres bus système, le protocole CAN ne fait pas appel
à des messages d ’acquittement : les erreurs sont signalées dès leur
apparition
 Pour procéder à la détection d ’erreur, le protocole CAN implémente trois
mécanismes au niveau message :
Division - Name - Date - Language

Cyclic Redundancy Check (CRC)

Vérification de Trame

Erreurs sur ACK
26
Protocole CAN : Controller Area Network
Détection et signalisation d’erreur
 Cyclic Redundancy Check (CRC)

Le CRC protège les informations présentes sur la trame en ajoutant
des bits de signature à la fin de l’émission. Côté récepteur, ces bits
sont recalculés et comparés à ceux reçus. S ’il y a discordance, une
erreur de CRC est décrétée
 Test de Trame

Ce mécanisme vérifie la structure de la trame émise, en procédant à
la vérification des champs de bits par rapport à un format fixe, et à la
taille de la trame. Les erreurs décelées par ces tests de trame sont
désignées sous l ’appellation "erreurs de format"
 ACK errors

Division - Name - Date - Language
Comme cela a déjà été mentionné, les trames reçues font l ’objet
d ’un acquit positif par l ’ensemble des récepteurs, par le truchement
d ’un acquit positif. S’il s ’avère qu ’aucun acquit n’est reçu par
l ’émetteur du message, alors est signalée une "ACK error"
27
Protocole CAN : Controller Area Network
Détection et signalisation d’erreur
 Le protocole CAN implémente également deux mécanismes pour la
détection d ’erreur, au niveau bit :


Division - Name - Date - Language
Monitoring
Bit stuffing (bourage)
28
Protocole CAN : Controller Area Network
Détection et signalisation d’erreur
 Monitoring
La capacité de l’émetteur à déceler des erreurs est basée sur la
surveillance des signaux du bus. Chaque nœud qui émet observe en
même temps les niveaux du bus, et détecte ce faisant les différences entre
un bit émis et un bit reçu. Ceci permet une détection fiable des erreurs de
niveau global, ainsi que des erreurs locales à l ’émetteur
 Bit stuffing (bourrage)
Le codage des bits individuels est testé au niveau du bit. La représentation
du bit utilisé par CAN est un codage de type "Non Return to Zero (NRZ)".
Ce codage garantit une efficacité maximale au niveau du codage du bit.
Au cas où, des fronts arbitraires de synchronisation sont générés au
moyen d ’une technique dite de "bit stuffing" (bourrage). Cela signifie
qu’après 5 bits consécutifs et de même niveau, l ’émetteur va insérer un
bit de bourrage dont l ’état sera complémentaire de celui des bits de la
séquence en cours. Ces bits de bourrage seront identifiés et retirés par les
récepteurs.
Division - Name - Date - Language
29
Protocole CAN : Controller Area Network
Détection et signalisation d’erreur
 Si une, voire plusieurs erreurs, sont décelées par au moins un nœud, au
travers de l’un ou l’autre de ces mécanismes, l’émission en cours est
interrompue par l’émission d’un "error flag"
 Ceci permet d ’éviter que les autres stations n’acceptent ce message, et
conforte la cohérence des donnés sur l ’ensemble du réseau
 Après avoir interrompu l’émission d’un message erroné, l ’émetteur essaie
automatiquement une ré-émission. Auquel cas, il peut se trouver qu ’il y ait
à nouveau compétition pour l’allocation du bus
Division - Name - Date - Language
30
Protocole CAN : Controller Area Network
Détection et signalisation d’erreur
 Quelle que soit la pertinence et l ’efficacité des méthodes décrites, il se
peut toutefois arriver que la présence d’un nœud défectueux conduise au
fait que l ’ensemble des messages (y compris les messages corrects)
fassent l ’objet d ’un abort
 Si aucune des mesures d ’auto-surveillance n’a été prise, le bus système
va de ce fait se retrouver bloqué
 C ’est pourquoi le protocole CAN fournit un mécanisme destiné à procéder
à la distinction entre erreurs sporadiques et erreurs permanentes, et
défaillances locales à un nœud
 Ceci est réalisé par évaluation statistique des situations d ’erreur des
nœuds, avec l ’objectif qu ’un nœud puisse reconnaître ses propres
défaillances, et éventuellement se porter dans un mode de fonctionnement
dans lequel le reste du réseau CAN ne sera pas négativement impacté
 Ceci peut aller jusqu’à une déconnexion par la station elle-même, afin
d ’éviter que, par erreur, les messages des autres nœuds ne soient
interprétés comme incorrects
Division - Name - Date - Language
31
Protocole CAN : Controller Area Network
Options de la couche physique
 Conformément à la norme ISO 11898-1, le protocole CAN ne définit pas
de couche physique
 Il définit en effet deux valeurs logiques qui doivent être représentées par
une couche physique
 Outre l ’implémentation des valeurs logiques, la couche physique doit
également être capable de permettre l ’émission et la réception de signaux
exactement dans le même instant
 C’est ce qui justifie l’implémentation d ’un temps de réponse, tel que requis
par le protocole CAN, qui soit inclus dans le temps de bit
 Deux couches physiques différentes sont actuellement définies :
Division - Name - Date - Language

couche Physique Haute Vitesse : Norme ISO 11898-2

couche Physique à Tolérance de Panne : Norme ISO 11898-3
32
Protocole CAN : Controller Area Network
Couche Physique Haute Vitesse : Norme ISO 11898-2
 La couche physique CAN à haute vitesse est spécifiée par la norme
ISO 11898-2
 Cette norme décrit les fonctionnalités de type Medium Access Unit
(MAU) de même que certaines caractéristiques dépendantes du type de
medium utilisé [MDI = Medium Dependent Interface]
 Cette norme est la plus importante, en ce qui concerne la couche
physique, pour ce qui se rapporte aux réseaux CAN dans les
applications d’automatisation industrielle
 D’autres spécifications sont détaillées dans les spécifications CANopen
et DeviceNet. De même, les spécifications relatives àr J1939 sont-elles
basées sur le norme ISO 11898-2
 Dans les automobiles, c’est cette couche physique qui est utilisée, sur
les applications gérant la motorisation et la transmission
Division - Name - Date - Language
33
Protocole CAN : Controller Area Network
Couche Physique Haute Vitesse : Norme ISO 11898-2
 La longueur théorique maximale du bus à 1 Mbit/s est de 40 m
 La longueur effective maximale dépend de la configuration de ‘bit-timing’
Pour des débits inférieurs à 1 Mbit/s, cette longueur du bus peut être
étendue. Ainsi, la longueur maximale du bus à 50 kbit/s est de 1 km
 Le nombre total de nœuds est limité par la charge électrique du bus.
Cependant, on peut recourir à des ponts ou répéteurs pour augmenter
ce nombre
Division - Name - Date - Language
34
Protocole CAN : Controller Area Network
Couche Physique Haute Vitesse : Norme ISO 11898-2
 Le médium physique est une ligne de bus sur 2 fils, avec un commun de
retour; il se termine sur une résistance à ses deux extrémités
 Pour qu’un nœud puisse interpréter correctement les niveaux de tension
du bus, il convient que soient supprimées les réflexions des signaux
électriques sur le bus
 Ceci est réalisé à l ’aide de résistances terminales (120 Ohms nominal)
que l’on place à chaque extrémité de la ligne du bus
 On évitera par principe de loger cette résistance terminale au sein d ’un
équipement, car la lignes de bus perdrait alors sa terminaison en cas de
déconnexion de cet équipement
Division - Name - Date - Language
35
Protocole CAN : Controller Area Network
Couche Physique Haute Vitesse : Norme ISO 11898-2
 Idem, on devra faire en sorte que la topologie de câblage d’un réseau
CAN se rapproche le plus possible d’une structure mono-ligne, en sorte
d ’éviter les réflexions d ’onde sur le câble
 En pratique cependant, il s’avère nécessaire de recourir à des lignes en
dérivation (stub) pour raccorder les équipements au bus
 Les réflexions pourront être minimisées en réalisant des dérivations
aussi courtes que possible, en particulier pour des débits élevés.
Ainsi, à 1 Mbit/s, la longueur d’un câble en dérivation ne doit pas
excéder 0,3 m
 Les câbles de bus peuvent être des fils parallèles, ou des paires
torsadées et/ou blindées, selon les contraintes EMC
Division - Name - Date - Language
36
Protocole CAN : Controller Area Network
Couche Physique Haute Vitesse : Norme ISO 11898-2
 Les connecteur utilisés pour raccorder les équipements au bus devront
présenter une impédance nominale de 120 Ohms, et une résistance
nominale en émission de 70 Méga-Ohms
 Les câbles choisis pour les lignes du bus CAN doivent présenter une
impédance nominale de 120 Ohms, une résistance par unité de
longueur de 70 Méga-Ohms / m, et un retard de ligne nominal de 5 ns/m
 Pour les lignes de bus supérieures à 40 m, la résistance spécifique du
câble de bus devra être inférieure
 Pour les applications courantes, le CiA recommande l ’utilisation de
circuits drivers qui soient compatibles ISO 11898-2
 Plusieurs fabricants proposent des chips intégrant ces transceivers
Division - Name - Date - Language
37
Protocole CAN : Controller Area Network
Couche Physique à Tolérance de Panne : ISO 11898-3
 Il existe plusieurs couches physiques à tolérance de panne, pour les
réseaux basés sur le protocole CAN
 La norme ISO 11519-2 décrit une circuiterie de transceiver présentant
des possibilités très limitées, en termes de fan-out
 Cette norme est destinée à disparaître d ’ici peu
 La couche physique spécifiée dans l’ISO 11992 est dédiée aux
applications de type camion et gros engins, qui offrent des tensions
différentielles élevées
 Le groupe de normalisation ISO TC22 SC3 WG1 a lancé une nouvelle
proposition de thème de travail, qui concerne une couche physique CAN
à tolérance de panne (ISO DIS 11898-3), destinée à se substituer à
l ’ISO 11519-2
Division - Name - Date - Language
38
Protocole CAN : Controller Area Network
Couche Physique à Tolérance de Panne : ISO 11898-3
 Cette nouvelle spécification de transceiver à tolérance de panne va
spécifier une consommation faible puissance, des modes de
déconnexion, ainsi que des procédures de réveil
 La fonctionnalité la plus significative des couches physiques à tolérance
de panne est leur capacité à opérer une émission sur un seul fil, en cas
de court-circuit d ’une ligne de bus avec la masse ou avec la tension
d ’alimentation
 Les court-circuits entre les deux lignes de bus conduisent de même à
une émission sur un seul fil
Division - Name - Date - Language
39
Protocole CAN : Controller Area Network
Couche Physique à Tolérance de Panne : ISO 11898-3
 L ’ISO 11898-3 spécifie l ’accès au bus CAN à tolérance de panne pour
des équipements plus modestes, en ce qui concerne le débit et la
longueur de bus
 Elle est essentiellement destinée à être utilisée dans les réseaux
électroniques de confort, sur les véhicules à moteur
 Pour fournir les conditions d ’une tolérance de panne, la résistance de
terminaison globale d’un réseau doit être d ’environ 1000 Ohms (et non
inférieure à 100 Ohms)
 Il est possible d ’utiliser des transceivers de bus à faible consommation,
ce qui permet de maintenir à son minimum la consommation du bus
Division - Name - Date - Language
40
Protocole CAN : Controller Area Network
Couche Physique à Tolérance de Panne : ISO 11898-3
 Le nombre de nœuds participants, tel que spécifié dans la norme ISO
11898-3, ne devrait pas être inférieur à 20 (à 125 kbit/s, pour une
longueur totale de réseau de 40 m) et pourrait monter à 32
 Le nombre effectif de nœuds varie, en fonction de la vitesse de
communication, de la charge capacitive du réseau, de la longueur de
ligne totale, du concept de terminaison de réseau, etc.
 Pour pouvoir fournir une vitesse de communication maximale de 125
kbit/s, la longueur totale du réseau ne devrait pas dépasser 40 m.
Toutefois, il est possible d ’augmenter cette longueur totale de réseau en
diminuant le débit
Division - Name - Date - Language
41
Protocole CAN : Controller Area Network
Couche Physique à Tolérance de Panne : ISO 11898-3
 La ligne de bus, dans la spécification ISO 11898-3, peut présenter l ’un
des deux états logiques que sont les états "récessif" et "dominant". Pour
pouvoir effectuer la distinction entre ces deux états, on considère une
tension différentielle
 Dans l ’état "récessif", la ligne CAN_L line est fixée à une tension
supérieure à celle de la ligne CAN_H. Ceci conduit en général à une
tension différentielle négative
 L ’état "dominant" est représenté par une tension différentielle positive.
Cela signifie que la lige CAN_H est fixée de façon active à un niveau de
tension supérieur, et que la lige CAN_L est fixée de façon active à un
niveau de tension inférieur
 L ’état "dominant" prend le pas sur l ’état "récessif", et s ’affirme au
travers des bits "dominants"
Division - Name - Date - Language
42