OT/IT bridge: unified namespace y MQTT Sparkplug B en industria

El puente OT/IT es el problema más silencioso de la industria: una máquina CNC de 1995 generando datos, un PLC hablando Modbus, y un ERP que necesita esa información pero nunca la recibe limpia. El unified namespace (UNS) resuelve ese puente con una idea de arquitectura, no con otro producto: un único árbol de topics MQTT donde todos los sistemas de planta y de negocio publican y consumen datos en el mismo lenguaje. Veremos cómo se diseña un unified namespace con MQTT Sparkplug B, qué papel juega el edge, cómo se organiza la jerarquía de nombres y qué errores conviene evitar.

Por qué OT e IT siguen siendo continentes separados

IT y OT no se llevan mal por capricho: optimizan cosas distintas. IT optimiza velocidad y flexibilidad. Un servidor puede reiniciarse, un microservicio puede redesplegarse diez veces al día, y si un dato se pierde suele haber una copia o una forma de regenerarlo. OT optimiza continuidad. Una máquina no se reinicia a mitad de un lote, un PLC lleva quince años ejecutando el mismo programa sin parpadear, y si un dato de proceso se pierde nadie sabrá después qué pasó en ese intervalo.

Esa diferencia de prioridades se refleja en los protocolos. Los que usa IT (HTTP, APIs REST, colas de mensajería corporativas) presuponen redes estables y clientes que pueden reintentar. Los que usa OT (Modbus, PROFINET, OPC UA en su uso clásico) nacieron para el determinismo en la red local y encajan mal cuando hay que atravesar una WAN o escalar a miles de dispositivos. Cuando un ingeniero de IT propone centralizar la autenticación de los equipos de planta en un directorio corporativo, el ingeniero de OT ve el riesgo inmediato: si ese servidor falla, la máquina deja de hablar.

El resultado habitual es que cada lado construye su silo. IT despliega su plataforma de datos y sus dashboards; OT mantiene sus SCADA y sus históricos locales. Entre ambos, integraciones punto a punto: un conector del MES al ERP, un script que exporta CSV del historiador, una API que lee del SCADA. Cada integración nueva multiplica el acoplamiento, y el dato que el negocio necesita para decidir llega tarde, incompleto o con unidades sin documentar. Ese patrón de conexiones directas entre pares de sistemas es lo que la literatura de arquitectura llama espagueti de integración, y es exactamente lo que el unified namespace viene a sustituir.

Qué es el unified namespace: arquitectura, no producto

El unified namespace es una decisión de arquitectura con un enunciado simple: todos los datos relevantes de la organización se publican en un único espacio de nombres jerárquico, en tiempo real, y cualquier sistema que necesite un dato se suscribe a él en lugar de pedírselo directamente a quien lo produce. En la práctica, ese espacio de nombres se implementa casi siempre como un árbol de topics sobre un broker MQTT. Aquí lo tratamos desde la perspectiva del proyecto de integración; el concepto en profundidad, con sus principios y comparativas, lo desarrollamos en la guía del Unified Namespace (UNS).

El cambio de fondo está en la dirección de las integraciones. En el modelo punto a punto, cada consumidor conoce a cada productor: el dashboard sabe la IP del SCADA, el ERP sabe qué tabla del MES leer. En el modelo UNS, productores y consumidores solo conocen el namespace. La máquina publica su estado en su rama del árbol; quien lo necesite se suscribe. Añadir un consumidor nuevo no toca nada de lo existente. Añadir una máquina nueva tampoco: publica en su rama y los suscriptores que escuchan con comodines la descubren.

Que el UNS sea arquitectura y no producto tiene consecuencias prácticas:

• Las máquinas antiguas no cambian. El PLC sigue hablando Modbus a su ritmo. Un gateway edge lo escucha, traduce y publica por él.
• El dato viaja una sola vez. Se captura y se normaliza en origen, y a partir de ahí todos los consumidores ven la misma versión.
• El estado actual es consultable. Con mensajes retenidos o con el mecanismo de birth certificates de Sparkplug, un sistema que se conecta obtiene la foto completa de la planta sin hacer polling a nadie.
• Escala por diseño. Un broker MQTT bien dimensionado maneja decenas de miles de clientes; el patrón publicación-suscripción no degrada al añadir consumidores.

Cómo se organiza el namespace: jerarquía y nombres

La parte más difícil de un UNS no es el broker: es el acuerdo sobre los nombres. Un namespace sin gobierno degenera en el mismo caos que pretendía resolver, solo que dentro de un broker. El punto de partida habitual es la jerarquía de equipamiento de ISA-95: empresa, planta, área, línea, célula o equipo. Sobre esa columna vertebral se cuelgan las señales:

captia/valencia/mecanizado/linea-2/cnc-07/estado
captia/valencia/mecanizado/linea-2/cnc-07/piezas/contador
captia/valencia/mecanizado/linea-2/cnc-07/husillo/temperatura
captia/valencia/energia/cuadro-general/potencia-activa

Tres reglas evitan la mayoría de los problemas posteriores. Primera: la jerarquía describe dónde está el dato y qué representa, nunca quién lo consume (nada de ramas llamadas dashboard o erp). Segunda: los nombres se pactan por escrito antes de conectar la segunda máquina, con un documento corto que defina niveles, idioma y convención de mayúsculas. Tercera: junto al valor viajan sus metadatos, como unidad de ingeniería, marca de tiempo de origen y calidad de la lectura, de modo que el consumidor no tenga que adivinar si esa temperatura está en grados o en décimas de grado.

Es útil distinguir también entre el dato crudo del dispositivo y el dato funcional del negocio. Muchas organizaciones publican ambos en ramas separadas: una rama de bajo nivel con las señales tal como salen del gateway, y una rama funcional con indicadores ya elaborados (estado de la línea, contadores por turno, OEE). Los consumidores de negocio se suscriben a la rama funcional y no dependen de los detalles de cada controlador.

MQTT y Sparkplug B: el idioma común

MQTT es un protocolo de publicación-suscripción nacido a finales de los noventa para telemetría sobre enlaces precarios, y estandarizado después por OASIS. Su virtud es la sobriedad: un mensaje es un topic y un payload, la conexión es ligera y tolera redes malas, y mecanismos como el last will permiten saber si un cliente se cayó. Precisamente por esa sobriedad, MQTT no dice nada sobre qué hay dentro del payload, y ahí es donde la industria necesitaba más estructura.

Sparkplug B es una especificación abierta, hoy bajo el paraguas de la Eclipse Foundation, que vive encima de MQTT y define lo que a MQTT le falta para uso industrial:

• Estructura de topics y de payload: un espacio de nombres predecible y un formato binario eficiente con métricas tipadas, en lugar de JSON improvisado distinto en cada planta.
• Gestión de estado: cada nodo edge anuncia su nacimiento (birth certificate) con la lista completa de sus métricas y valores, y el broker publica su defunción si el nodo desaparece. Cualquier consumidor sabe en todo momento si un dato está vivo o es información antigua (stale).
• Publicación por cambio: tras el birth, solo viajan las métricas que cambian. En enlaces lentos o medidos, esa diferencia importa.
• Tipado fuerte: un valor no es un texto libre, es un entero, un flotante o un booleano declarado. Eso elimina toda una familia de errores silenciosos de interpretación.

Sparkplug B no es la única forma de montar un UNS (hay organizaciones que definen su propio esquema de payload sobre MQTT plano), pero es el estándar con más soporte de fabricantes de gateways, brokers y plataformas, y resuelve de serie el problema del estado que en MQTT plano hay que reinventar. El detalle de la especificación, con su estructura de topics, sus birth y death certificates y sus alias de métricas, está en el artículo dedicado a Sparkplug B.

Arquitectura de referencia en tres capas

Una integración OT/IT sobre unified namespace tiene tres capas bien separadas.

