PROFINET, EtherNet/IP, EtherCAT, OPC UA y MQTT: función de cada protocolo

En resumen:

Utiliza

PROFINET, EtherNet/IP o EtherCAT

cuando un PLC o controlador de movimiento deba intercambiar datos de proceso cíclicos y previsibles con un robot, variador o dispositivo de E/S. Elige

OPC UA

si el software de supervisión necesita información de máquina estructurada y

MQTT

si hay que distribuir eventos y telemetría entre varias aplicaciones mediante un bróker de publicación/suscripción. No son tecnologías intercambiables: una misma fábrica puede emplear varias a la vez. Para elegir, importan más los controladores disponibles, las interfaces y licencias instaladas, los flujos de datos y las consecuencias de una pérdida de comunicación que una velocidad anunciada.

Guía de ingeniería actualizada el 13 de octubre de 2026. Comparación basada en normas y documentación técnica; no es un ensayo de laboratorio ni una certificación de compatibilidad entre modelos concretos de robot y PLC.

Respuesta rápida: ¿qué protocolo de comunicación industrial elegir?

Regla práctica:

elige un protocolo

para cada interfaz

, no uno para toda la fábrica. Por ejemplo, el PLC puede controlar el robot mediante PROFINET, mientras un gateway lee OPC UA y publica eventos seleccionados por MQTT.

Por qué utilizar Ethernet no significa hacer el mismo trabajo

Ethernet industrial engloba tecnologías distintas, no un sistema universal de comunicaciones. Compartir un conector tipo RJ45, cable Ethernet o parte de la infraestructura no implica que dos equipos se entiendan. Cambian los roles, las pilas de protocolos, los mecanismos temporales, el direccionamiento y los datos de aplicación.

La diferencia esencial está entre

datos de control cíclicos

e

información de supervisión

. Los primeros se actualizan de forma repetitiva para que el controlador ejecute la secuencia de máquina con entradas y salidas actuales. La segunda llega a aplicaciones que necesitan contexto e histórico, como MES, SCADA, mantenimiento o analítica.

Un robot puede necesitar una nueva palabra de mando del PLC en cada intervalo de E/S configurado. A un cuadro de producción quizá solo le interese cuándo empieza o termina una pieza y cuándo aparece una avería. Enviar esos eventos mediante el mapa cíclico complica la integración; utilizar un mensaje MQTT ordinario como único enclavamiento temporal crítico es un error de arquitectura.

Determinismo no significa simplemente velocidad.

En control importan la previsibilidad y los límites temporales, además del caudal medio. La respuesta real suma el tiempo de actualización de la red, la tarea del PLC, el procesamiento del controlador del robot y la lógica de aplicación. Una red rápida no corrige una secuencia mal diseñada.

1. PROFINET: control cíclico en instalaciones basadas en PLC

PROFINET

, mantenido por PROFIBUS & PROFINET International (PI), está orientado a la automatización industrial, con datos de proceso cíclicos, diagnósticos e integración de ingeniería. En una arquitectura habitual, el PLC es el

IO-Controller

y el robot o estación de E/S remotas actúa como

IO-Device

. Ambos intercambian las entradas y salidas configuradas.

Cómo funciona PROFINET

PROFINET admite comunicación en tiempo real para E/S cíclicas. Entre las modalidades conocidas figuran

RT (Real Time)

, utilizada en muchas aplicaciones generales, e

IRT (Isochronous Real Time)

, para necesidades de sincronización más exigentes cuando los equipos la admiten. PI también desarrolla capacidades relacionadas con Time-Sensitive Networking (TSN). No basta con marcar una casilla: hay que comprobar la función en el controlador, dispositivo, firmware y diseño de red reales.

Además de las E/S cíclicas se utilizan identificación de dispositivos, alarmas, diagnósticos y parametrización. La integración suele partir de un archivo

GSDML

, una descripción XML de PROFINET que indica módulos, tamaños de datos y funciones disponibles para el software de ingeniería.

Ejemplo: PLC y robot mediante PROFINET

