O Sparkplug 3.0 é a primeira versão da especificação Sparkplug lançada sob o Sparkplug Working Group da Eclipse Foundation, e em grande parte ela esclarece comportamentos que a 2.2 deixava abertos à interpretação. Nesta comparação você vai ver exatamente o que mudou entre a 2.2 e a 3.0, quais mudanças podem quebrar a interoperabilidade em uma frota mista e como planejar a atualização de edge nodes e aplicações host sem surpresas.
A versão curta
O Sparkplug 3.0 não reinventou o protocolo. O namespace de topics continua sendo spBv1.0, o payload Protobuf continua sendo o schema Sparkplug B e os certificados de birth e death continuam funcionando da mesma forma. O que mudou foi a precisão. A versão 2.2 descrevia o comportamento em texto corrido, que cada fornecedor interpretava de um jeito. A versão 3.0 reescreveu o documento como uma especificação formal com declarações normativas numeradas e o apoiou com um Technology Compatibility Kit (TCK) que testa as implementações contra essas declarações.
A única mudança visível na rede para quase todo mundo é a mensagem STATE da aplicação host. A maioria das outras mudanças afeta casos de borda: reconexões, wills atrasados, tratamento de sessões e codificação de tipos de dados.
Sparkplug 3.0 vs 2.2 em resumo
| Área | Sparkplug 2.2 | Sparkplug 3.0 |
|---|---|---|
| Estilo do documento | Texto descritivo | Declarações normativas, testáveis |
| Conformidade | Sem suíte de testes oficial | TCK com perfis de conformidade |
| Namespace de topics | spBv1.0/... |
Sem alteração |
| Schema do payload | Sparkplug B Protobuf | Sem alteração, regras de codificação esclarecidas |
| Topic STATE | STATE/{host_id} |
spBv1.0/STATE/{host_id} |
| Payload STATE | String ONLINE / OFFLINE |
JSON {"online": true, "timestamp": ...} |
| bdSeq | Descrito de forma vaga | Precisa coincidir entre NBIRTH e NDEATH, com regras de incremento |
| QoS do will NDEATH | Não especificado de forma consistente | QoS 1, não retained |
| Sessão MQTT | Implícita | Edge nodes e hosts usam clean sessions |
| Terminologia | Host SCADA/IIoT, aplicação primária | Host Application, Primary Host Application |
| Tipos de dados array | Listados, codificação pouco clara | Codificação definida |
As mudanças que mais importam
O novo topic e payload STATE
Na 2.2, um host primário publicava uma string retained ONLINE em STATE/{host_id} e registrava OFFLINE como seu will. Esse topic ficava fora do namespace spBv1.0, o que complicava as permissões, e uma string simples não permitia distinguir uma mensagem antiga de uma nova.
Na 3.0, o topic passa a ser spBv1.0/STATE/{host_id} e o payload vira JSON:
{ "online": true, "timestamp": 1792137600000 }
O host o publica como retained com QoS 1 depois de conectar e registra um will com "online": false e o mesmo timestamp usado no birth. Os edge nodes comparam timestamps e ignoram uma mensagem STATE mais antiga do que a que já viram. Isso elimina uma condição de corrida em que um will OFFLINE atrasado de uma sessão anterior do host podia fazer todos os edge nodes se desconectarem, mesmo com o host já de volta. O fluxo completo é tratado no nosso artigo sobre a Primary Host Application do Sparkplug.
Esta é uma mudança incompatível. Um edge node 2.2 que observa STATE/scada1 nunca vai ver um host 3.0, e um node 3.0 aguardando spBv1.0/STATE/scada1 vai esperar para sempre atrás de um host 2.2. Alguns produtos suportam as duas formas durante uma transição; verifique o seu antes de atualizar qualquer coisa.
Regras do bdSeq
A métrica bdSeq liga um NBIRTH ao NDEATH registrado para a mesma sessão MQTT. A versão 3.0 torna as regras explícitas: o will NDEATH precisa conter um bdSeq, o NBIRTH seguinte precisa carregar o mesmo valor e o valor muda a cada nova conexão. Os hosts usam essa correspondência para descartar um certificado de death que pertence a uma sessão mais antiga. Se você escreveu o seu próprio edge node com base na 2.2, este é o primeiro ponto a verificar. Nosso guia sobre certificados de birth e death do Sparkplug mostra uma implementação funcionando.
Comportamento de sessão e QoS
A versão 3.0 exige clean session para edge nodes e aplicações host (clean session true no MQTT 3.1.1, ou clean start com session expiry igual a zero no MQTT 5). Caso contrário, mensagens enfileiradas de uma sessão antiga poderiam chegar depois de um novo birth e confundir o modelo de estado. O will NDEATH usa QoS 1 e não é retained; births e dados também não são retained. Apenas a mensagem STATE do host é retained.
Tipos de dados e aliases mais claros
O datatype precisa estar presente em todas as métricas das mensagens de birth. Os aliases precisam ser únicos por edge node. Tipos array como Int32Array ou BooleanArray têm uma codificação de bytes definida, de modo que fornecedores que afirmam suportar arrays conseguem de fato trocar arrays entre si. A referência de tipos de dados do Sparkplug B lista todos os códigos.
Perfis de conformidade
O TCK define perfis para Edge Node, Host Application, MQTT Server e um opcional Sparkplug Aware MQTT Server. Qualquer broker MQTT 3.1.1 que suporte QoS 0 e 1, retained messages e wills pode transportar tráfego Sparkplug. O perfil "aware" acrescenta recursos opcionais do lado do broker definidos na especificação. Quando um fornecedor disser que é compatível com Sparkplug 3.0, pergunte qual perfil e se ele passou no TCK.
O que o Sparkplug 3.0 significa para o seu broker
Como o payload é opaco para o roteamento, o trabalho do broker quase não muda. Ele precisa de um tratamento confiável de last will, de retained messages para o STATE, de QoS 1 e de capacidade de conexões suficiente para todos os nodes e hosts. Um broker MQTT gerenciado como o ConnectMQ suporta MQTT 3.1.1 e 5.0 nos mesmos endpoints, então nodes 2.2 e 3.0 podem se conectar lado a lado durante a migração. O ConnectMQ também decodifica payloads Sparkplug B e os mostra no topic explorer do portal, o que facilita verificar durante uma migração se os births carregam datatypes, se os valores de bdSeq coincidem e se o novo topic STATE está retained com o JSON esperado.
Antes de mexer na produção, você pode ensaiar no servidor MQTT público, feito para testes e não para dados de produção, com um group ID aleatório. Por exemplo, publique e leia uma mensagem STATE 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
Depois, apague a retained message publicando um payload retained vazio no mesmo topic, já que a área pública é compartilhada.
Checklist de migração da 2.2 para a 3.0
- Faça o inventário de todos os edge nodes e hosts e registre qual versão do Sparkplug cada um suporta.
- Defina a estratégia para o topic STATE: atualizar hosts e nodes juntos ou usar produtos que suportem as duas formas durante a transição.
- Verifique se cada edge node registra um will NDEATH com bdSeq antes de conectar e repete esse bdSeq no NBIRTH.
- Confirme as configurações de clean session nos nodes e hosts.
- Verifique se as mensagens de birth incluem um datatype para cada métrica e se os aliases são únicos por node.
- Teste métricas array e template entre fornecedores, se você as usa.
- Rode o novo host em paralelo contra um group de teste, acompanhando births decodificados e o STATE em um topic explorer.
- Faça a virada um group por vez e mantenha um plano de rollback para o host.
Vale a pena atualizar?
Para projetos novos, comece com a 3.0. Ferramentas construídas sobre as versões atuais do Eclipse Tahu a seguem, e o TCK oferece um meio de cobrar dos fornecedores a aderência à especificação. Para plantas 2.2 existentes que funcionam, como uma linha de envase em Manaus ou uma subestação de uma usina, atualize quando substituir ou adicionar aplicações host, porque a mudança no STATE exige coordenação. Edge nodes que já tratam o bdSeq corretamente muitas vezes só precisam de uma atualização de firmware ou de configuração. Para o contexto de arquitetura mais amplo, leia o guia de IoT Industrial com MQTT. O texto oficial está no site do Eclipse Sparkplug.
Comece com o ConnectMQ
Crie um broker Serverless gratuito em app.connectmq.com, sem cartão de crédito. Conecte os seus edge nodes e o host Sparkplug 3.0 via TLS na porta 8883 e verifique births, deaths e mensagens STATE decodificados no portal do ConnectMQ antes de migrar a produção.
Perguntas frequentes
O Sparkplug 3.0 é retrocompatível com o 2.2?
O payload e o namespace de topics spBv1.0 são compatíveis. O topic e o payload STATE do host mudaram, então nodes 2.2 e hosts 3.0 (ou o contrário) não vão reconhecer o estado do host um do outro sem um modo de compatibilidade.
O Sparkplug 3.0 exige MQTT 5?
Não. O Sparkplug funciona sobre MQTT 3.1.1, e brokers MQTT 5 podem transportá-lo com configurações de sessão equivalentes. Um broker que suporta as duas versões permite migrar de forma gradual.
O topic continua sendo spBv1.0 no Sparkplug 3.0?
Sim. O namespace identifica o formato de payload Sparkplug B, que não mudou, então os topics continuam sendo spBv1.0/.... Apenas o STATE passou para dentro desse namespace.
O que é o TCK do Sparkplug?
O Technology Compatibility Kit é uma suíte de testes do projeto Eclipse Sparkplug que verifica as implementações contra as declarações normativas da especificação 3.0, por perfil, como edge node ou aplicação host.
