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

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

El protocolo que elijas hoy te acompañará toda la vida útil de la instalación. Diez, quince años.

Y sin embargo se suele decidir en cinco minutos, por inercia: "la sonda ya venía con Modbus". Nadie cablearía una planta sin plano, pero la arquitectura de comunicaciones — que es exactamente igual de estructural — se improvisa nodo a nodo.

En este artículo tienes el criterio completo para las tres opciones que cubren el 95% de los proyectos que pasan por Industrial Shields: Modbus RTU, Modbus TCP y OPC-UA. Y la respuesta a la pregunta que aparece en todas las conversaciones desde hace unos años: ¿dónde encaja MQTT en todo esto? — incluyendo cuándo sustituye a OPC-UA y cuándo usarlo es un error grave. Al final, la arquitectura de referencia que recomendamos, con los tres (o cuatro) protocolos colocados donde cada uno gana.

La comparativa en una tabla

La tabla resume; el criterio de verdad está en entender qué problema resuelve cada uno.

Modbus RTU: el veterano que se niega a morir (con razón)

Serie sobre RS-485, arquitectura maestro-esclavo, trama binaria con CRC16 y un silencio de 3,5 caracteres separando tramas. Simple hasta el extremo — la especificación completa se lee en una tarde — y por eso lo habla todo: desde un variador de 1985 hasta un contador de energía de este año.

Fortalezas reales:

• Hasta 1.200 metros de bus sin electrónica adicional: ningún Ethernet estándar llega ahí sin fibra o repetidores.
• Inmunidad al ruido excelente: el par diferencial de RS-485 rechaza el ruido de modo común que arruinaría una señal single-ended, exactamente lo que necesitas junto a variadores.
• Coste cero de infraestructura: dos hilos y referencia común. Sin switches, sin direcciones IP, sin departamento de IT.

Limitaciones reales:

• Un solo maestro: nadie más puede preguntar al bus. Si el SCADA quiere leer las mismas sondas que lee el PLC, o pasa por el PLC o no pasa.
• Sondeo secuencial: el maestro pregunta a cada esclavo por turno. Con 20 esclavos y mapas de registros grandes, tu ciclo de refresco se va a segundos — física, no configuración.
• Direccionamiento a mano: cada esclavo con su dirección puesta por dip-switch o menú, documentada en un papel que hay que mantener vivo.
• Cero seguridad: quien pincha el bus, lee y escribe. En un bus dentro de la máquina es asumible; hacia fuera, no.

Modbus TCP: el mismo idioma, sobre Ethernet

La misma semántica de registros de siempre, encapsulada en TCP/IP por el puerto 502. Lo que cambia es todo lo demás: varios clientes simultáneos contra el mismo equipo, topología en estrella con switches y velocidades de red local.

Fortalezas reales:

• Convivencia con la red existente: el mismo cableado estructurado, los mismos switches (idealmente segmentados).
• Diagnóstico con herramientas estándar: un ping localiza un nodo caído; un Wireshark te enseña cada transacción. Diagnosticar RS-485 exige osciloscopio y paciencia; diagnosticar Modbus TCP exige un portátil.
• Concurrencia: el PLC controla, el SCADA supervisa y el portátil de mantenimiento consulta — a la vez, contra el mismo esclavo.
• Escalado fácil: añadir un nodo es un latiguillo a un switch, no abrir un bus en servicio.

Limitaciones reales:

• Sigue sin seguridad nativa: la trama viaja en claro y sin autenticación. La respuesta correcta es arquitectura: segmentar la red OT (VLAN propia, firewall hacia IT) y no exponer jamás el puerto 502 fuera de ella.
• Sigue siendo un mapa plano de registros: el registro 40021 significa "temperatura horno" solo porque lo dice un Excel que alguien perderá. El protocolo transporta números, no significado — esta limitación es la puerta de entrada del siguiente.

OPC-UA: el que trae el modelo de datos incorporado

Aquí cambia la categoría. OPC-UA no transporta registros: transporta objetos con semántica. La variable se llama "Horno1.Temperatura", lleva unidades, timestamp y calidad del dato, y el cliente la descubre navegando el espacio de direcciones del servidor — sin Excel de mapeo. Conectas el cliente MES al servidor y ves la estructura de la máquina como quien navega carpetas.

Además trae lo que Modbus nunca tuvo: seguridad de serie. Firma y cifrado de sesión, autenticación mutua por certificados, usuarios con permisos por nodo. Es el único de los tres que puedes defender ante una auditoría de ciberseguridad sin escudarte en "está en una red aislada".

El coste: complejidad. Un servidor OPC-UA no se implementa en una tarde: espacio de direcciones, perfiles de seguridad, gestión de certificados. Consume memoria y CPU de verdad, y sobre un microcontrolador pequeño simplemente no cabe con todas sus capas — su lugar natural son equipos con sistema operativo Linux actuando de servidor o pasarela en la frontera OT/IT.

La consecuencia práctica: OPC-UA no compite con Modbus por el bus de campo. Compite por la frontera: el punto donde los datos de planta se entregan a sistemas que no son de planta — MES, historiador, ERP, otra empresa.

¿Y MQTT? Otra liga — y aquí está el criterio completo