El PLC puede enviar autorización de funcionamiento, número de programa y petición de arranque; el robot devuelve preparado, ocupado, completado y fallo. El contrato de señales define cada bit, quién lo controla y cómo recuperar una secuencia interrumpida. PROFINET transporta los bytes, pero

no define la lógica de handshake del fabricante del robot

.

Cuándo utilizar PROFINET:

cuando la planta ya lo utiliza, el controlador del robot dispone del rol IO-Device necesario y el entorno de ingeniería del PLC admite el GSDML y la configuración de E/S correctos. No supongas que tener PROFINET incluye PROFIsafe, IRT o funciones de movimiento.

2. EtherNet/IP: control basado en CIP mediante redes Ethernet/IP

EtherNet/IP

, mantenido por ODVA, transporta

Common Industrial Protocol (CIP)

sobre tecnologías estándar de Ethernet e Internet. Sirve para intercambiar E/S y diagnósticos. Aunque el nombre se parezca, no es una conexión Ethernet genérica ni es compatible automáticamente con PROFINET.

E/S cíclicas frente a mensajes explícitos

CIP distingue el intercambio de E/S, llamado habitualmente

implicit messaging

, del acceso a objetos mediante petición/respuesta, denominado

explicit messaging

. Para las E/S cíclicas se emplea habitualmente UDP y para los mensajes explícitos, TCP. Las conexiones intercambian assemblies de bytes cuyo significado depende del modelo de datos y la configuración del equipo.

En una relación PLC–robot, normalmente el PLC actúa como

I/O scanner

y la interfaz del robot como

adapter

. Los nombres y modos admitidos varían según fabricante y generación. El archivo

EDS (Electronic Data Sheet)

ayuda a configurar el dispositivo, pero también hay que verificar las instancias de assembly, longitud de entradas y salidas, ruta de conexión y

RPI

(intervalo de paquetes solicitado). El EDS, por sí solo, no garantiza una integración automática y completa.

ODVA define asimismo CIP Safety, CIP Motion, CIP Sync y CIP Security. Que formen parte de la familia

no demuestra que un controlador de robot concreto los admita

.

Cuándo utilizar EtherNet/IP:

cuando la arquitectura del PLC se basa en CIP, el robot o útil dispone del rol adapter correcto y se verifican tamaño, mapeado y actualización de la conexión. Un ping solo demuestra conectividad IP, no que exista un intercambio cíclico de E/S.

3. EtherCAT: procesamiento al vuelo y dispositivos sincronizados

EtherCAT

, promovido por EtherCAT Technology Group (ETG), utiliza otro método. Un

MainDevice

envía una trama por el segmento, y cada

SubDevice

lee sus datos de salida e inserta los de entrada mientras la trama circula. Este procesamiento

on-the-fly

reduce intercambios repetitivos por dispositivo y resulta útil en control distribuido exigente.

Por qué EtherCAT no es TCP/IP convencional

Las tramas habituales de datos de proceso EtherCAT emplean Ethernet y normalmente se identifican mediante EtherType

0x88A4

.

No son paquetes TCP o UDP convencionales.

Un switch de oficina, router IP o bróker MQTT no pasa automáticamente a formar parte de un segmento EtherCAT válido. Topología y hardware deben seguir los requisitos reales del sistema.

El mecanismo

Distributed Clocks (DC)

permite sincronizar dispositivos compatibles, especialmente servovariadores y otros sistemas de movimiento distribuido. Esa capacidad no significa que cualquier robot conectado consiga automáticamente movimiento coordinado.

La configuración suele utilizar archivos XML

ESI (EtherCAT SubDevice Information)

. Hay que comprobar objetos de proceso, estados operativos, modos de sincronización, compatibilidad del puerto físico y firmware. También puede ser necesaria una implementación específica del fabricante.

Cuándo utilizar EtherCAT:

cuando la plataforma de máquina está diseñada alrededor de EtherCAT, la sincronización o el movimiento distribuido justifican su uso y todos los equipos —incluida la interfaz del robot— admiten los roles y funciones exigidos. No elijas EtherCAT solo porque una cifra de ciclos resulte atractiva.

4. OPC UA: información de máquina con estructura y significado

OPC Unified Architecture (OPC UA)

, de OPC Foundation, es una arquitectura de comunicación industrial independiente de la plataforma. Permite representar equipos, propiedades, relaciones y métodos mediante un modelo de información que las aplicaciones pueden explorar y comprender. Habitualmente emplea cliente/servidor; también contempla publicación/suscripción en implementaciones compatibles. Incluye mecanismos de autenticación, cifrado y autorización.

Por qué importa el modelado de información

Imagina que un MES necesita conocer el modo de funcionamiento, programa seleccionado, alarma activa y contador de piezas de un robot. Un array bruto de E/S del PLC solo mostraría desplazamientos y números de bits. Un servidor OPC UA puede exponer objetos identificables, tipos y relaciones; los integradores siguen teniendo que conocer el modelo concreto, pero no dependen únicamente de un mapa de bytes anónimo.

Para robótica, la especificación

OPC 40010-1, OPC UA for Robotics – Part 1: Vertical Integration

define un modelo destinado a sistemas de nivel superior. La referencia oficial indica la

versión 1.02, publicada el 8 de septiembre de 2025

. Que un fabricante anuncie OPC UA no garantiza que implemente ese modelo complementario ni que admita todos sus elementos opcionales.

¿OPC UA sirve únicamente para supervisar?

No. OPC UA contempla lectura, escritura, métodos y publicación/suscripción. Los desarrollos

Field Level Communications / OPC UA FX

extienden la tecnología hacia aplicaciones de campo, incluidas necesidades de tiempo real. La precisión es importante: aunque una célula de robot convencional utilice OPC UA por encima de la red de control, no debe afirmarse que OPC UA sea incapaz por definición de controlar equipos. Hay que evaluar perfiles, dispositivos y temporización verificada de cada implementación.

Cuándo utilizar OPC UA:

cuando aplicaciones diferentes necesiten una representación estructurada, descubrible y protegida de los datos de máquina. Configura certificados, autenticación, permisos, endpoints seguros y alcance de las operaciones de lectura/escritura. Un servidor OPC UA no da permiso automáticamente al MES para ordenar movimiento.

5. MQTT: publicación y suscripción de eventos de producción

MQTT

es un protocolo de mensajería publicación/suscripción estandarizado por OASIS. Un equipo o aplicación edge publica en un

topic

y un bróker distribuye el mensaje a los suscriptores interesados. El emisor no tiene que conectarse directamente con cada cuadro de mando, base de datos o servicio de análisis.

Ejemplo de topic y payload MQTT

Un gateway podría publicar en

factory/bilbao/cell-03/robot-01/status

el siguiente JSON ilustrativo:

{
  "schema_version": 1,
  "asset_id": "robot-01",
  "timestamp_utc": "2026-10-13T12:00:00Z",
  "state": "running",
  "program_id": "job-024",
  "parts_completed": 1842,
  "source_quality": "good"
}

Datos de ejemplo, no valores medidos de un equipo real.

MQTT no define por sí mismo qué significan

state

,

program_id

o

parts_completed

. El contrato de integración debe especificar unidades, tipos, marcas temporales, identificadores de eventos, responsables, versiones de esquema y cómo detectar datos obsoletos.

Qué garantizan realmente los niveles QoS de MQTT

• 
  QoS 0:
  
  como máximo una entrega en MQTT; el mensaje puede perderse.
• 
  QoS 1:
  
  al menos una entrega en MQTT; puede haber duplicados.
• 
  QoS 2:
  
  exactamente una entrega en el intercambio MQTT correspondiente, con mayor sobrecarga. No garantiza que una transacción de base de datos posterior ni una acción física del robot se ejecute exactamente una vez.

