CANopen Emergency Nachrichten

CANopen Emergency (EMCY) Nachrichten sind ein optionaler Bestandteil des CANopen Protokolls um Fehler in den Geräten zu signalieren.

CANopen Emergency Protokoll

Producer

Als Producer werden die Geräte bezeichnet, welche in der Lage sind Emergency Nachrichten zu versendet. Damit können Fehler des Gerätes selbst,des CANopen-Stacks und der CAN-Kommunikation signalisiert werden. Die CANopen Spezifikation 301 definiert eine Menge an vordefinierten Fehlercodes und jedes CANopen-Geräte- oder Applikationsprofil kann weitere Fehlercodes definieren. Darüber hinaus ist es auch möglich herstellerspezifische Fehlercodes zu definieren. Zusätzlich können in den Nachrichten bis zu 5 Bytes hersteller-spezifischer Daten übertragen werden.

Consumer

Consumer sind die Geräte, welche die EMCY-Nachrichten andere Geräte empfangen können. Dies sind meist nur CANopen-Master-Geräte oder Diagnose- und Konfigurationstools.

Telegrammaufbau und CAN-IDs

CANopen Emergency Message
Die Länge einer Emergency-Nachricht ist immer 8 Byte. In den ersten beiden Byte wird der jeweilige EMCY Error Code des Fehlers übertragen. Danach folgt der aktuelle Wert des Error Registers (0x1011) und 5 hersteller-spezifische Bytes.

Die CAN-ID ist entsprechend dem Pre-defined Connection Set 0x80 + die Knotennummer des Producers.

Inhibit Time

Das optionale Inhibit Time Objekt (0x1015) definiert eine minimale Zeitspanne zwischen 2 Fehlernachrichten. Der Defaultvalue des Objekts ist 0 (keine Inhibitzeit) und der Wert kann in Vielfachen von 100µs definitiert werden. Mit einer entsprechenden Konfiguration des Objekts kann der Netzwerk-Master oder Systemintegrator verhindern, dass das CANopen-Netzwerk mit EMCY-Telegrammen geflutet wird.

Fehlerhistorie – Objekt 0x1003

Bei jedem EMCY-Producer kann optional das Objekt 0x1003 mit 1 bis 254 Subindizes implementiert werden. Ist das Objekt vorhanden, so dient es als Fehlerhistorie, welche die Fehlercodes alle vom Gerät gesendeten. Dabei wird immer der Error Code und ersten beiden hersteller-spezifischen Bytes in die Fehlerhistorie eingetragen, so dass der jeweils neueste Fehler auf Subindex 1 abgelegt wird.
CANopen Emergency Error History

Vordefinierte Fehlercodes aus CiA 301

CANopen Emergency Errror Codes[/caption]

Verbreitung

Obwohl die Emergency-Funktionalität optional ist, unterstützen die meisten CANopen-Stacks die entsprechende Producer und Consumer Funktionalität. Aufgrund dessen ist die Emergency-Producer-Funktion auch in vielen CANopen-Geräten implementiert. Auf Protokollebene ist die Implementierung der Producer-Funktionalität nicht sonderlich kompiliziert. Aufwändiger ist dagegen, dass die Erkennung der unterschiedlichen möglichen Fehler in der Applikation.

Tipps

  • Implementieren Sie die Emergency-Funktionalität in Ihren CANopen-Geräten.
  • Dokumentieren Sie alle Error Codes, welches das Gerät senden kann. Ohne eine Dokumentation unterstützter Fehlercodes, weiß der Anwender z.B. nicht ob ein Fehler nicht auftrat oder nur nicht signalisiert werden kann.
  • Implentieren Sie das Inhibit Time Objekt.

USDO – Universal Service Data Object

Das Universal Service Data Object

