CanBus: format des paquets CanBus et paquets étendu et protocoles étendus
A propos de canbus
Dans le précédent articles "Canbus: à la découverte du bus CAN et du shield CanDIY" nous abordions les principes de base du bus CAN et le format du paquet CAN standard.
Dans cet article, nous allons survoler le paquet CAN étendu et quelques protocoles CAN plus populaires que d'autres.
Bonne lecture,
Dominique
Le paquet CAN standard
Tout commence avec le paquet standard du bus CAN, paquet que nous avons décrit dans le précédent article.
Le problème du paquet standard CAN, c'est qu'il ne peut transporter uniquement 8 octets... pas mal pour des projets électroniques mais un peu juste s'il y a plus d'information à faire transiter.
Avec un ID en 11 bits, il est possible de coder 2047 IDs différents. L'ID sert à identifier l'émetteur d'information.
Ceci étant, si un intervenant (un calculateur) à besoin d'envoyer plus que 8 octets de données sur le bus CAN alors il devra utiliser plusieurs IDs pour communiquer cette informations.
Le paquet CAN étendu
Le paquet standard ne supporte que 2047 IDs... s'il y a de nombreuses informations à transporter alors nous risquons de tomber à court
Les paquets CAN étendu (extended CAN paquet) est un deuxième format supporté en standard par les bus CAN (à partir de la révision 2.0B).
Les paquets étendus sont identifié par le bit IDE qui est mis à 1 alors que ce dernier bit est 0 pour un paquet standard.
Avec le bit IDE à 1, le format de paquet étendu rajoute 18 bits au 11 premiers bits d'identification. Au total, cela fait une identification à 29 bits ( soit 563 870 911 IDs différents), de quoi transmettre un sacré paquet d'information sur le bus CAN.
La version étendue utilise également des flags différents (notez le RTR remplacé par un SRR) et déplacement du RTR après la zone d'arbitration ID.
Ceci étant, ce n'est pas parce que le paquet CAN est définit avec un format standard qu'il n'y a pas d'implémentation de protocole diverses et variées entrant dans le trames "Can Standard Packet" ou "Can Extented Packet". C'est surtout le monde automobile que l'on trouve des variantes... avec les protocoles les plus populaires étant ISO-TP et CANopen.
Protocole ISO-TP
Le protocole ISO-TP, aussi connu sous la norme ISO 15765-2, est un protocole standard pour envoyer des packets de données supérieurs à 8 octets.
ISO-TP permet d'envoyer jusqu'à 4095 octets en chaînant des paquets ensembles.
Ce protocole est utilisé lorsqu'il est nécessaire de transmettre une grande quantité d'information sur le bus CAN. Il est entre-autre utilisé pour les systèmes de diagnostique automobile (Unified Diagnostic Service).
ISO-TP permet, par exemple, de créer un tunnel IP over CAN (voir utilitaire isotptun sous Linux).
Pour pouvoir encapsuler ISO-TP dans CAN, un des huit octets est réservé pour étendre l'adressage, laissant ainsi 7 octets de donnée dans le packet CAN.
L'inconvénient du protocole ISO-TP est qu'il est facile d'inonder le bus CAN s'il y a beaucoup de données à faire transiter sur le bus. Il ne faut pas oublier que les paquets sont broadcastés.
Protocole CANopen
Dans le protocole CANopen, les 11 bits d'identification (Arbitration ID) du paquet CAN sont répartis en 4 bits de code fonction + 7 bits de ID (Node ID).
Cette nouvelle combinaison des 11 premiers bits est souvent appelée COB-ID (Communication object id).
Un ID sur 7 bits permet de définir 127 IDs.
CANopen est plus largement utilisé dans les milieux industriels (bus CAN industriel) où il est très apprécié. Ces dernières années, protocole CANopen à d'ailleurs adapté pour d'autres média industriels.
CANOpen est donc similaire aux paquets CAN mais avec une structure autour des 11 bits d'ID.
Par exemple, les messages heartbeat sont envoyés avec un code fonction 0x700 + Node ID.
CANopen prévoit également standardisation applicative (spécification CiA DS 301) qui met en oeuvre des dictionnaires d'objet (Object Dictionnary) qui est un tableau stockant des configurations et traite des données. Chaque noeud du réseau implémente un serveur autorisant les lectures/écritures dans le dictionnaire d'objet (le "Service Data Objet").
Il s'agit d'un protocole applicatif forcement plus complexe. Il existe par ailleurs une implémentation Python appelée CANopen for Python (voir cet article).
Ressource
Dans le précédent articles "Canbus: à la découverte du bus CAN et du shield CanDIY" nous abordions les principes de base du bus CAN et le format du paquet CAN standard.
Dans cet article, nous allons survoler le paquet CAN étendu et quelques protocoles CAN plus populaires que d'autres.
Bonne lecture,
Dominique
Le paquet CAN standard
Tout commence avec le paquet standard du bus CAN, paquet que nous avons décrit dans le précédent article.
 |
