Sparkplug B e Unified Namespace são as duas ideias que aparecem em quase todo projeto de IoT industrial construído sobre MQTT. Neste artigo você vai aprender o que é um Unified Namespace, como a hierarquia ISA-95 vira uma estrutura de topics, como funcionam o namespace de topics e o payload do Sparkplug B e como as duas abordagens se complementam. Ao longo do caminho, você vai publicar mensagens ISA-95 e Sparkplug B reais no broker.connectmq.com, o servidor MQTT público gratuito do ConnectMQ para testes.
Se os fundamentos do MQTT são novidade para você, leia primeiro o que é um broker MQTT.
O Problema: o Espaguete Ponto a Ponto
Uma planta típica, seja uma montadora em Joinville ou um frigorífico no interior, tem CLPs, SCADA, um MES, um historiador, um sistema de qualidade e um ERP. Tradicionalmente, cada sistema conversa com os outros por meio da sua própria conexão ponto a ponto. Adicione um novo dashboard e você precisa de três novas integrações. Mude uma tag de CLP e algo quebra mais adiante.
O MQTT resolve a parte do transporte: todo produtor publica em um broker, todo consumidor assina. O que o MQTT não decide por você é como nomear os topics e como formatar os payloads. É exatamente essa lacuna que o Unified Namespace e o Sparkplug B preenchem.
O Que É um Unified Namespace?
Um Unified Namespace (UNS) é uma visão única, orientada a eventos e hierárquica do estado atual de todo o negócio. Em vez de pedir dados a cada sistema, cada sistema publica o que sabe em uma única árvore de topics compartilhada no broker, e cada consumidor assina a parte de que precisa.
Três propriedades definem um bom UNS:
- Fonte única da verdade. O valor mais recente de cada máquina, linha e ordem fica em um só lugar.
- Estruturado pelo negócio. Os topics seguem a hierarquia física e organizacional, então as pessoas encontram os dados sem precisar de uma lista de tags.
- Report by exception. Os produtores publicam quando algo muda, e as retained messages entregam o estado atual imediatamente aos novos subscribers.
ISA-95 como Estrutura de Topics
A forma mais comum de estruturar um UNS é a hierarquia de equipamentos da ISA-95. Cada nível vira um nível de topic:
Enterprise / Site / Area / Line / WorkCell / <data class>
acme / izmir / machining / line1 / cnc1 / telemetry
Tabela de Design de Topics
| Nível ISA-95 | Valor de exemplo | Nível do topic | Dica de design |
|---|---|---|---|
| Enterprise | acme | 1 | Identificador fixo e curto da empresa |
| Site | izmir | 2 | Um por planta ou localidade |
| Area | machining | 3 | Departamento ou área de produção |
| Line | line1 | 4 | Linha de produção ou célula de processo |
| WorkCell | cnc1 | 5 | Máquina, robô ou estação |
| Classe de dados | telemetry, state, alarms, cmd | 6 | Separa dados rápidos de eventos e comandos |
Algumas regras práticas:
- Use ASCII minúsculo, sem espaços, e IDs estáveis em vez de nomes de exibição.
- Mantenha a profundidade previsível. Os consumidores dependem de wildcards como
acme/izmir/+/+/+/alarmspara obter todos os alarmes de um site. - Mantenha os comandos em um ramo próprio (
cmd), para que possam ser protegidos e auditados separadamente da telemetria. - Publique as mensagens de estado como retidas, para que um novo dashboard veja o valor atual na hora.
Teste: Publique uma Mensagem JSON ISA-95
A área pública do broker.connectmq.com permite até 8 níveis de topic, então use um prefixo aleatório curto em vez de um longo. Assine em um terminal:
mosquitto_sub -h broker.connectmq.com -p 1883 -i uns-a1b2-sub \
-t "a1b2/acme/#" -v
Publique uma leitura de máquina a partir de outro terminal:
mosquitto_pub -h broker.connectmq.com -p 1883 -i uns-a1b2-cnc1 -q 1 \
-t "a1b2/acme/izmir/machining/line1/cnc1/telemetry" \
-m '{"spindleSpeed":12000,"temperature":41.7,"status":"RUNNING"}'
O subscriber imprime o topic e o payload JSON. Tudo na área pública pode ser lido por qualquer pessoa, então nunca publique dados reais de produção ali.
O Que É Sparkplug B?
O Sparkplug B é uma especificação aberta, mantida sob a Eclipse Foundation, que define três coisas que o MQTT deixa em aberto: um namespace de topics fixo, um formato de payload binário e um modelo de gerenciamento de estado. Ele foi projetado para que SCADA e aplicações host descubram dispositivos automaticamente e sempre saibam se os dados estão atualizados ou desatualizados.
O Namespace de Topics do Sparkplug B
Todo topic Sparkplug B segue este padrão:
spBv1.0/{group_id}/{message_type}/{edge_node_id}/{device_id}
group_id agrupa edge nodes (por exemplo, uma planta), edge_node_id é o gateway ou dispositivo de borda, e o device_id opcional é um CLP ou sensor atrás desse edge node.
| Tipo de mensagem | Enviada por | Finalidade |
|---|---|---|
| NBIRTH | Edge node | O node fica online e declara todas as suas métricas |
| NDEATH | Broker (como Will) | O node ficou offline inesperadamente |
| DBIRTH | Edge node | Um dispositivo atrás do node fica online com suas métricas |
| DDEATH | Edge node | Um dispositivo ficou offline |
| NDATA / DDATA | Edge node | Valores de métricas alterados do node ou do dispositivo |
| NCMD / DCMD | Aplicação host | Comandos de escrita para um node ou dispositivo |
| STATE | Aplicação host | Anuncia se o host primário está online |
A mensagem NDEATH é registrada como o Last Will do MQTT quando o edge node se conecta, então o broker a publica automaticamente se a conexão cair. Os consumidores, então, marcam todos os dados daquele node como desatualizados.
Payload: Protobuf, Aliases e Números de Sequência
Os payloads Sparkplug B são codificados com Google Protocol Buffers. Um payload contém um timestamp, um número de sequência e uma lista de métricas; cada métrica tem um nome, um alias numérico opcional, um tipo de dado, um timestamp e um valor.
Mecânicas principais:
- Certificados de nascimento. NBIRTH e DBIRTH contêm todas as métricas com nome completo e tipo de dado. Mensagens DDATA posteriores podem enviar só o alias numérico e o novo valor, o que mantém os pacotes pequenos.
- Números de sequência. Toda mensagem de um edge node carrega um valor
seqde 0 a 255 que reinicia ao chegar ao fim. Se um host percebe uma lacuna, ele sabe que uma mensagem se perdeu e pode enviar um comando de rebirth (NCMD) para pedir novos certificados de nascimento. - bdSeq. Um número de sequência de nascimento/morte vincula cada NDEATH ao NBIRTH da mesma sessão, para que um certificado de morte antigo não apague uma sessão mais nova.
Aqui está a mesma leitura de antes, mostrada como a representação JSON de um payload DDATA do Sparkplug B:
{
"timestamp": 1760600000000,
"seq": 1,
"metrics": [
{ "name": "temperature", "timestamp": 1760600000000, "dataType": "Double", "value": 41.7 }
]
}
Sparkplug B vs Unified Namespace: Complementares, Não Concorrentes
| Aspecto | Sparkplug B | Unified Namespace ISA-95 |
|---|---|---|
| Estrutura de topics | Fixa: spBv1.0/group/type/node/device |
Livre, modelada na hierarquia do negócio |
| Payload | Protobuf com métricas tipadas | Geralmente JSON, definido por você |
| Consciência de estado | Nativa (birth, death, STATE) | Por convenção, normalmente com retained messages |
| Legibilidade | Precisa de um decodificador | Topics e payloads legíveis por humanos |
| Ideal para | Borda até o SCADA, descoberta de dispositivos, estado confiável | Acesso em toda a empresa, analytics, consumidores de TI |
Na prática, muitas plantas usam os dois. Os edge nodes falam Sparkplug B porque ele oferece estado confiável e payloads eficientes perto das máquinas. Os dados são então republicados em um namespace estruturado pela ISA-95, em JSON legível, onde MES, dashboards, um gêmeo digital e aplicações de TI os consomem sem nunca tocar em Protobuf. A parte difícil é essa camada de tradução, e é aí que o broker pode ajudar.
Como o ConnectMQ Trata Sparkplug B e Topics ISA-95
O ConnectMQ é um broker MQTT gerenciado com suporte nativo a IoT industrial:
- Detecção de ISA-95. Ele reconhece estruturas de topics ISA-95 e de Unified Namespace no seu tráfego.
- Decodificação de Sparkplug B. Ele detecta mensagens Sparkplug B e decodifica payloads tanto em Protobuf quanto em JSON.
- Republicação em ISA-95. Dados Sparkplug B podem ser republicados em uma estrutura ISA-95; por exemplo,
spBv1.0/factory1/DDATA/line1/cnc1viraconnectmq/factory1/production/line1/cnc1/telemetry, com um payload JSON plano que qualquer subscriber consegue ler. - Visões no portal. A visão Devices do portal organiza seus equipamentos por níveis ISA-95, e regras de alerta por limite com histórico de alertas permitem reagir quando, digamos, a temperatura de um spindle ultrapassa um limite.
Teste: Sparkplug B Entra, Telemetria Legível Sai
Use um group ID único, como a1b2plant. Primeiro, assine tanto o topic Sparkplug quanto o ramo republicado:
mosquitto_sub -h broker.connectmq.com -p 1883 -i spb-a1b2-sub -v \
-t "spBv1.0/a1b2plant/#" -t "connectmq/a1b2plant/#"
Depois, publique uma mensagem DDATA com um payload Sparkplug B em JSON:
mosquitto_pub -h broker.connectmq.com -p 1883 -i spb-a1b2-edge -q 1 \
-t "spBv1.0/a1b2plant/DDATA/line1/cnc1" \
-m '{"timestamp":1760600000000,"seq":1,"metrics":[{"name":"temperature","timestamp":1760600000000,"dataType":"Double","value":41.7}]}'
Quando testamos isso no broker.connectmq.com, o subscriber recebeu a mensagem Sparkplug B original e uma segunda mensagem em connectmq/a1b2plant/.../line1/cnc1/telemetry com o payload {"temperature":41.7,"timestamp":1760600000000}. As ferramentas downstream agora podem assinar connectmq/a1b2plant/+/+/+/telemetry e receber JSON limpo por máquina.
Para produção, crie um broker dedicado no portal e conecte com YOUR_USERNAME, YOUR_PASSWORD e YOUR_CLIENT_ID via TLS na porta 8883. Os topics de cada tenant ficam isolados de outros tenants e da área pública. Veja boas práticas de segurança MQTT para orientações sobre credenciais e TLS.
Checklist de Design para o Seu Primeiro UNS
- Defina os níveis ISA-95 e as regras de nomenclatura antes de o primeiro dispositivo se conectar.
- Decida de quais classes de dados você precisa (
telemetry,state,alarms,cmd) e mantenha-as consistentes. - Use Sparkplug B na borda, onde você precisa de consciência de birth/death, e um ramo ISA-95 legível para todos os demais.
- Use QoS 1 para estados e alarmes; veja Níveis de QoS MQTT Explicados para os prós e contras.
- Use retained messages para o estado atual e mantenha os payloads pequenos e tipados.
- Escolha um broker que cresça com você; como escolher um broker MQTT para IoT apresenta os critérios.
Comece com o ConnectMQ
Você pode testar os dois exemplos acima no servidor MQTT público agora mesmo, só com dados simulados. Para construir um Unified Namespace de verdade, com topics isolados, visões de dispositivos ISA-95 e alertas por limite, cadastre-se em app.connectmq.com. O plano Serverless é gratuito, não exige cartão de crédito, e você pode escalar para Dedicated, BYOC ou Self Managed Enterprise quando sua planta entrar em operação.
Perguntas frequentes
Sparkplug B é a mesma coisa que um Unified Namespace?
Não. O Sparkplug B é uma especificação de topics, payloads e estado de sessão sobre MQTT, enquanto um Unified Namespace é um padrão de arquitetura para organizar todos os dados do negócio em uma única hierarquia. Os dois funcionam bem juntos.
Posso ler mensagens Sparkplug B sem um decodificador Protobuf?
Não diretamente, porque o payload é binário. O ConnectMQ decodifica payloads Sparkplug B em Protobuf e JSON e pode republicá-los como JSON legível em uma estrutura de topics ISA-95.
Qual deve ser a profundidade de uma hierarquia de topics ISA-95?
Enterprise, Site, Area, Line e WorkCell mais uma classe de dados somam seis níveis, o que atende à maioria das plantas. Mantenha a profundidade consistente para que as assinaturas com wildcard funcionem de forma previsível.
O Sparkplug B exige MQTT 5?
Não. O Sparkplug B funciona sobre MQTT 3.1.1 e costuma ser implantado assim. O ConnectMQ suporta MQTT 3.1.1 e MQTT 5.0, então edge nodes Sparkplug e clientes mais novos podem compartilhar o mesmo broker.
