Broker MQTT industrial: qué debes buscar

Q: ¿Cómo sé si un gateway se ha desconectado?

Configura un last will retenido, como OFFLINE, en un topic de estado. El broker lo publica automáticamente cuando el gateway se desconecta sin un DISCONNECT limpio.

Un broker MQTT industrial está en el centro de los datos de tu planta: todos los gateways publican en él y todos los SCADA, MES, historiadores y dashboards leen de él. En esta guía verás qué capacidades distinguen a un broker que sobrevive en la planta de uno que simplemente supera las pruebas del protocolo, y ejecutarás un breve script en Python que comprueba los comportamientos más importantes en cualquier broker que estés evaluando.

Por qué el uso industrial cambia los requisitos

Cualquier broker conforme con el estándar puede enrutar un mensaje de un publicador a un suscriptor. En una aplicación IoT de consumo, eso suele bastar. En una planta, el broker transporta algo más que mensajes. Transporta estado: qué máquinas están en línea, el valor actual de cada tag y si una lectura es reciente u obsoleta. Los operarios toman decisiones a partir de ese estado y, en algunas arquitecturas, los sistemas SCADA generan alarmas a partir de él.

El tráfico industrial también es diferente. Miles de tags cambian a ritmos irregulares, una línea entera puede reconectarse a la vez tras un corte de red y los payloads pueden ser protobuf de Sparkplug B en lugar de JSON legible. Los clientes viven durante años en gateways que nadie quiere tocar. Un broker que funciona bien en un proyecto personal puede tener problemas en estas condiciones. Si el papel del propio broker es nuevo para ti, empieza por qué es un broker MQTT.

Capacidades clave de un broker MQTT industrial

Capacidad	Por qué importa en una planta	Qué comprobar
MQTT 3.1.1 y 5.0	Gateways antiguos y clientes nuevos deben convivir	Ambas versiones aceptadas en el mismo endpoint
Retained messages	Los nuevos suscriptores necesitan el estado actual al instante	Valores retenidos entregados al suscribirse
Sesiones persistentes	Los gateways se reconectan sin perder datos QoS 1	Expiración de sesión respetada, mensajes en cola entregados
Last will and testament	Los gateways desconectados deben marcarse automáticamente	Will publicado ante una desconexión no controlada
Soporte de Sparkplug B	Los payloads protobuf son opacos sin decodificar	Payloads legibles en las herramientas
Estructura ISA-95 / UNS	Los datos deben poder encontrarse por jerarquía de planta	Árbol de topics navegable por sitio, área y línea
TLS y autenticación	Los datos de planta cruzan zonas de red	TLS en el 8883, credenciales por cliente
Protección contra abusos	Un gateway que se comporta mal no debe afectar a los demás	Cuotas, protección contra flood, bloqueo de inicios de sesión
Visibilidad	La puesta en marcha y la resolución de problemas exigen ver los datos	Explorador de topics en vivo, estado de conexión, alertas
Modelo de operación	Alguien debe parchearlo y monitorizarlo	Propiedad clara, gestionado o autoalojado

Soporte de Sparkplug

Sparkplug B define la estructura de topics, los certificados de nacimiento y muerte (birth y death) y un payload protobuf para MQTT industrial. En sentido estricto, el broker no necesita entender Sparkplug: es una especificación del lado del cliente, y cualquier broker MQTT 3.1.1 que soporte retained messages, QoS y wills puede transportarlo. En la práctica, sin embargo, un broker capaz de decodificar payloads Sparkplug ahorra horas. Durante la puesta en marcha quieres ver Temperature = 72.4 y no un bloque de binario. Lee nuestra guía sobre el payload de Sparkplug B para entender lo que contiene.

Un paso todavía más útil es la republicación. Los topics Sparkplug como spBv1.0/factory1/DDATA/line1/cnc1 son compactos, pero poco amigables para los consumidores de IT. Un broker que pueda republicar esas métricas en topics ISA-95 como connectmq/factory1/production/line1/cnc1/telemetry permite que el SCADA nativo de Sparkplug y las aplicaciones de negocio orientadas a JSON usen los mismos datos. La relación entre ambos modelos se trata en Sparkplug B y el Unified Namespace.

Estado retenido y sesiones

