Automatisieren / CAN-Bus
Jürgen Förster, Holger Zeltwanger
Das offene CAN-Protokoll

CANopen ist die europäische, "offene" Lösung des Controller Area Network. Daneben existieren noch die US-amerikanischen, "offenen", CAN-basierenden höheren Protokollschichten DeviceNet und Smart Distributed System (SDS). Was bei der Implementierung von CANopen zu beachten ist, erläutert der folgende Beitrag.

CANopen ist eine standardisierte Anwendung des CAN Application Layer (CAL). Beide Spezifikationen sind Entwicklungen von Mitgliedern der internationalen Anwender- und Herstellervereinigung CAN in Automation (CiA) und stehen lizenzfrei zur Implementierung zur Verfügung. Das CANopen-Kommunikationsprofil ist in dem CiA-Draft-Standard 301 beschrieben und wird durch verschiedene Geräteprofile, zum Beispiel für E/A-Module, ergänzt. Bei der Implementierung müssen alle verbindlichen Funktionen realisiert werden. Falls optionale Funktionen implementiert werden sollen, müssen diese so gehalten sein, wie sie in der CANopen-Spezifikation beschrieben sind. Nur bei den herstellerspezifischen Funktionen kann der Implementierer seine Kreativität frei entfalten. CANopen setzt voraus, daß CAN-Transceiver und CAN-Protokoll-Controller entprechend ISO 11898 in der Hardware des Gerätes vorhanden sind.
CANopen - festgeschriebener minimaler Funktionsumfang
Die CANopen-Spezifikation beschreibt einen minimalen Funktionsumfang, den ein CANopen-Gerät erfüllen muß. Solche "Minimum Capability Devices" sind zwar als Standardprodukt nicht sonderlich sinnvoll, aber um eine "schlanke" Implementierung für spezielle Applikationen zu ermöglichen, sind viele Funktionen als optional eingestuft.
Jedes CANopen-Gerät muß das CANopen-Objektverzeichnis (Tabelle 1) kennen. In diesem Verzeichnis, das denen von Profibus und Interbus-S sehr ähnlich ist, sind alle für dieses Gerät relevanten CANopen-Objekte eingetragen. Lesende und schreibende Zugriffe erfolgen mit einem Service Data Object (SDO). SDOs werden für Änderungen im Objektverzeichnis und für Statusabfragen verwendet. Jedes CANopen-Gerät verfügt über mindestens ein SDO, dem zwei CAN-Identifier zugeordnet sind. SDOs nutzen das "Multiplexed Domain Transfer Protocol" der CAL-Spezifikation. Mit ihm lassen sich Daten beliebiger Länge übertragen, wobei die Daten gegebenenfalls auf mehrere CAN-Nachrichten aufgeteilt (segmentiert) werden. In der ersten CAN-Nachricht des SDO sind vier der acht Byte mit Protokollinformationen belegt. Für Zugriffe auf Objektverzeichniseinträge mit bis zu 4 Byte Länge genügt folglich eine einzige CAN-Nachricht (expedited Transfer). Bei Datenlängen größer 4 Byte erfolgt eine segmentierte Übertragung, bei der alle auf die erste CAN-Nachricht folgenden Segmente des SDO jeweils 7 Byte Nutzdaten enthalten können. Das letzte Segment enthält eine Ende-Kennung. Ein SDO wird bestätigt übertragen, das heißt, der Empfang jedes Segments wird durch eine entsprechende CAN-Nachricht quittiert.
Für die Übertragung von Prozeßdaten steht der Mechanismus des Process Data Object (PDO) zur Verfügung. Jedes Prozeßdaten produzierende oder konsumierende CANopen-Gerät verfügt deshalb über mindestens ein PDO. PDOs verwenden das "Stored Event Protocol" des CAN Application Layer. Dabei stehen dem Anwender alle acht Datenbyte eines CAN-Telegramms zur Übertragung von Anwendungsdaten zur Verfügung. PDOs werden unbestätigt übertragen, da die CAN-Verbindungsschicht die fehlerfreie Übertragung eines CAN-Frames sicherstellt. Außerdem sind bestätigte Dienste in zeitkritischen Applikationen nicht wünschenswert, weil sie die Busbandbreite signifikant reduzieren. PDOs sind also CAN "pur", ohne den geringsten Protokoll-Overhead durch CAL/CANopen. Die Dateninhalte der PDOs sind in den entsprechenden CANopen-Geräteprofilen spezifiziert (siehe Kasten).
In der CANopen-Spezifikation ist ein Basis-Set von Kommunikationsbeziehungen default-mäßig voreingestellt (Pre-Defined Master/Slave Connection Set). Die Zuordnung der CAN-Identifier erfolgt automatisch mit Hilfe der vom Systemintegrator eingestellten Knotennummer und der in der CANopen-Spezifikation definierten Voreinstellung der Objekte (Tabelle 2). PDOs haben eine höhere Priorität als SDOs. Das höchstpriore Objekt ist für das Netzwerk-Management (NMT) vorgesehen, mit ihm wird das CANopen-Netzwerk gestartet oder gestoppt. Die anderen definierten Objekte, zum Beispiel Emergency Message, Sync-Nachricht sowie Zeitstempel-Telegramm, sind optional zu implementieren. Die Verwendung dieser voreingestellten Kommunikationsbeziehungen setzt nicht nur auf der Netzwerk-Management-Seite, sondern auch auf der Seite der Prozeßdaten (PDOs) einen Master voraus, da alle PDOs unterschiedliche CAN-Identifier verwenden, also per Definition keinen Kommunikationspartner haben. Das paßt jedoch gut zu kleinen Applikationen, wo beispielsweise auf einem zentralen PC sowohl das Netzwerk-Management als auch eine Steuerungsapplikation zusammengefaßt sind. Möchte der Anwender hingegen flexiblere Kommunikationsbeziehungen für seine Prozeßdaten definieren, so muß er eins der weiter unten beschriebenen optionalen Verfahren der Identifier-Zuordnung implementieren.
Geräte mit minimalem Funktionsumfang erreichen nach dem Einschalten der Versorgungsspannung automatisch den Zustand "Initialization" und danach den Zustand "Pre-operational". In diesem Zustand kann das Gerät nur über SDOs mit dem für das Netzwerkmanagement zuständigen CANopen-Gerät (NMT-Master) kommunizieren. Erst nachdem der NMT-Master eine entsprechende CAN-Nachricht (NMT Start Remote Node) gesendet hat, geht das Minimum Capability Device (NMT-Slave) in den Zustand "Operational" und die eigentliche Kommunikation, das heißt die Übertragung von PDOs, kann beginnen. Jedes CANopen-Gerät muß alle in Bild 1 gezeigten Zustände sowie die zugehörigen Services zum Erreichen dieser Zustände beherrschen. Im Zustand "Prepared" nimmt das Gerät nicht mehr an der PDO-Kommunikation teil. Dieser Zustand kann für anwendungsspezifische Belange genutzt werden. Das konkrete Verhalten in diesem Zustand wird in den entsprechenden CANopen-Geräteprofilen festgelegt.
Die physikalische Busschnittstelle von CANopen-Geräten entspricht ISO 11898. Darüber hinaus sind mehrere Baudraten und zugehörige Bit-Timing-Einstellungen empfohlen (Tabelle 3). Jedes CANopen-Gerät muß aber eine 20-kBit/s-Übertragung unterstützen. Die Anschlußbelegung sowie die Bezeichnung für verschiedene Steckverbinder sind ebenfalls definiert. Im Prinzip läßt die CANopen-Spezifikation dem Systemintegrator weitgehende Freiheiten bei der Festlegung der mechanischen und elektromechanischen Komponenten, ohne die Interoperabilität zu gefährden.
Vordefinierte Objekte des CANopen
Zu den vordefinierten CANopen-Objekten zählt in erster Linie das Sync-Object, welches zur Synchronisation der Netzwerk-Teilnehmer verwendet werden kann. Vor allem bei Antriebsanwendungen ist diese als "CMS Basic Variable" entsprechend dem CAL-Standard implementierte Nachricht von Bedeutung und sollte deshalb in allen CANopen-Geräten unterstützt werden, die sich mit Antrieben synchronisieren müssen. Das zyklisch gesendete Sync-Telegramm veranlaßt die CANopen-Geräte, die diese Funktion unterstützen, die Istwerte der Eingänge quasi zeitgleich abzuspeichern. Diese werden in dem folgenden Zeitfenster (Bild 2) an alle interessierten Teilnehmer übertragen. Im anschließenden Zeitfenster senden die CANopen-Geräte die Ausgangswerte an die Aktuatoren. Diese Werte werden aber erst beim Empfang der nächsten Sync-Nachricht gültig. In den beiden spezifizierten Zeitfenstern und dem eventuell noch verbleibenden Zeitfenster innerhalb eines Kommunikationszyklus können asynchrone PDOs und SDOs übertragen werden, die in der Priorität niedriger angesiedelt sind.
Das ebenfalls optionale "Time Stamp Object" (CMS Stored Event nach CAL) dient als eine allgemeine Zeitbasis und eignet sich insbesondere zur zeitlichen Abstimmung in Datenerfassungssystemen.
Die dritte vordefinierte Nachricht ist das "Emergency Object". Die Implementierung dieses optionalen Objektes ist für alle Geräte sehr zu empfehlen, die in der Anwendung eine wichtige Funktion haben. Außerdem unterstützen einige CANopen-Geräteprofile dieses Objekt, um fatale Gerätefehler den anderen Teilnehmern mit hoher Priorität mitteilen zu können. Mit der Emergency-Nachricht signalisiert das Gerät einen internen Fehler.
Die optionale Überwachung der Geräte
Das CANopen-Kommunikationsinterface geht grundsätzlich davon aus, daß jedes angeschlossene Gerät korrekt funktioniert und in der Lage ist, mit den anderen Teilnehmern Nachrichten auszutauschen. Es kann jedoch vorkommen, daß ein Gerät nicht mehr einwandfrei arbeitet und in den Zustand "Disconnected" geht. Um dies zu erkennen, sollte der NMT-Master im CANopen-Netzwerk eine Datenbasis verwalten, in der alle NMT-Slaves eingetragen sind, die das sogenannte "Node/Life Guarding" unterstützen. Diese, bei asynchronem Nachrichtenaustausch dringend zu empfehlende Überwachung beginnt mit dem ersten Remote-Transmit-Request, nachdem der Guarding-Identifier vom NMT-Master übergeben wurde.
Bei der zyklischen Knotenüberwachung (Node Guarding) befragt der NMT-Master seine NMT-Slaves regelmäßig nach ihrem Zustand. Die am Überwachungsprozeß teilnehmenden NMT-Slaves überprüfen intern, ob das "Node Guarding" im definierten Zeittakt erfolgt (Life Guarding). Dies ist notwendig, um festzustellen, ob der NMT-Master noch "lebt".
Die in den verschiedenen standardisierten oder herstellerspezifischen CANopen-Geräteprofilen definierten PDOs enthalten in aller Regel mehrere Anwendungsobjekte, beispielsweise einen analogen Eingabewert, acht digitale Eingabewerte und acht digitale Ausgabewerte. Diese Belegung der PDOs mit standardisierten Objekten wird als Default-PDO-Mapping bezeichnet. Sollen diese PDOs vom Systemintegrator änderbar sein, oder soll die Definition eigener, für die Anwendung optimierter PDOs zulässig sein, so muß das Gerät variables PDO-Mapping unterstützen. Für einfache Geräte ist dies nicht erforderlich. Dann sind die PDO-Mapping-Einträge im Objektverzeichnis "read-only".
Die möglichen Arten des "Hochfahrens"
Die "natürliche" Form des Boot-Up in einem CANopen-Netwerk ist sicherlich die des Minimum-Boot-Up. Der aufwendigere CAL-Boot-Up stammt aus einer Zeit, als das mächtige Instrument des Objektverzeichnisses zur Parametrierung noch nicht zur Verfügung stand. In einigen Anwendungen wird ein erweiterter Boot-Up entsprechend der CAL-Spezifikation jedoch gefordert. Dies ist in allen CAL-Systemen ohne CANopen-Profil-Erweiterung der Fall. Weiterhin trifft das auch bei CANopen-Applikationen zu, die die Distributor-Funktion nutzen wollen. Der Distributor (DBT) teilt beim Initialisieren des Netzwerkes dynamisch die CAN-Identifier zu.
Ebenfalls optional ist die Zuordnung von CAN-Identifiern via SDO-Nachrichten. Diese Zuteilung erfolgt im Zustand "Pre-Operational". Der Konfigurations-Master hat dann Zugriff auf die Objektverzeichnisse aller CANopen-Geräte. Diese optionale Funktion ist zum Beispiel bei variablem PDO-Mapping nötig. Auf dem Markt sind inzwischen verschiedene Konfigurations-Tools zum Einstellen von PDO-Mappings und PDO-Identifiern verfügbar.
Das Elektronische Datenblatt
Das in der CANopen-Spezifikation im Anhang beschriebene "Electronic Data Sheet (EDS)" sollte vom Gerätehersteller unterstützt werden, damit CANopen-Konfigurationswerkzeuge ohne unnötigen Aufwand alle Informationen über ein Gerät einlesen können. Ein EDS ist nur ein Template. Wenn alle CANopen-Informationen (d.h. das Objektverzeichnis) in das EDS eingetragen sind, spricht man vom Device Description File (DCF). Das DCF enthält nicht nur die Objekte, sondern auch deren Werte. Es ist also die Inkarnation des EDS. Im DCF sind auch die Werte für Baudraten und Geräte-Identifizierung hinterlegt. Falls ein Hersteller kein EDS zur Verfügung stellt, kann der Systemintegrator auch ein Default-EDS verwenden, welches er allerdings selbst ausfüllen muß. hap

