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 Dienste im Detail

Nachfolgenden werden die geänderten bzw. neuen Dienste im Detail vorgestellt.

PDO – Process Data Object

Der PDO-Dienst dient weiterhin zum schnellen Übertragung von Prozessdaten. Dabei können die aktuellen Werte mehrere Objekte in einem PDO ohne Protokolloverhead im CAN-FD-Telegramm übertragen werden. Wie zuvor erläutert können nun bis zu 64 Byte in einem PDO übertragen werden. Trotz der längeren PDOs erreicht man durch die höhere Bitgeschwindigkeit im Datenbereich des PDO die gleiche Latenzzeit auf dem Bus. Diese wird bei 8 Byte Daten sogar kürzer, was die Echtzeitfähigkeit des CANopen FD sogar verbessert.
Wie bisher können bis zu 64 Objekte in einem PDO übertragen werden. Dies bedeutet auch, dass es nun nicht mehr möglich ist einzelne Bitobjekte in einem PDO zu übertragen. Dieses so genannte bitweise Mapping war bereits bei CANopen eher selten im Einsatz und wurde bei der Definition von CANopen FD abgeschafft.
Zudem ist das Anfordern eines PDOs per RTR-Telegramm nicht mehr möglich, da bei CAN-FD die RTR-Telegramme nicht mehr erlaubt sind. Deren Verwendung bereits vorher in der CiA Application Node AN802 mehr mehr empfohlen.

USDO – Universal Service Data Object

Anstelle des bisherige SDO-Dienst zum wahlfreien Zugriff auf alle Parameter und Messewerte im Objektverzeichnis haben die Mitglieder der CiA-Arbeitsgruppe den neuen Universal Service Data Object (USDO) Dienst für CANopen FD definiert. Die USDO-Nachrichten nutzen selbstverständlich auch die volle Länge der CAN-Telegramme. Des weiteren flossen nun Mechanismen für Broadcast und zum Routing über mehrere verbundene Netzwerke direkt in die Protokollspezifikation ein. Durch die Möglichkeit eines Broadcast Transfers wird es z.B. möglich bisher zeitaufwendige Firmware Updates paralle auszuführen.
Ein separater Artikel beschreibt den komplexen USDO-Dienst ausführlich.

EMCY – Emergency Object

Die Länge eines Emergenency Object bzw. der Emergency-Nachricht wurde auch entsprechend der Möglichkeiten von CAN-FD erhöht. Somit kann eine Emergency-Nachricht nun mehr Informationen in einem CAN FD-Telegramm mit der Länge von 20 Byte übertragen. Diese Nachricht beinhaltet nun folgende Informationen:

  • Logical device number
  • CiA specification number that specifies the error code
  • Error Register
  • Emergency Error Code
  • 5 bytes of manufacturer specific information
  • Error status & Time stamp

Node Guarding

Den Node Guarding Dienst hat man komplett aus dem Protokoll entfernt, da es RTR-Telegramme bei CAN FD nicht mehr gibt. Zur Überwachung einzelner Knoten soll nur noch der Heartbeatdienst verwendet werden. Dabei senden die einzelnen Geräte zyklisch in einem konfigurierbaren Intervall eine Status-Nachricht mit der CAN-ID 0x700+ und einem Byte Status. Heartbeat Consumer können den regelmäßigen Empfang der Statusnachricht auswerten und damit erkennen, ob ein Gerät noch vorhanden und im richtigen NMT-Zustand ist.

Neue Objekte im Objektverzeichnis

    • 0x1030 – Version information

Diese Obekt ist ein Array von UNSIGNED32-Werten, welche die Versionen aller unterstützter CiA-Spezifikationen detailliert aufführt.

  • 0x1031 – Active error history
  • 0x1032 – Active error list
  • 0x1040 – Port network allocation
  • 0x1041 – Routing table

Die Objekte zwischen 0x1200 und 0x12FF sind nun nicht mehr im Objektverzeichnis vorhanden bzw. reserviert. In CANopen brauchte man diese Objekte zur Konfiguration des SDO-Diensts, jedoch kommt der USDO-Dienst ohne Konfigurationsobjekte aus.

Geänderte Objekte im Objektverzeichnis

    • 0x1000 – Device Type
    • Das Device Type-Objekt ist in CANopen FD ein Array mit mehreren UNSIGNED32-Subindizes. Dabei entspricht jeder Subindizes einem implementierten Geräteprofil.

    CANopen FD Stacks & Tools

    Der CANopen-Spezialist emotas embedded communication bietet einen CANopen FD Protokollstack sowie ein komplettes Portfolio an entsprechenden Tools an.

    emotas CANopen FD Stack Übersicht
    emotas CANopen FD Stack Übersicht

    Der CANinterpreter ist ein CAN FD-Analyzer mit CANopen FD-Interpretation, jedoch findet sich die gesamte Funktionalität dieses Tools auch im CANopen DeviceExplorer wieder. Der CANopen DeviceExplorer ist ein Master-Tool, welches bei der Geräteentwicklung und späteren Diagnose Dienste leistet. Für den Entwurf des Objektverzeichnisses ist der CANopen DeviceDesigner im Lieferumfang des CANopen FD Stacks der Firma emotas embedded communication GmbH enthalten. Als Gegenstelle zum FD Bootloader bietet emotas mit dem CANopen UpdateManager ebenfalls ein Tool für einfache Firmware-Updates für einzelne Geräte oder komplette Netzwerke.