OPC UA vs MQTT: cómo unir el SCADA de planta con la nube

OPC UAOProtocoloOPC UAEstándar de interoperabilidad para la automatización industrialVer perfil vs MQTTProtocoloMQTTEl protocolo pub/sub estándar del IoTVer perfil es un falso dilema en casi todas las plantas: OPC UA dice qué significa el dato, MQTT lo transporta, y casi siempre hacen falta los dos.

Aun así, la pregunta sale en casi todos los proyectos de IoTITérminoIoT (Internet de las cosas)El IoT (Internet of Things) es la red de objetos físicos con sensores, software y conectividad que recogen e intercambian datos y actúan de forma autónoma.Ver perfil industrial. El equipo de automatización tiene servidores OPC UA en sus PLC y en el SCADA, y se fía de ellos. El equipo de sistemas o de nube quiere MQTT porque atraviesa cortafuegos sin complicaciones y escala a miles de emplazamientos. Cada uno tiene razón en su mitad del problema, y la discusión empieza cuando se le pide a un protocolo que haga el trabajo del otro.

Esta guía compara los dos donde importa en un proyecto real: modelo de datos, transporte, seguridad, ancho de banda y lo que pasa en la frontera entre la red de planta e internet. Después recorre tres arquitecturas que funcionan en producción y una lista corta de preguntas para elegir entre ellas. Está pensada para integradores e ingenieros de planta que ya saben qué hace un sistema SCADA y necesitan llevar sus datos a otro sitio sin romper nada.

OPC UA vs MQTT: la respuesta corta

Si solo vas a leer una sección, que sea esta.

OPC UA (Open Platform Communications Unified Architecture, normalizado como IEC 62541) es un marco de interoperabilidad industrial. Define cómo expone una máquina sus datos en forma de modelo estructurado: una bomba es un objeto con una velocidad, un estado, una alarma y un método para arrancarla, cada uno con su tipo, sus unidades y su rango de ingeniería. Un cliente puede recorrer ese modelo sin saber nada de antemano.

MQTT (Message Queuing Telemetry Transport, estándar de OASIS) es un transporte ligero de publicación y suscripción. Los equipos publican mensajes en topics de un broker, y quien esté suscrito los recibe. A MQTT no le importa qué va dentro del mensaje. Esa es su ventaja y también su límite.

Así que la comparación honesta no es «cuál es mejor». Es esta:

• Dentro de la planta, entre PLC, SCADA e históricos, suele ganar OPC UA. El modelo y el soporte de los fabricantes ya están ahí.
• De la planta a la nube, y entre muchos emplazamientos, suele ganar MQTT. La conexión sale desde dentro, pesa poco y aguanta enlaces malos.
• En la frontera, algo tiene que traducir uno al otro sin perder el significado por el camino. Ahí es donde la mayoría de proyectos sale bien o mal.

Qué hace bien OPC UA

OPC UA sustituyó al OPC clásico, que dependía de DCOM de Windows y era un suplicio entre redes. La arquitectura unificada no depende de la plataforma y funciona en cualquier cosa, desde un PLC hasta un servidor en la nube.

Un modelo, no solo valores

La idea central es el espacio de direcciones. Cada dato es un nodo con nombre, tipo, unidad y relaciones con otros nodos. Las especificaciones complementarias van más allá: los grupos de cada industria publican modelos estándar para máquina herramienta, robótica, líneas de envasado y otros equipos, de modo que dos máquinas de fabricantes distintos se describen igual.

Para un ingeniero de planta, esto significa que una pantalla nueva del SCADA o un histórico pueden descubrir qué ofrece una máquina en lugar de leer una hoja de cálculo con direcciones de registros. Solo eso ahorra días de puesta en marcha en una línea mediana.

Suscripciones, métodos e histórico

Un cliente OPC UA no tiene por qué sondear. Crea una suscripción con elementos monitorizados, un intervalo de muestreo y una banda muerta, y el servidor envía solo los cambios. En la misma sesión puede llamar a métodos de la máquina, leer datos históricos y recibir alarmas y condiciones con su estado. MQTT no trae nada de esto de serie.

Seguridad desde el diseño

Cada aplicación OPC UA tiene un certificado X.509. Las conexiones pueden ir sin seguridad, con mensajes firmados o con mensajes firmados y cifrados, y además los usuarios se autentican. Bien hecho, es una seguridad sólida. Mal hecho, alguien pone el modo en None durante la puesta en marcha y nadie lo vuelve a cambiar.

Dónde le cuesta a OPC UA

