ELEM0110 | Automatización Industrial

1. El Origen Automotriz: CAN Bus

Mucho antes de que Ethernet dominara la fábrica, el sector de la automoción resolvió un problema similar: cómo conectar decenas de sensores y centralitas (ECUs) en un coche de forma robusta y económica. La solución fue el CAN (Controller Area Network), un bus serie diferencial extremadamente fiable. Su robustez es tal que la industria de la maquinaria pesada y la automatización lo adoptó rápidamente.

Para un técnico de UF1794, es vital entender que CAN es solo la capa física y de enlace. Define el cableado (un par trenzado, CAN_H y CAN_L) y un ingenioso método de arbitraje (CSMA/CA) que permite a los nodos competir por el bus sin destruir los mensajes de los demás. Sin embargo, CAN no define qué significan los datos que viajan por el bus. Dos protocolos de aplicación principales se construyeron sobre esta base: CANopen y DeviceNet.

2. CANopen: El Estándar Europeo para Movimiento

Desarrollado en Europa por la organización CiA (CAN in Automation), CANopen es un protocolo de alto nivel muy popular en servomotores, encoders y sistemas embebidos. Su filosofía se basa en un Diccionario de Objetos (Object Dictionary - OD), que es un mapa de memoria estandarizado. Cualquier dispositivo CANopen que se precie tendrá, por ejemplo, el parámetro "Velocidad" en el mismo índice del diccionario.

La comunicación se divide en dos tipos de mensajes:

PDO (Process Data Objects): Son telegramas cortos y rápidos para datos cíclicos. Se usan para enviar consignas de velocidad, leer posiciones de encoders, etc. Son como el tráfico RT de PROFINET.
SDO (Service Data Objects): Son mensajes más lentos y fiables para configuración bajo demanda. Se usan para parametrizar el dispositivo, leer diagnósticos o descargar firmware. Son como el tráfico acíclico NRT.

3. DeviceNet: El CIP Americano sobre CAN

Mientras Europa desarrollaba CANopen, en América, Rockwell Automation (Allen-Bradley) y la ODVA tomaron un camino diferente. En lugar de crear un nuevo lenguaje, tomaron su protocolo de aplicación estrella, el CIP (Common Industrial Protocol), y lo adaptaron para que pudiera viajar sobre un bus físico CAN. El resultado fue DeviceNet.

Esto significa que, a nivel de aplicación, DeviceNet y EtherNet/IP "hablan el mismo idioma". Ambos utilizan el modelo de objetos CIP con Clases, Instancias y Atributos, y ambos dividen la comunicación en Mensajería Implícita (para E/S cíclicas) y Mensajería Explícita (para configuración). La única diferencia es el "transporte": DeviceNet mete los mensajes CIP en tramas CAN, mientras que EtherNet/IP los mete en paquetes TCP/UDP.

4. Integración en Redes Ethernet Modernas

Hoy en día, tanto CANopen como DeviceNet se consideran buses de campo "legacy" o de nivel de máquina. Es raro encontrar un PLC moderno con un puerto CAN nativo. La estrategia de integración es idéntica a la que vimos con PROFIBUS: el uso de pasarelas (Gateways).

Un Gateway PROFINET a CANopen se comporta como un esclavo PROFINET (IO Device) en la red Ethernet, y como un Maestro CANopen en el bus serie. El PLC S7-1500 le envía los datos por PROFINET, y la pasarela se encarga de traducirlos a PDOs y SDOs para controlar los servomotores.
Un Gateway EtherNet/IP a DeviceNet (a menudo llamado "Scanner") hace lo mismo en el ecosistema Rockwell, permitiendo que un PLC ControlLogix controle una red de sensores y actuadores DeviceNet antiguos.

Para el programador del PLC moderno, la existencia del bus CAN es casi transparente. Interactúa con la pasarela como si fuera un módulo de E/S más en su red Ethernet.

Figura 1: Arquitectura de integración de buses CAN. El PLC principal vive en la red Ethernet y solo se comunica con la pasarela. Esta actúa como Maestro del bus CAN, gestionando la comunicación serie con los dispositivos de campo y mapeando sus datos para que el PLC pueda acceder a ellos de forma transparente.
Fuente: Elaboración Propia. Licencia: CC BY-SA 4.0.

📝 Evaluación Técnica: Protocolos sobre CAN

1. ¿Cuál es la capa física y de enlace común que utilizan tanto el protocolo CANopen como el protocolo DeviceNet?

2. En el protocolo CANopen, ¿qué tipo de objeto se utiliza para el intercambio rápido y cíclico de datos de proceso (ej. posición de un encoder), y cuál para la configuración bajo demanda de parámetros?

3. ¿Qué relación existe entre el protocolo de aplicación de DeviceNet y el de EtherNet/IP?

🤖 Ejercicio Práctico 5: Sniffer de Bus CAN con Python

Objetivo: Entender la estructura de una trama CAN básica y cómo se identifican los mensajes en el bus.

Copia el siguiente *prompt* y pégalo en un modelo de IA (como ChatGPT, Gemini o Claude).

Actúa como un ingeniero de automoción o de sistemas embebidos. Escribe un script en Python que utilice la librería `python-can` para leer y mostrar tramas de un bus CAN. El script debe: 1. Importar la librería `can`. 2. Configurar una interfaz de bus virtual para poder simular sin hardware real (ej. `interface.Bus('test', bustype='virtual')`). 3. Crear un bucle que lea los mensajes del bus. 4. Por cada mensaje recibido, debe imprimir de forma clara y formateada: - El Timestamp (marca de tiempo). - El Arbitration ID (el identificador del mensaje). - El DLC (Data Length Code - cuántos bytes de datos lleva). - Los datos (payload) en formato hexadecimal. Comenta el código explicando que el Arbitration ID es clave, ya que en CAN los mensajes no tienen origen ni destino, sino un identificador de contenido que determina su prioridad en el bus.