Los mensajes retenidos muestran el último estado publicado, que puede estar desactualizado. Las sesiones persistentes, reintentos y caducidad requieren configuración deliberada. Utiliza marcas de tiempo, criterios de vigencia e identificadores o claves de idempotencia cuando proceda. Protege el sistema con autenticación, TLS cuando corresponda, listas de control por topic y acceso limitado al bróker.

Cuándo utilizar MQTT:

para distribuir eventos operativos, avisos de mantenimiento o telemetría histórica. Que la nube pueda publicar un topic no significa que MQTT pueda sustituir el mando cíclico PLC–robot ni las funciones de seguridad validadas.

Cómo conviven estos protocolos en una célula robotizada

Imagina una célula de embalaje con robot industrial, PLC, pinza, sensores y panel de supervisión. Una arquitectura razonable separa estas responsabilidades:

1. 
   Control de máquina:
   
   el PLC intercambia órdenes y estados del robot a través de un fieldbus cíclico admitido. El controlador ejecuta su programa validado. Otros variadores y E/S pueden usar esa red u otra de campo.
2. 
   Seguridad funcional:
   
   un sistema diseñado por separado supervisa protecciones y funciones de parada segura. Según la evaluación de riesgos, puede utilizar E/S cableadas de seguridad o un protocolo de seguridad compatible.
3. 
   Datos operativos estructurados:
   
   robot, PLC o gateway exponen diagnósticos y estados seleccionados mediante OPC UA, con escritura restringida por política.
4. 
   Distribución de eventos:
   
   un gateway autorizado transforma cambios relevantes en eventos MQTT y los envía al bróker, que no forma parte del lazo de control necesario para operar la máquina.
5. 
   Aplicaciones empresariales:
   
   MES, mantenimiento y analítica usan la información para trazabilidad, OEE y resolución de incidencias.

Este esquema es solo un ejemplo. Algunas plantas comunican directamente PLC y MES; otras usan un historiador industrial o prescinden de MQTT. Un gateway debe resolver una necesidad real, no añadir otro servicio susceptible de fallar.

Ejemplo práctico: un handshake robusto entre PLC y robot

El protocolo transporta señales; el

contrato de interfaz

define cómo debe comportarse la máquina. Esta tabla ilustra un ciclo de recogida y colocación. Los nombres y direcciones son conceptuales, no un estándar ni un mapeado particular de fabricante.

Posible secuencia:

el PLC comprueba las condiciones habituales de máquina, selecciona trabajo, presenta un identificador nuevo y solicita el ciclo. El robot confirma qué orden acepta, pasa a ocupado y notifica la finalización con el mismo identificador. El PLC no inicia otro ciclo hasta conciliar el anterior y sus resultados. Un arranque, timeout o enlace perdido nunca debe convertir silenciosamente una petición antigua en otra orden de movimiento.

Hay que definir qué ocurre tras recuperar la alimentación, paradas de emergencia, paradas de protección, reinicios, cambios de trabajo, fallos simultáneos y modo manual. Los bits de aplicación

Ready

o

Heartbeat


no son señales de seguridad certificadas

, salvo diseño y validación específicos dentro de una arquitectura de seguridad adecuada. Un estado de fieldbus convencional no demuestra por sí mismo que la célula sea segura.

No confundas E/S, movimiento del robot y seguridad funcional

Son tres problemas de ingeniería diferentes:

• 
  Handshake estándar de E/S:
  
  transmite arranque, estados, números de programa y diagnósticos. A menudo basta un bloque cíclico pequeño.
• 
  Coordinación de movimiento:
  
  sincroniza ejes, seguimiento de cintas o movimientos coordinados. Puede exigir opciones de movimiento del fabricante, relojes sincronizados, perfiles compatibles o interfaces propias; no basta con acelerar las E/S.
• 
  Seguridad funcional:
  
  detecta situaciones peligrosas y ejecuta funciones de seguridad validadas. Entre los protocolos posibles figuran
  
  PROFIsafe
  
  ,
  
  CIP Safety
  
  y
  
  Safety over EtherCAT (FSoE)
  
  , siempre con extremos certificados compatibles y diseño y validación específicos.

