El protocolo MQTT industrial es el estándar de mensajería ligero más utilizado en proyectos IIoT e Industria 4.0. Desarrollado en 1999 por IBM y Eurotech, el protocolo MQTT industrial nació para la monitorización remota de oleoductos mediante conexiones satelitales. De hecho, hoy es el protocolo de transporte de referencia para conectar PLCs, sensores y gateways edge con plataformas cloud en proyectos de automatización industrial. Concretamente, lo estandarizó OASIS en 2013. Por tanto, hoy está presente en más del 85 % de los proyectos IoT activos en el mundo.
Concretamente, en Electrohine integramos el protocolo MQTT industrial junto con OPC UA y Modbus. Lo hacemos en proyectos de energía, tratamiento de aguas y fabricación. MQTT no sustituye a OPC UA: actúa como la capa de transporte eficiente desde el edge hacia los sistemas IT y cloud.
Índice
- Qué es el protocolo MQTT y cómo funciona
- Calidad de servicio (QoS) y mensajes retenidos
- Protocolo MQTT industrial frente a OPC UA
- MQTT Sparkplug para uso industrial avanzado
- Cuándo usar el protocolo MQTT industrial
- Errores frecuentes al implementar MQTT
- Preguntas frecuentes
- Fuentes
Qué es el protocolo MQTT industrial y cómo funciona el broker
El protocolo MQTT industrial funciona con tres elementos: publicador, broker y suscriptores. El publicador envía datos al broker sin saber quién los recibirá. El broker los almacena y los distribuye a los suscriptores de ese tópico. Los tópicos se organizan en jerarquías: planta/linea1/bomba/temperatura. Cualquier número de suscriptores puede recibirlos.
Concretamente, el protocolo MQTT industrial usa el modelo publicador-suscriptor. Esto lo diferencia del modelo cliente-servidor de Modbus o OPC UA. En el modelo convencional, el cliente solicita datos y espera la respuesta. En cambio, con MQTT el publicador envía datos al broker sin saber quién los recibe. Asimismo, el broker los distribuye a todos los suscriptores del tópico.
De hecho, esto lo hace especialmente eficiente con cientos o miles de dispositivos publicando datos hacia múltiples consumidores. La cabecera fija de MQTT tiene solo 2 bytes, lo que lo hace extremadamente ligero frente a HTTP o REST. Asimismo, funciona en redes 2G, GPRS, LoRa y conexiones satelitales. Asimismo, funciona en microcontroladores con memoria muy limitada.
Los tópicos admiten comodines: electrohine/planta1/# recibe todos los datos de la planta 1. +/+/+/bomba/+ recibe los datos de todas las bombas. En consecuencia, simplifica la suscripción en instalaciones con muchos puntos de medida. De hecho, es algo habitual en proyectos de edge computing industrial.
Calidad de servicio (QoS) y mensajes retenidos en MQTT
El protocolo MQTT industrial define tres niveles QoS. QoS 0: máximo un envío, sin confirmación. El QoS 1: al menos un envío, puede duplicarse. QoS 2: exactamente un envío, con doble confirmación. Concretamente, activar QoS 2 en todo aumenta la latencia sin necesidad. La elección debe basarse en el requisito real de cada tópico.
Los tres niveles de QoS en el protocolo MQTT industrial
QoS 0 es el más eficiente. Sirve para datos de telemetría donde la pérdida ocasional no es crítica: temperatura, vibración, consumo energético. Por su parte, QoS 1 es el más habitual en industria. Garantiza la entrega sin el overhead de la doble confirmación. En cambio, QoS 2 se reserva para mensajes donde la duplicación sería problemática: comandos de actuación o transacciones de negocio.
Mensajes retenidos y mecanismo Last Will
Asimismo, el protocolo MQTT industrial soporta mensajes retenidos (retained messages): el broker almacena el último mensaje publicado en cada tópico y lo envía inmediatamente a cualquier nuevo suscriptor. Asimismo, un nuevo cliente que se conecta recibe el estado actual sin esperar a la próxima publicación.
El mecanismo Last Will and Testament (LWT) permite que el broker notifique automáticamente a los suscriptores cuando un dispositivo pierde la conexión. Sin él, en consecuencia, la plataforma no detecta desconexiones hasta el siguiente intento de publicación. De hecho, esto genera lecturas incorrectas del estado de la instalación.
Protocolo MQTT industrial frente a OPC UA: diferencias y complementariedad
El protocolo MQTT industrial y OPC UA no son competidores: resuelven capas distintas. MQTT es un transporte ligero y escalable para publicar datos; no define qué significan esos datos. OPC UA es un estándar de interoperabilidad que define la estructura, el significado y la seguridad de los datos industriales. La arquitectura recomendada combina OPC UA para el modelo semántico y el protocolo MQTT industrial como transporte hacia el cloud.
| Parámetro | Protocolo MQTT industrial | OPC UA |
|---|---|---|
| Arquitectura | Publicador / Broker / Suscriptor | Cliente/Servidor + Pub/Sub |
| Modelo de datos | Sin semántica nativa (JSON, binario) | Objetos con nombre, unidad y calidad |
| Overhead | Muy bajo (cabecera 2 bytes) | Mayor (XML/binary + certificados) |
| Escalabilidad | Muy alta: millones de dispositivos | Alta, mayor coste por dispositivo |
| Seguridad | TLS opcional; sin autenticación nativa | X.509, TLS, autorización granular |
| Uso principal | Telemetría IIoT, edge→cloud a escala | PLC↔SCADA, MES, ERP; integración OT |
En la práctica, la arquitectura más extendida combina OPC UA en el nivel OT y MQTT como transporte hacia el cloud. Concretamente, la extensión Pub/Sub de OPC UA (OPC 10000-14) permite publicar datos OPC UA directamente sobre MQTT. Así pues, se combina la semántica de OPC UA con la ligereza de este protocolo. Fabricantes como HiveMQ documentan ampliamente esta arquitectura híbrida para entornos IIoT a gran escala.
MQTT Sparkplug: el protocolo MQTT industrial estructurado
MQTT Sparkplug es una extensión del protocolo MQTT industrial gestionada por la Eclipse Foundation. Añade semántica a los mensajes MQTT: define el estado de los dispositivos, el formato del payload (Protocol Buffers), la detección automática de dispositivos y la sincronización de estado. Es la respuesta industrial a la falta de semántica nativa de MQTT estándar.
El estándar MQTT base no define el formato del payload. Concretamente, puede ser JSON, texto plano, binario o XML. Concretamente, esto da flexibilidad. Sin embargo, impide la interoperabilidad entre sistemas de distintos proveedores. Sparkplug resuelve esto definiendo: un formato de payload estándar basado en Protocol Buffers, una jerarquía de tópicos normalizada (spBv1.0/grupo/DDATA/nodo/dispositivo), mensajes de nacimiento y muerte para gestionar el estado de cada dispositivo, y la definición de métricas con nombre, tipo de dato y timestamp.
En consecuencia, cualquier plataforma IIoT compatible con Sparkplug recibe datos de cualquier gateway que lo implemente. De hecho, no necesita configuración personalizada. Por tanto, MQTT con Sparkplug es una alternativa real a OPC UA para arquitecturas IIoT a gran escala donde la semántica es un requisito. De hecho, brokers como HiveMQ soportan Sparkplug de forma nativa en sus versiones enterprise.
Cuándo usar el protocolo MQTT industrial en automatización
El protocolo MQTT industrial es la elección correcta cuando se necesita conectar muchos dispositivos con ancho de banda limitado, cuando los datos deben llegar a plataformas cloud a gran escala o cuando la arquitectura IIoT requiere publicar un dato hacia múltiples consumidores. No es adecuado como único protocolo en la capa OT donde la semántica y la seguridad avanzada son requisitos.
Casos en los que MQTT es la mejor opción
- Conexiones con ancho de banda limitado: el protocolo MQTT industrial es la mejor opción para instalaciones con conectividad limitada —enlaces 4G rural, LoRa, conexiones satelitales—. Su cabecera mínima reduce el tráfico al máximo comparado con otros protocolos.
- Arquitecturas cloud con muchos dispositivos: cuando cientos o miles de dispositivos deben enviar datos a una plataforma cloud para análisis centralizado, MQTT escala mejor que OPC UA cliente/servidor. Plataformas como AWS IoT Core y Azure IoT Hub soportan MQTT de forma nativa.
- Integración edge-cloud: en la arquitectura habitual de edge computing industrial, el gateway publica datos procesados en un broker MQTT y los sistemas cloud se suscriben. MQTT permite que múltiples consumidores (analítica, dashboards, alertas) reciban los mismos datos sin duplicar la conexión.
Cuándo no usar solo MQTT
En cambio, MQTT no es adecuado como único protocolo en la capa OT. Concretamente, para esa capa, OPC UA es el correcto. MQTT actúa por encima del nivel SCADA: es la capa de transporte complementaria hacia IT y cloud.
Errores frecuentes al implementar el protocolo MQTT industrial
- No cifrar las comunicaciones: el protocolo MQTT industrial sin TLS transmite datos en texto plano. Concretamente, en redes con acceso a internet esto expone los datos de proceso a interceptación. Siempre debe usarse TLS, especialmente en instalaciones con requisitos de ciberseguridad industrial IEC 62443.
- Jerarquía de tópicos mal diseñada: una estructura de tópicos incoherente hace el sistema difícil de mantener. La convención
empresa/planta/línea/dispositivo/variablefacilita el uso de comodines y la gestión de permisos. De hecho, rediseñarla en producción es costoso. Conviene planificarla desde el inicio del proyecto. - QoS 2 para todo sin evaluar el impacto: activar QoS 2 en todas las comunicaciones satura el broker y aumenta la latencia sin necesidad. Para datos de telemetría continua, QoS 0 o QoS 1 son suficientes en la mayoría de aplicaciones industriales.
- No configurar el mecanismo LWT: sin el Last Will and Testament configurado, la plataforma no detecta las desconexiones hasta el siguiente intento de publicación. Asimismo, esto genera lecturas incorrectas en el sistema de supervisión.
¿Estás conectando tus sistemas de control a plataformas cloud?
Electrohine diseña arquitecturas de conectividad IIoT con protocolo MQTT industrial, OPC UA y gateways edge para conectar PLCs, sensores y SCADA con plataformas cloud en proyectos de automatización industrial.Consulta con nuestros ingenieros →
Preguntas frecuentes sobre el protocolo MQTT industrial
Conceptos y funcionamiento
¿Qué es el protocolo MQTT y para qué sirve en la industria?
MQTT —Message Queuing Telemetry Transport— es un protocolo de mensajería ligero estandarizado por OASIS, basado en el modelo publicador-suscriptor. En la industria, el protocolo MQTT industrial sirve para transmitir datos de sensores, PLCs y gateways hacia plataformas cloud o brokers de datos, con un overhead mínimo ideal para conexiones con ancho de banda limitado y arquitecturas IIoT con muchos dispositivos conectados.
¿Qué es un broker MQTT y cuál se usa más en industria?
Un broker MQTT es el servidor central que recibe los mensajes de los publicadores y los reenvía a los suscriptores. Concretamente, en entornos industriales los más utilizados son HiveMQ (escalable, soporte empresarial), Mosquitto (open source, ligero, para edge), y los servicios cloud AWS IoT Core y Azure IoT Hub para arquitecturas cloud nativas.
¿El protocolo MQTT industrial reemplaza a OPC UA?
No; de hecho, OPC UA y el protocolo MQTT industrial resuelven capas distintas. OPC UA define la semántica y la seguridad de los datos industriales, siendo el protocolo de referencia para integración OT. MQTT es un transporte ligero sin modelo de datos propio, ideal para publicar datos hacia el cloud. La arquitectura más robusta combina OPC UA en la capa OT y MQTT como transporte hacia el cloud.
Implementación y seguridad
¿Cómo se conecta un PLC Siemens al protocolo MQTT industrial?
Un PLC Siemens S7-1500 puede publicar en un broker MQTT de dos formas. La primera, mediante el módulo Industrial Edge de Siemens. La segunda, a través de un gateway externo (como N3uron o Moxa) que lee datos del PLC vía OPC UA o Modbus y los publica en MQTT. Asimismo, los S7-1500 con firmware reciente permiten implementar un cliente MQTT directamente en Structured Text mediante bloques de función de TIA Portal.
¿Qué es MQTT Sparkplug y por qué es importante?
MQTT Sparkplug es una especificación abierta de la Eclipse Foundation. Añade semántica al protocolo MQTT industrial estándar. Concretamente, define el formato del payload (protobuf), la estructura de tópicos, la gestión del estado de los dispositivos y la detección automática de métricas. Permite que cualquier plataforma IIoT compatible consuma datos de cualquier dispositivo Sparkplug. De hecho, no requiere configuración personalizada.
¿Es seguro el protocolo MQTT para datos industriales?
MQTT sin cifrado no es seguro para datos industriales. Con TLS, el protocolo MQTT industrial cifra la comunicación entre los dispositivos y el broker. Concretamente, para instalaciones con requisitos de ciberseguridad industrial según IEC 62443, Asimismo, MQTT debe implementarse siempre con TLS, autenticación de dispositivos y gestión adecuada de certificados. De hecho, sin estas medidas un broker expuesto a internet es un vector de ataque para la red OT.
Fuentes consultadas
- OASIS — MQTT Version 5.0 Specification. oasis-open.org
- Waveteliot — Guía completa del protocolo MQTT (diciembre 2025). waveteliot.com
- HiveMQ — MQTT vs OPC UA and Sparkplug (noviembre 2023). hivemq.com
- Automatica e Instrumentación — MQTT y OPC UA: cuál es la mejor manera de comunicar dispositivos industriales (mayo 2024). automaticaeinstrumentacion.com
- Bluemation — IIoT Industrial: guía completa. bluemation.com
Sobre el autor
Artículo elaborado por el equipo técnico de Electrohine. Especializados en arquitecturas IIoT con protocolo MQTT industrial, OPC UA y gateways edge. Más de 20 años de experiencia en proyectos de automatización en energía, agua y fabricación. Última revisión: julio de 2026.