Como Construir um Unified Namespace Passo a Passo

Saber como construir um Unified Namespace transforma um termo da moda em uma arquitetura que funciona: um único broker MQTT onde cada máquina, linha e sistema publica seu estado atual sob um topic previsível, baseado em hierarquia. Neste tutorial você vai modelar sua planta, escolher um broker, publicar dados retidos da borda com Python, adicionar um consumidor que lê o estado de toda a planta e implantar a governança que mantém o namespace utilizável à medida que ele cresce.

O que você está construindo

Um Unified Namespace (UNS) não é um produto. É um acordo: todos os produtores publicam em um único hub orientado a eventos, organizado por uma estrutura comum, e todos os consumidores assinam o que precisam em vez de criar integrações ponto a ponto. Na prática, esse hub é um broker MQTT e a estrutura costuma ser a hierarquia de equipamentos ISA-95.

A arquitetura final tem quatro camadas:

A propriedade-chave é o desacoplamento. O historiador não sabe que o CLP existe, e o gateway do CLP não sabe quem está ouvindo. Cada um se conecta uma única vez, ao broker.

Passo 1: Modele a hierarquia da sua planta

Antes de escrever qualquer código, decida como a planta será organizada no namespace. A hierarquia de equipamentos ISA-95 oferece um ponto de partida comprovado: empresa, site, área, linha (ou célula de processo) e célula ou máquina. Nosso guia sobre a hierarquia de equipamentos ISA-95 explica cada nível com exemplos de chão de fábrica.

Percorra uma lista curta para uma área piloto:

1. Liste os sites no escopo e dê a cada um um identificador curto, estável e em minúsculas (dallas, izmir).
2. Dentro de um site, liste as áreas (packaging, utilities, machining).
3. Dentro de uma área, liste as linhas e suas máquinas (line2/filler, line2/capper).
4. Decida o que fica sob cada máquina: um objeto telemetry, topics individuais por métrica ou ambos.
5. Registre o resultado como uma árvore de topics e obtenha a concordância de operações, engenharia e TI.

Uma primeira árvore piloto pode ficar assim:

acme/dallas/packaging/line2/filler/telemetry
acme/dallas/packaging/line2/filler/state
acme/dallas/packaging/line2/capper/telemetry
acme/dallas/utilities/compressors/comp1/telemetry

Invista tempo aqui. Renomear um topic depois que vinte consumidores dependem dele é doloroso. Nossos guias sobre topics MQTT ISA-95 e estrutura de topics UNS trazem árvores prontas e as armadilhas a evitar.

Passo 2: Escolha o broker central

O broker se torna o software mais importante da planta, então escolha com cuidado. Ele precisa suportar MQTT 3.1.1 para gateways mais antigos e MQTT 5 para clientes mais novos, retained messages para o estado atual, TLS com credenciais por cliente e conexões suficientes para todos os gateways e consumidores que você pretende adicionar. Para um checklist completo, veja como escolher um broker MQTT para IoT.

Você pode operar o broker por conta própria em um servidor na planta ou usar um broker MQTT na nuvem operado por terceiros. As plantas, seja uma fábrica de autopeças em Joinville ou uma linha de envase em Campinas, costumam começar o piloto com um broker MQTT gerenciado porque isso tira a aplicação de patches e o monitoramento de servidores do caminho crítico. O ConnectMQ, por exemplo, oferece em cada broker MQTT 3.1.1 e 5.0, TLS na porta 8883, um explorador de topics em tempo real e uma visão de dispositivos que agrupa os dispositivos ativos por níveis ISA-95, exatamente o que você quer ver enquanto o namespace toma forma.

Para este tutorial, você pode usar o servidor MQTT público (gratuito) em broker.connectmq.com. Ele não exige conta, mas tudo o que é publicado ali pode ser lido por qualquer pessoa e ele serve apenas para testes e protótipos, não para dados de produção; por isso prefixamos os topics com connectmq/demo/<random-id>/ e publicamos apenas valores simulados. O servidor MQTT público permite até 8 níveis de topic, o que acomoda connectmq/demo/k4p9/dallas/packaging/line2/filler/telemetry exatamente.