La lógica de seguridad, la comunicación segura,

Safe Torque Off

, parada de protección y parada de emergencia no son conceptos equivalentes. Su función, nivel de prestación requerido y recuperación dependen de la evaluación de riesgos y normas aplicables, no de esta comparación.

Método de ingeniería en seis pasos para elegir protocolo

1. 
   Inventaría los equipos reales.
   
   Registra CPU del PLC, controlador del robot, módulos de E/S, variadores, revisiones de firmware, tarjetas de red y licencias instaladas. No presupongas que todos los robots de una marca incluyen lo mismo.
2. 
   Define la función.
   
   Clasifica cada dato como orden/estado cíclico, movimiento, comunicación relacionada con seguridad, diagnóstico o telemetría empresarial.
3. 
   Comprueba los roles.
   
   Distingue PROFINET IO-Controller/IO-Device, EtherNet/IP scanner/adapter y EtherCAT MainDevice/SubDevice. Dos productos que anuncian el mismo protocolo pueden no comunicarse directamente si sus roles son incompatibles.
4. 
   Solicita evidencia de integración.
   
   Pide GSDML para PROFINET, EDS y detalles de conexión para EtherNet/IP, o ESI para EtherCAT. Para OPC UA, endpoints, namespaces y perfiles de seguridad; para MQTT, contrato del bróker y payload.
5. 
   Establece tiempos y fallos.
   
   Define intervalos, vigencia de datos, timeouts y estados de máquina después de una pérdida de enlace o reinicio. Considera por separado el ciclo del PLC, el procesamiento del robot y la seguridad.
6. 
   Prueba la interfaz mínima en banco.
   
   Conecta equipos, intercambia E/S representativas, verifica tipos y orden de bytes, y reproduce una desconexión y reinicio antes de comprometer la arquitectura.

Tres situaciones habituales de compra

Escenario A: fábrica con PROFINET.

Si el robot elegido tiene una opción IO-Device compatible, mantener el fieldbus existente puede simplificar ingeniería, repuestos y mantenimiento. Verifica la opción instalada, no solo la ficha comercial.

Escenario B: PLC basado en CIP.

Un adapter EtherNet/IP en el robot puede facilitar la conexión. Comprueba assemblies, tamaños, RPI y reacción a fallos antes de programar el PLC.

Escenario C: máquina EtherCAT con varios servoejes.

EtherCAT puede ser lo adecuado para sus variadores y E/S. Sin embargo, el robot industrial independiente podría intercambiar el handshake de programa por otro fieldbus si su controlador así lo requiere. Una máquina puede utilizar legítimamente varias redes de campo.

Qué importa más que el tiempo de ciclo anunciado

Las cifras teóricas de actualización que publican algunos proveedores pueden ser válidas para determinadas configuraciones, pero no describen la respuesta de la célula completa. Analiza por separado:

• 
  Intervalo de actualización del fieldbus:
  
  frecuencia de intercambio de datos de proceso.
• 
  Jitter:
  
  variación temporal de la llegada o ejecución de datos y tareas.
• 
  Periodo de tarea del PLC:
  
  momento en que lee entradas, ejecuta lógica y actualiza salidas.
• 
  Reacción del controlador del robot:
  
  detección de la entrada mapeada y cambio de estado de aplicación.
• 
  Respuesta física:
  
  tiempo adicional de reacción del hardware dentro de la secuencia validada.

En un handshake convencional inicio/ocupado/completo, la previsibilidad, el diagnóstico y la compatibilidad pueden importar bastante más que acortar una fracción del ciclo de red. Con variadores fuertemente acoplados y movimiento sincronizado, las prioridades cambian. Si el tiempo es crítico, mide el hardware previsto; no infieras prestaciones del nombre del protocolo.

Segmentación, acceso remoto y ciberseguridad

OPC UA y MQTT dan visibilidad, pero abren otras vías de acceso. Una defensa en profundidad separa el control de máquina de supervisión y empresa, permite únicamente los flujos necesarios y evita que la caída de analítica detenga o comprometa el control.