Der USDO Service in CANopen-FD ist die Weiterentwicklung des SDO Service aus CANopen.
Er ist primär für Konfigurations- und Diagnosedaten konzipiert.
Durch die Verwendung von CAN-FD können Telegramme bis zu 64 Byte lang sein.
Dies und die höheren Datenbitraten von bis zu 5 MBit/s ermöglicht eine signifikant schnellere Datenübertragung.
Eine kleine Demonstration über die Geschwindigkeitsvorteile von CANopen-FD über CANopen finden Sie hier.
Für die Übertragung stehen das Expedited, Segmented und Bulk Protokoll zur Verfügung.
Daten können sowohl in Unicast als auch Broadcast gesendet werden.
Für Netzwerkübergreifende Transfers steht ein eigener Remote Service zur Verfügung.

USDO Unicast

USDO ermöglicht, wie SDO bisher auch, die Verbindungen zwischen genau einem Client und genau einem Server.
Darüber hinaus kann der Client auch mehrere Sessions zu dem gleichen Server gleichzeitig hergestellen.
Auch können mehrere Clients zur selben Zeit auf das Objektverzeichnis eines Servers zugreifen
Ein simultaner Zugriff auf das selbe Objekt ist nicht möglich und wird mit „Data transfer not possible“ abgelehnt.
Sollten zu viele gleichzeitige Anfragen einen Server erreichen, kann er diese mit „USDO Server Busy“ ablehnen.

USDO Broadcast

Ein Client kan eine Broadcast Verbindung zu allen verfügbaren Servern herstellen.
Wenn ein Server eine Verbindung ablehnen muss, z.B. wegen zu vielen offenen Verbindungen, informiert er den Clienten darüber mittels eines Aborts.

USDO Remote Service

Der USDO Remote Service implementiert das Senden von Telegrammen in andere, nicht direkt angeschlossene CAN Netzwerke, über einen transparenten CANopen-FD Router.
Hier werden im ersten Segment zusätzliche Protokolldaten mitgesendet, wie z.B. Ursprungs- und Zielnetzwerk, sowie Ursprungs- und Zielknotennummer.

USDO Expedited Protokoll Type

Der Expedited Transfer ist eine bestätigte Übertragung mit einer Nutzdatengröße von maximal 56 Byte.
Hierbei werden Protokolldaten wie z.B. Zieladresse, Session ID ect. zusammen mit den Nutzdaten übertragen.
Frame Example: Unicast Expedited Upload mit 56 Byte Daten:

USDO Expedited Transfer
USDO Expedited Transfer

USDO Segmented Protokoll Type

Der Segmented Transfer ist eine bestätigte Übertragung mit einer maximal definierbaren Datengröße von ca. 4,29 Gigabyte oder undefinierter Größe als Stream.
Selbst wenn ein Expedited Transfer für die Übertragung ausreichen würde, führt der Server diesen Transfer auch durch wenn er angefragt wurde.
Zunächst werden im ersten Segment, Protokolldaten wie z.B. Zieladresse, Datentype und Datengröße mitgeteilt, erst ab dem zweiten Segment beginnt die Übertragung der Applikationsdaten.
Hierbei wird jedes einzelne Segment vom Server bestätigt.
Frame Example: Unicast Segmented Upload mit 64 Byte Daten:

USDO Segmented Transfer
USDO Segmented Transfer

USDO Bulk Protokoll Type

Als Pendant zum Block Transfer bei CANopen, ist der Bulk Transfer in CANopen-FD eine bestätigte Übertragung.
Dieses Protokoll ermöglicht die bestätigte Übertragung von bis zu 4,29 Gigabyte.
Jedoch können auch Daten gestreamt und somit undefinierte Datengrößen übertragen.
Wie auch beim Segmented Transfer beinhaltet das erste Segment lediglich Protokolldaten wie z.B. Zieladresse, Session ID.
Außerdem überträgt der Server auch die kleinste Zeitspanne zwischen zwei Segmenten.
Dieser Wert ist für den Clienten bindend.
Ab dem zweiten Segment überträgt der Client die Applikationsdaten.
Anders als beim Segmentiertem Protokoll wird hier nur der Start und das Ende der Übertragung bestätigt.
Frame Example: Unicast Bulk Download mit 172 Byte Daten:

USDO Bulk Transfer
USDO Bulk Transfer

USDO Stream

