Sparkplug B explicado: MQTT para IoT industrial

O MQTT puro é propositalmente neutro: qualquer tópico, qualquer payload. Essa flexibilidade é um problema nas fábricas, onde um sistema SCADA de um fornecedor precisa entender os dados de gateways de CLP fabricados por outro. O Sparkplug B preenche essa lacuna. É uma especificação aberta, mantida pelo Sparkplug Working Group da Eclipse Foundation, que define como usar o MQTT na IoT industrial: uma estrutura de tópicos fixa, um formato de payload binário e regras para saber se cada dispositivo está online. A versão 3.0 da especificação também foi publicada como a norma internacional ISO/IEC 20237.

Se você é novo no protocolo de base, comece por o que é MQTT.

Os componentes de um sistema Sparkplug

• Servidor MQTT — qualquer broker compatível com MQTT 3.1.1 ou 5.
• Edge Node — um gateway ou dispositivo que se conecta ao MQTT, por exemplo um gateway de CLP. Ele publica seus próprios dados e os dos dispositivos que estão por trás dele.
• Device — um sensor, CLP ou máquina ligado a um Edge Node. Os devices não se conectam ao MQTT diretamente; o Edge Node fala por eles.
• Host Application — um consumidor como SCADA, MES ou historian que assina os dados e envia comandos. Um deles pode ser designado como Primary Host Application.

O namespace de tópicos do Sparkplug

Todo tópico Sparkplug B segue a mesma estrutura:

spBv1.0/<group_id>/<message_type>/<edge_node_id>[/<device_id>]

# Examples
spBv1.0/Plant1/NBIRTH/Gateway-07
spBv1.0/Plant1/DDATA/Gateway-07/Press-3
spBv1.0/Plant1/DCMD/Gateway-07/Press-3

• spBv1.0 — o namespace e a versão da definição de payload.
• group_id — um agrupamento lógico de Edge Nodes, como uma planta ou linha de produção.
• message_type — um dos tipos de mensagem abaixo.
• edge_node_id e o device_id opcional — identificam quem publica.

Como a estrutura é fixa, os consumidores podem assinar com curingas como spBv1.0/Plant1/+/# ou spBv1.0/+/DDATA/#. Cole-os no testador de tópicos para ver o que eles abrangem, ou leia tópicos e curingas MQTT para conhecer as regras.

Tipos de mensagem

O Sparkplug se baseia em report by exception (envio por exceção): depois que a mensagem BIRTH estabelece todas as métricas, as mensagens DATA carregam apenas os valores que mudaram. Um consumidor que entra tarde, ou que perde o fio, pode pedir um novo BIRTH enviando um NCMD que define a métrica Node Control/Rebirth como true.

Estado da sessão: NDEATH, bdSeq e seq

O grande diferencial do Sparkplug é que um host sempre sabe se os dados estão atualizados. Isso se apoia no Last Will and Testament do MQTT:

1. Quando o Edge Node se conecta, ele registra uma mensagem NDEATH como seu will. O will carrega uma métrica bdSeq (sequência birth/death).
2. Logo após conectar, ele publica o NBIRTH com o mesmo bdSeq, seguido de um DBIRTH para cada device.
3. Se o node cair, o broker publica o will NDEATH. O host compara o bdSeq dele com o do último NBIRTH e marca todas as métricas desse node e de seus devices como desatualizadas (stale).

O bdSeq é incrementado a cada nova sessão MQTT (voltando a zero após 255), para que um NDEATH atrasado de uma conexão antiga não seja confundido com a queda da conexão atual.

Além disso, toda mensagem que um Edge Node publica carrega um número seq de 0 a 255. O NBIRTH começa em 0 e cada mensagem seguinte o incrementa, voltando a 0 depois de 255. Se um host vê uma lacuna, sabe que uma mensagem se perdeu e pode solicitar um rebirth.

A Primary Host Application e o STATE

Dados só são úteis se alguém os estiver registrando. Uma Primary Host Application publica uma mensagem STATE retida (e registra um STATE offline como seu will). Edge Nodes configurados com um primary host esperam que ele esteja online antes de publicar seus births e, se ele ficar offline, se desconectam e podem armazenar dados localmente ou fazer failover para outro servidor MQTT até que ele volte. No Sparkplug 3.0, o tópico é spBv1.0/STATE/<host_id>, com um pequeno payload JSON:

{ "online": true, "timestamp": 1760140800000 }

Implantações mais antigas da versão 2.x usavam o tópico STATE/<host_id> com uma string simples ONLINE/OFFLINE.

Payloads em Protobuf

Os payloads do Sparkplug B são codificados com Google Protocol Buffers. Um payload tem um timestamp, um seq e uma lista de métricas. Cada métrica tem um nome, um tipo de dado, um valor, um timestamp opcional e um alias numérico opcional. Os aliases são declarados no BIRTH; as mensagens DATA podem então enviar o alias em vez do nome completo, o que mantém as mensagens compactas.

timestamp: 1760140800123
seq: 17
metrics {
  alias: 4            # "Press-3/Hydraulic/Pressure" in DBIRTH
  timestamp: 1760140800120
  datatype: Float
  float_value: 182.4
}

A codificação binária deixa os payloads pequenos, o que importa em links limitados; você pode estimar o tamanho dos pacotes com a calculadora de tamanho de pacote MQTT. A desvantagem é que um cliente genérico mostra bytes brutos. Mesmo assim, você pode usar um para confirmar que births e deaths chegam nos tópicos certos:

Acompanhar um namespace Sparkplug no cliente online

Configurações MQTT usadas pelo Sparkplug

• QoS 0 para mensagens NBIRTH/DBIRTH, DATA e CMD; QoS 1 para o will NDEATH e para o STATE.
• Retain false para tudo, exceto o STATE, que é retido.
• Clean sessions para os Edge Nodes (Clean Session true no 3.1.1, ou Clean Start true com session expiry 0 no MQTT 5). O Sparkplug gerencia o estado por conta própria por meio de births e rebirths, então não depende de sessões persistentes.

Primeiros passos com o Eclipse Tahu

O Eclipse Tahu é a implementação de referência do Sparkplug, com a definição Protobuf e bibliotecas cliente para Java, C, Python e JavaScript. Ele cuida da codificação, dos aliases e dos números de sequência para que você possa se concentrar nas suas métricas. O Sparkplug Working Group também publica um Technology Compatibility Kit (TCK) para testar se as implementações seguem a especificação.

Considerações de segurança

Como os comandos Sparkplug podem escrever setpoints em máquinas reais, trate o acesso aos tópicos NCMD e DCMD como crítico para a segurança. Use TLS, credenciais únicas por Edge Node e ACLs que permitam a cada node publicar apenas sob o seu próprio edge_node_id. Nossas boas práticas de segurança MQTT trazem os detalhes.

Perguntas frequentes