Literatur
[1] CAN Application Layer Spezifikation (CiA DS-201 bis DS-207), Version 1.1. Erlangen, Februar 1996.
[2] CANopen Communication Profile (CiA DS-301), Version 3.0. Erlangen, Oktober 1996.
[3] CANopen Device Profile for I/O Modules (CiA DSP-401), Version 1.4. Erlangen, Dezember 1996.
[4] Proceedings 1st, 2nd, 3rd international CAN Conference. Erlangen, September 1994, Oktober 1995, Oktober 1996.
[5] Etschberger, K.; Zeltwanger, H.: Von der Vielfalt zur Einheit - Kommunikations- und Geräteprofile für CAN. Elektronik 1996, H. 8, S. 100 bis 106.
[6] Zeltwanger, H.: Der "richtige" Einstieg in die CAN-Vernetzung. Elektronik 1997, H. 3, S. 48 bis 51.

Holger Zeltwanger initiierte 1992 die Gründung der internationalen Anwender- und Herstellervereinigung "CAN in Automation (CiA)", deren Geschäfte er seitdem als Vorstandsmitglied führt.

Dipl.-Ing. Jürgen Förster studierte Elektrotechnik mit der Fachrichtung Informationsverarbeitung an der Fachhochschule Bielefeld.

Index (hex) Objekt
0000 nicht belegt
0001-001F Statische Daten-Typen
0020-003F Komplexe Daten-Typen
0040-005F Herstellerspezifische Daten-Typen
0060-007F Geräteprofilspezifische Daten-Typen (statisch)
0080-009F Geräteprofilspezifische Daten-Typen (komplex)
00A0-0FFF Reserviert für anderweitige Nutzung
1000-1FFF Kommunikationsprofile
2000-5FFF Herstellerspezifische Profile
6000-9FFF Standardisierte Geräteprofile
A000-FFFF Reserviert für anderweitige Nutzung

