CANopen · CiA 301 · CiA 419 · PDO · SDO · NMT · Automatización de edificios · 10 min de lectura

CANopen en automatización de edificios: Diccionario de objetos, PDO, SDO y perfil HVAC CiA 419

CANopen es la capa de aplicación que funciona sobre el bus CAN, estandarizada por CAN in Automation (CiA) como CiA 301. Define cómo los dispositivos describen sus datos (diccionario de objetos), cómo se intercambian los valores de proceso a alta velocidad (PDO), cómo se leen y escriben los parámetros durante la puesta en marcha (SDO) y cómo se gestiona la red (NMT) — además de perfiles de tipo de dispositivo como CiA 419 para sistemas HVAC que especifican exactamente qué objetos debe proporcionar un enfriador o una UTA.

Diccionario de objetos CANopen

Cada dispositivo CANopen tiene un diccionario de objetos (OD) — una tabla estructurada de todos los parámetros y valores de proceso que soporta el dispositivo. Cada entrada se direcciona mediante un índice de 16 bits (0x0000–0xFFFF) y un subíndice de 8 bits (0x00–0xFF). El fabricante proporciona el OD en un archivo Electronic Data Sheet (EDS) — un archivo de texto en formato INI que las herramientas de configuración cargan para conocer qué objetos soporta el dispositivo.

Índice	Objeto	Descripción
0x1000	Tipo de dispositivo	Obligatorio — identifica el perfil de dispositivo CiA implementado (p. ej. 0x00190191 = CiA 419 HVAC)
0x1001	Registro de errores	Obligatorio — campo de bits de categorías de error activas (comunicación, específicas del dispositivo, etc.)
0x1008	Nombre del dispositivo del fabricante	Opcional — cadena de modelo de dispositivo legible por humanos
0x1017	Tiempo de latido del productor	Tiempo de ciclo de latido en ms — 0 desactiva latido
0x1018	Objeto de identidad	ID de fabricante, código de producto, revisión, número de serie (subíndices 1–4)
0x1400–0x15FF	Parámetros de comunicación RPDO	COB-ID, tipo de transmisión y tiempo de inhibición para cada PDO de recepción
0x1600–0x17FF	Parámetros de mapeo RPDO	Qué objetos OD se asignan a cada RPDO (índice, subíndice, longitud de bits)
0x1800–0x19FF	Parámetros de comunicación TPDO	COB-ID, tipo de transmisión, temporizador de eventos para cada PDO de transmisión
0x1A00–0x1BFF	Parámetros de mapeo TPDO	Qué objetos OD se empaquetan en cada TPDO
0x2000–0x5FFF	Objetos específicos del fabricante	Valores de proceso específicos del dispositivo — temperaturas del chiller, códigos de alarma, puntos de consigna
0x6000–0x9FFF	Objetos de perfil de dispositivo CiA	Objetos de perfil estandarizados (CiA 419 HVAC: 0x6000–0x67FF)

PDO — Objetos de datos de proceso

Los PDO son el mecanismo de intercambio de datos en tiempo real en CANopen — tramas CAN rápidas y de baja sobrecarga que transportan hasta 8 bytes de datos de proceso sin sobrecarga de protocolo más allá de la trama CAN misma. Un PDO de transmisión (TPDO) envía datos desde un dispositivo a la red; un PDO de recepción (RPDO) acepta datos escritos por un maestro u otro dispositivo.

El mapeo PDO define qué entradas del diccionario de objetos se empaquetan en un PDO. Por ejemplo, un TPDO1 de chiller podría empaquetar la temperatura de suministro (0x6010:01, 16 bits), la temperatura de retorno (0x6010:02, 16 bits), el estado de funcionamiento del compresor (0x6020:01, 8 bits) y el estado de alarma (0x6030:01, 8 bits) — totalizando 6 bytes en una sola trama CAN transmitida cada 1 segundo.

Tipos de transmisión PDO — tabla CiA 301

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

Los SDO se utilizan para la configuración y el acceso a parámetros — lectura o escritura de cualquier entrada del diccionario de objetos mediante un handshake confirmado y acusado. A diferencia de los PDO (disparar y olvidar), las transferencias SDO garantizan la entrega y devuelven el valor leído o una confirmación de la escritura. El acceso SDO es lento (varias tramas CAN por lectura/escritura) y se utiliza durante la puesta en marcha, no para datos de proceso cíclicos.

Ejemplo de lectura/escritura SDO — trama manual de PCAN-View

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 — máquina de estados de gestión de red

