MQTT (Message Queuing Telemetry Transport)

¿Qué Es MQTT?

MQTT fue desarrollado originalmente por IBM a finales de los años 90 para monitorear oleoductos vía satélite, donde el ancho de banda era escaso y las conexiones eran poco confiables. El protocolo fue posteriormente estandarizado por OASIS y se convirtió en la columna vertebral de las implementaciones modernas de Internet Industrial de las Cosas (IIoT). A diferencia de los protocolos web tradicionales que requieren que un dispositivo pida repetidamente actualizaciones a un servidor, MQTT permite a los dispositivos enviar datos en el momento en que se generan y que esos datos se distribuyan instantáneamente a cada sistema que los necesite.

Para los equipos de mantenimiento y operaciones, MQTT es más relevante como la capa de comunicación que conecta los sensores físicos en los equipos con los dashboards de monitoreo, las plataformas CMMS y los sistemas de analítica. Entender cómo funciona MQTT ayuda a los gerentes de mantenimiento a evaluar las arquitecturas de redes de sensores, diagnosticar brechas en los datos y tomar decisiones informadas sobre la infraestructura de monitoreo remoto de equipos.

Cómo Funciona MQTT: El Modelo Publicar-Suscribir

MQTT se construye alrededor de tres roles: publicadores, suscriptores y un broker.

Un publicador es cualquier dispositivo que genera datos, como un sensor de vibración en un motor o un sensor de temperatura en un compresor. El publicador envía sus datos al broker junto con una etiqueta de tema, por ejemplo planta/linea-3/motor-7/temperatura.

El broker es un servidor que recibe todos los mensajes entrantes y los enruta basándose en las suscripciones de temas. Desacopla completamente a los publicadores de los suscriptores: un sensor no necesita saber qué sistemas consumen sus datos.

Un suscriptor es cualquier aplicación que ha registrado interés en un tema. Cuando llega un nuevo mensaje sobre ese tema, el broker empuja inmediatamente el mensaje a cada suscriptor activo. Una plataforma de monitoreo de condición, un dashboard de mantenimiento y un historiador pueden recibir la misma lectura de sensor simultáneamente sin que el sensor necesite conocer ninguno de ellos.

Esta arquitectura hace que MQTT sea extremadamente escalable. Agregar un nuevo sistema consumidor no requiere cambios en los sensores ni en el broker, solo una nueva suscripción. Eliminar un sistema igualmente no requiere cambios en los dispositivos en campo.

Temas y Jerarquías de Temas en MQTT

Los temas en MQTT son cadenas que usan un separador de barra diagonal para crear una jerarquía, similar a una ruta de archivo. Una jerarquía de temas bien estructurada refleja la distribución física de una instalación.

Una convención de nomenclatura de temas consistente es una de las decisiones más importantes en cualquier implementación de MQTT. Determina la facilidad con la que los nuevos sistemas pueden suscribirse a subconjuntos relevantes de datos y qué tan mantenible es la red con el tiempo. Muchos equipos industriales alinean su jerarquía de temas MQTT con su jerarquía de activos para que los datos sean trazables hasta los registros de equipos específicos.

Niveles de Calidad de Servicio (QoS) de MQTT Explicados

No todos los datos de sensores tienen la misma consecuencia si se pierde un mensaje. MQTT aborda esto con tres niveles de Calidad de Servicio.

Para aplicaciones de mantenimiento predictivo, QoS 1 es la opción más común. Garantiza que las alertas de violación de umbral y los eventos de detección de anomalías lleguen a la plataforma de monitoreo incluso si la red cae brevemente, sin la penalización de latencia de QoS 2.

Mensajes Retenidos y Last Will en MQTT

Dos características de MQTT son especialmente útiles para el monitoreo industrial: los mensajes retenidos y el Last Will and Testament (LWT).

Un mensaje retenido es un mensaje marcado para ser almacenado por el broker. Cuando un nuevo suscriptor se conecta y solicita un tema, el broker entrega inmediatamente el mensaje retenido más reciente, para que el suscriptor siempre tenga un valor de inicio conocido en lugar de esperar el próximo ciclo de publicación. Esto es útil para temas de estado que se actualizan con poca frecuencia, como el estado operativo de una máquina.

