OPC UA vs MQTT: cuál elegir para conectar tu planta

OPC UA y MQTT no compiten: resuelven capas distintas. OPC UA es el estándar para leer datos de máquinas y PLCs dentro de la planta, con modelo de información rico y seguridad integrada. MQTT es el protocolo de transporte ligero para mover esos datos hacia la nube y entre sistemas. La arquitectura habitual usa ambos: OPC UA en el acceso a máquina, MQTT en la distribución.

Por qué "OPC UA vs MQTT" suele ser una pregunta mal planteada

La pregunta aparece constantemente en proyectos de conectividad industrial, y casi siempre esconde una confusión de capas. OPC UA y MQTT ocupan lugares distintos de la arquitectura: uno define qué es el dato (un modelo de información con tipos, unidades, jerarquías y semántica) y el otro define cómo viaja (un transporte de publicación y suscripción pensado para redes poco fiables). Comparar los dos como alternativas excluyentes es como comparar un idioma con un servicio de mensajería: se pueden usar juntos, y de hecho es lo habitual.

Dicho esto, la pregunta tiene una versión legítima: en cada tramo concreto de la arquitectura (del PLC al gateway, del gateway a la nube, entre aplicaciones) hay que elegir un mecanismo, y ahí sí conviene entender las fortalezas de cada uno. Este artículo recorre esa decisión tramo a tramo, con una tabla comparativa de criterios y casos de uso según el tamaño de la planta.

Qué resuelve cada protocolo

OPC UA (IEC 62541) nació para unificar el acceso a datos de automatización. Su valor central es el modelo de información: un servidor OPC UA no expone registros numerados sino un espacio de direcciones navegable, con nodos tipados, unidades de ingeniería, jerarquías de objetos y metadatos. El cliente puede descubrir qué ofrece el servidor sin documentación externa. Incluye seguridad de serie (autenticación por certificados, firmado y cifrado por canal), suscripciones con banda muerta, lectura histórica, alarmas y métodos invocables. Es el estándar de facto para hablar con PLCs, CNCs y equipos modernos dentro de la red OT.

MQTT nació en el otro extremo: telemetría sobre enlaces caros e inestables. Es deliberadamente mínimo: un broker central, clientes que publican y se suscriben a topics jerárquicos, tres niveles de QoS, sesiones persistentes y el mecanismo de last will para detectar desconexiones. No impone ningún formato de payload: el contenido del mensaje es responsabilidad de quien publica. Esa ligereza es su fortaleza (funciona igual con diez clientes que con diez mil, atraviesa firewalls con una única conexión saliente) y también su carencia: sin una convención de topics y payloads, cada integración inventa la suya. Sparkplug B existe precisamente para cubrir ese hueco con una convención estándar sobre MQTT.

Tabla comparativa: OPC UA frente a MQTT

Criterio	OPC UA	MQTT
Naturaleza	Estándar de interoperabilidad con modelo de información	Protocolo de transporte publish/subscribe
Modelo de comunicación	Cliente-servidor (con extensión PubSub)	Publicación y suscripción vía broker central
Semántica del dato	Integrada: tipos, unidades, jerarquías, descubrimiento	Ninguna: el payload es libre (convenciones como Sparkplug B la añaden)
Peso y complejidad	Alto: stack completo, más exigente de implementar	Mínimo: clientes ligeros, apto para dispositivos pequeños
Redes poco fiables	No es su terreno natural: sesión pesada, reconexión costosa	Su terreno natural: QoS, sesiones persistentes, last will
Escalado de consumidores	Cada cliente añade carga al servidor (la máquina)	El broker desacopla: n consumidores sin tocar la fuente
Seguridad	Integrada en el estándar: certificados, firmado, cifrado	Delegada en TLS y en la autenticación del broker
Atravesar la frontera OT/IT	Requiere abrir acceso hacia la red de planta	Una única conexión saliente desde el gateway al broker
Papel típico en planta	Acceso a datos de máquina dentro de la red OT	Distribución del dato hacia nube, histórico y aplicaciones

Cuándo tiene sentido OPC UA

OPC UA es la elección natural en estos escenarios:

Acceso a máquinas y PLCs modernos. Si el equipo ya expone un servidor OPC UA, es la vía más rica y más mantenible de leerlo: el modelo de información evita el trabajo de mapear registros crudos y documentarlos aparte. Es el escenario central de la conectividad PLC.
Comunicación máquina a máquina dentro de la planta, donde la red local es fiable y la semántica importa: una celda que consulta el estado de la anterior, un sistema de calidad que lee parámetros del proceso.
Entornos con requisitos de seguridad formales. La seguridad por certificados de OPC UA está definida en el propio estándar y es auditable, algo relevante en sectores regulados.
Cuando el descubrimiento aporta valor: integradores y sistemas que necesitan explorar qué datos ofrece un equipo sin depender de hojas de señales externas.

Cuándo tiene sentido MQTT

Enviar datos de planta a la nube. Conexión saliente única, tolerancia a cortes, QoS por mensaje: es exactamente el problema para el que se diseñó. Combinado con buffering local en el gateway, garantiza histórico sin huecos (lo tratamos en la guía de edge industrial con buffering).
Muchos consumidores para el mismo dato. El broker desacopla productores de consumidores: histórico, dashboards, alertas y ERP se suscriben sin añadir ni una conexión a la máquina.
Construir un unified namespace: una jerarquía de topics común para toda la organización donde cada sistema publica y consume. Es el patrón que desarrollamos en la guía del unified namespace OT/IT.
Dispositivos pequeños y sensores IIoT donde un stack OPC UA completo no cabe o no compensa.

La arquitectura combinada: OPC UA abajo, MQTT arriba

La respuesta práctica en la mayoría de plantas no es elegir sino combinar. El patrón de referencia tiene tres tramos:

Máquina → gateway: OPC UA (o el protocolo nativo del equipo: Modbus, S7…). El gateway actúa como cliente OPC UA dentro de la red OT, donde la sesión pesada no molesta y el modelo de información aporta.
Gateway → broker: MQTT. El gateway normaliza (nombres con estructura, unidades de ingeniería, timestamp de origen) y publica por MQTT con el QoS adecuado, con una sola conexión saliente que respeta la segmentación OT/IT.
Broker → consumidores: MQTT. Histórico, analítica, dashboards y aplicaciones de negocio se suscriben a los topics que necesitan.

Este patrón conserva lo mejor de cada protocolo: la riqueza semántica de OPC UA donde se genera el dato y la robustez y el desacoplamiento de MQTT donde se distribuye. Es la base de los proyectos de integración OT/IT y de integración MQTT que abordamos en Captia Connect.

OPC UA sobre MQTT: cuando el modelo de información viaja por el broker

Existe una tercera vía que confunde a muchos equipos: OPC UA PubSub, definido en la parte 14 del estándar (IEC 62541-14). En lugar del modelo cliente-servidor clásico, PubSub permite que un servidor OPC UA publique sus datos sobre un transporte de publicación y suscripción, y MQTT es uno de los transportes contemplados. El publicador serializa los datos (en JSON o en el formato binario UADP) y los envía a un broker MQTT; los suscriptores los consumen sin abrir sesión contra la máquina. Sobre el papel, combina lo mejor de ambos mundos: la semántica tipada de OPC UA viajando con el desacoplamiento y la escalabilidad de MQTT.

En la práctica conviene templar las expectativas. La adopción de PubSub en el parque instalado es todavía desigual: muchos PLCs y equipos que exponen servidor OPC UA clásico no publican por PubSub, y las herramientas de consumo varían en madurez. Además, el suscriptor no navega el espacio de direcciones como lo haría un cliente clásico: depende de los metadatos que el publicador emite junto al dato, de modo que parte del valor de descubrimiento se traslada a la configuración del publicador. Y sigue haciendo falta un broker MQTT bien gobernado, con las mismas decisiones de topics, seguridad y calidad de servicio que en cualquier despliegue MQTT.

Nuestra lectura práctica: OPC UA sobre MQTT no invalida el patrón del gateway, lo refina. La decisión real del tramo gateway a broker no es el transporte (será MQTT en ambos casos) sino la convención de payload: JSON propio documentado, Sparkplug B o codificación OPC UA PubSub. Si tus equipos y tu plataforma de destino ya hablan PubSub, aprovecharlo evita traducciones; si no, una convención bien definida en el gateway ofrece hoy el mismo resultado con menos fricción, y deja abierta la migración a PubSub cuando el ecosistema lo justifique.

