Modbus, MQTT, OPC-UA: ¿qué protocolo industrial elegir en 2026?

· 16 min de lectura
16 min read
Equipo Eziwan
Equipo Eziwan
Infraestructura IoT

La pregunta «¿qué protocolo debo utilizar para mi proyecto de IoT industrial?» surge sistemáticamente en los proyectos de modernización de fábricas. Modbus, MQTT y OPC-UA son los tres protocolos más mencionados, pero no son alternativas equivalentes. Funcionan en capas diferentes, responden a necesidades distintas y, a menudo, se complementan entre sí en lugar de competir.

Este artículo aclara sus diferencias fundamentales, sus puntos fuertes y sus limitaciones, y te ofrece una guía para decidir cuál es el protocolo más adecuado según tu caso de uso.

Lo primero es entenderlo: protocolos de naturaleza diferente​

Antes de compararlos, hay que tener en cuenta que Modbus, MQTT y OPC-UA no funcionan al mismo nivel:

Modbus es un protocolo de lectura de datos: permite consultar un equipo para leer sus registros (mediciones, estados). Se trata de un protocolo de campo, de tipo maestro/esclavo, diseñado para la adquisición de datos en equipos industriales.

MQTT es un protocolo de mensajería: permite publicar y suscribirse a flujos de datos a través de un broker centralizado. Se trata de un protocolo de transporte de mensajes, no de adquisición directa en un dispositivo.

OPC-UA es una arquitectura de servicios: combina la adquisición de datos, el acceso al modelo de datos, la seguridad, las alarmas y el historial en un único estándar industrial unificado. Es la solución más completa —y la más compleja—.

En la práctica: La mayoría de las arquitecturas industriales de IoT modernas utilizan las tres. Modbus para leer los equipos de campo. MQTT para transmitir los datos a la nube. OPC-UA para la interoperabilidad entre sistemas complejos.

Modbus RTU y Modbus TCP​

¿Qué es Modbus?​

Modbus fue creado en 1979 por Modicon (hoy Schneider Electric). Es el protocolo industrial más antiguo que sigue en uso —y, con diferencia, el más extendido en el ámbito industrial francés—.

Modbus RTU funciona a través de un enlace serie RS-485 (o RS-232). Es asíncrono, de tipo maestro/esclavo, con una topología de bus lineal (multipunto). Puede haber hasta 247 esclavos en un mismo bus RS-485.

Modbus TCP es Modbus encapsulado en paquetes TCP/IP. Funciona en Ethernet, en el puerto 502. Mantiene el modelo maestro/esclavo, pero permite topologías de red arbitrarias (estrella, árbol). No hay un límite estricto de esclavos en la red.

Qué permite leer Modbus​

Modbus ofrece 4 tipos de datos:

  • Coils (0x): salidas digitales de lectura/escritura (booleanos)
  • Discrete Inputs (1x): entradas digitales de solo lectura (booleanos)
  • Registros de entrada (3x): registros de 16 bits de solo lectura (medidas de sensores)
  • Registros de retención (4x): registros de 16 bits de lectura/escritura (puntos de consigna, parámetros)

Para leer un valor de temperatura en un sensor: el maestro envía una solicitud «leer los registros 3x01 a 3x02», y el esclavo responde con los dos registros que contienen el valor (por lo general, un número flotante de 32 bits repartido en dos registros contiguos).

Ventajas de Modbus​

Universalidad absoluta: Si tienes un equipo industrial con un puerto RS-485 o un puerto Ethernet y no sabes qué protocolo utiliza, empieza por probar con Modbus. Es muy probable que sea compatible con Modbus.

Simplicidad: El protocolo es sencillo: registros numerados y funciones estándar de lectura y escritura. Cualquier desarrollador puede implementar un cliente Modbus en unas pocas horas.

Resiliencia: No hay dependencia de ningún intermediario ni de ningún servidor central. El maestro consulta directamente a cada esclavo. Un fallo del maestro no afecta a las relaciones entre los esclavos.

Madurez: 45 años de implantación industrial. Las bibliotecas Modbus están disponibles en todos los lenguajes de programación (Python, C, Java, JavaScript...).

Limitaciones de Modbus​

Arquitectura exclusivamente «pull»: El maestro debe consultar de forma proactiva a cada esclavo. Los dispositivos no envían datos de forma espontánea. En un bus con 50 esclavos consultados cada segundo, la frecuencia real por esclavo puede reducirse a 20 segundos.

Falta de seguridad nativa: Modbus RTU y Modbus TCP no cuentan con ningún mecanismo de autenticación ni de cifrado. Cualquier dispositivo de la red puede leer o escribir en los registros de un equipo Modbus expuesto. La seguridad debe añadirse a nivel de red (VPN, segmentación).