El modelo cliente-servidor clásico está orientado a conexión: el cliente abre una sesión contra un servidor que escucha, normalmente en el puerto 4840. Para un servicio en la nube eso significa entrar *dentro* de la red de planta, algo que la mayoría de equipos de seguridad OT rechaza, y con razón. La especificación añadió la conexión inversa para que sea el servidor quien marque hacia fuera, pero el soporte en el parque instalado es desigual.

Las pilas de software también pesan más que las de MQTT, y gestionar certificados en decenas de emplazamientos es trabajo de operación de verdad. Todos los certificados caducan, y uno caducado se parece muchísimo a un fallo de red a las tres de la mañana.

Qué hace bien MQTT

MQTT se diseñó para enlaces poco fiables y de poco ancho de banda, y se nota. La cabecera fija ocupa dos bytes. Un equipo abre una sola conexión TCP de salida hacia un broker, la mantiene viva y publica cuando tiene algo que decir.

Hecho para el tramo de la planta a la nube

Como es la planta quien abre la conexión, no hay que abrir ningún puerto de entrada en el cortafuegos OT. Con TLS en el puerto 8883, el tráfico parece una sesión cifrada de salida más. Esta propiedad explica casi toda la popularidad de MQTT en IoT industrial.

El protocolo también lleva bien los enlaces malos:

• Los niveles de calidad de servicio 0, 1 y 2 permiten elegir, mensaje a mensaje, entre menos carga y más garantía de entrega.
• Las sesiones persistentes conservan suscripciones y mensajes en cola cuando un cliente se cae y vuelve.
• Los mensajes retenidos dan a un suscriptor nuevo el último valor conocido al instante.
• El último deseo (last will) avisa a todos cuando un publicador desaparece sin despedirse.

La versión 3.1.1 sigue siendo la más desplegada, y MQTT 5.0 añade propiedades de usuario, códigos de motivo, caducidad de mensajes y suscripciones compartidas. Los detalles de brokers, sesiones y dimensionado están en nuestra guía de brokers MQTT.

Dónde le cuesta a MQTT

MQTT mueve bytes. No dice que `linea2/prensa4/temp` está en grados Celsius, se muestrea cada segundo y salta una alarma a 85. Cada proyecto se inventa su árbol de topics y su formato de mensaje, y dos integradores se inventarán dos distintos.

Por eso hay convenciones encima de MQTT. La especificación Sparkplug de Eclipse define un espacio de nombres de topics, un formato binario de mensaje y mensajes de nacimiento y muerte para que el suscriptor sepa qué equipos están en línea y qué métricas publican. Otros equipos usan JSON sin más y una convención de nombres escrita. En cualquier caso, el significado tiene que salir de algún sitio, y en una planta que ya usa OPC UA, la fuente obvia es el propio modelo OPC UA.

Para una comparación más amplia de MQTT con otros transportes, mira MQTT vs CoAP vs HTTP.

OPC UA vs MQTT, cara a cara

La tabla resume las diferencias que importan al diseñar el puente.

Una fila merece más atención que las demás. La especificación PubSub de la Parte 14 de la OPC Foundation permite que el propio OPC UA publique sobre MQTT, con el modelo de datos OPC UA dentro de los mensajes. Sobre el papel, eso cierra el debate OPC UA vs MQTT. En la práctica, hoy pocos PLC y servidores SCADA instalados lo soportan, así que la mayoría de proyectos sigue necesitando un gateway.

Tres arquitecturas que funcionan en la práctica

Hay muchas formas de dibujar el esquema, pero tres cubren casi todos los proyectos reales. Se diferencian en dónde se hace la traducción y en quién tiene que abrir qué en la red.

1. Gateway en el edge: entra OPC UA, sale MQTT

Un gateway de software pequeño corre en un PC industrial o en un servidor de la planta. Hace de cliente OPC UA frente a los PLC o el servidor SCADA, se suscribe a las variables que importan, las asigna a topics MQTT y las publica hacia fuera, con TLS, al broker de la nube.

Es el patrón más habitual porque no exige nada a los equipos existentes. Los PLC siguen como estaban, el cortafuegos OT solo permite una conexión de salida y el gateway puede guardar datos mientras se cae el enlace a internet.

El trabajo está en la correspondencia entre variables y topics. Una regla útil: que la metadata OPC UA viaje con el valor. La unidad de ingeniería, el rango y el código de calidad deberían ir en el mensaje o en una descripción publicada, no solo en la cabeza de alguien.