• 
  Segmentación:
  
  define zonas de célula, supervisión y empresa, con conducciones enrutadas o firewalls donde corresponda.
• 
  Identidad:
  
  usa cuentas de servicio separadas, permisos limitados y evita contraseñas predeterminadas o clientes anónimos sin restricciones.
• 
  Certificados y cifrado:
  
  configura modos de seguridad OPC UA, certificados de confianza y transporte seguro MQTT; controla caducidad y renovación.
• 
  Mínimo privilegio:
  
  publica datos operativos en solo lectura por defecto. Las escrituras remotas necesitan un flujo de órdenes revisado y auditado.
• 
  Fallos independientes:
  
  perder nube, bróker, historiador o SCADA no debe causar un comportamiento inseguro.
• 
  Mantenimiento:
  
  conserva copias de configuración, planos de red, documentación de soporte y un proceso controlado para firmware y credenciales.

Ningún artículo certifica la seguridad de red de una fábrica. Las medidas concretas dependen del análisis de amenazas, las restricciones productivas, los requisitos aplicables y el equipamiento real.

Checklist de puesta en marcha: pruebas que conviene registrar

• 
  Identidad:
  
  están presentes los controladores, firmware, módulos y licencias previstos.
• 
  Configuración:
  
  coinciden archivos de dispositivo, orden de módulos, assemblies y orden de bytes/bits.
• 
  Roles y direcciones:
  
  cada interfaz funciona como controlador/dispositivo o cliente/servidor según el diseño.
• 
  Handshake normal:
  
  programa, preparado, petición, aceptado, ocupado y completado concuerdan en ambos equipos.
• 
  Entrada inválida:
  
  números de programa no válidos, valores mal formados y órdenes contradictorias se rechazan o gestionan con seguridad.
• 
  Pérdida de enlace:
  
  desconectar o detener un proceso provoca la respuesta y alarma previstas; recuperarse no reinicia inesperadamente un ciclo.
• 
  Retorno de alimentación:
  
  PLC, robot y gateway concilian estados y limpian solicitudes obsoletas tras reiniciar.
• 
  Vigencia de datos:
  
  consumidores OPC UA/MQTT distinguen estado actual, desconectado y obsoleto.
• 
  Control de acceso:
  
  fallan como corresponde los intentos de escritura, publicación y conexión no autorizados.
• 
  Validación de seguridad:
  
  personal cualificado comprueba por separado las funciones reales de seguridad, fallos relevantes y rearranque.

Conserva una matriz de interfaces aprobada y los resultados de prueba junto con esquemas eléctricos y copias de PLC y robot. El próximo técnico no debería tener que deducir el significado de un bit examinando el programa en marcha.

Preguntas frecuentes

¿Es mejor PROFINET o EtherNet/IP?

Ninguno es mejor en todos los casos. Ambos pueden intercambiar E/S cíclicas entre PLC y robot. Suelen decidir el PLC instalado, las opciones del controlador, herramientas de ingeniería, roles y necesidades de soporte. Valida la combinación exacta y no decidas por una velocidad nominal.

¿EtherCAT es más rápido que PROFINET?

EtherCAT está diseñado para intercambio determinista eficiente y sincronización de equipos. PROFINET también dispone de mecanismos de tiempo real, incluido IRT. Sin hardware, topología, ciclos configurados y tarea de control definidos, una clasificación genérica de velocidad carece de utilidad técnica.

¿Pueden comunicarse directamente PLC y robot con OPC UA?

Sí, si ambos implementan funciones OPC UA compatibles y la aplicación está diseñada para ello. Pero disponer de un servidor OPC UA no implica contar con E/S cíclicas adecuadas ni una ruta de seguridad validada. Comprueba requisitos e implementación concretos.

¿Puede MQTT arrancar o detener un robot industrial?

