MQTT para IoT industrial: la guía completa del IIoT

MQTT en el IoT industrial es la forma en que las plantas modernas llevan los datos de PLC, sensores y máquinas a los sistemas que actúan sobre ellos, sin las frágiles integraciones punto a punto del pasado. Esta guía explica por qué MQTT se convirtió en la columna vertebral del IIoT, cómo se monta una arquitectura del edge a la nube, dónde encajan Sparkplug B y los espacios de nombres de topics ISA-95, y cómo construir un primer flujo de datos de la máquina al broker con código ejecutable. Al terminar tendrás una arquitectura de referencia y una lista de comprobación para llevar a tu próxima reunión de proyecto.

Por qué MQTT se convirtió en la columna vertebral del IoT industrial

La automatización clásica sigue el modelo por capas de Purdue: los sensores hablan con los PLC, los PLC con el SCADA, el SCADA con un historian, y el MES y el ERP están por encima. Cada capa se integra con la siguiente mediante conexiones punto a punto, a menudo con protocolos propietarios. Añadir un nuevo consumidor de datos de máquina, como un dashboard de calidad o un modelo de mantenimiento predictivo, obliga a tocar varios de esos enlaces.

MQTT rompe ese patrón con la publicación/suscripción. Cada fuente de datos publica una sola vez en un broker central, y cualquier número de consumidores se suscribe exactamente a lo que necesita. Si este modelo es nuevo para ti, qué hace un broker MQTT cubre lo fundamental. En el ámbito industrial, varias propiedades de MQTT importan especialmente:

Conexiones solo salientes. Los dispositivos edge abren las conexiones hacia el broker; nada necesita entrar en la red de planta. Eso encaja mucho mejor con las políticas de seguridad OT que los protocolos de sondeo que requieren acceso entrante.
Report by exception. Los dispositivos publican cuando un valor cambia en lugar de ser sondeados en un ciclo fijo, lo que reduce drásticamente el ancho de banda en enlaces lentos o medidos. Consulta report by exception.
Conciencia del estado. Los mensajes de Last Will and Testament, los valores retenidos y los keep-alives indican a cada consumidor si una máquina está en línea y cuál fue su último estado conocido.
Huella ligera. Los clientes MQTT funcionan en PLC, gateways e incluso microcontroladores, y operan sobre enlaces móviles.
Estándar abierto. MQTT es un estándar OASIS con clientes en todos los lenguajes, así que no quedas atado al stack de un proveedor.

Esto no deja obsoletos OPC UA ni los buses de campo. OPC UA sigue siendo excelente para modelos de información ricos y el acceso a nivel de máquina, y por eso la mayoría de las arquitecturas IIoT combinan ambos; los comparamos en OPC UA vs MQTT.

Arquitectura de referencia de MQTT para IoT industrial

Una arquitectura IIoT práctica tiene cuatro capas. Cada una tiene una función clara, y el broker está en el centro.

Capa	Componentes	Responsabilidades
Dispositivos y control	PLC, CNC, robots, sensores, accionamientos	Ejecutan el proceso; exponen datos mediante Modbus, OPC UA, EtherNet/IP, S7 y otros
Edge	Gateways industriales, PC edge, PLC con clientes MQTT	Conversión de protocolos, report by exception, buffer, lógica local
Broker	Broker MQTT en planta o en la nube	Enrutamiento, sesiones, estado, seguridad, la única fuente de verdad para los datos en vivo
Aplicaciones	SCADA, MES, historians, dashboards, analítica, ERP	Consumen, almacenan, visualizan y actúan sobre los datos

El artículo sobre arquitectura IIoT profundiza en cada capa. Estas son las decisiones que más importan.

El gateway edge

La mayoría de las máquinas instaladas no hablan MQTT. Un gateway edge IIoT las lee con su protocolo nativo y publica en el broker. Debe sondear rápido en local pero publicar solo cuando hay cambios, añadir marcas de tiempo y unidades, y almacenar en buffer los mensajes cuando falla el enlace de subida. Esa última tarea se llama store and forward, y es lo que impide que un corte de red se convierta en un hueco en los datos. Para protocolos concretos, consulta Modbus TCP a MQTT, la guía del gateway de OPC UA a MQTT y del PLC a la nube.

Ubicación en la red

Las plantas suelen separar las redes OT e IT, con una DMZ entre ambas. Los patrones habituales son un broker en la DMZ al que publican los gateways OT, un broker en la nube al que se llega mediante una regla de firewall saliente, o ambos conectados mediante un puente. Cada uno tiene ventajas e inconvenientes en latencia, autonomía y seguridad; MQTT en la DMZ industrial los analiza uno por uno.

