Broker MQTT industrial: qué exigirle (QoS, retained, LWT, Sparkplug, buffering)

El broker MQTT es la pieza central de la mensajería de una planta conectada: todo lo que produce datos publica en él y todo lo que los consume se suscribe a él. Pero no todos los despliegues valen para entorno industrial. Un broker MQTT industrial debe garantizar entrega con niveles de QoS bien elegidos, conservar el último valor conocido con retained messages, detectar caídas de clientes con LWT, hablar Sparkplug B cuando hace falta un contrato de datos, apoyarse en buffering en el edge para sobrevivir a cortes y cerrar la seguridad con TLS, autenticación y autorización por topic. Esta guía repasa cada requisito y termina con una checklist.

El papel del broker en la planta

MQTT es un protocolo de publicación y suscripción: los clientes no hablan entre sí, hablan con el broker. Un gateway publica las señales de una línea en un árbol de topics; el historian, el MES y los dashboards se suscriben a las ramas que les interesan. Ese desacoplamiento es lo que convierte al broker en la columna vertebral de una plataforma de datos industriales: añadir un consumidor nuevo no toca a los productores, y viceversa.

Precisamente porque todo pasa por él, el broker concentra los requisitos que en una arquitectura punto a punto están repartidos: garantía de entrega, estado de los clientes, contrato de datos, continuidad ante cortes y seguridad. Elegir y configurar el broker sin pensar en estos cinco frentes es la forma más rápida de montar una demo que no sobrevive al primer mes de producción. La elección entre MQTT y otras opciones de conectividad la tratamos en OPC UA vs MQTT; aquí damos por decidido MQTT y nos centramos en exigirle lo correcto al broker.

QoS: qué garantiza cada nivel y cuál usar

MQTT define tres niveles de calidad de servicio (QoS) que gobiernan la entrega de cada mensaje entre cliente y broker:

Dos matices que separan la teoría de la práctica. Primero: la garantía es entre cliente y broker en cada tramo, no de extremo a extremo por sí sola; el nivel efectivo lo fija también la suscripción del consumidor. Segundo: QoS 2 no es "el mejor": su coste por mensaje lo hace mala elección para telemetría masiva. La combinación sana en planta suele ser QoS 1 como norma, con consumidores preparados para descartar duplicados, y QoS 0 reservado a flujos de alta frecuencia tolerantes a pérdida.

Retained messages: el último valor conocido

Por defecto, un suscriptor solo recibe lo que se publica después de suscribirse. Si un dashboard se conecta a las 10:00 y la temperatura se publicó a las 09:59, el dashboard no ve nada hasta la siguiente publicación. Los retained messages resuelven esto: el broker guarda el último mensaje retenido de cada topic y lo entrega inmediatamente a cada suscriptor nuevo.

En planta esto importa más de lo que parece: estados de máquina, consignas vigentes y valores de cambio lento deben publicarse retenidos para que cualquier consumidor que arranque, o se reconecte tras un corte, tenga una foto completa sin esperar al siguiente ciclo. La disciplina asociada es limpiar los retained obsoletos (publicando un mensaje vacío retenido) cuando un equipo se retira, o el árbol de topics acumula fantasmas de máquinas que ya no existen.

Last Will and Testament: saber cuándo un equipo se cae

En un sistema de publicación y suscripción, el silencio es ambiguo: si un gateway deja de publicar, ¿es que no hay novedades o es que se ha caído? El mecanismo Last Will and Testament (LWT) resuelve la ambigüedad: al conectarse, cada cliente deja registrado en el broker un mensaje de testamento; si la conexión se pierde sin desconexión ordenada, el broker lo publica en su nombre.

