Modbus RTU vs Modbus TCP vs OPC UA: cuál elegir en planta

El protocolo que eliges acompaña a la instalación toda su vida útil, a menudo diez o quince años. Aun así, se suele elegir por inercia: "la sonda ya venía con Modbus". Esta guía da el criterio para las tres opciones que cubren la mayoría de proyectos de planta, sitúa MQTT entre ellas y acaba con una arquitectura de referencia en la que cada protocolo trabaja en el nivel donde gana.

1. Nivel 1Bus de campoModbus RTU en RS-485: variadores, contadores, sondas, esclavos de E/S
2. Nivel 2Red de controlModbus TCP en Ethernet: PLC, SCADA local, HMI
3. Nivel 3Frontera OT/ITOPC UA en una pasarela: MES, historiador, terceros
4. TelemetríaNube o centralMQTT a través de un broker: datos hacia arriba, nunca control hacia abajo

Modbus RTU vs Modbus TCP vs OPC UA vs MQTT: tabla comparativa

La tabla es el resumen. La elección sale del problema que resuelve cada protocolo, que se explica a continuación.

¿Cuándo usar Modbus RTU?

Modbus RTU es un protocolo binario maestro y esclavo sobre una línea serie, normalmente RS-485. Cada trama acaba con un CRC-16, y las tramas se separan con un silencio de al menos 3,5 caracteres (1,75 ms fijos por encima de 19.200 bit/s). La especificación es corta, así que casi todos los variadores, contadores de energía, sondas y módulos de E/S lo hablan, desde equipos de hace décadas hasta los modelos de este año.

Puntos fuertes:

• Hasta 1.200 m de bus sin electrónica adicional, a velocidades bajas (unos 100 kbit/s o menos). Un tramo de Ethernet de cobre se queda en 100 m.
• Buena inmunidad al ruido. El receptor RS-485 lee la diferencia entre dos hilos, así que el ruido que llega igual a los dos se anula. Eso cuenta junto a variadores y contactores.
• Sin infraestructura. Un par trenzado y una referencia común: sin switches, sin direcciones IP, sin departamento de IT.

Limitaciones:

• Un solo maestro. Si el SCADA necesita los mismos valores que lee el PLC, los obtiene a través del PLC.
• Sondeo secuencial. El maestro pregunta a cada esclavo por turno. A 19.200 bit/s, leer 10 registros de un esclavo tarda unos 20 ms en la línea más el tiempo de respuesta del esclavo, así que 20 esclavos con mapas de registros grandes llevan el ciclo de refresco a segundos.
• Direccionamiento manual. Cada esclavo tiene su dirección puesta por DIP switch o menú, y el mapa de registros vive en un documento que alguien debe mantener al día.
• Sin seguridad. Cualquiera conectado al bus puede leer y escribir. Es aceptable dentro de una máquina, no fuera de ella.

La mayoría de fallos intermitentes de RTU son eléctricos: consulta Diagnóstico de fallos RS485 paso a paso y Errores de cableado de PLC. Para programas de maestro y esclavo en PLC basados en Arduino y ESP32, consulta Modbus RTU con PLC basados en Arduino y ESP32.

¿Cuándo usar Modbus TCP?

Modbus TCP lleva los mismos códigos de función y registros dentro de TCP/IP, en el puerto 502, con una cabecera MBAP de 7 bytes en lugar de la dirección de esclavo y el CRC. Lo que cambia es la red: varios clientes pueden hablar con el mismo equipo, la topología es en estrella con switches y la velocidad es la de la red local.

Puntos fuertes:

• Usa el Ethernet de la planta. El mismo cableado estructurado y los mismos switches, idealmente en un segmento OT separado.
• Diagnóstico con herramientas estándar. Un ping encuentra un nodo caído y Wireshark descodifica cada transacción. RS-485 pide osciloscopio y paciencia; Modbus TCP pide un portátil.
• Concurrencia. El PLC controla, el SCADA supervisa y un portátil de mantenimiento lee, todo a la vez.
• Fácil de ampliar. Un nodo nuevo es un latiguillo a un switch, no un cambio en un bus en servicio.

Limitaciones:

• Sin seguridad en Modbus TCP estándar. Las tramas viajan en claro y sin autenticación. La Modbus Organization publica una variante segura con TLS (Modbus/TCP Security, puerto 802), pero pocos equipos de campo la soportan. En la práctica la respuesta es la arquitectura: una red OT con su propia VLAN, un firewall hacia IT y el puerto 502 nunca expuesto fuera de ella.
• Sigue siendo un mapa plano de registros. El registro 40021 significa "temperatura del horno" solo porque lo dice una hoja de cálculo. El protocolo transporta números, no significado, y ese es el hueco que llena OPC UA.

Hay ejemplos que funcionan con Python y Node-RED en la guía de Modbus TCP y RTU para PLC con Raspberry Pi, y con CODESYS en Configurar Modbus en un PLC con Raspberry Pi con CODESYS.

¿Cuándo usar OPC UA?

OPC UA no transporta registros: transporta objetos con significado. Una variable se llama, por ejemplo, Horno1.Temperatura, y lleva su tipo de dato, unidades, una marca de tiempo y un código de estado. Un cliente navega por el espacio de direcciones del servidor y encuentra las variables sin hoja de mapeo: conectas un cliente MES y ves la estructura de la máquina como un árbol de carpetas.

Además trae lo que Modbus nunca tuvo: seguridad desde el diseño. Sesiones firmadas y cifradas, autenticación mutua con certificados X.509 y usuarios con permisos por nodo. De los tres, es el único que puedes defender en una auditoría de ciberseguridad sin decir "está en una red aislada".

El coste es la complejidad. Un servidor necesita un espacio de direcciones, políticas de seguridad y gestión de certificados, y consume memoria y CPU de verdad. Existen perfiles embebidos pequeños, pero un servidor completo con seguridad encaja mejor en un equipo Linux que hace de servidor o pasarela en la frontera OT/IT.

Por eso OPC UA no compite con Modbus por el bus de campo. Compite por la frontera: el punto donde los datos de planta van a sistemas de fuera de la planta, como un MES, un historiador, un ERP u otra empresa. Hay un ejemplo con flujos en Servidor OPC UA en un Raspberry PLC con Node-RED.

¿Dónde encaja MQTT y cuándo es un error?

MQTT no compite con Modbus, y solo a veces con OPC UA. Es un protocolo de publicación y suscripción a través de un broker central: los nodos no hablan entre sí, publican mensajes en topics y el broker los entrega a los suscriptores. Nació para telemetría sobre enlaces malos: la cabecera fija ocupa solo 2 bytes, tolera desconexiones y escala a miles de nodos sin sondeo.

Cuándo MQTT es la mejor opción:

• Telemetría hacia la nube o hacia un sistema central remoto: muchos nodos dispersos, enlaces intermitentes (Wi-Fi, 4G) y datos que van en un solo sentido. Un ESP32 PLC que publica por MQTT es más simple y más robusto que cualquier alternativa.
• Arquitecturas IIoT nuevas donde controlas los dos extremos y puedes fijar el contrato de datos. Con Sparkplug B (Eclipse Foundation, publicado como ISO/IEC 20237), MQTT añade estado de sesión (mensajes de nacimiento y muerte) y una carga útil definida, que cubre parte del terreno de OPC UA.
• Volumen: para mover series temporales de cientos de máquinas a un historiador, publicar y suscribir es más eficiente que el sondeo cliente y servidor.

Cuándo MQTT es un error grave:

• Control. Enviar órdenes a actuadores a través de un broker pone un intermediario, un punto único de fallo con latencia no acotada, dentro del lazo de control. QoS 1 y 2 garantizan la entrega, no el momento. Una orden de paro que llega tarde no es una orden de paro.
• Integración con terceros sin contrato previo. MQTT puro no define el contenido del mensaje, y cada integrador inventa un formato JSON. OPC UA pone el modelo de datos en el estándar.
• Cualquier cosa cuya ausencia pararía o dañaría la máquina. Los datos que pueden llegar tarde viajan por publicación y suscripción; el control viaja por protocolos deterministas y punto a punto.

En resumen, MQTT mueve muy bien los datos hacia arriba; no mueve la responsabilidad hacia abajo. Para empezar, consulta MQTT con Node-RED en un Raspberry PLC y MQTT sobre TLS en un ESP32 PLC.

