Aliases de Métricas no Sparkplug: Economizando Banda nas Mensagens DATA

Os aliases de métricas do Sparkplug permitem que um edge node substitua nomes longos de métricas, como Line2/Filler/Motor/CurrentAmps, por um pequeno inteiro em cada mensagem DATA. Neste guia você vai aprender como funciona o mapeamento de aliases entre as mensagens BIRTH e DATA, quando os aliases compensam a complexidade extra e como encontrar e corrigir divergências de aliases quando os valores decodificados de repente parecem errados.

Por que os nomes de métricas custam caro

Os payloads Sparkplug B são Protobuf, que já é compacto. Os números são codificados como varint, os timestamps são inteiros de 64 bits e não há pontuação de JSON. A única parte de um payload que o Protobuf não consegue encolher é uma string, e os nomes de métricas são strings.

As convenções de nomenclatura industriais deixam essas strings longas. Um caminho de tag copiado do navegador de tags de um CLP ou SCADA costuma trazer a área, a máquina, o subsistema e o sinal: Packaging/Line2/Filler/Infeed/Motor1/Current. Quando uma mensagem DDATA reporta um único valor alterado, esse nome de 45 caracteres pode ser várias vezes maior do que o valor e o timestamp somados.

Em uma rede cabeada de planta isso raramente importa. Em links celulares, links via satélite, rádio licenciado ou redes compartilhadas congestionadas, como os de uma mineradora no interior ou de uma usina remota, importa muito. Cada byte é pago, seja em dinheiro, seja em latência. Os aliases de métricas do Sparkplug são a resposta da especificação: envie o nome uma vez e, depois, refira-se a ele por um número.

Como funcionam os aliases de métricas do Sparkplug

O mecanismo tem três regras.

1. No NBIRTH (para métricas em nível de node) ou no DBIRTH (para métricas de device), cada métrica é enviada com o seu name e um alias, um inteiro de 64 bits sem sinal.
2. Nas mensagens NDATA, DDATA, NCMD e DCMD seguintes, a métrica é enviada apenas com o alias. O campo name é omitido.
3. Os aliases precisam ser únicos no escopo de um edge node. Duas métricas no mesmo edge node, mesmo em devices diferentes, não podem compartilhar um alias.

Uma Primary Host Application ou qualquer outro consumidor monta uma tabela de consulta quando recebe o BIRTH. A partir daí, toda métrica DATA que chega com um alias é resolvida de volta para o seu nome completo por meio dessa tabela.

Esta é a mesma métrica nos dois tipos de mensagem, mostrada como a estrutura Protobuf decodificada:

DBIRTH  spBv1.0/plant1/DBIRTH/edge-07/filler-02
  metric { name: "Infeed/Motor1/Current"  alias: 12  datatype: Float  float_value: 4.81 }
  metric { name: "Infeed/Motor1/Running"  alias: 13  datatype: Boolean  boolean_value: true }

DDATA   spBv1.0/plant1/DDATA/edge-07/filler-02
  metric { alias: 12  datatype: Float  float_value: 4.93  timestamp: 1792137600123 }

A métrica do DDATA não carrega nome algum. Sem o DBIRTH, um consumidor tem um float e o número 12, e nada mais.

O que os aliases não mudam

Os aliases substituem apenas o nome. Datatype, valor, timestamp, propriedades de qualidade e metadados funcionam exatamente como antes. Os topics também permanecem os mesmos: os aliases não têm nada a ver com os topic aliases do MQTT 5, que encurtam a string do topic no nível do protocolo. Os dois podem coexistir, mas são recursos independentes definidos por especificações diferentes. Se você quer a versão no nível do MQTT, veja a seção de topic alias no nosso guia de recursos do MQTT 5.

Nomes vs aliases: prós e contras

A linha de risco é a que importa. Um nome errado é óbvio. Um alias errado não é: o consumidor grava tranquilamente uma corrente de motor em uma tag de temperatura, o número parece plausível, e um historiador ou um gêmeo digital da linha passa a exibir dados errados sem nenhum aviso.

O ciclo de vida dos aliases na prática

Os aliases só são válidos durante a vida de um único BIRTH. Entender quando essa vida termina evita a maioria dos bugs.