Capa 1: traducción de protocolos (edge)

El gateway edge vive cerca de las máquinas, en la red OT. Lee Modbus, PROFINET, OPC UA o señales cableadas, cada protocolo a su ritmo. Valida las lecturas, les añade marca de tiempo de origen y unidad, las almacena en un buffer local persistente por si la red falla, y las publica como Sparkplug B en el namespace. Es la pieza que permite que las máquinas de 1995 participen sin tocarlas. Esta capa coincide con lo que en nuestro catálogo llamamos ingesta edge y conectividad con PLC.

Capa 2: broker MQTT (columna vertebral)

Un broker con soporte de sesiones persistentes y, deseablemente, alta disponibilidad. Puede correr en un servidor de planta, en una nube privada o en un cloud público tras una VPN; lo relevante es que edge y consumidores solo se conectan a él. Si el broker cae, el edge sigue capturando y buffereando; cuando vuelve, drena el atraso. La elección concreta (Mosquitto endurecido, HiveMQ, EMQX u otros) depende del volumen y de los requisitos de operación, no del patrón.

Capa 3: consumidores (IT)

El historiador, el data warehouse, los dashboards, el MES, los modelos de IA y, con un conector adecuado, el ERP: todos se suscriben a las ramas que les interesan. No hay polling ni APIs frágiles entre sistemas; hay suscripciones asíncronas a un espacio de nombres estable. La integración MQTT de cada consumidor con el broker y la integración con el ERP son proyectos acotados porque el contrato es siempre el mismo: el namespace. Si quieres ver cómo encajan estas tres capas dentro de una arquitectura completa de adquisición, almacenamiento y explotación, lo desarrollamos en nuestra plataforma de datos industriales.

El edge como productor: buffering y calidad del dato

El unified namespace es tan bueno como el dato que entra en él, y el dato entra por el edge. Dos propiedades del gateway condicionan todo lo demás. La primera es el store-and-forward: la captura y la publicación deben ser procesos independientes, con un buffer persistente en disco entre ambos, de modo que un corte de WAN de horas no abra huecos en el histórico. La segunda es la normalización en origen: traducir direcciones de registro a nombres de negocio, aplicar escalas y unidades, y marcar la calidad de cada lectura una sola vez, en el gateway, en lugar de repetir esa traducción en cada consumidor.

Dimensionar el buffer, elegir el nivel de QoS de MQTT adecuado para cada señal y evitar los fallos típicos (buffers en RAM, timestamps de llegada en lugar de origen, relojes sin disciplinar) da para una guía propia. La hemos escrito: el pilar sobre edge industrial con buffering y QoS recorre esa cadena completa, del sensor a la nube, con criterios concretos de dimensionado.

Del topic al contrato de datos

Cuando el namespace empieza a tener consumidores de negocio, aparece una pregunta nueva: ¿qué promete exactamente cada topic? Que cnc-07/husillo/temperatura exista no dice con qué frecuencia se actualiza, en qué unidad está, qué pasa cuando la máquina está apagada ni quién responde si el dato deja de llegar. Mientras el único consumidor es un dashboard que mira alguien de planta, la ambigüedad se tolera. Cuando el consumidor es una liquidación de producción o un modelo de mantenimiento predictivo, no.

La respuesta madura es tratar cada rama publicada como un contrato de datos: un acuerdo explícito de esquema, unidades, frecuencia, calidad y propiedad, versionado cuando cambia. El unified namespace pone a todos los sistemas a hablar por el mismo canal; los contratos definen qué se puede esperar de lo que se dice por ese canal. Desarrollamos ese siguiente paso en la guía de contratos de datos industriales, que continúa naturalmente esta.

Tres escenarios donde funciona

Escenario 1: fábrica con decenas de máquinas veteranas

PLC de finales de los noventa, medidores de energía analógicos, sin red industrial digna de ese nombre. Uno o varios gateways edge traducen todo a Sparkplug B y lo publican en el namespace. Las máquinas no se tocan; la planta pasa de no tener datos a ver estado y contadores en tiempo real, y el histórico empieza a acumularse desde el primer día.