La función de Last Will and Testament permite a un dispositivo preregistrar un mensaje con el broker al momento de la conexión. Si el dispositivo se desconecta inesperadamente sin enviar una notificación de desconexión adecuada, el broker publica automáticamente el mensaje LWT en nombre del dispositivo. Para los equipos de mantenimiento, esto permite alertas inmediatas cuando un sensor o gateway pierde energía o conectividad de red, en lugar de depender de la detección basada en tiempo de espera.

MQTT vs HTTP vs OPC-UA: Una Comparación para Equipos Industriales

Muchas arquitecturas industriales modernas usan tanto MQTT como OPC-UA. Un PLC o sistema SCADA puede comunicarse internamente usando OPC-UA, mientras que un gateway de borde convierte y reenvía esos datos hacia arriba vía MQTT para transmisión a la analítica de nube o a un Espacio de Nombres Unificado.

MQTT en el Monitoreo de Condición y las Redes de Sensores

El monitoreo basado en condición requiere un flujo constante de datos de activos distribuidos en una instalación. Los sensores que miden vibración, temperatura, corriente y presión generan lecturas continuamente, a veces a cientos de muestras por segundo por sensor. El sondeo HTTP sobrecargaría la red e introduciría latencia; MQTT maneja estas cargas de trabajo de forma nativa.

Una implementación típica funciona así: los sensores o gateways de borde conectados al equipo publican lecturas en un broker MQTT local o en la nube. Una plataforma de monitoreo de condición se suscribe a los temas relevantes y procesa el flujo de datos entrantes en tiempo real, activando alertas cuando las lecturas cruzan umbrales o cuando los modelos de machine learning detectan patrones asociados con fallas de equipos.

MQTT también es central para las arquitecturas de comunicación máquina a máquina (M2M) donde los activos deben compartir información de estado entre sí o con los sistemas de control sin intervención humana. Por ejemplo, un sensor que detecta vibración anormal puede publicar una alerta que active automáticamente una orden de trabajo en un CMMS conectado.

MQTT y el Espacio de Nombres Unificado

El Espacio de Nombres Unificado (UNS) es un patrón de arquitectura industrial cada vez más popular en el que todos los datos de una instalación, desde sensores y PLCs hasta sistemas ERP y MES, se publican en un único broker MQTT compartido. Cada sistema de la empresa se suscribe a los temas que necesita y publica los datos que genera, sin integraciones punto a punto entre sistemas.

El modelo de publicación-suscripción de MQTT es la capa de transporte natural para un UNS porque permite que cualquier número de productores y consumidores intercambien datos sin acoplamiento. Un equipo de mantenimiento que adopta un enfoque UNS puede esperar que los brokers MQTT sean una pieza central de su infraestructura de Industria 4.0, junto con los sistemas DCS y MES.

Consideraciones de Seguridad de MQTT para Implementaciones Industriales

MQTT fue diseñado para entornos con recursos limitados donde la seguridad no siempre era factible, por lo que el protocolo no aplica autenticación ni cifrado por defecto. En implementaciones industriales, esto crea riesgos si los brokers se dejan con la configuración predeterminada.

Las prácticas de seguridad principales para las implementaciones industriales de MQTT son:

• Cifrado del transporte: Usa siempre TLS en el puerto 8883 en lugar de TCP sin cifrar en el puerto 1883. Esto previene la interceptación y los ataques de intermediario en los datos de sensores.
• Autenticación: Requiere credenciales de nombre de usuario y contraseña como mínimo. Para sistemas críticos, usa TLS mutuo con certificados de cliente para verificar la identidad del dispositivo.
• Autorización: Configura el broker con listas de control de acceso (ACL) a nivel de tema para que cada dispositivo o aplicación solo pueda publicar o suscribirse a sus temas autorizados.
• Segmentación de red: Coloca el broker MQTT en una zona de red dedicada y restringe el acceso usando reglas de firewall. Los sensores no deben poder llegar directamente a internet.
• Reforzamiento del broker: Deshabilita las conexiones anónimas, limita el tamaño de los mensajes y establece límites de tasa apropiados para prevenir condiciones de denegación de servicio por dispositivos mal configurados.