Tabelle 1. Das CANopen-Objektverzeichnis: wichtigster Teil der jeweiligen Geräteprofile
Broadcast-Objekte des "Pre-defined Master/Slave Connection Set"
Objekt Funktionscode (binär) resultierende COB-ID Kommunikations-Parameter an Index CMS-Prioritäten-Gruppe

NMT 0000 0 - 0
SYNC 0001 128 (1005h) 0
TIME STAMP 0010 256 - 1
Peer-to-Peer-Objekte des "Pre-defined Master/Slave Connection Set"
Objekt Funktionscode (binär) resultierende COB-IDs Kommunikations-Parameter an Index CMS-Prioritäten-Gruppe
EMERGENCY 0001 129-255 - 0 , 1
PDO1 (tx) 0011 385-511 1800h 1 , 2
PDO1 (rx) 0100 513-639 1400h 2
PDO2 (tx) 0101 641-767 1801h 2 , 3
PDO2 (rx) 0110 769-895 1401h 3 , 4
SDO (tx) 1011 1409-1535 6
SDO (rx) 1100 1537-1663 6 , 7
Nodeguard 1110 1793-1919 (100Eh) -
Tabelle 2. Die automatische Zuordnung der CAN-Identifier
Bitrate Buslänge Nominelle Bit-Zeit tb Anzahl der Zeiteinheiten pro Bit Länge der Zeiteinheit tq Plazierung des Sample-Punktes
1 MBit/s 25 m 1 æs 8 125 ns 6 tq (750 ns)
800 kBit/s 50m 1,25 æs 10 125 ns 8 tq (1 æs)
500 kBit/s 100 m 2 æs 16 125 ns 14 tq (1,75 æs)
250 kBit/s 250 m 4 æs 16 250 ns 14 tq (3,5 æs)
125 kBit/s 500 m 8 æs 16 500 ns 14 tq (7 æs)
50 kBit/s 1000 m 20 æs 16 1,25 æs 14 tq (17,5 æs)
20 kBit/s 2500 m 50 æs 16 3,125 æs 14 tq (43,75 æs)
10 kBit/s 5000 m 100 æs 16 6,25 æs 14 tq (87,5 æs)

