Unified Namespace (UNS): qué es, principios y arquitectura con MQTT y Sparkplug B

El Unified Namespace (UNS) es un patrón de arquitectura de datos industrial en el que todos los sistemas de una organización, de planta y de negocio, publican y consumen sus datos en un único espacio de nombres jerárquico y en tiempo real, normalmente implementado como un árbol de topics sobre un broker MQTT. En lugar de conectar cada sistema con cada sistema, todos hablan con el namespace: es la fuente única del estado actual de la organización. Esta guía desarrolla el concepto a fondo: definición, principios, estructura, arquitectura técnica con MQTT y Sparkplug B, en qué se diferencia de un data lake o de un historiador, y cómo lo implementamos con Captia Connect.

Qué es el Unified Namespace: definición

Una definición operativa: el Unified Namespace es una estructura centralizada de publicación y suscripción donde reside el estado actual de todos los datos relevantes del negocio, organizados en una jerarquía semántica que refleja la estructura física y funcional de la organización. Tres palabras cargan el peso de la definición:

• Unified (unificado). Un solo espacio de nombres para toda la organización. El dato del PLC, el resultado de calidad, el consumo del contador y el estado de la orden de fabricación conviven en el mismo árbol, con la misma convención de nombres. No hay un silo por departamento.
• Namespace (espacio de nombres). Lo que se comparte no es una base de datos ni una API: es una jerarquía de nombres con semántica pactada. Cada nodo del árbol dice qué es el dato y dónde vive, y esa dirección es estable aunque cambie la tecnología que hay debajo.
• Estado actual. El UNS contiene la foto viva de la planta en este momento. No es un archivo histórico: el histórico es un consumidor que se suscribe al UNS y persiste lo que pasa por él.

El término se asocia a Walker Reynolds y la comunidad de Industria 4.0 que lo popularizó a partir de los años 2010, pero el patrón no pertenece a ningún fabricante: es una decisión de arquitectura que se puede implementar con componentes abiertos. Esa neutralidad es parte esencial de su valor.

El problema que resuelve: integración punto a punto

Sin un UNS, cada necesidad de dato se resuelve con una integración directa: el MES lee del SCADA, el dashboard consulta al MES, el ERP recibe un CSV nocturno del historiador. Con pocos sistemas el patrón funciona; con cada sistema nuevo, el número de conexiones posibles crece de forma combinatoria y cada conexión es un desarrollo propio, con su formato, su credencial y su modo de fallar. La literatura de arquitectura lo llama espagueti de integración.

El UNS invierte la dirección de las integraciones. Cada sistema se conecta una sola vez, al namespace, como productor, como consumidor o como ambos. Añadir el sistema número veinte cuesta una conexión, no diecinueve. Y como productores y consumidores no se conocen entre sí, sustituir un sistema no rompe a los demás: el contrato es el namespace, no la tecnología que publica en él.

Este mismo problema, contado desde la perspectiva del proyecto de conectar la planta con los sistemas corporativos, lo desarrollamos en la guía de integración OT/IT con unified namespace: aquella pieza recorre el roadmap de implantación; esta profundiza en el concepto y su arquitectura.

Los cuatro principios del UNS

1. El UNS es la fuente única del estado actual. Cualquier sistema que quiera saber qué está pasando pregunta al namespace, no a la máquina ni a otra aplicación. Si un dato importa para el negocio, se publica en el UNS; si no está en el UNS, para el resto de la organización no existe.

2. Arquitectura orientada a eventos. Los datos se publican cuando cambian y los consumidores reaccionan cuando llegan. No hay polling, no hay extracciones programadas de madrugada: el dato viaja en el momento en que nace, y quien lo necesita lo recibe con segundos de latencia, no con horas.

3. El dato nace en el borde y sube normalizado. La traducción de protocolos, las unidades de ingeniería, la marca de tiempo de origen y la calidad de la lectura se resuelven en el edge, una sola vez, antes de publicar. Todos los consumidores ven la misma versión del dato, con la misma semántica.

4. Arquitectura abierta y desacoplada. El UNS se apoya en estándares abiertos (MQTT como transporte, Sparkplug B como semántica, ISA-95 como jerarquía de referencia) precisamente para que ningún componente sea insustituible. El broker se puede cambiar, el gateway se puede cambiar, y el namespace, que es el activo real, permanece.

Estructura: la jerarquía ISA-95 como esqueleto

Un namespace necesita una columna vertebral y el punto de partida habitual es la jerarquía de equipamiento de ISA-95: empresa, planta, área, línea, célula o equipo. Sobre ese esqueleto físico se cuelgan las señales y, en ramas paralelas, los datos funcionales elaborados:

empresa/planta/area/linea/maquina/señal

acme/valencia/mecanizado/linea-2/cnc-07/husillo/temperatura
acme/valencia/mecanizado/linea-2/cnc-07/estado
acme/valencia/mecanizado/linea-2/oee/turno-actual
acme/valencia/energia/cuadro-general/potencia-activa

La regla de oro es que la jerarquía describe qué es el dato y dónde vive, nunca quién lo consume: no hay ramas llamadas erp ni dashboard. Y la decisión más rentable de todo el proyecto es pactar por escrito la convención de nombres (niveles, idioma, mayúsculas, unidades) antes de conectar la segunda máquina. Muchas organizaciones separan además una rama de dato crudo, tal como sale del gateway, y una rama funcional con indicadores elaborados, como estado de línea u OEE por turno, a la que se suscriben los consumidores de negocio.

