OPC UA vs MQTT es uno de los debates más habituales del IoT industrial, y casi siempre se plantea mal. Esta comparativa explica para qué se diseñó cada protocolo, en qué se diferencian en modelado de información, patrón de comunicación, seguridad y conectividad cloud, y por qué la respuesta más común en el mundo real es "OPC UA en el edge, MQTT hacia el cloud". Al final sabrás cuál usar en cada capa de tu arquitectura.
Dos protocolos, dos tareas distintas
OPC UA (Open Platform Communications Unified Architecture) es un marco de interoperabilidad industrial. No solo define cómo se mueven los bytes, sino cómo se describe una máquina a sí misma: objetos, variables, métodos, tipos, unidades de ingeniería, alarmas e históricos. Un cliente se conecta a un servidor, explora su espacio de direcciones y lee, escribe, se suscribe o llama a métodos. Está normalizado como IEC 62541 y viene integrado en muchos PLC, CNC y sistemas SCADA modernos.
MQTT es un protocolo de mensajería ligero de publicación/suscripción. Los clientes se conectan a un broker central, publican mensajes en topics y se suscriben a los topics que les interesan. MQTT no dice deliberadamente nada sobre el significado del payload; mueve bytes de forma eficiente y fiable sobre redes poco fiables. Es un estándar OASIS, y las versiones 3.1.1 y 5.0 están ampliamente extendidas. Si el concepto de broker es nuevo para ti, empieza por qué hace un broker MQTT.
Así que la comparación se parece un poco a comparar un esquema de base de datos con un bus de mensajes. Ambos mueven datos, pero el valor que aporta cada uno es diferente.
OPC UA vs MQTT de un vistazo
| Dimensión | OPC UA (cliente/servidor) | MQTT |
|---|---|---|
| Patrón principal | Sesiones cliente/servidor; suscripciones por sesión | Publicación/suscripción a través de un broker |
| Modelo de información | Espacio de direcciones rico, tipado y navegable con metadatos | Ninguno integrado; topics y payloads los defines tú o una especificación como Sparkplug B |
| Descubrimiento | Explorar el servidor para encontrar nodos y tipos | Suscribirse con comodines; sin descubrimiento de esquema integrado |
| Acoplamiento | Cada consumidor se conecta a cada servidor | Productores y consumidores solo conocen el broker |
| Sentido de la red | El cliente debe alcanzar el servidor, normalmente entrando en la red OT | Todos los clientes se conectan hacia fuera con el broker |
| Huella | Stack más pesado, mensajes más grandes, estado de sesión | Librerías cliente muy pequeñas, cabecera mínima de 2 bytes |
| Seguridad | Certificados de aplicación, firma y cifrado, tokens de usuario | TLS en el transporte, usuario/contraseña o certificados de cliente, autorización en el broker |
| Escritura y llamadas a métodos | Nativas: escribir variables, llamar a métodos | Posibles mediante topics de comandos, pero por convención |
| Alcance cloud e IT | Soporte nativo limitado en plataformas cloud | Soportado por prácticamente todas las plataformas IoT y lenguajes |
| Hábitat típico | PLC, CNC, SCADA, MES en la red de planta | Gateways edge, aplicaciones cloud, dashboards, móviles, dispositivos con recursos limitados |
OPC UA también tiene una extensión PubSub (Parte 14) que puede usar MQTT como transporte. Eso difumina bastante la frontera y lo tratamos en nuestro artículo sobre OPC UA PubSub sobre MQTT. Esta comparativa se centra en el OPC UA cliente/servidor clásico porque es lo que expone hoy la mayoría de los equipos instalados.
Modelado de información: la gran ventaja de OPC UA
La característica más potente de OPC UA es la semántica. Un servidor puede decir "esta es una variable llamada SpindleTemperature, es un Double, su unidad son grados Celsius, su rango va de 0 a 120 y pertenece a un objeto de tipo MachineToolType". Las especificaciones complementarias (companion specifications) van más allá y definen modelos estándar para clases enteras de máquinas, de modo que las inyectoras de dos fabricantes distintos pueden parecer iguales para un cliente.
MQTT no trae nada de esto de serie. Un payload 47.3 en un topic son solo bytes. Los equipos lo compensan de tres maneras:
- Convenciones de topics, como una jerarquía ISA-95, para que la propia ruta aporte contexto. Nuestra guía de topics MQTT ISA-95 muestra una estructura práctica.
- JSON autodescriptivo con valor, unidad, calidad y marca de tiempo en cada mensaje.
- Sparkplug B, que añade un payload definido, certificados de nacimiento y muerte y metadatos de métricas sobre MQTT.
Si el modelado rico es innegociable para un caso de uso, por ejemplo un MES que lee recetas y llama a métodos en una máquina, OPC UA es la opción natural.
Patrón de comunicación: sesiones frente a desacoplamiento
Con el OPC UA clásico, cada consumidor abre una sesión con cada servidor que necesita. Diez aplicaciones leyendo de cincuenta máquinas pueden suponer cientos de sesiones, cada una consumiendo memoria en PLC que nunca se dimensionaron para ello. Añadir un nuevo consumidor implica tocar reglas de firewall y la configuración del servidor.
Con MQTT, cada máquina o gateway publica una sola vez en el broker y cualquier número de consumidores se suscribe. Añadir un nuevo dashboard o un trabajo de analítica no toca nada en la planta. Lo mismo vale para un gemelo digital 3D de la línea: se suscribe a los mismos topics como un consumidor más. Este desacoplamiento es la razón principal por la que MQTT se convirtió en la columna vertebral del patrón Unified Namespace.
La otra cara: MQTT pone el broker en la ruta crítica. Si cae, no fluye nada, así que la disponibilidad, la monitorización y la capacidad del broker se convierten en preocupaciones operativas. Esa es una de las razones por las que muchos equipos eligen un broker MQTT gestionado en lugar de operar brokers por su cuenta.
Modelos de seguridad
Ambos protocolos pueden asegurarse bien, y ambos pueden desplegarse de forma insegura.
La seguridad de OPC UA es a nivel de aplicación: cada cliente y servidor tiene un certificado X.509 de instancia de aplicación, y la sesión puede firmarse, o firmarse y cifrarse. La autenticación de usuario va por encima. El dolor operativo habitual es la gestión de la confianza de certificados en decenas de dispositivos.
La seguridad de MQTT es sobre todo a nivel de transporte y de broker: TLS para el cifrado, credenciales o certificados de cliente para la autenticación y reglas en el broker sobre lo que puede hacer cada cliente. La ventaja arquitectónica es el sentido de la conexión. Como cada cliente MQTT se conecta hacia fuera con el broker, no abres puertos entrantes hacia la red OT. Nuestro artículo de buenas prácticas de seguridad MQTT recoge lo esencial.
Conectividad cloud
Aquí es donde la comparación está más desequilibrada. Los servicios cloud, las aplicaciones web y móviles y las herramientas de datos hablan casi universalmente MQTT, HTTP o ambos. Muy pocos hablan OPC UA cliente/servidor de forma nativa, y exponer un servidor OPC UA directamente a internet es una mala idea. La pequeña huella de MQTT, su tolerancia a enlaces inestables, los keep-alives y los mensajes Last Will se diseñaron exactamente para este tipo de conexión remota e intermitente.
El patrón que usan la mayoría de las plantas: OPC UA en el edge, MQTT hacia el cloud
En la práctica, la pregunta rara vez es "¿OPC UA o MQTT?", sino "¿dónde va cada uno?". El patrón que se repite una y otra vez:
Level 0-2 Machines and PLCs -> OPC UA servers (native or via drivers)
Level 2-3 Edge gateway -> OPC UA client: subscribes to tags
-> maps nodes to a topic hierarchy, adds units and quality
Level 3-4 MQTT broker -> single hub (Unified Namespace)
Level 4+ Consumers -> dashboards, historian, MES, analytics, cloud apps
El gateway conserva la semántica de OPC UA donde viven las máquinas y la traduce a una estructura de topics y un formato de payload que todo lo demás puede consumir. Nuestro tutorial para construir un gateway OPC UA a MQTT recorre una implementación funcional en Python que publica en un broker mediante TLS.
Puedes ver en segundos cómo es el lado MQTT de ese patrón. Este comando publica un valor procedente de OPC UA, con su contexto, en el servidor MQTT público gratuito, pensado solo para pruebas:
mosquitto_pub -h broker.connectmq.com -p 1883 -i opcua-vs-mqtt-5d2e \
-t "connectmq/demo/5d2e/plant1/line1/cnc1/spindle_temp" -r -q 1 \
-m '{"value":47.3,"unit":"degC","quality":"Good","source":"ns=2;s=Line1.CNC1.SpindleTemp"}'
Cualquier suscriptor de connectmq/demo/5d2e/# lo recibe ahora sin saber nada de OPC UA.
Lista de decisión
Usa esta lista para decidir por caso de uso, no por planta:
- ¿Un cliente necesita explorar, escribir consignas o llamar a métodos en una máquina? Usa OPC UA cliente/servidor.
- ¿Muchos consumidores necesitan los mismos datos, algunos fuera de la red de planta? Publícalos en MQTT.
- ¿Los dispositivos tienen recursos limitados (microcontroladores, sensores a batería) o usan enlaces celulares? MQTT.
- ¿Necesitas modelos de máquina neutrales respecto al fabricante con semántica estándar? OPC UA y sus companion specifications; si haces de puente, traslada la semántica a los payloads MQTT.
- ¿Quieres un Unified Namespace? MQTT como hub, con OPC UA alimentándolo desde el edge.
- ¿No puedes abrir puertos entrantes en el firewall? Las conexiones solo salientes de MQTT encajan.
- ¿Necesitas control determinista de baja latencia entre controladores? Ninguno de los dos es la herramienta adecuada para el control en tiempo real estricto; usa el bus de campo diseñado para ello.
Dónde encaja ConnectMQ
ConnectMQ es el lado MQTT de esta arquitectura: un broker MQTT gestionado que soporta MQTT 3.1.1 y 5.0 sobre TCP, TLS y WebSockets. No habla OPC UA por sí mismo, y es así por diseño; tu gateway edge se encarga de OPC UA y le publica en MQTT. ConnectMQ detecta topics ISA-95 y de Unified Namespace, los muestra en un explorador de topics en vivo y en una vista de dispositivos organizada por niveles ISA-95, y puede decodificar payloads Sparkplug B si tu gateway usa ese formato. Para una visión general del stack completo, consulta nuestra guía de IoT industrial con MQTT.
Empieza con ConnectMQ
Prueba el patrón edge-cloud sin instalar un broker. Regístrate en app.connectmq.com con el plan Serverless gratuito (sin tarjeta de crédito), crea un broker y apunta tu gateway OPC UA hacia él con las credenciales generadas. Esa misma tarde tendrás datos de planta fluyendo hacia un broker MQTT privado en la nube.
Preguntas frecuentes
¿MQTT está sustituyendo a OPC UA?
No. MQTT está sustituyendo a las integraciones punto a punto por encima de la planta, mientras que OPC UA sigue siendo la forma estándar en que muchas máquinas exponen datos estructurados. La mayoría de las arquitecturas usan ambos.
¿Qué es más seguro, OPC UA o MQTT?
Ambos son seguros si se configuran correctamente. OPC UA protege las sesiones con certificados de aplicación; MQTT se apoya en TLS y en la autenticación del broker, con la ventaja de que los clientes solo hacen conexiones salientes.
¿Puede OPC UA usar MQTT directamente?
Sí. OPC UA Parte 14 PubSub define MQTT como transporte con codificaciones JSON o UADP binaria, de modo que los publicadores OPC UA pueden enviar mensajes a través de un broker MQTT estándar.
¿Qué es mejor para un Unified Namespace, OPC UA o MQTT?
MQTT es el hub habitual de un Unified Namespace gracias al desacoplamiento de la publicación/suscripción. Los servidores OPC UA suelen alimentar ese namespace a través de gateways edge.