Dónde se ejecuta el broker

Los brokers en planta siguen funcionando cuando internet no, lo que importa para todo lo que esté dentro de un lazo de control. Los brokers en la nube simplifican mucho la agregación de varias plantas, el acceso remoto y los dashboards. Muchas plantas hacen ambas cosas: la lógica local se queda en local y un broker MQTT en la nube agrega las plantas para la analítica y los sistemas corporativos. Elijas lo que elijas, los requisitos industriales de disponibilidad, aislamiento y seguridad son más altos que en el IoT de consumo, algo que tratamos en cómo elegir un broker MQTT industrial.

Diseño de topics: ISA-95 y el Unified Namespace

MQTT por sí solo no dice nada sobre la estructura de los topics, y esa libertad es peligrosa a escala de planta. Sin una convención, acabas con machine7/temp, Line-2/Temp_C y plant/oven/temperature en el mismo broker, y nadie puede suscribirse a "todo lo de la línea 2".

La respuesta industrial es alinear los topics con la jerarquía de equipos de ISA-95:

enterprise/site/area/line/cell/measurement
acme/izmir/machining/line1/cnc1/spindle_temp

Un broker organizado así se convierte en un Unified Namespace (UNS): un único lugar donde se publica el estado actual de todo el negocio con una estructura que todos entienden. El MES se suscribe a acme/izmir/#, un dashboard de línea a acme/izmir/machining/line1/# y un modelo de mantenimiento a acme/+/+/+/+/vibration. Añadir un consumidor nunca obliga a tocar un productor.

Reglas que funcionan en plantas reales:

Acuerda los nombres de los niveles y los caracteres permitidos antes de que se conecte el primer dispositivo.
Usa minúsculas, sin espacios, e identificadores estables (IDs de activo, no apodos de los operarios).
Separa telemetría, estado, eventos y comandos en topics hoja distintos.
Pon las unidades de ingeniería y las marcas de tiempo en el payload, no en el topic.
Publica el estado actual como retained messages para que los nuevos consumidores lo reciban al instante.

Las pautas detalladas están en topics MQTT ISA-95, estructura de topics del UNS y la guía paso a paso cómo construir un Unified Namespace.

Sparkplug B: estado y estructura para MQTT

Sparkplug B es una especificación de la Eclipse Foundation que define cómo deben usar MQTT los dispositivos industriales. Resuelve tres cosas que MQTT deja abiertas:

Un espacio de nombres de topics: spBv1.0/{group_id}/{message_type}/{edge_node_id}/{device_id}.
Un formato de payload: métricas codificadas en Protobuf con nombres, tipos de datos, marcas de tiempo y alias.
Gestión del estado: certificados de nacimiento (NBIRTH, DBIRTH) y de defunción (NDEATH, DDEATH), para que cada consumidor sepa qué nodos edge y dispositivos están en línea y qué métricas publican.

Tipo de mensaje	Enviado por	Significado
NBIRTH / DBIRTH	Nodo edge / dispositivo	En línea, con la lista completa de métricas y sus valores actuales
NDATA / DDATA	Nodo edge / dispositivo	Valores de métricas que han cambiado (report by exception)
NDEATH / DDEATH	Broker mediante Last Will / nodo edge	Fuera de línea; los valores deben considerarse obsoletos
NCMD / DCMD	Aplicación host	Comando para escribir una métrica o solicitar un renacimiento
STATE	Aplicación host principal	Si el SCADA/host central está en línea

Las ventajas son la interoperabilidad entre productos compatibles con Sparkplug y un estado fiable. El precio es que los payloads Protobuf no son legibles por personas y que la estructura fija de topics no refleja la jerarquía de tu planta. Empieza por las explicaciones de el payload de Sparkplug B y los certificados de nacimiento y defunción de Sparkplug, y recurre a decodificar Sparkplug B en Python cuando necesites inspeccionar el tráfico en bruto.

Sparkplug B e ISA-95 juntos

Muchas plantas usan ambos: Sparkplug B en el edge para una comunicación eficiente y consciente del estado, y un espacio de nombres ISA-95 en JSON para todos los demás. La parte delicada es la capa de traducción entre ellos. Nuestro artículo sobre Sparkplug B y el Unified Namespace compara los dos enfoques en detalle, y la siguiente sección muestra cómo un broker puede hacer la traducción por ti.

