EtherCAT - el bus de campo Ethernet

Esta sección proporciona una introducción detallada a EtherCAT (Ethernet for Control Automation Technology). EtherCAT es una tecnología de Ethernet industrial en tiempo real desarrollada originalmente por Beckhoff Automation. El protocolo EtherCAT que se da a conocer en el estándar IEC61158 es adecuado para requisitos en tiempo real duros y blandos en la tecnología de automatización, en pruebas y mediciones y en muchas otras aplicaciones.

El enfoque principal durante el desarrollo de EtherCAT fue lograr tiempos de ciclo cortos (≤ 100 µs), jitter reducido para una sincronización precisa (≤ 1 µs) y bajos costes de hardware.

EtherCAT se introdujo en abril de 2003 y el EtherCAT Technology Group se fundó en noviembre de 2003. Entretanto, ETG se ha convertido en la organización de Ethernet industrial y bus de campo más grande del mundo. El ETG reúne a fabricantes y usuarios, que contribuyen en grupos de trabajo técnicos al avance de la tecnología EtherCAT.

1. Características de EtherCAT

1.1 Principio funcional
1.2 El protocolo EtherCAT
1.3 Topología flexible
1.4 EtherCAT P
1.5 Sincronización de alta precisión 
1.6 Diagnóstico y localización de errores
1.7 Requisitos de alta disponibilidad 
1.8 Safety over EtherCAT
1.9 Perfiles de comunicación 
1.9.1 Protocolo de aplicación CAN over EtherCAT (CoE) 
1.9.2 Perfil de servoaccionamiento, conforme a IEC 61800-7-204 (SoE) 
1.9.3 Ethernet over EtherCAT (EoE) 
1.9.4 File Access over EtherCAT (FoE)
1.9.5 ADS over EtherCAT (AoE)
1.10 Protocolo de automatización EtherCAT (EAP) 
1.11 Integración de otros sistemas de bus 
1.12 EtherCAT, TSN, Industrie 4.0 e IoT

2. Implementando interfaces EtherCAT

2.1 MainDevice
2.2 SubDevice

3. Conformidad y certificación 

3.1 Plug Fest
3.2 Herramienta de prueba de conformidad (CTT) 
3.3 Grupo de Trabajo Técnico de Conformidad 
3.4 Centro de prueba EtherCAT 

4. Normalización internacional 

 

 

 

1.1 Principio funcional 

El EtherCAT MainDevice envía un telegrama que pasa por cada nodo. Cada EtherCAT-SubDevice lee «sobre la marcha» los datos direccionados a él e inserta sus datos en la trama mientras la trama se mueve aguas abajo. El retardo de la trama se debe únicamente a los tiempos de retardo de propagación del hardware. El último nodo de un segmento (o línea de derivación) detecta un puerto abierto y envía el mensaje al MainDevice utilizando la función full duplex de la tecnología Ethernet.

La velocidad de datos efectiva máxima del telegrama aumenta a más del 90 % y, debido a la utilización de la función full duplex, la velocidad de datos efectiva teórica es incluso superior a 100 Mbit/s (> 90 % de dos veces 100 Mbit/s).

El MainDevice EtherCAT es el único nodo dentro de un segmento al que se le permite enviar activamente una trama EtherCAT; todos los demás nodos simplemente reenvían tramas aguas abajo. Este concepto evita retrasos impredecibles y garantiza capacidades en tiempo real.

El MainDevice utiliza un controlador de acceso al medio (MAC) Ethernet estándar sin un procesador de comunicaciones adicional. Esto permite implementar un MainDevice en cualquier plataforma de hardware con un puerto Ethernet disponible, independientemente del sistema operativo en tiempo real o del software de aplicaciones que se utilice. Los EtherCAT-SubDevices utilizan un controlador de SubDevices EtherCAT (ESC, del inglés EtherCAT Slave Controller) para procesar tramas sobre la marcha y totalmente en hardware, lo que hace que el rendimiento de la red sea predecible e independiente de la implementación del SubDevice individual.

1.2 El protocolo EtherCAT 

EtherCAT incrusta su carga útil en una trama Ethernet estándar. La trama se identifica con el identificador (0x88A4) en el campo EtherType. Dado que el protocolo EtherCAT está optimizado para datos de proceso de ciclos cortos, se puede eliminar el uso de pilas de protocolos, tales como TCP/IP o UDP/IP.

EtherCAT en una trama Ethernet estándar (conforme a IEEE 802.3)

Para garantizar la comunicación IT Ethernet entre los nodos, las conexiones TCP/IP se pueden tunelizar opcionalmente a través de un canal de buzón de correo sin afectar la transferencia de datos en tiempo real.

Durante el arranque, el equipo MainDevice configura y asigna los datos de proceso en los SubDevices. Se pueden intercambiar diferentes cantidades de datos con cada SubDevice, desde un bit hasta unos pocos bytes, o incluso hasta kilobytes de datos.

The EtherCAT frame contains one or more datagrams. The datagram header indicates what type of access the MainDevice would like to execute:

• lectura, escritura, lectura-escritura
• Acceso a un SubDevice específico mediante direccionamiento directo, o acceso a múltiples SubDevices mediante direccionamiento lógico (direccionamiento implícito)

El direccionamiento lógico se utiliza para el intercambio cíclico de datos de proceso. Cada datagrama direcciona una parte específica de la imagen de proceso en el segmento EtherCAT, para la cual están disponibles 4 GBytes de espacio de direcciones. Durante el arranque de la red, a cada SubDevice se le asignan una o más direcciones en este espacio global de direcciones. Si a varios SubDevices se les asignan direcciones en la misma área, todos pueden ser direccionados con un único datagrama. Puesto que los datagramas contienen completamente toda la información relacionada con el acceso a datos, el MainDevice puede decidir cuándo y a qué datos acceder. Por ejemplo, el MainDevice puede utilizar tiempos de ciclo cortos para actualizar datos en los accionamientos, mientras que utiliza un tiempo de ciclo más largo para muestrear las I/Os; no se requiere una estructura de datos de proceso fija. Esto también alivia el MainDevice en comparación con los sistemas de bus de campo convencionales, en los que los datos de cada nodo debían leerse individualmente, clasificarse con la ayuda del controlador de procesos y copiarse en la memoria.

