 |
|
Introduction
|
|
|
|
1.1 Origines et utilisations du CAN.
1.2 Le CAN dans le modèle ISO/OSI.
1.3 Fonctionnement du CAN.
Le CAN est un protocole de communication série qui supporte efficacement le contrôle en temps réel de systèmes distribués tels qu'on peut en trouver dans les automobiles, et ceci avec un très haut niveau d'intégrité au niveau des données. Le CAN a été standardisé par l'ISO dans les normes 11898 pour les applications à hauts débits et ISO 11519 pour les applications à bas débits. | ||||||||||||||||||||||||
1.1 Origines et utilisations du CAN. | ||||||||||||||||||||||||
1.1.1 Le CAN dans l'industrie automobile.Pour satisfaire les exigences de plus en plus importantes du client en matière de sécurité et de confort, et pour se conformer aux les lois de réduction de la pollution et de la consommation de plus en plus drastiques, l'industrie automobile a développé de nombreux systèmes électroniques : systèmes anti-patinage, contrôle électronique du moteur, de l'air climatisé, fermeture centralisée des portes, etc. La complexité de ces systèmes et la nécessité d'échanger des données entre eux signifient de plus en plus de câbles. A côté du coût très important de ce câblage, la place qui lui est nécessaire pouvait le rendre tout simplement impossible. Enfin, le nombre croissant de connections et de câbles posait de sérieux problèmes de fiabilité et de réparation. Bosch, un important équipementier automobile, a fournit la solution dans le milieu des années 80 avec le bus CAN. L'entreprise allemande a définit le protocole et a autorisé de nombreux autres fabricants à développer des composants compatibles CAN. Avec le protocole CAN, les contrôleurs, capteurs et actionneurs communiquent
entres eux sur deux câbles à une vitesse pouvant aller jusqu'à 1 Mbits/s.
Les contrôleurs CAN sont physiquement petits, peu coûteux et entièrement
intégrés. Ils sont utilisables à des débits importants, en temps réel et dans
des environnements difficiles. Enfin, les transmissions ont un haut niveau de
fiabilité. C'est pourquoi ils ont été utilisés dans d'autres industries que
l'automobile et des applications utilisant le CAN sont aujourd'hui disponibles
dans l'agriculture, la marine, le matériel médical, les machines textiles, etc.
On apprend dans une enquête de la publication Electronics Weekly du 15 novembre 1995 que, dans le monde :
| ||||||||||||||||||||||||
1.2 Le CAN dans le modèle ISO/OSI. | ||||||||||||||||||||||||
|
Le CAN étant un protocole réseau, il s'intègre dans la norme ISO/OSI (ISO : International Standards Organization, OSI : Open Systems Interconnection) qui définit 7 couches permettant de couvrir la totalité d'un protocole. Les différentes couches définissent les services du protocole. Le tableau suivant résume les couches utilisées par le protocole CAN.
1.2.1 Le modèle ISO/OSI1.2.1.1 La couche physique.La première couche du modèle a pour but de conduire les éléments binaires jusqu'à leur destination sur le support physique. Elle fournit les moyens matériels nécessaires à l'activation, au maintien et à la désactivation de ces connections physiques. Cette couche gère la représentation du bit (codage, timing, synchronisation), et définit les niveaux électriques, optiques,... des signaux ainsi que le support de transmission. Le protocole CAN ne décrit que la représentation détaillée du bit (Physical Signalling),
mais pas le moyen de transport et les niveaux des signaux de telles sorte qu'ils puissent
être optimisés selon l'application.
Elle fournit les moyens fonctionnels nécessaires à l'établissement, au maintien et à la libération des connexions entres les entités du réseau. Cette couche (aussi appelée couche de communication de donnée, Data Link Layer) devra notamment corriger les erreurs qui ont pu se produire au premier niveau (même s'il est impossible de corriger toutes les erreurs). Le protocole CAN décrit entièrement cette couche. La couche liaison est subdivisée en deux sous-couches. La sous-couche LLC (Logical Link Control) effectue :
La sous-couche MAC (Medium Access Control), qui est le coeur du protocole CAN, effectue :
1.2.1.3 La couche réseau.La couche réseau doit permettre d'acheminer correctement les paquets d'informations jusqu'à l'utilisateur final, en passant par des passerelles qui interconnectent plusieurs réseaux entre eux. Elle assure le contrôle des flux (pour tenir des temps de réponse acceptables), le routage des paquets, et l'adressage (pour l'ensemble des machines du monde !). C'est aussi ici qu'interviennent les deux philosophies concurrentes des réseaux:
Cette couche est vide dans le protocole CAN.
La couche transport est le dernier niveau qui s'occupe de l'acheminement des informations. Elle doit optimiser la qualité de la transmission, notamment avec des outils de détection d'erreurs et des algorithmes de renvoi des messages perdus. Cette couche est vide dans le protocole CAN.
La couche de session permet aux différents éléments du réseau d'organiser et de synchroniser leur dialogue. Il faut en effet s'assurer si l'on veut émettre de l'information qu'un récepteur est là pour récupérer ce qui a été envoyé. Cette couche est vide dans le protocole CAN.
Cette couche se charge de la syntaxe des informations que se communiquent les éléments du réseau, c'est-à-dire que ces éléments utilisent bien un langage commun pour transférer des données. Cette couche est vide dans le protocole CAN.
C'est la dernière couche du modèle OSI. Elle donne aux applications le moyen d'accéder aux couches inférieures. Cette couche a été normalisée en 1987 au sein d'une structure globale : la structure de la couche application, ou ALS (Application Layer Structure). Elle détermine comment différentes applications vont pouvoir coexister et utiliser des modules communs. De très nombreuses normes ont été définies sur cette base. Cette couche n'est bien sûr pas vide pour le protocole CAN, mais sa spécification est laissée à l'utilisateur. | ||||||||||||||||||||||||
1.3 Fonctionnement du CAN. | ||||||||||||||||||||||||
1.3.1 Principes.1.3.1.1 "Identifiers".Les trames de données transmises par un noeud sur le bus ne contiennent ni une quelconque adresse du noeud expéditeur ou du noeud destinataire. C'est plutôt le contenu du message, sa signification (son "meaning") qui est précisé par un identificateur (ID). Chaque noeud recevant un message regarde si celui-ci est intéressant pour lui grâce à l'ID. Si c'est le cas, il le traite, sinon, il l'ignore. Cet unique ID indique aussi la priorité des messages. Plus la valeur est faible,
plus le message sera prioritaire. Si deux noeuds ou plus cherchent à avoir
accès au bus en même temps, c'est celui de plus haute priorité qui gagne. Les
messages de priorité inférieure seront automatiquement retransmis lorsque le bus
sera libre.
La norme CAN ne spécifie pas de couche physique. Différentes implémentations sont donc possibles : filaire, HF, infrarouge, par fibre optique, etc. Mais toute implémentation doit respecter le principe des bits dominants /
récessifs. Chaque noeud doit pouvoir présenter sur le bus un bit appelé
dominant (0 logique) et un bit appelé récessif (1 logique). Les implémentations
doivent aussi respecter la règle suivante : si 2 noeuds présentent des niveaux
logiques différents, le bit dominant s'impose.
Dans un système typique, certains paramètres vont changer plus rapidement que d'autres. Ce sera par exemple la vitesse d'un moteur, tandis qu'un paramètre plus lent pourra être la température de l'habitacle. Il est donc naturel que les paramètres qui varient le plus soient transmis le plus souvent et par conséquent doivent avoir une plus grande priorité. Dans les applications en temps réel, ceci nécessite non seulement une vitesse de transmission importante, mais aussi un mécanisme d'allocation du bus efficace qui soit capable de traiter les cas où plus d'un noeud cherchent à transmettre en même temps. Pour déterminer la priorité des messages, le CAN utilise la méthode CSMA/CD (Carrier Sense, Multiple Access with Collision Detect) avec la capacité supplémentaire de l'arbitrage non destructif (Non-Destructive Bitwise Arbitration) afin d'offrir une disponibilité maximale du bus. Comme on l'a vu précédemment, la priorité d'un message est déterminée par la valeur de son ID. La valeur de chaque ID, et donc la priorité de chaque type de messages, est assignée durant la conception du système. Un certain nombre de standards ont été développés selon les domaines d'utilisation du bus CAN pour fixer la priorité des ID et permettre une interopératibilité des différents équipements. Tout conflit de bus est résolu par le mécanisme du "ET cablé", c'est-à-dire qu'un état dominant écrase un état récessif. Concrètement, si plusieurs noeuds débutent leur trame en même temps, le premier qui présente un bit récessif alors qu'au moins un autre présente un bit dominant perd l'arbitrage (dans la trame, l'ID commence par le bit de poids fort).
Tout ce passe donccomme si le message de plus haute priorité était le seul à être transmis. Lorsqu'un noeud perd l'arbitrage, il devient automatiquement un récepteur du message en cours de transmission, et il n'essaiera de retransmettre son message que lorsque le bus sera à nouveau libre. L'avantage d'un tel système est une utilisation meilleure du bus qu'avec
d'autres mécanismes, tels que le mécanisme de "fixed time schedule allocation" du Token ring
ou l'arbitrage destructif de l'Ethernet.
L'information sur le bus est envoyée sous la forme de messages (Appelés
aussi trames ou "frames".) au format fixé. Quand le bus est libre, n'importe
quel noeud peut commencer à envoyer un message.
Le protocole CAN 2.0 comporte deux sous-spécifications qui diffèrent uniquement au niveau de la longueur de l'ID. La version 2.0A définit des ID de 11 bits et la version 2.0B des ID de 29 bits. On appelle ces trames respectivement des trames standards ("Standard Frames") et des trames étendues ("Extended Frames"). Le format standard est équivalent au format tel qu'il était décrit dans la version 1.2 du protocole. Le format étendu est une nouvelle fonctionnalité du protocole 2.0. Pour permettre le développement de contrôleurs assez simple, le support complet du format étendu n'est pas requis pour être conforme au protocole 2.0. Les contrôleurs sont considérés conforme au protocole 2.0 s'ils respectent les deux conditions suivantes :
On se référera à la description du protocole CAN en 10.3.1.2 pour le détail du fonctionnement de la
compatibilité du CAN 2.0B par rapport au 2.0A.
Quatre types de messages peuvent être transmis :
1.3.4 Format des trames de données.Les trames de données (Data Frames) sont composées de 7 parties détaillées ci-après. Le format est indiqué pour des trames respectant le protocole 2.0A. On se référera à la documentation du protocole CAN pour le format des trames 2.0B.
1.3.4.1 Start of frame.Le bit Start of frame (SOF) marque le début d'une Data Frame ou d'une Remote frame. C'est un unique bit dominant. Un noeud ne peut bien sûr débuter une transmission que si le bus est libre. Ensuite, tous les autres noeuds se synchronisent sur SOF du noeud ayant
commencé une transmission.
L'Arbitration field est constitué de l'identifieur et du bit RTR. L'identificateur (ID) permet d'identifier le message. Il est transmis dans l'ordre ID10 à ID0, où ID0 est le bit le moins significatif. Le bit RTR (Remote Transmission Request) caractérise les Remote Frames. Il est
dominant dans les Data Frames et récessif dans les Remote Frames.
Le Control field est composé de 6 bits. Les 2 premiers sont des bits réservés et
les 4 suivants constituent le Data length code (DLC). Le DLC indique le nombre
d'octets du Data field. La valeur du DLC est forcément comprise entre 0 et 8,
soit 9 valeurs. 4 bits dominants (0000) correspondent à la valeur 0 pour le DLC,
tandis que 1 bit récessif et 3 bits dominant (1000) correspondent à la valeur 8.
Le CRC field est composé de la séquence de CRC sur 15 bits suivi du CRC delimiter (1 bit récessif). La séquence de CRC (Cyclic redundancy code) permet de vérifier l'intégrité des données
transmises. Les bits utilisés dans le calcul du CRC sont ceux du SOF, de l'Arbitration field,
du Control field et du Data field.
Le ACK field est composé de 2 bits, l'ACK Slot et le ACK Delimiter (1 bit récessif).
Le noeud en train de transmettre envoie un bit récessif pour le ACK Slot.
Un noeud ayant reçu correctement le message en informe le transmetteur en envoyant un
bit dominant pendant le ACK Slot : il acquitte le message.
Chaque Data frame et Remote frame est terminée par une séquence de 7 bits récessifs.
Pour les Data Frames et les Remote Frames, les bits depuis le Start of frame jusqu'à la séquence de CRC sont codés selon la méthode du bit stuffing. Quand un transmetteur détecte 5 bits consécutifs de même valeur dans les bits à transmettre, il ajoute automatiquement un bit de valeur opposée.
1.3.6 Détection et gestion des erreurs.Le CAN a été créé pour opérer dans des environnements difficiles et c'est
pourquoi il comprend de nombreux mécanismes de détection d'erreur.
Le CAN implémente cinq mécanismes de détection des erreurs, 2 au niveau bits (le "bit monitoring" et le "bit stuffing") et 3 au niveau messages (vérification du CRC, de la forme des trames et de l'acquittement). Ces cinq types d'erreurs différents qui peuvent être détectée par un noeud sont :
1.3.6.2 Trames d'erreursUne trame d'erreur est constituée de deux parties. La première est formée par la superposition des différents "Error flags" mis par les noeuds du bus. La seconde partie est un délimiteur. Un noeud qui détecte une erreur la signale en envoyant un Error flag. Celui-ci viole la règle du bit stuffing (6 bits dominants consécutifs) et par conséquent, tous les autres noeuds détectent aussi une erreur et commencent à envoyer un Error flag. La séquence de bits dominants qui existe alors sur le bus est le résultat de la superposition de plusieurs Error flags, et sa longueur varie entre 6 et 12 bits. Il existe deux types d'Error flags :
L'Error delimiter est composé de 8 bits récessifs. En fait, après avoir transmis
son Error flag, chaque noeuds envoie des bits récessifs et observe le bus
jusqu'à ce qu'il détecte un bit récessif, après quoi il envoie encore 7 bits
récessifs supplémentaires.
Le confinement des erreurs est un mécanisme permettant de faire la différence entre des erreurs temporaires ou permanentes. Les erreurs temporaires peuvent être causées par des glitchs par exemple, tandis que des erreurs permanentes sont en général due à de mauvaises connections ou à des composants défaillants. Ce système va permettre d'enlever un noeud défaillant du bus qui sinon aurait pu perturber les autres noeuds. Un noeud peut être dans trois états : error-active, error-passive ou bus-off.
Deux compteurs d'erreurs sont implémentés dans chaque noeud : celui des erreurs en transmission (Transmit error count) et celui des erreurs en réception (Receive error count). Les grandes règles de modifications des compteurs d'erreurs sont les suivantes. Elles sont détaillées avec leurs exceptions dans le protocole CAN en 5.2.
Un noeud est en mode error-active si ses deux compteurs d'erreurs sont
inférieurs à 127. Il est en error-passive si l'un des deux est compris entre 128
et 256. Si le Transmit error count est supérieur à 256, le noeud est en
bus-off.
Le protocole CAN est extrêmement fiable au de niveau de la détection des erreurs. Les erreurs survenants sur tous les noeuds sont détectables à 100 %. Au niveau des erreurs survenants sur un seul noeud, rien que la vérifcation du CRC peut permettre de détecter jusqu'à 5 erreurs de bits avec une probabilité de 100 % . La probabilité qu'une erreur ne soit pas détectée par le mécanisme du CRC est de 3.10-5. Avec tous les autres mécanismes de détection, la vraie valeur est de 10-11. De plusieurs appareils identiques, celui que vous choisirez sera le seul à ne pas fonctionner. Généralisation de l'Axiome du Choix de Picavet. | ||||||||||||||||||||||||