MQTT no compite con Modbus, y solo a veces compite con OPC-UA. Es un protocolo de publicación/suscripción a través de un broker central: los nodos no se hablan entre sí, publican mensajes en "topics" y el broker los distribuye a quien esté suscrito. Nació para telemetría sobre enlaces malos, y en eso sigue siendo imbatible: cabecera mínima (cabe en un ESP32 con holgura), tolerancia a desconexiones, y un modelo que escala a miles de nodos sin que nadie sondee a nadie.

Cuándo MQTT sustituye a OPC-UA (y con ventaja):

• Telemetría hacia la nube o hacia una central remota: muchos nodos dispersos, enlaces intermitentes (WiFi, 4G), datos que fluyen en un solo sentido. Un ESP32 PLC publicando por MQTT es más simple, más barato y más robusto que cualquier alternativa.
• Arquitecturas IIoT de nueva planta donde ambos extremos son tuyos y puedes fijar el contrato de datos: con la especificación Sparkplug B, MQTT gana además estado de sesión ("birth/death certificates") y un modelo de datos definido, cubriendo parte del terreno semántico de OPC-UA.
• Volumen y escala: cuando lo que necesitas es mover series temporales de cientos de máquinas a un histórico, el modelo pub/sub aplasta al cliente-servidor en eficiencia.

Cuándo usar MQTT es un error grave:

• Control: mandar órdenes a actuadores a través de un broker es poner un intermediario — un punto único de fallo con latencia no acotada — dentro de tu lazo de control. QoS 1 o 2 garantizan entrega, no garantizan cuándo. Una orden de parada que llega "seguro, pero tarde" no es una orden de parada.
• Interoperabilidad con terceros sin contrato previo: MQTT puro no define qué hay dentro del mensaje — cada integrador inventa su JSON. OPC-UA lleva el modelo de datos en el estándar; con MQTT (sin Sparkplug pactado), vuelves al Excel de mapeo, ahora en versión topics.
• Cualquier cosa cuya ausencia detenga o dañe la máquina: la regla de la semana pasada aplica también aquí — por pub/sub viajan datos que pueden llegar tarde; el control va por protocolos deterministas y punto a punto.

La versión corta: MQTT mueve datos hacia arriba de forma extraordinaria; no mueve responsabilidad hacia abajo. OPC-UA sigue ganando cuando la frontera exige semántica estándar, seguridad certificable e interoperabilidad con sistemas de terceros; MQTT gana cuando la frontera es tuya, los nodos son muchos y el enlace es malo.

La arquitectura de referencia: RTU abajo, TCP en medio, UA/MQTT arriba

Esta es la arquitectura que recomendamos — y la que montamos — 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, esclavos de E/S. Distancias largas, ruido, coste mínimo, dispositivos de cualquier década. Un bus (o varios) por máquina, en línea, terminado, apantallado — como vimos en los errores de cableado.

Nivel 2 — Red de control: Modbus TCP. Entre PLCs, y de los PLCs al SCADA local. Red Ethernet OT segmentada, switches industriales, concurrencia para que control y supervisión no se estorben. Aquí viven también las HMIs.

Nivel 3 — Frontera OT/IT: OPC-UA y/o MQTT. Una pasarela — un equipo Linux en carril DIN — concentra los datos de los niveles inferiores y los entrega hacia arriba: OPC-UA para MES, historiadores y sistemas de terceros que exigen semántica y seguridad; MQTT para telemetría hacia la nube o la central. Es el único punto que cruza el firewall, y cruza con cifrado y certificados — nunca exponiendo Modbus directamente a IT.

La virtud de esta arquitectura es que cada nivel aísla al de abajo: puedes renovar el SCADA sin tocar el bus de campo, o cambiar de plataforma cloud sin tocar el control. Y la pasarela traduce una sola vez, en un solo sitio, con un solo mapeo documentado.

La regla de decisión, en corto

• Bus de campo hacia variadores, sondas y esclavos de E/S → Modbus RTU (y que siga).
• Comunicación entre PLCs, y de PLC a SCADA en red local → Modbus TCP.
• Frontera OT/IT: entregar datos a MES, historiadores o a otra empresa → OPC-UA.
• Telemetría masiva, nodos remotos, enlaces intermitentes, cloud → MQTT (nunca control).

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

📥 Descarga la checklist: "De prototipo Arduino a instalación industrial"
Los 12 pasos — comunicaciones incluidas — para llevar tu proyecto de la mesa al cuadro eléctrico, en PDF imprimible.
👉Descarga la checklist gratuita →

Casi toda nuestra gama habla varios de estos protocolos a la vez: los M-Duino llevan Ethernet y RS-485 (Modbus) integrados de serie, los ESP32 PLC añaden WiFi y BLE, y la familia Raspberry Pi PLC habla Modbus RTU, Modbus TCP, RS-485 y Ethernet sobre Linux. Si tu duda es qué equipo poner en la frontera OT/IT, empieza por el GateBerry — un gateway basado en Raspberry Pi que hace de puente entre sensores, equipos locales y la nube, totalmente compatible con Node-RED, MQTT y plataformas abiertas: GateBerry, la pasarela industrial para PLC — es la consulta que más resolvemos.