CANopen, ein standardisiertes Kommunikationssystem für dezentrale und verteilte embedded Steuerungen, stellt einige grundlegende Dienste für die Kommunikation zur Verfügung. Hierzu zählt beispielsweise die Übertragung von Echtzeit-Nachrichten, welche Prozessdaten enthalten (PDO-Kommunikation). PDOs können von allen interessierten Teilnehmern empfangen werden. Der bestätigte Client/Server-Dienst SDO (Service-Daten-Objekt) findet Verwendung, um schreibend oder lesend auf die im Objektverzeichnis eines CANopen-Gerätes enthaltenen Parameter zuzugreifen. Die CANopen-Anwendungsschicht stellt zudem ein Netzwerkmanagement (NMT) zur Verfügung.

Das Gerät mit der NMT-Masterfunktion steuert die NMT-Zustandsmaschinen der anderen Teilnehmer. CANopen-Geräte mit NMT-Slavefunktion dürfen allerdings beim NMT-Master das Starten und Stoppen anderer Teilnehmer anfordern. Diese Funktion sowie selbst startende CANopen- Geräte sind in der Spezifikationsreihe CiA 302 beschrieben, welche unlängst komplett überarbeitet und in mehrere Teile gegliedert wurde. Außerdem kamen neue Funktionen hinzu, beispielsweise die CANopen-zu-CANopen-Router-Funktion.

Bis dato wurden einige der in CiA 302 beschriebenen Funktionen - etwa die Funktion „Flying-NMT-Master" oder auch die Busleitungsredundanz - nur singulär betrachtet. Die überarbeitete Version berücksichtigt nun darüber hinaus die Kombination dieser Funktionen in einem Gerät. Das Konzept des „fliegenden" NMT-Masters, welches im Teil 2 der Spezifikation detailliert beschrieben ist (Teil 1 enthält lediglich einige grundsätzliche Begriffsdefinitionen), ist in Systemen erforderlich, welche sicherheitskritisch sind oder hochverfügbar sein müssen - so etwa im Umfeld der Schiffsautomation und im Bereich Medizintechnik. Für den Fall, dass der NMT-Master ausfällt, einigen sich die anderen CANopen-Geräte mit „schlafender" NMT-Master-Funktion, wer die Aufgabe übernimmt. Erholt sich der ausgefallene NMT-Master, so fordert er von seinem Stellvertreter die NMT-Master-Funktion zurück.

Extra Parameter für Tiefseebohrer

Für diese Übergabe der NMT-Master-Funktion wurden vier Protokolle spezifiziert, die es ermöglichen, mehrere CANopen-NMT-Master in einem Netzwerk zu betreiben. Der Systementwickler muss den Geräten lediglich unterschiedliche NMT-Prioritäten zuteilen. Der NMT-Master mit der höchsten Priorität erhält beim Aushandeln das Aktivitätsrecht, die anderen schalten ihre NMT-Master-Funktion ab. Teil 3 der Spezifikation CiA 302 beschreibt das Herunterladen von Programmen und den Konfigurationsmanager.

Diese Funktionen kommen vor allem in dezentralen Steuerungssystemen zum Einsatz, in denen ein Gerät - der CANopen-Manager - die anderen Teilnehmer konfiguriert. Im Extremfall konfiguriert der CANopen-Manager bei jedem Systemstart sämtliche CANopen-Geräte, um so eine versehentliche Fehlkonfiguration aus einer vorherigen Sitzung zu vermeiden.

So ist dementsprechend ausgeschlossen, dass die Konfiguration eines ausgetauschten Gerätes nicht korrekt erfolgt. Außerdem lassen sich damit inkompatible Softwareversionen in den Geräten verhindern. Der Software-Download wird mit Hilfe der „normalen" (segmentierten) SDO-Dienste bewerkstelligt. Im CANopen- Objektverzeichnis sind bis zu 254 verschiedene Programme an definierten Adressen speicherbar. Auf korrespondierenden Adressen lassen sich weitere Informationen (Datum, Version) über diese Programme ablegen.

Diese Parameter sind insbesondere auf Wunsch der Hersteller von Überwachungssystemen für Tiefseebohrungen hinzugekommen, für die eine Inkonsistenz der heruntergeladenen Programme inakzeptabel ist - man kann schließlich nicht mit einem Diagnosegerät tauchen gehen.

Die „echte“ verteilte Steuerung

In Teil 4 ist die Verwendung von Netzwerkvariablen definiert. Programmierbare Geräte haben vor der Programmierung keine Prozessdaten, sondern nur Platzhalter (Netzwerkvariablen).