Arquitectura técnica: MQTT y Sparkplug B

El UNS es un patrón, no un producto, pero su implementación de referencia se apoya en dos estándares que encajan como capas:

MQTT como transporte. Protocolo de publicación y suscripción estandarizado por OASIS, ligero, tolerante a redes malas y con mecanismos como el last will para detectar clientes caídos. Su modelo de topics jerárquicos con comodines es exactamente la forma que necesita un namespace: suscribirse a acme/valencia/mecanizado/# es suscribirse a un área entera de la planta. Cómo se compara con el enfoque cliente-servidor de OPC UA lo tratamos en OPC UA frente a MQTT.

Sparkplug B como semántica. MQTT no dice nada del contenido del payload; Sparkplug B, especificación abierta de la Eclipse Foundation, lo define: estructura de topics predecible, métricas tipadas en un formato binario eficiente, gestión de estado con birth y death certificates, y publicación solo por cambio. Cualquier consumidor sabe en todo momento si un dato está vivo o es información antigua. Dedicamos a la especificación un artículo propio: Sparkplug B: qué define y cuándo usarlo.

Sobre esas dos capas, la arquitectura mínima de un UNS tiene tres piezas:

• Gateways edge en la red de planta, que leen cada máquina en su protocolo nativo, normalizan y publican en el namespace. Si la red cae, almacenan en un buffer local persistente y publican el atraso al volver.
• Un broker MQTT como punto de encuentro, en planta, en una nube privada o en cloud público: edge y consumidores solo se conectan a él.
• Consumidores suscritos: historiador, dashboards, MES, ERP, modelos de análisis. Cada uno escucha las ramas que le interesan y ninguno conoce a los productores.

Esta es también la espina dorsal de una arquitectura completa de datos de planta; cómo encaja el UNS con la capa de persistencia y la de consumo lo desarrollamos en la guía de la plataforma de datos industriales.

UNS frente a data lake, historiador y ESB

UNS frente a data lake. El data lake almacena datos en reposo para análisis posterior; el UNS distribuye el estado actual en movimiento. No compiten: el data lake es un consumidor natural del UNS. Confundirlos lleva a intentar hacer analítica histórica contra un broker o distribución en tiempo real contra un almacén, y ninguna de las dos cosas funciona bien.

UNS frente a historiador. El historiador industrial persiste series temporales de proceso y las sirve para consulta. En una arquitectura UNS es un suscriptor más: escucha el namespace y graba. El UNS no guarda histórico; garantiza que el histórico que se guarde sea completo y coherente porque todo pasó por el mismo canal.

UNS frente a ESB o middleware corporativo. Un enterprise service bus también centraliza integraciones, pero orquesta transacciones entre aplicaciones IT con transformaciones por cada par de sistemas. El UNS es más simple y más radical: no orquesta, publica. La semántica no se negocia conexión a conexión, se fija una vez en el namespace, y eso lo hace operable por un equipo de planta sin un departamento de middleware.

Cómo implementa Captia Connect un UNS

Captia Connect es la capa edge de adquisición de datos con la que construimos este patrón en plantas reales. Su encaje con el UNS es directo:

• Adquisición multiprotocolo en el edge. Lectura de PLC, sensores, contadores y SCADA sobre MQTT, OPC UA, Modbus TCP y Modbus RTU sobre RS-485, entre otros protocolos, de modo que las máquinas existentes participan en el namespace sin modificarse. Es el terreno de la conectividad con PLC y la ingesta edge.
• Normalización en origen. Las señales se traducen a nombres de negocio y unidades pactadas antes de publicarse, de forma que el namespace recibe dato limpio, no direcciones de registro.
• Buffering y persistencia sin conectividad. Si el enlace con el broker cae, la captura continúa y el atraso se publica al volver, con lo que el histórico aguas arriba queda completo.
• Conectividad segura y despliegue flexible. Envío seguro hacia el broker y despliegue local, híbrido o cloud según la planta.

Aguas arriba del namespace, Captia.ai consume ese mismo dato para SCADA web, dashboards, reglas, alertas y workflows: un ejemplo de que, con el UNS bien construido, cada consumidor nuevo es una suscripción y no un proyecto de integración.

Errores habituales al construir un UNS

Tratarlo como un producto que se compra. Instalar un broker no crea un UNS, igual que comprar estanterías no crea una biblioteca. El activo es la convención de nombres y la disciplina de publicarlo todo por el mismo canal.

Dejar la jerarquía para después. Un namespace con nombres improvisados degenera en el caos que pretendía resolver, solo que dentro de un broker. La convención se pacta por escrito antes de conectar la segunda máquina.

Publicar dato crudo sin normalizar. Si cada consumidor tiene que adivinar unidades y escalas, el UNS solo ha movido el problema de sitio. La normalización en el edge no es opcional.

Usarlo como archivo histórico. El UNS es estado actual en movimiento. El histórico vive en un consumidor que persiste, no en el broker.

Permitir integraciones punto a punto "provisionales". Cada conector directo abierto "solo por ahora" es deuda que el namespace tendrá que absorber después. La disciplina incomoda la primera semana y renta todos los años siguientes.

Preguntas frecuentes sobre el Unified Namespace

Si estás valorando construir un Unified Namespace en tu planta, en Captia Connect implementamos exactamente esta arquitectura, desde la integración MQTT y la integración OT/IT hasta el diseño de la jerarquía de nombres. El detalle de la arquitectura completa está en nuestra plataforma de datos industriales.