Passo 3: Publique os dados da borda como estado retido

A camada de borda lê as máquinas e publica seu estado atual. Implantações reais usam drivers OPC UA, Modbus ou de CLP; aqui, um script Python faz o papel de gateway para que você veja as regras de publicação com clareza. Instale o cliente com pip install "paho-mqtt>=2.0".

import json
import random
import time
from datetime import datetime, timezone

import paho.mqtt.client as mqtt

BROKER = "broker.connectmq.com"
PREFIX = "connectmq/demo/k4p9"     # substitua k4p9 pelo seu próprio ID aleatório
MACHINES = [
    ("dallas", "packaging", "line2", "filler"),
    ("dallas", "packaging", "line2", "capper"),
]

def on_connect(client, userdata, flags, reason_code, properties):
    print("gateway connected:", reason_code)
    for site, area, line, machine in MACHINES:
        state_topic = f"{PREFIX}/{site}/{area}/{line}/{machine}/state"
        client.publish(state_topic, "online", qos=1, retain=True)

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="uns-gateway-k4p9")
client.on_connect = on_connect
# Se o gateway cair, o broker marca a primeira máquina como offline para todos
client.will_set(f"{PREFIX}/dallas/packaging/line2/filler/state", "offline", qos=1, retain=True)
client.connect(BROKER, 1883, keepalive=30)
client.loop_start()

counts = {m[3]: 0 for m in MACHINES}
try:
    while True:
        for site, area, line, machine in MACHINES:
            counts[machine] += random.randint(4, 6)
            payload = {
                "timestamp": datetime.now(timezone.utc).isoformat(),
                "speed_bpm": round(random.uniform(110, 125), 1),
                "temperature_c": round(random.uniform(38, 44), 1),
                "good_count": counts[machine],
            }
            topic = f"{PREFIX}/{site}/{area}/{line}/{machine}/telemetry"
            client.publish(topic, json.dumps(payload), qos=1, retain=True)
        time.sleep(5)
except KeyboardInterrupt:
    client.loop_stop()
    client.disconnect()

Três regras fazem disso um publicador de UNS, e não apenas um emissor de dados. Toda mensagem é retida, então um novo consumidor recebe o valor atual imediatamente. Os payloads carregam seu próprio timestamp e as unidades nos nomes dos campos. E a disponibilidade da máquina é explícita, com uma will message que muda o estado para offline quando o gateway desaparece.

Se a sua borda já fala Sparkplug B, você não precisa reescrevê-la. O ConnectMQ decodifica payloads Sparkplug B e pode republicá-los em topics ISA-95, por exemplo spBv1.0/factory1/DDATA/line1/cnc1 em connectmq/factory1/production/line1/cnc1/telemetry. Assim, edge nodes Sparkplug e publicadores de JSON simples compartilham um único namespace. Os prós e contras de cada abordagem estão em MQTT, Sparkplug B e o Unified Namespace.

Passo 4: Adicione seus primeiros consumidores

Um namespace prova seu valor quando novos consumidores surgem sem que ninguém mexa na borda. Este assinante monta em memória um modelo de toda a planta a partir de uma única assinatura com curinga:

import json
import paho.mqtt.client as mqtt

PREFIX = "connectmq/demo/k4p9"
plant = {}

def on_connect(client, userdata, flags, reason_code, properties):
    client.subscribe(f"{PREFIX}/#", qos=1)

def on_message(client, userdata, msg):
    levels = msg.topic[len(PREFIX) + 1:].split("/")
    if len(levels) != 5:
        return
    site, area, line, machine, kind = levels
    node = plant.setdefault(site, {}).setdefault(area, {}).setdefault(line, {}).setdefault(machine, {})
    text = msg.payload.decode()
    node[kind] = json.loads(text) if kind == "telemetry" else text
    print(f"{site}/{area}/{line}/{machine} {kind}: {node[kind]}" + (" (retained)" if msg.retain else ""))

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="uns-viewer-k4p9")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=60)
client.loop_forever()

