Sparkplug B: namespace, birth y death certificates, alias de métricas y cuándo usarlo

Sparkplug B es la especificación abierta, mantenida por la Eclipse Foundation, que define cómo usar MQTT en entornos industriales: fija la estructura de topics, tipa el payload con métricas declaradas y resuelve la gestión de estado mediante birth y death certificates, de modo que cualquier consumidor sabe en todo momento si un dato está vivo o es información antigua. Es la semántica de referencia del Unified Namespace. En este artículo vemos qué define exactamente, cómo funcionan su namespace, sus certificados de nacimiento y muerte y sus alias de métricas, y cuándo conviene usarlo frente a MQTT plano.

Qué es Sparkplug B

MQTT nació deliberadamente agnóstico: un mensaje es un topic y un payload de bytes, y el protocolo no opina sobre qué hay dentro. Esa sobriedad lo hizo universal, pero dejó a cada proyecto industrial inventando su propio esquema: cómo nombrar los topics, cómo codificar los valores, cómo saber si un dispositivo sigue conectado. Sparkplug nació para cerrar esa brecha con una respuesta común, y la revisión B de su payload es la que adoptó la industria.

Hoy la especificación vive en la Eclipse Foundation como proyecto abierto, con versiones publicadas y un programa de compatibilidad para implementaciones. En una frase: Sparkplug B define cómo se llaman las cosas (el namespace de topics), qué forma tienen (payload binario con métricas tipadas, codificado con Protocol Buffers) y cómo se gestiona el estado (birth y death certificates) cuando se usa MQTT para datos industriales.

Qué añade a MQTT plano

Interoperabilidad de serie. Un gateway y una plataforma que hablan Sparkplug B se entienden sin acordar nada más: la estructura de topics y el formato del payload ya están pactados por la especificación.
Tipado fuerte. Cada métrica declara su tipo (entero, flotante, booleano, texto) y puede llevar metadatos y propiedades como la unidad de ingeniería. Se elimina la familia entera de errores de interpretar un texto libre.
Estado conocido. El mecanismo de birth y death certificates hace que el estado de cada nodo y dispositivo sea parte del protocolo, no una convención que cada proyecto reinventa.
Eficiencia en el enlace. Payload binario compacto, publicación solo por cambio y alias numéricos de métricas reducen el tráfico frente a JSON repetitivo sobre MQTT plano.

La comparación de fondo entre el transporte pub/sub y el modelo cliente-servidor de OPC UA la tratamos en OPC UA frente a MQTT; aquí nos centramos en lo que Sparkplug B añade una vez elegido MQTT.

El namespace: estructura de topics

Sparkplug B fija una estructura de topics de cinco partes, siempre igual:

spBv1.0/<group_id>/<message_type>/<edge_node_id>/[device_id]

spBv1.0/valencia-planta/NDATA/gateway-linea-2
spBv1.0/valencia-planta/DDATA/gateway-linea-2/cnc-07

spBv1.0 identifica la versión del namespace de Sparkplug.
group_id agrupa nodos relacionados lógicamente, por ejemplo una planta o un área.
message_type declara qué es el mensaje: NBIRTH y NDEATH (nacimiento y muerte de un nodo edge), DBIRTH y DDEATH (de un dispositivo colgado de ese nodo), NDATA y DDATA (datos por cambio), NCMD y DCMD (comandos hacia el nodo o el dispositivo) y STATE (estado de las aplicaciones anfitrionas).
edge_node_id identifica el nodo edge dentro del grupo, y el device_id opcional identifica cada dispositivo que ese nodo representa, por ejemplo cada máquina leída por un mismo gateway.

Obsérvese que la jerarquía de Sparkplug es de infraestructura (grupo, nodo, dispositivo), no de negocio. La jerarquía semántica tipo ISA-95 (planta, área, línea, máquina) vive dentro de los nombres de las métricas o en la capa que organiza el Unified Namespace: ambas conviven y se complementan.

Birth y death certificates: la gestión de estado

La aportación más distintiva de Sparkplug B es que convierte el estado de la sesión en información de primera clase. La secuencia es así:

Al conectarse, el nodo edge registra en el broker un last will con su mensaje de muerte (NDEATH) y publica su certificado de nacimiento (NBIRTH): la lista completa de sus métricas con nombre, tipo, valor actual y alias. Después publica un DBIRTH por cada dispositivo que representa.
Durante la sesión, solo publica NDATA y DDATA con las métricas que cambian, referenciadas por su alias.
Si el nodo cae sin despedirse, el broker publica por él el NDEATH registrado como last will. Todos los suscriptores saben al instante que ese nodo y sus dispositivos han pasado a estar desconectados, y que sus últimos valores son información antigua (stale), no datos vivos.
Al reconectar, un nuevo NBIRTH restablece el estado completo. Un número de secuencia en cada mensaje permite a los consumidores detectar pérdidas y pedir un rebirth si algo no cuadra.

