Protocole CAN Tutoriel

Protocole CAN Tutoriel
1

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)

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 (format de trame étendu) Publication par le CiA du protocole CANopen Développement du protocole de communication TTCAN : Time-Triggered communication protocol for CAN

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

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

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

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

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

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

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 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

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 J définit les communications basées sur CAN sur les camions et bus

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 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 De même en ce qui concerne les Smart Distributed Systems basés sur CAN : EN

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

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

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

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

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

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

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

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

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

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"

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)

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

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)

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 : Cyclic Redundancy Check (CRC) Vérification de Trame Erreurs sur ACK

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 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"

Le protocole CAN implémente également deux mécanismes pour la détection d ’erreur, au niveau bit : Monitoring Bit stuffing (bourage)

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.

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

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

Protocole CAN : Controller Area Network Options de la couche physique
Conformément à la norme ISO , 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 : couche Physique Haute Vitesse : Norme ISO couche Physique à Tolérance de Panne : Norme ISO

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 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 Dans les automobiles, c’est cette couche physique qui est utilisée, sur les applications gérant la motorisation et la transmission 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 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 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 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 Plusieurs fabricants proposent des chips intégrant ces transceivers 2

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 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 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 ), destinée à se substituer à l ’ISO 2

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 2

L ’ISO 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 2

Le nombre de nœuds participants, tel que spécifié dans la norme ISO , 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 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 2

La ligne de bus, dans la spécification ISO , 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" 2

Protocole CAN Tutoriel

Présentations similaires

Présentation au sujet: "Protocole CAN Tutoriel"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back

Entrer

S'autoriser via un réseau social:

Protocole CAN Tutoriel

Présentations similaires

Présentation au sujet: "Protocole CAN Tutoriel"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back