Con EtherCAT, el MainDevice únicamente necesita llenar una sola trama EtherCAT con nuevos datos de salida y enviar la trama a través del Acceso Directo a Memoria (DMA, del inglés Direct Memory Access) al controlador MAC. Cuando se recibe una trama con nuevos datos de entrada a través del controlador MAC, el MainDevice puede volver a copiar la trama a través de DMA en la memoria del ordenador, todo ello sin que la CPU tenga que copiar activamente ningún dato. Además de los datos cíclicos, se pueden utilizar otros datagramas para comunicaciones asíncronas o impulsadas por eventos.

Inserción de datos de proceso sobre la marcha

Además del direccionamiento lógico, el equipo MainDevice también puede direccionar un SubDevice a través de su posición en la red. Este método se utiliza durante el arranque de la red para determinar la topología de la red y compararla con la topología planificada.

Después de comprobar la configuración de la red, el dispositivo MainDevice puede asignar a cada nodo una dirección de nodo configurada y comunicarse con el nodo a través de esta dirección fija. Esto permite un acceso específico a los dispositivos, incluso cuando se cambia la topología de la red durante el funcionamiento, por ejemplo, con grupos Hot Connect. Existen dos enfoques para la comunicación SubDevice-SubDevice. Un SubDevice puede enviar datos directamente a otro SubDevice que esté conectado aguas abajo en la red. Dado que las tramas EtherCAT sólo pueden procesarse hacia adelante, este tipo de comunicación directa depende de la topología de la red y es especialmente adecuada para la comunicación SubDevice-SubDevice en un diseño de máquina constante (por ejemplo, en máquinas de impresión o de embalaje). Por el contrario, la comunicación SubDevice-SubDevice libremente configurable pasa por el equipo MainDevice y requiere dos ciclos de bus (no necesariamente dos ciclos de control). Gracias al excelente rendimiento de EtherCAT, este tipo de comunicación SubDevice-SubDevice sigue siendo más rápido que con otras tecnologías de comunicación.

1.3 Topología flexible  

Lineal, en árbol, en estrella o cadena margarita: EtherCAT es compatible con prácticamente todas las topologías. EtherCAT hace posible una topología lineal o en bus pura con cientos de nodos sin las limitaciones que normalmente surgen de los conmutadores o hubs en cascada.

Al cablear el sistema, la combinación de líneas con íneas de caída o líneas de derivación es beneficiosa: los puertos necesarios para crear líneas de caída se integran directamente en muchos módulos de I/O, por lo que no se necesitan conmutadores adicionales ni componentes de infraestructura activos. También se puede utilizar naturalmente la topología clásica de Ethernet en estrella.

Las máquinas modulares o los cambiadores de herramientas requieren la conexión y desconexión de segmentos de red o nodos individuales durante el funcionamiento. Los controladores SubDevices EtherCAT ya incluyen la base para esta característica de Hot Connect. Si se elimina una estación vecina, el puerto se cierra automáticamente para que el resto de la red pueda seguir funcionando sin interferencias. Tiempos de detección muy cortos < 15 μs garantizan un cambio de formato fluido.

EtherCAT ofrece una gran flexibilidad en cuanto a los tipos de cable, por lo que cada segmento puede utilizar el tipo exacto de cable que mejor se adapte a sus necesidades. El económico cable Ethernet industrial puede utilizarse entre dos nodos con una separación de hasta 100 m en el modo 100BASE-TX. Además, la adición de protocolo EtherCAT P permite la transmisión de datos y energía a través de un solo cable. Esta opción permite la conexión de dispositivos tales como sensores con una sola línea. Fibras ópticas (como 100BASE-FX) también pueden utilizarse, por ejemplo, para distancias entre nodos superiores a 100 m. Toda la gama de cableados para Ethernet también está disponible para EtherCAT.

Topología flexible – lineal, en árbol o en estrella

Se pueden conectar hasta 65.535 dispositivos a un segmento EtherCAT, por lo que la ampliación de la red es prácticamente ilimitada. Dado el número prácticamente ilimitado de nodos, los dispositivos modulares como las estaciones de I/O «sliced» pueden diseñarse de tal forma que cada módulo sea propiamente un nodo EtherCAT. De esta manera se elimina el bus de extensión local; el alto rendimiento de EtherCAT llega directamente a cada módulo sin retrasos, ya que no hay puerta de enlace en el acoplador de bus ni en la cabecera.

1.4 EtherCAT P: comunicación y energía en un cable

EtherCAT P (P = potencia) es una adición al estándar de protocolo EtherCAT descrito anteriormente. No permite solo la transmisión de datos de comunicación, sino también la tensión periférica a través de un único cable Ethernet estándar de cuatro hilos.

EtherCAT y EtherCAT P son idénticos en términos de tecnología de protocolos, ya que la adición afecta exclusivamente a la capa física. No se requieren nuevos controladores de SubDevices EtherCAT cuando se utiliza EtherCAT P. Se podría decir que EtherCAT P tiene las mismas ventajas de comunicación que EtherCAT, pero también proporciona la fuente de alimentación a través del cable de comunicación, ofreciendo atractivas ventajas y mejoras para numerosas aplicaciones.

EtherCAT P: datos y energía a través de un cable

Dos fuentes de alimentación de 24V, aisladas eléctricamente y conmutables individualmente, alimentan los nuevos dispositivos EtherCAT P, disponibles con US para el sistema y los sensores y UP para la periferia y los actuadores. Ambas tensiones, US y UP, se encuentran directamente acopladas a la línea de comunicación EtherCAT de 100Mbit/s. Gracias a esta transmisión de energía, el usuario puede conectar en cascada varios dispositivos EtherCAT P y para ello solo necesita un cable. Esto permite reducir el cableado y diseñarlo de forma más compacta y rentable, ahorrar costes del sistema y espacio ocupado por los dispositivos, equipos y máquinas.

EtherCAT P es especialmente interesante para aquellas partes de una máquina que son independientes y a menudo se encuentran un poco aisladas, ya que pueden ser suministradas con datos y energía a través de un solo cable. Todos los tipos de sensores son perfectamente adecuados para EtherCAT P: un único conector M8 compacto permite la integración eficiente de estos dispositivos de campo en la red de alta velocidad y los conecta a la tensión de alimentación. Gracias a la codificación mecánica del conector, se evitan posibles fuentes de error durante la conexión de los dispositivos.

