Device Shadow vs Gêmeo Digital: Diferenças, Casos de Uso e um Padrão de Shadow com MQTT

A dúvida device shadow vs gêmeo digital aparece em quase todo projeto de IoT, porque ambos mantêm na nuvem uma cópia do estado de um dispositivo. Este artigo explica exatamente como eles diferem em escopo, dados e propósito, mostra quando um shadow é tudo de que você precisa e quando é necessário um gêmeo completo, e apresenta um padrão de device shadow portátil construído sobre topics MQTT retidos.

Para aprofundar o lado do gêmeo, veja o guia completo sobre gêmeo digital.

O Que É um Device Shadow?

Um device shadow é um documento de estado persistente para um único dispositivo, mantido na nuvem. Ele normalmente tem três partes:

• Reported: o último estado que o dispositivo reportou.
• Desired: o estado que uma aplicação quer que o dispositivo tenha.
• Delta: a diferença, sobre a qual o dispositivo deve agir.

As plataformas de IoT em nuvem introduziram os shadows (chamados de device twins em algumas plataformas) para resolver um problema específico: as aplicações precisam ler e alterar o estado do dispositivo mesmo quando ele está em modo de economia de energia ou offline. O shadow está sempre disponível; o dispositivo se sincroniza com ele quando se conecta.

Um shadow é deliberadamente simples. Ele conhece um único dispositivo, guarda o estado atual e um número de versão, e faz pouco além disso.

O Que É um Gêmeo Digital?

Um gêmeo digital é um conceito mais amplo: uma representação virtual ao vivo de um ativo, processo ou sistema físico que combina o estado atual com contexto e comportamento. Além do estado que um shadow guarda, um gêmeo normalmente acrescenta:

• Um modelo: o que o ativo é, suas propriedades, unidades e semântica, muitas vezes expresso em DTDL ou como uma Asset Administration Shell.
• Relacionamentos: esta bomba pertence àquela estação, que abastece aquele reservatório.
• Histórico: séries temporais usadas para tendências, diagnóstico e previsão.
• Análises ou simulação: valores derivados, detecção de anomalias, cenários what-if.
• Visualização: dashboards ou cenas 3D mostrando muitos ativos juntos.

Um gêmeo pode representar coisas que nem são um único dispositivo: uma linha de produção, um andar de edifício, uma planta inteira.

Device Shadow vs Gêmeo Digital: Lado a Lado

A relação é cumulativa: a maioria dos gêmeos digitais contém algo parecido com um shadow para cada dispositivo, enquanto um shadow sozinho não é um gêmeo completo. Nosso artigo sobre gêmeo digital vs sombra digital trata de uma distinção relacionada, mas diferente, da literatura acadêmica, em que sombra digital significa fluxo de dados em mão única do ativo para o modelo.

Quando um Device Shadow Basta

Escolha um shadow quando:

1. Você gerencia muitos dispositivos semelhantes, como tomadas inteligentes, rastreadores ou medidores.
2. A necessidade principal é "mostrar o estado atual e me deixar mudar configurações".
3. Os dispositivos dormem ou se conectam de forma intermitente e precisam se atualizar quanto à configuração.
4. Você não precisa de relacionamentos entre dispositivos nem de análises por cima.

IoT de consumo, configuração de frotas e ajustes remotos são território clássico de shadows.

Quando Você Precisa de um Gêmeo Digital Completo

Escolha um gêmeo quando:

1. O valor vem de ver os ativos em contexto: uma linha, um edifício, uma rede elétrica.
2. Você precisa correlacionar estado com histórico para diagnosticar problemas.
3. Várias fontes de dados descrevem um único ativo (CLP, sensor de vibração, MES).
4. Os usuários querem visões espaciais ou 3D.
5. Você planeja manutenção preditiva ou simulação.

Plantas industriais, sistemas de energia e edifícios, de uma usina hidrelétrica a uma fábrica no Polo Industrial de Manaus, quase sempre acabam aqui. O artigo sobre arquitetura de gêmeo digital mostra as camadas extras de que você vai precisar.

Construindo um Device Shadow Portátil com Topics MQTT Retidos

Serviços de shadow em nuvem ficam presos à sua plataforma. Você pode obter o mesmo comportamento em qualquer broker MQTT que siga o padrão usando retained messages, o que mantém o design portátil. O layout de topics:

connectmq/demo/<id>/shadows/<device>/reported   retained, device writes
connectmq/demo/<id>/shadows/<device>/desired    retained, apps write
connectmq/demo/<id>/shadows/<device>/delta      not retained, computed by a shadow service
connectmq/demo/<id>/shadows/<device>/status     retained, last will

As retained messages entregam de graça a propriedade mais importante de um shadow: quem assinar, quando quer que assine, recebe os documentos reportado e desejado mais recentes. Um pequeno serviço calcula os deltas:

import json
import paho.mqtt.client as mqtt

BASE = "connectmq/demo/4d2a/shadows"
shadows = {}

def on_connect(client, userdata, flags, reason_code, properties):
    client.subscribe(f"{BASE}/+/reported", qos=1)
    client.subscribe(f"{BASE}/+/desired", qos=1)

