Si dedica algún tiempo al IoT industrial, habrá escuchado el mismo debate una y otra vez. ¿Deberíamos usar MQTT u OPC UA? La pregunta se plantea como una competencia, como si un protocolo debiera ganar y el otro perdiera. En la práctica, ese planteamiento es erróneo. MQTT y OPC UA se diseñaron para resolver problemas fundamentalmente diferentes, y la mayoría de las arquitecturas IIoT de producción terminan usando ambos, a menudo al mismo tiempo, en la misma puerta de enlace.
Este artículo analiza lo que realmente hace bien cada protocolo, dónde se descomponen y cómo decidir cuál pertenece a qué lado de su canal de datos.
TL;DR
- MQTT mueve bytes. Es un transporte liviano para mensajería de publicación/suscripción, independiente de la carga útil e ideal para redes restringidas y telemetría en la nube.
- OPC UA cambia de significado. Es un marco de modelado de información completo con seguridad integrada, datos semánticos y capacidad de descubrimiento, diseñado para la interoperabilidad en la planta.
- No son mutuamente excluyentes. OPC UA PubSub (Parte 14) puede ejecutarse sobre MQTT, brindándole datos semánticos además de pub/sub liviano.
- Una puerta de enlace IIoT típica habla OPC UA (o Modbus, EtherNet/IP, S7) en el lado sur y luego publica en agentes MQTT en el lado norte.
Dos orígenes diferentes, dos mentalidades diferentes
MQTT nació en 1999 en IBM, diseñado por Andy Stanford-Clark y Arlen Nipper para monitorear oleoductos a través de enlaces satelitales. Las limitaciones dieron forma a todo: asumir que la red es lenta, costosa y poco confiable; suponga que el dispositivo es pequeño; mantenga el encabezado del protocolo microscópico; Deje que la aplicación decida qué poner en la carga útil. Dos décadas más tarde, MQTT 3.1.1 se convirtió en un estándar ISO (ISO/IEC 20922) y MQTT 5 agregó características que las arquitecturas de nube modernas esperan: propiedades de usuario, vencimiento de mensajes, suscripciones compartidas, códigos de motivo.
OPC UA surgió de un mundo diferente. La Fundación OPC lanzó la primera especificación en 2008 como sucesora de OPC Classic (OLE para control de procesos), que había vinculado la industria a Microsoft DCOM. El mandato era romper esa dependencia y al mismo tiempo resolver un problema más difícil: ¿cómo hacer que un PLC Siemens, un controlador de movimiento Beckhoff, un servoaccionamiento B&R y un DCS Rockwell se entiendan semánticamente, y no solo intercambien bytes sin formato? La respuesta de OPC UA fue un modelo de información: un espacio de direcciones autodescriptivo donde los datos tienen tipos, relaciones y significado.
Estas historias de origen explican casi todas las decisiones de diseño que siguen.
Arquitectura
MQTT está centrado en el corredor y está desacoplado. Los editores envían mensajes a los temas. Los suscriptores registran interés en los temas. Un intermediario central distribuye el tráfico. Los editores y suscriptores nunca se conocen directamente. El intermediario puede ser una pequeña instancia integrada de Mosquitto o una implementación de HiveMQ en clúster que maneja millones de clientes; al protocolo no le importa.
OPC UA era originalmente cliente-servidor. Un cliente abre una sesión con un servidor, luego emite servicios: Browse para explorar el espacio de direcciones, Read y Write para acceder a los valores de los nodos, CreateSubscription para recibir notificaciones de los cambios. El servidor tiene estado y autoridad. Esto funcionó bien en una LAN, pero no se adaptó al estilo de nube.
OPC UA Parte 14 agregó PubSub en 2018, lo que admite transportes basados en intermediarios (MQTT, AMQP) y sin intermediarios (multidifusión UDP). Este fue el reconocimiento por parte de la fundación de que el mundo había pasado del mero cliente-servidor.
Protocol selection by design axis
bar chartModelos de datos
Aquí es donde los dos protocolos divergen más marcadamente.
MQTT es independiente de la carga útil. El cuerpo de un mensaje puede ser JSON, Protobuf, CBOR, binario sin formato, JPEG o texto sin formato. El protocolo lo lleva pero no lo interpreta. Su jerarquía de temas (fábrica/línea-3/horno/temperatura) es una convención de nomenclatura que usted mismo inventa y aplica. Si un suscriptor necesita saber que la "temperatura" está en grados Celsius y oscila entre 0 y 400, ese conocimiento vive fuera del protocolo: en la documentación, en un contrato, en un registro de esquema.
OPC UA está intensamente estructurado. Cada nodo en el espacio de direcciones tiene un NodeId, un BrowseName, un DataType, un Value y referencias a otros nodos. Las especificaciones complementarias superpuestas (PLCopen para lógica de control, Auto-ID para lectores RFID, MachineTool, Pump, Robotics, Weihenstephan para cervecerías) definen cómo se ve una "Pump" o "MachineTool" en términos de OPC UA. Un cliente que nunca ha visto su dispositivo puede conectarse, explorar el espacio de direcciones, descubrir qué está disponible y comprender la semántica de cada valor sin ningún acuerdo previo.
Esa capacidad (conectar y descubrir con semántica completa) es la característica principal de OPC UA. También es lo que lo hace más pesado.
Seguridad
MQTT se basa en TLS para el cifrado de transporte, nombre de usuario/contraseña o certificados de cliente para la autenticación y ACL a nivel de intermediario para la autorización. El modelo de seguridad reside en el corredor. Los diferentes corredores implementan la autorización de manera diferente y no existe una forma estándar de expresar permisos detallados en el protocolo mismo.
OPC UA tiene seguridad criptográfica integrada en la capa de mensajes. Certificados X.509 para cliente y servidor, políticas de seguridad configurables (Basic256Sha256, Aes256_Sha256_RsaPss), firma y cifrado por mensaje, autenticación de usuario independiente de la autenticación de aplicaciones y control de acceso basado en roles definido en la Parte 18. Para entornos que necesitan demostrar cumplimiento con IEC 62443 o NERC CIP, OPC UA le brinda primitivas que se asignan directamente a los estándares.
Este es uno de los argumentos más fuertes a favor de OPC UA en la planta: el modelo de seguridad fue diseñado para sistemas de control industriales desde el primer día.
Ancho de banda y gastos generales
El paquete mínimo de MQTT es de 2 bytes de encabezado fijo más un encabezado variable y carga útil. Una "PUBLICACIÓN" de un flotante de 4 bytes para un tema breve ocupa menos de 20 bytes en el cable. QoS 0 (disparar y olvidar), 1 (al menos una vez) y 2 (exactamente una vez) le permiten intercambiar confiabilidad por ancho de banda.
OPC UA Binary es más detallado. Una notificación simple de elemento monitoreado puede tener entre 50 y 100 bytes. Las sesiones, las suscripciones y los tokens de seguridad añaden una sobrecarga de gestión del estado. El protocolo fue diseñado para el rendimiento de LAN, no para el ancho de banda celular. OPC UA sobre HTTPS/SOAP (el antiguo enlace XML) era realmente pesado y ahora rara vez se usa.
OPC UA PubSub sobre MQTT o UDP reduce significativamente la sobrecarga, especialmente con la codificación JSON o UADP binaria. Para diseños totalmente nuevos que necesitan tanto estructura semántica como eficiencia de ancho de banda, esta combinación es cada vez más la respuesta correcta.
Descubribilidad
Conecte un cliente MQTT a un corredor que nunca haya visto. ¿Qué puedes hacer? Puede suscribirse a # (todo comodín) y observar el flujo de tráfico, luego intentar realizar ingeniería inversa en la jerarquía de temas y el formato de carga útil. Esa es su única opción sin documentación externa.
Conecte un cliente OPC UA a un servidor que nunca haya visto. Puede explorar todo el espacio de direcciones, inspeccionar tipos de datos, leer valores históricos, ver qué métodos se pueden llamar e identificar si el servidor implementa una especificación complementaria conocida. El protocolo es fundamentalmente introspectable.
Para los sistemas que evolucionan con frecuencia (donde se agregan, retiran o reconfiguran máquinas) esto es importante. Los clientes OPC UA se adaptan automáticamente. Los clientes de MQTT necesitan que sus contratos se actualicen fuera de banda.
Cuándo utilizar MQTT
MQTT es la elección correcta cuando:
- Está enviando telemetría desde dispositivos perimetrales a la nube, especialmente a través de enlaces celulares, satelitales u otros enlaces con ancho de banda limitado.
- Tiene muchos editores y muchos suscriptores y necesita un acoplamiento flexible entre ellos.
- Se está integrando con plataformas de IoT de hiperescala (AWS IoT Core, Azure IoT Hub, Google Cloud IoT, HiveMQ Cloud); todas hablan MQTT de forma nativa.
- Usted controla el formato de carga útil de un extremo a otro y no necesita interoperabilidad semántica entre proveedores.
- Necesita una huella de cliente pequeña en microcontroladores con recursos limitados.
- Está conectando datos de OT a sistemas de TI (Kafka, bases de datos de series temporales, herramientas de inteligencia empresarial).
Cuándo utilizar OPC UA
OPC UA es la elección correcta cuando:
- Está leyendo datos de PLC y controladores de movimiento en la planta. La mayoría de los principales proveedores (Siemens (S7-1500), Beckhoff (TwinCAT), B&R (Automation Studio), Rockwell, ABB incluyen servidores OPC UA en sus controladores.
- Necesita interoperabilidad semántica entre equipos de diferentes proveedores sin necesidad de escribir adaptadores personalizados para cada uno.
- Está operando en un entorno regulado (farmacéutico, automotriz, aeroespacial) donde la procedencia y la seguridad de los datos son importantes.
- Su estructura de datos cambiará con el tiempo y los clientes deberán adaptarse sin tener que volver a compilarlos.
- Está implementando una especificación complementaria conocida (Weihenstephan para cervecerías, Euromap para maquinaria para plásticos, Umati para máquinas herramienta).
- Necesita soporte integrado para acceso histórico, alarmas, condiciones y métodos (funciones invocables).
El patrón híbrido: OPC UA en el sur, MQTT en el norte
La mayoría de las puertas de enlace IIoT modernas, incluida Modibus MB213, implementan lo que es esencialmente una capa de traducción. En el lado sur (hacia el campo), la puerta de enlace habla los protocolos que hablan los dispositivos de campo: Modbus RTU y TCP, cliente OPC UA para PLC, EtherNet/IP, Siemens S7, BACnet para automatización de edificios. En el lado norte (hacia la nube o la empresa), publica en agentes MQTT, a menudo con TLS y certificados de cliente, y a menudo utiliza Sparkplug B para la estructura de carga útil.
Este patrón funciona porque los requisitos de cada lado son diferentes. La planta necesita determinismo, capacidad de descubrimiento y semántica estandarizada: territorio OPC UA. El camino hacia la nube necesita eficiencia del ancho de banda, un acoplamiento flexible y un amplio soporte del ecosistema: territorio MQTT. La puerta de entrada es donde ocurre la traducción.
Bujía B: MQTT con semántica
La mayor debilidad de Vanilla MQTT es la falta de estructura de carga útil. Sparkplug B, una especificación de Eclipse Foundation desarrollada por Cirrus Link, aborda este problema. Define:
Sparkplug B no coincide con la profundidad semántica de OPC UA: no hay especificaciones complementarias, ni métodos, ni modelo de alarmas y condiciones. Pero es dramáticamente más liviano que OPC UA y, para muchos casos de uso de telemetría en la nube, es el punto óptimo.
- Un espacio de nombres de tema estandarizado (spBv1.0/{group_id}/{message_type}/{edge_node_id}/{device_id})
- Certificados de nacimiento y defunción para que los suscriptores sepan qué métricas ofrece un editor y cuándo se desconecta
- Definiciones de métricas fuertemente tipadas con unidades de ingeniería, escala y estado histórico
- Numeración secuencial para detectar pérdida de mensajes
OPC UA PubSub sobre MQTT
Si desea la riqueza semántica de OPC UA pero la eficiencia de transporte de MQTT, OPC UA PubSub sobre MQTT (Parte 14) es cada vez más el patrón recomendado para diseños totalmente nuevos. El editor serializa mensajes OPC UA utilizando la codificación binaria UADP o la codificación JSON y los publica en temas MQTT. Los suscriptores reciben datos OPC UA completamente tipificados sin la sobrecarga del establecimiento de sesión.
La desventaja: la madurez de las herramientas es menor que la del cliente-servidor Vanilla MQTT u OPC UA. No todos los brokers, no todas las plataformas en la nube y no todos los sistemas SCADA manejan OPC UA PubSub con elegancia todavía. Espere que esto mejore rápidamente en los próximos dos o tres años.
Marco de decisión
En caso de duda, haga tres preguntas:
¿Dónde residen los datos y adónde deben ir? Planta a planta: OPC UA. Desde la planta hasta la nube: MQTT (u OPC UA PubSub sobre MQTT). De nube a nube: MQTT.
¿Quién controla el esquema? Si controlas tanto al editor como al suscriptor, MQTT más un formato de carga documentada funciona. Si necesita interoperabilidad entre proveedores sin acuerdos bilaterales, OPC UA.
¿Cuál es el presupuesto de ancho de banda? Celular, LPWAN o satélite: inclínese hacia MQTT. LAN cableada sin restricciones: OPC UA está bien.
| Preocupación | MQTT | OPC UA |
|---|---|---|
| Tamaño de carga útil | Mínimo | Superior |
| Semántica incorporada | No | Sí |
| Descubribilidad | No | Sí |
| Ecosistema de nube | Excelente | Limitado |
| Adopción en planta | Creciendo | Dominante |
| Modelo de seguridad | Transporte (TLS) | Mensaje + Transporte |
| Especificaciones complementarias | No (la bujía B más cercana) | Muchos |
| Mejor ajuste | Telemetría, conexión con la nube | Interoperabilidad, sistemas de control |
Pensamiento final
La respuesta honesta a "¿MQTT u OPC UA?" casi siempre es "ambos, en lugares diferentes". MQTT es la herramienta adecuada para mover bytes de manera eficiente a través de redes. OPC UA es la herramienta adecuada para transmitir significado entre proveedores. Una arquitectura IIoT bien diseñada utiliza cada uno de ellos cuando sus puntos fuertes se alinean con el problema que tiene ante sí.
Precisamente por eso existen las puertas industriales: para hacer que la frontera entre estos dos mundos sea limpia, segura y observable.
Modibus MB213 admite MQTT (con TLS, Sparkplug B y QoS configurable) y OPC UA (funciones de cliente y servidor) de fábrica, junto con Modbus RTU/TCP y otros protocolos industriales. Para analizar una arquitectura específica, [contáctenos](https://modibus.com).