Tutoriel. Division - Name - Date - Language 2 Protocole CANopen Introduction La couche application CANopen (EN 50325-4), alliée au profil de communication

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



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



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


Protocole CANopen Modèle de Device

Relation entre le modèle OSI , normes CAN et profils CANopen



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.



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



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


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


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


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.


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)


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)



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



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)



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


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


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


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


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)


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


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



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



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


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


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).


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


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)


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


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


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


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



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



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.



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é

Documents

Tutoriel. Division - Name - Date - Language 2 Protocole CANopen Introduction La couche application CANopen (EN 50325-4), alliée au profil de communication