El gateway es también donde se controla el ancho de banda. Sondear 1.800 variables cada segundo produce 1.800 valores por segundo. Si publicas por excepción, con una banda muerta razonable por variable, y solo uno de cada diez valores cambia de forma significativa cada segundo, el flujo baja a unos 180 valores por segundo. Lo notan la factura de la nube y los paneles.

Así es como Cloud Studio IoT conecta OPC UA, ModbusMProtocoloModbusEl bus de campo industrial más extendidoVer perfil y otros protocolos industriales: un módulo de software instalado en el edge hace de gateway y envía los datos a la plataforma por MQTT de forma segura. El servidor MQTT de la plataforma es propio de cada instancia y usa TLS en el puerto 8883, de modo que la planta solo necesita esa salida.

2. OPC UA PubSub nativo sobre MQTT

Los controladores más nuevos y algunos productos SCADA pueden publicar mensajes OPC UA PubSub directamente en un broker MQTTBTérminoBroker MQTTUn broker MQTT es el servidor central que recibe los mensajes de los publishers y los distribuye a los subscribers según los temas. Ejemplos: Mosquitto, EMQX, HiveMQ.Ver perfil. El gateway desaparece y el modelo de datos viaja intacto.

Es el diseño más limpio cuando los equipos lo soportan. Antes de contar con ello, comprueba tres cosas: que todos los equipos de la línea soporten PubSub sobre MQTT (no solo sobre UDP), qué codificación usan (JSON o el formato binario UADP) y si la plataforma que recibe los datos sabe decodificarla. Un parque mixto suele acabar con un gateway de todos modos para las máquinas antiguas.

3. Cliente OPC UA directo por VPN

La aplicación en la nube hace de cliente OPC UA y se conecta al servidor OPC UA de la planta a través de una VPN entre sedes. No se traduce nada.

Funciona para una sola planta con una VPN ya montada y un equipo que ya gestiona certificados. Escala mal. Cada planta nueva añade un túnel, la nube mantiene una sesión por servidor y una caída de la VPN supone un hueco de datos sin nada guardado en el edge. La mayoría de proyectos que empiezan así pasan a un gateway en el edge en la tercera o cuarta planta.

Una nota sobre el unified namespace

En estas conversaciones vas a oír hablar del «unified namespace». La idea es poner un broker MQTT en el centro de la empresa y que todos los sistemas publiquen su estado actual en un único árbol de topics bien estructurado por planta, área, línea y máquina. Es más un principio de arquitectura que un producto, y depende por completo de la disciplina con la que se respeten las convenciones de topics y mensajes. Los modelos OPC UA son una buena fuente para esa estructura; MQTT es el transporte habitual.

Seguridad a los dos lados del puente

El puente entre OPC UA y MQTT es también el puente entre la red OT e internet. Las decisiones de seguridad aquí importan más que la elección de protocolo.

En el lado de la planta:

• Nunca dejes la seguridad de OPC UA en None en producción. Usa conexiones firmadas y cifradas y dale al gateway su propio certificado y su propio usuario, con permisos de solo lectura salvo que tenga que escribir.
• Limita lo que ve el gateway. Debe suscribirse a las variables que necesita el proyecto, no recorrer todo el espacio de direcciones de cada PLC.
• Planifica la renovación de certificados antes de que caduque el primero. Deja escrito quién los renueva y cuándo.

En el lado de la nube:

• Solo conexiones de salida. El gateway se conecta al broker; nada desde internet se conecta a la planta.
• TLS en todas las conexiones MQTT, con credenciales por planta, para poder revocar un gateway comprometido sin tocar los demás.
• Escribir es otra decisión. Mandar consignas u órdenes desde la nube a un PLC es posible, pero debe ser explícito, limitado a variables concretas y quedar registrado.

El marco de referencia para la seguridad de sistemas de control industrial es ISA/IEC 62443, que organiza la planta en zonas y conductos. En sus términos, el gateway es un conducto y merece el mismo escrutinio que cualquier otro. Para el panorama general de amenazas OT, mira nuestro artículo sobre ciberseguridad OT.

Cómo elegir para tu proyecto

La decisión OPC UA vs MQTT se convierte en una lista corta de preguntas en cuanto conoces el parque instalado.

