CANopen – Grundlagen und Einführung in das CANopen-Protokoll

Was ist CANopen?

Kurzdefinition von CANopen

Typische Einsatzszenarien

CANopen wird überall dort eingesetzt, wo robuste, echtzeitfähige Kommunikation zwischen mehreren Steuergeräten erforderlich ist. Typische Einsatzbereiche sind:

• Maschinen- und Anlagenbau (z. B. Verpackungsmaschinen, Handhabungssysteme)
• Mobile Arbeitsmaschinen und Nutzfahrzeuge
• Robotik und Antriebstechnik
• Medizintechnik, Labortechnik und Diagnosesysteme
• Bahn-, Gebäude- und Energietechnik

Die Kombination aus einfacher Verkabelung, hoher Störsicherheit und standardisierten Geräteprofilen macht CANopen besonders attraktiv für eingebettete Systeme. Entwickler profitieren davon, dass viele grundlegende Funktionen – etwa der Austausch von Prozessdaten, das Konfigurieren von Parametern oder das Erkennen von Fehlern – bereits durch das Protokoll definiert sind.

CAN und CANopen im Vergleich

Der CAN-Bus in Kürze

Der CAN-Bus (Controller Area Network) ist ein serielles Feldbussystem, das ursprünglich für den Einsatz im Fahrzeug entwickelt wurde. Er definiert unter anderem:

• das elektrische Signal (physikalische Schicht),
• die Bitübertragung,
• das Rahmenformat (CAN-Frames),
• die Arbitrierung auf dem Bus und die Fehlerbehandlung.

CAN selbst beschreibt also, wie Bits auf den Bus gelangen und wie mehrere Teilnehmer kollisionsfrei und fehlertolerant kommunizieren. Was die einzelnen Telegramme inhaltlich bedeuten, bleibt dabei offen. Jedes Projekt, jede Applikation müsste ohne zusätzliche Protokollebene selbst festlegen, welche Identifier welche Daten transportieren und wie Parameter zu interpretieren sind.

Wie setzt CANopen auf CAN auf?

Das CANopen Protokoll baut genau auf dieser Basis auf. CANopen verwendet die CAN-Frames als Transportmedium und legt fest:

• welche Telegrammtypen es gibt (z. B. für Prozessdaten, Konfiguration, Fehler),
• wie Geräte adressiert werden,
• wie Parameter strukturiert und konfiguriert werden,
• wie Zustände und Fehler eines Teilnehmers gemeldet werden.

Damit hebt CANopen die Abstraktionsebene: Statt jedes Gerät und jedes Telegramm individuell zu definieren, stehen standardisierte Profile und Kommunikationsmechanismen zur Verfügung. Entwickler müssen sich nicht mehr um jedes Detail des CAN-Frames kümmern, sondern arbeiten auf der Ebene von Objekten, Parametern und Diensten des CANopen Stacks.

CANopen im OSI-Schichtenmodell

Zur Einordnung hilft das OSI-Schichtenmodell:

• Der CAN-Bus deckt hauptsächlich die Schicht 1 (Physical Layer, ISO 11898-2) und Schicht 2 (Data Link Layer, ISO 11898-1) ab.
• CANopen ergänzt darüber die höheren Schichten, insbesondere Schicht 7 (Application Layer, EN 50325-4) und Teile der darüber liegenden Kommunikationslogik.

Vereinfacht gesagt übernimmt CANopen die Rolle der „Sprache“, mit der sich Geräte auf dem CAN-Bus verständigen. Damit wird festgelegt, welche Daten mit welcher Bedeutung übertragen werden, wie sie strukturiert sind und welche Dienste ein CANopen-Knoten unterstützen muss. Für Entwickler ist diese Einordnung wichtig: Hardwarenahe Funktionen (Transceiver, CAN-Controller) bleiben auf der CAN-Ebene, während Applikationslogik und Protokollverhalten im CANopen Stack umgesetzt sind.

Architektur und Kernkonzepte von CANopen

Das CANopen-Netzwerkmodell

Ein CANopen-Netzwerk besteht aus mehreren Teilnehmern (Nodes), die über den CAN-Bus verbunden sind. Jeder Teilnehmer besitzt eine eindeutige Node-ID. Häufig übernimmt ein Gerät im Netzwerk die Rolle eines CANopen-Managers (ursprünglich als Master bezeichnet), – etwa eine zentrale Steuerung, SPS oder ein übergeordnetes Steuergerät.

Typische Aufgaben eines CANopen-Managers sind:

• Initialisieren des Netzwerks und Setzen der Teilnehmer in den gewünschten Betriebszustand,
• Konfiguration von Parametern über SDO-Kommunikation,
• Starten und Stoppen der zyklischen Datenübertragung,
• Überwachung von Teilnehmern über Heartbeat-Mechanismen.

Die übrigen Teilnehmer verhalten sich als Devices (ursprünglich als Slave bezeichnet). Sie stellen ihre Prozessdaten bereit (z. B. Messwerte, Stellsignale) und lassen sich über standardisierte Objekte konfigurieren. CANopen definiert dabei klar, welches Protokollverhalten ein konformes Gerät zeigen muss – unabhängig vom Hersteller.

Objektverzeichnis (Object Dictionary)

Kommunikationsdienste: SDO, PDO, NMT, SYNC, EMCY, Heartbeat

Das CANopen Protokoll stellt verschiedene Kommunikationsdienste zur Verfügung, die unterschiedliche Aufgaben erfüllen:

