CANopen in der Gebäudeautomation: Objektverzeichnis, PDO, SDO und CiA 419 HVAC-Profil

CANopen Objektverzeichnis

Jedes CANopen-Gerät verfügt über ein Objektverzeichnis (OD) – eine strukturierte Tabelle aller Parameter und Prozesswerte, die das Gerät unterstützt. Jeder Eintrag wird über einen 16-Bit-Index (0x0000–0xFFFF) und einen 8-Bit-Subindex (0x00–0xFF) adressiert. Der Hersteller stellt das OD in einer Electronic Data Sheet (EDS)-Datei bereit – einer Textdatei im INI-Format, die von Konfigurierungswerkzeugen geladen wird, um zu wissen, welche Objekte das Gerät unterstützt.

PDO — Prozessdatenobjekte

PDOs sind der Echtzeit-Datenaustauschmechanismus in CANopen — schnelle, überheadarme CAN-Frames, die bis zu 8 Byte Prozessdaten ohne zusätzlichen Protokoll-Overhead jenseits des CAN-Frames transportieren. Ein Transmit-PDO (TPDO) sendet Daten von einem Gerät an das Netzwerk; ein Receive-PDO (RPDO) akzeptiert Daten, die von einem Master oder einem anderen Gerät geschrieben wurden.

Das PDO-Mapping definiert, welche Objektverzeichniseinträge in ein PDO gepackt werden. Beispielsweise könnte ein Kältemaschinen-TPDO1 die Vorlauftemperatur (0x6010:01, 16 Bit), Rücklauftemperatur (0x6010:02, 16 Bit), Kompressor-Betriebsstatus (0x6020:01, 8 Bit) und Alarmstatus (0x6030:01, 8 Bit) packen — insgesamt 6 Byte in einem einzelnen CAN-Frame, der alle 1 Sekunde gesendet wird.

Transmission type (object 0x1800:02 for TPDO1):

  Type 0:   Acyclic, synchronous — PDO sent after SYNC only if data changed
  Type 1–240: Cyclic, synchronous — PDO sent every N SYNC messages
              Example: type 10 = send PDO every 10th SYNC telegram
  Type 254: Event-driven, manufacturer-specific — sent on internal event
  Type 255: Event-driven, profile-specific — sent when data changes
            (most common for building automation — avoids fixed polling)

TPDO1 event timer (object 0x1800:05):
  Value in ms — maximum time between PDO transmissions even if no change
  Example: 5000 ms = resend TPDO1 every 5 seconds regardless
  Use 0 to disable the timer (rely on event trigger only)

Inhibit time (object 0x1800:03):
  Minimum time between two TPDO1 transmissions in 100µs steps
  Example: 1000 = 100ms minimum between sends — prevent bus flooding

SDO — Service Data Objects

SDOs werden für Konfiguration und Parameterzugriff verwendet — Lesen oder Schreiben eines beliebigen Objektverzeichniseintrags mittels eines bestätigten Handshakes. Im Gegensatz zu PDOs (Feuer-und-Vergessen) garantieren SDO-Übertragungen die Zustellung und geben den gelesenen Wert oder eine Bestätigung des Schreibvorgangs zurück. Der SDO-Zugriff ist langsam (mehrere CAN-Frames pro Lese-/Schreibvorgang) und wird während der Inbetriebnahme verwendet, nicht für zyklische Prozessdaten.

SDO Read (Initiate Upload) — read object 0x6010:01 (supply water temp)
  COB-ID: 0x600 + node ID  (example: node 3 → 0x603)
  DLC: 8
  Data: 40 10 60 01 00 00 00 00
        |  |     |
        |  |     Sub-index: 0x01
        |  Index low byte: 0x10
        Command specifier: 0x40 (Initiate Upload Request)

SDO Response from device:
  COB-ID: 0x580 + node ID  (example: node 3 → 0x583)
  Data: 4B 10 60 01 E8 03 00 00
        |           |
        |           Value: 0x03E8 = 1000 → ÷10 = 100.0°C? No → check EDS
        Command: 0x4B = 4-byte, expedited (2 meaningful bytes)

SDO Write — set temperature setpoint object 0x6011:01 to 45°C (0x01C2 = 450 × 0.1°C)
  COB-ID: 0x600 + node ID
  DLC: 8
  Data: 2B 11 60 01 C2 01 00 00
        |  |     |  |
        |  |     Sub-index: 0x01
        |  Index: 0x6011
        Command: 0x2B (Write 2 bytes, expedited)

NMT — Netzwerkmanagement-Zustandsmaschine

Der NMT-Master (typischerweise das CANopen-Gateway oder die SPS) steuert den Betriebszustand aller Knoten im Netzwerk. Nach dem Einschalten wechseln die Knoten automatisch in den Zustand Pre-Operational — PDOs sind inaktiv, aber der SDO-Zugriff für die Konfiguration ist verfügbar. Der NMT-Master sendet einen Broadcast-Befehl, um alle Knoten in den Zustand Operational zu versetzen und den PDO-Austausch zu aktivieren.

CiA 417 Aufzugs- und CiA 419 HVAC-Geräteprofile

CiA-Geräteprofile standardisieren das Objektverzeichnis-Layout für bestimmte Gerätetypen und gewährleisten die Interoperabilität zwischen Geräten verschiedener Hersteller. Zwei Profile sind für die Gebäudeautomation direkt relevant: CiA 417 für Aufzugsanlagen und CiA 419 für HVAC-Systeme.

CANopen-Gateways zu BACnet, Modbus und KNX

Die meisten Gebäudeautomationssysteme (KNX, BACnet, Modbus) können nativ kein CANopen sprechen – ein Protokoll-Gateway vermittelt zwischen den Feldbuswelten. Drei Gateway-Familien sind weit verbreitet.