Sparkplug B es una especificación abierta de la Eclipse Foundation que define cómo los dispositivos industriales publican datos sobre MQTT: fija un espacio de nombres de tópicos, una carga útil binaria basada en Protocol Buffers y un ciclo de vida de sesión con certificados de nacimiento y de muerte que hacen explícito el estado de cada nodo.
Qué añade sobre MQTT
MQTT es deliberadamente agnóstico: define cómo se publica y se recibe, pero no qué se publica ni cómo se llama. Dos plantas pueden usar el mismo broker y ser incompatibles, porque una envía JSON en fabrica/linea1/temp y la otra un número suelto en L1/TT001/pv. Sparkplug B cierra ese hueco con tres decisiones.
La primera es el espacio de nombres de tópicos. Todos los mensajes siguen la forma spBv1.0/<group_id>/<tipo>/<edge_node_id>/[<device_id>], donde el tipo es uno de un conjunto cerrado: NBIRTH y NDEATH para el ciclo de vida de un nodo de borde, DBIRTH y DDEATH para el de cada dispositivo colgado de él, NDATA y DDATA para los valores, y NCMD y DCMD para las órdenes en sentido descendente. El conjunto se completa con STATE, que anuncia la disponibilidad de la aplicación anfitriona primaria y viaja en su propio tópico. Un consumidor que no conoce la instalación sabe leer la estructura igualmente, porque la estructura es parte del estándar.
La segunda es la carga útil. En lugar de texto libre, Sparkplug B codifica los datos con Protocol Buffers en un esquema definido: cada métrica lleva nombre, tipo de dato, marca de tiempo propia y, opcionalmente, propiedades. Además del ahorro de bytes frente a JSON, eso significa que el receptor no tiene que adivinar si un valor es entero, real o booleano.
La tercera es el estado, y es la aportación menos obvia y más importante.
Certificados de nacimiento y de muerte
Cuando un nodo de borde se conecta al broker, registra de antemano su mensaje NDEATH como «última voluntad» (el last will and testament de MQTT). A partir de ahí, si el nodo se cae, se queda sin red o se apaga sin despedirse, es el propio broker el que publica su muerte. No hay que esperar a un tiempo de espera en el consumidor ni deducir la ausencia de datos: la desconexión es un evento explícito en el mismo flujo que los valores.
Nada más conectar, el nodo publica su NBIRTH: un mensaje que enumera todas las métricas que va a reportar, con su tipo y su valor inicial, y hace lo propio con un DBIRTH por cada dispositivo que cuelga de él. El resultado es un sistema autodescriptivo: cualquier consumidor que se suscriba sabe, sin configuración previa ni tablas de mapeo, qué señales existen y de qué tipo son. Después del nacimiento, los mensajes de datos pueden referirse a cada métrica por un alias numérico en lugar de por su nombre completo, lo que reduce el tamaño de cada publicación.
A eso se añade un número de secuencia que acompaña a los mensajes de la sesión y permite detectar pérdidas o desorden, y un número de secuencia de nacimiento que enlaza cada NDEATH con el NBIRTH al que corresponde, de forma que una reconexión rápida no se confunde con la sesión anterior. Sparkplug B también asume publicación por excepción: se envía cuando el valor cambia, no cada ciclo, y el estado actual se reconstruye a partir del nacimiento más el flujo posterior, no de mensajes retenidos en el broker.
Su papel en el unified namespace
Un Unified Namespace aspira a que el estado actual de toda la operación esté disponible en un único lugar y que cualquier sistema nuevo pueda enterarse sin integraciones a medida. MQTT a secas da el transporte, pero deja dos preguntas sin responder: cómo sabe un consumidor recién llegado qué existe, y cómo distingue «la máquina está parada» de «la máquina lleva un rato sin decir nada». Sparkplug B responde a ambas con el mismo mecanismo: el certificado de nacimiento describe el inventario y el de muerte declara la ausencia. Por eso, en arquitecturas de unified namespace, Sparkplug suele ocupar la franja que va del equipo al broker, mientras que las capas superiores pueden seguir consumiendo en formatos más libres.
Sparkplug B frente a MQTT «plano»
La diferencia práctica no es de protocolo sino de contrato. Con MQTT plano se elige la jerarquía de tópicos que convenga, normalmente inspirada en ISA-95 (empresa, planta, área, línea, celda), y se publica JSON legible que cualquiera puede inspeccionar con un cliente básico. Es flexible y fácil de depurar, pero cada instalación inventa su propio diccionario y el estado hay que resolverlo a mano con mensajes retenidos y señales de vida. Con Sparkplug B se gana descubrimiento automático, tipado y estado, y se paga con una estructura de tópicos fija de cuatro o cinco niveles, en la que la jerarquía de planta hay que codificarla dentro del identificador de grupo, y con una carga binaria que no se lee sin decodificador.
Ninguna de las dos opciones es universalmente mejor: la elección depende de cuántos consumidores independientes vayan a existir y de cuánta disciplina de modelado se pueda sostener. Lo que no funciona es mezclarlas sin criterio en el mismo espacio de nombres.
Qué implica consumir datos en Sparkplug B
Suscribirse a un tópico Sparkplug y esperar leer un número no funciona: hace falta un cliente que decodifique Protocol Buffers y, sobre todo, que mantenga estado. El valor de una métrica solo se interpreta con el certificado de nacimiento de su nodo, que es donde viven el nombre, el tipo y la correspondencia entre alias y señal. Un consumidor que se conecta a mitad de partida no tiene ese contexto, y por eso la especificación prevé que pueda pedir al nodo que vuelva a publicar su nacimiento mediante un comando de control. Cualquier historian o servicio de analítica que se enganche a un flujo Sparkplug tiene que implementar esa negociación; no es opcional.
La publicación por excepción tiene una consecuencia parecida: entre cambios no hay tráfico, así que el silencio es información válida y no un fallo. La cadena de tiempos también mejora respecto al sondeo clásico, porque cada métrica viaja con la marca de tiempo que le puso el nodo de borde, no la de recepción; a cambio, exige que los relojes de los nodos estén sincronizados, normalmente por NTP, si se van a correlacionar eventos entre equipos. En el sentido descendente, los mensajes de comando permiten escribir hacia la planta, lo que convierte la autorización por tópico y la separación entre publicadores de datos y emisores de órdenes en una decisión de diseño de seguridad, no de comodidad.
Del lado del equipo, quien habla Sparkplug rara vez es el PLC. Lo habitual es que un gateway industrial lea el autómata por OPC-UA o Modbus y actúe como nodo de borde: él construye el inventario de métricas, sella los tiempos, mantiene la sesión y almacena localmente mientras el enlace está caído. La lógica de control no se toca en ningún momento.
Relación con otros términos
Sparkplug B es una capa de convención sobre MQTT y una pieza habitual del Unified Namespace en proyectos de convergencia OT/IT. El desarrollo completo de esa arquitectura está en la guía OT/IT y Unified Namespace, y el despliegue de brokers y jerarquías de tópicos es el objeto de la integración MQTT.