• O NBIRTH reinicia tudo. Quando um edge node publica um novo NBIRTH, todas as tabelas de aliases daquele node são descartadas e reconstruídas a partir do novo NBIRTH e dos DBIRTHs seguintes. Um edge node é livre para atribuir números de alias diferentes depois de um rebirth, então um consumidor nunca deve manter aliases em cache entre births.
• O NDEATH invalida a tabela. Quando o broker publica a mensagem will NDEATH do edge node, os consumidores devem marcar as métricas do node como desatualizadas e deixar de confiar na tabela de aliases até o próximo NBIRTH.
• O DBIRTH pode adicionar métricas de device. Um device pode fazer rebirth sozinho, e os aliases das suas métricas ainda precisam ser únicos em todo o edge node.
• Solicitações de rebirth recuperam o estado perdido. Um host que vê um alias que não conhece deve enviar um NCMD com a métrica Node Control/Rebirth definida como true, em vez de adivinhar. Nosso artigo sobre rebirth no Sparkplug detalha esse fluxo.

O número de sequência também ajuda. Toda mensagem Sparkplug de um edge node carrega um seq de 0 a 255 que volta ao início. Se um consumidor vê uma lacuna, ele pode ter perdido um BIRTH e deve solicitar um rebirth antes de voltar a confiar nos aliases. As regras das mensagens BIRTH e DEATH estão explicadas em certificados de birth e death do Sparkplug.

Decodificando dados com alias em Python

O script a seguir assina todo o tráfego Sparkplug de um group, monta tabelas de aliases a partir das mensagens NBIRTH e DBIRTH e resolve as métricas DATA de volta para os nomes. Ele usa o sparkplug_b_pb2.py, o módulo Protobuf gerado do projeto Eclipse Tahu; copie-o para junto do script e instale as dependências com pip install paho-mqtt protobuf.

import paho.mqtt.client as mqtt
import sparkplug_b_pb2

BROKER = "broker.connectmq.com"
GROUP = "demo-7f3k2"          # use o seu próprio group ID exclusivo no broker público
alias_tables = {}             # edge_node_id -> {alias: name}

def on_connect(client, userdata, flags, reason_code, properties):
    print("connected:", reason_code)
    client.subscribe(f"spBv1.0/{GROUP}/#", qos=0)

def on_message(client, userdata, msg):
    parts = msg.topic.split("/")
    if len(parts) < 4:
        return
    msg_type, edge_node = parts[2], parts[3]
    device = parts[4] if len(parts) > 4 else None

    payload = sparkplug_b_pb2.Payload()
    payload.ParseFromString(msg.payload)

    if msg_type == "NBIRTH":
        alias_tables[edge_node] = {}          # um novo NBIRTH reinicia todos os aliases
    if msg_type in ("NBIRTH", "DBIRTH"):
        table = alias_tables.setdefault(edge_node, {})
        for m in payload.metrics:
            if m.HasField("alias"):
                if m.alias in table and table[m.alias] != m.name:
                    print(f"WARNING duplicate alias {m.alias} on {edge_node}")
                table[m.alias] = m.name
        print(f"{msg_type} {edge_node}/{device or ''}: {len(alias_tables[edge_node])} aliases")
        return

    if msg_type == "NDEATH":
        alias_tables.pop(edge_node, None)
        print(f"NDEATH {edge_node}: alias table cleared")
        return

    if msg_type in ("NDATA", "DDATA"):
        table = alias_tables.get(edge_node)
        for m in payload.metrics:
            name = m.name
            if not name and m.HasField("alias"):
                if table is None or m.alias not in table:
                    print(f"UNKNOWN alias {m.alias} from {edge_node}, request a rebirth")
                    continue
                name = table[m.alias]
            value = getattr(m, m.WhichOneof("value")) if m.WhichOneof("value") else None
            print(f"{edge_node}/{device or ''} {name} = {value} (seq {payload.seq})")

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="alias-decoder-7f3k2")
client.on_connect = on_connect
client.on_message = on_message
client.connect(BROKER, 1883, keepalive=60)
client.loop_forever()

Para gerar tráfego de teste com aliases, combine este script com o publisher do nosso tutorial de simulador de edge node Sparkplug B. Os dois scripts funcionam com o servidor MQTT público (gratuito) em broker.connectmq.com. Lembre-se de que o servidor MQTT público pode ser lido por qualquer pessoa e serve para testes e protótipos, então use um group ID aleatório e nunca publique dados reais da planta ali.

Depurando divergências de aliases

A maioria dos problemas com aliases se encaixa em alguns poucos padrões. Use este checklist quando os valores decodificados parecerem errados.

