Uma arquitetura de gêmeo digital clara é o que separa um gêmeo que escala para centenas de ativos de uma demonstração que desmorona depois dos cinco primeiros. Este guia percorre uma arquitetura de referência camada por camada, de sensores e gateways de borda, passando por uma espinha dorsal de mensageria, até state stores, modelos e visualização 3D, para que você possa projetar uma stack em que cada parte tem uma única função e pode ser substituída de forma independente.
Para os conceitos por trás dos gêmeos digitais, veja nosso guia sobre a tecnologia de gêmeo digital.
As Seis Camadas de uma Arquitetura de Gêmeo Digital
A maioria dos gêmeos bem-sucedidos, qualquer que seja o fornecedor ou framework, acaba com estas camadas:
| Camada | Responsabilidade | Tecnologia típica |
|---|---|---|
| 1. Dispositivo e borda | Ler sensores e controladores, normalizar, armazenar em buffer | CLPs, ESP32, Raspberry Pi, gateways de borda |
| 2. Mensageria | Mover dados e comandos em tempo real, desacoplar produtores e consumidores | Broker MQTT |
| 3. Estado | Manter o valor atual de cada propriedade | Topics retidos, armazenamento chave-valor, serviço de gêmeo |
| 4. Histórico | Armazenar séries temporais para tendências e análises | Banco de dados de séries temporais |
| 5. Modelo | Descrever ativos, relacionamentos, unidades e comportamento | Hierarquia de ativos, DTDL, AAS, modelos físicos ou de ML |
| 6. Visualização e aplicações | Exibir o gêmeo e agir sobre ele | Dashboards, visualizadores 3D web, apps móveis |
A regra de design principal: as camadas conversam entre si por contratos bem definidos (topics e schemas de payload), nunca por atalhos privados. É isso que permite trocar um dashboard por um visualizador 3D ou acrescentar um job de análise sem mexer no firmware dos dispositivos.
Camada 1: Dispositivo e Borda
Ativos físicos raramente falam uma linguagem amigável para gêmeos. Um controlador CNC expõe OPC UA ou um protocolo do fabricante; uma bomba antiga em uma estação de saneamento tem um sinal de 4–20 mA entrando em um CLP; um sensor novo pode rodar em um ESP32. A camada de borda preenche essa lacuna.
Responsabilidades na borda:
- Tradução de protocolos de Modbus, OPC UA ou fieldbus para MQTT.
- Normalização para unidades e nomes consistentes, para que
spindle_rpmsignifique a mesma coisa em todo lugar. - Deadband e controle de taxa, publicando um valor apenas quando ele muda de forma significativa ou em um intervalo fixo.
- Buffering quando o uplink cai, reenviando depois os dados com os timestamps originais.
Coloque os timestamps na origem. Um gêmeo que só sabe quando o broker recebeu um valor não consegue distinguir uma rede lenta de uma máquina lenta.
Camada 2: A Espinha Dorsal de Mensageria
A camada de mensageria é a coluna vertebral da arquitetura de gêmeo digital. Todo produtor publica nela e todo consumidor assina a partir dela, o que significa que os dispositivos nunca precisam saber quem está observando. Um broker MQTT é a escolha mais comum porque oferece:
- Topics hierárquicos que espelham a hierarquia de ativos.
- Wildcards, para que um visualizador no nível da linha assine
plant1/line2/#e receba todas as máquinas. - Retained messages que entregam o estado mais recente a novos assinantes imediatamente.
- Níveis de QoS para equilibrar garantias de entrega e overhead.
- Mensagens Last Will para que o gêmeo saiba quando um dispositivo desaparece.
Um bom design de topics segue a hierarquia no estilo ISA-95, terminando em uma classe de mensagem:
<enterprise>/<site>/<area>/<line>/<asset>/telemetry
<enterprise>/<site>/<area>/<line>/<asset>/state
<enterprise>/<site>/<area>/<line>/<asset>/cmd
<enterprise>/<site>/<area>/<line>/<asset>/cmd/ack
Separe telemetry (um fluxo, não retido), state (valores atuais, retidos) e cmd (comandos, nunca retidos). Misturá-los é a fonte mais comum de bugs em gêmeos, como um comando antigo sendo reenviado a um dispositivo após a reconexão. Nosso guia de gêmeo digital com MQTT aprofunda esses padrões.
Rodar o broker por conta própria significa cuidar de certificados TLS, autenticação, escalabilidade e monitoramento. Um broker MQTT gerenciado como o ConnectMQ elimina esse trabalho para que a equipe possa se concentrar no gêmeo em si.
Camada 3: Estado
A camada de estado responde a uma pergunta: qual é o valor atual do ativo neste exato momento? Há três opções comuns:
- Topics MQTT retidos. Cada ativo ou propriedade tem uma retained message. Simples, sem infraestrutura extra, e os visualizadores recebem o estado completo ao se conectar. Detalhado em usando retained messages MQTT como estado do gêmeo digital.
- Um serviço de gêmeo. Um serviço dedicado, como o Eclipse Ditto ou um microsserviço próprio, assina a telemetria e mantém um documento JSON por ativo, expondo-o via API.
- Um armazenamento em memória ou chave-valor alimentado por um assinante, útil quando muitas aplicações consultam o estado por API em vez de MQTT.
Para muitas equipes, a resposta certa é começar com topics retidos e adotar um serviço de gêmeo quando precisar de consultas, controle de acesso por ativo ou tratamento de estado desejado vs reportado. Veja sincronização de estado de gêmeo digital para esses padrões.
Camada 4: Histórico
O estado ao vivo não basta para tendências, análise de causa raiz ou machine learning. Um assinante de histórico escuta os topics de telemetria e grava em um banco de séries temporais. Ferramentas como Telegraf, Node-RED ou um pequeno serviço em Python atuam como clientes MQTT comuns para isso:
import json
import paho.mqtt.client as mqtt
def on_connect(client, userdata, flags, reason_code, properties):
client.subscribe("acme/plant1/+/+/+/telemetry", qos=1)
def on_message(client, userdata, msg):
point = json.loads(msg.payload)
asset_path = msg.topic.rsplit("/", 1)[0]
# Substitua por uma gravação no seu banco de séries temporais
print(asset_path, point)
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="YOUR_CLIENT_ID")
client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.tls_set()
client.on_connect = on_connect
client.on_message = on_message
client.connect("YOUR_BROKER_HOST", 8883)
client.loop_forever()
Mantenha os gravadores de histórico independentes do caminho ao vivo. Se o banco de dados estiver lento, a visualização 3D não deve atrasar.
Camada 5: O Modelo
A camada de modelo transforma números em significado. No mínimo, ela é um registro de ativos: quais ativos existem, como se relacionam (o site contém a linha, que contém a máquina), que propriedades cada um tem e em quais unidades. Gêmeos mais avançados acrescentam:
- Schemas formais, como interfaces DTDL ou submodelos da Asset Administration Shell.
- Valores derivados, como OEE, eficiência ou vida útil remanescente.
- Modelos de simulação ou de ML que preveem o comportamento e o comparam com a realidade.
Armazene o modelo separadamente do fluxo de dados, versione-o e referencie-o a partir dos topics por meio de IDs de ativos estáveis. Quando uma máquina é substituída, o modelo muda, mas o contrato de topics pode continuar o mesmo.
Camada 6: Visualização e Aplicações
A camada superior é o que as pessoas veem: dashboards, cenas 3D, apps móveis e consoles de alertas. Visualizadores 3D no navegador se conectam diretamente ao broker via WebSocket seguro, assinam o ramo relevante, carregam o estado retido ao se conectar e depois animam conforme as mensagens ao vivo chegam. Com MQTT.js, são poucas linhas:
import mqtt from "mqtt";
const client = mqtt.connect("wss://broker.connectmq.com:8084/mqtt", {
clientId: "twin-viewer-" + Math.random().toString(16).slice(2, 10),
protocolVersion: 5,
});
client.on("connect", () => {
client.subscribe("connectmq/demo/a91c/plant1/#");
});
client.on("message", (topic, payload) => {
const assetPath = topic.split("/").slice(3, -1).join("/");
updateSceneObject(assetPath, JSON.parse(payload.toString()));
});
function updateSceneObject(path, values) {
console.log("update", path, values);
}
O exemplo usa o servidor MQTT público (gratuito) em broker.connectmq.com, adequado para testes e protótipos, não para dados de produção. Em produção, use credenciais com escopo somente leitura para os visualizadores e mantenha a publicação de comandos atrás de um backend que valida as solicitações.
Checklist de Arquitetura de Gêmeo Digital
Antes de construir, confirme cada ponto:
- Hierarquia de topics definida e documentada, com classes separadas para telemetria, estado e comandos.
- Schema de payload por tipo de ativo, incluindo unidades e timestamps de origem.
- Estado retido para cada propriedade de que um visualizador precisa ao carregar.
- Mensagens Last Will para que ativos offline apareçam como offline.
- Gravador de histórico desacoplado do caminho ao vivo.
- Modelo de ativos versionado e indexado por IDs estáveis.
- TLS em tudo o que estiver fora da rede da planta, credenciais únicas por dispositivo ou gateway.
- Caminho de comandos com confirmações e timeouts.
Onde o ConnectMQ se Encaixa na Arquitetura
O ConnectMQ ocupa a camada de mensageria: um broker MQTT gerenciado, ou seja, um broker MQTT na nuvem com MQTT 3.1.1 e 5.0, TLS na porta 8883, WebSocket seguro na 8084 para visualizadores no navegador, retained messages e assinaturas compartilhadas para escalar consumidores nos planos pagos. Ele também detecta hierarquias de topics ISA-95 e pode decodificar Sparkplug B e republicá-lo em topics ISA-95, o que simplifica o contrato entre a borda e o gêmeo. State stores, bancos de histórico e serviços de modelo continuam sendo componentes seus, conectados como clientes MQTT. A demonstração de gêmeo digital 3D do ConnectMQ mostra a camada de visualização dessa arquitetura rodando ao vivo via WSS.
Comece Sua Arquitetura de Gêmeo Digital no ConnectMQ
Cadastre-se em app.connectmq.com, escolha o plano Serverless gratuito, sem cartão de crédito, crie um broker e use as credenciais geradas para conectar seu gateway de borda e seu primeiro visualizador. O cliente no navegador e o explorador de topics ao vivo permitem validar seu design de topics antes de escrever uma linha de código de visualização.
Perguntas frequentes
Qual é a camada mais importante em uma arquitetura de gêmeo digital?
A camada de mensageria e de contrato de dados. Se os topics e payloads forem bem projetados, todas as outras camadas podem ser construídas, substituídas ou escaladas de forma independente.
Preciso de um banco de dados separado para o estado do gêmeo?
No início, não. Retained messages MQTT podem guardar o estado atual de muitos gêmeos; acrescente um serviço de gêmeo ou um armazenamento quando precisar de consultas, controle de acesso por ativo ou tratamento de estado desejado.
Visualizadores 3D devem se conectar diretamente ao broker MQTT?
Para visualizações ao vivo somente leitura, conectar via WebSocket seguro é simples e rápido. Encaminhe os comandos por um backend que os valide e audite.
Como uma arquitetura de gêmeo digital lida com dispositivos offline?
Use mensagens Last Will do MQTT para publicar um status offline, armazene dados em buffer na borda durante as quedas e inclua timestamps de origem para que dados atrasados sejam posicionados corretamente.
