EtherCAT es un bus de campo sobre Ethernet desarrollado por Beckhoff, mantenido por la EtherCAT Technology Group y normalizado en IEC 61158. Una única trama recorre todos los esclavos encadenados y cada uno lee y escribe sus datos al vuelo, mientras la trama sigue circulando, en lugar de almacenarla y reenviarla como haría un conmutador.
Dónde aparece EtherCAT en planta
EtherCAT vive dentro de la máquina más que entre máquinas. Aparece sobre todo en equipos de fabricantes de bienes de equipo con control basado en PC industrial: envasado y embalaje, máquina herramienta, líneas de corte y conformado, manipulación y robótica, y en cualquier aplicación con varios ejes que deban moverse coordinados. En una planta española típica no es la red que une los armarios de la línea, sino el bus interno de una o varias máquinas compradas llave en mano. Eso tiene una consecuencia práctica importante: la configuración del maestro, y con ella los nombres de las variables, suele pertenecer al fabricante de la máquina, no al departamento de mantenimiento de la planta.
EtherCAT frente a PROFINET
Ambos usan tramas y cableado Ethernet estándar, y ahí acaba el parecido. PROFINET es una red conmutada: cada dispositivo tiene su enlace, recibe su propia trama y la infraestructura es la misma que la de IT. EtherCAT trata el segmento como un anillo lógico recorrido por una sola trama que los esclavos procesan al paso mediante un circuito dedicado; no se conmuta ni se enruta, y meter un switch convencional dentro del segmento rompe el mecanismo. Otra diferencia de fondo está en el maestro: EtherCAT no exige tarjeta especial en el lado del control, porque el maestro es software sobre una interfaz Ethernet corriente, mientras que la clase isócrona de PROFINET necesita hardware preparado también en el lado del controlador. EtherCAT alcanza tiempos de ciclo en el rango de las decenas de microsegundos y sincronización entre nodos por debajo del microsegundo gracias a los relojes distribuidos.
Cómo se extraen los datos de un segmento EtherCAT
La primera restricción es estructural: un segmento EtherCAT tiene exactamente un maestro. No existe la figura del segundo cliente que se conecta a leer, como sí ocurre en redes basadas en TCP/IP. Por tanto, la vía natural es el propio maestro, que casi siempre es un PC industrial o un controlador con capacidad de exponer sus variables por OPC-UA o por una interfaz del fabricante. Es la ruta con mejor relación entre esfuerzo y datos obtenidos, y no toca el bus.
La captura pasiva sí es posible y tiene una particularidad favorable: como toda la información del segmento viaja en la misma trama, un TAP situado entre el maestro y el primer esclavo ve el tráfico completo, sin depender de dónde esté cada nodo. El problema es semántico. La trama transporta una imagen de proceso plana direccionada de forma lógica: los esclavos no viajan identificados por nombre, sino por posición y por rangos de direcciones que el maestro asignó al arrancar. Sin el fichero de configuración de red del maestro y los ficheros de descripción de los esclavos, lo capturado son bloques de bytes sin significado.
La segunda restricción es física y hay que planificarla: el segmento es una cadena. Insertar cualquier elemento en línea, incluido un TAP pasivo, interrumpe el anillo y detiene la máquina, salvo que la topología ya incluya derivadores y grupos configurados como Hot Connect, pensados precisamente para conectar y desconectar ramas en marcha. En la práctica, un punto de captura permanente se instala en parada programada.
Sobre latencia conviene invertir la pregunta habitual. EtherCAT entrega el dato mucho más rápido de lo que una capa de datos puede o necesita consumir; el diseño correcto no es transportar el ciclo de control hacia arriba, sino agregar y submuestrear en el maestro o en el equipo de borde y publicar solo lo que sostiene una decisión. Enviar una señal de ciclo de microsegundos a un histórico es un problema de coste, no una ventaja de resolución.
Relación con otros términos
EtherCAT compite en el mismo espacio que PROFINET y EtherNet/IP, y reutiliza el diccionario de objetos de CANopen como uno de sus protocolos de buzón, de ahí que muchos accionamientos se parametricen igual en ambos mundos. El dato acaba subiendo por OPC-UA desde el maestro o desde un nodo de edge computing. En Captia Connect es un caso de interoperabilidad de sistemas heterogéneos: leer la máquina sin intervenir en su lógica de control.