Arquitectura de referencia: RTU abajo, TCP en medio, OPC UA y MQTT arriba

Esta es la arquitectura que recomendamos para una planta típica. Tres niveles, cada protocolo donde gana:

Nivel 1, bus de campo: Modbus RTU. Del PLC hacia abajo: variadores, sondas, contadores de energía y esclavos de E/S. Distancias largas, ruido, coste bajo y equipos de cualquier edad. Uno o varios buses por máquina, cableados en línea, terminados en los dos extremos y apantallados.

Nivel 2, red de control: Modbus TCP. Entre PLC, y de los PLC al SCADA local y a las HMI. Una red Ethernet OT segmentada con switches industriales, donde control y supervisión no se estorban.

Nivel 3, frontera OT/IT: OPC UA, MQTT o los dos. Una pasarela, un equipo Linux en carril DIN, recoge los datos de los niveles inferiores y los pasa hacia arriba: OPC UA para MES, historiadores y sistemas de terceros que necesitan significado y seguridad, y MQTT para telemetría hacia la nube o un sistema central. Es el único punto que cruza el firewall, con cifrado y certificados. Modbus nunca se expone directamente a IT.

Cada nivel aísla al de abajo: puedes cambiar el SCADA sin tocar el bus de campo, o cambiar de plataforma cloud sin tocar el control. La pasarela traduce una sola vez, en un solo sitio, con un solo mapeo documentado.

La regla de decisión

• Bus de campo hacia variadores, sondas y esclavos de E/S: Modbus RTU.
• Entre PLC, y de PLC a SCADA o HMI local: Modbus TCP.
• Frontera OT/IT, datos para un MES, un historiador u otra empresa: OPC UA.
• Telemetría masiva, nodos remotos, enlaces intermitentes, nube: MQTT, nunca para control.

Si una instalación no encaja en este esquema, la pregunta útil no suele ser "¿qué protocolo?" sino "¿qué nivel de la arquitectura falta?".

Preguntas frecuentes sobre Modbus RTU, Modbus TCP y OPC UA

¿Modbus TCP es más rápido que Modbus RTU?

Sí, en la mayoría de instalaciones. Modbus RTU funciona de 9.600 a 115.200 bit/s y pregunta a un esclavo cada vez; Modbus TCP funciona a la velocidad de Ethernet y acepta varios clientes. Los registros y los códigos de función son los mismos, así que a menudo el límite pasa a ser el tiempo de respuesta del equipo.

¿Pueden trabajar en el mismo sistema equipos Modbus RTU y Modbus TCP?

Sí, mediante una pasarela que es servidor Modbus TCP en Ethernet y maestro Modbus RTU en RS-485. La pasarela traduce las peticiones y los esclavos RTU se quedan en su bus.

¿Cuántos equipos puede tener un bus Modbus RTU?

El protocolo admite direcciones de esclavo de 1 a 247. El estándar RS-485 admite 32 cargas unitarias por segmento; los transceptores con una fracción de carga unitaria o los repetidores permiten más equipos. En la práctica, el tiempo de sondeo pone el límite antes.

¿OPC UA sustituye a Modbus?

No en el bus de campo. OPC UA necesita más recursos y su valor está en el modelo de datos y en la seguridad de la frontera OT/IT. El diseño habitual mantiene Modbus abajo y publica los datos con OPC UA desde una pasarela.

¿MQTT es una alternativa a OPC UA?

Para telemetría hacia sistemas que controlas, sí, sobre todo con Sparkplug B. Para integrar terceros que necesitan un modelo de datos estándar, o para todo lo que deba pasar una auditoría de seguridad, OPC UA es la opción más segura. Para el control, ninguno de los dos sustituye a Modbus o a un bus de campo.

Más sobre comunicaciones industriales

• Guía de Modbus TCP y RTU para PLC con Raspberry Pi: ejemplos con Python y Node-RED
• Modbus RTU con PLC basados en Arduino y ESP32
• Diagnóstico de fallos RS485 paso a paso
• Servidor OPC UA en un Raspberry PLC con Node-RED
• PLC Arduino vs ESP32 vs Raspberry Pi: cuál elegir
• Aplicaciones industriales: 50 ejemplos reales por sector, con sus señales y protocolos