EtherCAT P puede utilizarse en la misma red junto con la tecnología EtherCAT estándar. Unidades rectificadoras adecuadas transforman el sistema físico común de EtherCAT en EtherCAT P manteniendo de forma consistente la codificación de datos Ethernet. De la misma manera, un dispositivo puede ser suministrado con EtherCAT P pero, a su vez, también puede transmitir el protocolo EtherCAT.
Leer más...

1.5 Distributed-Clocks para una sincronización de alta precisión  

En aplicaciones con procesos distribuidos espacialmente que requieren acciones simultáneas, la sincronización exacta es particularmente importante. Este es el caso por ejemplo en aplicaciones en las que varios servoejes ejecutan movimientos coordinados.

A diferencia de la comunicación completamente síncrona, cuya calidad sufre inmediatamente de errores de comunicación, los Distributed-Clocks sincronizados tienen un alto grado de tolerancia al jitter en el sistema de comunicación. Por eso, la solución EtherCAT para sincronizar nodos se basa en estos Distributed-Clocks (DC, relojes distribuidos).

Sincronización completamente basada en hardware con compensación de los retardos de propagación.

La calibración de los relojes en los nodos está completamente basada en hardware. La hora del primer SubDevice DC se distribuye cíclicamente a todos los demás dispositivos del sistema. Con este mecanismo, los relojes del SubDevice pueden ajustarse con precisión a este reloj de referencia. El jitter resultante en el sistema es significativamente menos de 1μs.

Dado que la hora enviada desde el reloj de referencia llega a los SubDevices con un ligero retardo, este retardo de propagación debe medirse y compensarse para cada SubDevice con el fin de asegurar la sincronicidad y simultaneidad. Este retardo se mide durante el arranque de la red o, si se desea, incluso de forma continua durante el funcionamiento, asegurando que los relojes sean simultáneos y cuenten con diferencias muy por debajo de 1μs entre ellos.

Sincronicidad y simultaneidad - Vista ampliada de dos dispositivos distribuidos con 300 nodos y una longitud de cable de 120 m

Si todos los nodos tienen la misma información horaria, pueden ajustar sus señales de salida simultáneamente y fijar sus señales de entrada con una marca de tiempo de alta precisión. En las aplicaciones de Motion Control, además de la sincronicidad y la simultaneidad, también es importante la precisión del ciclo. En este tipo aplicaciones, la velocidad se deriva típicamente de la posición medida, por lo que es crítico que las mediciones de posición se tomen de forma equidistante y precisa (es decir, en ciclos exactos). Incluso inexactitudes muy pequeñas en el tiempo de medición de la posición pueden traducirse en inexactitudes mayores en la velocidad calculada, especialmente en relación con tiempos de ciclo cortos. Con EtherCAT, las mediciones de posición son desencadenadas por el reloj local preciso y no por el sistema de bus, lo que conduce a una precisión mucho mayor.

Además, el uso de Distributed-Clocks también descarga el MainDevice. Puesto que acciones como la medición de posición son desencadenadas por el reloj local y no cuando se recibe la trama, el MainDevice no tiene requisitos tan estrictos para enviar tramas. Esto permite que el MainDevice stack se implemente en software en un hardware Ethernet estándar. Incluso un jitter en el rango de varios microsegundos no disminuye la precisión de los Distributed-Clocks. Dado que la precisión del reloj no depende de cuándo sea establecido, el tiempo absoluto de la transmisión de la trama se vuelve irrelevante. El MainDevice EtherCAT sólo necesita asegurarse de que el telegrama EtherCAT se envía con la suficiente antelación, antes de que la señal DC en los SubDevices desencadene la salida.

1.6 Diagnóstico y localización de errores  

La experiencia con sistemas de bus de campo convencionales ha demostrado que las características de diagnóstico juegan un papel importante en la determinación de la disponibilidad de una máquina y el tiempo de puesta en servicio. Además de la detección de errores, la localización de errores es importante durante la resolución de problemas. EtherCAT ofrece la posibilidad de analizar y comparar la topología real de la red con la topología planificada durante el arranque. EtherCAT también tiene muchas capacidades de diagnóstico adicionales inherentes a su sistema.

El controlador de SubDevices EtherCAT en cada nodo comprueba si hay errores en la trama en movimiento con una suma de comprobación. La información se proporciona a la aplicación del SubDevice únicamente si la trama se ha recibido correctamente. Si hay un error de bit, se incrementa el contador de errores y se informa a los nodos siguientes de que la trama contiene un error. El MainDevice también detectará que la trama tiene un fallo y descartará su información. El MainDevice es capaz de detectar dónde se produjo el fallo originalmente en el sistema analizando los contadores de errores de los nodos. Esto supone una enorme ventaja en comparación con los sistemas de bus de campo convencionales, en los que un error se propaga a lo largo de toda la línea, haciendo imposible localizar la fuente del error. EtherCAT puede detectar y localizar perturbaciones ocasionales antes de que el problema afecte la operación de la máquina.

Gracias al exclusivo principio de utilización del ancho de banda de EtherCAT, que es varias veces mejor que las tecnologías Ethernet industriales que utilizan tramas individuales, la probabilidad de perturbaciones inducidas por errores de bit dentro de una trama de EtherCAT es sustancialmente menor, si se utiliza el mismo tiempo de ciclo. Y, si se utilizan tiempos de ciclo mucho más cortos, como en el uso típico de EtherCAT, el tiempo requerido para la recuperación de errores se reduce significativamente. Por consiguiente, también es mucho más sencillo controlar estos problemas dentro de la aplicación.

Dentro de las tramas, el Working Counter permite supervisar la coherencia de la información en cada datagrama. Cada nodo que está direccionado por el datagrama y cuya memoria es accesible incrementa automáticamente el Working Counter. El MainDevice puede entonces confirmar cíclicamente si todos los nodos están trabajando con datos coherentes. Si el Working Counter tiene un valor diferente al que debería, el MainDevice no envía los datos de este datagrama a la aplicación de control. El MainDevice puede entonces detectar automáticamente la razón del comportamiento inesperado con ayuda de la información de estado y de error de los nodos, así como el estado del enlace.

