Alternativas ao Azure Digital Twins: Opções Gerenciadas, Open Source e Baseadas em MQTT

Se você está procurando uma alternativa ao Azure Digital Twins, provavelmente gosta da ideia de um grafo de gêmeos modelado e consultável, mas quer mais portabilidade, uma stack mais simples ou uma implantação que não dependa de uma única nuvem. Este artigo compara as principais famílias de alternativas: outros serviços gerenciados, plataformas de gêmeos open source e stacks do tipo "faça você mesmo" construídas sobre MQTT padrão. Você também verá código funcional de um grafo de gêmeos mínimo alimentado por MQTT, para avaliar por conta própria o caminho DIY.

O conceito de gêmeo digital é novo para você? Nosso guia de tecnologia explica os fundamentos.

O Que o Azure Digital Twins Realmente Oferece

Antes de comparar, vale ser preciso sobre o que você estaria substituindo. O Azure Digital Twins é um serviço de plataforma para modelar ambientes. Seus principais blocos são:

• Modelos DTDL: definições baseadas em JSON-LD de tipos de gêmeos, suas propriedades, telemetria, componentes e relacionamentos.
• Um grafo de gêmeos: instâncias desses modelos conectadas por relacionamentos, como um andar que contém salas que contêm sensores.
• Uma linguagem de consulta para percorrer e filtrar o grafo.
• Rotas de eventos que enviam as mudanças dos gêmeos para outros serviços do Azure para processamento posterior.

Vale notar que ele não é o lugar onde os dados dos dispositivos chegam. As mensagens dos dispositivos normalmente caem primeiro em um serviço de ingestão, e você escreve código de integração, muitas vezes uma função serverless, para atualizar as propriedades dos gêmeos. Você também precisa trazer seu próprio armazenamento para o histórico, sua própria visualização e suas próprias análises. Em outras palavras, ele é uma camada de uma solução de gêmeo, não a solução inteira.

Esse enquadramento importa. A maioria das alternativas substitui a camada de modelagem e de grafo, enquanto as camadas de ingestão, histórico e visualização são necessárias em qualquer arquitetura.

Por Que as Equipes Procuram Alternativas

As motivações que mais ouvimos são práticas, e não ideológicas:

1. Portabilidade. As unidades, como as plantas de um grupo industrial em Campinas, Joinville e Manaus, rodam em nuvens diferentes ou on-premises, e o gêmeo precisa funcionar em todas elas.
2. Protocolos padrão. As equipes querem que dispositivos e gateways falem MQTT puro, em vez de um SDK específico de uma nuvem.
3. Simplicidade. Muitos projetos precisam de estado ao vivo e de uma hierarquia, não de um motor completo de consultas em grafo. Vários serviços gerenciados integrados podem ser pesados demais para isso.
4. Padrões industriais. Fabricantes podem preferir a Asset Administration Shell ou estruturas ISA-95 ao DTDL.
5. Competências e previsibilidade de custos. Equipes pequenas preferem componentes que conseguem operar, inspecionar e entender.

As Alternativas Comparadas

A comparação de ferramentas open source de gêmeo digital aprofunda Ditto, BaSyx e o lado da visualização, e o guia da Asset Administration Shell cobre a modelagem AAS em detalhes.

A Abordagem Nativa em MQTT na Prática

A alternativa mais leve trata a própria hierarquia de tópicos MQTT como a espinha dorsal do gêmeo. Em um Unified Namespace, cada ativo publica seu estado em um tópico que codifica sua posição: site/area/line/cell/asset. A hierarquia oferece relacionamentos de "contém" de graça, as mensagens retidas oferecem o estado atual de graça e os curingas oferecem consultas como "tudo na linha 2".

Depois, você acrescenta apenas o que a hierarquia não consegue expressar: modelos tipados, vínculos cruzados como "a bomba 104 alimenta o tanque 3" e histórico.

Veja um serviço mínimo de grafo de gêmeos em Python. Ele assina um namespace, monta uma árvore de gêmeos a partir dos caminhos dos tópicos, armazena o estado mais recente de cada um e oferece uma consulta simples. Execute-o no servidor MQTT público (gratuito) com um prefixo aleatório seu; ele serve para testes e protótipos, não para dados de produção.

import json
import threading

import paho.mqtt.client as mqtt

ROOT = "connectmq/demo/adt-5m1"
twins = {}  # caminho -> {"state": {...}, "children": set()}
lock = threading.Lock()


def upsert(path, state):
    parts = path.split("/")
    with lock:
        for i in range(1, len(parts) + 1):
            node = "/".join(parts[:i])
            twins.setdefault(node, {"state": {}, "children": set()})
            if i > 1:
                twins["/".join(parts[:i - 1])]["children"].add(node)
        twins[path]["state"].update(state)


def query(prefix, predicate):
    with lock:
        return {p: t["state"] for p, t in twins.items()
                if p.startswith(prefix) and t["state"] and predicate(t["state"])}


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


def on_message(client, userdata, msg):
    path = msg.topic[len(ROOT) + 1:-len("/state")]
    upsert(path, json.loads(msg.payload))


client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="adt-5m1-graph")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883)
client.loop_start()

input("Publish some states, then press Enter to query...\n")
hot = query("site1/assembly", lambda s: s.get("temp_c", 0) > 70)
print(json.dumps(hot, indent=2))
print("Children of site1/assembly:", sorted(twins.get("site1/assembly", {}).get("children", [])))
client.loop_stop()

Alimente-o com alguns estados:

mosquitto_pub -h broker.connectmq.com -p 1883 -i adt-5m1-a -r -q 1 \
  -t "connectmq/demo/adt-5m1/site1/assembly/line2/robot3/state" -m '{"temp_c":74,"mode":"auto"}'
mosquitto_pub -h broker.connectmq.com -p 1883 -i adt-5m1-b -r -q 1 \
  -t "connectmq/demo/adt-5m1/site1/assembly/line2/press1/state" -m '{"temp_c":51,"mode":"auto"}'

Como as duas mensagens são retidas, o serviço de grafo reconstrói o estado atual de cada gêmeo assim que se conecta, sem um banco de dados separado. Esse é o núcleo do que um serviço de grafo de gêmeos faz, em cerca de quarenta linhas. Em produção, você acrescentaria um registro de modelos (arquivos DTDL ou JSON Schema descrevendo cada tipo de ativo), persistiria o histórico em um banco de dados de séries temporais e exporia a consulta por meio de uma API.

Se você já tem modelos DTDL de um projeto no Azure, não precisa jogá-los fora. O DTDL é uma especificação aberta; você pode manter os arquivos de interface como documentação e schemas de validação e mapear a telemetria e as propriedades de cada modelo para tópicos. O guia de DTDL mostra como.

O Que Você Perde e o Que Você Ganha

Seja honesto sobre os prós e contras antes de migrar.

Você perde um motor gerenciado de consultas em grafo, a validação de modelos integrada e a integração com o restante do ecossistema Azure. Se a sua organização roda todo o resto no Azure e precisa de consultas complexas de múltiplos saltos sobre muitas entidades, permanecer pode ser a resposta certa.

Você ganha um gêmeo que funciona em qualquer lugar onde o MQTT funciona, ou seja, praticamente em todo lugar: gateways de CLP, placas ESP32, Node-RED, Python, navegadores via WebSocket. Todos os consumidores leem os mesmos dados ao vivo. A arquitetura é fácil de explicar, e cada camada, do broker ao armazenamento e ao 3D, pode ser trocada de forma independente.

Um caminho intermediário sensato é comum: manter o namespace MQTT como sistema de registro do estado ao vivo e projetá-lo na ferramenta de grafo ou de AAS de que cada aplicação específica precisar.

Checklist de Migração

1. Faça o inventário dos seus modelos DTDL e instâncias de gêmeos e anote quais relacionamentos são hierárquicos e quais são vínculos cruzados.
2. Projete uma hierarquia de tópicos que espelhe os relacionamentos hierárquicos, seguindo os níveis ISA-95 sempre que possível.
3. Aponte os gateways para um broker MQTT e publique o estado como mensagens retidas e a telemetria como não retida.
4. Substitua as rotas de eventos por assinantes MQTT: um gravador de histórico, um serviço de alertas, um visualizador 3D.
5. Armazene os vínculos cruzados e os metadados dos modelos em um pequeno serviço de registro ou em um repositório de configuração.
6. Rode os caminhos antigo e novo em paralelo por algumas semanas e compare os estados antes de migrar os consumidores.

Escolhendo o Broker

Em um gêmeo nativo em MQTT, o broker é o único componente do qual tudo depende, então ele não deve ser um servidor amador debaixo da mesa de alguém. Um broker MQTT gerenciado oferece endpoints TLS, autenticação e capacidade sem que você precise operar a infraestrutura.

A ConnectMQ suporta MQTT 3.1.1 e 5.0, TCP e TLS para gateways, WebSocket e WebSocket seguro para gêmeos no navegador, e detecta tópicos ISA-95 e Unified Namespace no portal, mostrando os dispositivos por nível hierárquico. Ela não tenta ser uma plataforma de gêmeos em si; você conecta seu serviço de grafo, seu historiador e seus visualizadores como clientes MQTT comuns, o que mantém a arquitetura portável. Se você precisa do broker dentro da sua própria conta de nuvem, o plano BYOC o executa lá, gerenciado pela ConnectMQ.

Construa um Gêmeo Portável na ConnectMQ

Comece pelo namespace: publique o estado retido de alguns ativos e conecte um visualizador e um serviço de grafo. Crie um broker Serverless gratuito da ConnectMQ, sem cartão de crédito, e você terá em minutos uma base portável para o seu gêmeo.

Perguntas frequentes

Qual é a melhor alternativa ao Azure Digital Twins?

Depende do que você precisa. O Eclipse Ditto atende gêmeos centrados em dispositivos com APIs, o Eclipse BaSyx atende projetos de Asset Administration Shell e uma stack nativa em MQTT atende equipes que querem estado ao vivo portável com o mínimo de infraestrutura.

Posso reutilizar meus modelos DTDL em outro lugar?

Sim. O DTDL é uma especificação aberta, então os arquivos continuam úteis como schemas e documentação. Você pode mapear telemetria e propriedades para tópicos MQTT e validar os payloads com base neles.

Preciso de um banco de dados de grafos para um gêmeo digital?

Nem sempre. Uma hierarquia de tópicos cobre os relacionamentos de contenção, e as mensagens retidas cobrem o estado atual. Adicione um armazenamento em grafo apenas quando precisar de consultas complexas entre muitas entidades com vínculos cruzados.

O MQTT é suficiente para um gêmeo em produção?

O MQTT cuida da distribuição de dados ao vivo. Um gêmeo em produção também precisa de armazenamento de histórico, de um registro de modelos e de visualização, que se conectam ao broker como clientes MQTT.