El maestro NMT (típicamente la puerta de enlace CANopen o el PLC) controla el estado operativo de todos los nodos de la red. Después del encendido, los nodos entran automáticamente en el estado Pre-Operational — los PDO están inactivos pero el acceso SDO para configuración está disponible. El maestro NMT envía un comando de difusión para que todos los nodos pasen al estado Operational, activando el intercambio de PDO.

Estado NMT	PDO activos	SDO activo	Notas
Inicialización	No	No	El dispositivo arranca aquí al encender, transición automática
Pre-Operacional	No	Sí	Configurar mapeos PDO, establecer parámetros del nodo mediante SDO
Operativo	Sí	Sí	Estado de funcionamiento normal — PDO y SDO ambos activos
Detenido	No	No	Estado de mantenimiento — sin comunicación excepto NMT

El protocolo Heartbeat (CiA 301) reemplaza el mecanismo anterior Node Guarding. Cada nodo transmite una trama Heartbeat en un intervalo configurable (típicamente 1000 ms). El maestro NMT monitorea la recepción de Heartbeats — si un nodo deja de enviar Heartbeats, el maestro detecta la falla del nodo y puede activar una alarma en el sistema de automatización del edificio.

Perfiles de dispositivo CiA 417 para ascensores y CiA 419 para HVAC

Los perfiles de dispositivo CiA estandarizan la disposición del diccionario de objetos para tipos específicos de equipos, garantizando la interoperabilidad entre dispositivos de diferentes fabricantes. Dos perfiles son directamente relevantes para la automatización de edificios: CiA 417 para sistemas de ascensores y CiA 419 para sistemas HVAC.

Objeto CiA 419	Índice	Descripción
Temperatura del aire de impulsión	0x6010:01	INT16, unidad 0,01°C — dividir entre 100 para valor en °C
Temperatura del aire de retorno	0x6010:02	INT16, unidad 0,01°C — aire de retorno/extracción de zona
Temperatura del aire exterior	0x6010:05	INT16, unidad 0,01°C — lectura del sensor ambiente
Punto de consigna de temperatura	0x6011:01	INT16, unidad 0,01°C — escribible por el maestro para control del punto de consigna
Punto de consigna de velocidad del ventilador	0x6020:01	UINT16, unidad 0,01% — 0–10000 = comando de velocidad 0–100%
Velocidad real del ventilador	0x6020:02	UINT16, unidad 0,01% — porcentaje real de salida del ventilador
Punto de consigna de posición de válvula	0x6030:01	UINT16, unidad 0,01% — comando de válvula de calefacción/refrigeración
Posición real de la válvula	0x6030:02	UINT16, unidad 0,01% — retroalimentación de posición de válvula
Modo de operación	0x6040:01	UINT8 — 0=apagado, 1=calefacción, 2=refrigeración, 3=automático, 4=solo ventilador
Estado de alarma	0x6050:01	Campo de bits UINT32 — cada bit representa un código de alarma específico

Puertas de enlace CANopen a BACnet, Modbus y KNX

La mayoría de los sistemas de automatización de edificios (KNX, BACnet, Modbus) no pueden hablar CANopen de forma nativa — una puerta de enlace de protocolo traduce entre los mundos de los buses de campo. Se utilizan ampliamente tres familias de puertas de enlace.

Puerta de enlace	Protocolos	Notas
Puerta de enlace Ixxat CANopen	CANopen ↔ Modbus TCP/RTU	Configurable mediante interfaz web – mapear objetos OD CANopen a registros de holding Modbus; admite hasta 127 nodos CANopen
Anybus X-gateway CANopen–BACnet	CANopen ↔ BACnet IP	HMS Networks – mapeo de objetos BACnet mediante Anybus Configuration Manager; utilizado en grandes integraciones BMS
EMS Electronic CANopen–KNX	CANopen ↔ KNX TP	Asigna objetos CANopen PDO/SDO a direcciones de grupo KNX; configuración mediante plugin ETS6
Weinzierl BAOS CANopen Bridge	CANopen ↔ KNX IP	Enrutamiento KNX IP con función maestra CANopen; utilizado en pasarelas de cuadros eléctricos

Solicite siempre el archivo EDS al fabricante del equipo antes de pedir una pasarela. Sin el EDS, no puede determinar qué índices de objetos admite el dispositivo ni si implementa un perfil CiA estándar o solo utiliza objetos específicos del fabricante. Algunos enfriadores solo exponen un subconjunto de objetos CiA 419 y requieren objetos específicos del fabricante para los códigos de alarma.