Sparkplug 3.0 es la primera versión de la especificación Sparkplug publicada bajo el Sparkplug Working Group de la Eclipse Foundation, y sobre todo aclara comportamientos que la 2.2 dejaba abiertos a interpretación. En esta comparativa aprenderás exactamente qué cambió entre la 2.2 y la 3.0, qué cambios pueden romper la interoperabilidad en un parque mixto y cómo planificar la migración de edge nodes y aplicaciones host sin sorpresas.
La versión corta
Sparkplug 3.0 no reinventó el protocolo. El namespace de topics sigue siendo spBv1.0, el payload Protobuf sigue siendo el esquema Sparkplug B y los certificados de birth y death funcionan igual. Lo que cambió es la precisión. La versión 2.2 describía el comportamiento en prosa que cada fabricante leía de forma distinta. La versión 3.0 reescribió el documento como una especificación formal con declaraciones normativas numeradas, y la respaldó con un Technology Compatibility Kit (TCK) que prueba las implementaciones frente a esas declaraciones.
El único cambio visible en la red para casi todo el mundo es el mensaje STATE de la aplicación host. La mayoría de los demás cambios afectan a casos límite: reconexiones, wills tardíos, gestión de sesiones y codificación de tipos de datos.
Sparkplug 3.0 frente a 2.2 de un vistazo
| Área | Sparkplug 2.2 | Sparkplug 3.0 |
|---|---|---|
| Estilo del documento | Prosa descriptiva | Declaraciones normativas, comprobables |
| Conformidad | Sin batería de pruebas oficial | TCK con perfiles de conformidad |
| Namespace de topics | spBv1.0/... |
Sin cambios |
| Esquema del payload | Protobuf de Sparkplug B | Sin cambios, reglas de codificación aclaradas |
| Topic STATE | STATE/{host_id} |
spBv1.0/STATE/{host_id} |
| Payload STATE | Cadena ONLINE / OFFLINE |
JSON {"online": true, "timestamp": ...} |
| bdSeq | Descrito de forma vaga | Debe coincidir entre NBIRTH y NDEATH, con reglas de incremento |
| QoS del will NDEATH | No especificado de forma coherente | QoS 1, no retained |
| Sesión MQTT | Implícita | Edge nodes y hosts usan clean sessions |
| Terminología | Host SCADA/IIoT, aplicación primaria | Host Application, Primary Host Application |
| Tipos de datos array | Enumerados, codificación poco clara | Codificación definida |
Los cambios más importantes
El nuevo topic y payload STATE
En la 2.2, un host primario publicaba una cadena retained ONLINE en STATE/{host_id} y registraba OFFLINE como su will. Ese topic quedaba fuera del namespace spBv1.0, lo que complicaba los permisos, y una cadena simple no permitía distinguir un mensaje antiguo de uno nuevo.
En la 3.0 el topic pasa a ser spBv1.0/STATE/{host_id} y el payload se convierte en JSON:
{ "online": true, "timestamp": 1792137600000 }
El host lo publica como retained con QoS 1 tras conectarse y registra un will con "online": false y la misma marca de tiempo que usó en el birth. Los edge nodes comparan las marcas de tiempo e ignoran un mensaje STATE más antiguo que el que ya vieron. Esto elimina una condición de carrera en la que un will OFFLINE retrasado de una sesión anterior del host podía hacer que todos los edge nodes se desconectaran aunque el host ya hubiera vuelto. El flujo completo se explica en nuestro artículo sobre la aplicación host primaria de Sparkplug.
Es un cambio incompatible. Un edge node 2.2 que vigila STATE/scada1 nunca verá un host 3.0, y un nodo 3.0 que espera spBv1.0/STATE/scada1 esperará indefinidamente detrás de un host 2.2. Algunos productos admiten ambas formas durante una transición; comprueba los tuyos antes de actualizar nada.
Reglas de bdSeq
La métrica bdSeq vincula un NBIRTH con el NDEATH registrado para la misma sesión MQTT. La versión 3.0 hace explícitas las reglas: el will NDEATH debe contener un bdSeq, el NBIRTH siguiente debe llevar el mismo valor y el valor cambia en cada nueva conexión. Los hosts usan esa coincidencia para descartar un certificado de death que pertenece a una sesión anterior. Si escribiste tu propio edge node siguiendo la 2.2, es lo primero que debes verificar. Nuestra guía sobre certificados birth y death de Sparkplug muestra una implementación funcional.
Comportamiento de sesión y QoS
La versión 3.0 exige una clean session para edge nodes y aplicaciones host (clean session a true en MQTT 3.1.1, o clean start con una expiración de sesión de cero en MQTT 5). De lo contrario, mensajes en cola de una sesión antigua podrían llegar después de un birth nuevo y confundir el modelo de estado. El will NDEATH usa QoS 1 y no es retained; los births y los datos tampoco lo son. Solo el mensaje STATE del host es retained.
Tipos de datos y alias más claros
El tipo de datos debe estar presente en cada métrica de los mensajes de birth. Los alias deben ser únicos por edge node. Los tipos array, como Int32Array o BooleanArray, tienen una codificación de bytes definida, de modo que los fabricantes que afirman admitir arrays pueden intercambiarlos de verdad. La referencia de tipos de datos de Sparkplug B enumera todos los códigos.
Perfiles de conformidad
El TCK define perfiles para Edge Node, Host Application, MQTT Server y un Sparkplug Aware MQTT Server opcional. Cualquier broker MQTT 3.1.1 que admita QoS 0 y 1, retained messages y wills puede transportar tráfico Sparkplug. El perfil "aware" añade funciones opcionales del lado del broker definidas en la especificación. Cuando un fabricante diga que es compatible con Sparkplug 3.0, pregunta qué perfil y si ha superado el TCK.
Qué significa Sparkplug 3.0 para tu broker
Como el payload es opaco para el enrutamiento, el trabajo del broker apenas cambia. Necesita una gestión fiable del last will, retained messages para STATE, QoS 1 y capacidad de conexión suficiente para todos los nodos y hosts. Un broker MQTT gestionado como ConnectMQ admite MQTT 3.1.1 y 5.0 en los mismos endpoints, de modo que nodos 2.2 y 3.0 pueden conectarse en paralelo mientras migras. ConnectMQ también decodifica payloads Sparkplug B y los muestra en el explorador de topics del portal, lo que facilita comprobar durante una migración que los births llevan tipos de datos, que los valores de bdSeq coinciden y que el nuevo topic STATE es retained con el JSON esperado.
Antes de tocar producción, puedes ensayar en el servidor MQTT público gratuito con un group ID aleatorio. Por ejemplo, publica y lee un mensaje STATE de la 3.0:
mosquitto_pub -h broker.connectmq.com -p 1883 -i host-test-4e1b -r -q 1 \
-t "spBv1.0/STATE/demo-host-4e1b" -m '{"online": true, "timestamp": 1792137600000}'
mosquitto_sub -h broker.connectmq.com -p 1883 -i host-watch-4e1b -t "spBv1.0/STATE/demo-host-4e1b" -v
Después, borra el retained message publicando un payload vacío como retained en el mismo topic, ya que el área pública es compartida.
Checklist de migración de la 2.2 a la 3.0
- Inventaría todos los edge nodes y hosts y anota qué versión de Sparkplug admite cada uno.
- Decide la estrategia para el topic STATE: actualizar hosts y nodos a la vez o usar productos que admitan ambas formas durante la transición.
- Verifica que cada edge node registra un will NDEATH con bdSeq antes de conectarse y repite ese bdSeq en el NBIRTH.
- Confirma la configuración de clean session en nodos y hosts.
- Comprueba que los mensajes de birth incluyen un tipo de datos para cada métrica y que los alias son únicos por nodo.
- Prueba las métricas array y template entre fabricantes si las utilizas.
- Ejecuta el nuevo host en paralelo contra un grupo de prueba, observando los births decodificados y STATE en un explorador de topics.
- Migra grupo a grupo y mantén un plan de vuelta atrás para el host.
¿Deberías actualizar?
Para proyectos nuevos, empieza con la 3.0. Las herramientas basadas en las versiones actuales de Eclipse Tahu la siguen, y el TCK te da una forma de exigir a los fabricantes que cumplan la especificación. Para plantas existentes con la 2.2 que funcionan, actualiza cuando sustituyas o añadas aplicaciones host, porque el cambio de STATE obliga a coordinarse. Los edge nodes que ya gestionan bien el bdSeq a menudo solo necesitan una actualización de firmware o de configuración. Para el contexto de arquitectura más amplio, lee la guía de IoT industrial con MQTT. El texto oficial está en el sitio de Eclipse Sparkplug.
Empieza con ConnectMQ
Crea un broker Serverless gratuito en app.connectmq.com, sin tarjeta de crédito. Conecta tus edge nodes y tu host Sparkplug 3.0 mediante TLS en el puerto 8883 y verifica births, deaths y mensajes STATE decodificados en el portal de ConnectMQ antes de migrar producción.
Preguntas frecuentes
¿Sparkplug 3.0 es retrocompatible con la 2.2?
El payload y el namespace de topics spBv1.0 son compatibles. El topic y el payload STATE del host cambiaron, así que los nodos 2.2 y los hosts 3.0 (o al revés) no reconocerán el estado del host del otro sin un modo de compatibilidad.
¿Sparkplug 3.0 requiere MQTT 5?
No. Sparkplug funciona sobre MQTT 3.1.1, y los brokers MQTT 5 pueden transportarlo con una configuración de sesión equivalente. Un broker que admite ambas versiones te permite migrar de forma gradual.
¿El topic sigue siendo spBv1.0 en Sparkplug 3.0?
Sí. El namespace identifica el formato de payload Sparkplug B, que no cambió, así que los topics siguen siendo spBv1.0/.... Solo STATE se trasladó a ese namespace.
¿Qué es el TCK de Sparkplug?
El Technology Compatibility Kit es una batería de pruebas del proyecto Eclipse Sparkplug que comprueba las implementaciones frente a las declaraciones normativas de la especificación 3.0, por perfil, como edge node o aplicación host.
