CANopen
CANopen est un protocole traitant de la couche réseau (couche 3 du modèle OSI) à la couche application (couche 7 du modèle OSI), originellement pour les Bus de terrain du type CAN (Controller area network) fonctionnant en temps réel. D'autres bus intègrent depuis peu CANopen, tel EtherCAT ou Powerlink démontrant ainsi l'intérêt de l'industrie pour ce mode de communication. Il est utilisé dans de nombreux domaines : automobile, agricole, industriel (ascenseurs, escaliers roulants, motion control) et médical (rayons X, salles d'opérations). Ce bus de terrain est connu pour être une solution de communication économique et efficace.
CANopen est une reprise de la couche applicative CAL développée par Philips Medical Systems ; il reprend les services et protocoles de gestion de bus et de messages de la couche CAL tout en définissant le contenu des messages et en intégrant la notion de système distribué. Un élément maître du réseau coordonne les éléments esclaves. La vitesse de transmission peut atteindre 1 Mbit/s.
Les Dictionnaires d'objets
Un dictionnaire d'objet définit, pour chacune des entrées/sorties d'un périphérique CANopen (appelé nœud), l'information sur le format de la donnée ainsi que sur le moyen d'y accéder. Chaque entrée du dictionnaire possède un index unique ainsi qu'une liste de sous-index. On accède à un objet grâce au couple [index, sub-index].
Une des principales nouveautés de CANopen est la notion de dictionnaire d'objets (Object Dictionary ou OD) déjà présente dans d'autres bus de terrain comme Profibus. Pour chaque nœud CANopen présent sur le bus il existe un OD généralement sous forme de fichier texte au format EDS (Electronic Data Sheet) permettant de connaître l'ensemble des entrées/sorties d'un nœud. Il est possible de créer à partir d'un fichier au format EDS un autre fichier représentant une configuration donnée d'un nœud pour un bus. Ce fichier, très similaire à l’EDS, est alors appelé DCF (Device Configuration File). En faisant une analogie avec la programmation orientée objet (POO) on peut dire que l’EDS est la classe tandis que le DCF représente une instance de cette classe.
Les OD sont divisés en profiles. Les plus utilisés sont les suivants :
- Communication Profile Area
- Manufacturer Specific Profile Area
- Standardised Device Profile Area
Toutes les entrées de ces profiles sont définies par la CiA (CAN in Automation) excepté pour le Manufacturer Specific Profile Area qui est libre d'utilisation.
Les protocoles de communication
CANopen offre différents moyens pour accéder aux données de l'OD.
Service Data Object (SDO)
Ce service permet l'accès aux paramètres des périphériques (ou nœuds) présents dans le dictionnaire d'objet, la communication est alors du type question/réponse et chaque message est confirmé par une sorte d'acknowledge : Le maître accède à l'objet de l'OD grâce au couple [index,sub-index] et l'esclave répond soit en envoyant les données désirées soit en confirmant le bon déroulement de l'écriture de l'objet. Que ce soit en lecture ou en écriture, le format des données est vérifié et le message contient une confirmation du bon déroulement de la requête.
Process Data Object (PDO)
Il est destiné au transfert de données temps réel, ce protocole permet de mettre dans un même message un ou plusieurs champs de l'OD. On peut donc mettre dans un même message jusqu'à 64 messages de 1 bit. Ce type de message réduit donc fortement l'overhead (le nombre de bits ne transportant pas de l'information utile). L'autre avantage des PDO est que la lecture se fait au travers d'un message court de type synchrone ou asynchrone qui est reçu par l'ensemble des nœuds présents sur le bus. Ce mécanisme permet de lire une information donnée au même instant sur l'ensemble des capteurs/nœuds du bus.
Heart Beat
C'est un protocole pour les contrôles d'erreur. Il s'agit d'un message périodique d'un nœud signalant sa présence et son état au maître du réseau.
La Machine d'état
Quatre états sont possibles pour un nœud :
- initialisation: utilisation du message Boot-up pour communiquer avec l'élément maître du réseau ;
- pré-opérationnel : seuls les messages SDO sont permis ;
- opérationnel : les messages SDO et PDO sont permis ;
- stoppé : seule la communication à l'élément maître est permise.
Structure Générale d'une trame CAN
| Start of frame | Arbitration Field | Control Field | Data Field | CRC Field | ACK Field | End Of Frame |
| 1 bit | 12 ou 32 bit | 6 bit | de 0 Ã 8 octets | 16 bit | 2 bit | 7 bit |
Une trame de données CAN commence par 1 bit dominant le Start of Frame qui permet la re-synchronisation des nœuds, puis, elle est suivie d'un champ d'arbitrage. La suivante, le champ de contrôle contient la longueur du champ de données. Après le champ de données vient le Cyclic Redundancy Check qui est utilisé pour détecter une éventuelle erreur de transmission.
Taille d'un message
Le fait que CAN utilise un protocole de non retour à zéro (Non-Return-Zero ou NRZ) implique l'utilisation de bits de remplissage (stuff bit). Ces bits de remplissage sont rajoutés dans les messages CAN afin qu'il n'y ait jamais plus de 5 bits ayant la même valeur d'affilée.
Les champs pouvant être modifiés par le bit stuffing sont les suivants :
- Arbitration Field
- Control Field
- Data Field
- CRC Field
Il est important de prendre en compte ces bits de remplissage pour pouvoir déterminer combien de nœuds peuvent être utilisés sur un même bus en fonction de la fréquence des échanges de données.
La formule ci-contre représente la dimension d'un message CAN en fonction de la longueur de son champ de données (Data Length Code ou DLC) dans le meilleur et dans le pire cas de l'algorithme de stuffing:
Pour un message au format CAN standard :
Pour un message au format CAN étendu :
Dans la réalité, il est impossible d'atteindre le pire des cas où car le champ de control contient deux bits dominants et le champ DLC ayant comme valeur maximum 8, il ne peut pas contenir que des bits de même valeur.
Il existe une formule empirique donnant une approximation du nombre maximum de stuff bits pour une trame CAN d'un DLC donné. Cette formule est exacte dans plus de 99 % des cas :
COB-ID
Chaque trame CANopen commence par un COB-ID faisant office d'identifiant de cette trame. Au cours de la phase de configuration, chacun des nœuds reçoit le COB-ID de la (ou les) trame(s) dont il est le récepteur ou l'émetteur....