Un Unified Namespace solo funciona si un dashboard que arranca a las 9:00 puede ver el estado de todas las máquinas a las 9:00, y no cuando cada máquina vuelva a cambiar. Eso es lo que aportan los retained messages. Las sesiones persistentes con una expiración de sesión razonable protegen frente al otro fallo habitual: un gateway que se reconecta tras un breve corte de red y pierde todo lo publicado en sus suscripciones mientras tanto. En los sistemas Sparkplug, la aplicación host primaria se apoya en estos mecanismos junto con los death certificates para seguir el estado de los edge nodes.

Seguridad acorde con la realidad de OT

Los gateways deben autenticarse con sus propias credenciales, conectarse mediante TLS y quedar bloqueados si alguien bombardea el inicio de sesión con contraseñas erróneas. Los client IDs vinculados a credenciales impiden que un dispositivo suplante a otro o lo desconecte reutilizando su ID. El broker también debe limitar cuánto puede publicar un único cliente, para que un gateway mal configurado que publica un tag cada milisegundo no degrade el servicio para el resto de la planta.

Visibilidad para quienes ponen en marcha el sistema

La capacidad más infravalorada de un broker es una buena ventana hacia su interior. Cuando un ingeniero de control conecta un gateway nuevo, la primera pregunta siempre es "¿están llegando los datos y están en el lugar correcto?". Un explorador de topics en vivo, una vista de los clientes conectados y un topic de estado de conexión responden a eso en segundos. Las alertas por umbral convierten el broker de una simple tubería en una herramienta básica de monitorización para valores como límites de temperatura o la salud de los gateways. Con el estado retenido bien organizado, esos mismos topics pueden alimentar un gemelo digital 3D de la línea, ya sea en una planta de manufactura en Monterrey o en una instalación minera en Chile.

Disponibilidad y modelo de operación

Pregunta quién parchea el broker, quién renueva los certificados, quién vigila el disco y la memoria y a quién llaman a las 3 de la madrugada. El autoalojamiento da control total, pero hace al equipo de planta responsable de un servidor expuesto a internet. Un broker MQTT gestionado traslada ese trabajo al proveedor. Elijas lo que elijas, planifica cómo se comportan los clientes durante un reinicio del broker: reconexión con backoff, reanudación de sesiones y republicación de births o de estado retenido cuando sea necesario.

Prueba tú mismo cualquier broker MQTT industrial

Las listas de funcionalidades son fáciles de escribir. Este script MQTT 5 comprueba cuatro comportamientos que importan en las plantas: entrega de retenidos, reanudación de sesión, last will y reason codes. Ejecútalo primero contra el servidor MQTT público gratuito, solo con datos de prueba, y después contra cualquier broker que estés evaluando.

import time
import uuid
import paho.mqtt.client as mqtt
from paho.mqtt.properties import Properties
from paho.mqtt.packettypes import PacketTypes

HOST, PORT = "broker.connectmq.com", 1883
BASE = f"connectmq/demo/{uuid.uuid4().hex[:8]}/plant1/line1"

def make_client(cid):
    return mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
                       client_id=cid, protocol=mqtt.MQTTv5)

def session_props(seconds):
    p = Properties(PacketTypes.CONNECT)
    p.SessionExpiryInterval = seconds
    return p

received = []

def on_message(client, userdata, msg):
    received.append((msg.topic, msg.payload.decode(), msg.retain))

# 1. El gateway publica estado retenido y registra un last will
gw = make_client("gw-" + uuid.uuid4().hex[:6])
gw.will_set(f"{BASE}/gw1/status", "OFFLINE", qos=1, retain=True)
gw.connect(HOST, PORT, keepalive=5)
gw.loop_start()
gw.publish(f"{BASE}/gw1/status", "ONLINE", qos=1, retain=True)
gw.publish(f"{BASE}/cnc1/state", "RUNNING", qos=1, retain=True).wait_for_publish()

# 2. Un suscriptor tardío con sesión persistente recibe el estado retenido al instante
sub_id = "scada-" + uuid.uuid4().hex[:6]
sub = make_client(sub_id)
sub.on_message = on_message
sub.connect(HOST, PORT, clean_start=False, properties=session_props(300))
sub.loop_start()
sub.subscribe(f"{BASE}/#", qos=1)
time.sleep(2)
print("Retained on subscribe:", received)

# 3. El suscriptor se desconecta, el gateway publica y el suscriptor reanuda su sesión
sub.disconnect(); sub.loop_stop()
gw.publish(f"{BASE}/cnc1/state", "IDLE", qos=1).wait_for_publish()
received.clear()
sub = make_client(sub_id)
sub.on_message = on_message
sub.connect(HOST, PORT, clean_start=False, properties=session_props(300))
sub.loop_start()
time.sleep(2)
print("Delivered after resume:", received)