1. ¿Qué hablan ya los equipos? Si los PLC y el SCADA exponen OPC UA, úsalo dentro de la planta. No sustituyas una capa OPC UA que funciona para «estandarizar en MQTT».
2. ¿Cuántas plantas hay, y cuántas habrá? Una sola planta puede vivir con una VPN y un cliente directo. A partir de cinco, casi siempre compensa un gateway en el edge y MQTT.
3. ¿Qué permite el equipo de seguridad OT? Si las conexiones de entrada a la planta están prohibidas, que es lo normal, el transporte a la nube es MQTT de salida.
4. ¿Quién define el significado del dato? Decide pronto si llevas el modelo OPC UA dentro del mensaje, si adoptas una convención como Sparkplug o si escribes tu propio estándar de topics. Cambiarlo con 20 plantas en marcha sale caro.
5. ¿Hace falta escribir en la planta? Leer es fácil con cualquier arquitectura. Escribir consignas desde la nube exige un diseño pensado, aprobaciones y un registro de auditoría.
6. ¿La plataforma de destino acepta lo que le mandas? Comprueba el formato de mensaje, la estructura de topics y los requisitos de TLS antes de comprar gateways.

Para la mayoría de integradores la respuesta es la misma: OPC UA en planta, un gateway en el edge en cada emplazamiento, MQTT con TLS hacia la nube y una convención de nombres escrita que sobreviva al primer proyecto. El despliegue completo, del piloto a varias plantas, está en nuestra guía de implementación de IoT industrial.

Una buena prueba para cualquier propuesta es preguntar qué pasa si se cae el enlace a internet durante cuatro horas. Si la respuesta incluye datos perdidos o un técnico conduciendo hasta la planta, la arquitectura no está terminada.

Conclusión

La pregunta OPC UA vs MQTT tiene una respuesta práctica en cuanto separas el significado del transporte. Lo esencial:

• OPC UA es el protocolo adecuado dentro de la planta: lleva el modelo de datos, los métodos, las alarmas y una seguridad de aplicación sólida.
• MQTT es el transporte adecuado de la planta a la nube: sale desde dentro, pesa poco y aguanta enlaces pobres.
• El gateway en el edge es donde los proyectos salen bien o mal. Que cada valor viaje con su unidad, su rango y su calidad, y publica por excepción.
• OPC UA PubSub sobre MQTT es el diseño más limpio a largo plazo, pero comprueba el soporte de los equipos antes de contar con él.
• La seguridad vive en el puente: certificados en el lado OPC UA, TLS y credenciales por planta en el lado MQTT, y ninguna conexión de entrada a la planta.

Cuando el dato llega a la nube, el trabajo pasa a la telemetría: almacenamiento, paneles y alarmas que los operadores lean de verdad. Si estás evaluando dónde debería acabar ese dato, nuestra guía de compra de plataformas SCADA IoT recoge qué comprobar, y la página de la solución para sistemas SCADA muestra cómo lo resuelve la plataforma. Para revisar la arquitectura de una planta concreta, habla con el equipo.

Preguntas frecuentes

¿Es mejor OPC UA o MQTT?

Ninguno es mejor, porque hacen trabajos distintos. OPC UA describe qué significa el dato y MQTT lo transporta. Dentro de la planta, entre PLC, SCADA e historiadores, suele ganar OPC UA. De la planta a la nube y entre muchas plantas, suele ganar MQTT.

¿Se pueden usar OPC UA y MQTT juntos?

Sí, y es el diseño más habitual. Un gateway de software en el edge actúa como cliente OPC UA hacia los PLC o el servidor SCADA, mapea las variables que interesan a topics MQTT y publica hacia el broker de la nube con una conexión saliente sobre TLS.

¿Qué es OPC UA PubSub sobre MQTT?

Es la parte 14 de la especificación OPC UA, que permite a OPC UA publicar sobre MQTT manteniendo su modelo de datos dentro de los mensajes. Hoy lo soportan pocos PLC y servidores SCADA instalados, así que comprueba el soporte de cada equipo, la codificación de los mensajes (JSON o UADP) y si la plataforma que recibe el dato sabe decodificarla.

¿Por qué se usa MQTT para enviar los datos de planta a la nube?

Porque la conexión la abre la planta, así que no hay que abrir ningún puerto de entrada en el cortafuegos OT. Además MQTT tolera los enlaces malos: los niveles de calidad de servicio, las sesiones persistentes, los mensajes retenidos y el last will cubren las caídas y las reconexiones.

¿Qué es Sparkplug?

Eclipse Sparkplug es una especificación que se apoya en MQTT. Define un espacio de nombres para los topics, un payload binario y mensajes de nacimiento y muerte, de modo que un suscriptor sabe qué equipos están en línea y qué métricas publican.

¿Qué puertos usan OPC UA y MQTT?

Un servidor OPC UA suele escuchar en el puerto 4840. MQTT sobre TLS usa el puerto 8883, con una conexión saliente desde la planta hacia el broker.