Casos de uso por tamaño de empresa

Planta pequeña (una línea, pocas máquinas)

Con cinco o diez máquinas y un objetivo inicial de visibilidad (contadores, estados, paros), la arquitectura mínima es un único gateway que lee por OPC UA o Modbus y publica por MQTT hacia un broker gestionado en la nube. No compensa montar infraestructura intermedia: la simplicidad de MQTT permite empezar con histórico y cuadros de mando en semanas y crecer después sin rehacer nada.

Planta mediana (varias líneas, mezcla de máquinas antiguas y modernas)

Aquí conviven equipos con servidor OPC UA y máquinas veteranas que solo hablan buses de campo o señales cableadas. El patrón útil es un gateway por línea o por área que unifique esa heterogeneidad: hacia abajo, cada protocolo nativo; hacia arriba, un único espacio de topics MQTT normalizado. La decisión importante deja de ser el protocolo y pasa a ser la convención de nombres y la calidad del dato publicado.

Grupo industrial (varias plantas, corporativo)

A escala multiplanta, MQTT aporta su mayor ventaja: cada planta publica su árbol de señales contra un broker (local o corporativo con puente entre ellos) y el corporativo consume una vista homogénea de todas las fábricas sin acceso directo a ninguna red OT. OPC UA sigue siendo el estándar de acceso a máquina dentro de cada planta, y la gobernanza se desplaza a mantener la convención de topics común y las políticas de seguridad del broker.

Preguntas frecuentes sobre OPC UA y MQTT

¿OPC UA y MQTT son alternativas o se combinan?

Se combinan. OPC UA es un estándar de interoperabilidad con modelo de información, ideal para acceder a datos de máquina dentro de la red OT; MQTT es un transporte ligero de publicación y suscripción, ideal para distribuir esos datos hacia la nube y entre aplicaciones. La arquitectura habitual usa OPC UA entre máquina y gateway, y MQTT del gateway hacia arriba.

¿Puedo enviar datos a la nube directamente con OPC UA?

Técnicamente es posible, pero implica exponer acceso hacia la red de planta y mantener sesiones pesadas sobre un enlace WAN que fallará. MQTT invierte el sentido: una única conexión saliente desde el gateway, con QoS y sesiones persistentes pensadas para redes poco fiables. Por eso el tramo hacia la nube se resuelve casi siempre con MQTT, con buffering local en el gateway.

¿Qué es Sparkplug B y qué aporta sobre MQTT?

MQTT no define el formato del mensaje ni la estructura de topics, y Sparkplug B es la convención estándar que cubre ese hueco: una jerarquía de topics fija, un payload binario con tipos y timestamps, y mensajes de nacimiento y muerte de cada nodo que permiten saber en todo momento qué equipos están publicando. Aporta a MQTT parte de la semántica que OPC UA trae de serie.

¿Qué es OPC UA sobre MQTT y cuándo debería plantearlo?

Es la variante PubSub de OPC UA (IEC 62541-14) usando MQTT como transporte: el publicador serializa los datos con su semántica OPC UA y los envía al broker, sin sesiones cliente-servidor contra la máquina. Tiene sentido cuando tus equipos y tu plataforma de destino ya lo soportan de serie. Si no es el caso, un gateway que publique MQTT con una convención de payload bien definida logra hoy el mismo resultado y permite migrar más adelante.

Mis máquinas antiguas no tienen OPC UA, ¿qué hago?

Es el caso más común, no la excepción. El gateway edge lee cada máquina por su protocolo nativo (Modbus, S7, buses de campo o señales cableadas a módulos de E/S), normaliza los valores a unidades de ingeniería y publica el conjunto por MQTT en un árbol de topics coherente. Los consumidores aguas arriba ven un espacio de señales homogéneo sin saber qué protocolo habla cada equipo.

Si estás decidiendo cómo conectar tu planta, en Captia Connect diseñamos esta arquitectura completa: desde la conectividad con PLCs y la ingesta edge hasta la integración MQTT con tu plataforma de datos industriales.