La consecuencia práctica es enorme: una aplicación que se conecta al broker obtiene la foto completa y actual de la planta sin hacer polling a nadie, y nunca confunde un valor congelado con un valor válido. En MQTT plano, todo ese mecanismo hay que diseñarlo, documentarlo y mantenerlo a mano.

Alias de métricas y publicación por cambio

En el NBIRTH, cada métrica declara junto a su nombre legible un alias numérico. A partir de ahí, los mensajes de datos pueden referirse a la métrica solo por ese alias: en lugar de repetir linea-2/cnc-07/husillo/temperatura en cada publicación, viaja un entero. Combinado con la publicación por cambio (report by exception: tras el birth solo viajan las métricas cuyo valor cambia) y con el payload binario de Protocol Buffers, el resultado es un protocolo muy frugal con el ancho de banda, pensado para enlaces lentos, medidos o inestables.

El precio de esa frugalidad es que el flujo solo se entiende completo: quien quiera interpretar un DDATA necesita haber visto el DBIRTH que declaró los alias. Por eso los consumidores de Sparkplug B se apoyan en la secuencia de estado del apartado anterior, y por eso importa elegir brokers y herramientas que la respeten.

Cuándo usar Sparkplug B y cuándo no

Sparkplug B compensa claramente cuando:

Hay más de un productor y más de un consumidor. La interoperabilidad pactada por especificación evita negociar formato con cada pieza nueva del sistema.
El estado importa. Si distinguir un dato vivo de uno congelado es relevante (y en planta casi siempre lo es), los birth y death certificates resuelven de serie lo más difícil de hacer bien a mano.
El enlace es lento, medido o inestable. Alias, publicación por cambio y payload binario están diseñados exactamente para ese caso.
El proyecto va a crecer. Un Unified Namespace que empieza con dos máquinas y aspira a cubrir la planta agradece un contrato estable desde el primer día.

Y hay casos donde MQTT plano u otra opción puede bastar:

Integraciones puntuales y cerradas, con un solo productor y un solo consumidor bajo el mismo equipo, donde un JSON documentado es suficiente y la dependencia de tooling Sparkplug no aporta.
Consumidores que exigen payload legible. El binario de Sparkplug requiere decodificación; si toda la cadena de consumo espera JSON, hay que añadir esa pieza de traducción y conviene valorarla.
Datos sin naturaleza de telemetría, como ficheros o transacciones complejas, que encajan mejor en otros canales.

Sparkplug B en la práctica con Captia Connect

En Captia Connect trabajamos MQTT como uno de los protocolos centrales de la capa de adquisición: el edge lee PLC, sensores, contadores y SCADA en sus protocolos nativos (OPC UA, Modbus TCP, Modbus RTU sobre RS-485, entre otros), normaliza las señales en origen y las publica de forma segura hacia el broker, con buffering local persistente para que un corte de red no abra huecos en el histórico. Sobre esa base, aplicar la semántica Sparkplug B es la vía natural cuando el proyecto necesita gestión de estado e interoperabilidad con varias plataformas; el diseño concreto forma parte de la integración MQTT de cada planta.

Preguntas frecuentes sobre Sparkplug B

¿Qué diferencia hay entre MQTT y Sparkplug B?

MQTT es el protocolo de transporte: define cómo publicar y suscribirse a topics, pero no qué contienen los mensajes. Sparkplug B es una especificación que vive encima de MQTT y define la estructura de topics, el formato tipado del payload y la gestión de estado con birth y death certificates. Todo mensaje Sparkplug B es MQTT; no todo MQTT es Sparkplug.

¿Qué es un birth certificate en Sparkplug B?

Es el mensaje (NBIRTH para un nodo edge, DBIRTH para un dispositivo) que se publica al establecer la sesión y que declara la lista completa de métricas con su nombre, tipo, valor actual y alias. A partir de él, los consumidores pueden interpretar los mensajes de datos posteriores, que solo llevan los cambios. Su pareja, el death certificate, se registra como last will en el broker y anuncia la desconexión del nodo aunque este caiga sin avisar.

¿Para qué sirven los alias de métricas?

Para ahorrar ancho de banda. El nombre completo de cada métrica viaja una sola vez, en el birth certificate, junto a un alias numérico; los mensajes de datos posteriores referencian la métrica solo por ese número. En enlaces lentos, medidos o con miles de señales, la diferencia de tráfico frente a repetir nombres largos en cada mensaje es sustancial.

¿Sparkplug B es obligatorio para montar un Unified Namespace?

No es obligatorio, pero es la semántica de referencia. Se puede montar un UNS sobre MQTT plano con un esquema de payload propio, a cambio de diseñar y mantener a mano lo que Sparkplug B resuelve de serie: gestión de estado, tipado de métricas y un formato que gateways, brokers y plataformas soportan sin acuerdos adicionales.

Si estás definiendo la capa de datos de tu planta y valoras si Sparkplug B encaja en ella, en Captia Connect diseñamos e implantamos la integración MQTT y la integración OT/IT completa. El contexto de arquitectura general está en nuestra guía de la plataforma de datos industriales.