Sparkplug B vs JSON es una de las primeras decisiones de diseño en cualquier proyecto MQTT industrial, y la respuesta rara vez es "uno u otro para siempre". En esta comparativa aprenderás en qué se diferencian ambos enfoques en interoperabilidad, conciencia de estado, ancho de banda y herramientas, cuándo encaja cada uno y cómo combinarlos para que las máquinas hablen Sparkplug mientras las personas y los dashboards leen JSON.
Dos filosofías distintas
A MQTT en sí no le importa lo que hay dentro de un mensaje. Esa es a la vez su fortaleza y la razón por la que existe este debate.
JSON puro sobre MQTT significa que diseñas tus propios topics y payloads. Un sensor de temperatura podría publicar {"temp": 21.4, "unit": "C", "ts": 1792137600} en plant1/hall2/sensor7/telemetry. Cualquiera puede leerlo, todos los lenguajes lo analizan y puedes empezar en cinco minutos.
Sparkplug B es una especificación por encima de MQTT. Fija la estructura de topics (spBv1.0/group/type/node/device), codifica los payloads en Protobuf y añade un modelo de estado con certificados de birth y death, números de secuencia y comandos. Renuncias a libertad y ganas interoperabilidad con cualquier SCADA o aplicación host compatible con Sparkplug.
Esta es la misma lectura en JSON:
{
"timestamp": 1792137600123,
"spindleSpeed": 1462.3,
"spindleRunning": true
}
En Sparkplug B, el payload DDATA equivalente es Protobuf binario. Una vez decodificado tiene este aspecto, pero en la red son bytes compactos con alias en lugar de nombres:
{
"timestamp": 1792137600123,
"seq": 17,
"metrics": [
{ "alias": 3, "datatype": 10, "doubleValue": 1462.3 },
{ "alias": 4, "datatype": 11, "booleanValue": true }
]
}
Sparkplug B frente a JSON, lado a lado
| Criterio | JSON puro | Sparkplug B |
|---|---|---|
| Estructura de topics | La que elijas | Namespace spBv1.0 fijo |
| Codificación del payload | Texto legible por personas | Protobuf binario |
| Esquema | Informal, por proyecto | Definido por la especificación |
| Tipos de datos | Número, cadena y booleano JSON | Explícitos: de Int8 a UInt64, Float, Double, DateTime, DataSet, Template y más |
| Estado online/offline del dispositivo | Lo construyes tú (LWT, topics de estado) | Integrado mediante NBIRTH/NDEATH/DBIRTH/DDEATH |
| Detección de mensajes perdidos | La construyes tú | Números de secuencia |
| Descubrimiento de métricas | Documentación o convenciones | Los mensajes de birth enumeran todas las métricas |
| Tamaño del payload | Mayor, los nombres se repiten en cada mensaje | Compacto, alias tras el birth |
| Legibilidad en herramientas genéricas | Excelente | Necesita un decodificador |
| Interoperabilidad con SCADA | Mapeo a medida por sistema | Plug and play con hosts Sparkplug |
| Curva de aprendizaje | Baja | Moderada |
| Comandos a dispositivos | Tu propia convención | NCMD y DCMD |
Dónde gana Sparkplug B
Interoperabilidad
El mayor argumento a favor de Sparkplug es que un gateway de un fabricante y un SCADA de otro pueden trabajar juntos sin un proyecto de mapeo. El host lee los births, descubre cada métrica con su tipo de datos y empieza a mostrar datos. Con JSON, cada nueva fuente de datos requiere que alguien acuerde nombres de campo, unidades y marcas de tiempo.
Conciencia de estado
Sparkplug no solo te dice el último valor, sino si sigue siendo válido. Cuando un gateway se queda sin alimentación, el broker publica su NDEATH y todos los hosts marcan como obsoletos los tags relacionados. Con JSON puedes aproximarte a esto con un last will en un topic de estado, pero también necesitas valores retained, una convención para el estado a nivel de dispositivo y lógica en cada consumidor.
Ancho de banda
Protobuf con alias de métricas es bastante más pequeño que un JSON que repite los nombres de campo en cada mensaje. Combinado con report by exception, donde solo se envían los valores que cambian, Sparkplug se adapta bien a enlaces celulares y satelitales. Para un puñado de sensores en la Ethernet de planta, la diferencia rara vez importa.
Dónde gana JSON
Simplicidad y legibilidad
Puedes depurar JSON con mosquitto_sub y tus propios ojos. Los desarrolladores web, los ingenieros de datos y los equipos de TI ya lo conocen. Herramientas low-code como Node-RED lo manejan de forma nativa.
Flexibilidad
JSON te permite modelar los topics en torno a la jerarquía de tu planta, por ejemplo un árbol ISA-95, que es como muchos equipos estructuran un Unified Namespace. El namespace fijo de Sparkplug se detiene en grupo, nodo y dispositivo.
Consumidores no industriales
Las apps móviles, los dashboards web, las funciones en la nube y los notebooks de analítica suelen querer JSON. Alimentarlos con Sparkplug implica que cada uno necesita el archivo proto y gestionar los alias.
Prueba ambos en un broker de pruebas
Puedes comparar la legibilidad tú mismo en el servidor MQTT público gratuito. Publica JSON:
mosquitto_pub -h broker.connectmq.com -p 1883 -i json-test-a81c \
-t "connectmq/demo/a81c/line1/cnc1/telemetry" \
-m '{"timestamp": 1792137600123, "spindleSpeed": 1462.3, "spindleRunning": true}'
Después ejecuta un simulador Sparkplug, como el de nuestra guía sobre certificados birth y death de Sparkplug, y suscríbete a ambos con salida detallada. El JSON se imprime limpio; los mensajes Sparkplug aparecen como texto parcialmente binario hasta que los decodificas. El área pública es legible por todo el mundo, así que usa IDs aleatorios y nada de datos reales.
El patrón híbrido: Sparkplug en el edge, JSON para los consumidores
Muchas plantas acaban usando ambos. Los edge nodes y el SCADA hablan Sparkplug B para un transporte fiable y consciente del estado, y una capa de traducción publica JSON legible en un árbol de topics ISA-95 para dashboards, analítica y sistemas de TI.
Puedes construir esa capa de traducción tú mismo: un servicio en Python que se suscribe a spBv1.0/#, decodifica el Protobuf, resuelve los alias y republica JSON. Nuestro tutorial sobre cómo decodificar Sparkplug B en Python es un buen punto de partida.
O bien deja que lo haga el broker. ConnectMQ decodifica Sparkplug B y puede republicarlo en topics ISA-95, de modo que spBv1.0/factory1/DDATA/line1/cnc1 aparece como connectmq/factory1/production/line1/cnc1/telemetry. Los dashboards, los flujos de Node-RED y los agentes Telegraf se suscriben a los topics legibles como clientes MQTT corrientes, mientras tus hosts Sparkplug siguen usando el namespace original. El portal también muestra la vista Sparkplug decodificada en su explorador de topics, para que los ingenieros vean nombres de métricas en lugar de bytes.
Checklist para decidir
- ¿Tienes, o piensas comprar, un SCADA o una aplicación host compatible con Sparkplug? Si es así, inclínate por Sparkplug.
- ¿Los operadores necesitan saber cuándo los valores están obsoletos? Sparkplug te lo da sin código a medida.
- ¿Los enlaces son de pago por consumo o de poco ancho de banda? Sparkplug con alias y report by exception ayuda.
- ¿El equipo está formado sobre todo por desarrolladores web y de TI con unos pocos sensores? JSON te permite avanzar más rápido.
- ¿Quieres los topics organizados por niveles ISA-95? JSON encaja de forma natural, o usa el patrón híbrido.
- ¿Muchas aplicaciones no industriales consumirán los datos? Ofrece JSON, de forma nativa o mediante traducción.
- ¿Mezclas fabricantes en el edge? Sparkplug reduce el trabajo de mapeo.
Si has respondido que sí a puntos de ambos lados, el enfoque híbrido suele ser el adecuado.
El broker es el mismo en ambos casos
Ambos payloads funcionan en cualquier broker MQTT que cumpla el estándar, así que esta decisión no te ata a una infraestructura. Lo que cambia es cuánta visibilidad obtienes. Un broker MQTT gestionado que entiende Sparkplug y los topics ISA-95 hace que la parte binaria sea tan accesible como la de JSON. Para la arquitectura general, lee MQTT, Sparkplug B y el Unified Namespace y la guía de IoT industrial con MQTT.
Empieza con ConnectMQ
Crea un broker Serverless gratuito en app.connectmq.com, sin tarjeta de crédito. Publica JSON y Sparkplug B en paralelo y comprueba que ambos se leen sin problemas en el explorador de topics de ConnectMQ, con los datos Sparkplug republicados en topics ISA-95.
Preguntas frecuentes
¿Sparkplug B es siempre mejor que JSON para el IoT industrial?
No. Sparkplug B es mejor para la interoperabilidad con SCADA y por su conciencia de estado integrada. JSON es más sencillo y flexible, y a menudo es la mejor opción para proyectos pequeños o consumidores del lado de TI.
¿Sparkplug puede usar JSON en lugar de Protobuf?
La especificación Sparkplug B define la codificación Protobuf. Algunas herramientas ofrecen una representación JSON para depuración o integración, y ConnectMQ puede decodificar ambas formas.
¿Puedo mezclar Sparkplug B y JSON en el mismo broker?
Sí. Usan topics distintos, así que conviven sin conflictos. Muchas plantas ejecutan Sparkplug bajo spBv1.0 y JSON bajo un árbol ISA-95 en el mismo broker.
¿JSON sobre MQTT admite el estado online de los dispositivos?
No por sí mismo. Puedes implementarlo con un mensaje de last will retained en un topic de estado, pero tienes que definir y hacer cumplir la convención tú mismo.
