Modelagem de Dados IIoT: De Tags a Modelos de Informação

A modelagem de dados IIoT é o trabalho de transformar milhares de tags de CLP enigmáticas em informação estruturada e autodescritiva, que qualquer aplicação consegue consumir sem uma planilha de tags ao lado. Neste guia você vai conhecer as três camadas de um bom modelo de dados industrial, ver como ISA-95, templates Sparkplug B e OPC UA se encaixam e aprender a publicar um ativo modelado via MQTT, para que o resultado fique visível e testável em minutos.

Por que tags planas deixam de escalar

Toda planta começa com tags, seja um frigorífico, seja uma planta de embalagens em Joinville. Um CLP expõe N7:42, DB10.DBW4 ou Line2_Mtr3_Amps, e alguém mantém uma planilha explicando o que cada uma significa. Isso funciona para uma IHM conversando com um controlador. Deixa de funcionar no momento em que você adiciona um segundo consumidor.

Os problemas aparecem de formas previsíveis:

O significado vive fora dos dados. A tag T_204 é uma temperatura apenas porque um documento diz isso. A unidade, a faixa válida e o ativo ao qual pertence não estão no payload.
Cada integração repete o mapeamento. A equipe de MES, a do historiador e a de analytics reconstroem cada uma o mesmo dicionário de tags, e cada versão vai se distanciando.
Máquinas idênticas parecem diferentes. Cinco envasadoras de três fabricantes expõem cinco esquemas de nomes, então um dashboard feito para uma não pode ser reaproveitado nas outras.
Mudanças quebram consumidores silenciosamente. Quando um engenheiro de controle renomeia uma tag, nada avisa as aplicações a jusante.

Um modelo de dados resolve isso colocando estrutura, contexto e identidade nos próprios dados. Ele é a base de um Unified Namespace e é o que torna os dados de uma planta reutilizáveis, e não apenas disponíveis.

As três camadas de um modelo de dados IIoT

Uma forma útil de pensar a modelagem de dados IIoT é em três camadas. Cada uma responde a uma pergunta diferente, e cada uma pode ser projetada de forma independente.

Camada	Pergunta que responde	Norma ou ferramenta típica	Exemplo
Localização (onde)	A qual site, área, linha e célula isto pertence?	Hierarquia de equipamentos ISA-95	`acme/berlin/packaging/line2/filler1`
Tipo (o quê)	Que tipo de ativo é este e quais atributos ele sempre tem?	Templates Sparkplug B, ObjectTypes OPC UA	`Filler` com velocidade, estado, contagem, refugos
Dados da instância (valor)	Qual é o valor atual, com que unidade, qualidade e timestamp?	Schema de payload (JSON ou Protobuf)	`{"value": 118.4, "unit": "bpm", "ts": ...}`

Localização: o caminho ISA-95

A camada de localização dá a cada ponto de dado um endereço que as pessoas reconhecem. A ISA-95 define uma hierarquia de empresa, site, área, linha de produção ou centro de trabalho e unidade de trabalho. Usá-la como caminho do topic significa que o endereço de um valor também diz de onde ele vem fisicamente. O artigo sobre a hierarquia de equipamentos ISA-95 aprofunda a escolha dos níveis, e topics MQTT ISA-95 mostra como eles se mapeiam para os níveis de topic.

Mantenha a camada de localização estável. O layout físico raramente muda, por isso é uma boa espinha dorsal. Evite colocar no caminho coisas voláteis, como códigos de produto ou nomes de turno.

Tipo: definições de ativos reutilizáveis

A camada de tipo é onde a modelagem de verdade acontece. Você define uma Pump uma única vez, com seus atributos (vazão, pressão de descarga, corrente do motor, estado de operação), unidades e faixas permitidas, e toda instância de bomba segue essa definição, independentemente de qual CLP ou fabricante está por baixo.

Há duas formas comuns de expressar tipos em sistemas MQTT industriais:

Templates Sparkplug B permitem que um edge node publique uma definição de template no seu birth certificate e depois publique instâncias que fazem referência a ela. Veja o guia de templates Sparkplug para entender o mecanismo.
ObjectTypes e especificações companion do OPC UA definem tipos ricos e padronizados para muitas classes de máquina. Se suas máquinas já falam OPC UA, reutilize esses tipos em vez de inventar novos. A comparação OPC UA vs MQTT explica como os dois coexistem.

Se nenhum dos dois se aplicar, um JSON Schema simples por tipo de ativo, guardado sob controle de versão, é suficiente para começar.

Dados da instância: um payload consistente