1. Consumidor iniciado depois do BIRTH. As mensagens BIRTH não são retained no Sparkplug, então um consumidor que se conecta depois só vê DATA com aliases. A solução é uma solicitação de rebirth, ou uma Primary Host Application que dispare rebirths automaticamente.
2. Cache desatualizado depois de um rebirth. Se um consumidor mantém a tabela antiga depois de um novo NBIRTH, os valores vão parar nos nomes errados. Reinicie a tabela a cada NBIRTH, como faz o script acima.
3. Aliases duplicados entre devices. Algumas configurações de borda numeram os aliases por device, começando em 1. Dois devices passam então a reivindicar o alias 1, o que viola a regra de unicidade e corrompe qualquer consumidor que indexe as tabelas por edge node.
4. Alias zero tratado como ausente. No Protobuf, um campo definido com o seu valor padrão pode ser indistinguível de um campo ausente, dependendo de como o código faz a verificação. Começar os aliases em 1 evita toda uma classe de bugs.
5. Nomes e aliases misturados. Uma métrica DATA pode legalmente incluir nome e alias. Os consumidores devem preferir o nome quando presente, e os edge nodes devem ser consistentes.
6. Vários publishers usando o mesmo edge node ID. Dois gateways configurados com o mesmo group e edge node ID sobrescrevem os births um do outro. O sintoma são aliases que alternam de significado.

A inspeção visual agiliza esse trabalho. O ConnectMQ decodifica payloads Sparkplug B, em Protobuf ou JSON, então no topic explorer ao vivo do portal você pode abrir as mensagens BIRTH e DATA lado a lado e conferir se o alias 12 é mesmo a métrica que você espera. O ConnectMQ também pode republicar dados Sparkplug B em topics ISA-95 legíveis, por exemplo spBv1.0/factory1/DDATA/line1/cnc1 em connectmq/factory1/production/line1/cnc1/telemetry, o que oferece aos consumidores que não usam Sparkplug um caminho que não depende de tabelas de aliases.

Quando você deve habilitar aliases?

Os aliases são opcionais. Habilite-os quando o link entre a borda e o broker for tarifado ou restrito, quando houver muitas tags com nomes longos ou quando um único gateway publicar muitas métricas em alta frequência. Mantenha os nomes simples quando estiver prototipando, quando muitos consumidores leves assinarem diretamente sem um host primário ou quando a facilidade de depuração importar mais do que os bytes.

Um meio-termo funciona bem para muitas equipes: desenvolva e comissione com nomes, meça o tamanho dos payloads sob carga realista e ative os aliases apenas nos sites cujos links precisarem. Como os aliases são negociados inteiramente dentro do BIRTH, os consumidores que implementam a consulta corretamente não precisam de nenhuma mudança de configuração quando você ativa essa opção.

Para entender melhor onde o Sparkplug se encaixa em uma arquitetura de planta, nosso guia de IoT industrial com MQTT cobre o panorama geral, e o artigo sobre payload Sparkplug B explica cada campo que você viu na saída decodificada acima. A definição oficial do comportamento dos aliases é a especificação Eclipse Sparkplug.

Teste aliases do Sparkplug no ConnectMQ

Rodar edge nodes e aplicações host contra um broker que você controla é a forma mais rápida de validar o tratamento de aliases antes que ele chegue à produção. O ConnectMQ é um broker MQTT gerenciado com MQTT 3.1.1 e 5.0, TLS na porta 8883 e decodificação de Sparkplug B embutida no portal. Crie um broker no plano gratuito Serverless em app.connectmq.com, sem cartão de crédito, e aponte o seu edge node para ele com o username, a senha e o client ID gerados.

Perguntas frequentes

Os aliases de métricas do Sparkplug são obrigatórios?

Não. Os aliases são opcionais no Sparkplug B. Um edge node pode enviar nomes completos de métricas em toda mensagem DATA, e os consumidores precisam tratar as duas formas.

Os números de alias podem mudar entre births?

Sim. Os aliases só valem até o próximo NBIRTH daquele edge node. Os consumidores precisam reconstruir as tabelas a cada NBIRTH e nunca persistir aliases entre sessões.

O que um host deve fazer com um alias desconhecido?

Ele não deve adivinhar. A resposta correta é enviar um NCMD com Node Control/Rebirth definido como true para que o edge node republique as suas mensagens BIRTH e o mapeamento completo de aliases.

Os aliases do Sparkplug são o mesmo que os topic aliases do MQTT 5?

Não. Os aliases de métricas do Sparkplug substituem os nomes das métricas dentro do payload, enquanto os topic aliases do MQTT 5 substituem a string do topic no nível do protocolo. Eles são independentes e podem ser usados juntos.