Los entornos de tecnología operativa requieren especial cuidado porque las redes de sensores a menudo mezclan dispositivos más antiguos que no pueden soportar TLS con gateways modernos que sí pueden. En estos casos, asegurar el gateway y aislar los dispositivos heredados en una VLAN separada es un enfoque pragmático.

Brokers MQTT Comunes Usados en la Industria

La elección del broker afecta la escalabilidad, la sobrecarga de gestión y las opciones de integración. Los brokers más ampliamente utilizados en contextos industriales son:

• Eclipse Mosquitto: De código abierto, ligero y ampliamente implementado en gateways de borde y pequeños servidores locales. Adecuado para instalaciones con algunos cientos de dispositivos.
• HiveMQ: Broker de nivel empresarial con fuerte clustering, consola de gestión y ecosistema de extensiones. Común en grandes implementaciones de IoT industrial.
• EMQX: Broker de código abierto y empresarial de alto throughput capaz de manejar millones de conexiones concurrentes. Popular en plataformas IoT a escala de nube.
• AWS IoT Core / Azure IoT Hub: Endpoints MQTT gestionados en la nube con autenticación integrada, gestión de dispositivos e integración con servicios de analítica en la nube.

Para la mayoría de las instalaciones de manufactura, un broker local combinado con reenvío selectivo a la nube proporciona el mejor equilibrio entre latencia, soberanía de datos y capacidad de monitoreo en tiempo real.

Versiones de MQTT: MQTT 3.1.1 vs MQTT 5

MQTT 3.1.1 es la versión más ampliamente implementada en los sistemas industriales existentes. MQTT 5, lanzado en 2019, introdujo varias características relevantes para las operaciones de mantenimiento:

• Códigos de razón: Cada acuse de recibo incluye ahora un código de razón, lo que facilita mucho el diagnóstico de fallas de conexión y errores de entrega.
• Expiración de mensajes: Los publicadores pueden establecer un tiempo de vida en los mensajes para que las lecturas obsoletas se descarten si no se han consumido dentro de una ventana definida.
• Propiedades de usuario: Los metadatos clave-valor pueden adjuntarse a cualquier mensaje sin cambiar el formato del payload, permitiendo un etiquetado de datos más enriquecido sin cambios de esquema.
• Suscripciones compartidas: Múltiples suscriptores pueden compartir una suscripción al mismo tema, distribuyendo el procesamiento de mensajes entre múltiples consumidores sin entrega duplicada.

Los equipos que construyen nueva infraestructura de monitoreo de condición de activos deberían considerar MQTT 5 por su mejor diagnóstico y flexibilidad operativa, particularmente la expiración de mensajes y los códigos de razón.

Lo más importante

MQTT es la columna vertebral de comunicaciones de las redes de sensores industriales modernas. Su modelo de publicación-suscripción, la mínima sobrecarga y las garantías de entrega flexibles lo convierten en el protocolo correcto para transmitir datos de máquinas de alta frecuencia desde el piso de producción hacia plataformas de monitoreo, sistemas de mantenimiento y motores de analítica.

Para los equipos de mantenimiento y operaciones, MQTT no es solo una preocupación de desarrolladores. Entender cómo funcionan el broker, los temas y los niveles de QoS ayuda a los equipos a diseñar pipelines de datos confiables, solucionar brechas en la cobertura de sensores y evaluar si su infraestructura de monitoreo de condición puede soportar analítica predictiva en tiempo real. A medida que las instalaciones avanzan hacia arquitecturas de Industria 4.0, la fluidez en MQTT se está convirtiendo en una competencia práctica para los ingenieros de confiabilidad y los gerentes de mantenimiento.

Preguntas Frecuentes