Modbus vs OPC UA vs MQTT: qué protocolo industrial te conviene

Una planta tiene 40 medidores de energía que hablan Modbus, una línea nueva cuyos controladores exponen OPC UA y una petición de la dirección para ver todo en un tablero en la nube para el próximo trimestre. La pregunta de Modbus vs OPC UA vs MQTT casi nunca tiene una sola respuesta, porque los tres resuelven problemas distintos: Modbus mueve valores de registros, OPC UA describe qué significan esos valores y protege el acceso a ellos, y MQTT reparte mensajes a quien se suscriba. En este artículo comparamos cómo funciona cada uno, qué ofrece cada especificación, qué encontraron las mediciones independientes sobre su desempeño y cómo calcular si una red Modbus puede hacer polling lo bastante rápido.

Puntos clave

• Modbus es petición-respuesta: un cliente pregunta y un servidor contesta. Su modelo de datos son cuatro tablas de bits y registros de 16 bits numerados, sin nombres, unidades ni tipos. Una sola lectura regresa como máximo 125 registros.
• Los servidores OPC UA exponen un espacio de direcciones de nodos con tipo y enlazados entre sí, que los clientes pueden explorar, más servicios de lectura, escritura, suscripciones, alarmas y eventos. La seguridad (autenticación, firma, cifrado) es parte de la especificación.
• MQTT 5.0 es un transporte de publicación-suscripción a través de un broker, con tres garantías de entrega: como máximo una vez, al menos una vez y exactamente una vez. Lleva cualquier carga útil y no define modelo de datos.
• En el benchmark de Profanter et al. (2019), MQTT tuvo el menor overhead de conexión y de mensaje, mientras que la implementación OPC UA open62541 estuvo entre los menores tiempos de ida y vuelta. Los resultados dependieron de la implementación y de la carga.
• La elección muchas veces sigue la capa: Modbus en el equipo heredado, OPC UA para datos estructurados de planta y MQTT para distribución de muchos a muchos o de la planta a la nube.

El problema: tres protocolos, tres trabajos distintos

Los datos industriales tienen que cruzar varias fronteras: del sensor o el variador al controlador, de los controladores a los sistemas de supervisión y, cada vez más, de la planta a aplicaciones en la nube o corporativas. Cada frontera tiene necesidades distintas. En el dispositivo importan sobre todo la sencillez y la compatibilidad con el equipo instalado. En la planta, operadores e ingenieros necesitan saber qué es cada valor, en qué unidad y quién lo puede cambiar. Entre la planta y la nube, las conexiones se caen, los firewalls bloquean el tráfico de entrada y muchos consumidores quieren los mismos datos.

Comparar los protocolos como si fueran alternativas para el mismo trabajo lleva a malas decisiones, como hacer analítica en la nube leyendo registros Modbus por una VPN, o meter un stack OPC UA completo en un sensor que solo necesita mandar un número.

Lo que ofrece cada especificación

Modbus: registros y peticiones

La especificación del protocolo de aplicación Modbus (V1.1b3, publicada por la Modbus Organization) define un intercambio cliente-servidor sencillo. Un cliente manda una petición con un código de función y un rango de direcciones; el servidor regresa los datos o una excepción. El modelo de datos tiene cuatro tablas principales: entradas discretas (bits de solo lectura), coils (bits de lectura y escritura), registros de entrada (palabras de 16 bits de solo lectura) y registros holding (palabras de 16 bits de lectura y escritura). Una petición Read Holding Registers puede regresar como máximo 125 registros, un límite que viene de la unidad de datos máxima de 253 bytes del protocolo.

Lo que Modbus no define es qué significa un registro. El registro 40,021 puede ser una temperatura en décimas de grado, la mitad baja de un float de 32 bits o un campo de bits de estado, y la única forma de saberlo es el mapa de registros del equipo. El orden de bytes y de palabras para valores de 32 bits cambia entre fabricantes. El mismo protocolo de aplicación corre por líneas seriales (RTU) y sobre TCP/IP, y la Modbus Organization también publicó un protocolo Modbus Security que envuelve Modbus/TCP en TLS, pero mucho del equipo instalado es anterior.