A camada de valor é o payload. Seja qual for o formato escolhido, todo valor deve carregar o mesmo envelope: o valor, a unidade de engenharia, um timestamp da origem e um indicador de qualidade. Sem timestamp de origem, os consumidores não conseguem distinguir uma mensagem atrasada de uma leitura nova. Sem qualidade, um sensor congelado parece um processo estável.

Projetando um modelo de dados IIoT passo a passo

O checklist a seguir funciona para uma primeira linha ou uma primeira classe de máquina. Faça-o no papel antes de escrever qualquer configuração de gateway.

Escolha uma classe de ativo com várias instâncias. Bombas, motores ou envasadoras são boas candidatas, porque o reaproveitamento compensa imediatamente.
Liste as perguntas que os consumidores fazem. "Está rodando?", "Quanto produziu nesta hora?", "Está caminhando para uma falha?". O modelo deve responder a essas perguntas diretamente.
Defina o tipo. Dê a cada atributo um nome em linguagem simples, atribua uma unidade, um tipo de dado e uma faixa esperada. Decida quais atributos são telemetria (mudam com frequência), estado (mudam com eventos) e metadados (raramente mudam).
Mapeie tags para atributos por fabricante. Este é o único lugar onde nomes de tag específicos do fabricante devem aparecer, normalmente no gateway de borda.
Fixe o caminho de localização. Escolha os níveis ISA-95 de que precisa e registre os nomes permitidos em cada nível.
Escolha o envelope do payload. JSON com valor, unidade, timestamp e qualidade é o mais fácil de depurar. Protobuf do Sparkplug B é mais compacto e traz a semântica de birth e death.
Versione o modelo. Adicione um atributo modelVersion ou mantenha as definições de tipo em um repositório para que os consumidores detectem mudanças.
Publique uma instância e revise-a com os consumidores antes de estender ao restante da frota.

Publicando um ativo modelado via MQTT

Aqui está um exemplo mínimo em Python que publica uma envasadora modelada: metadados como retained message e telemetria como mensagens periódicas, tudo sob um caminho ISA-95. Ele usa o servidor MQTT público (gratuito) em broker.connectmq.com, feito para testes e protótipos, então não envie dados reais da planta para ele; o servidor MQTT público pode ser lido por qualquer pessoa.

import json
import random
import time
import uuid

import paho.mqtt.client as mqtt

BROKER = "broker.connectmq.com"
RUN_ID = uuid.uuid4().hex[:8]
BASE = f"connectmq/demo/{RUN_ID}/berlin/line2/filler1"

# Definição do tipo: como toda Filler se parece
FILLER_MODEL = {
    "type": "Filler",
    "modelVersion": "1.2.0",
    "attributes": {
        "speed": {"unit": "bpm", "dataType": "float", "min": 0, "max": 200},
        "state": {"dataType": "string", "enum": ["RUNNING", "IDLE", "FAULT"]},
        "goodCount": {"unit": "units", "dataType": "int"},
        "rejectCount": {"unit": "units", "dataType": "int"},
    },
    "metadata": {"vendor": "ExampleVendor", "serial": "F-2291", "commissioned": "2024-03-11"},
}


def on_connect(client, userdata, flags, reason_code, properties):
    print("connected:", reason_code)


client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=f"model-demo-{RUN_ID}")
client.on_connect = on_connect
client.connect(BROKER, 1883, keepalive=60)
client.loop_start()

# Publica o modelo uma vez, retido, para que assinantes tardios possam descobri-lo
client.publish(f"{BASE}/model", json.dumps(FILLER_MODEL), qos=1, retain=True)

good, rejects = 0, 0
try:
    while True:
        ts = int(time.time() * 1000)
        speed = round(random.gauss(120, 4), 1)
        good += int(speed / 60 * 5)
        rejects += 1 if random.random() < 0.05 else 0
        for name, value, unit in [
            ("speed", speed, "bpm"),
            ("goodCount", good, "units"),
            ("rejectCount", rejects, "units"),
        ]:
            payload = {"value": value, "unit": unit, "ts": ts, "quality": "GOOD"}
            client.publish(f"{BASE}/telemetry/{name}", json.dumps(payload), qos=0)
        client.publish(f"{BASE}/state", json.dumps({"value": "RUNNING", "ts": ts}), qos=1, retain=True)
        time.sleep(5)
except KeyboardInterrupt:
    client.loop_stop()
    client.disconnect()

Acompanhe o resultado com o cliente Mosquitto:

mosquitto_sub -h broker.connectmq.com -p 1883 -i watcher-$RANDOM -t "connectmq/demo/+/berlin/#" -v