El patrón práctico es publicar un mensaje de estado retenido ("conectado") al arrancar y registrar como testamento el estado contrario ("desconectado"), también retenido. Cualquier consumidor sabe entonces, en todo momento y sin sondear, qué productores están vivos, y una regla de alertas puede avisar en segundos de la caída de un gateway. Un broker industrial debe soportar LWT sin restricciones y el equipo debe usarlo en todos los clientes: es la diferencia entre descubrir una caída por el hueco en el histórico o por una alerta a tiempo.

Sparkplug B: del topic libre al contrato

MQTT no impone ni estructura de topics ni formato de payload: esa libertad es su fuerza y su riesgo. Con diez máquinas y tres integradores distintos, la libertad degenera en un broker lleno de convenciones incompatibles. Sparkplug B es la especificación que cierra ese hueco para entornos industriales: define la estructura del namespace, un formato de payload binario con métricas tipadas y, sobre LWT, un modelo de estado de sesión con mensajes de nacimiento y muerte de cada nodo y dispositivo.

La consecuencia práctica es que cualquier consumidor compatible sabe, sin acuerdos bilaterales, qué métricas existen, de qué tipo son y si su fuente está en línea o si el dato es antiguo. No todos los proyectos necesitan Sparkplug desde el primer día, pero el broker elegido debe soportarlo sin fricción, porque es el camino natural cuando el número de productores y consumidores crece. El patrón completo de namespace lo desarrollamos en la guía de unified namespace y MQTT Sparkplug B.

Buffering: lo que el broker no resuelve solo

Aquí conviene deshacer un malentendido frecuente: las garantías de QoS protegen mensajes en tránsito, no mensajes que nunca llegaron a enviarse. Si la red entre el gateway y el broker cae durante dos horas, el broker no puede hacer nada por los datos generados en ese intervalo: la responsabilidad es del publicador.

Por eso un despliegue industrial serio exige store-and-forward persistente en el edge: el gateway escribe cada valor en disco local antes de publicarlo y reenvía el atraso, en orden y con su marca de tiempo de origen, cuando la conexión vuelve. Las sesiones persistentes del broker ayudan en el otro sentido, guardando mensajes para suscriptores temporalmente desconectados, pero no sustituyen al buffer del publicador. El dimensionado de ese buffer (días de autonomía, no minutos) lo tratamos en la guía de edge industrial con buffering y QoS.

Seguridad: TLS, autenticación y autorización por topic

El broker es el punto por el que pasa todo el dato de planta, y eso lo convierte en el activo a proteger. Los mínimos no negociables:

• TLS en todas las conexiones. Cifrado de transporte siempre, también dentro de la planta. El tráfico MQTT sin cifrar es legible y manipulable por cualquiera con acceso a la red.
• Autenticación de cada cliente. Ningún cliente anónimo. Credenciales por cliente o, mejor, certificados de cliente, de modo que cada gateway y cada aplicación tengan identidad propia y revocable.
• Autorización por topic. Que un cliente esté autenticado no significa que pueda todo: cada identidad debe poder publicar y suscribirse solo a las ramas que le corresponden. Un gateway de la línea 3 no tiene por qué poder publicar en los topics de la línea 1, y un dashboard de solo lectura no debe poder publicar en absoluto.
• Conexiones salientes desde la planta. El patrón seguro es que el edge inicie la conexión hacia el broker, sin abrir puertos entrantes en la red OT. La superficie de exposición de la planta queda en cero.

Estos requisitos forman parte del mismo planteamiento que desarrollamos en la guía de zero trust en OT industrial: identidad por dispositivo, mínimo privilegio y ninguna confianza implícita por estar dentro de la red.

Checklist: qué exigirle a un broker MQTT industrial

Preguntas frecuentes sobre brokers MQTT industriales

Si estás diseñando la mensajería de tu planta, en Captia Connect desplegamos esta capa completa: adquisición multiprotocolo con MQTT y OPC UA, buffering local persistente, normalización en origen y conectividad segura hacia el broker, como parte de la integración MQTT y de la arquitectura que describimos en plataforma de datos industriales.