Una aplicación puede recibir técnicamente un comando MQTT, pero MQTT no garantiza control de movimiento determinista y seguro ni parada certificada. Las órdenes remotas deben pasar por autorización, comprobaciones del estado del PLC/robot y controles de máquina validados. La seguridad no debe depender de mensajes MQTT ordinarios.

¿Pueden PROFINET, EtherNet/IP y EtherCAT compartir switch?

No lo presupongas. Algunas instalaciones PROFINET y EtherNet/IP pueden utilizar infraestructura Ethernet industrial gestionada adecuada, atendiendo a protocolo, tiempos y topología. Las comunicaciones cíclicas habituales de EtherCAT funcionan de otra forma y necesitan hardware de segmento compatible. Compartir tipo de cable no significa interoperar.

¿Para qué sirven GSDML, EDS y ESI?

Son descripciones para herramientas de ingeniería:

GSDML

en PROFINET,

EDS

en muchas integraciones EtherNet/IP y

ESI

en EtherCAT. Ayudan a configurar datos, parámetros e identidad, pero no sustituyen las comprobaciones de firmware, roles y semántica de señales.

Conclusión: define primero la frontera del control

En una célula robotizada industrial puede ser útil partir de

fieldbus cíclico para secuenciar la máquina, funciones de seguridad validadas por separado, OPC UA para datos estructurados de supervisión y MQTT solo donde aporte valor distribuir eventos mediante bróker

. Es un patrón, no una obligación universal. La integración depende de las interfaces reales, un contrato de señales inequívoco y comportamiento ensayado ante fallos.

Antes de comprar una tarjeta o licencia, quizá el documento más valioso sea una página que indique

quién controla cada señal, por qué red viaja, cuánto tiempo sigue siendo válida y qué ocurre cuando desaparece

.

Fuentes y verificaciones adicionales

Recursos primarios de organismos de normalización revisados para esta actualización:

• 
  PROFIBUS & PROFINET International — tecnología PROFINET
  
  : variantes de tiempo real, diagnósticos y PROFIsafe.
• 
  PI — especificación GSDML de PROFINET
  
  : diferencia entre descripciones XML PROFINET y GSD de PROFIBUS.
• 
  ODVA — EtherNet/IP
  
  : CIP y comunicación cíclica basada en UDP.
• 
  EtherCAT Technology Group — tecnología EtherCAT
  
  : procesamiento al vuelo, relojes distribuidos y seguridad.
• 
  ETG — EtherCAT Compendium
  
  : estados, ingeniería e implementación.
• 
  OPC Foundation — OPC Unified Architecture
  
  : modelos de información y seguridad.
• 
  OPC Foundation — OPC UA for Robotics, Part 1
  
  : versión 1.02, 8 de septiembre de 2025.
• 
  OPC Foundation — Field Level Communications / OPC UA FX
  
  .
• 
  OASIS — MQTT Version 5.0
  
  : norma OASIS del 7 de marzo de 2019.

Nota de verificación:

estas fuentes fundamentan los principios y especificaciones publicados. No verifican opciones instaladas ni compatibilidad de una pareja indeterminada de PLC y robot, ni miden prestaciones de una fábrica concreta. Referencias comprobadas el 13 de octubre de 2026.

¿Estás planificando la integración entre robot y PLC?

Empieza por el controlador exacto del robot, modelo de PLC, firmware, opciones de fieldbus y señales necesarias. Consulta más guías en

AYXWORKS Robotics & Automation

, incluida la

guía de picking guiado por visión y recuperación

. La viabilidad y distribución de responsabilidades pueden plantearse con Eurobots/ReBots. Más información sobre el autor en el

portfolio de AYXWORKS

.

Para debatir:

¿qué conexión te ha dado más problemas al ponerla en marcha: mapeado PROFINET, assemblies EtherNet/IP, configuración EtherCAT, seguridad OPC UA o coherencia de payload MQTT?

Ilustración interior: gráfico explicativo original de AYXWORKS; no sustituye un esquema de red específico. Mantén los créditos de cualquier imagen destacada de WordPress según su licencia real.