OPC UA: un modelo de información con seguridad

La especificación OPC UA (publicada por la OPC Foundation como OPC 10000 y como la serie IEC 62541) se describe como un estándar independiente de la plataforma que permite que distintos sistemas y dispositivos se comuniquen de forma segura y confiable. Su idea central es el espacio de direcciones: un servidor representa sus datos como nodos conectados por referencias, con atributos que describen cada nodo, así que un cliente puede explorar el servidor y encontrar, por ejemplo, un objeto bomba con una variable de velocidad en revoluciones por minuto, un setpoint que puede escribir y alarmas a las que se puede suscribir.

Encima del espacio de direcciones, OPC UA define servicios de lectura y escritura, suscripciones que avisan al cliente cuando cambia un valor, y alarmas y eventos. La seguridad es parte de la especificación: la descripción general menciona mecanismos de autenticación, cifrado y revisión de integridad, con mensajes que se pueden firmar y cifrar en la capa de transporte y usuarios que se autentican al iniciar la sesión. Además del modelo cliente-servidor basado en sesiones, OPC UA PubSub lleva datos de publicadores a suscriptores y no está atado a un sistema de mensajería en particular; puede correr sobre MQTT, entre otros.

Las especificaciones complementarias (companion specifications) estandarizan modelos de información para tipos concretos de equipo, para que máquinas de distintos fabricantes expongan estructuras parecidas.

MQTT: publicación-suscripción a través de un broker

MQTT versión 5.0, estándar de OASIS publicado en marzo de 2019, es un transporte cliente-servidor de publicación-suscripción. Los clientes publican mensajes en temas (topics) de un servidor (el broker), y el broker reenvía cada mensaje a los clientes suscritos a temas que coinciden. Publicadores y suscriptores no necesitan saber unos de otros, y los dispositivos solo hacen conexiones de salida, lo que funciona bien a través de firewalls.

La especificación define tres calidades de servicio: QoS 0, “como máximo una vez”, donde puede perderse el mensaje; QoS 1, “al menos una vez”, donde los mensajes llegan con seguridad pero puede haber duplicados; y QoS 2, “exactamente una vez”. También define mensajes retenidos, para que un suscriptor nuevo reciba de inmediato el último valor de un tema, y un mensaje Will que el broker publica si un cliente se desconecta de forma anormal, una manera sencilla de detectar un equipo fuera de línea. Los intervalos de expiración de sesión controlan cuánto tiempo guarda el broker el estado de un cliente desconectado.

MQTT no dice nada de la carga útil. Una temperatura se puede mandar como texto, JSON o una estructura binaria, y el nombre de los temas queda a criterio de quien diseña el sistema. Convenciones como Sparkplug, u OPC UA PubSub sobre MQTT, agregan la estructura que MQTT deja fuera.

Lo que muestran las mediciones

Profanter, Tekat, Dorofeev, Rickert y Knoll compararon OPC UA, ROS, DDS y MQTT en la IEEE International Conference on Industrial Technology de 2019, con implementaciones de código abierto en dos máquinas Linux de tiempo real. MQTT (Eclipse Paho) tuvo el menor overhead de protocolo, 17 bytes para establecer la conexión, mientras que OPC UA tuvo más overhead por mensaje. En tiempo de ida y vuelta con el sistema en reposo, la implementación OPC UA PubSub de open62541 fue la más rápida de los middleware probados para la mayoría de los tamaños de mensaje, seguida por DDS y OPC UA cliente-servidor, con MQTT más lento y con más valores atípicos. Con carga de CPU, la latencia de OPC UA se mantuvo cerca de la de reposo, mientras que MQTT y DDS se alentaron unos 300 µs. Los autores advierten que los resultados reflejan esas implementaciones específicas.

