Transmission et surveillance CANopen

Introduction

CANopen est un protocole de communication standard ouvert et une spécification de profil d'appareil (EN 50325-4) qui repose sur le protocole CAN (Controller Area Network). 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.

PDO (Process Data Object)

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

Modes de transmission

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

• Inhibit Time : L'utilitaire Inhibit Time est utilisé pour 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).

• Temps d'événement : Le paramètre Temps d'événement permet de définir un délai d'expiration au bout duquel la transmission d'un PDO est forcée, même si aucun changement d'état n'a eu lieu. Le temps d'événement est exprimé en millisecondes.

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

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.

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, notamment lorsqu'ils sont commandés par Evénement.

Node Guarding

Dans ce protocole, le maître NMT (généralement le contrôleur) interroge chaque équipement NMT (coupleur de bus, par exemple) à intervalles réguliers définis par le paramètre Guard Time. L'équipement répond en envoyant son état NMT. Si l'équipement ne reçoit pas d'interrogation après la période définie par 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 1029 est gardé comme option par défaut), la gestion de repli démarre et un événement de protection est généré. Lifetime est défini comme suit : Lifetime = Guard Time x Lifetime Factor. L'objet 100CH comprend le paramètre Guard Time, exprimé en millisecondes. L'objet 100DH contient le paramètre Lifetime Factor. Les paramètres Guard Time et Lifetime peuvent être configurés différemment selon les équipements.

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

Les valeurs typiques du paramètre Guard Time sont comprises entre 200 ms et 2 s.

Afin d'assurer un fonctionnement plus fiable et plus sécurisé, vous devez spécifier un paramètre Lifetime Factor (objet 100DH) égal ou supérieur à 2. Si la valeur 1 est utilisée, en cas de retard dû au traitement de messages de haute priorité ou du traitement interne sur le maître Node Guarding, l'équipement peut passer par inadvertance à l'état configuré dans l'objet 1029H.

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 configuré (en millisecondes) dans l'objet 1017H. Les équipements chargés de surveiller ce message auront un paramètre Consumer Heartbeat Time configuré (en millisecondes) dans l'objet 1016H. Si le message Heartbeat du producteur n'est pas reçu dans le délai configuré pour les équipements consommateurs, ces équipements génèrent 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é.