Dado que EtherCAT utiliza tramas Ethernet estándar, el tráfico de red Ethernet se puede registrar con la ayuda de herramientas de software Ethernet gratuitas. Por ejemplo, el conocido software Wireshark viene con un intérprete de protocolo para EtherCAT, de modo que la información específica del protocolo, como el Working Counter, los comandos, etc., se muestran en texto sin formato.
Diagnóstico EtherCAT para usuarios
Diagnóstico EtherCAT para desarrolladores

1.7 Requisitos de alta disponibilidad  

En el caso de máquinas o equipos con requisitos de disponibilidad muy elevados, una rotura de cable o un mal funcionamiento de un nodo no debe significar que ya no se pueda acceder a un segmento de red o que falle toda la red.

EtherCAT permite la redundancia de cables con medidas sencillas. Conectando un cable desde el último nodo a un puerto Ethernet adicional en el MainDevice, una topología lineal se extiende a una topología en anillo. Un caso de redundancia, como una rotura de cable o un fallo de nodo, se detecta mediante un complemento de software en el MainDevice stack. ¡Eso es todo!

Los propios nodos no necesitan ser modificados y ni siquiera «saben» que están siendo operados en una red redundante.

Redundancia de cables económica con SubDevices EtherCAT estándar

La detección de enlaces en los SubDevices detecta y resuelve automáticamente los casos de redundancia con un tiempo de recuperación inferior a 15 μs, por lo que, como máximo, se interrumpe un único ciclo de comunicación. Esto significa que incluso las aplicaciones Motion con tiempos de ciclo muy cortos pueden seguir funcionando sin problemas cuando se rompe un cable.

Con EtherCAT, también es posible realizar la redundancia del MainDevice con Hot Standby. Los componentes vulnerables de la red, como los conectados a una cadena portacables, se pueden cablear con un cable de derivación, de modo que incluso cuando se rompe un cable, el resto de la máquina sigue funcionando.

1.8 Safety over EtherCAT 

Los sistemas de comunicación modernos no solo realizan la transferencia determinística de datos de control, sino que también permiten la transferencia de datos de control críticos para la seguridad a través del mismo medio. EtherCAT utiliza el protocolo Safety over EtherCAT (FSoE = Fail Safe over EtherCAT) para este propósito, permitiendo:

• Un único sistema de comunicación para los datos de control y de seguridad
• La capacidad de modificar y ampliar de forma flexible la arquitectura del sistema de seguridad
• Soluciones precertificadas para simplificar las aplicaciones de seguridad
• Potentes funciones de diagnóstico para funciones de seguridad
• Integración perfecta del diseño de seguridad en el diseño de la máquina
• La capacidad de utilizar las mismas herramientas de desarrollo tanto para aplicaciones estándar como de seguridad

Safety over EtherCAT permite arquitecturas más simples y flexibles que con la lógica de relés

La tecnología de seguridad EtherCAT ha sido desarrollada según el estándar IEC 61508, cuenta con la aprobación TÜV SÜD Rail y está estandarizada en IEC 61784-3. El protocolo es adecuado para aplicaciones de seguridad con un nivel de integridad de seguridad de hasta SIL 3.

Con Safety over EtherCAT, el sistema de comunicación forma parte de un llamado Black Channel (canal negro), que no se considera relevante para la seguridad. El sistema de comunicación estándar EtherCAT utiliza un único canal para transferir datos estándar y datos críticos para la seguridad. Las tramas de seguridad, conocidas como Safety Containers (contenedores de seguridad), contienen datos de proceso críticos para la seguridad e información adicional utilizada para proteger estos datos. Los contenedores de seguridad se transportan como parte de los datos de proceso de la comunicación. La seguridad de la transferencia de datos no depende de la tecnología de comunicación subyacente y no está restringida a EtherCAT; los contenedores de seguridad pueden viajar a través de sistemas de bus de campo, Ethernet o tecnologías similares y pueden hacer uso de cables de cobre, fibra óptica e incluso conexiones inalámbricas.

El contenedor de seguridad se encuentra incrustado en los datos de proceso de la comunicación cíclica

Gracias a esta flexibilidad, la conexión segura de diferentes partes de la máquina resulta más sencilla. El contenedor de seguridad es enrutado a través de los diferentes controladores y se procesa en las diferentes partes de la máquina. De este modo, las funciones de parada de emergencia de toda una máquina o de parada de partes específicas de una máquina son fáciles de realizar, incluso si las partes de la máquina están acopladas a otros sistemas de comunicación (p. ej., Ethernet).

La implementación del protocolo FSoE en un dispositivo requiere pocos recursos y puede conducir a un alto nivel de rendimiento y, en consecuencia, a tiempos de reacción cortos. En la industria robótica, existen aplicaciones que utilizan SoE para aplicaciones seguras de Motion Control en un lazo cerrado de 8 kHz.

Principio del Black Channel: se puede utilizar la interfaz de comunicación estándar

Más información sobre Safety over EtherCAT en la página web de ETG:
www.ethercat.org/safety

1.9 Perfiles de comunicación  

Para configurar y diagnosticar los SubDevices, es posible acceder a las variables proporcionadas para la red con la ayuda de la comunicación acíclica. Esto se basa en un protocolo de buzón de correo fiable con una función de recuperación automática de mensajes erróneos.

Para soportar una amplia variedad de dispositivos y capas de aplicación, se han establecido los siguientes perfiles de comunicación EtherCAT:

• Protocolo de aplicación CAN over EtherCAT (CoE)
• Perfil de servoaccionamiento, conforme a IEC 61800-7-204 (SoE)
• Ethernet over EtherCAT (EoE)
• File Access over EtherCAT (FoE)
• Automation Device Protocol over EtherCAT (ADS over EtherCAT, AoE)

Diferentes perfiles de comunicación pueden coexistir en el mismo sistema

No se requiere que un SubDevice soporte todos los perfiles de comunicación, en vez de ello, puede decidir qué perfil es el más adecuado para sus necesidades. Se notifica al MainDevice qué perfiles de comunicación se han implementado mediante el archivo de descripción del SubDevice.

1.9.1 Protocolo de aplicación CAN over EtherCAT (CoE)  