• SDO (Service Data Object):
  SDOs werden für die Konfiguration und den gezielten Datenaustausch mit dem Objektverzeichnis verwendet. Über SDO kann ein Master z. B. Parameterwerte schreiben oder Statusinformationen lesen. SDO-Kommunikation ist flexibel, aber im Vergleich langsamer und nicht für harte Echtzeit ausgelegt.
• PDO (Process Data Object):
  PDOs dienen dem schnellen, zyklischen Austausch von Prozessdaten. Typischerweise werden Messwerte, Statusbits oder Stellgrößen darin übertragen. Ein PDO kann mehrere Signale bündeln und wird ohne zusätzlichen Protokoll-Overhead gesendet – ideal für echtzeitkritische Anwendungen.
• NMT (Network Management):
  NMT-Kommandos steuern den Zustand eines Teilnehmers (z. B. Start, Stop, Pre-Operational, Reset). Der NMT-Master kann damit das gesamte Netzwerk kontrolliert in Betrieb nehmen oder anhalten.
• SYNC:
  Das SYNC-Objekt ist ein spezielles Telegramm, das als Synchronisationsimpuls für das Netzwerk dient. Knoten können ihre PDO-Übertragung an den Empfang von SYNC-Nachrichten koppeln und so zeitlich deterministisches Verhalten erreichen.
• EMCY (Emergency):
  EMCY-Nachrichten signalisieren Fehlerzustände eines Knotens. Sie werden mit hoher Priorität gesendet, sobald ein definierter Fehler auftritt, und ermöglichen eine schnelle Reaktion der übergeordneten Steuerung.
• Heartbeat:
  Über Heartbeat-Mechanismen teilen Knoten zyklisch mit, dass sie noch aktiv sind und sich im erwarteten Zustand befinden. Der Manager erkennt dadurch ausgefallene oder blockierte Knoten frühzeitig.

Gemeinsam bilden diese Kommunikationsdienste den „Werkzeugkasten“, mit dem CANopen-Knoten konfiguriert, überwacht und im Echtzeitbetrieb betrieben werden.

Zustandsautomat / Gerätezustände

Historie und Standardisierung

Entstehung der CAN in Automation

Um diese Situation zu verbessern, wurde die Nutzer- und Herstellerorganisation CAN in Automation (CiA) gegründet. Ziel der CiA war es, ein offenes, herstellerübergreifendes Protokoll auf Basis von CAN zu spezifizieren. Aus diesem Umfeld heraus entwickelte sich CANopen als standardisiertes Applikationsprotokoll mit klar definierten Geräteprofilen.

Schon früh entstanden erste Spezifikationen und Implementierungen in verschiedensten Branchen, insbesondere im Maschinenbau und in mobilen Arbeitsmaschinen. Mit zunehmender Verbreitung wuchs der Bedarf nach stabilen, normierten Dokumenten – die Grundlage für die spätere Standardisierung.

Wichtige CANopen Standards

Im Laufe der Zeit wurden zahlreiche Dokumente rund um CANopen geschaffen. Die wichtigsten Grundlagen sind:

• CiA 301 – CANopen Application Layer and Communication Profile
  Dieses Dokument beschreibt den grundlegenden Aufbau des CANopen-Protokolls: Kommunikationsobjekte, Objektverzeichnis, Zustandsautomat, Adressierung und das Verhalten eines CANopen-konformen Geräts. CiA 301 ist sozusagen das „Herzstück“ des klassischen CANopen.
• CiA 1301 – CANopen FD
  Mit der Einführung von CAN FD (Flexible Data-Rate) wurde auch CANopen erweitert: CANopen FD nutzt die erweiterten Möglichkeiten von CAN FD, etwa höhere Datenraten und größere Nutzdaten. CiA 1301 definiert, wie das CANopen-Konzept auf CAN FD abgebildet wird und welche neuen Optionen sich dadurch ergeben.

Daneben existiert eine Vielzahl weiterer CiA-Dokumente, etwa für Geräte- und Anwendungsprofile (z. B. CiA 401, CiA 402). Für Entwickler heißt das: Je nach Anwendung sind neben den Basisdokumenten auch spezifische Profilstandards relevant.

Entwicklung und heutige Bedeutung

CANopen hat sich über viele Jahre von einem Protokoll für eher spezialisierte Anwendungen zu einem etablierten Standard in der industriellen Kommunikation entwickelt. Gründe dafür sind:

• die robuste CAN-Bus-​Technologie im Hintergrund,
• ein klar spezifiziertes Kommunikationsverhalten,
• die große Auswahl an verfügbaren Geräten und Stacks.

Auch wenn heute viele weitere Kommunikationssysteme existieren (z. B. Industrial Ethernet-Varianten), bleibt CANopen in zahlreichen Anwendungen eine attraktive Lösung – insbesondere dort, wo:

• robuste, echtzeitfähige Kommunikation auf vergleichsweise einfacher Hardware benötigt wird,
• kostensensitive, eingebettete Systeme eingesetzt werden,
• lange Produktlebenszyklen und hohe Ausfallsicherheit gefragt sind.

Mit CANopen FD wird der Standard zudem an moderne Anforderungen angepasst, ohne das Grundprinzip von CANopen zu verlassen. Für Entwickler bedeutet das: Investitionen in CANopen-Know-how sind langfristig nutzbar, unabhängig davon, ob klassischer CAN oder CAN FD verwendet wird.