Feldkommunikation CANopen-FD: Das USDO-Protokoll erlaubt Vollvermaschung

Modulare Maschinen brauchen „eingebettete“ Netzwerke. Je eigenständiger die Module agieren, desto mehr direkte Querkommunikation ist sinnvoll. Optimal: Jedes Gerät kann mit jedem anderen Netzteilnehmer kommunizieren.

Anbieter zum Thema

compmall GmbH

MicroControl GmbH & Co. KG

SMC Deutschland GmbH

CAN in Automation (CiA) GmbH

CAN (Controller Area Network) – ursprünglich für dezentrale und verteilte Steuerungen in Personenkraftwagen entwickelt – hat sich in vielen Maschinensteuerungen seit Jahren bewährt. Um eine Interoperabilität der am Markt erhältlichen Steuerungen, Antriebe und Sensoren zu erreichen, wurde die CANopen-Anwendungsschicht samt Geräteprofile entwickelt. Um eine Herstellerunabhängigkeit und Neutralität zu gewährleisten, verwaltet der eingetragene Verein CAN in Automation (CiA) die CANopen-Spezifikation. Der rund 600 Mitglieder zählende internationale Verband hat im letzten Jahr die CANopen-FD-Spezifikation herausgegeben. Auf der SPS IPC Drives und der Embedded World zeigte er ein CANopen-FD-Netzwerk, in dem Protokoll-Implementierungen von verschiedenen Herstellern Daten austauschten.

CANopen-FD basiert auf CAN-FD

CANopen basierte auf dem klassischen CAN-Protokoll, das in fast jedem Mikrocontroller implementiert ist. Es zeichnet sich durch Zuverlässigkeit aus. CAN zählt zu den preisgünstigsten Netzwerken, die außerdem noch robust sind. Wie schon erwähnt, wird CAN seit fast 30 Jahren vor allem in Fahrzeugen eingesetzt. Die Autohersteller haben vor einigen Jahren damit begonnen, zum CAN-FD-Protokoll zu migrieren. CAN-FD-Controller beherrschen zwar auch das klassische CAN-Protokoll, können aber im CAN-FD-Modus die Datenframes teilweise schneller übertragen. Außerdem erlaubt es Nutzdaten mit einer Länge von 64 Byte (bisher nur 8 Byte).

CANopen-FD nutzt die längeren Datenframes beispielsweise in den USDO-Protokollen (Universal SDO). Wer sich mit CANopen beschäftigt, weiß, dass die SDO-Protokolle (Servicedatenobjekt) bestätigt sind. Das heißt, sie entsprechen dem Client-Server-Prinzip, wobei der Client immer die Initiative der Kommunikation hat. Er fordert Daten vom SDO-Server an oder sendet ihm Daten. Da die Datenlänge bisher auf 8 Byte begrenzt war und der SDO-Protokoll-Overhead 4 Byte betrug, musste man schon bei 5-Byte-Daten segmentieren – also zwei SDO-Segmente senden bzw. empfangen. Dies führt in der Protokoll-Software zu einem gewissen Overhead. Aufgrund des kleinen Protokoll-Overheads war auch nur eine Punkt-zu-Punkt-Verbindung zwischen Client und Server möglich. Es gab keine SDO-Broadcast- oder -Multicast-Kommunikation.

Vollvermaschung der Netzwerkteilnehmer

Die in der CANopen-FD-Spezifikation definierten USDO-Protokolle benutzen einen Teil des größeren Protokoll-Headers, um darin die Zieladresse zu kodieren. Im CAN-Identifier befindet sich die Quelladresse. So kann man ohne zusätzliche CAN-Identifier eine Vollvermaschung der Netzwerkteilnehmer erreichen.

Bei ersten Gesprächen mit Maschinenbauern kam die Idee auf, nur per USDO zu kommunizieren. Einerseits hat man auf Kommunikationsebene bereits eine Bestätigung, dass die Nachricht beim Empfänger angekommen ist und andererseits muss man keine PDO-Querkommunikation (Prozessdatenobjekt) konfigurieren. Für handelsübliche speicherprogrammierbare Steuerungen sind für CANopen entsprechende PDO-Funktionsblöcke vorhanden. Das PDO-Protokoll erfordert allerdings eine Konfiguration, wenn der Anwender mit den Default-Einstellungen (Priorität, Sender/Empfänger-Beziehung und Dateninhalt) nicht einverstanden ist. Dies erfolgt in der Regel durch SDO-Dienste, die ebenfalls per Funktionsblock aufgerufen werden.

USDO-Nachrichten werden direkt aus dem Anwendungsprogramm gesendet und beantwortet. Es ist keine Konfiguration erforderlich. Die USDO-Protokolle unterstützen auch eine Segmentierung großer Datenmengen und die den erforderlichen Wiederzusammenbau auf der Empfängerseite. Möchte man große Datenmengen übertragen, beispielsweise für das Herunterladen von Programmen oder das Hochladen von Diagnosedaten, kann man die Bulk-USDO-Protokolle nutzen, bei denen nicht jedes einzelne Segment bestätigt wird.