No hay detección automática: No existe ningún mecanismo de detección de dispositivos Modbus en un bus. Debes conocer la dirección de esclavo y las direcciones de los registros de cada dispositivo.

Falta de nomenclatura semántica: El registro 40001 no indica qué contiene; es necesario consultar la documentación del fabricante para saber que se trata de la «temperatura de entrada del agua». No hay autodescripción.

¿Cuándo se debe utilizar Modbus?​

  • Lectura de datos en equipos de campo (contadores de energía, sensores de presión, variadores, controladores PLC)
  • Redes de campo existentes con cableado RS-485 ya instalado
  • Proyectos con equipos heterogéneos de distintos fabricantes (Modbus es el más universal)
  • Presupuestos limitados o equipos sin conocimientos especializados

MQTT (Message Queuing Telemetry Transport)​

¿Qué es MQTT?​

MQTT fue creado en 1999 por IBM para la telemetría en enlaces satelitales de baja velocidad. Fue estandarizado por OASIS en 2014 (MQTT 3.1.1) y en 2019 (MQTT 5.0).

MQTT es un protocolo de publicación/suscripción: los emisores envían mensajes a temas, y los suscriptores reciben los mensajes de los temas a los que están suscritos. Un broker MQTT central se encarga de enrutar los mensajes entre emisores y suscriptores.

Arquitectura MQTT​

El broker es el núcleo de la arquitectura MQTT. Los clientes (publishers y subscribers) se conectan al broker; nunca se comunican directamente entre sí.

Ventajas de MQTT​

Arquitectura «push»: Los editores envían datos cuando tienen algo que comunicar. No hay sondeos: el suscriptor recibe los datos inmediatamente tras su publicación. Latencia habitual: 10-50 ms de extremo a extremo.

Ligero: El protocolo se ha diseñado para dispositivos con recursos limitados (microcontroladores, módems 2G). Un mensaje MQTT puede caber en 2 bytes (encabezado mínimo). Consume muy poco ancho de banda.

QoS configurable: Tres niveles de calidad de servicio: QoS 0 (como máximo una vez), QoS 1 (como mínimo una vez), QoS 2 (exactamente una vez). Para las aplicaciones críticas, QoS 2 garantiza la entrega exactamente una vez.

Interoperabilidad en la nube: Todos los principales proveedores de servicios en la nube (AWS IoT Core, Azure IoT Hub, Google Cloud IoT) ofrecen un broker MQTT nativo. MQTT es el protocolo de facto para las arquitecturas de IoT en la nube.

TLS nativo: MQTT es compatible con TLS 1.3 de forma nativa. La seguridad está integrada en el protocolo, no es un complemento.

Limitaciones de MQTT​

No puede leer los dispositivos directamente: Un dispositivo Modbus RTU no es compatible de forma nativa con MQTT. Se necesita una pasarela que lea los datos Modbus y los publique en MQTT. Por eso, Modbus y MQTT suelen utilizarse conjuntamente en las arquitecturas de IoT industrial.

Dependencia del broker: Si el broker MQTT deja de funcionar, toda la arquitectura de mensajería se colapsa. La resiliencia del broker es fundamental. Los brokers gestionados (AWS IoT, HiveMQ Cloud) son muy fiables, pero crean una dependencia de un servicio externo.

No existe un modelo de datos estandarizado: MQTT no define el formato de los mensajes ni la estructura de los temas. Cada implementación es libre, lo que perjudica la interoperabilidad. Dos sistemas MQTT de distintos fabricantes no se comunican necesariamente entre sí sin necesidad de adaptaciones.

No hay un modelo nativo de solicitud/respuesta: MQTT está orientado a eventos unidireccionales. Para implementar un patrón de solicitud/respuesta (por ejemplo, solicitar un parámetro a un dispositivo), hay que utilizar MQTT 5.0 con temas de respuesta correlacionados; es posible, pero más complejo.

¿Cuándo utilizar MQTT?​

  • Transporte de datos desde el campo a la nube (Modbus → Pasarela → MQTT → Nube)
  • Arquitecturas basadas en eventos en las que los datos cambian de forma irregular
  • Implementaciones de IoT integradas en microcontroladores o dispositivos con recursos limitados
  • Integración con brokers nativos en la nube (AWS IoT, Azure IoT Hub)

OPC-UA (Arquitectura Unificada OPC)​

¿Qué es OPC-UA?​

