Combinar um gêmeo digital com MQTT é a forma mais direta de manter um modelo virtual em sintonia com equipamentos reais. Neste guia você vai aprender por que o modelo publish/subscribe do MQTT combina tão bem com gêmeos, como projetar topics, estado retido, presença e comandos, e como transmitir o estado ao vivo para um gêmeo no navegador com código Python e JavaScript executável.
Se o conceito de gêmeo é novo para você, comece pelo guia de tecnologia de gêmeo digital.
Por Que o MQTT Combina com Gêmeos Digitais
Um gêmeo precisa de três coisas do seu transporte: atualizações de baixa latência, uma forma de quem chega depois obter o estado atual e baixo acoplamento, para que novos consumidores possam ser adicionados sem mexer nos dispositivos. O MQTT oferece os três no próprio protocolo.
| Requisito do gêmeo | Recurso do MQTT | Por que ajuda |
|---|---|---|
| Atualizações ao vivo | Conexões persistentes, entrega por push | Os valores chegam em milissegundos, sem polling |
| Estado atual ao carregar | Retained messages | Um novo visualizador recebe instantaneamente o último valor de cada topic |
| Hierarquia de ativos | Topics hierárquicos e wildcards | plant1/line2/# entrega uma linha inteira em uma única assinatura |
| Status online/offline | Last Will and Testament | O broker anuncia quando um dispositivo cai |
| Controle de confiabilidade | QoS 0, 1, 2 | Telemetria rápida em QoS 0, eventos importantes em QoS 1 |
| Muitos consumidores | Desacoplamento publish/subscribe | Dashboards, visualizações 3D e análises compartilham um único fluxo |
| Visualizadores no navegador | MQTT sobre WebSocket | Cenas 3D se conectam diretamente, sem gateway extra |
O polling HTTP, por outro lado, obriga cada visualizador a bombardear uma API e ainda deixa lacunas entre as consultas. Filas de mensagens projetadas para processamento no backend muitas vezes não têm estado retido nem conectividade com o navegador. É por isso que tantas plataformas de gêmeo colocam um broker MQTT no centro.
Projetando Topics para um Gêmeo Digital com MQTT
A árvore de topics é o esquema de endereçamento do seu gêmeo. Espelhe a hierarquia física e termine com uma classe de mensagem:
connectmq/demo/<id>/factory1/line1/cnc1/telemetry stream, not retained
connectmq/demo/<id>/factory1/line1/cnc1/state current state, retained
connectmq/demo/<id>/factory1/line1/cnc1/status online/offline, retained + last will
connectmq/demo/<id>/factory1/line1/cnc1/cmd commands, never retained
connectmq/demo/<id>/factory1/line1/cnc1/cmd/ack command results
Regras que evitam dor de cabeça depois:
- Use identificadores estáveis nos níveis dos topics, não nomes de exibição. Nomes mudam; IDs não.
- Coloque unidades e timestamps no payload, não no topic.
- Mantenha cada payload pequeno e focado em um único ativo.
- Nunca retenha comandos. Um
cmdretido seria reexecutado toda vez que um dispositivo se reconectasse.
Para uma discussão mais profunda sobre como os topics se mapeiam para o modelo de ativos, veja arquitetura de gêmeo digital.
Retained Messages como a Memória do Gêmeo
Quando um visualizador abre o gêmeo, ele não deveria esperar o próximo ciclo de telemetria para mostrar cada máquina. Publicar o estado com a flag retain significa que o broker armazena a última mensagem de cada topic e a entrega imediatamente na assinatura. O tutorial de estado com retained MQTT constrói um gêmeo completo dessa forma; aqui está a ideia central em Python com paho-mqtt 2.x:
import json
import random
import time
import paho.mqtt.client as mqtt
PREFIX = "connectmq/demo/b72e/factory1/line1/cnc1"
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="cnc1-sim-b72e")
client.will_set(f"{PREFIX}/status", payload="offline", qos=1, retain=True)
client.connect("broker.connectmq.com", 1883)
client.loop_start()
client.publish(f"{PREFIX}/status", "online", qos=1, retain=True)
try:
while True:
state = {
"ts": int(time.time() * 1000),
"spindle_rpm": random.randint(7800, 8200),
"feed_mm_min": random.randint(900, 1100),
"tool": 4,
"mode": "AUTO",
}
client.publish(f"{PREFIX}/state", json.dumps(state), qos=0, retain=True)
time.sleep(1)
except KeyboardInterrupt:
client.publish(f"{PREFIX}/status", "offline", qos=1, retain=True)
client.loop_stop()
client.disconnect()
O Last Will no topic status é importante. Se o simulador travar ou a rede cair, o broker publica offline por você e, como a mensagem é retida, qualquer visualizador aberto depois também vê a máquina como offline.
Transmitindo o Gêmeo para o Navegador
Um gêmeo 3D ou 2D no navegador se conecta via WebSocket seguro na porta 8084 com o caminho /mqtt. Este exemplo com MQTT.js assina a linha inteira e atualiza um modelo do gêmeo em memória que o seu código de renderização pode ler a cada frame:
import mqtt from "mqtt";
const prefix = "connectmq/demo/b72e/factory1/line1";
const twin = new Map();
const client = mqtt.connect("wss://broker.connectmq.com:8084/mqtt", {
clientId: "twin-viewer-" + Math.random().toString(16).slice(2, 10),
protocolVersion: 5,
clean: true,
});
client.on("connect", () => {
client.subscribe(`${prefix}/+/state`);
client.subscribe(`${prefix}/+/status`);
});
client.on("message", (topic, payload) => {
const parts = topic.split("/");
const asset = parts[parts.length - 2];
const kind = parts[parts.length - 1];
const current = twin.get(asset) || {};
if (kind === "status") {
current.online = payload.toString() === "online";
} else {
Object.assign(current, JSON.parse(payload.toString()));
}
twin.set(asset, current);
console.log(asset, current);
});
Desacople o tratamento de mensagens da renderização. As mensagens atualizam o modelo; o loop de renderização lê o modelo. Isso mantém as taxas de quadros suaves mesmo quando as mensagens chegam em rajadas.
Design de Payload para Mensagens do Gêmeo
Os topics dizem aos consumidores a que lugar um valor pertence; os payloads dizem o que ele significa. Algumas convenções mantêm um gêmeo em crescimento gerenciável:
- Inclua um timestamp de origem (
tsem milissegundos) em toda mensagem de estado e de telemetria. Assim, os visualizadores podem mostrar a idade de cada valor e ignorar atualizações fora de ordem. - Use nomes de campos e unidades consistentes entre ativos do mesmo tipo, de preferência documentados em um schema ou em uma linguagem de modelagem como DTDL.
- Envie o estado completo no topic de estado, não patches parciais. Um patch parcial retido deixaria um novo visualizador com metade do quadro.
- Mantenha os payloads compactos. JSON é fácil de depurar e adequado para a maioria dos gêmeos; mude para uma codificação binária apenas quando a largura de banda for de fato limitada.
- Acrescente um campo de versão do schema quando os payloads puderem evoluir, para que dispositivos antigos e novos coexistam durante as implantações.
Essas regras não custam nada no início e evitam um retrabalho significativo quando dezenas de tipos de ativos e várias aplicações consumidoras passam a depender do mesmo fluxo.
Comandos: Fechando a Malha
Um gêmeo que observa se torna um gêmeo que opera quando consegue enviar comandos. O padrão seguro:
- A aplicação publica um comando com um correlation ID em
.../cmdcom QoS 1, sem reter. - O dispositivo valida e executa o comando e publica o resultado em
.../cmd/ackcom o mesmo ID. - O dispositivo atualiza seu
stateretido, que todos os visualizadores veem. - A aplicação aplica um timeout se nenhuma confirmação chegar.
O MQTT 5 torna isso mais limpo com as propriedades response topic e correlation data, além da expiração de mensagens, para que um comando que esperou demais seja descartado em vez de executado atrasado. Leia recursos do MQTT 5 para os detalhes. Para o tratamento de estado desejado versus reportado, veja sincronização de estado de gêmeo digital.
Escolhendo o QoS para Dados do Gêmeo
- Telemetria rápida para animação: QoS 0. Um frame perdido é substituído pelo próximo.
- Mudanças de estado e alarmes: QoS 1, para que não se percam em desconexões breves.
- Comandos: QoS 1 com tratamento idempotente e correlation IDs. QoS 2 raramente é necessário se os comandos forem idempotentes.
O artigo níveis de QoS do MQTT explicados cobre os trade-offs em profundidade.
Como o ConnectMQ Alimenta um Gêmeo Digital 3D ao Vivo
O ConnectMQ mantém uma demonstração web de gêmeo digital 3D de uma pequena fábrica com máquina CNC, braço robótico, forno, tanque, transportador e bomba. Ativos simulados publicam o estado no broker e a cena 3D assina via WebSocket seguro, usando exatamente os padrões acima: topics hierárquicos, estado retido para carregamento instantâneo e atualizações ao vivo comandando a animação.
Para o seu próprio gêmeo, o ConnectMQ oferece um broker MQTT gerenciado com MQTT 3.1.1 e 5.0, TLS na porta 8883 e WSS na 8084 com certificado Let's Encrypt, para que os visualizadores no navegador se conectem sem avisos de certificado. O explorador de topics ao vivo do portal e a visão de dispositivos por níveis ISA-95 ajudam a verificar se cada ativo está publicando onde deveria. Comece a experimentar no servidor MQTT público (gratuito) com dados de demonstração e depois migre para suas próprias credenciais para ativos reais.
Solução de Problemas em Gêmeos Digitais com MQTT
- O visualizador não mostra nada até a primeira atualização. O estado não está sendo publicado com a flag retain.
- Um dispositivo continua executando um comando antigo após reiniciar. Um comando foi retido. Limpe-o publicando um payload retido vazio nesse topic e pare de reter comandos.
- Ativos continuam "online" após queda de energia. Não há Last Will configurado ou o keepalive é longo demais.
- O navegador não consegue se conectar. Verifique a URL
wss://, a porta 8084 e o caminho/mqtt. - Animação engasgando. A renderização está acoplada ao tratamento de mensagens ou a taxa de telemetria é baixa demais para um movimento suave; interpole entre as amostras.
Conecte Seu Gêmeo Digital ao ConnectMQ
Crie um broker no plano Serverless (Free) em app.connectmq.com, sem cartão de crédito, copie o usuário, a senha e o client ID gerados e aponte seu simulador e seu visualizador para ele. Em poucos minutos você terá um gêmeo ao vivo transmitindo via MQTT.
Perguntas frequentes
Por que usar MQTT em vez de REST em um gêmeo digital?
O MQTT envia as atualizações assim que acontecem por uma conexão persistente e mantém o estado mais recente em retained messages, enquanto o REST exige polling e acrescenta latência e carga.
Um navegador pode se conectar diretamente ao MQTT para um gêmeo 3D?
Sim. Os navegadores se conectam via MQTT sobre WebSocket, por exemplo wss://broker.connectmq.com:8084/mqtt, usando uma biblioteca como MQTT.js.
Devo reter a telemetria ou apenas o estado?
Retenha o topic de estado atual para que os visualizadores carreguem instantaneamente; deixe os fluxos de telemetria de alta frequência sem retenção para evitar confusão entre o fluxo e o snapshot.
Como mostrar no gêmeo quando um dispositivo fica offline?
Configure uma mensagem Last Will em um topic de status retido. O broker a publica automaticamente quando o dispositivo se desconecta de forma inesperada.