def on_message(client, userdata, msg):
    _, _, _, _, device, kind = msg.topic.split("/")
    doc = json.loads(msg.payload) if msg.payload else {}
    shadow = shadows.setdefault(device, {"reported": {}, "desired": {}})
    shadow[kind] = doc
    delta = {
        key: value
        for key, value in shadow["desired"].items()
        if key not in ("version", "ts") and shadow["reported"].get(key) != value
    }
    if delta:
        client.publish(f"{BASE}/{device}/delta", json.dumps(delta), qos=1)

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="shadow-service-4d2a")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883)
client.loop_forever()

Teste com o servidor MQTT público (gratuito), que serve para testes e protótipos, não para dados de produção:

mosquitto_pub -h broker.connectmq.com -p 1883 -i lamp1-4d2a -q 1 -r \
  -t "connectmq/demo/4d2a/shadows/lamp1/reported" -m '{"on": false, "brightness": 40}'

mosquitto_pub -h broker.connectmq.com -p 1883 -i app-4d2a -q 1 -r \
  -t "connectmq/demo/4d2a/shadows/lamp1/desired" -m '{"version": 1, "on": true, "brightness": 80}'

mosquitto_sub -h broker.connectmq.com -p 1883 -i watch-4d2a \
  -t "connectmq/demo/4d2a/shadows/lamp1/#" -v

O serviço publica {"on": true, "brightness": 80} no topic de delta. Um dispositivo também pode dispensar o serviço por completo: ele assina seu topic desejado retido e calcula o delta localmente, o que costuma ser mais simples para frotas pequenas. As regras de reconexão e versionamento de sincronização de estado de gêmeo digital se aplicam sem alterações.

Limites do Shadow com Topics Retidos

Seja honesto sobre o que este padrão não oferece. Não há API de consulta ("encontre todas as lâmpadas acesas"), não há controle de acesso por documento além do que as credenciais do seu broker permitem, e as retained messages ficam no broker, não em um banco de dados. Se você precisar disso, acrescente um serviço de gêmeo ou um assinante que grava em banco de dados ao lado do broker. Para muitas frotas, porém, topics retidos bastam e evitam toda uma camada de serviços.

Erros Comuns ao Escolher Entre os Dois

As equipes tendem a cometer um de dois erros opostos. O primeiro é chamar um shadow de gêmeo e depois se surpreender quando as partes interessadas esperam histórico, contexto e análises que um único documento de estado não consegue fornecer. Se o gerente da planta perguntar "por que a linha 3 ficou mais lenta na terça passada?", um shadow não tem resposta.

O segundo erro é começar com uma plataforma de gêmeo pesada quando o requisito real é "deixar o app móvel mudar o setpoint do termostato enquanto o dispositivo dorme". Esse projeto precisa de um shadow, e acrescentar modelagem, bancos de grafos e cenas 3D só atrasa a entrega.

Um teste útil é anotar as três perguntas que os usuários mais querem ver respondidas. Se todas forem sobre o estado atual ou a configuração de um único dispositivo, construa um shadow. Se alguma envolver tempo, relacionamentos entre ativos ou comparação entre comportamento esperado e real, planeje um gêmeo, mas comece mesmo assim pelos topics de estado no estilo shadow descritos acima, porque o gêmeo será construído sobre eles.

Do Shadow ao Gêmeo: Um Caminho Prático

1. Comece com um topic reportado e um desejado, retidos, por dispositivo.
2. Acrescente um topic de status com Last Will para presença.
3. Acrescente um assinante de histórico gravando em um banco de séries temporais.
4. Introduza um modelo de ativos com hierarquia e unidades.
5. Acrescente um dashboard ou uma visão 3D que assine ramos inteiros.
6. Coloque análises sobre o histórico e o estado ao vivo.

Cada passo reutiliza os mesmos topics, então os dispositivos nunca precisam mudar.

Construa Shadows e Gêmeos no ConnectMQ

O ConnectMQ fornece a base de mensageria para os dois: um broker MQTT gerenciado com retained messages, Last Will, MQTT 3.1.1 e 5.0, TLS na porta 8883 e WSS na 8084 para dashboards no navegador. Sua lógica de shadow e seus serviços de gêmeo se conectam como clientes MQTT comuns, então nada fica preso a uma nuvem. Crie um broker Serverless gratuito em app.connectmq.com, sem cartão de crédito, e leve seu primeiro device shadow para ele.

Perguntas frequentes

Um device shadow é um gêmeo digital?

Um device shadow é uma forma simples de estado semelhante ao de um gêmeo para um único dispositivo. Um gêmeo digital acrescenta modelo, relacionamentos, histórico e análises, muitas vezes abrangendo muitos dispositivos.

Posso construir um device shadow sem uma plataforma de IoT em nuvem?

Sim. Topics MQTT retidos para os estados reportado e desejado, mais um serviço de delta opcional, reproduzem o comportamento de um shadow em qualquer broker MQTT que siga o padrão.

Qual é a diferença entre device twin e device shadow?

São essencialmente o mesmo conceito com nomes diferentes conforme a plataforma: um documento na nuvem com propriedades reportadas e desejadas para um único dispositivo.

Preciso de um banco de dados para um device shadow?

Não necessariamente. As retained messages guardam o estado mais recente. Acrescente um banco de dados quando precisar de consultas entre dispositivos, histórico ou trilhas de auditoria.