Sparkplug B vs JSON no MQTT: Qual Payload Você Deve Usar?

Sparkplug B vs JSON é uma das primeiras decisões de projeto em qualquer iniciativa de MQTT industrial, e a resposta raramente é "um ou outro para sempre". Nesta comparação você vai ver como as duas abordagens diferem em interoperabilidade, consciência de estado, banda e ferramentas, quando cada uma se encaixa e como combiná-las para que as máquinas falem Sparkplug enquanto pessoas e dashboards leem JSON.

Duas filosofias diferentes

O MQTT em si não se importa com o que vai dentro de uma mensagem. Essa é ao mesmo tempo a sua força e o motivo pelo qual este debate existe.

JSON puro sobre MQTT significa que você projeta os seus próprios topics e payloads. Um sensor de temperatura pode publicar {"temp": 21.4, "unit": "C", "ts": 1792137600} em plant1/hall2/sensor7/telemetry. Qualquer pessoa consegue ler, toda linguagem faz o parse e você começa em cinco minutos.

Sparkplug B é uma especificação sobre o MQTT. Ela fixa a estrutura de topics (spBv1.0/group/type/node/device), codifica os payloads em Protobuf e acrescenta um modelo de estado com certificados de birth e death, números de sequência e comandos. Você abre mão de liberdade e ganha interoperabilidade com qualquer SCADA ou aplicação host compatível com Sparkplug.

Esta é a mesma leitura em JSON:

{
  "timestamp": 1792137600123,
  "spindleSpeed": 1462.3,
  "spindleRunning": true
}

Em Sparkplug B, o payload DDATA equivalente é Protobuf binário. Depois de decodificado ele fica assim, mas na rede são bytes compactos com aliases no lugar dos nomes:

{
  "timestamp": 1792137600123,
  "seq": 17,
  "metrics": [
    { "alias": 3, "datatype": 10, "doubleValue": 1462.3 },
    { "alias": 4, "datatype": 11, "booleanValue": true }
  ]
}

Sparkplug B vs JSON lado a lado

Onde o Sparkplug B vence

Interoperabilidade

O maior argumento a favor do Sparkplug é que um gateway de um fornecedor e um sistema SCADA de outro podem trabalhar juntos sem um projeto de mapeamento. O host lê os births, descobre cada métrica com o seu tipo de dado e começa a exibir os dados. Com JSON, toda nova fonte de dados exige que alguém combine nomes de campos, unidades e timestamps.

Consciência de estado

O Sparkplug informa não apenas o último valor, mas também se ele ainda é válido. Quando um gateway perde energia, o broker publica o seu NDEATH e todos os hosts marcam as tags relacionadas como desatualizadas. Com JSON você consegue algo parecido com um last will em um topic de status, mas também precisa de valores retained, de uma convenção para status em nível de device e de lógica em cada consumidor.

Banda

Protobuf com aliases de métricas é consideravelmente menor do que JSON que repete os nomes dos campos em cada mensagem. Combinado com report by exception, em que só os valores alterados são enviados, o Sparkplug se adapta bem a links celulares e via satélite. Isso pesa em poços de óleo e gás, mineradoras e fazendas remotas. Para um punhado de sensores na Ethernet da planta, a diferença raramente importa.

Onde o JSON vence

Simplicidade e legibilidade

Você consegue depurar JSON com mosquitto_sub e os próprios olhos. Desenvolvedores web, engenheiros de dados e equipes de TI já o conhecem. Ferramentas low-code como o Node-RED o tratam nativamente.

Flexibilidade

O JSON permite modelar os topics em torno da hierarquia da sua planta, por exemplo uma árvore ISA-95, que é como muitas equipes estruturam um Unified Namespace. O namespace fixo do Sparkplug para em group, node e device.

Consumidores não industriais

Apps móveis, dashboards web, funções na nuvem e notebooks de analytics normalmente querem JSON. Alimentá-los com Sparkplug significa que cada um precisa do arquivo proto e do tratamento de aliases.

Teste os dois em um broker de testes

Você mesmo pode comparar a legibilidade no servidor MQTT público, destinado a testes. Publique 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}'

