Transmission et surveillance CANopen

Introduction

CANopen est un protocole de communication standard ouvert et une spécification de protocole d'équipement (EN 50325-4) qui repose sur le protocole Controller Area Network (CAN). Le protocole de « couche 7 » a été développé pour les applications réseau intégrées et définit les fonctions de communication et d'équipement pour les systèmes CAN.

CANopen prend en charge les communications cycliques et pilotées par événement, ce qui vous permet de réduire la charge du bus au minimum tout en continuant de bénéficier de brefs temps de réaction.

Process Data Object (PDO)

Les objets PDO fournissent une interface de communication avec les données de traitement, permettant le transfert de ces données en temps réel. L'ensemble de PDO d'un équipement CANopen décrit les échanges implicites entre cet équipement et ses partenaires de communication sur le réseau. L'échange des PDO est autorisé lorsque l'équipement est en mode OPERATIONAL.

Il existe deux types de PDO :

oLes PDO transmis (TPDO) : PDO transmis par l'équipement

oLes PDO reçus (RPDO) : PDO reçus par l'équipement

Modes de transmission

coupleur de bus TM3 CANopen prend en charge trois types de mode de transmission de PDO :

Deux autres options sont associées aux PDO déclenchés par des événements :

oInhibit Time : L'utilitaire Inhibit Time permet de définir un délai minimum avant la transmission d'un nouveau PDO. Cela évite de surcharger le bus lorsqu'un nombre important d'événements se produisent dans un laps de temps court. La valeur de Inhibit Time est exprimée en multiples de 100 μs.

Cette fonctionnalité est disponible pour le transfert type 255 (asynchrone).

Ce tableau fournit des exemples de valeurs :

oTemps d'événement : le temps d'événement sert à définir un délai d'expiration au bout duquel la transmission d'un PDO est forcée, même en cas d'absence de changement de l'état. Le temps d'événement est exprimé en millisecondes.

Cette fonctionnalité est disponible pour le type 255 (asynchrone).

Ce tableau fournit des exemples de valeurs :

Service Data Object (SDO)

Les SDO permettent d'accéder aux données d'un équipement à l'aide de requêtes explicites. Le service SDO est disponible lorsque l'équipement est à l'état OPERATIONAL ou PRE-OPERATIONAL.

Il existe deux types de SDO :

oSDO en lecture (SDO en téléchargement)

oSDO en écriture (SDO en chargement)

Le protocole SDO repose sur un modèle client/serveur. Pour un SDO en téléchargement, le client (généralement le contrôleur) envoie une requête indiquant l'objet à lire. Le serveur (dans le cas présent, le coupleur de bus) renvoie les données contenues dans l'objet. Pour un SDO en chargement, le client (généralement le contrôleur) envoie une requête indiquant l'objet à écrire et la valeur souhaitée. Une fois l'objet mis à jour, le serveur (dans le cas présent, le coupleur de bus) renvoie un message de confirmation.

Si un SDO ne peut pas être traité par le serveur (coupleur de bus), le serveur renvoie un code d'erreur (code d'abandon). Cela s'applique à la fois au SDO en téléchargement et au SDO en chargement. Si le serveur ne répond pas dans une période prédéfinie (délai d'expiration du SDO), le client émet un code d'abandon pour dépassement du délai d'expiration du SDO.

Protocoles de contrôle d'erreur

Les protocoles de contrôle d'erreur servent à détecter les erreurs de communication sur le réseau. Il existe deux protocoles : Node Guarding et heartbeat. Ces deux mécanismes de surveillance sont particulièrement importants dans le système CANopen. Les équipements connectés au bus ne signalent pas régulièrement leur présence en mode de fonctionnement, en particulier lorsqu'ils sont commandés par Événement.

NOTE : Les équipements CANopen ne peuvent pas prendre en charge la surveillance via les deux méthodes (Node Guarding et Heartbeat) simultanément. Si l'équipement reçoit les deux configurations, il utilisera uniquement la méthode de surveillance Heartbeat.

Node Guarding

Dans ce protocole, le maître NMT (généralement le contrôleur) interroge chaque esclave NMT (un coupleur de bus, par exemple) à intervalles réguliers, appelés Guard Time. L'esclave répond en envoyant son état NMT. Si l'esclave ne reçoit pas d'interrogation après une période définie, appelée Lifetime, il passe à l'état configuré dans l'objet 1029H et génère un événement life guarding. Le coupleur de bus passe à l'état configuré dans l'objet 1029H (si l'objet 1029H est l'objet par défaut), la gestion du repli démarre et un événement de protection est généré. L'option Lifetime est définie comme suit : Lifetime = Guard Time x Lifetime Factor. L'objet 100CH comprend le paramètre Guard Time, exprimé en millisecondes. L'objet 100DH comprend le paramètre Lifetime Factor. Les paramètres Guard Time et Lifetime peuvent être configurés différemment pour plusieurs esclaves.

Lorsque l'un des deux paramètres Lifetime Factor ou Guard Time est défini sur 0 (configuration par défaut), l'esclave n'effectue aucune surveillance. Pour l'activer, vous devez entrer une valeur (au moins 2) dans l'objet 100DH et spécifier une durée en millisecondes dans l'objet 100CH.

Les valeurs classiques du paramètre Guard Time se situent entre 200 ms et 2 s.

Afin d'assurer un fonctionnement plus fiable et plus sécurisé, vous devez indiquer un paramètre Lifetime Factor (objet 100DH) d'une valeur minimale de 2. Si vous utilisez une valeur de 1, lorsqu'un retard se produit en raison du traitement de messages prioritaires ou du traitement interne sur le maître Node Guarding, l'esclave peut, par inadvertance, passer à l'état configuré dans l'objet 1029H.

La surveillance est effectuée de la façon suivante :

NOTE : Même si la fonction de surveillance est désactivée (les registres Guard Time et Lifetime Factor sont définis sur 0), l'esclave répond aux requêtes distantes du maître. Pour le message Guarding, la valeur initiale du bit Toggle envoyé dans le premier message Guarding est de 0. Ensuite, le bit Toggle change à chaque message Guarding suivant, ce qui permet de savoir si un message a été perdu.

L'état du réseau de l'équipement est indiqué par les sept bits restants :

Mécanisme Heartbeat

Dans ce protocole, le producteur transmet un message Heartbeat de manière périodique, en fonction du paramètre Producer Heartbeat Time (en millisecondes) configuré dans l'objet 1017H. Les équipements chargés de la surveillance de ce message disposent d'un paramètre Consumer Heartbeat Time (en millisecondes), configuré dans l'objet 1016H. Si le message Heartbeat du producteur ne parvient pas à l'équipement consommateur avant l'expiration du délai configuré, cet équipement génère un événement Heartbeat. Le coupleur de bus passe à l'état CANopen configuré dans l'objet 1029H, la gestion du repli démarre et un événement Heartbeat est généré.

Le message Heartbeat indique l'état de l'équipement sur un octet, composé de :

oLe bit ayant le poids le plus fort est réservé et sa valeur est toujours 0

oLes 7 bits ayant les poids les plus faibles fournissent l'état de l'équipement, en produisant le message Heartbeat

Les valeurs possibles sont les suivantes :