Tutoriel 1

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 2

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 2

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 2

Protocole CANopen Modèle de Device Relation entre le modèle OSI , normes CAN et profils CANopen 2

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

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 2

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 2

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 2

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 2

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

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

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

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 2

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

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 2

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 2

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 2

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 2

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

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 2

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 2

Protocole CANopen Network Management (NMT) - Message NMT L ’automate d ’état CANopen spécifie les états suivants : Initialisation Pré-Opérationnel Opérationnel Arrêt 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 2

Protocole CANopen Network Management (NMT) - Message NMT 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 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 2

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 2

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

Protocole CANopen Special Function Object (SFO) - Objet de Synchronisation 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 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 2

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

Protocole CANopen Special Function Object (SFO) - Objet Emergency 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 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 2

Protocole CANopen Special Function Object (SFO) - Objet Horodate 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 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 2

Protocole CANopen Contrôle d ’Erreur : protocole Heartbeat 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 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 2

Protocole CANopen Bit Timing Les valeurs données dans les tables ci-après constituent un exemple basé sur les hypothèses suivantes : 2

Protocole CANopen Bit Timing 2

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 2

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é 2