Con el protocolo CoE, EtherCAT proporciona los mismos mecanismos de comunicación que en el estándar CANopen® EN 50325-4: diccionario de objetos, asignación PDO (Process Data Objects, objetos de datos de proceso) y SDO (Service Data Objects, objetos de datos de servicio). Incluso la gestión de red es similar. Esto hace posible implementar EtherCAT con un mínimo esfuerzo en dispositivos que anteriormente estaban equipados con CANopen®. Incluso, grandes partes del firmware de CANopen® son reutilizables. Opcionalmente, se puede prescindir de la limitación PDO heredada de 8 bytes, y también es posible utilizar el ancho de banda mejorado de EtherCAT para soportar la carga de todo el Diccionario de objetos. Los perfiles de dispositivo, como el perfil de accionamiento CiA 402, también se pueden reutilizar para EtherCAT.

1.9.2 Perfil de servoaccionamiento, conforme a IEC 61800-7-204 (SoE)  

SERCOS™ es una interfaz de comunicación en tiempo real, especialmente para aplicaciones de Motion Control. El perfil SERCOS™ para servoaccionamientos está incluido el estándar internacional IEC 61800-7. El estándar también contiene la asignación de este perfil a EtherCAT. El canal de servicio, incluido el acceso a todos los parámetros y funciones internas del accionamiento, se asigna al buzón de correo de EtherCAT.

1.9.3 Ethernet over EtherCAT (EoE) 

EtherCAT utiliza las capas físicas de Ethernet y la trama Ethernet. El término Ethernet también se asocia frecuentemente con la transferencia de datos en aplicaciones de IT, que se basan en una conexión TCP/IP.

Transmisión transparente de protocolos de IT estándar

Mediante el protocolo Ethernet over EtherCAT (EoE) se puede transportar cualquier tráfico de datos Ethernet dentro de un segmento EtherCAT. Los dispositivos Ethernet se conectan a un segmento EtherCAT a través de los denominados Switchports. Las tramas Ethernet se tunelizan a través del protocolo EtherCAT, de forma similar a los protocolos de Internet (p. ej. TCP/IP, VPN, PPPoE (DSL), etc.), lo que hace que la red EtherCAT sea completamente transparente para dispositivos Ethernet. El dispositivo con la propiedad Switchport se encarga de insertar fragmentos TCP/IP en el tráfico EtherCAT y por lo tanto evita que las propiedades en tiempo real de la red se vean afectadas.

Adicionalmente, los dispositivos EtherCAT también pueden soportar protocolos Ethernet (como HTTP) y, por lo tanto, comportarse como un nodo Ethernet estándar fuera del segmento EtherCAT. El MainDevice actúa como un conmutador de capa 2 que envía las tramas a través de EoE a los nodos correspondientes según sus direcciones MAC. De esta manera, todas las tecnologías de internet también se pueden implementar en un entorno EtherCAT, como un servidor web integrado, correo electrónico, transferencia FTP, etc.

1.9.4 File access over EtherCAT (FoE) 

Este sencillo protocolo, similar al TFTP (Trivial File Transfer Protocol), permite el acceso a archivos en un dispositivo y la carga uniforme de firmware a los dispositivos en toda la red. El protocolo se ha especificado deliberadamente de forma simple, para que pueda ser soportado por programas del gestor de arranque - no se requiere una pila TCP/IP.

1.9.5 ADS over EtherCAT (AoE) 

Como protocolo cliente-servidor basado en buzón de correo, ADS over EtherCAT (AoE) está definido por la especificación EtherCAT. Mientras que protocolos como el protocolo de aplicación CAN over EtherCAT (CoE) proporcionan un concepto semántico detallado, AoE los complementa perfectamente a través de servicios enrutables y paralelos dondequiera que los casos de uso lo requieran. Por ejemplo, esto podría incluir el acceso a subredes a través de EtherCAT utilizando dispositivos de puerta de enlace de un programa de PLC como CANopen®, IO-Link™ y otros.

AoE tiene una sobrecarga mucho menor en comparación con servicios similares proporcionados por el protocolo de internet (IP). El telegrama AoE contiene siempre tanto los parámetros de direccionamiento del emisor como del receptor, por lo que es posible una implementación muy sencilla en ambos extremos (cliente y servidor). AoE es también el protocolo de elección para la comunicación acíclica mediante el protocolo de automatización EtherCAT (EAP, del inglés EtherCAT Automation Protocol) y, por lo tanto, proporciona una comunicación fluida entre un sistema MES, el EtherCAT y los dispositivos de bus de campo subordinados conectados a través de puertas de enlace. AoE sirve como el medio estándar para obtener información de diagnóstico de red EtherCAT de una herramienta de diagnóstico remoto.

1.10 Comunicación a nivel de toda la planta con el protocolo de automatización EtherCAT (EAP)  

El nivel de gestión de procesos tiene requisitos de comunicación especiales que difieren ligeramente de los requisitos tratados por el protocolo de dispositivos EtherCAT, descritos en las secciones anteriores. Las máquinas o secciones de una máquina a menudo necesitan intercambiar información de estado e información sobre los siguientes pasos de fabricación entre sí. Además, suele haber un controlador central que supervisa todo el proceso de fabricación, que proporciona al usuario información sobre el estado de la productividad y asigna los pedidos a las distintas estaciones de la máquina. El protocolo de automatización EtherCAT (EAP) cumple todos los requisitos anteriores.

Comunicación en toda la fábrica con EtherCAT

El protocolo define interfaces y servicios para:

• Intercambio de datos entre EtherCAT-MainDevices (comunicación MainDevice-MainDevice),
• Comunicación a Interfaces Hombre-Máquina (HMI, del inglés Human Machine Interfaces),
• Un controlador de supervisión para acceder a los dispositivos que pertenecen a los segmentos EtherCAT subyacentes (enrutamiento),
• Integración de herramientas para la configuración de la máquina o planta, así como para la configuración del dispositivo.

Arquitectura de comunicaciones en toda la fábrica con el Protocolo de Automatización EtherCAT y Safety over EtherCAT

Los protocolos de comunicaciones utilizados en EAP forman parte del estándar internacional IEC 61158. EAP puede transmitirse a través de cualquier conexión Ethernet, incluyendo un enlace inalámbrico, por ejemplo, haciendo posible incluir vehículos de guiado automático (AGV, del inglés automated guided vehicles), que son comunes en la industria de los semiconductores y la automoción.

El intercambio cíclico de datos de proceso con EAP sigue el principio «Push» o «Poll». En el modo «Push», cada nodo envía sus datos con su propio tiempo de ciclo o como múltiplo del propio tiempo de ciclo. Cada receptor puede configurarse para recibir datos de emisores específicos. La configuración de los datos de emisor y receptor se realiza a través del conocido Diccionario de objetos. En el modo «Poll», un nodo (a menudo el controlador central) envía un telegrama a los otros nodos, y cada nodo responde con su propio telegrama.