Práctica: tu primer flujo de datos MQTT para IoT industrial

Puedes probar ahora mismo patrones de topics industriales en el servidor MQTT público gratuito en broker.connectmq.com. Usa un prefijo único, mantén los topics en un máximo de 8 niveles y recuerda que cualquiera puede leer el área pública, así que usa solo datos simulados.

Suscríbete a toda la planta simulada:

mosquitto_sub -h broker.connectmq.com -p 1883 -i iiot-sub-m5q2 \
  -t "connectmq/demo/m5q2/#" -v

Publica una lectura con estilo ISA-95 y un estado de máquina retenido:

mosquitto_pub -h broker.connectmq.com -p 1883 -i iiot-pub-m5q2 -q 1 \
  -t "connectmq/demo/m5q2/machining/line1/cnc1/telemetry" \
  -m '{"spindle_temp":61.4,"spindle_rpm":8200,"unit_temp":"C","ts":1760600000}'

mosquitto_pub -h broker.connectmq.com -p 1883 -i iiot-pub-m5q2 -q 1 -r \
  -t "connectmq/demo/m5q2/machining/line1/cnc1/state" -m "RUNNING"

Un puente edge mínimo de Modbus TCP a MQTT

El siguiente script hace de gateway edge. Lee cada segundo dos holding registers de un dispositivo Modbus TCP, publica solo cuando un valor cambia más allá de una banda muerta y registra un Last Will para que los consumidores sepan cuándo desaparece el gateway. Usa pymodbus 3.x y paho-mqtt 2.x:

pip install "pymodbus>=3.6" "paho-mqtt>=2.0"

import json
import time

import paho.mqtt.client as mqtt
from pymodbus.client import ModbusTcpClient

PLC_HOST = "192.168.1.50"      # tu dispositivo Modbus TCP o simulador
BASE = "connectmq/demo/m5q2/machining/line1/press1"
DEADBAND = 0.5                 # publica solo si un valor varía al menos esto

def on_connect(client, userdata, flags, reason_code, properties):
    print("Broker connection:", reason_code)
    client.publish(f"{BASE}/state", "ONLINE", qos=1, retain=True)

mqttc = mqtt.Client(
    mqtt.CallbackAPIVersion.VERSION2,
    client_id="edge-press1-m5q2",
    protocol=mqtt.MQTTv5,
)
mqttc.will_set(f"{BASE}/state", "OFFLINE", qos=1, retain=True)
mqttc.on_connect = on_connect
mqttc.reconnect_delay_set(min_delay=1, max_delay=30)
mqttc.connect("broker.connectmq.com", 1883, keepalive=30)
mqttc.loop_start()

plc = ModbusTcpClient(PLC_HOST, port=502)
last = {}

while True:
    if not plc.connected:
        plc.connect()
    rr = plc.read_holding_registers(address=0, count=2)
    if rr.isError():
        print("Modbus read failed:", rr)
        time.sleep(2)
        continue

    values = {
        "pressure_bar": rr.registers[0] / 10.0,  # escalado x10 en el PLC
        "temperature_c": rr.registers[1] / 10.0,
    }
    changed = {k: v for k, v in values.items()
               if k not in last or abs(v - last[k]) >= DEADBAND}
    if changed:
        changed["ts"] = int(time.time() * 1000)
        mqttc.publish(f"{BASE}/telemetry", json.dumps(changed), qos=1)
        last.update({k: v for k, v in changed.items() if k != "ts"})
    time.sleep(1)

Observa el terminal del suscriptor: los valores solo aparecen cuando cambian, y llega OFFLINE si matas el script. El escalado de registros, el orden de las palabras y el direccionamiento varían entre fabricantes de PLC, así que revisa el mapa de registros del dispositivo; nuestra guía de puente de Modbus a MQTT cubre esos detalles. Un gateway de producción también guardaría en disco durante los cortes y usaría TLS con credenciales.

Cómo da soporte ConnectMQ al IoT industrial con MQTT

ConnectMQ es un broker MQTT gestionado con funciones pensadas específicamente para el tráfico industrial:

Detección de ISA-95 y UNS. El broker reconoce en tu tráfico las estructuras de topics ISA-95 y Unified Namespace.
Decodificación de Sparkplug B. Los payloads Sparkplug B se decodifican (Protobuf o JSON) para que puedas leerlos en el portal en lugar de mirar bytes.
Republicación de Sparkplug a ISA-95. Los datos Sparkplug B pueden republicarse en topics ISA-95 con payloads legibles; por ejemplo, spBv1.0/factory1/DDATA/line1/cnc1 pasa a ser connectmq/factory1/production/line1/cnc1/telemetry. Los nodos edge siguen hablando Sparkplug mientras el MES y los dashboards consumen un espacio de nombres limpio.
Vista de dispositivos ISA-95 y alertas. El portal muestra los dispositivos organizados por niveles ISA-95, y las reglas de alerta por umbral con registro de alertas señalan valores como una temperatura de husillo que supera un límite.
Elección de despliegue. Empieza con el plan Serverless gratuito y pasa después a un clúster aislado Dedicated, a BYOC dentro de tu propia cuenta en la nube o a Self Managed Enterprise para plantas que deben permanecer on-premises.

Para ver cómo queda todo de principio a fin, la demo web del gemelo digital 3D de ConnectMQ muestra una fábrica con una CNC, un brazo robótico, un horno, un depósito, una cinta transportadora y una bomba que se actualizan en vivo por WebSocket seguro. El almacenamiento y la analítica se resuelven de forma abierta: historians, Telegraf, Node-RED o tus propios servicios se suscriben al broker como clientes MQTT estándar. Consulta cómo construir un historian MQTT para ese patrón.

Lista de comprobación para un proyecto de MQTT en IoT industrial

Usa esta lista al definir el alcance de un primer despliegue. La versión completa está en nuestra checklist de conectividad IIoT.

Inventaría máquinas, protocolos y los puntos de datos que realmente responden a una pregunta de negocio.
Acuerda con OT e IT una jerarquía de topics ISA-95 y unas reglas de nomenclatura.
Decide el formato de payload: Sparkplug B en el edge, JSON para los consumidores, o ambos.
Elige el hardware de gateway y confirma que admite buffer y TLS.
Decide dónde se ejecuta el broker y cómo cruza el tráfico la frontera OT/IT.
Emite credenciales únicas por gateway y exige TLS en el 8883.
Define la gestión del estado: Last Will, topics de estado retenidos, mensajes de nacimiento y defunción.
Planifica el almacenamiento y la visualización con herramientas suscriptoras, no con magia en el broker.
Haz un piloto en una línea, mide y después escala.

La alineación organizativa importa tanto como la tecnología; la convergencia IT/OT explica cómo se reparten las responsabilidades entre equipos. Para ver dónde encaja esta capa de conectividad en un programa de transformación digital, lee nuestra guía de la Industria 4.0.

Crea tu piloto de IoT industrial con ConnectMQ

Prueba los ejemplos anteriores en broker.connectmq.com y después crea un broker privado en app.connectmq.com. El plan Serverless gratuito no requiere tarjeta de crédito y basta para un piloto de una sola línea con unos pocos gateways, dashboards y la decodificación de Sparkplug B y las vistas ISA-95 descritas arriba.

Preguntas frecuentes

¿Es MQTT adecuado para la automatización industrial?

Sí, para mover datos entre máquinas, gateways edge y aplicaciones. Los lazos de control en tiempo real estricto siguen perteneciendo a los buses de campo y los PLC; MQTT transporta los datos a su alrededor hacia el SCADA, el MES, los historians y la analítica.

¿Necesito Sparkplug B para MQTT en IoT industrial?

No, pero ayuda cuando deben interoperar productos de muchos fabricantes y necesitas un estado en línea/fuera de línea fiable. Muchas plantas usan Sparkplug B en el edge y un espacio de nombres ISA-95 en JSON para los consumidores.

¿El broker MQTT industrial debe ejecutarse en planta o en la nube?

Nada que esté dentro de un lazo de control debería depender de un enlace a internet, por eso los brokers locales son habituales en planta. Un broker en la nube es mejor para la agregación de varias plantas, los dashboards remotos y la integración corporativa, y muchas arquitecturas usan ambos.

¿Cómo conecto un PLC que no admite MQTT?

Usa un gateway edge que lea el PLC con su protocolo nativo, como Modbus, OPC UA, S7 o EtherNet/IP, y publique en el broker. Muchos PLC más recientes también incorporan clientes MQTT.

¿Puede ConnectMQ leer mensajes Sparkplug B?

Sí. ConnectMQ decodifica los payloads Sparkplug B y puede republicarlos en topics ISA-95 con payloads legibles, para que los consumidores que no usan Sparkplug puedan aprovechar los datos directamente.

IoT industrial con MQTT: la guía completa del IIoT