L'« histoire » du CAN

La disponibilité de composants microélectroniques performants et peu coûteux a permis à l'industrie automobile d'introduire des calculateurs électroniques autonomes (ECU) pour différents domaines fonctionnels, tels que l'allumage, la commande de transmission et les systèmes antiblocage. Il est rapidement apparu que, pour de nouvelles améliorations fonctionnelles — et donc une amélioration significative du comportement de conduite —, la synchronisation de tous les processus répartis entre les différents calculateurs était nécessaire, réalisée par un échange de données contrôlé entre les dispositifs.

L'introduction de systèmes de communication numériques dans l'industrie automobile a également été motivée par le nombre croissant d'équipements électroniques de carrosserie et de confort à connecter, tels que la climatisation, le réglage des sièges et rétroviseurs, les vitres électriques, les systèmes antivol et les mécanismes de verrouillage et d'éclairage centralisés. Dans le domaine automobile, un système de communication numérique devait principalement réduire la quantité et la longueur du câblage, et atténuer les points de câblage critiques, comme le passage entre l'habitacle et les portes avant.

En raison des exigences particulièrement élevées en matière de robustesse de la transmission de données dans un environnement riche en interférences électromagnétiques, il a été nécessaire de développer un concept de communication adapté. Ce fut le point de départ du développement du protocole CAN (Controller Area Network), initié par Bosch en 1983. Depuis — en plus de l'utilisation dans les voitures — le CAN est présent dans un large éventail de domaines d'application :

• Véhicules utilitaires (camions de collecte et de pompiers)
• Transports en commun (chemins de fer, trains, tramways, bus)
• Agriculture et sylviculture (tracteurs, etc.)
• Militaire
• Aviation et maritime
• Bâtiments (ascenseurs)
• Construction (grues, pelleteuses, etc.)

Topologie de bus, nombre de participants

Les réseaux CAN sont typiquement organisés en structures linéaires avec des résistances de terminaison de 120 Ohms à chaque extrémité de la ligne (voir figure). Les dérivations sont autorisées dans une certaine mesure, et une topologie en étoile est également possible (par ex. dans les applications automobiles). Le nombre de participants (nœuds) dans chaque réseau n'est pas limité par le protocole mais dépend des performances des composants utilisés.

Les répéteurs CAN ont de multiples usages lorsque les réseaux CAN doivent être étendus : ils peuvent être utilisés pour établir un couplage physique de deux segments ou plus d'un système de bus CAN, pour implémenter des topologies en arbre ou en étoile, ou pour ajouter de longues lignes de dérivation. De plus, les segments de réseau peuvent être découplés électriquement à l'aide d'un répéteur à isolation galvanique.

Figure 1 : Topologie linéaire d'un réseau CAN

Messages CAN

La communication sur le bus CAN s'effectue via des « messages » qui contiennent à la fois des bits de contrôle et des bits de données. La structure d'un tel message est appelée trame.

• Trame de données (Data Frame) : Utilisée pour transmettre des données d'un émetteur vers un ou plusieurs récepteurs à l'initiative de la source de données (émetteur).
• Trame de requête (Remote Frame) : Permet à un participant du bus (récepteur) de demander la transmission d'un message spécifique à une source de données.
• Trame d'erreur (Error Frame) : Signale à tous les participants du bus (émetteurs ou récepteurs) qu'une erreur de transmission a été détectée.
• Trame de surcharge (Overload Frame) : Utilisée par un contrôleur CAN pour indiquer une surcharge. Cette trame n'est plus implémentée aujourd'hui, car les performances des contrôleurs modernes sont suffisantes.

Échange de messages selon le principe producteur-consommateur

Contrairement à une transmission orientée nœud, dans laquelle un message est échangé entre deux nœuds spécifiques, la transmission des messages CAN repose sur le principe producteur-consommateur. Un message transmis par un nœud (producteur) peut être lu par tous les autres nœuds (consommateurs). À cette fin, les messages ne sont pas marqués avec une destination mais avec un identifiant de message unique. L'envoi de messages à tous les nœuds d'un réseau est également appelé diffusion (broadcasting).

Figure 2 : Identifiant 11 bits (format standard, spécification CAN 2.0A)

