CANopen es una pila de protocolos de comunicación y una especificación de perfil de dispositivo para sistemas integrados utilizados en automatización . En términos del modelo OSI , CANopen implementa las capas superiores, incluida la capa de red . El estándar CANopen consta de un esquema de direccionamiento, varios protocolos de comunicación pequeños y una capa de aplicación definida por un perfil de dispositivo. Los protocolos de comunicación admiten la gestión de red, la monitorización de dispositivos y la comunicación entre nodos, incluida una capa de transporte simple para la segmentación/desegregación de mensajes. El protocolo de nivel inferior que implementa el enlace de datos y las capas físicas suele ser la red de área del controlador (CAN), aunque los dispositivos que utilizan otros medios de comunicación (como Ethernet Powerlink , EtherCAT ) también pueden implementar el perfil de dispositivo CANopen.
Los perfiles básicos de dispositivos y comunicaciones CANopen se proporcionan en la especificación CiA 301 publicada por CAN in Automation . [1] Los perfiles para dispositivos más especializados se construyen sobre este perfil básico y se especifican en numerosos otros estándares publicados por CAN in Automation, como CiA 401 [2] para módulos de E/S y CiA 402 [3] para control de movimiento.
Cada dispositivo CANopen debe implementar ciertas características estándar en su software de control.
Los dispositivos CANopen deben tener un diccionario de objetos, que se utiliza para la configuración y la comunicación con el dispositivo. Una entrada en el diccionario de objetos se define mediante:
Los tipos de datos básicos para valores de diccionario de objetos, como booleanos , enteros y flotantes, se definen en el estándar (su tamaño en bits se almacena opcionalmente en la definición de tipo relacionada, rango de índice 0x0001–0x001F), así como los tipos de datos compuestos, como cadenas, matrices y registros (definidos en el rango de índice 0x0040–0x025F). Los tipos de datos compuestos se pueden subindexar con un índice de 8 bits; el valor en el subíndice 0 de una matriz o registro indica el número de elementos en la estructura de datos y es del tipo UNSIGNED8.
Por ejemplo, los parámetros de comunicación del dispositivo, estandarizados en el perfil básico de dispositivo CiA 301 [4], se asignan en el rango de índice 0x1000–0x1FFF ("área de perfil de comunicación"). Las primeras entradas en esta área son las siguientes:
Si se utilizan las herramientas adecuadas, el contenido del diccionario de objetos de un dispositivo, basado en una hoja de datos electrónica (EDS), se puede personalizar en un archivo de configuración del dispositivo (DCF) para integrar el dispositivo en una red CANopen específica. Según CiA 306 [5] , el formato del archivo EDS es el formato de archivo INI . Existe un próximo formato de estilo XML, que se describe en CiA 311 [6] .
El bus CAN , la capa de enlace de datos de CANopen, solo puede transmitir paquetes cortos que constan de un identificador de 11 bits, un bit de solicitud de transmisión remota (RTR) y de 0 a 8 bytes de datos. El estándar CANopen divide el identificador de trama CAN de 11 bits en un código de función de 4 bits y un identificador de nodo CANopen de 7 bits. Esto limita la cantidad de dispositivos en una red CANopen a 127 (el 0 está reservado para la transmisión). Una extensión del estándar de bus CAN (CAN 2.0 B) permite identificadores de trama extendidos de 29 bits, pero en la práctica, rara vez se ven redes CANopen lo suficientemente grandes como para necesitar el rango de identificadores extendido.
En CANopen, el identificador de 11 bits de una trama CAN se conoce como identificador de objeto de comunicación o COB-ID. En caso de colisión de transmisión, el arbitraje de bus utilizado en el bus CAN permite que la trama con el identificador más pequeño se transmita primero y sin demora. El uso de un número de código bajo para funciones críticas en el tiempo garantiza la menor demora posible.
Contenido de un marco CANopen:
El marco de datos con un identificador de 11 bits también se denomina "formato de marco base".
La asignación CAN-ID predeterminada ordena las tramas atribuyendo un código de función (NMT, SYNC, EMCY, PDO, SDO...) a los primeros 4 bits, de modo que se dé prioridad a las funciones críticas. Sin embargo, esta asignación se puede personalizar para fines especiales (excepto para NMT y SDO, necesarios para la comunicación básica).
El estándar reserva determinados identificadores CAN para la gestión de la red y las transferencias SDO. Algunos códigos de función e identificadores CAN deben asignarse a la funcionalidad estándar después de la inicialización del dispositivo, pero pueden configurarse para otros usos más adelante.
Para estructuras de red simples, CANopen admite una asignación predefinida de identificadores de mensajes.
Las direcciones de transmisión y recepción se dan desde el punto de vista del dispositivo. Por lo tanto, una consulta a un dispositivo de la red enviaría un 0x600+nodeid y obtendría un 0x580+nodeid. [1]
Se utilizan diferentes tipos de modelos de comunicación en la mensajería entre nodos CANopen.
En una relación maestro/esclavo , un nodo CANopen se designa como maestro, que envía o solicita datos a los esclavos. El protocolo NMT es un ejemplo de un modelo de comunicación maestro/esclavo.
En el protocolo SDO se implementa una relación cliente/servidor , donde el cliente SDO envía datos (el índice y subíndice del diccionario de objetos) a un servidor SDO, que responde con uno o más paquetes SDO que contienen los datos solicitados (el contenido del diccionario de objetos en el índice dado).
En los protocolos Heartbeat y Node Guarding se utiliza un modelo productor/consumidor . En el modelo push de productor/consumidor, el productor envía datos al consumidor sin una solicitud específica, mientras que en el modelo pull , el consumidor debe solicitar los datos al productor.
Los protocolos NMT se utilizan para emitir comandos de cambio de máquina de estado (por ejemplo, para iniciar y detener los dispositivos), detectar arranques de dispositivos remotos y condiciones de error.
El protocolo de control de módulo lo utiliza el maestro NMT para cambiar el estado de los dispositivos. El COB-ID de la trama CAN de este protocolo siempre es 0, lo que significa que tiene un código de función 0 y un ID de nodo 0, lo que significa que cada nodo de la red procesará este mensaje. El ID del nodo real, al que está destinado el comando, se proporciona en la parte de datos del mensaje (en el segundo byte). Este también puede ser 0, lo que significa que todos los dispositivos del bus deben pasar al estado indicado.
El protocolo Heartbeat se utiliza para supervisar los nodos de la red y verificar que estén activos. Un productor de heartbeat (normalmente un dispositivo esclavo) envía periódicamente un mensaje con el código de función binario 1110 y su ID de nodo (COB-ID19 = 0x700 + ID de nodo). La parte de datos de la trama contiene un byte que indica el estado del nodo. El consumidor de heartbeat lee estos mensajes. Si los mensajes no llegan en un plazo determinado (definido en el diccionario de objetos de los dispositivos), el consumidor puede tomar medidas para, por ejemplo, reiniciar el dispositivo o indicar un error. El formato de la trama es:
Los dispositivos CANopen deben realizar la transición del estado inicializando al preoperacional automáticamente durante el arranque. Cuando se realiza esta transición, se envía un único mensaje de latido al bus. Este es el protocolo de arranque .
Existe un protocolo de estilo respuesta/contestación (modelo pull), llamado protección de nodos, para la monitorización de esclavos.
El protocolo SDO se utiliza para configurar y leer valores del diccionario de objetos de un dispositivo remoto. El dispositivo a cuyo diccionario de objetos se accede es el servidor SDO y el dispositivo que accede al dispositivo remoto es el cliente SDO. La comunicación siempre la inicia el cliente SDO. En la terminología CANopen, la comunicación se visualiza desde el servidor SDO, de modo que una lectura de un diccionario de objetos da como resultado una carga SDO y una escritura en una entrada del diccionario es una descarga SDO.
Debido a que los valores del diccionario de objetos pueden ser mayores que el límite de ocho bytes de una trama CAN, el protocolo SDO implementa la segmentación y desegmentación de mensajes más largos. En realidad, existen dos de estos protocolos: descarga/carga SDO y descarga/carga en bloque SDO. La transferencia en bloque SDO es una incorporación más reciente al estándar, que permite transferir grandes cantidades de datos con una sobrecarga de protocolo ligeramente menor.
Los COB-ID de los respectivos mensajes de transferencia SDO de cliente a servidor y de servidor a cliente se pueden configurar en el diccionario de objetos. Se pueden configurar hasta 128 servidores SDO en el diccionario de objetos en las direcciones 0x1200 - 0x127F. De manera similar, las conexiones de cliente SDO del dispositivo se pueden configurar con variables en 0x1280 - 0x12FF. Sin embargo, el conjunto de conexiones predefinidas define un canal SDO que se puede utilizar incluso justo después del arranque (en el estado preoperacional) para configurar el dispositivo. Los COB-ID de este canal son 0x600 + ID de nodo para recepción y 0x580 + ID de nodo para transmisión.
Para iniciar una descarga, el cliente SDO envía los siguientes datos en un mensaje CAN con el COB-ID de 'recepción' del canal SDO.
El protocolo de objeto de datos de proceso se utiliza para procesar datos en tiempo real entre varios nodos. Puede transferir hasta 8 bytes (64 bits) de datos por cada PDO, ya sea desde o hacia el dispositivo. Un PDO puede contener varias entradas de diccionario de objetos y los objetos dentro de un PDO se pueden configurar mediante las entradas de diccionario de objetos de parámetros y de mapeo.
Existen dos tipos de PDO: los de transmisión y los de recepción (TPDO y RPDO). Los primeros son para los datos que vienen del dispositivo (el dispositivo es un productor de datos) y los segundos para los datos que van al dispositivo (el dispositivo es un consumidor de datos); es decir, con RPDO se pueden enviar datos al dispositivo y con TPDO se pueden leer datos del dispositivo. En el conjunto de conexiones predefinido hay identificadores para cuatro TPDO y cuatro RPDO disponibles. Con la configuración, son posibles 512 PDO.
Los PDO se pueden enviar de forma sincrónica o asincrónica. Los PDO sincrónicos se envían después del mensaje SYNC, mientras que los mensajes asincrónicos se envían después de un disparador interno o externo. Por ejemplo, puede realizar una solicitud a un dispositivo para que transmita un TPDO que contiene los datos que necesita enviando un TPDO vacío con el indicador RTR (si el dispositivo está configurado para aceptar solicitudes de TPDO).
Con los RPDO, por ejemplo, se pueden iniciar dos dispositivos simultáneamente. Solo es necesario asignar el mismo RPDO a dos o más dispositivos diferentes y asegurarse de que esos RPDO estén asignados con el mismo COB-ID.
El productor de sincronización proporciona la señal de sincronización al consumidor de sincronización. Cuando el consumidor de sincronización recibe la señal, comienza a realizar sus tareas sincrónicas.
En general, la fijación del tiempo de transmisión de mensajes PDO sincrónicos junto con la periodicidad de transmisión del objeto de sincronización garantiza que los dispositivos sensores puedan organizarse para muestrear variables de proceso y que los dispositivos actuadores puedan aplicar su actuación de manera coordinada.
El identificador del objeto de sincronización está disponible en el índice 1005h.
Generalmente, el objeto Time-Stamp representa una hora como un campo de 6 bytes: un recuento de milisegundos después de la medianoche (como máximo 27 bits, almacenados en un campo de 32 bits) y un número sin signo de 16 bits de días desde el 1 de enero de 1984. (Esto se desbordará el 7 de junio de 2163).
Algunas aplicaciones en las que el tiempo es un factor crítico, especialmente en redes grandes con velocidades de transmisión reducidas, requieren una sincronización muy precisa; puede ser necesario sincronizar los relojes locales con una precisión del orden de microsegundos. Esto se logra utilizando el protocolo de sincronización de alta resolución opcional que emplea una forma especial de mensaje de marca de tiempo para ajustar la inevitable desviación de los relojes locales.
La marca de tiempo de alta resolución está codificada como unsigned32 con una resolución de 1 microsegundo, lo que significa que el contador de tiempo se reinicia cada 72 minutos. Se configura asignando la marca de tiempo de alta resolución (objeto 1013h) a un PDO.
Los mensajes de emergencia se activan cuando se produce una situación de error fatal interno del dispositivo y se transmiten desde el dispositivo de aplicación en cuestión a los demás dispositivos con alta prioridad. Esto los hace adecuados para alertas de error de tipo interrupción. Un telegrama de emergencia solo se puede enviar una vez por "evento de error", es decir, los mensajes de emergencia no se deben repetir. Mientras no se produzcan nuevos errores en un dispositivo, no se deben enviar más mensajes de emergencia. Mediante los códigos de error de emergencia definidos en el perfil de comunicación CANopen, el registro de errores y la información adicional específica del dispositivo se especifican en los perfiles del dispositivo.
Ejemplo de traza de comunicaciones entre un maestro y dos esclavos transductores de presión configurados para id 1 e ID de nodo 2.
La hoja de datos electrónica (EDS) es un formato de archivo, definido en CiA306, que describe el comportamiento de comunicación y las entradas del diccionario de objetos de un dispositivo. Esto permite que herramientas como herramientas de servicio, herramientas de configuración, herramientas de desarrollo y otras gestionen los dispositivos de manera adecuada.
Estos archivos EDS son obligatorios para pasar la prueba de conformidad CANopen de CiA.
Desde finales de 2007 se ha definido en CiA311 un nuevo formato basado en XML denominado XDD, que cumple la norma ISO 15745.