Segmentierter als auch Bulk Transfer können genutzt werden um Datenübertragungen mit unbestimmter Länge zu realisieren.
Dazu setzt der Client die Datenlänge auf den Wert 0.
Bis der Client oder Server die Übertragung beenden, wird die Übertragung aufrecht erhalten.

CANopen FD – der Nachfolger von CANopen

CAN FD – die Grundlage von CANopen FD

CANopen FD basiert auf CAN FD, welches eines Weiterentwicklung des seit 1991 in Kraftfahrzeugen verwendeten Bussystems CAN ist.
Unter Beibehaltung der Vorteile von CAN erlaubt CAN FD nun eine höhere Bitrate in der Datenphase mit Werten von bis zu 5 Mbit/s. Zudem sind nun Nutzdaten bis zu einer Länge von maximal 64 Byte möglich. Zur Beibehaltung der Zuverlässigkeit der Datenübertragung wurde die bisherige CRC-Prüfsumme je nach Datenlänge von 15 auf 17 bzw. 21 Bit erhöht. Seit dem Jahre 2015 ist CAN FD zudem in die bestehende ISO-Norm 11898-1 integriert und seit 2017 steht eine größere Anzahl an Mikrocontrollern mit integriertem CAN FD Controllern sowie Standalone CAN FD Controller am Markt zur Verfügung. Zur vereinfachten Migration von CAN zu CAN FD unterstützen alle CAN FD Controller auch das klassische CAN.

Der Weg zu CANopen FD

Um die Vorteile von CAN FD auch außerhalb der Automotive-Welt zu nutzen, haben die die Mitglieder des CAN in Automation e.V. das CANopen Kommunikationsprotokoll zu CANopen FD weiterentwickelt und im Dokument CiA 1301 Version 1.0 spezifiziert. Die Entwicklung begann bereits im Jahr 2012 als im März zur damaligen Internationalen CAN Konferenz Heinz-Jürgen Oertel die ersten Ideen für ein „CANopen auf CAN FD“ vorgestellt hatte. Im Anschluss gründete sich im Rahmen des CiA eine Arbeitsgruppe mit Mitgliedern verschiedener Firmen, um eine Spezifikation für den Nachfolger für CANopen zu erstellen. Diese Arbeiten wurden im Herbst 2017 mit der Freigabe der CiA 1301 Spezifikation abgeschlossen. Dennoch sind auch 2018 noch weitere Aktivitäten zur Umstellung bzw. Anpassung der weiteren Kommunikationsprofile (z.B. 302 und 305) sowie der CANopen-Geräteprofile nötig.

Überblick über CANopen FD

Bei der Weiterentwicklung hat man die grundlegenden Prinzipien von CANopen wie das Objektverzeichnis, eine Parameterliste für alle Prozess- und Konfigurationswerte mit jeweils einem 16-bit Index und einem 8-bit Subindex zur Adressierung, beibehalten. Weiterhin gibt es definierte Dienste zur Übertragung von Prozessdaten, Konfigurationsdaten, Alarm-Notifikationen (Emergency) sowie Dienste zum Netzwerkmanagement und zur Überwachung der Knoten. Die maximale Länge der Prozessdatenobjekte (PDO) beträgt in CANopen FD nun 64 Byte. Damit können Geräte nun längere CAN FD-Telegramme mit mehreren Mess- oder Sollwerten zusammen in einem Telegramm senden. Neben der Erhöhung des Datendurchsatzes erleichtert dies die Synchronisation zusammengehöriger Daten – beispielsweise in Mehrachscontrollern. „CANopen FD – der Nachfolger von CANopen“ weiterlesen

CANopen LSS – Dynamische Knotennummervergabe durch Layer Setting Services

CANopen-Geräte benötigen zur eindeutigen Adressierung für viele CANopen-Dienste eine Knotennummer im Wertebereich von 1 bis 127. Die in CiA-305 definierten Layer Setting Services (LSS) bieten eine Möglichkeit diese Knotennummer dynamisch über CANopen zu vergeben. Dieser Artikel gibt einen Überblick über LSS und stellt die Vorteile von LSS gegenüber anderen Verfahren heraus. „CANopen LSS – Dynamische Knotennummervergabe durch Layer Setting Services“ weiterlesen