OPC-UA (IEC 62541) fue desarrollado por la Fundación OPC a partir de 2006 como sucesor de OPC Classic (basado en COM/DCOM de Windows). Se trata del estándar industrial más ambicioso: combina la adquisición de datos, el modelo semántico, la seguridad, el historial, las alarmas y el acceso a los métodos en un único protocolo.

OPC-UA es hoy en día el protocolo preferido por los fabricantes de controladores lógicos programables (PLC) para las arquitecturas de la Industria 4.0: Siemens TIA Portal (S7-1500), Rockwell ControlLogix, Beckhoff TwinCAT, B&R Automation: todos ellos son compatibles con OPC-UA de forma nativa desde hace entre 5 y 10 años.

Puntos fuertes de OPC-UA​

Modelo de datos semántico: A diferencia de Modbus (registros numerados anónimos), OPC-UA presenta un árbol de objetos con nombre y tipo. El nodo «ns=2;i=1001» puede denominarse «Máquina1/MotorPrincipal/TemperaturaRodamiento» y contar con metadatos (unidad, rango, descripción). La autodescripción es nativa.

Seguridad integrada: Autenticación, autorización, cifrado, integridad de los mensajes… todo está incluido en el protocolo. OPC-UA admite varios perfiles de seguridad (None, Sign, SignAndEncrypt) con algoritmos modernos (AES-256, RSA-2048+).

Publicación/Suscripción desde OPC-UA PubSub (2017): OPC-UA ahora puede funcionar en modo de publicación asíncrona (push), y no solo en modo de solicitud/respuesta (pull). Puede publicar en brokers MQTT, lo que hace que OPC-UA y MQTT sean complementarios en lugar de competidores.

Acceso a los métodos: OPC-UA permite invocar métodos en los equipos, no solo leer valores. El accionamiento de una válvula, el comando de arranque de un motor… todo se modela como un objeto OPC-UA.

Semántica e interoperabilidad: Las «Companion Specifications» de OPC-UA definen modelos estandarizados por sectores: OPC-UA para plásticos, para robótica, para PackML (embalaje), para minería... Un software SCADA compatible con OPC-UA para PackML puede conectarse a cualquier línea de envasado que cumpla con la norma, sin necesidad de una configuración específica.

Limitaciones de OPC-UA​

Complejidad: OPC-UA es el protocolo más complejo de implementar y configurar. Las especificaciones superan las 1000 páginas. La curva de aprendizaje es considerable para los equipos que no cuentan con experiencia previa en OPC-UA.

Recursos necesarios: Un servidor OPC-UA completo requiere más recursos que un esclavo Modbus. Los controladores lógicos programables antiguos o los microcontroladores con recursos limitados no pueden incorporar una pila OPC-UA completa (aunque existen perfiles «nano» más ligeros).

No es universal en el campo: Los equipos antiguos (anteriores a 2010-2015) no son compatibles con OPC-UA. En un parque industrial heterogéneo, encontrarás muchos más equipos Modbus que OPC-UA entre los equipos de campo existentes.

Sobrecarga de red: Los mensajes OPC-UA son más voluminosos que los mensajes Modbus (XML o binarios, según el protocolo de transporte). En conexiones 4G de baja velocidad, esto puede ser un factor a tener en cuenta.

¿Cuándo se debe utilizar OPC-UA?​

  • Controladores Siemens S7-1200/1500 recientes con TIA Portal (OPC-UA nativo)
  • Arquitecturas de la Industria 4.0 con interoperabilidad SCADA/MES/ERP
  • Proyectos que requieren un alto nivel de seguridad y trazabilidad en los accesos
  • Entornos con equipos de distintos fabricantes que requieren interoperabilidad semántica

Guía para tomar decisiones: ¿qué combinación elegir para tu proyecto?​

Arquitectura típica sencilla del IoT industrial​

Uso: Supervisión de procesos, alertas, historial. El 80 % de los proyectos de IoT industrial franceses se ajustan a este modelo.

Arquitectura con bus de integración en la nube​

Uso: Proyectos con varios consumidores de datos (SCADA + ERP + BI). MQTT como bus de integración.

Arquitectura de la Industria 4.0 con OPC-UA​

Aplicaciones: Fábricas con controladores lógicos programables (PLC) de última generación, proyectos de Industria 4.0, integración con sistemas MES.

Matriz de decisión​

RequisitoModbus RTUModbus TCPMQTTOPC-UA
Lectura de sensores de campo RS-485✓✓———
Lectura de controladores en red✓✓✓—✓
Envío de datos a la nube——✓✓✓
Interoperabilidad SCADA/MES✗✗Parcial✓✓
Seguridad integrada✗✗TLS✓✓
Equipos antiguos✓✓✓—✗
Controladores recientes (>2015)✓✓—✓✓
Arquitecturas nativas en la nube✗✗✓✓✓
Pymes sin conocimientos sobre protocolos✓✓✓✓✓✗