# 4. Simular la caída del gateway: detener el bucle de red sin DISCONNECT
received.clear()
gw.loop_stop()
gw.socket().close()
time.sleep(10)  # esperar más de 1,5 x keepalive
print("Last will:", received)
sub.disconnect()

Resultado esperado: los valores retenidos ONLINE y RUNNING al suscribirse, el cambio IDLE entregado tras reanudar la sesión aunque se publicó mientras el suscriptor estaba ausente, y OFFLINE llegando en cuanto el broker detecta que el gateway ha desaparecido. Recuerda que el broker público lo puede leer cualquiera y tiene límites deliberados (mensajes de 64 KB, 10 mensajes por segundo por cliente, expiración de sesión de hasta 30 minutos), así que ejecuta las pruebas de carga solo contra tu propio broker.

Lista de comprobación para la evaluación

Ejecuta el script anterior contra el broker candidato con TLS en el puerto 8883.
Publica tráfico Sparkplug B real desde un simulador y comprueba si puedes leerlo en las herramientas del broker.
Reconecta 50 clientes a la vez y observa si hay conexiones rechazadas o CONNACK lentos.
Publica demasiado rápido a propósito y comprueba qué reason code recibes, por ejemplo 0x97 (cuota excedida) en MQTT 5.
Prueba cinco contraseñas erróneas seguidas y confirma que el broker reacciona.
Pregunta quién opera el broker y cómo funciona la renovación de certificados.

Para una comparativa más amplia y no industrial, consulta cómo elegir un broker MQTT para IoT.

Cómo aborda ConnectMQ el uso industrial

ConnectMQ es un broker MQTT gestionado construido teniendo en cuenta estos requisitos. Soporta MQTT 3.1.1 y 5.0 sobre TCP, TLS, WebSocket y WebSocket seguro, retained messages, expiración de sesión y todos los reason codes de MQTT 5. Detecta topics ISA-95 y de Unified Namespace, decodifica Sparkplug B (protobuf y JSON) y republica las métricas Sparkplug en topics ISA-95. Cada broker expone el estado de conexión en $SYS/broker/connection/{clientId}/state, y el portal añade un explorador de topics en vivo, una vista de dispositivos por nivel ISA-95 y reglas de alerta por umbral. El aislamiento multi-tenant, las cuotas por plan, la protección contra flood y el bloqueo de IP tras inicios de sesión fallidos repetidos protegen a cada tenant. Los planes van desde Serverless gratuito hasta clústeres Dedicated, BYOC en tu propia cuenta cloud y Self Managed Enterprise. Para las ventajas e inconvenientes del alojamiento en general, lee nuestra guía de broker MQTT en la nube; para el panorama industrial completo, consulta IoT industrial con MQTT.

Empieza con ConnectMQ

Crea un broker Serverless gratuito en app.connectmq.com, sin tarjeta de crédito. Apunta el script de prueba y un simulador Sparkplug hacia él y verás los datos de tu planta decodificados y organizados por nivel ISA-95 en el portal de ConnectMQ en cuestión de minutos.

Preguntas frecuentes

¿Un broker MQTT industrial necesita soportar Sparkplug B?

Sparkplug B funciona en cualquier broker conforme con retained messages, QoS y last will. Un broker que además decodifica los payloads Sparkplug facilita mucho la puesta en marcha y la resolución de problemas.

¿Es obligatorio MQTT 5 para el uso industrial?

No, Sparkplug B y muchos gateways usan MQTT 3.1.1. MQTT 5 añade funciones útiles como la expiración de sesión, los reason codes y las suscripciones compartidas, por lo que un broker debería soportar ambas versiones.

¿Debo autoalojar o usar un broker MQTT industrial gestionado?

El autoalojamiento da control total, pero hace a tu equipo responsable de parches, certificados y monitorización. Un broker gestionado elimina ese trabajo, y opciones como BYOC mantienen el broker en tu propia cuenta cloud.

¿Cómo sé si un gateway se ha desconectado?

Configura un last will retenido, como OFFLINE, en un topic de estado. El broker lo publica automáticamente cuando el gateway se desconecta sin un DISCONNECT limpio.

Qué buscar en un broker MQTT industrial