Un estudio de Silveira Rocha y colegas en Acta IMEKO (2019) comparó OPC UA PubSub y MQTT para el intercambio entre planta y nube, midiendo los datos transferidos y el tiempo de ida y vuelta en varios escenarios de nube, y concluyó que la mejor opción depende del escenario. El hilo común es que la implementación y el despliegue importan tanto como el protocolo.

Un presupuesto de polling Modbus, paso a paso

Modbus en línea serial se consulta un equipo a la vez, así que la pregunta es si un ciclo completo cabe en la tasa de actualización. Números ilustrativos para una red RTU:

• 50 medidores, cada uno leído con una petición de 20 registros holding, a 19,200 baudios.
• Petición: 8 bytes. Respuesta: 5 bytes de trama más 40 bytes de datos, 45 bytes.
• Cada carácter RTU ocupa 11 bits en la línea, así que 53 bytes son 583 bits, unos 30 ms a 19,200 baudios.
• Silencios entre tramas de 3.5 tiempos de carácter, unos 2 ms cada uno, dos por transacción: unos 4 ms.
• Tiempo de respuesta del equipo (según la documentación del medidor; aquí, 10 ms ilustrativos).

Una transacción tarda unos 44 ms, así que un ciclo completo de 50 medidores tarda unos 2.2 segundos. Si el tablero necesita actualizaciones cada segundo, las opciones son subir los baudios, leer menos registros por consulta, repartir los medidores en dos o tres líneas seriales, o poner un gateway que consulte localmente y publique los cambios hacia arriba. Con Modbus/TCP el tiempo en la línea baja, pero el tiempo de respuesta de cada equipo y el manejo de peticiones del cliente siguen sumando.

Modbus vs OPC UA vs MQTT, lado a lado

Propiedad	Modbus	OPC UA	MQTT
Patrón	Petición-respuesta (el cliente consulta al servidor)	Sesiones cliente-servidor con suscripciones; opción PubSub	Publicación-suscripción a través de un broker
Modelo de datos	Cuatro tablas de bits y registros de 16 bits numerados	Espacio de direcciones con tipos y explorable; modelos complementarios	Ninguno; carga útil y temas los define el sistema
Significado de los valores	Mapa de registros del equipo	En el modelo (nombres, tipos, unidades, relaciones)	Por convención (por ejemplo, Sparkplug)
Seguridad	Ninguna en el protocolo base; Modbus Security agrega TLS en TCP	Autenticación, firma y cifrado en la especificación	TLS y autenticación en el broker, según el despliegue
Entrega	Respuesta o timeout por petición	Basada en sesión; suscripciones con colas	QoS 0, 1, 2; mensajes retenidos; mensaje Will
Overhead	Muy bajo	Más alto por mensaje	Muy bajo
Lugar típico	Equipos de campo, medidores, variadores, equipo heredado	Controladores, SCADA, MES, máquina a máquina	Del borde a la nube, muchos consumidores, enlaces intermitentes

Qué hacer en la práctica

Elige por capa, no por moda

Deja Modbus donde los equipos ya lo hablan, usa OPC UA donde se necesiten datos de planta estructurados y seguros, y usa MQTT donde muchos sistemas consuman datos o el enlace cruce a la nube.

Documenta los mapas de registros Modbus como si fueran código

Registra el significado, la unidad, la escala, el tipo de dato y el orden de palabras de cada registro en un mapa con control de versiones, y pruébalo contra un valor conocido en el equipo real.

Calcula los ciclos de polling antes de agregar equipos

Usa el presupuesto de arriba con tus baudios, número de registros y tiempos de respuesta. Deja margen para reintentos.

Activa la seguridad donde el protocolo la tiene

Usa los modos firmados y cifrados de OPC UA con certificados reales, no la política “None”, y corre MQTT sobre TLS con credenciales por equipo. Mantén Modbus en redes aisladas o detrás de un gateway.

Define desde el principio la carga útil y los temas MQTT

Acuerda una estructura de temas, un formato de carga útil, marcas de tiempo y unidades antes de que publique el primer equipo, o adopta una convención que ya los defina.

