CANopen · CiA 301 · CiA 419 · PDO · SDO · NMT · Building automation · 10 min read

CANopen in Building Automation: Object Dictionary, PDO, SDO and CiA 419 HVAC Profile

CANopen is the application layer that runs on top of CAN bus, standardised by CAN in Automation (CiA) as CiA 301. It defines how devices describe their data (object dictionary), how process values are exchanged at high speed (PDO), how parameters are read and written during commissioning (SDO), and how the network is managed (NMT) — plus device-type profiles such as CiA 419 for HVAC systems that specify exactly which objects a chiller or AHU must provide.

CANopen object dictionary

Every CANopen device has an object dictionary (OD) — a structured table of all parameters and process values the device supports. Each entry is addressed by a 16-bit index (0x0000–0xFFFF) and an 8-bit sub-index (0x00–0xFF). The manufacturer provides the OD in an Electronic Data Sheet (EDS) file — a plain text file in INI format that configuring tools load to know what objects the device supports.

Index	Object	Description
0x1000	Device type	Mandatory — identifies the CiA device profile implemented (e.g. 0x00190191 = CiA 419 HVAC)
0x1001	Error register	Mandatory — bit field of active error categories (communication, device-specific, etc.)
0x1008	Manufacturer device name	Optional — human-readable device model string
0x1017	Producer heartbeat time	Heartbeat cycle time in ms — 0 disables heartbeat
0x1018	Identity object	Vendor ID, product code, revision, serial number (sub-indices 1–4)
0x1400–0x15FF	RPDO communication parameters	COB-ID, transmission type, and inhibit time for each Receive PDO
0x1600–0x17FF	RPDO mapping parameters	Which OD objects are mapped into each RPDO (index, sub-index, bit length)
0x1800–0x19FF	TPDO communication parameters	COB-ID, transmission type, event timer for each Transmit PDO
0x1A00–0x1BFF	TPDO mapping parameters	Which OD objects are packed into each TPDO
0x2000–0x5FFF	Manufacturer-specific objects	Device-specific process values — chiller temps, alarm codes, setpoints
0x6000–0x9FFF	CiA device profile objects	Standardised profile objects (CiA 419 HVAC: 0x6000–0x67FF)

PDO — Process Data Objects

PDOs are the real-time data exchange mechanism in CANopen — high-speed, low-overhead CAN frames that carry up to 8 bytes of process data with no protocol overhead beyond the CAN frame itself. A Transmit PDO (TPDO) sends data from a device to the network; a Receive PDO (RPDO) accepts data written by a master or another device.

PDO mapping defines which object dictionary entries are packed into a PDO. For example, a chiller TPDO1 might pack supply water temperature (0x6010:01, 16 bits), return water temperature (0x6010:02, 16 bits), compressor run status (0x6020:01, 8 bits), and alarm status (0x6030:01, 8 bits) — totalling 6 bytes in a single CAN frame transmitted every 1 second.

PDO transmission types — CiA 301 table

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 are used for configuration and parameter access — reading or writing any object dictionary entry using a confirmed, acknowledged handshake. Unlike PDOs (fire-and-forget), SDO transfers guarantee delivery and return the read value or a confirmation of the write. SDO access is slow (multiple CAN frames per read/write) and is used during commissioning, not for cyclic process data.

SDO read/write example — PCAN-View manual frame

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 — Network Management state machine

The NMT master (typically the CANopen gateway or PLC) controls the operating state of all nodes on the network. After power-on, nodes enter Pre-Operational state automatically — PDOs are inactive but SDO access is available for configuration. The NMT master sends a broadcast command to transition all nodes to Operational, activating PDO exchange.

NMT state	PDOs active	SDO active	Notes
Initialisation	No	No	Device starts here on power-on, transitions automatically
Pre-Operational	No	Yes	Configure PDO mappings, set node parameters via SDO
Operational	Yes	Yes	Normal running state — PDOs and SDOs both active
Stopped	No	No	Maintenance state — no communication except NMT

The Heartbeat protocol (CiA 301) replaces the older Node Guarding mechanism. Each node transmits a heartbeat frame at a configurable interval (typically 1000ms). The NMT master monitors heartbeat reception — if a node stops sending heartbeats, the master detects node failure and can trigger an alarm in the building automation system.

CiA 417 elevator and CiA 419 HVAC device profiles

CiA device profiles standardise the object dictionary layout for specific equipment types, ensuring interoperability between devices from different manufacturers. Two profiles are directly relevant to building automation: CiA 417 for elevator systems and CiA 419 for HVAC systems.

CiA 419 object	Index	Description
Supply air temperature	0x6010:01	INT16, unit 0.01°C — divide by 100 for °C value
Return air temperature	0x6010:02	INT16, unit 0.01°C — zone return/extract air
Outside air temperature	0x6010:05	INT16, unit 0.01°C — ambient sensor reading
Temperature setpoint	0x6011:01	INT16, unit 0.01°C — writable by master for setpoint control
Fan speed setpoint	0x6020:01	UINT16, unit 0.01% — 0–10000 = 0–100% speed command
Actual fan speed	0x6020:02	UINT16, unit 0.01% — actual fan output percentage
Valve position setpoint	0x6030:01	UINT16, unit 0.01% — heating/cooling valve command
Actual valve position	0x6030:02	UINT16, unit 0.01% — valve position feedback
Operating mode	0x6040:01	UINT8 — 0=off, 1=heating, 2=cooling, 3=auto, 4=fan only
Alarm status	0x6050:01	UINT32 bit field — each bit represents a specific alarm code

CANopen gateways to BACnet, Modbus and KNX

Most building automation systems (KNX, BACnet, Modbus) cannot natively speak CANopen — a protocol gateway translates between the fieldbus worlds. Three gateway families are widely used.

Gateway	Protocols	Notes
Ixxat CANopen Gateway	CANopen ↔ Modbus TCP/RTU	Configurable via web UI — map CANopen OD objects to Modbus holding registers; supports up to 127 CANopen nodes
Anybus X-gateway CANopen–BACnet	CANopen ↔ BACnet IP	HMS Networks — BACnet object mapping via Anybus Configuration Manager; used in large BMS integrations
EMS Electronic CANopen–KNX	CANopen ↔ KNX TP	Maps CANopen PDO/SDO objects to KNX group addresses; config via ETS6 plugin
Weinzierl BAOS CANopen Bridge	CANopen ↔ KNX IP	KNX IP routing with CANopen master function; used in panelboard gateways

Always request the EDS file from the equipment manufacturer before ordering a gateway. Without the EDS, you cannot determine which object indices the device supports and whether it implements a standard CiA profile or uses manufacturer-specific objects only. Some chillers only expose a subset of CiA 419 objects and require manufacturer-specific objects for alarm codes.