imported>Winkekatze: Doppelte Verlinkung entfernt

2026-01-07T08:40:44Z

Doppelte Verlinkung entfernt

Neue Seite

[[Datei:Canopen logo.svg|mini|Logo von CANopen]]
'''CANopen''' ist ein auf [[Controller Area Network|CAN]] basierendes Kommunikationsprotokoll, welches hauptsächlich in der [[Automatisierungstechnik]] und zur Vernetzung innerhalb komplexer Geräte verwendet wird.

Das Hauptverbreitungsgebiet von CANopen ist Europa. Jedoch steigen sowohl in Nordamerika als auch in Asien die Nutzerzahlen. Es wurde vorwiegend von deutschen mittelständischen Unternehmen initiiert und im Rahmen des [[ESPRIT (Forschung)|ESPRIT]]-Projekts ASPIC unter Leitung von [[Robert Bosch GmbH|Bosch]] als Prototyp von 1993 bis 1995 erarbeitet.<ref>{{Internetquelle |url=https://www.can-cia.org/can-knowledge/canopen/canopen/ |titel=CANopen – The standardized embedded network |hrsg=CAN in Automation |sprache=en |abruf=2023-11-09}}</ref> Seit 1995 wird es von der Organisation [[CAN in Automation]] '''(CiA)''' gepflegt und ist als Europäische Norm EN 50325-4 standardisiert.

== Grunddienste von CANopen ==
In CANopen sind mehrere Grunddienste (Dienstprimitive) definiert.
Diese Grunddienste sind:

; Request
: Anforderung eines CANopen-Dienstes durch die Anwendung
; Indication
: Meldung an die Anwendung, dass ein Ergebnis oder eine bestimmte Nachricht vorliegt
; Response
: Antwort der Anwendung auf eine Indication
; Confirmation
: Bestätigung an die Anwendung, dass ein CANopen-Dienst ausgeführt wurde

In CANopen werden neben diesen Client-Server-Diensten auch weitere Kommunikationskonzepte wie das [[Erzeuger-Verbraucher-Problem|Producer-Consumer-Konzept]] genutzt. Darin zeigt sich, dass CANopen kein klassisches Master-Slave-System ist.
Ursprünglich deckt CANopen im [[OSI-Modell]] die Anwendungsschicht (Schicht 7) ab und nutzt CAN als Schicht-2-Transportmedium. Seit 2006 sind jedoch auch vermaschte Netzwerke mit [[Routing]]-Möglichkeiten standardisiert.

== Kommunikationsobjekte ==
Kommunikationsobjekte können folgendermaßen gegliedert werden in
* ''Servicedatenobjekte'' (SDO) zur Parametrierung von Objektverzeichniseinträgen,
* ''[[Prozessdaten]]objekte'' (PDO) zum Transport von Echtzeitdaten,
* ''Netzwerkmanagement-Objekte'' (NMT) zur Steuerung des [[Automat (Informatik)|Zustandsautomaten]] des CANopen-Geräts und zur Überwachung der Knoten,
* weitere Objekte wie Synchronisationsobjekt (SYNC), Zeitstempel und Fehler-Nachrichten (EMCY).

== Objektverzeichnis ==
Alle Kommunikationsobjekte und alle Anwenderobjekte werden im Objektverzeichnis (OV) (engl. Object Dictionary (OD)) zusammengefasst.
Das OV ist im CANopen-Gerätemodell das Bindeglied zwischen der Anwendung und der CANopen-Kommunikationseinheit.
Jeder Eintrag im Objektverzeichnis steht für ein Objekt und wird durch einen 16-Bit-Index gekennzeichnet. Ein Index kann wiederum bis zu 255 Subindizes enthalten.
Dadurch können unabhängig von den „11-Bit-Identifiern“ bis zu 65536 × 254 Elemente unterschieden werden. (Die Subindizes 0 und 255 können nicht frei verwendet werden.)
In Profilen ist die Zuordnung von Kommunikations- und Geräteprofilobjekten zu einem jeweiligen Index genau definiert; somit wird mit dem Objektverzeichnis eine eindeutige Schnittstelle zwischen der Anwendung und der Kommunikation nach außen definiert.
So ist beispielsweise jedem CANopen-Knoten im Netz bekannt, dass auf Index 1017h das Heartbeat-Intervall zu finden ist, und jeder Knoten oder jedes Konfigurationsprogramm kann lesend oder schreibend darauf zugreifen.

{| class="wikitable"
! Indexbereich
! Verwendung
|-
! 0000{{0|–0000}}
| nicht genutzt
|-
! 0001–009F
| Datentypen (Sonderfall)
|-
! 00A0–0FFF
| reserviert
|-
! 1000–1FFF
| Kommunikationsprofil
|-
! 2000–5FFF
| herstellerspezifischer Bereich
|-
! 6000–9FFF
| bis zu 8 standardisierte Geräteprofile
|-
! A000–AFFF
| Prozessabbilder von IEC61131-Geräten
|-
! B000–BFFF
| Prozessabbilder von CANopen-Gateways nach CiA 302-7
|-
! C000–FFFF
| reserviert
|}

Für jedes Kommunikationsobjekt existiert ein eindeutiger COB-ID (Communication Object Identifier) im Netzwerk. Der COB-ID besteht aus 32-Bit-Werten, wobei die ersten beiden Bits jeweils eine objektspezifische Bedeutung haben. In einem 11-Bit-CAN-Netz haben die folgenden 19 Bits (29 bis 11) den Wert 0 und die letzten Bits (10 bis 0) entsprechen dem CAN-Identifier.

Servicedatenobjekte stellen einen Dienst zum Zugriff auf das Objektverzeichnis bereit.
Jedes CANopen-Gerät benötigt mindestens einen SDO-Server, welcher SDO-Anforderungen von anderen Geräten entgegennimmt und bearbeitet.
Per Default-Einstellung nutzen Nachrichten zum SDO-Server eines Geräts die Knotennummer des Empfängers + 1536 (0x600) als COB-ID bzw. als „Identifier“ für die CAN-Nachricht.
Für die Antwort des SDO-Servers wird als „Identifier“ die Knotennummer des Senders + 1408 (0x580) verwendet.
Mit diesen relativ hohen und somit niederpriorisierten IDs werden Einträge im OV übertragen.
Für diesen SDO-Transfer existiert ein Protokoll, welches 4 Byte benötigt, um die Senderichtung, den Index und den Subindex zu kodieren.
Somit bleiben nur noch 4 Byte von den 8 Byte eines CAN-Datenfeldes für den Dateninhalt übrig.
Für Objekte, deren Dateninhalt größer als 4 Byte ist, gibt es noch zwei weitere Protokolle zum fragmentierten SDO-Transfer.

Im Gegensatz zu dem niederpriorisierten und mit Protokolldaten überladenen SDO-Transfer stellen die Prozessdatenobjekte eine schnellere Möglichkeit zum Transport von Prozessdaten zur Verfügung.
Die zum PDO-Transfer genutzten „Identifier“ liegen bei Defaulteinstellungen im COB-ID-Bereich von 385 (0x181) bis 1407 (0x57F) und sind somit höherpriorisiert als die SDO-Nachrichten. Weiterhin enthalten sie nur [[Nutzdaten]], und somit stehen 8 Byte zur Verfügung.
Der Inhalt der Nutzdaten wird über PDO-Mapping-Einträge bestimmt.
Dies sind Objekte im OV, die wie eine Zuordnungstabelle festlegen, welche Daten über ein PDO übertragen werden.
Diese Daten sind wiederum Inhalte anderer Objekte des OV.
In einem PDO können auch die Werte mehrerer Objekte übertragen werden, und die Empfänger des PDOs können entsprechend ihrer PDO-Mapping-Einträge nur Teile der Daten nutzen.
Beim Empfang eines PDOs werden wiederum die Daten entsprechend den Mapping-Einträgen in jeweils andere Objekte des OV, z. B. in ein digitales Ausgangsobjekt, geschrieben.
Die Übertragung von PDOs kann zyklisch, ereignisorientiert, abgefragt oder synchronisiert geschehen.

Netzwerkverwaltungsobjekte dienen der Verwaltung des Netzes. So gibt es u. a. Nachrichten, welche eine Zustandsänderung in einem Gerät veranlassen oder globale Fehlermeldungen verbreiten.

Das Sync-Objekt sendet oder empfängt beispielsweise die hochpriorisierte SYNC-Nachricht, welche der Synchronisation der Knoten im Netz dient und mit dem Zeitstempel-Objekt eine einheitliche Zeit im Netz sicherstellt.
Daneben gibt es im Kommunikationsprofil und insbesondere in den Geräte-Profilen noch eine Vielzahl anderer Objekte.

== Geräteprofile ==
Für eine Reihe von Geräteklassen wurden CANopen-Geräteprofile definiert.
Diese Geräteprofile definieren die Funktionalität und den Aufbau des Objektverzeichnisses für die jeweiligen Geräte.
Durch die Nutzung von CANopen-Geräten, welche einem bestimmten Profil entsprechen, wird eine höhere Unabhängigkeit von den Geräteherstellern erreicht.

Einige der Geräteprofile sind:<ref>{{Internetquelle |url=https://www.can-cia.org/index.php?id=specifications&no_cache=1 |titel=Technical documents |hrsg=CAN in Automation |sprache=en |abruf=2023-11-09}}</ref>
{| class="wikitable"
! Standard
! Geräteklasse
|-
! CiA 401
| Ein-/Ausgabe-Module
|-
! CiA 402
| elektrische Antriebe
|-
! CiA 404
| Sensoren und Regler
|-
! CiA 406
| Lineare und rotierende Geber (Encoder)
|-
! CiA 408
| hydraulische Ventile und Antriebe
|}

== Anwendungsprofile ==
[[Datei:Lift logo.svg|mini|100px|Logo der SIG Lift]]Im Gegensatz zu den Geräteprofilen wird bei den Anwendungsprofilen nicht die Funktionalität einer Gruppe von Geräten (Antriebe, Encoder, Ein-/Ausgänge) beschrieben, sondern die Funktionen einer Anwendung. So gibt es z. B. Anwendungsprofile für [[Aufzugsanlage]]n (CiA 417), Schienenfahrzeuge (CiA 421), Müllfahrzeuge (CiA 422) oder Elektroleichtfahrzeuge wie Elektrofahrräder (CiA 454 [[EnergyBus]]).

Die wichtigsten Anwendungsprofile sind:
{| class="wikitable"
! Standard
! Anwendung
|-
! CiA 410
| Neigungsmesser
|-
! CiA 412
| Medizinische Geräte
|-
! CiA 413
| Gateways zu LKW-Aufbauten
|-
! CiA 415
| Sensoren für Straßenbaumaschinen
|-
! CiA 416
| Türsteuerungen
|-
! CiA 417
| Aufzugssteuerungen
|-
! CiA 418/9
| Batterien und Ladegeräte
|-
! CiA 420
| Extruder-Nachfolgegeräte
|-
! CiA 421
| Schienenfahrzeuge
|-
! CiA 422
| Müllfahrzeuge
|-
! CiA 444
| Krane/Spreader
|-
! CiA 454
| Elektroleichtfahrzeuge<ref>{{Internetquelle |url=http://www.embedded-communication.com/canopen/energybus-the-canopen-based-communication-standard-for-levs-and-e-bikes/ |titel=EnergyBus - CANopen für Elektrofahrräder |werk=embedded communication |datum=2014-11-15 |sprache=de-DE |abruf=2023-11-09}}</ref>
|}

== Electronic Datasheets ==
Für die Nutzung von CANopen-Geräten sind weiterhin elektronische Datenblätter, sogenannte EDS-Dateien, nötig.
Diese Dateien in einem standardisierten Textformat beschreiben sowohl die wichtigsten Parameter der Objekte der Objektverzeichnisse eines Gerätes als auch physikalische Parameter, wie z. B. die unterstützten Baudraten.
Konfigurationstools können EDS-Dateien einlesen und mit ihrer Hilfe mit dem jeweiligen Gerät kommunizieren und es ggf. parametrisieren. Zur Prüfung der syntaktischen Korrektheit eines EDS gibt es das freie Tool CANchkEDS.<ref>{{Internetquelle |url=https://www.vector.com/int/en/know-how/protocols/canopen/ |titel=CANopen - Higher-Layer CAN Protocol |werk= |hrsg=Vector |sprache=en |offline= |archiv-url= |archiv-datum= |archiv-bot= |abruf=2023-11-09}}</ref>

Beispiel: Auszug aus einer EDS-Datei

[FileInfo]
FileName=newProject_line0.eds
FileVersion=1
FileRevision=0
EDSVersion=4.0
Description=xxx
CreationTime=10:15AM
CreationDate=03-06-2005
CreatedBy=me
ModificationTime=10:15AM
ModificationDate=03-06-2005
ModifiedBy=me

[DeviceInfo]
VendorName=xxx
VendorNumber=0x0
ProductName=test
ProductNumber=0x0
RevisionNumber=0x0
OrderCode=
BaudRate_10=0
BaudRate_20=0
BaudRate_50=1
BaudRate_125=1
BaudRate_250=1
BaudRate_500=0
BaudRate_800=0
BaudRate_1000=0
DynamicChannelsSupported=0
GroupMessaging=0
LSS_Supported=0
Granularity=0
SimpleBootUpSlave=1
SimpleBootUpMaster=0
NrOfRXPDO=0
NrOfTXPDO=0

[MandatoryObjects]
SupportedObjects=3
1=0x1000
2=0x1001
3=0x1018

[1000]
ParameterName=Device Type
ObjectType=0x07
DataType=0x0007
AccessType=const
DefaultValue=0x00000000
PDOMapping=0

[1001]
ParameterName=Error Register
ObjectType=0x07
DataType=0x0005
AccessType=ro
DefaultValue=0x00
PDOMapping=0

Seit Anfang 2007 ist ein auf [[XML]]-basierendes Beschreibungsformat XDD standardisiert. Dieses Format basiert auf dem [[International Organization for Standardization|ISO]]-Standard 15745 und erlaubt eine detaillierte Beschreibung der Gerätefunktionalität. Dabei wird die Applikation unabhängig von CANopen beschrieben und die Parameter der Applikation werden den CANopen-Objekten zugeordnet.

Für dieses neue, XML-basierte Format als auch für das davor gültige EDS-Format gibt es den Editor CANeds, der als [[Freeware]] verfügbar ist.<ref>{{Internetquelle |url=https://www.vector.com/int/en/support-downloads/downloads/add-ons-and-freeware/caneds/ |titel=Beschreibung und Download von Vector CANeds |hrsg=Vector Informatik GmbH |sprache=en |abruf=2025-12-17}}</ref>

== Weblinks ==
* [http://www.can-cia.org Website der CiA]
* [http://www.can-cia.org/can-knowledge/canopen/canopen-history/ Geschichte der Entwicklung von CANopen]
* [http://www.CANopen-Lift.org Wiki der CANopen-Lift Community]
* [https://www.microcontrol.net/service/grundlagen/canopen/ Einführung CANopen] mit Application Notes der MicroControl GmbH & Co. KG
* [http://cordis.europa.eu/search/index.cfm?fuseaction=proj.document&PJ_LANG=EN&PJ_RCN=297118&pid=3&q=55A19F7E7057939926C634386F12508E&type=sim Suchergebnis zu dem ESPRIT Project ASPIC]

== Einzelnachweise ==
<references />

{{SORTIERUNG:Canopen}}
[[Kategorie:Netzwerkprotokoll]]
[[Kategorie:Feldbus]]

CANopen - Versionsgeschichte

imported>Winkekatze: Doppelte Verlinkung entfernt