Qué no hacer

No consultes los equipos de campo directamente desde la nube. Y no trates el nombre de un tema MQTT como modelo de datos; sin cargas útiles acordadas, cada consumidor tiene que adivinar.

Cómo aplicarlo

Si tienes una hora

Dibuja el camino de tus datos del sensor al tablero y marca en cada enlace qué protocolo usa, quién inicia la conexión y si está protegido.

Si tienes un sprint

Arma un prototipo de gateway que consulte localmente algunos equipos Modbus, convierta los registros en valores con nombre y tipo, y publique los cambios por MQTT o los exponga por OPC UA. Mide el ciclo de polling.

Si quieres que dure toda la vida del producto

Guarda los mapas de registros, los modelos OPC UA y las definiciones de temas y cargas MQTT en control de versiones junto con el firmware y la configuración del gateway, y revísalos cada vez que se agregue un equipo o un consumidor.

La pregunta que debes hacerte: “Si alguien nuevo se conecta a estos datos el año que entra, ¿va a poder saber qué significa cada valor sin preguntarle a quien lo configuró?”

Preguntas frecuentes

¿OPC UA está reemplazando a Modbus?

No en el equipo instalado, donde Modbus sigue muy extendido porque es sencillo y barato de implementar. OPC UA es más común en controladores y sistemas de supervisión nuevos, y muchas veces un gateway traduce los datos Modbus a un modelo OPC UA.

¿MQTT es mejor que OPC UA?

Hacen trabajos distintos. MQTT es un transporte ligero para repartir mensajes a través de un broker y no define modelo de datos; OPC UA define un modelo de información, servicios y seguridad. OPC UA PubSub incluso puede usar MQTT como transporte.

¿Modbus es seguro?

El protocolo base no tiene autenticación ni cifrado. La Modbus Organization publica un protocolo Modbus Security que usa TLS para Modbus/TCP, pero mucho del equipo instalado no lo soporta, así que las redes Modbus normalmente se aíslan o se acceden a través de un gateway.

¿Qué protocolo tiene la menor latencia?

Depende de la implementación y de la carga. En un benchmark de 2019 con implementaciones de código abierto, OPC UA PubSub de open62541 estuvo entre los menores tiempos de ida y vuelta, y MQTT tuvo el menor overhead pero más valores atípicos de latencia.

¿Puedo usar MQTT y OPC UA juntos?

Sí. Un patrón común es OPC UA dentro de la planta y MQTT de un gateway de borde a la nube, y OPC UA PubSub puede publicar sus mensajes sobre MQTT.

Lecturas relacionadas: lazo de corriente 4–20 mA, procesamiento en el borde vs la nube para datos industriales y tableros que los operadores sí usan.

Fuentes

1. Modbus Organization. Modbus Application Protocol Specification V1.1b3 y especificaciones relacionadas. https://modbus.org/modbus-specifications
2. OPC Foundation. OPC 10000-1: OPC Unified Architecture, Part 1: Overview and Concepts, sección 4. https://reference.opcfoundation.org/specs/OPC-10000-1/4
3. OASIS (2019). MQTT Version 5.0. OASIS Standard, 7 de marzo de 2019. https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html
4. Profanter, S., Tekat, A., Dorofeev, K., Rickert, M., & Knoll, A. (2019). “OPC UA versus ROS, DDS, and MQTT: Performance Evaluation of Industry 4.0 Protocols.” 2019 IEEE International Conference on Industrial Technology (ICIT), 955–962. https://doi.org/10.1109/ICIT.2019.8755050
5. Silveira Rocha, M., Serpa Sestito, G., Dias, A. L., Turcato, A. C., Brandão, D., & Ferrari, P. (2019). “On the Performance of OPC UA and MQTT for Data Exchange Between Industrial Plants and Cloud Servers.” Acta IMEKO, 8(2), 80–87. https://doi.org/10.21014/acta_imeko.v8i2.648