La comunicación EAP cíclica se puede incrustar directamente en la trama Ethernet, sin necesidad de protocolos adicionales de transporte o enrutamiento. Nuevamente, el EtherType Ox88A4 identifica el uso específico EtherCAT de la trama. Esto permite el intercambio de datos de alto rendimiento con EAP en un ciclo de milisegundos. Si se requiere un enrutamiento de datos entre máquinas distribuidas, los datos de proceso también se pueden transmitir a través de UPD/IP o TCP/IP.

Adicionalmente, con la ayuda del protocolo Safety over EtherCAT, también es posible transmitir datos críticos para la seguridad a través de EAP. Esto es común en los casos en los que partes de una máquina grande necesitan intercambiar datos críticos de seguridad para realizar una función de parada de emergencia global, o para informar a las máquinas vecinas de una parada de emergencia.

1.11 Integración de otros sistemas de bus  

El amplio ancho de banda de EtherCAT permite integrar redes de bus de campo convencionales como sistema subyacente a través de una puerta de enlace EtherCAT, lo que resulta especialmente útil a la hora de migrar de un bus de campo convencional a EtherCAT. El cambio a EtherCAT es gradual, lo que permite seguir utilizando componentes de automatización que aún no admiten una interfaz EtherCAT.

Interfaces de bus de campo descentralizadas

La capacidad de integrar puertas de enlace descentralizadas también reduce el tamaño físico del PC industrial, a veces incluso a un PC industrial embebido, ya que las ranuras de extensión ya no son necesarias. En el pasado, también se necesitaban ranuras de extensión para conectar dispositivos complejos, tales como puertas de enlace de MainDevices y SubDevices de bus de campo, interfaces de serie rápidas y otros subsistemas de comunicación. En EtherCAT, todo lo que se necesita para conectar estos dispositivos es un único puerto Ethernet. Los datos de proceso del subsistema subyacente están disponibles directamente en la imagen de proceso del sistema EtherCAT.

1.12 Potenciando la transformación digital con EtherCAT, TSN, Industrie 4.0 e IoT  

Optimización de procesos, Predictive Maintenance, fabricación como servicio, sistemas adaptativos, ahorro de recursos, fábricas inteligentes, reducción de costes - hay innumerables razones para utilizar datos de redes de control en sistemas de alto nivel. Internet of Things (IoT), Industrie 4.0, Made in China 2025, Industrial Value Chain Initiative: existe la necesidad común de una comunicación fluida, continua y estandarizada en todos los niveles. Datos de sensores cargados a la nube junto con fórmulas y parámetros descargados de sistemas ERP en dispositivos distribuidos; tómese como ejemplo un sistema de alimentación compartido por dos máquinas: hay requisitos de flujo de datos tanto en dirección vertical como en dirección horizontal. EtherCAT cumple intrínsecamente los requisitos de la transformación digital a través de su alto rendimiento, flexibilidad e interfaces abiertas: Un rendimiento superior del sistema es el requisito previo para agregar funciones de Big Data a las redes de control.

EtherCAT proporciona la flexibilidad para añadir conectividad en la nube a sistemas existentes sin siquiera «tocar» el controlador o actualizar los SubDevices: Los Edge Gateways pueden acceder a cualquier dato dentro de cualquier EtherCAT-SubDevice a través de la función Mailbox Gateway del EtherCAT-MainDevice. El Edge Gateway puede ser un dispositivo remoto, hablando con el MainDevice a través de TCP o UDP/IP, o una entidad de software ubicada directamente en el mismo hardware que el propio EtherCAT-MainDevice.

Adicionalmente, las interfaces abiertas permiten integrar cualquier protocolo basado en IT - incluyendo OPC UA, MQTT, AMQP o cualquier otro - ya sea dentro del MainDevice o directamente en los SubDevices, proporcionando así un enlace directo para IoT sin discontinuidades de protocolo desde el sensor hasta la nube.

Todas estas características siempre han formado parte del protocolo EtherCAT, lo que demuestra lo avanzada que es su arquitectura. No obstante, funciones de red adicionales se añaden a medida que evolucionan y adquieren relevancia. Por supuesto, también es importante tener en cuenta el pasado a la hora de mirar hacia el futuro: esta introducción de nuevas y valiosas características se gestiona con total continuidad de la red, ya que el propio protocolo EtherCAT ha permanecido estable en la «Versión 1» desde su introducción en 2003.

Otros nuevos desarrollos en el área de las funciones de redes sensibles al tiempo (TSN, del inglés Time Sensitive Networking) mejoran aún más las capacidades en tiempo real de la comunicación controlador a controlador. Habilitados por TSN, los sistemas de control, incluso los basados en la nube, pueden acceder a una red de EtherCAT-SubDevices, también en redes de planta. Puesto que EtherCAT solo necesita una trama para toda una red, este tipo de acceso es mucho más sencillo y, por tanto, más rápido que cualquier otro bus de campo o tecnología Ethernet industrial. De hecho, los expertos del EtherCAT Technology Group han contribuido activamente desde el primer día en el grupo de trabajo de TSN del IEEE 802.1, en un momento en que TSN todavía era conocido como AVB.

El EtherCAT Technology Group (ETG) también fue una de las primeras organizaciones de bus de campo en asociarse con la Fundación OPC. El protocolo OPC UA complementa la gama EtherCAT porque es una tecnología de comunicación cliente/servidor escalable basada en TCP/IP con seguridad integrada, lo que permite la transferencia de datos cifrados hasta sistemas MES/ERP. Con OPC UA Pub/Sub, se ha mejorado la usabilidad de OPC UA en aplicaciones máquina a máquina (M2M) y para la comunicación vertical con servicios basados en la nube. El ETG está contribuyendo activamente a todos estos desarrollos para garantizar que se adapten perfectamente en el entorno EtherCAT.

Por lo tanto, se puede decir que EtherCAT no solo está preparado para el IoT, sino que EtherCAT es IoT.

 

 

