Saber cómo construir un Unified Namespace convierte una palabra de moda en una arquitectura que funciona: un único broker MQTT donde cada máquina, línea y sistema publica su estado actual bajo un topic predecible basado en la jerarquía. En este tutorial modelarás tu planta, elegirás un broker, publicarás datos edge retenidos con Python, añadirás un consumidor que lee el estado completo de la planta y establecerás la gobernanza que mantiene el namespace utilizable a medida que crece.
Qué vas a construir
Un Unified Namespace (UNS) no es un producto. Es un acuerdo: todos los productores publican en un único hub orientado a eventos, organizado según una estructura compartida, y todos los consumidores se suscriben a lo que necesitan en lugar de construir integraciones punto a punto. En la práctica, ese hub es un broker MQTT y la estructura suele ser la jerarquía de equipos ISA-95.
La arquitectura final tiene cuatro capas:
| Capa | Responsabilidad | Componentes típicos |
|---|---|---|
| Edge | Leer las máquinas y publicar su estado | Gateways de PLC, puentes OPC UA o Modbus, nodos edge Sparkplug |
| Hub | Enrutar y conservar el estado actual | Broker MQTT con retained messages |
| Estructura | Hacer que los datos sean localizables | Árbol de topics ISA-95, convenciones de payload |
| Consumidores | Usar los datos | Dashboards, historians, MES, analítica, alertas |
La propiedad clave es el desacoplamiento. El historian no sabe que el PLC existe y el gateway del PLC no sabe quién está escuchando. Cada uno se conecta una sola vez, al broker.
Paso 1: Modela la jerarquía de tu planta
Antes de escribir código, decide cómo se organiza la planta en el namespace. La jerarquía de equipos ISA-95 ofrece un punto de partida probado: empresa, sitio, área, línea (o celda de proceso) y celda o máquina. Nuestra guía sobre la jerarquía de equipos ISA-95 explica cada nivel con ejemplos de planta.
Recorre una lista breve para un área piloto:
- Enumera los sitios incluidos y asigna a cada uno un identificador corto, estable y en minúsculas (
dallas,izmir). - Dentro de un sitio, enumera las áreas (
packaging,utilities,machining). - Dentro de un área, enumera las líneas y sus máquinas (
line2/filler,line2/capper). - Decide qué va debajo de cada máquina: un objeto
telemetry, topics individuales por métrica o ambos. - Documenta el resultado como un árbol de topics y consigue que operaciones, ingeniería e IT lo acuerden.
Un primer árbol piloto podría tener este aspecto:
acme/dallas/packaging/line2/filler/telemetry
acme/dallas/packaging/line2/filler/state
acme/dallas/packaging/line2/capper/telemetry
acme/dallas/utilities/compressors/comp1/telemetry
Dedica tiempo a esta fase. Renombrar un topic cuando ya dependen de él veinte consumidores es doloroso. Nuestras guías sobre topics MQTT ISA-95 y la estructura de topics de un UNS incluyen árboles listos para usar y los errores que conviene evitar.
Paso 2: Elige el broker central
El broker se convierte en el software de planta más importante que operas, así que elígelo con criterio. Debe soportar MQTT 3.1.1 para los gateways más antiguos y MQTT 5 para los clientes nuevos, retained messages para el estado actual, TLS con credenciales por cliente y suficientes conexiones para cada gateway y consumidor que vayas a añadir. Para una lista de comprobación completa, consulta cómo elegir un broker MQTT para IoT.
Puedes ejecutar el broker tú mismo en un servidor de la planta o usar un broker MQTT en la nube operado por un tercero. Las plantas suelen empezar el piloto con un broker MQTT gestionado porque así eliminan del camino crítico la aplicación de parches y la monitorización de servidores. ConnectMQ, por ejemplo, ofrece en cada broker MQTT 3.1.1 y 5.0, TLS en el puerto 8883, un explorador de topics en vivo y una vista de dispositivos que agrupa los dispositivos activos por niveles ISA-95, justo lo que quieres ver mientras el namespace toma forma.
Para este tutorial puedes usar el servidor MQTT público gratuito en broker.connectmq.com, pensado para pruebas y prototipos, no para datos de producción. No necesita cuenta, pero todo lo que se publica allí es legible por cualquiera, así que anteponemos a los topics connectmq/demo/<random-id>/ y publicamos solo valores simulados. El broker público admite hasta 8 niveles de topic, lo que encaja exactamente con connectmq/demo/k4p9/dallas/packaging/line2/filler/telemetry.
Paso 3: Publica los datos edge como estado retenido
La capa edge lee las máquinas y publica su estado actual. Los despliegues reales usan drivers OPC UA, Modbus o de PLC; aquí un script de Python hace las veces de gateway para que veas con claridad las reglas de publicación. Instala el cliente con pip install "paho-mqtt>=2.0".
import json
import random
import time
from datetime import datetime, timezone
import paho.mqtt.client as mqtt
BROKER = "broker.connectmq.com"
PREFIX = "connectmq/demo/k4p9" # sustituye k4p9 por tu propio ID aleatorio
MACHINES = [
("dallas", "packaging", "line2", "filler"),
("dallas", "packaging", "line2", "capper"),
]
def on_connect(client, userdata, flags, reason_code, properties):
print("gateway connected:", reason_code)
for site, area, line, machine in MACHINES:
state_topic = f"{PREFIX}/{site}/{area}/{line}/{machine}/state"
client.publish(state_topic, "online", qos=1, retain=True)
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="uns-gateway-k4p9")
client.on_connect = on_connect
# Si el gateway cae, el broker marca la primera máquina como offline para todos
client.will_set(f"{PREFIX}/dallas/packaging/line2/filler/state", "offline", qos=1, retain=True)
client.connect(BROKER, 1883, keepalive=30)
client.loop_start()
counts = {m[3]: 0 for m in MACHINES}
try:
while True:
for site, area, line, machine in MACHINES:
counts[machine] += random.randint(4, 6)
payload = {
"timestamp": datetime.now(timezone.utc).isoformat(),
"speed_bpm": round(random.uniform(110, 125), 1),
"temperature_c": round(random.uniform(38, 44), 1),
"good_count": counts[machine],
}
topic = f"{PREFIX}/{site}/{area}/{line}/{machine}/telemetry"
client.publish(topic, json.dumps(payload), qos=1, retain=True)
time.sleep(5)
except KeyboardInterrupt:
client.loop_stop()
client.disconnect()
Tres reglas convierten esto en un publicador UNS y no en un simple emisor de datos. Cada mensaje es retenido, de modo que un consumidor nuevo recibe el valor actual de inmediato. Los payloads llevan su propio timestamp y las unidades en los nombres de los campos. Y la disponibilidad de la máquina es explícita, con un mensaje de última voluntad (will) que cambia el estado a offline cuando el gateway desaparece.
Si tu edge ya habla Sparkplug B, no tienes que reescribirlo. ConnectMQ decodifica payloads Sparkplug B y puede republicarlos en topics ISA-95, por ejemplo spBv1.0/factory1/DDATA/line1/cnc1 en connectmq/factory1/production/line1/cnc1/telemetry. Así, los nodos edge Sparkplug y los publicadores JSON simples comparten un mismo namespace. Las ventajas e inconvenientes de cada opción se tratan en MQTT, Sparkplug B y el Unified Namespace.
Paso 4: Añade tus primeros consumidores
Un namespace demuestra su valor cuando aparecen consumidores sin que nadie toque el edge. Este suscriptor construye un modelo en memoria de toda la planta a partir de una única suscripción con comodín:
import json
import paho.mqtt.client as mqtt
PREFIX = "connectmq/demo/k4p9"
plant = {}
def on_connect(client, userdata, flags, reason_code, properties):
client.subscribe(f"{PREFIX}/#", qos=1)
def on_message(client, userdata, msg):
levels = msg.topic[len(PREFIX) + 1:].split("/")
if len(levels) != 5:
return
site, area, line, machine, kind = levels
node = plant.setdefault(site, {}).setdefault(area, {}).setdefault(line, {}).setdefault(machine, {})
text = msg.payload.decode()
node[kind] = json.loads(text) if kind == "telemetry" else text
print(f"{site}/{area}/{line}/{machine} {kind}: {node[kind]}" + (" (retained)" if msg.retain else ""))
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="uns-viewer-k4p9")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=60)
client.loop_forever()
Ejecútalo mientras el gateway está en marcha y fíjate en que los primeros mensajes llegan marcados como retenidos: el consumidor tuvo la imagen completa de la planta en el momento de suscribirse. Acota el alcance con comodines después del prefijo, por ejemplo connectmq/demo/k4p9/+/packaging/# para un área en todos los sitios o connectmq/demo/k4p9/+/+/+/filler/telemetry para todas las llenadoras de cualquier lugar.
Los siguientes consumidores habituales son un dashboard, un historian y un servicio de alertas. Cada uno es simplemente otro suscriptor, y lo mismo vale para un gemelo digital 3D de la línea que lea los estados retenidos. Para el almacenamiento, nuestra guía sobre el historian MQTT muestra suscriptores con Telegraf y Python que alimentan bases de datos de series temporales; el namespace sigue siendo la fuente de la verdad actual mientras el almacenamiento guarda el histórico.
Paso 5: Gobierna el namespace
Sin reglas, un UNS degenera en un pantano de topics en cuestión de meses. Establece lo siguiente antes de que se incorpore la segunda área:
- Estándar de nombres. Minúsculas, guiones en lugar de espacios, sin nombres de personas ni números de ticket en los topics.
- Propiedad. Cada rama del árbol tiene un responsable que aprueba los topics nuevos.
- Contrato de payload. Un esquema JSON documentado por tipo de topic, con reglas de unidades y timestamps.
- Credenciales por publicador. Una identidad por gateway o aplicación para saber quién publica qué y revocar el acceso limpiamente.
- Proceso de cambios. Los topics nuevos se añaden y los antiguos se marcan como obsoletos con una fecha de retirada; nunca se renombran en silencio.
- Observabilidad. Alguien vigila el estado de las conexiones, las tasas de mensajes y los topics inactivos.
El portal de ConnectMQ ayuda en la parte de observabilidad: el explorador de topics en vivo muestra el árbol a medida que crece, la vista de dispositivos ISA-95 indica a qué empresa, sitio, área y línea pertenece cada dispositivo activo, y las reglas de alerta por umbral te avisan cuando un valor cruza un límite.
Errores comunes al construir un UNS
| Error | Consecuencia | Mejor enfoque |
|---|---|---|
| Empezar a escala de toda la planta | Meses de modelado antes de obtener valor | Pilotar una línea y después ampliar |
| Estado no retenido | Los consumidores nuevos no ven nada hasta que cambian los valores | Retener los topics de estado actual |
| Tecnología en la ruta del topic | opcua/ y modbus/ se filtran hasta los consumidores |
Modelar la planta, no el protocolo |
| Un único login compartido para el broker | Sin trazabilidad y revocación arriesgada | Una credencial por cliente |
| Usar el UNS como base de datos | El broker guarda un histórico para el que nunca se diseñó | Un historian o data lake se suscribe |
Para el contexto industrial más amplio, consulta nuestra guía de MQTT para IoT industrial.
Construye tu Unified Namespace en ConnectMQ
Un Unified Namespace necesita un broker en cuya disponibilidad puedas confiar y una visión clara del árbol de topics a medida que crece. ConnectMQ es un broker MQTT gestionado con MQTT 3.1.1 y 5.0, TLS, retained messages, decodificación Sparkplug B, republicación ISA-95 y una vista de dispositivos ISA-95. Empieza tu piloto en el plan gratuito Serverless en app.connectmq.com, sin tarjeta de crédito, y pasa a un plan de pago, Dedicated o BYOC a medida que se incorporen más líneas.
Preguntas frecuentes
¿Necesito Sparkplug B para construir un Unified Namespace?
No. Muchos namespaces usan JSON simple sobre MQTT. Sparkplug B añade gestión de estado y métricas tipadas, y ambos pueden coexistir si el broker republica los datos Sparkplug en topics legibles.
¿El broker del UNS debe ejecutarse on-premise o en la nube?
Ambas opciones funcionan. On-premise mantiene el tráfico en local; un broker alojado elimina trabajo de operación y facilita el acceso entre sitios. Muchas plantas empiezan el piloto con un broker alojado y deciden en función de lo que aprenden.
¿Qué tamaño debe tener el primer piloto de UNS?
Una línea o un área con unas pocas máquinas y dos o tres consumidores bastan para demostrar el patrón y afinar el estándar de nombres.
¿Un Unified Namespace sustituye a un historian?
No. El UNS contiene el estado actual y los eventos; un historian o un data lake se suscribe a él y conserva el histórico a largo plazo.