Tabelle 3. Empfohlene Baudraten und Bit-Zeitbetrachtungen der physikalischen Busschnittstelle der CANopen-Geräte

 
CANopen-Geräteprofile
In Ergänzung zum CANopen-Kommunikationsprofil veröffentlicht die Anwender- und Herstellervereinigung CiA standardisierte CANopen-Geräteprofile. Derzeit sind mehrere Geräteprofile in der Spezifikation, und die ersten sind als Draft Standard Proposal bereits publiziert oder werden in Kürze verfügbar sein.
CiA DSP-401 Geräteprofil für E/A-Module Version 1.4 (12/96)
CiA DSP-402 Geräteprofil für Antriebe Version 1.0 (5/97)
CiA WD-404 Geräteprofil für Regler und Meßtechnik nicht veröffentlicht
CiA WD-405 Geräteprofil für IEC 1131 nicht veröffentlicht
CiA DSP-406 Geräteprofil für Encoder Version 1.0 (5/97)
CiA WD-407 Geräteprofil für Nahverkehr nicht veröffentlicht
DS = Draft Standard: veröffentlichte Spezifikation, die in der Regel ein Jahr lang nicht geändert und erweitert wird.
DSP = Draft Standard Proposal: veröffentlichter Spezifikationsentwurf, der noch nicht gänzlich fehlerfrei ist.
WD = Work Draft: CiA-intern zur Diskussion akzeptiertes Arbeitspapier.