La tecnología EtherCAT ha sido especialmente optimizada para permitir un diseño económico, de forma que añadir una interfaz EtherCAT a un sensor, dispositivo I/O o controlador integrado no debería aumentar significativamente los costes del dispositivo. Además, la interfaz EtherCAT tampoco requiere una CPU más potente. Por el contrario, los requisitos de la CPU se basan únicamente en las necesidades de la aplicación objetivo.

Además de los requisitos de hardware y software, para el desarrollo de una interfaz también son importantes el soporte de desarrollo y la disponibilidad de pilas de comunicación. El EtherCAT Technology Group ofrece soporte de desarrollo en todo el mundo, respondiendo rápidamente a las consultas y abordando los problemas técnicos. Finalmente, existen kits de evaluación de múltiples fabricantes, talleres para desarrolladores y códigos de muestra gratuitos para facilitar el inicio.

Para el usuario final, el factor más importante es la interoperabilidad de los dispositivos EtherCAT de varios fabricantes. Para asegurar la interoperabilidad, se solicita a los fabricantes de dispositivos que realicen una prueba de conformidad antes de lanzar los dispositivos al mercado. La prueba comprueba si la implementación es acorde a la especificación EtherCAT y se puede realizar con la Herramienta de prueba de conformidad EtherCAT. La prueba también se puede utilizar durante el desarrollo del dispositivo para descubrir y corregir tempranamente cualquier problema de implementación.

2.1 MainDevice 

La interfaz para un EtherCAT-MainDevice tiene un único requisito de hardware, increíblemente simple: un puerto Ethernet. La implementación utiliza o bien un controlador Ethernet integrado o una tarjeta de red estándar y económica, por lo que no requiere una tarjeta de interfaz especial. Esto significa que, con tan solo un puerto Ethernet estándar, un MainDevice puede implementar una solución de red en tiempo real compleja.

En la mayoría de los casos, el controlador Ethernet está integrado mediante Acceso directo a memoria (DMA; del inglés Direct Memory Access), por lo que no se requiere capacitad de la CPU para la transferencia de datos entre el MainDevice y la red. En una red EtherCAT, la asignación tiene lugar en los SubDevices. Cada SubDevice escribe sus datos en la ubicación correcta de la imagen de proceso y lee los datos direccionados a él mientras la trama lo atraviesa. Por lo tanto, la imagen de proceso que llega al MainDevice ya está correctamente clasificada.

Puesto que la CPU del MainDevice ya no es responsable de la clasificación, sus requisitos de rendimiento dependen únicamente de la aplicación deseada y no de la interfaz EtherCAT. Especialmente para aplicaciones pequeñas, medianas y claramente definidas, la implementación de un EtherCAT-MainDevice es muy sencilla. Los EtherCAT-MainDevices han sido implementados para una amplia variedad de sistemas operativos: Windows y Linux en varias iteraciones, QNX, RTX, VxWorks, Intime y eCos son tan solo algunos ejemplos.

Arquitectura típica de MainDevice EtherCAT

Los miembros del ETG ofrecen una variedad de opciones para soportar la implementación de un EtherCAT-MainDevice, desde descargas gratuitas de bibliotecas MainDevice EtherCAT y códigos de MainDevices de muestra hasta paquetes completos (incluyendo servicios) para varios sistemas operativos en tiempo real y CPU.

Para operar una red, el EtherCAT-MainDevice requiere la estructura de datos de proceso cíclica, así como comandos de arranque para cada SubDevice. Estos comandos se pueden exportar a un archivo de Información de red EtherCAT (ENI, del inglés EtherCAT Network Information) con la ayuda de una herramienta de configuración EtherCAT que utiliza archivos de Información de SubDevice EtherCAT (ESI, del inglés EtherCAT SubDevice Information) de los dispositivos conectados.

La amplitud de implementaciones de MainDevices disponibles y sus funciones soportadas varían. Dependiendo de la aplicación objetivo, las funciones opcionales están soportadas o se omiten intencionadamente para optimizar el uso de los recursos de hardware y software. Por esta razón, los MainDevices EtherCAT se clasifican en dos clases: un MainDevice Clase A es un MainDevice EtherCAT estándar, mientras un MainDevice Clase B es un MainDevice con menos funciones. En principio, todas las implementaciones del MainDevices deben tener como objetivo una clasificación Clase A. La Clase B solo se recomienda para casos en los que los recursos disponibles son insuficientes para soportar todas las funcionalidades, tal como en sistemas integrados.

2.2 SubDevice

Los SubDevices EtherCAT utilizan Controladores de SubDevices EtherCAT (ESC, del inglés EtherCAT SubDevice Controllers) económicos en forma de un ASIC, una FPGA o integrados en un microcontrolador estándar. Los SubDevices simples ni siquiera necesitan un microcontrolador adicional porque las entradas y las salidas se pueden conectar directamente al ESC. Para SubDevices más complejos, el rendimiento de comunicación depende solo mínimamente del rendimiento del microcontrolador y, en la mayoría de los casos, un microcontrolador de 8 bits es suficiente.

Los Controladores de SubDevices EtherCAT están disponibles de múltiples fabricantes, con tamaños de DPRAM interna y números de Unidades de gestión de memoria de bus de campo (FMMUs, del inglés Fieldbus Memory Management Units) en función del modelo. También hay disponibles diferentes Interfaces de datos de proceso (PDI, del inglés Process Data Interfaces) para el acceso externo desde el controlador de la aplicación a la memoria de la aplicación:

• La interfaz I/O paralela de 32 bits es adecuada para conectar hasta 32 entradas y salidas digitales, pero también para sensores o actuadores simples para los cuales es suficiente con 32 bits de datos y no se requiere un controlador de aplicación.
• La Interfaz periférica serial (SPI, del inglés Serial Peripheral Interface) está prevista para aplicaciones con pequeñas cantidades de datos de proceso, como dispositivos I/O analógicos, codificadores o accionamientos simples.
• La interfaz de microcontrolador paralela de 8/16 bits equivale a las interfaces comunes de controladores de bus de campo con DPRAM integrada. Es particularmente adecuada para nodos complejos con grandes cantidades de datos.
• Se han implementado buses sincrónicos adecuados para varios microcontroladores para variaciones FPGA y on-Chip.

Hardware del SubDevice: Controlador de Ethercat-SubDevice con CPU host

