Glosario de Automatización • COB-ID de CANopen

¿Qué es un COB-ID de CANopen?

Ingeniería Merobix • • 6 min de lectura

La primera vez que mira una captura de CANopen, los identificadores CAN crudos parecen crípticos hasta que aprende que CANopen los asigna con un esquema simple y predecible construido a partir de un código de función y un número de nodo. Ese esquema es el COB-ID, y saber cómo se descompone le permite leer un bus CANopen de un vistazo y configurar los PDO correctamente. Esta página explica qué es un COB-ID, cómo el conjunto de conexiones predefinido deriva los identificadores por defecto a partir del node ID, y por qué esa estructura importa cuando mapea objetos hacia un sistema de monitoreo.

Volver al glosario

COB-ID de CANopen en una línea: Un COB-ID (identificador de objeto de comunicación) es el identificador CAN que CANopen asigna a cada mensaje, y en el conjunto de conexiones predefinido estándar se construye con un código de función en los bits altos más el node ID del dispositivo en los siete bits bajos. Esa estructura significa que el COB-ID le dice a la vez qué clase de mensaje es y a qué nodo pertenece, así que puede decodificar un bus CANopen directamente desde los identificadores.

Cómo un COB-ID codifica nodo y función

CANopen no usa los identificadores CAN crudos de manera arbitraria; los estructura. En el conjunto de conexiones predefinido que define el estándar, un COB-ID de 11 bits se divide en un campo superior de código de función y un campo inferior que lleva el node ID de siete bits, que va de 1 a 127. El código de función dice qué clase de objeto de comunicación es el mensaje, por ejemplo un mensaje de emergencia, un PDO de transmisión o recepción en particular, un SDO o un heartbeat, y el node ID dice a qué dispositivo concierne.

Por eso los identificadores por defecto de CANopen se ven regulares en un analizador. Los mensajes de gestión de nodos y de emergencia, los cuatro PDO por defecto, los canales SDO y el heartbeat ocupan cada uno un rango conocido de código de función, y dentro de ese rango los bits bajos cuentan el número de nodo. Una vez que interioriza la división, puede mirar un identificador pelado y decir de inmediato tanto el tipo de mensaje como el nodo, sin tabla de consulta, lo cual es un ahorro de tiempo genuino al leer un bus en vivo.

El conjunto de conexiones predefinido y sus límites

El conjunto de conexiones predefinido existe para que una red simple funcione de fábrica: asigne a cada dispositivo un node ID único y sus COB-ID por defecto caen en su lugar automáticamente, dando a cada nodo sus PDO estándar, su SDO, su heartbeat y sus identificadores de emergencia sin asignación manual de identificadores. Para muchas máquinas ese mapeo por defecto es todo lo que se necesita, y es la razón por la que la puesta en servicio de CANopen puede ser tan rápida cuando los node ID están bien puestos.

Los valores por defecto tienen límites, sin embargo. El conjunto predefinido da a cada nodo solo un puñado de PDO por defecto, así que un dispositivo que necesita publicar más datos de proceso, o una red que quiere un mapeo productor-consumidor a la medida, reconfigura los COB-ID explícitamente a través de los parámetros de comunicación en el diccionario de objetos. Cuando remapea un PDO a un COB-ID no estándar, está anulando el esquema predefinido, y tanto el nodo productor como el consumidor deben acordar el nuevo identificador.

Como un COB-ID es en última instancia un identificador CAN, su valor numérico también fija la prioridad del mensaje a través del arbitraje del bus CAN. El arreglo de códigos de función está dispuesto para que los objetos CANopen críticos en tiempo obtengan identificadores más bajos y por lo tanto mayor prioridad, que es otra razón para no reasignar COB-ID a la ligera: un identificador a la medida mal elegido puede invertir la prioridad prevista y dejar que el tráfico de mantenimiento supere a los datos de tiempo real.

Por qué la estructura ayuda al monitoreo

Para quien integra CANopen hacia arriba, la estructura del COB-ID es un regalo porque hace al bus autodescriptivo a nivel de identificador. Un gateway o un analizador puede derivar, solo del COB-ID, a qué nodo y a qué objeto pertenece cada trama, que es como las herramientas presentan un flujo CAN crudo como tráfico CANopen organizado en lugar de una lista indiferenciada de identificadores. Esa descomposición es el primer paso para convertir tramas en tags con nombre.

También hace más limpia la solución de problemas. Si el heartbeat de un nodo se detiene, su COB-ID de heartbeat simplemente enmudece, y como el COB-ID identifica al nodo, usted sabe de inmediato qué dispositivo se cayó, lo que conecta directamente con el monitoreo por node guarding y heartbeat. Nunca está adivinando a qué dispositivo físico corresponde un identificador, porque el node ID está ahí mismo, en los bits bajos.

Cuando los datos llegan a una plataforma de monitoreo a través de un gateway, el COB-ID ya hizo su trabajo y los valores aparecen como tags ordinarios, pero el mapeo limpio que habilitó es lo que hizo sistemática la integración. Una red con node ID bien asignados y COB-ID por defecto se mapea hacia un historiador con una estructura de tags predecible y repetible, que es exactamente lo que quiere en una flota de máquinas similares.

Preguntas frecuentes

¿Qué contiene un COB-ID de CANopen?

En el conjunto de conexiones predefinido estándar, un COB-ID de 11 bits se construye con un campo superior de código de función y un node ID inferior de siete bits (1 a 127). El código de función identifica el tipo de mensaje, como una emergencia, un PDO específico, un canal SDO o un heartbeat, y el node ID identifica a qué dispositivo pertenece el mensaje. Así, un COB-ID le dice a la vez qué es un mensaje y a qué nodo concierne, legible directamente desde el identificador.

¿Qué es el conjunto de conexiones predefinido de CANopen?

Es el mapeo por defecto que asigna automáticamente a cada nodo sus COB-ID estándar basándose solo en su node ID, de modo que una red simple funciona sin asignación manual de identificadores. Fijar un node ID único da a cada dispositivo sus PDO por defecto, su canal SDO, su heartbeat y sus identificadores de emergencia. Las redes que necesitan más PDO o un mapeo a la medida anulan estos valores por defecto a través de los parámetros de comunicación en el diccionario de objetos.

¿Puedo cambiar un COB-ID de CANopen?

Sí, a través de los parámetros de comunicación de los PDO en el diccionario de objetos, y a veces es necesario cuando un dispositivo requiere más PDO que los por defecto o un mapeo productor-consumidor a la medida. Tanto el nodo productor como el consumidor deben acordar el nuevo COB-ID. Como un COB-ID es un identificador CAN, su valor también fija la prioridad de arbitraje, así que un identificador mal elegido puede invertir la prioridad prevista de los mensajes.

Más en Protocolos industriales
PDO vs SDO en CANopen  •  CANopen  •  Node guarding frente a heartbeat  •  Diccionario de objetos CANopen  •  Todo en Protocolos industriales →
Capacitación SCADA gratuita para operadores
Merobix University - 70 lecciones en video y 261 preguntas de examen, del primer inicio de sesión a los reportes de cumplimiento (contenido en inglés). Sin llamada de ventas.
Comenzar gratis →