Feldbustechnik

Die Zukunft von CANopen

8. November 2017, 2:30 Uhr | Günter Herkommer

Ähnlich wie die Automobilindustrie benötigt auch die Industrieautomation immer mehr Busbandbreite. Zudem gewinnt in puncto Kommunikation das Thema Cloud mehr und mehr an Bedeutung. Wie trägt das in beiden Branchen seit Langem etablierte CAN-Protokoll dem Rechnung?

Längere Nutzdaten und höhere Datenraten – diese Forderung stellen viele Anhänger von CANopen bereits seit geraumer Zeit. Dem Rechnung tragend, haben CiA-Mitglieder das CAN- open-Protokoll seit Februar 2015 an das leistungsfähigere CAN-FD-Protokoll an- gepasst und gleichzeitig funktionale Erweiterungen für einige CAN-open-Kommunikationsdienste spezifiziert. Das Netzwerk-Management einschließlich der Heartbeat-Funktion blieb dabei ebenso unverändert wie das Time- und das Sync-Protokoll. Während das Time-Protokoll zum Abgleich der lokalen Uhren in den Hardware-Komponenten mit einer Genauigkeit von einer Millisekunde dient, lassen sich mit dem Sync-Protokoll die CANopen-Geräte synchronisieren, was insbesondere in der Antriebstechnik von Nutzen ist.

Die vom CAN-FD-Protokoll zur Verfügung gestellten Nutzdaten (Payload) sind achtmal länger als beim klassischen CAN-Protokoll (maximal 8 Byte). Dies nutzt die FD-Anwendungsschicht für das PDO-Protokoll. Eine PDO-Nachricht kann nun bis zu 64 Byte Prozessdaten übertragen. Dies verbessert die Protokoll-Effizienz signifikant. Um die PDO-Konfiguration bezüglich der Zusammenstellung von Prozessdaten möglichst einfach zu gestalten, wurde auf ein bitweises Mapping verzichtet. Die mi- nimale Größe eines Pro- zessdatums beträgt 1 Byte.

Matchmaker+ Anbieter zum Thema

zu Matchmaker+

Auch das Emcy-Protokoll (für hochpriore Notfall-Informationen) nutzt die längere Payload des FD-Protokolls. Neben dem 8-Byte-Inhalt der klassischen Emcy-Nachricht sind nun Zusatzinformationen verfügbar, die es bisher nicht gab (siehe Bild 1). Es ist jetzt beispielsweise möglich, die Emcy-Nachricht einem logischen Gerät zuzuordnen. Generell erlaubt CANopen, in einem Gerät bis zu acht Profile (logische Geräte) zu unterstützen. Ein typisches Beispiel hierfür ist eine Mehrachsen-Steuerung mit Zusatzfunktion wie zum Beispiel E/A-Funktionen, speziellen Sensoren oder auch Pipetier-Einheiten. Außerdem kann man in der Emcy-Nachricht mitteilen, ob ein permanenter Fehler aufgetreten ist beziehungsweise wann. Dieser ‚Zeitstempel‘ hat eine Auflösung von einer Millisekunde.

In CANopen-FD wird das klassische SDO-Protokoll durch das USDO-Protokoll ersetzt (s. Bild 2). Es hat nicht nur Zusatzfunktionen, sondern nutzt auch ein anderes Adressierungsschema, um Broad- und Multicast-Übertragungen zu ermöglichen. Damit lassen sich nun mehrere gleichartige Geräte simultan konfigurieren. Die genutzten CAN-Identifier ergeben sich aus einem Offset (600 h für den Client plus Node-ID des Clients sowie 580 h für den Server plus die Node-ID des Servers). Damit ist im CAN-Identifier der Absender codiert. Im Protokoll-Header der Nutzdaten ist der Empfänger codiert – sprich die Node-ID eines exklusiven Gerätes (1 bis 127), die ID einer Gruppe (128 bis 255) oder alle Teilnehmer (0). Dieser lang gehegte Wunsch vieler Anwender scheiterte bisher am Protokoll-Header von nur 4 Byte. Weitere funktionale Erweiterungen sind die Session-Nummer, die Information über den Datentyp des übertragenen Parameters und die Möglichkeiten, mehrere Parameter in einer USDO-Nachricht zu übertragen.

Auch wenn in der ersten Version von CANopen-FD noch nicht alle Funktionen implementiert werden, sind diese bereits angedacht und stehen in Kürze zur Verfügung. Ebenso ist der SDO-Fernzugriff auf Geräte in anderen Netzwerk-Segmenten bereits vorbereitet und ersetzt damit das bisher notwendige SDO-Remote-Access-Protokoll (CiA 302-7).

Zwar hatten verschiedene Wissenschaftler schon um die Jahrtausendwende ähnlich Vorschläge wie CAN-FD unterbreitet; allerdings war nicht unbedingt damit zu rechnen, dass die Automobilindustrie das CAN-Protokoll verbessert. Dazu kam es erst in der zweiten Dekade, als einige PKW-Hersteller forderten, CAN zu beschleunigen. Selbstverständlich lassen sich die CAN-FD-Nachrichten aber auch ‚langsam‘ übertragen, sofern nur an den längeren Nachrichten Interesse besteht, um beispielsweise Daten zu verschlüsseln oder den Zugriff zu autorisieren. In diesem Fall wird die Bitrate in der Datenphase nicht beschleunigt.

Möchte man die Geschwindigkeitsvorteile des CAN-FD-Protokolls nutzen, gilt es allerdings bei der Entwicklung der Geräte und des physikalischen Netzwerkes mehr auf die Einhaltung von Design-Empfehlungen zu achten als bisher. Insbesondere ist darauf zu achten, dass die steigenden und fallenden Flanken möglichst symmetrisch sind und dass die Impedanz über die ganze Strecke möglichst identisch ist.

Impedanz-Sprünge führen ebenso wie unabgeschlossene Stichleitungen zu ‚Klingeln‘ auf den Signalleitungen. Im schlimmsten Fall führen solche Effekte zu falschen Bitwerten und werden von den Controllern als Fehler erkannt. Die CANopen-FD-Spezifikation verweist deshalb auf CiA-Dokumente, in denen entsprechende Richtlinien und Design-Empfehlungen beschrieben sind. Zum Beispiel gilt es, die Timequanta (atomare Zeiteinheit in einem Netzwerk) in der Arbitrierungs- und der Datenphase gleich groß zu konfigurieren beziehungsweise sie auch möglichst kurz zu halten, damit der unvermeidbare Quantisierungsfehler bei der Umschaltung von der langsamen in die schnellere Bitrate minimiert wird.

Das Thema Cloud ist heute im Kontext der industriellen Kommunikation nicht mehr wegzudiskutieren. Dem Rechnung tragend standardisiert CiA aktuell den Zugriff aus den ‚Wolken‘ auf CANopen-Netzwerke – und zwar in der Spezifika-tion CiA 309-5, die kurz vor der Veröffentlichung steht. Die hier definierte Restful-Anwendungs-Programmierschnittstelle (API) leitet die aus dem CANopen-Netzwerk kommenden Daten über ein CANopen-IoT-Gateway und das http-Protokoll in die ‚Wolke‘ beziehungsweise ist die Schnittstelle für die der Cloud gesendeten Informationen. Die Daten und Dienste sind JSON-formatiert. Allerdings unterstützt die API keine ereignisorientierten Abläufe. Für diese Aufgaben wird das MQTT-Protocol genutzt.