Repare na profundidade: o servidor MQTT público permite até 8 níveis de topic, então a demonstração mantém apenas site, linha e máquina sob o prefixo de demonstração (o topic mais profundo, .../filler1/telemetry/speed, tem exatamente 8 níveis). No seu próprio namespace você acrescentaria também empresa e área. Em produção, em um broker MQTT gerenciado, você usa suas próprias credenciais e não fica limitado a um prefixo de demonstração compartilhado.

Como o ConnectMQ ajuda você a enxergar o modelo

Quando os dados modelados começam a fluir, você precisa de uma forma de verificá-los. O ConnectMQ detecta topics no estilo ISA-95 e Unified Namespace e mostra no portal os dispositivos conectados agrupados por níveis ISA-95, de modo que um nível errado ou um nome de linha com erro de digitação salta aos olhos imediatamente. O explorador de topics em tempo real mostra as mensagens retidas de modelo e estado ao lado da telemetria, uma forma rápida de confirmar que o envelope é consistente entre as instâncias.

Se seus edge nodes publicam Sparkplug B, o ConnectMQ decodifica os payloads Protobuf e pode republicá-los em topics ISA-95; por exemplo, spBv1.0/factory1/DDATA/line1/cnc1 se torna connectmq/factory1/production/line1/cnc1/telemetry. Assim você tem o transporte compacto do Sparkplug a partir da borda e topics legíveis e modelados para os consumidores. O artigo sobre Sparkplug B e Unified Namespace aborda esse padrão em detalhes.

Armadilhas comuns na modelagem de dados IIoT

Modelar o CLP em vez do processo. Se o seu atributo se chama DB10_Word4, você apenas mudou a tag de lugar. Modele aquilo de que operadores e engenheiros falam.
Níveis de hierarquia demais. Cada nível extra é mais um lugar para inconsistências de nomes. Use os níveis que realmente variam na sua planta e pule o resto.
Unidades nos nomes dos atributos. temperature_degC acopla o nome à unidade. Coloque a unidade no payload ou na definição do tipo.
Sem timestamps de origem. O horário de chegada ao broker não é o horário da medição, especialmente quando os gateways fazem buffer durante quedas.
Misturar estado e telemetria em um único fluxo. Mudanças de estado são raras e devem ser retidas; telemetria de alta frequência geralmente não.
Sem responsável. Um modelo sem dono se desvia. Atribua uma pessoa ou equipe por tipo de ativo.

Para onde o modelo vai depois

Um bom modelo de dados não é um fim em si mesmo. Ele alimenta o historiador, o MES, os dashboards, o machine learning e o gêmeo digital de cada linha. O guia de IoT industrial com MQTT mostra a arquitetura mais ampla e, se quiser entender como as mensagens são roteadas entre todos esses consumidores, comece por o que faz um broker MQTT. Quando você ultrapassar uma única planta, um broker MQTT na nuvem permite que vários sites publiquem em um único namespace consistente.

Comece com o ConnectMQ

Modele uma classe de ativo, publique-a e observe-a em um broker real. Crie um broker Serverless gratuito em app.connectmq.com, sem cartão de crédito, aponte seu gateway ou o script Python acima para suas próprias credenciais (YOUR_USERNAME, YOUR_PASSWORD, YOUR_CLIENT_ID) e use a visão de dispositivos ISA-95 para conferir se sua hierarquia ficou como você projetou.

Perguntas frequentes

O que é modelagem de dados IIoT?

Modelagem de dados IIoT é a prática de dar aos dados industriais uma estrutura consistente: uma localização em uma hierarquia de ativos, um tipo que define quais atributos um ativo tem e um formato de payload com unidades, timestamps e qualidade. Ela substitui planilhas de tags por dados autodescritivos.

Devo usar templates Sparkplug B ou tipos OPC UA?

Use tipos OPC UA se suas máquinas já os expõem ou se existe uma especificação companion para sua classe de equipamento. Use templates Sparkplug B quando sua arquitetura de borda for nativa em MQTT e você quiser a semântica de birth e death; ambos podem alimentar o mesmo namespace ISA-95.

Onde deve acontecer o mapeamento de tags para o modelo?

No gateway de borda ou no conector mais próximo do CLP. Isso mantém os nomes específicos do fabricante em um único lugar e permite que todos os consumidores acima do gateway vejam apenas o modelo limpo.

Preciso de um modelo de dados antes de começar um Unified Namespace?

Você precisa pelo menos da camada de localização e de um envelope de payload. Os tipos de ativo podem ser adicionados classe a classe, mas combinar primeiro os caminhos e o envelope evita renomeações caras mais tarde.

Modelagem de Dados IIoT: De Tags Planas a Modelos de Informação