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.

Bild 2. Das USDO-Protokoll ist nicht wie das SDO-Protokoll auf eine Punkt-zu-Punkt-Ver­bindung beschränkt, so dass alle oder auch verschiedene Gruppen adressierbar sind; dies beschleunigt zum Beispiel die Konfiguration gleichartiger Geräten.

© CAN in Automation

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 exklu­siven Gerätes (1 bis 127), die ID einer Gruppe (128 bis 255) oder alle Teilnehmer (0). Dieser lang ge­hegte Wunsch vieler Anwender scheiterte bisher am Protokoll-Header von nur 4 Byte. Weitere funktionale Er­weiterungen sind die Session-Nummer, die Information über den Datentyp des übertragenen Parameters und die Möglichkeiten, mehrere Parameter in einer USDO-Nachricht zu über­tragen.

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 Jahrtausend­wende ä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 lang­samen 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. 
 

Wer Weg in die Cloud

In CiA 309-5 sind sowohl die physikalische als auch die logische Adressierung der Geräte und Netzwerke spezifiziert.

Bei der physikalischen Adressierung handelt es sich um eine Abbildung von CANopen-Diensten im ASCII-Format auf die Restful-API, wie sie in CiA 309-3 spezifiziert ist. Für die logische Adressierung wird eine Betriebsmittelkennzeichnung eingeführt, mit der auf logischer Ebene eine Adressierung von Netzwerken und Geräten erfolgt. Man unterscheidet drei Arten dieses sogenannten Referenzdesignators. Damit lassen sich die einzelnen CANopen-Parameter als ParamRefd, die CAN-open-Geräte als NodeRefd und die CANopen-Netzwerke als NetRefd systemweit eindeutig identifizieren. Diese Identifikation kann sich – wie in IEC 81346 beschrieben – auf Produkt, Funktion und Ort beziehen. Der Systementwickler muss sich also bei der logischen Adressierung nicht mit Netzwerk- und Knotennummern sowie Parameter-Index herumschlagen.

Neben dem direkten Zugriff aus den ‚Wolken‘ können CANopen-Netzwerke über Ethernet-basierte Rückgrat-Netzwerke mit der Cloud verbunden werden, um die in CANopen-Netzwerken gesammelten Daten zu verarbeiten – Stichwort ‚big data processing‘. Gateways zu Profinet sind schon seit einiger Zeit in der gemeinsam mit Profibus International (PI) entwickelten Spezifikation CiA 309-4 beschrieben. Noch in Entwicklung ist ein Gateway zu OPC-UA-Netzwerken. Auch diese Spezifikation steht kurz vor der Veröffentlichung und wird von der OPC Foundation in einem sogenannten Kompendium-Standard herausgegeben.

Die in ‚eingebetteten‘ und ‚tief-eingebetteten‘ CANopen-Netzwerken anfallenden Daten sind damit  direkt oder indirekt auf standardisierte Art und Weise in die ‚Wolken‘ übertragbar. Die Kommunikation funktioniert aber auch in die andere Richtung. Das heißt: Die CANopen-Netzwerke lassen sich aus der Cloud heraus konfigurieren und partiell steuern. Auf diese Weise ist kein physikalischer Netzwerk-Zugriff erforderlich.
Wann alle der genannten neuen Funktionen samt Konformitätstest verfügbar sind, steht noch nicht abschließend fest. Ende September zumindest die erste Version der Spezifikation CiA 1301 herausgegeben, in der die Mehrzahl der oben erwähnten CANopen-FD-Dienste und -Protokolle beschrieben sind. Die ersten CANopen-Profile sollten ein PDO-Mapping für 64-Byte-Nachrichten spezifizieren, damit sie auf der diesjährigen SPS IPC Drives „vom Stapel laufen“ können. Für das weitverbreitete Antriebsprofil CiA 402 gibt es bereits ein PDO-Mapping für 64-Byte-Nachrichten.

Autor: 
Holger Zeltwanger ist geschäftsführendes Vorstandsmitglied des CAN in Automation e.V. (CiA).