• SOF : Start of Frame = un bit dominant
• RTR : Remote Transmission Request — si le bit RTR est positionné, il définit une Remote Frame
• IDE : Identifier Extension, 1 bit
• r0 : bit réservé
• DLC : Data Length Code = 4 bits (nombre d'octets dans le champ de données, 0 à 8 octets, les valeurs 9 à 15 ne sont pas supportées)

L'identifiant de message désigne le contenu du message CAN, pas le dispositif. Dans un système de mesure, par exemple, un identifiant distinct peut être attribué aux paramètres température, tension et pression. Cependant, plusieurs paramètres peuvent aussi être combinés sous un seul identifiant si le total des données ne dépasse pas la longueur maximale du champ de données.

Les dispositifs récepteurs décident sur la base de l'identifiant si un message leur est pertinent et filtrent les messages concernés à partir du flux de données disponible sur le bus.

Le format standard d'un identifiant CAN est habituellement de 11 bits, permettant 2 048 messages différents par système. Ce nombre est suffisant pour la plupart des applications. Cependant, l'utilisation d'identifiants de 29 bits (format étendu) permet de définir beaucoup plus de messages différents. Habituellement, les 29 bits sont structurés et utilisés pour des applications spéciales (par ex., camions, SAE J1939).

Format de trame

Le début d'un message (voir image) est signalé par un bit dominant de tête, suivi de l'identifiant de message de 11 bits et d'un bit supplémentaire qui distingue entre un message de données et un message de requête de transmission à distance (RTR). Un nœud du réseau peut demander la transmission d'un message particulier à un autre nœud du système. Cependant, le nœud distant doit être programmé pour répondre à un tel message RTR.

Le champ de contrôle spécifie le format de transmission (standard/étendu) d'un message et le nombre d'octets de données suivants.

Le champ de données d'un message CAN peut contenir de zéro à huit octets de données. Le champ de données est suivi du segment CRC de 15 bits, qui permet au récepteur de vérifier le message reçu. Dans le champ d'acquittement, l'émetteur d'un message attend la confirmation d'une réception sans erreur d'au moins un nœud récepteur du réseau. Cette confirmation — utilisée exclusivement pour l'isolation des défauts côté émetteur — est fournie par tous les nœuds récepteurs sans erreur du réseau en envoyant un bit dominant dans le slot d'acquittement.

Le champ de fin de trame (EOF) signale l'achèvement d'une transmission sans erreur d'un message CAN.

Figure 3 : Format d'un message CAN standard (trame de données)

• Start of Frame (SOF) = un bit dominant
• Champ d'arbitrage, composé d'un segment d'identifiant (11 bits ou 29 + 2 bits) plus un bit RTR
• Champ de contrôle (CTRL) = 6 bits — IDE (1 bit), réservé (1 bit), DLC (4 bits)
• Champ de données (DATA) = 0 à 8 × 8 bits
• Somme de contrôle (CRC) = 15 bits suivis d'un bit délimiteur CRC récessif
• Champ d'acquittement (ACK) = 2 bits (bit ACK + délimiteur ACK récessif)
• Fin de trame (EOF) = 7 bits (récessifs)
• Intermission (IFS) = 3 bits ; nombre min. de bits récessifs séparant les messages consécutifs

Transmission multimaître, orientée événement

Chaque nœud d'un réseau CAN peut commencer à émettre un message dès que le bus est libre. Il peut arriver que plus d'un nœud commence à transmettre un message en même temps. Un processus de sélection (arbitrage du bus) est donc nécessaire pour garantir qu'un seul nœud continue la transmission de son message.

Comme chaque nœud peut initier un transfert de message, un échange d'informations direct entre tous les participants du réseau est possible. Il en résulte une charge de bus beaucoup plus faible et un besoin réduit en débit de transmission de données par rapport à une transmission cyclique de messages.

Arbitrage sans perte, bit à bit

L'arbitrage garantit un transfert de messages fluide et correct sur le bus CAN. Pendant la phase d'arbitrage, il est déterminé lequel des messages transmis simultanément a la priorité la plus élevée. Seul le nœud envoyant ce message peut poursuivre la transmission après l'arbitrage. Le message avec la valeur d'identifiant la plus basse a la priorité la plus élevée.

Pendant la phase d'arbitrage qui inclut la transmission de l'identifiant de message et du bit RTR, chaque nœud surveille le niveau de signal sur le bus. Si un nœud, émettant lui-même un niveau récessif (un 1 logique), détecte un niveau de bus dominant (un 0 logique), il interrompt immédiatement son processus de transmission et passe en état de réception. Comme pour tout arbitrage de bus, une fois qu'un message est envoyé, la procédure assure un accès au bus sans perte.

Figure 4 : Principe de l'arbitrage bit à bit sans perte — Les nœuds 1, 2 et 3 démarrent un processus d'arbitrage au même moment. Au point 2, le nœud 2 détecte que le bus n'a pas le niveau récessif qu'il avait l'intention de transmettre et annule son processus. Au point 3, le nœud 1 abandonne. Au point 4, le nœud 3 transmet ses données.

Communication orientée priorité

Le processus d'arbitrage décrit ci-dessus garantit que le message avec la priorité la plus élevée est transmis dès que le bus est libre. Le principe de communication orientée priorité permet une utilisation très efficace de la bande passante disponible pour la transmission de données. Il assure que les messages de basse priorité peuvent utiliser le bus sans retarder significativement la transmission des messages de haute priorité. Pour le message de plus haute priorité à un débit de 1 Mbit/s, la latence maximale résultante est de 130 temps de bit.

En revanche, lors de la conception d'un système CAN, il faut veiller à ce que les messages de haute priorité n'occupent pas en permanence le bus. Ceci peut être réalisé en introduisant des temps de blocage de transmission (CANopen : Inhibit Time).

Débit binaire et longueur de bus

Le principe d'arbitrage bit à bit utilisé en CAN nécessite une comparaison des niveaux de bits locaux de tous les nœuds répartis sur le réseau de bus dans un seul intervalle de temps de bit. Puisque le temps de propagation du signal — nécessaire à la dispersion du signal sur le bus — est proportionnel à la longueur du bus, la durée d'un intervalle de bit doit augmenter avec la longueur du bus.

La taille maximale possible du réseau est donc essentiellement déterminée par le temps de propagation du signal du support de bus : à 1 Mbit/s, par exemple, une portée de réseau jusqu'à 40 m est possible, tandis qu'à 80 kbit/s, la taille du réseau peut dépasser 1 000 m.

Figure 5 : Rapport entre débit de données et longueur de câble — La ligne pointillée montre la règle empirique pour les débits < 400 kbit/s et les longueurs > 100 m. La zone grise montre l'utilisation autorisée sans prise en compte des temps de transit électriques.

La longueur maximale du bus et le débit binaire maximal se comportent de manière inverse. Pour une longueur de bus de plus de 100 m, la règle empirique suivante peut être utilisée : Débit binaire (en Mbit/s) × longueur de bus (en m) ≤ 60

Détection d'erreurs et isolation des défauts

L'une des principales caractéristiques du protocole CAN est sa forte capacité à détecter les erreurs de transmission. Cela permet au CAN de répondre aux exigences très élevées requises pour la mise en réseau des dispositifs de contrôle dans les véhicules.

La haute capacité de détection d'erreurs est obtenue par la combinaison de plusieurs mesures. L'une des plus efficaces est la surveillance du niveau de bus par l'émetteur d'un message (bit monitoring). Ainsi, toutes les erreurs à effet global sont détectées. De plus, chaque récepteur de message vérifie également chaque message reçu à l'aide du segment CRC ainsi que des éléments de format fixe. Cela permet de détecter même les erreurs à effet local.

En plus de la détection des erreurs de transmission, le protocole CAN inclut également un mécanisme d'identification et de déconnexion des nœuds défectueux. Cela garantit que les nœuds de réseau défaillants n'interfèrent pas continuellement avec le transfert de messages.

Signalisation d'erreurs

Contrairement aux concepts de communication avec transmission orientée abonné, le CAN — en tant que protocole orienté message — suit le principe de signalisation d'erreurs, où chaque nœud vérifie l'exactitude de chaque message transmis sur le bus.

Dès qu'un nœud émetteur ou récepteur détecte une erreur, il le signale à tous les autres nœuds en envoyant un message d'erreur (Error Frame). Cette trame contient une séquence de bits (normalement invalide) de six bits de même polarité, habituellement une séquence de bits dominants. Tous les nœuds détectent le signal d'erreur et rejettent la partie du message déjà reçue. Ainsi, un jeu de données cohérent est assuré pour tous les abonnés du réseau.

Une fois qu'un nœud émetteur a transmis ou reçu une trame d'erreur, il tente immédiatement de retransmettre le message précédent via l'arbitrage du bus.

Le mécanisme de signalisation d'erreurs garantit que l'échange de messages reste exact et cohérent entre tous les abonnés opérationnels du réseau. La signalisation d'erreurs intervenant immédiatement après la détection d'une erreur, des temps de récupération très courts sont garantis. De plus, le fait que le bus ne soit occupé supplémentairement que lorsqu'une erreur survient offre un avantage significatif par rapport aux méthodes d'acquittement : une charge de bus additionnelle beaucoup plus faible.

Protocoles de couche supérieure

Le protocole CAN décrit ci-dessus, normalisé dans l'ISO 11898, correspond à un protocole de couche 1/2 dans le modèle OSI de communication de données. Cependant, des fonctions supplémentaires sont nécessaires pour réaliser des réseaux complets.

Deux standards sont largement utilisés dans les systèmes embarqués et l'automatisation industrielle : CANopen et DeviceNet. CANopen est le standard dominant pour les applications réseau embarquées, tandis que DeviceNet est principalement utilisé dans l'automatisation industrielle, en particulier dans les systèmes de Rockwell Automation. Dans le domaine des véhicules utilitaires, la norme SAE J1939 est également appliquée.