Industrielle Kommunikation

HMS und Emtas schließen Partnerschaft für CAN-basierte Kommunikation

Gleichberechtigte Kommunikation zwischen eigenständigen Geräten

Kombiniert mit der Broadcast- bzw. Multicast-Funktion kann der Anwender in CANopen-FD-Netzwerken gleichartige Geräte parallel mit einem Software-Update versehen. Eine weitere USDO-Funktion ist das Adressieren von CANopen-FD-Knoten in einem anderen Netzwerksegment, die über ein oder mehrere Gateways miteinander verbunden sein müssen. Diese Funktion gab es zwar auch schon im klassischen CANopen, führte aber ein Schattendasein, da zusätzliche Protokolle benötigt wurden, die selten in Geräten implementiert wurden.

Apropos selten implementiert: Auch im klassischen CANopen konnte ein SDO-Vollvermaschung konfiguriert werden. Allerdings brauchte man dazu viele CAN-Identifier (vier für jede Verbindung). Die meisten CANopen-Geräte verfügen nur über eine SDO-Client-Funktion. Die CANopen-Steuerungen haben die korrespondierenden Server. Damit hat man eigentlich eine Master/Slave-Architektur. Mit dem USDO wird dies nun aufgebrochen. Nun ist auch praktisch eine gleichberechtigte Kommunikation zwischen weitgehend eigenständigen Geräten möglich. Dies ist meines Erachtens vor allem für modulare Maschinen und Anlagen vorteilhaft. Außerdem führt dann ein „single-point-of-failure“ nicht zum sofortigen Ausfall.

Der Preis: Genauere Auslegung der physikalischen Übertragung

Will man nicht nur die funktionalen Vorteile von CANopen-FD, sondern auch höhere Übertagungsgeschwindigkeit in der Datenphase eines CAN-FD-Datenframe nutzen, dann muss man ehrlicherweise auch den Preis nennen. Ohne in die nachrichtentechnischen Tiefen einzusteigen, sei erwähnt, dass bei Datenraten über 1 Mbit/s, sich die Komponenten symmetrisch verhalten müssen. Auch das „Klingeln“ auf den Leitungen muss man unterdrücken, wenn man Daten mit 2 Mbit/s und schneller zuverlässig übertragen möchte.

Das CAN-FD-Protokoll ist in der Arbitrierungsphase mit dem klassischen CAN-Protokoll identisch. Alle Bits müssen innerhalb einer Bitzeit von allen Teilnehmern erkannt werden. Sie sind also synchronisiert. Hier gilt weiterhin die Abhängigkeit der Datenrate von der Länge des Netzwerkes bzw. umgekehrt. Wenn nach der Arbitrierung nur ein Teilnehmer die Sendeerlaubnis hat, kann man schneller werden, da die Teilnehmer nicht mehr synchronisiert sein müssen. Dies ist erst wieder beim Bestätigen des Frames (ACK) erforderlich. Deshalb erlaubt das CAN-FD-Protokoll, dass eine Ende-Erkennung auch zwei Bitzeiten lang sein darf. Dann sind alle Teilnehmer wieder synchronisiert und können mit der „langsameren“ Bitrate fortfahren. Übrigens auch die Fehlerframes werden mit der Arbitrierungsbitrate gesendet.

Fazit und Ausblick

Auch wenn derzeit Industrial-Ethernet die Schlagzeilen beherrscht, gibt es auch bei CAN Weiterentwicklungen, die für industrielle Anwender interessant sind. Wer sich mit niedrigen Preisen und geringem Platzbedarf anfreunden kann und auch nichts gegen eine zuverlässige und robuste Übertragung einzuwenden hat, ist bei CAN-FD gut aufgehoben.

CANopen-FD bietet darüber hinaus mit den weitgehend wieder verwendbaren CANopen-Profilen die Interoperabilität, die gerade Anwendungen mit kleinen und mittleren Stückzahlen unabdingbar sind. Zumal wenn man nicht alle Geräte im Hause entwickeln und fertigen möchte. Um die Chancen auf Interoperabilität weiter zu verbessern, müssen CANopen-FD-Geräte vom CiA auf Konformität getestet werden, bevor sie unter diesem Logo verkauft werden dürfen. Dies war bei CANopen nicht erforderlich. Was sich im Nachhinein nicht nur als vorteilhaft erwies: Einige am Markt erhältlich Geräte, die das CANopen-Logo tragen, enthalten manchmal nur Spuren davon.

CAN-Messmodul

Neues Messmodul ermöglicht Temperaturmessung in Hochvolt-Umgebungen

CANopen-Controller Library

Selbstkonfigurierender CANopen-Controller für PCAN-Interfaces

* Holger Zeltwanger, Managing Director, CAN in Automation (CiA)

(ID:45437532)