Inicie-o enquanto o gateway estiver rodando e repare que as primeiras mensagens vêm marcadas como retidas: o consumidor teve a visão completa da planta no instante em que assinou. Restrinja o escopo com curingas depois do prefixo, por exemplo connectmq/demo/k4p9/+/packaging/# para uma área em todos os sites ou connectmq/demo/k4p9/+/+/+/filler/telemetry para todas as envasadoras em qualquer lugar.

Os próximos consumidores típicos são um dashboard, um historiador, um serviço de alertas e, mais adiante, um gêmeo digital da linha. Cada um é apenas mais um assinante. Para armazenamento, nosso guia de historiador MQTT mostra assinantes Telegraf e Python alimentando bancos de dados de séries temporais; o namespace continua sendo a fonte da verdade atual, enquanto o armazenamento guarda o histórico.

Passo 5: Governe o namespace

Sem regras, um UNS se degrada em um pântano de topics em poucos meses. Implante estas regras antes que a segunda área entre:

• Padrão de nomenclatura. Minúsculas, hifens em vez de espaços, nada de nomes de pessoas ou números de chamados nos topics.
• Responsabilidade. Cada ramo da árvore tem um responsável que aprova novos topics.
• Contrato de payload. Um JSON schema documentado por tipo de topic, com regras de unidades e timestamp.
• Credenciais por publicador. Uma identidade por gateway ou aplicação, para saber quem publica o quê e revogar acessos de forma limpa.
• Processo de mudança. Novos topics são adicionados, topics antigos são descontinuados com data de desativação e nunca renomeados silenciosamente.
• Observabilidade. Alguém acompanha o estado das conexões, as taxas de mensagens e os topics desatualizados.

O portal do ConnectMQ ajuda na parte de observabilidade: o explorador de topics em tempo real mostra a árvore enquanto ela cresce, a visão de dispositivos ISA-95 mostra a qual empresa, site, área e linha cada dispositivo ativo pertence, e regras de alerta por limite avisam quando um valor ultrapassa um limiar.

Erros comuns ao construir um UNS

Para o contexto industrial mais amplo, veja nosso guia de MQTT para IoT industrial.

Construa seu Unified Namespace no ConnectMQ

Um Unified Namespace precisa de um broker em cuja disponibilidade você possa confiar e de uma visão clara da árvore de topics à medida que ela cresce. O ConnectMQ é um broker MQTT gerenciado com MQTT 3.1.1 e 5.0, TLS, retained messages, decodificação de Sparkplug B, republicação ISA-95 e uma visão de dispositivos ISA-95. Comece seu piloto no plano gratuito Serverless em app.connectmq.com, sem cartão de crédito, e migre para um plano pago, Dedicated ou BYOC conforme mais linhas forem entrando.

Perguntas frequentes

Preciso de Sparkplug B para construir um Unified Namespace?

Não. Muitos namespaces usam JSON simples sobre MQTT. O Sparkplug B acrescenta gerenciamento de estado e métricas tipadas, e os dois podem coexistir se o broker republicar os dados Sparkplug em topics legíveis.

O broker do UNS deve rodar on-premise ou na nuvem?

Os dois funcionam. On-premise mantém o tráfego local; um broker MQTT gerenciado elimina trabalho de operação e facilita o acesso entre sites. Muitas plantas começam o piloto com um broker MQTT gerenciado e decidem com base no que aprendem.

Qual deve ser o tamanho do primeiro piloto de UNS?

Uma linha ou uma área com algumas máquinas e dois ou três consumidores é suficiente para comprovar o padrão e refinar o padrão de nomenclatura.

Um Unified Namespace substitui um historiador?

Não. O UNS mantém o estado atual e os eventos; um historiador ou data lake o assina e guarda o histórico de longo prazo.