Depois rode um simulador Sparkplug, como o do nosso guia sobre certificados de birth e death do Sparkplug, e assine os dois com saída detalhada. O JSON aparece limpo; as mensagens Sparkplug aparecem como texto parcialmente binário até você decodificá-las. A área pública pode ser lida por qualquer pessoa, então use IDs aleatórios e nenhum dado real.

O padrão híbrido: Sparkplug na borda, JSON para os consumidores

Muitas plantas acabam usando os dois. Edge nodes e SCADA falam Sparkplug B para ter um transporte confiável e consciente de estado, e uma camada de tradução publica JSON legível em uma árvore de topics ISA-95 para dashboards, analytics, um gêmeo digital e sistemas de TI.

Você pode construir essa camada de tradução por conta própria: um serviço Python que assina spBv1.0/#, decodifica o Protobuf, resolve os aliases e republica em JSON. Nosso tutorial sobre como decodificar Sparkplug B em Python é um ótimo ponto de partida.

Outra opção é deixar o broker fazer isso. O ConnectMQ decodifica Sparkplug B e pode republicá-lo em topics ISA-95, de modo que spBv1.0/factory1/DDATA/line1/cnc1 aparece como connectmq/factory1/production/line1/cnc1/telemetry. Dashboards, fluxos Node-RED e agentes Telegraf assinam os topics legíveis como clientes MQTT comuns, enquanto os seus hosts Sparkplug continuam usando o namespace original. O portal também mostra a visão Sparkplug decodificada no topic explorer, para que os engenheiros vejam nomes de métricas em vez de bytes.

Checklist de decisão

1. Você tem, ou pretende comprar, um SCADA ou uma aplicação host compatível com Sparkplug? Se sim, prefira o Sparkplug.
2. Os operadores precisam saber quando os valores estão desatualizados? O Sparkplug entrega isso sem código personalizado.
3. Os links são tarifados ou de baixa banda? Sparkplug com aliases e report by exception ajuda.
4. A equipe é formada principalmente por desenvolvedores web e de TI, com poucos sensores? O JSON faz você avançar mais rápido.
5. Você quer topics organizados pelos níveis do ISA-95? O JSON se encaixa naturalmente, ou use o padrão híbrido.
6. Muitas aplicações não industriais vão consumir os dados? Ofereça JSON, nativamente ou por tradução.
7. Você mistura fornecedores na borda? O Sparkplug reduz o trabalho de mapeamento.

Se você respondeu sim a itens dos dois lados, a abordagem híbrida costuma ser a certa.

O broker é o mesmo nos dois casos

Os dois payloads rodam em qualquer broker MQTT compatível com o padrão, então essa decisão não prende você a uma infraestrutura. O que muda é o quanto de visibilidade você tem. Um broker MQTT gerenciado que entende Sparkplug e topics ISA-95 torna o lado binário tão acessível quanto o lado JSON. Para a arquitetura mais ampla, leia MQTT, Sparkplug B e o Unified Namespace e o guia de IoT Industrial com MQTT.

Comece com o ConnectMQ

Crie um broker Serverless gratuito em app.connectmq.com, sem cartão de crédito. Publique JSON e Sparkplug B lado a lado e veja os dois de forma legível no topic explorer do ConnectMQ, com os dados Sparkplug republicados em topics ISA-95.

Perguntas frequentes

O Sparkplug B é sempre melhor que JSON para IoT industrial?

Não. O Sparkplug B é melhor para interoperabilidade com SCADA e para consciência de estado embutida. O JSON é mais simples e flexível, e muitas vezes é a melhor escolha para projetos pequenos ou consumidores voltados à TI.

O Sparkplug pode usar JSON em vez de Protobuf?

A especificação Sparkplug B define a codificação Protobuf. Algumas ferramentas oferecem uma representação JSON para depuração ou integração, e o ConnectMQ consegue decodificar as duas formas.

Posso misturar Sparkplug B e JSON no mesmo broker?

Sim. Eles usam topics diferentes, então coexistem sem conflito. Muitas plantas rodam Sparkplug em spBv1.0 e JSON em uma árvore ISA-95 no mesmo broker.

JSON sobre MQTT suporta status online do device?

Não por si só. Você pode implementá-lo com uma mensagem last will retained em um topic de status, mas precisa definir e garantir a convenção por conta própria.