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)
Struktur Objektverzeichnis
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
Jeder CANopen-Knoten folgt einem definierten Zustandsautomaten. Typische Zustände sind:
- Initialization: Startphase nach dem Einschalten, Hardware-Initialisierung.
- Pre-Operational: Konfigurationsphase, SDO-Kommunikation ist möglich, PDOs sind typischerweise noch deaktiviert.
- Operational: Normalbetrieb, PDOs werden gesendet und verarbeitet, Echtzeitkommunikation ist aktiv.
- Stopped: Knoten ist angehalten, reagiert nur eingeschränkt auf bestimmte Telegramme.
Übergänge zwischen diesen Zuständen werden durch NMT-Kommandos gesteuert. Für Entwickler ist der Zustandsautomat wichtig, um z. B. zu definieren, ab wann Prozessdaten gültig sind, wann Konfigurationen erlaubt sind oder wie eine Steuerung beim Einschalten eine Anlage schrittweise in Betrieb nimmt.
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.
Typische Anwendungsbereiche und Vorteile
Branchen und Anwendungen
-
Maschinen- und Anlagenbau
Verpackungsmaschinen, Montageanlagen, Handhabungs- und Fördertechnik setzen häufig auf CANopen. Sensoren, Antriebe, I/O-Module und Bediengeräte werden über ein gemeinsames Netz verbunden und von einer zentralen Steuerung verwaltet. -
Mobile Arbeitsmaschinen und Nutzfahrzeuge
Landmaschinen, Kommunalfahrzeuge, Baumaschinen oder Sonderfahrzeuge nutzen CANopen, um Steuergeräte, Motorsteuerungen, Joysticks, Anzeigeeinheiten und Sicherheitssysteme miteinander zu vernetzen. -
Robotik und Antriebstechnik
Servoantriebe, Schrittmotoren und Frequenzumrichter werden oft über das CANopen-Profil für Antriebe (CiA 402) eingebunden. So können Bewegungsabläufe standardisiert angesprochen und Antriebe verschiedener Hersteller in einem System kombiniert werden. -
Medizintechnik und Labortechnik
In medizinischen Geräten, Laborautomaten oder Analysesystemen verbindet CANopen z. B. Pumpen, Sensoren, Aktoren und Bedienoberflächen. Die Anforderungen an Zuverlässigkeit und Diagnosefähigkeit sind hier besonders hoch. -
Bahn-, Gebäude- und Energietechnik
In Schienenfahrzeugen, Aufzügen, Türsystemen, Heizungs- und Lüftungstechnik oder Energieanlagen ermöglicht CANopen eine robuste Kommunikation auch in rauen Umgebungen und über lange Produktlebenszyklen.
Gemeinsam ist all diesen Anwendungen, dass sie verteilte, eingebettete Systeme mit mehreren Steuergeräten, klaren Echtzeitanforderungen und hohem Zuverlässigkeitsanspruch umfassen – ein ideales Einsatzfeld für CANopen.
Technische Vorteile von CANopen
CANopen bringt aus Entwicklersicht eine Reihe von Vorteilen mit sich:
- Standardisierte Geräteprofile
Durch Profile wie CiA 401 (I/O-Module) und CiA 402 (Antriebe) verhalten sich Geräte unterschiedlicher Hersteller in weiten Teilen gleich. Das erleichtert die Integration neuer Komponenten und den Austausch im Feld. - Klare Struktur durch Objektverzeichnis
Alle relevanten Parameter eines Geräts sind über das Objektverzeichnis erreichbar. Statt proprietärer Konfigurationsprotokolle gibt es ein einheitliches Schema für Lesen und Schreiben von Parametern. - Flexibler und effizienter Datenaustausch
Die Kombination aus PDOs für schnelle Prozessdaten und SDOs für die Konfiguration bietet eine gute Balance aus Echtzeitfähigkeit und Flexibilität. Entwickler können gezielt festlegen, welche Signale in welchen PDOs übertragen werden. - Robuste Fehlerbehandlung und Überwachung
Mechanismen wie EMCY (Fehlermeldungen) und Heartbeat sorgen dafür, dass Fehler erkannt und zielgerichtet behandelt werden können. Ausfallende Knoten lassen sich schnell detektieren. - Interoperabilität und Wiederverwendbarkeit
Einmal implementierte CANopen-Funktionalität (z. B. ein Antriebsprofil) kann in vielen Projekten wiederverwendet werden. Das reduziert Entwicklungsaufwand und Testkosten. - Geringe Hardwareanforderungen
CANopen setzt auf dem bewährten CAN-Bus auf. Viele Mikrocontroller bringen bereits integrierte CAN-Controller mit, und die physikalische Schnittstelle ist vergleichsweise kostengünstig.
In Summe macht dies CANopen zu einer attraktiven Option für viele Embedded-Projekte, bei denen robuste Feldbus-Kommunikation gefragt ist.
CANopen Lösungen von MicroControl
CANopen-Protokollstacks
Auf Basis der in diesem Artikel beschriebenen Konzepte bietet MicroControl modulare CANopen / CANopen FD Protokollstacks an, die speziell für den Einsatz in eingebetteten Systemen optimiert wurden. Die Stacks sind auf geringen Speicherbedarf und hohe Performance ausgelegt und lassen sich über die standardisierte Treiberschnittstelle CANpie FD flexibel auf unterschiedliche Zielhardware portieren.
CANopen / CANopen FD Master Protokollstack
Der CANopen Master Protokollstack bildet die Grundlage für komplexe Steuerungen und die Überwachung ganzer CANopen-Netzwerke. Er unterstützt u. a. die Standards CiA 301 / CiA 1301 (FD), CiA 302 und CiA 305 und stellt alle wichtigen Dienste bereit: SDO (Client/Server), PDO, NMT, EMCY, SYNC sowie Layer Setting Services (LSS). Anzahl der PDOs, SDO-Clients und sogar die Anzahl der unterstützten CAN-Kanäle lassen sich zur Laufzeit konfigurieren, um RAM- und Flash-Bedarf optimal an die Zielapplikation anzupassen.
CANopen / CANopen FD Slave Protokollstack
Der CANopen Slave Protokollstack ist für intelligente Sensoren und Aktoren konzipiert und auf besonders niedrige Ressourcenanforderungen optimiert. Er implementiert die volle Funktionalität der CANopen-Standards CiA 301 / CiA 1301 und CiA 305 und eignet sich damit ideal für kompakte Geräte mit begrenztem Speicher und einfachen Controllern.
CANopen Bootloader Protokollstack
Für Firmware-Updates über das CANopen-Netzwerk bietet MicroControl einen CANopen Bootloader Protokollstack an. Er unterstützt einen reduzierten Objektverzeichnisumfang sowie NMT, SDO (inkl. Blocktransfer), EMCY, Heartbeat und LSS und ermöglicht die Verwaltung von bis zu vier Flash-Speicherbereichen für Programm und Daten. Die Aktualisierung erfolgt komfortabel über das CANopen Download Tool, das als PC-Software mitgeliefert wird.
Schulungen, Workshops und Engineering-Support
Ergänzend zu den Protokollstacks bietet MicroControl Schulungen, Workshops und technische Beratung rund um CAN, CANopen und CANopen FD an.
- Grundlagen- und Intensiv-Trainings zu CAN und CANopen – ideal für Entwicklerteams und Studierende, die schnell praxisrelevantes Know-how aufbauen wollen.
- Workshops zur Projektunterstützung, z. B. zur Definition der Netzwerkarchitektur, PDO-Mappings oder zur Integration von Safety-Funktionen.
- Engineering-Support bei der Portierung der Stacks auf neue Zielhardware, bei der Inbetriebnahme von CANopen-Netzwerken oder bei der Analyse von Feldproblemen.
Damit ist MicroControl nicht nur Lieferant von Protokollsoftware, sondern ein Komplettpartner für CANopen-Projekte – von der ersten Konzeptphase über die Implementierung bis hin zur Serienbetreuung.
Downloads
Application Note 1201 (deutsch) – Einführung in CANopen
Beschreibt die grundlegenden Kommunikationsmechanismen und die Verwendung der Identifier
PDF [376 KB]
Application Note 1202 (englisch) – Identifier Usage in CANopen Networks
Verwendung der CAN-Identifier in CANopen Netzwerken
PDF [118 KB]
Application Note 1203 (englisch) – Automatic start of CANopen slave devices
Beschreibt die Einstellung von zyklischen PDO und die Autostart Funktion
PDF [291 KB]
Application Note 1204 (englisch) – Configuration of CANopen devices via LSS
Einstellung der Bitrate und Node-ID über Layer-Setting-Services
PDF [208 KB]
Sie möchten ein Beratungsgespräch?
+49 2241 - 25 65 9 - 0
Schreiben Sie eine Nachricht oder rufen Sie uns an.