| CAN standard Packet - source: The Car hacker's Handbook on publicism.info |
Avec un ID en 11 bits, il est possible de coder 2047 IDs différents. L'ID sert à identifier l'émetteur d'information.
Ceci étant, si un intervenant (un calculateur) à besoin d'envoyer plus que 8 octets de données sur le bus CAN alors il devra utiliser plusieurs IDs pour communiquer cette informations.
Le paquet CAN étendu
Le paquet standard ne supporte que 2047 IDs... s'il y a de nombreuses informations à transporter alors nous risquons de tomber à court
Les paquets CAN étendu (extended CAN paquet) est un deuxième format supporté en standard par les bus CAN (à partir de la révision 2.0B).
Les paquets étendus sont identifié par le bit IDE qui est mis à 1 alors que ce dernier bit est 0 pour un paquet standard.
Avec le bit IDE à 1, le format de paquet étendu rajoute 18 bits au 11 premiers bits d'identification. Au total, cela fait une identification à 29 bits ( soit 563 870 911 IDs différents), de quoi transmettre un sacré paquet d'information sur le bus CAN.
 | |
| Source: wiki.csie.ncku.edu.tw |
Ceci étant, ce n'est pas parce que le paquet CAN est définit avec un format standard qu'il n'y a pas d'implémentation de protocole diverses et variées entrant dans le trames "Can Standard Packet" ou "Can Extented Packet". C'est surtout le monde automobile que l'on trouve des variantes... avec les protocoles les plus populaires étant ISO-TP et CANopen.
Protocole ISO-TP
Le protocole ISO-TP, aussi connu sous la norme ISO 15765-2, est un protocole standard pour envoyer des packets de données supérieurs à 8 octets.
ISO-TP permet d'envoyer jusqu'à 4095 octets en chaînant des paquets ensembles.
Ce protocole est utilisé lorsqu'il est nécessaire de transmettre une grande quantité d'information sur le bus CAN. Il est entre-autre utilisé pour les systèmes de diagnostique automobile (Unified Diagnostic Service).
ISO-TP permet, par exemple, de créer un tunnel IP over CAN (voir utilitaire isotptun sous Linux).
Pour pouvoir encapsuler ISO-TP dans CAN, un des huit octets est réservé pour étendre l'adressage, laissant ainsi 7 octets de donnée dans le packet CAN.
L'inconvénient du protocole ISO-TP est qu'il est facile d'inonder le bus CAN s'il y a beaucoup de données à faire transiter sur le bus. Il ne faut pas oublier que les paquets sont broadcastés.
 |
| Echanges CAN autour des ISO-TP - source : the car whisperers |
Dans le protocole CANopen, les 11 bits d'identification (Arbitration ID) du paquet CAN sont répartis en 4 bits de code fonction + 7 bits de ID (Node ID).
Cette nouvelle combinaison des 11 premiers bits est souvent appelée COB-ID (Communication object id).
Un ID sur 7 bits permet de définir 127 IDs.
 |
| Trame CANOpen (encapsulé dans une trame CAN) - source: ni.com |
CANOpen est donc similaire aux paquets CAN mais avec une structure autour des 11 bits d'ID.
Par exemple, les messages heartbeat sont envoyés avec un code fonction 0x700 + Node ID.
CANopen prévoit également standardisation applicative (spécification CiA DS 301) qui met en oeuvre des dictionnaires d'objet (Object Dictionnary) qui est un tableau stockant des configurations et traite des données. Chaque noeud du réseau implémente un serveur autorisant les lectures/écritures dans le dictionnaire d'objet (le "Service Data Objet").
Il s'agit d'un protocole applicatif forcement plus complexe. Il existe par ailleurs une implémentation Python appelée CANopen for Python (voir cet article).
Ressource
- Can bus sur Wikipedia (Wikipedia, anglais)
- ISO-TP (Wikipedia, anglais)
- CANopen (Wikipedia, anglais)
- CANOpen Applicatif - spec CiA DS 301
.png)
Écrire un commentaire