Escenario 2: planta con OPC UA pero sin dato fiable a nivel corporativo

OPC UA funciona bien en la red local, pero el enlace cliente-servidor sufre con latencia e intermitencia cuando atraviesa la WAN, y cada aplicación corporativa que quiere datos abre su propia sesión contra el servidor. La solución es un gateway que actúa de cliente OPC UA local, valida, y publica vía Sparkplug B. El servidor OPC UA atiende a un solo cliente estable; el resto del mundo consume del broker.

Escenario 3: sistemas no fabriles que también son planta

Una cámara de visión artificial con API REST, una báscula con salida serie, un sistema de gestión energética con su propio software. El edge consume cada interfaz peculiar, la traduce y publica el resultado como topics del namespace. El resultado de inspección o la pesada del lote quedan disponibles para cualquier sistema sin acoplarse al equipo que los produce, igual que las señales de sensores o de visión artificial.

Implementación: roadmap típico

Fase 1: mapeo y arquitectura

Inventario de dispositivos y protocolos, definición de la jerarquía de nombres, elección de gateway y broker. Es la fase barata donde se evitan los errores caros: un namespace mal nombrado se paga durante años.

Fase 2: desarrollo de la traducción

Configuración de drivers por protocolo, mapeo de señales, validación, buffering y pruebas en laboratorio con el broker de destino.

Fase 3: despliegue gradual

Primero una máquina, después grupos. El namespace convive en paralelo con los sistemas antiguos, que no se apagan hasta que el dato nuevo está validado. No hay paros de producción: el gateway solo escucha.

Fase 4: consumo y operación

Dashboards y primeros consumidores de negocio, alertas de salud del propio namespace (nodos caídos, datos stale), documentación de topics y formación del equipo de IT para operar broker y gateways.

Retorno y justificación

El coste de una integración OT/IT depende del número de máquinas, de la variedad de protocolos y del estado de la red, así que cualquier cifra general sería humo. Lo que sí es general es de dónde sale el retorno:

• Tiempo de detección: los problemas de proceso pasan de descubrirse en el informe del día siguiente a verse en minutos.
• Calidad del dato: una sola versión del dato, normalizada en origen, en lugar de tres extracciones que no cuadran entre sí.
• Coste marginal decreciente: conectar la máquina veinte cuesta una fracción de lo que costó la primera, porque la arquitectura ya existe. En el modelo punto a punto ocurre lo contrario.
• Opcionalidad: dashboards, MES, modelos de IA y ERP consumen el mismo namespace. Cada iniciativa nueva de datos arranca desde una base hecha, no desde cero.

Lo que no es el puente OT/IT

No es reemplazar máquinas. Las máquinas siguen siendo las que son; el gateway las representa en el namespace sin modificarlas.

No es centralización forzada. El dato se comparte, el control no. La máquina sigue siendo autónoma: si el broker, la WAN o todo el edificio de IT desaparecen, la producción continúa.

No es un data lake. El UNS es el sistema circulatorio del dato en tiempo real; el almacenamiento histórico es un consumidor más que se suscribe y persiste. Confundir ambos lleva a diseños que no sirven bien a ninguno de los dos propósitos.

No es complejidad añadida. MQTT y Sparkplug B son especificaciones sobrias que un equipo de mantenimiento y un equipo de IT pueden operar juntos. La complejidad real, la del espagueti de integraciones, es la que se retira.

Preguntas frecuentes sobre unified namespace

Si estás valorando cómo llevar el dato de tus máquinas hasta tus sistemas de negocio sin construir otro espagueti de integraciones, en Captia Connect trabajamos exactamente este patrón: desde la integración OT/IT y la conectividad de planta hasta la integración MQTT con tu plataforma de datos. El primer paso es un mapeo de lo que tienes y de dónde está el primer valor.