Tutoriel
Division - Name - Date - Language 2
Protocole CANopen Introduction
La couche application CANopen (EN 50325-4), alliée au profil de
communication CiA 301, donne un accès direct aux paramètres d ’un
équipement, et donne la possibilité de procéder à l’émission de données
process en temps critique
Des services de gestion du réseau CANopen simplifient par ailleurs la
conception de projet, l’intégration système, et les diagnostics
Dans chaque application de contrôle décentralisé, différents services et
protocoles de communication son requis
CANopen définit tous ces services et protocoles, de même que
l ’ensemble des objets de communication nécessaires
Division - Name - Date - Language 3
Protocole CANopen Introduction
Le Dictionnaire d’Objet décrit la fonctionnalité complète d’un équipement
par le biais d’objets de communication, et établit la liaison entre
l’interface de communication et le programme d’application
L’ensemble des objets de communication (données d’application et
paramètres de configuration) est décrit de façon standardisée dans son
Dictionnaire d’Objets
Ces objets sont accessible par un index sur 16 bits, et, dans le cas de
tableaux et d ’enregistrements, on dispose d ’un sous-index de 8 bits
Division - Name - Date - Language 4
Protocole CANopen Introduction
Les pages suivantes aborde plus en détail le protocole, les services, et
objets de communication CANopen
Modèle d’Equipement (Device) et Dictionnaire d ’Objets
Process Data Objects (PDO)
Service Data Objects (SDO)
Objets Network Management (NMT)
Special Function Objects (SFO : Sync, Emcy, Time)
Contrôle d ’Erreur : protocole Heartbeat
Bit timing
Division - Name - Date - Language 5
Protocole CANopen Modèle de Device
Relation entre le modèle OSI , normes CAN et profils CANopen
Division - Name - Date - Language 6
Protocole CANopen Modèle de Device
Tout équipement CANopen peut être vu comme un équipement
générique
Cet équipement générique est raccordé au réseau CAN à l ’une de
ses extrémités, en même temps qu’il est raccordé à des données
d’entrée/sorte particulières à l’autre de ses extrémités.
L’application est une connaissance clé du constructeur
d ’équipement
L’interface entre l’application et CAN est réalisée par un Dictionnaire
d ’Objet (object dictionary)
Ce "Dictionnaire d ’Objet" est unique pour n’importe quel équipement
CANope, et il détaille l ’ensemble des accès offerts, tels que
ménagés par l’implémentation de l’application, en termes de
données, autant qu ’en terme de configuration.
Division - Name - Date - Language 7
Protocole CANopen Modèle de Device
Pour offrir effectivement un accès à son Dictionnaire d‘Objet, chaque
équipement CANopen se doit d ’implémenter une pile de protocoles
CANopen
Cette pile de protocoles CANopen est un ensemble logiciel,
normalement implémenté sur le même contrôleur que celui qui est
utilisé par le logiciel de l ’application
La pile de protocoles CANopen est capable d ’assurer différentes
fonctions, pour des finalités différentes
Division - Name - Date - Language 8
Protocole CANopen Modèle de Device
Process Data Object (PDO)
utilisation pour transmettre des données d ’application
ces données d ’application sont transmises en mode diffusion (broadcast) sans surcharge (overhead) de protocole
Service Data Object (SDO)
utilisation pour donner accès à l ’ensemble des paramètres de l ’équipement
on fait appel aux SDOs pour des échanges directs d ’équipement à équipement
Error Control (Contrôle d ’Erreur)
utilisation pour valider le fait que tout équipement fonctionne correctement, en termes de communication CAnopen
Network Management (Gestion Réseau)
utilisation pour le contrôle du réseau, en termes d ’échanges CANopen; et indirectement en termes de comportement du système
Division - Name - Date - Language 9
Protocole CANopen Modèle de Device - Dictionnaire d’Objets
Le Dictionnaire d’Objets détaille l’ensemble des
accès offerts sur le programme d’application de
l’équipement, tant en termes de données
d ’application, qu’en terme de paramètres de
configuration
Ce Dictionnaire d’Objets donne accès à tous les types de données utilisés par
l’équipement, aux paramètres de communication (pour configurer l ’équipement en
termes de communication), ainsi qu ’aux données de l’application et aux paramètres de
configuration
Division - Name - Date - Language 10
Protocole CANopen Feuille de données électronique
L'EDS est un fichier ASCII normalisé contenant des informations sur la
fonctionnalité communication d'un équipement de réseau, et le détail de
son dictionnaire d'objets (comme défini dans DS-301)
L'EDS définit également les objets particuliers à ce type d ’équipement,
et/ou spécifiques au fabricant (selon DS-401 et DSP-402)
A l'aide de l'EDS, vous pouvez normaliser des outils pour :
configurer des équipements CANopen
définir des réseaux pour équipements CANopen
gérer des informations de projet sur différentes plates-formes
Division - Name - Date - Language 11
Protocole CANopen Process Data Object (PDO)
PDO : de l'anglais "Process Data Object ", Objet de Données Process
Sur les réseaux basés sur technologie CAN, les PDOs sont émis :
en tant que messages de diffusion non confirmés
ou envoyés d'un appareil producteur à un appareil consommateur
L'objet PDO émetteur (TxPDO) provenant de l'appareil Producteur
dispose d'un identificateur spécifique correspondant à l'objet PDO
récepteur (RxPDO) des équipements consommateur.
Division - Name - Date - Language 12
Protocole CANopen Process Data Object (PDO) - Emission
Les PDOs (Process Data Objects) sont mappés sur une trame CAN
unique, et utilisent à concurrence des 8 octets du champ de données de
cette trame CAN pour émettre les objets application
Tout PDO dispose d’un identificateur unique, et ne peut être transmis
que par un seul et même nœud
Un PDO peut à l ’encontre être réceptionné par plus d ’un seul nœud
(communications producteur/consommateur)
Division - Name - Date - Language 13
Protocole CANopen Process Data Object (PDO) - Emission des PDOs
Les envois de PDO peuvent être déclenchés :
par un événement interne,
par un temporisateur interne,
par des requêtes distantes (remote requests)
ou encore suite à la réception d ’un message
de synchro (Sync)
Division - Name - Date - Language 14
Protocole CANopen Process Data Object (PDO) - Emission des PDOs
Emission de PDO déclenchée par un événement
interne ou par un temporisateur interne
En émission de PDO déclenchée par un événement interne, c ’est un événement (spécifié
dans le device profile) qui déclenche les émission des messages
En émission de PDO déclenchée par un temporisateur interne, c ’est un temps écoulé qui
actionne les nœuds émetteurs périodiques
Division - Name - Date - Language 15
Protocole CANopen Process Data Object (PDO) - Emission des PDOs
Emission de PDO déclenchée par une Requête
Distante
En émission de PDO Remotely requested, càd déclenchée par une Requête Distante, un
autre équipement peut initialiser l’émission d’un PDO asynchrone, en envoyant une requête
d’émission distante (Remote Transmission Request)
Division - Name - Date - Language 16
Protocole CANopen Process Data Object (PDO) - Emission des PDOs
Emission de PDO synchrone : pour initialiser l’échantillonnage simultané des valeurs des entrées de l’ensembles des nœuds, il est nécessaire que prenne place l’émission périodique d’un message Sync
L ’émission synchrone des PDOs intervient selon le cas selon un mode de transmission cyclique ou acyclique :
une émission synchrone cyclique de PDOs signifie que le nœud attend l’arrivée d’un message Sync; après quoi il envoie la valeur qu’il a mesurée. Le numéro identifiant le type d ’émission de ce PDO (compris entre 1 et 240) indique le taux de Sync en fonction duquel il va se déterminer (i.e. le nombre de messages Sync qu’il devra voir passer avant que n ’intervienne une nouvelle émission de ses valeurs)
une émission synchrone acyclique de PDOs signifie que cette émission est déclenchée par un événement défini comme spécifique à l ’application. Le Nœud envoie ses valeurs sur le prochain message Sync; celles-ci ne seront pas émises tant que ne surviendra pas un nouvel événement événement spécifique à l ’application
Division - Name - Date - Language 17
Protocole CANopen Process Data Object (PDO) - Mapping des PDOs
Pour chacun des PDOs, sont
décrits dans le dictionnaire d’objet
tant le mapping adopté par défaut
pour les objets de l’application, que
le mode d’émission admis pour ces
PDOs
Les identificateurs des PDOs
doivent disposer d ’un haut niveau
de priorité, afin de garantir un
temps de réponse court
L ’émission d ’un PDO ne donne
pas lieu à confirmation
Division - Name - Date - Language 18
Protocole CANopen Process Data Object (PDO) - Mapping des PDOs
Le mapping des PDOs définit quels sont les objets application qui sont émis au sein d ’un PDO
Ce mapping décrit également la séquence et la longueur des objets d ’application mappés
Un équipement qui admet un mapping variable de ses PDOs doit prendre en compte ce mapping durant l ’état pré-opérationnel
Si es supporté un mapping dynamique pendant l ’état opérationnel, c’est le Client SDO qui est alors responsable de la cohérence des données
Division - Name - Date - Language 19
Protocole CANopen Service Data Object (SDO)
Un SDO (Service Data Object) procède à la lecture ou à la
lecture d ’entités du Dictionnaire d ’Objets
Le Protocole de Transport des SDOs autorise l’émission
d ’objets d ’une taille quelconque
Le premier octet du premier segment contient les informations de contrôle de flux qui sont
nécessaires, y compris un "toggle bit" destiné à permettre de venir à bout du problème bien
connu de doublon des trames CAN réceptionnées
Les 3 octets suivants de ce premier segment donnent les valeurs d ’index et de sous-index
des l ’entrée du Dictionnaire d ’Objet qu’il convient de lire ou d’écrire
Les 4 derniers octets de ce premier segment sont disponibles pour des données utilisateur
Division - Name - Date - Language 20
Protocole CANopen Service Data Object (SDO)
Le deuxième segment, ainsi que les segments suivants (faisant appel exactement au même
identificateur CAN) contiennent l’octet de contrôle et jusqu’à 7 octets de données utilisateur
Le récepteur va confirmer chacun des segments, ou un bloc de segments, de manière à ce
que puisse se mettre en place une communication en peer-to-peer (client/server)
Division - Name - Date - Language 21
Protocole CANopen Network Management (NMT)
Les objets de Gestion de Réseau (Network
Management) comprennent notamment :
le message de Boot-up
le protocole Heartbeat
le message NMT
Message de Boot-up et protocole Heartbeat sont implémentés en tant que trames CAN
simples, ne comportant qu ’un seul octet de données
Division - Name - Date - Language 22
Protocole CANopen Network Management (NMT) - Message NMT
Le message NMT est mappé sur une trame CAN unique, et admet une longueur de 2 octets de données
Son identificateur is 0
Le premier octet porte le spécificateur de la commande
Le deuxième octet porte le Node-ID de l ’équipement devant exécuter le commande (dans le cas d’une valeur de Node-ID spécifiée 0, tous les nœuds doivent exécuter cette commande)
Le message NMT émis par le Maître NMT force l’ensemble des nœuds à se placer dans un autre état NMT
Division - Name - Date - Language 23
Protocole CANopen Network Management (NMT) - Message NMT
Après la mise sous tension, chaque équipement CANopen se trouve positionné dans l ’état Initialisation, et transite automatiquement dans l’état Pré-opérationnel
Dans cet état Pré-opérationnel, l’émission de SDOs est autorisée
A partir du moment où le Maître NMT aura placé un, voire plusieurs nœuds dans l’état Opérationnel, ceux-ci se voient alors autorisés à émettre et à recevoir des PDOs
Dans l ’état Arrêt, plus aucune communication n ’est autorisée, à l ’exception d ’objets NMT
L ’automate d ’état CANopen spécifie les états suivants :
Initialisation
Pré-Opérationnel
Opérationnel
Arrêt
Division - Name - Date - Language 24
Protocole CANopen Network Management (NMT) - Message NMT
dans le sous-état de Reset Communication, ce sont les paramètres de la zone de communication du profil qui se voient replacés à la valeur qui est la leur à la mise sous tension
c’est dans le troisième sous-état qu’a lieu l’initialisation; état dans lequel un nœud entre automatiquement lorsqu’il fait sa mise sous tension. Les valeurs de paramètres adoptées à la mise sous tension sont les dernières sauvegardées
L ’état Initialisation est sub-divisé en 3 sous-états, de façon à permettre un reset partiel ou complet d ’un nœud
dans le sous-état de Reset Application, ce sont tant les paramètres logés sur la zone du profil spécifique au constructeur, que ceux logés sur la zone du profil correspondant à un équipement standard, qui se voient replacés à la valeur qui est la leur à la mise sous tension
Division - Name - Date - Language 25
Protocole CANopen Network Management (NMT) - Message de Boot-up
Un équipement envoie un message de Boot-up pour indiquer au Maître NMT qu ’il a atteint l ’état Pré-Operationnel
Ceci survient à chaque fois que l ’équipement fait sa première mise sous tension, mais également suite à une mise hors tension survenue en fonctionnement
Ce message de Boot-up présente le mêm identificateur que l ’objet Heartbeat; le contenu de ses données étant cependant à zéro
Division - Name - Date - Language 26
Protocole CANopen Special Function Object (SFO)
CANopen définit également 3 protocoles spécifiques pour respectivement l’émission d ’une
synchronisation, l’indication d’un état d’urgence (emergency), et l’horodatage (time-stamp).
Division - Name - Date - Language 27
Protocole CANopen Special Function Object (SFO) - Objet de Synchronisation
Il peut exister un certain décalage (jitter) avec l’émission opérée par le Procteur de Sync, du
fait de ce que certains autres objets disposant d ’une priorité supérieure, ou encore du fait
d ’une trame ayant été émise juste avant l ’arrivée du message Sync
Ce message Sync est mappé sur une unique trame CAN, avec un identificateur de 128 par
défaut. Un message Sync ne comporte pas de données
L ’objet Sync est diffusé périodiquement par le
Producteur de Sync (Sync Producer)
L’intervalle de temps écoulé entre les messages
de Sync est défini par la Période du Cycle de
Communication (Communication Cycle Period),
qui peut subir un reset provenant d ’un outil de
configuration, appliqué aux équipements de
l’application durant le processus de boot-up
Division - Name - Date - Language 28
Protocole CANopen Special Function Object (SFO) - Objet Emergency
Un message dît d’Emergency est déclenché par l’occurrence d ’une situation d ’erreur interne
Il est émis par un producteur d’Emergency, sur l ’équipement concerné de l ’application
Ceci les rend adaptés à des interruptions de type ‘alerte sur erreur’ (error alerts)
Division - Name - Date - Language 29
Protocole CANopen Special Function Object (SFO) - Objet Emergency
Zéro ou plusieurs consommateurs d’Emergency peuvent recevoir ces messages
La réaction d’un consommateur d’Emergency est particulière à l ’application
CANopen définit plusieurs Codes d ’Erreur d ’Emergency destinés à être transmis par ces
messages d’Emergency, qui sont des trames CAN individuelles, avec 8 octets de données
Un message Emergency n’est émis qu’une
seule fois par ‘événement d’erreur ’
Aussi longtemps qu’aucune nouvelle erreur
ne survient sur un équipement, aucun
nouveau message d’erreur ne pourra être
émis
Division - Name - Date - Language 30
Protocole CANopen Special Function Object (SFO) - Objet Horodate
Cette émission d ’objet se conforme au modèle producteur/consommateur avec push
La trame CAN associée s ’arroge l’identificateur prédéfini de 256, et comporte un champ de
données de 6 octets de longueur
Par l ’intermédiaire d ’un horodatage
(Time-Stamp), une référence temporelle
commune de trame peut être fournie aux
équipemnts de l ’application
Celle-ci comporte une valeur du type Time-
of-Day
Division - Name - Date - Language 31
Protocole CANopen Contrôle d ’Erreur : protocole Heartbeat
Il indique que le nœud émetteur est encore en train de fonctionner correctement
Outre ce protocole Heartbeat existe un service de contrôle d ’erreur plus ancien, et pour tout
dire quasi obsolète, que l ’on appelle protocole de Node and Life Guarding. Son implantation
n ’est pas conseillée
Le protocole Heartbeat intervient à des fins
de contrôle d ‘ erreur
Il signale la présence d ’un nœud, en même
temps que son état
Un message Heartbeat est un message
périodique d ’un nœud donné, à l ’intention
d ’un ou de plusieurs autres nœuds
Division - Name - Date - Language 32
Protocole CANopen Bit Timing
Les valeurs données dans les tables ci-après constituent un exemple basé sur les hypothèses suivantes :
Fréquence d'Oscillateur : 16 MHz ±0.1% (1000 ppm)
Mode d'Echantillonnage : Echantillonnage Simple SAM = 0
Mode de SynchronisationTransitions de Récessif à Dominant uniquement SYNC = 0
Largeur de "Synchronization jump" 1 * tq SJW = 0
Segment de Phase n° 2 2 * tq TSEG2 = 1
Division - Name - Date - Language 33
Protocole CANopen Bit Timing
Débit
Longueur de Câble Drop sans
terminaison (5)
Longueur de Bus (1)(longueur cumulée)
1 Mbit/s 8 tq 6 tq
25 m (1 µs) (750 ns)800 kbit/s 10 tq 8 tq
50 m (1.25 µs) (1 µs)500 kbit/s 16 tq 14 tq
100 m (2 µs) (1.75 µs)250 kbit/s 16 tq 14 tq
250 m (2) (4 µs) (3,5 µs)125 kbit/s 16 tq 14 tq
500 m (2) (8 µs) (7 µs)50 kbit/s 16 tq 14 tq
1000 m (3) (20 µs) (17.5 µs)20 kbit/s 16 tq 14 tq
2500 m (3) (50 µs) (43.75 µs)10 kbit/s 16 tq 14 tq
5000 m (3) (100 µs) (87.5 µs)275 (1,375) m 6.25 µs
55 (275) m 1.25 µs
137.5 (687.5) m 3.125 µs
11 (55) m 250 ns
22 (110) m 500 ns
2.5 (12.5) m 125 ns
5.5 (27.5) m 125 ns
Durée d'un
quantum (4)
Bit Time
Nominal (4)
Localisation du point
d'échantillonnage (4)
1.5 (7.5) m 125 ns
Division - Name - Date - Language 34
Protocole CANopen Bit Timing
Les estimations de longueur de bus qui précèdent sont arrondies (cas le
plus défavorable) sur la base d ’un temps de propagation de 5 ns/m, et
avec les valeurs suivantes estimées pour le retard total effectif, en entrée
et en sortie d’un équipement
500 - 250 kbit/s 300 ns (dont 2 * 40 ns pour les optocoupleurs)
125 kbit/s 450 ns (dont 2 * 100 ns pour les optocoupleurs)
50 - 10 kbit/s
1,5 tq; Retard Effectif = retard de Récessif à Dominant plus
Dominant à Récessif, divisé par 2.
Division - Name - Date - Language 35
Protocole CANopen Bit Timing
Pour des longueurs de bus supérieures à environ 200 m, l’utilisation
d’opto-coupleurs est conseillée
Si ces opto-coupleurs sont placés entre le Contrôleur CAN et le
transceiver, ceci joue sur la longueur maximale de bus, en fonction du
retard de propagation des opto-coupleurs i.e. -4 mètres par 10 ns de
délai de propagation, selon le type d’opto-coupleur utilisé
Pour des longueurs de bus supérieures à 1 km, il sera nécessaire de
recourir à des équipements de type pont ou répéteur
Les valeurs de "bit timings" donnés dans le tableau qui précède sont
calculées pour une fréquence d ’oscillateur de 16 MHz. Si c ’est un autre
oscillateur qui est utilisé, alors le nombre de "time quanta" peut être
différent. Dans tous les cas, la position du point d ’échantillonnage devra
être aussi proche que possible du point d ’échantillonnage conseillé