Cómo gestiona Eziwan los tres protocolos​

La pasarela Eziwan es independiente de los protocolos de campo:

  • Modbus RTU: puerto RS-485 nativo, modo maestro, hasta 247 esclavos por bus, sondeo configurable de 1 s a 15 min
  • Modbus TCP: cliente Modbus TCP, conexiones simultáneas a varios servidores Modbus
  • MQTT: emisor MQTT (publicación de los datos recopilados), posibilidad de suscribirse para recibir comandos
  • OPC-UA: cliente OPC-UA (lectura de nodos, suscripción a cambios de valor) — disponible bajo petición para implementaciones OPC-UA

En cuanto a la nube, los datos se normalizan internamente y se exponen a través de:

  • API REST (JSON) para aplicaciones en la nube
  • Webhooks para eventos en tiempo real
  • MQTT saliente para integraciones mediante bus

Puedes combinar Modbus RTU en los dispositivos de campo y MQTT hacia tu nube de AWS/Azure sin tener que modificar nada: la pasarela se encarga de la conversión.

Conclusión​

En 2026, la respuesta a «¿Modbus, MQTT u OPC-UA?» suele ser «los tres juntos»:

  • Modbus para leer tus equipos de campo (es el protocolo que utilizan)
  • MQTT para transportar los datos a tu nube y distribuirlos a varias aplicaciones
  • OPC-UA si tienes controladores lógicos programables (PLC) recientes de Siemens, Rockwell o Beckhoff y necesitas interoperabilidad SCADA/MES

No se trata de una competición, sino de una arquitectura por capas. La elección no es «qué protocolo», sino «qué protocolo en qué capa para qué equipo».

Preguntas frecuentes — Modbus, MQTT y OPC-UA​

¿Se pueden utilizar Modbus y MQTT al mismo tiempo en la misma pasarela?

Sí, y es la arquitectura más habitual en el IIoT. La pasarela recoge los datos de los controladores mediante Modbus TCP o RTU (capa de campo) y los publica en MQTT hacia la nube (capa de transporte). Modbus se detiene en la pasarela; nunca queda expuesto a Internet. MQTT se encarga del transporte hacia la nube, con TLS 1.3 y autenticación.

¿Puede OPC-UA sustituir a Modbus en los controladores lógicos programables existentes (S7-1200, M340)?

En los Siemens S7-1200, el servidor OPC-UA solo está disponible a partir de la versión de firmware V4.4 y requiere una configuración explícita en TIA Portal. En los S7-1500, está integrado de forma nativa desde la versión de firmware V2.0. En los Schneider M340, OPC-UA no está integrado de serie; se necesitaría un módulo adicional. En la práctica, para los parques existentes, Modbus TCP sigue siendo la solución universal; OPC-UA resulta relevante principalmente para los nuevos proyectos con controladores lógicos programables recientes.

MQTT con QoS 0 frente a QoS 1 frente a QoS 2: ¿qué elegir para la supervisión industrial?

Para la supervisión de datos de proceso (temperaturas, presiones), el QoS 1 (Al menos una vez) ofrece el equilibrio adecuado: la entrega está garantizada incluso tras una reconexión, a riesgo de que se produzcan algunas duplicaciones (aceptables para datos de monitorización). El QoS 2 (Exactly Once) es más pesado debido al intercambio de confirmaciones y rara vez es necesario para las mediciones. El QoS 0 (At Most Once) es adecuado para datos muy frecuentes (> 1/s) en los que se acepta una pérdida ocasional.

¿Es suficiente para el sector industrial un broker MQTT público (HiveMQ, EMQX cloud)?

Para proyectos piloto o no críticos, sí. Pero para una producción con restricciones de confidencialidad (datos de procesos, identificaciones de los equipos), es preferible un broker privado alojado en Francia. Los datos MQTT que pasan por brokers públicos estadounidenses pueden estar sujetos a la ley CLOUD Act, lo cual debe evaluarse en función de la sensibilidad de los datos y del sector de actividad.

¿Influye OPC-UA en el rendimiento del controlador en comparación con Modbus?

OPC-UA consume mucho más recursos de CPU y memoria que Modbus TCP. En un S7-1500 con CPU 1511, con un servidor OPC-UA activo y 50 conexiones de clientes, el tiempo de ciclo puede aumentar entre un 5 % y un 15 %. En un S7-1200, los recursos son más limitados: comprueba sistemáticamente el impacto con el programa de producción completo antes de implementar OPC-UA en producción.

Para profundizar en el tema​

Recursos adicionales​