La configuración de hardware está guardada en una memoria no volátil (por ejemplo, EEPROM), la Interfaz de información de SubDevice (SII, del inglés SubDevice Information Interface), que contiene información sobre las características básicas del dispositivo, de forma que el MainDevice puede leerla durante el arranque y operar el dispositivo, incluso si no está disponible el archivo de descripción del dispositivo. El archivo de Información de SubDevice EtherCAT (ESI) que viene con el dispositivo está basado en XML y contiene la descripción completa de las propiedades accesibles por la red, tales como datos de proceso y sus opciones de asignación, los protocolos de buzón de correo soportados, incluyendo características opcionales, así como los modos de sincronización soportados. La Herramienta de configuración de red utiliza esta información para la configuración online y offline de la red.

SubDevice Hardware: EtherCAT SubDeviceController with Host CPU

Varios fabricantes ofrecen kits de evaluación para implementar SubDevices. Estos kits incluyen software de aplicaciones de SubDevice en código fuente y a veces también un MainDevice de prueba. Utilizando un kit de evaluación es posible poner en marcha una red EtherCAT MainDevice-SubDevice completamente funcional en unos pocos pasos. La página web del ETG contiene una Guía de Implementación de SubDevices con consejos y sugerencias útiles sobre documentación adicional para la implementación de SubDevices:
Guía de Implementación de Esclavos ETG.2200 EtherCAT y EtherCAT P

 

Dos factores importantes para un estándar de comunicación exitoso son la conformidad y la interoperabilidad. Además de requerir una prueba de conformidad para cada implementación de dispositivo (con la ayuda de la Herramienta de prueba de conformidad EtherCAT automatizada), el EtherCAT Technology Group ofrece una variedad de actividades para garantizar la interoperabilidad entre los MainDevices EtherCAT, los SubDevices y también la Herramienta de configuración EtherCAT.
Read more...

3.1 Plug Fest 

Cuando se intenta probar si múltiples dispositivos son interoperables, la conexión de los dispositivos entre sí resulta un enfoque pragmático. Teniendo esto en cuenta, el ETG organiza varias de las denominadas Plug Fests cada año, que habitualmente tienen una duración de dos días. Durante las Plug Fests, los fabricantes de MainDevices y SubDevices se reúnen para probar si sus dispositivos pueden funcionar juntos, lo que permite mejorar la usabilidad de los dispositivos en el campo. El ETG realiza Plug Fests regularmente en Europa, Norteamérica y Asia.
Leer más...

3.2 Herramienta de prueba de conformidad (CTT)  

La Herramienta de prueba de conformidad EtherCAT (CTT) permite probar automáticamente el comportamiento de un EtherCAT-SubDevice. La CTT es un programa de Windows que únicamente requiere un puerto Ethernet estándar. La herramienta envía tramas EtherCAT al Dispositivo en prueba (DuT, del inglés Device under Test) y recibe sus respuestas. Un caso de prueba se marca como superado si la respuesta del DuT corresponde a la respuesta definida. Los casos de prueba están definidos como archivos XML. Esto permite modificar o expandir los casos de prueba sin tener que modificar la propia herramienta de prueba. El TWG de Conformidad es responsable de especificar y publicar los casos de prueba válidos más actuales. Además de las pruebas de protocolo, la CTT también examine si los valores del archivo de Información de SubDevice EtherCAT (ESI, del inglés EtherCAT SubDevice Information) son válidos. Finalmente, la CTT también realiza pruebas de protocolo específicas del dispositivo, como para el perfil de accionamiento CiA402. Todos los pasos y los resultados de la prueba son guardados en un registro de la prueba (Test Logger) y pueden ser analizados o guardados como verificación documentada de la aprobación del dispositivo.
Leer más...

3.3 Grupo de Trabajo Técnico de Conformidad  

La Política de prueba de conformidad EtherCAT exige a los fabricantes de dispositivos probar cada dispositivo con una versión válida de la Herramienta de prueba de conformidad EtherCAT antes de lanzar el dispositivo al mercado. El fabricante debe realizar esta prueba internamente. El Comité Técnico (TC, del inglés Technical Committee) del ETG estableció un Grupo de Trabajo Técnico (TWG, del inglés Technical Working Group) de Conformidad que determina los procedimientos de prueba, los contenidos de la prueba y la implementación de la Herramienta de prueba de conformidad. El TWG de conformidad expande continuamente la prueba y su alcance. El TWG de conformidad también establece el proceso de prueba de interoperabilidad, con el cual los dispositivos pueden ser probados en el contexto de una red completa.
Leer más...

3.4 Centro de prueba EtherCAT  

Los Centros de prueba EtherCAT (ETC, del inglés EtherCAT Test Center) oficiales en Europa, Asia y Norteamérica están acreditados por el ETG y realizan la Prueba de conformidad EtherCAT oficial. La Prueba de conformidad EtherCAT incluye las pruebas automatizadas realizadas con la CTT, pruebas de interoperabilidad dentro de una red, así como un examen de los indicadores del dispositivo, marcado y pruebas de las interfaces EtherCAT.

Se recomienda a los fabricantes de dispositivos, aunque no es obligatorio, que sus dispositivos sean probados en un ETC. Tras superar la Prueba de conformidad, el fabricante recibe un certificado de Conformidad EtherCAT probada para su dispositivo. Este certificado solo está disponible para dispositivos que han superado la Prueba de conformidad en un ETC, no para aquellos que han sido probados internamente.

La prueba adicional en un Centro de prueba EtherCAT acreditado aumenta además la compatibilidad y la operación y el diagnóstico uniformes de las implementaciones EtherCAT. Los usuarios finales deberían solicitar los Certificados de conformidad EtherCAT probada cuando eligen dispositivos para sus aplicaciones.
Leer más...

 

El EtherCAT Technology Group es un socio oficial de la IEC. Tanto EtherCAT como Safety over EtherCAT son estándares IEC (IEC 61158 e IEC 61784). Estos estándares no solo incluyen las capas de protocolo inferiores, sino también la capa de aplicación y perfiles de dispositivo, por ejemplo, para accionamientos. SEMI™ (Semiconductor Equipment and Materials International) ha aceptado EtherCAT como estándar de comunicación (E54.20) para la industria de los semiconductores. Los Grupos de trabajo en el Grupo de Trabajo Técnico (TWG) de Semiconductores del ETG han definido perfiles de dispositivo específicos de la industria y guías de implementación. La especificación EtherCAT está disponible en inglés, japonés, coreano y chino.