Alternativas a Azure Digital Twins: opciones gestionadas, de código abierto y basadas en MQTT

Si buscas una alternativa a Azure Digital Twins, probablemente te gusta la idea de un grafo de gemelos modelado y consultable, pero quieres más portabilidad, un stack más sencillo o un despliegue que no dependa de una sola nube. Este artículo compara las principales familias de alternativas: otros servicios gestionados, plataformas de gemelos de código abierto y stacks propios construidos sobre MQTT estándar. También verás código funcional de un grafo de gemelos mínimo alimentado por MQTT para que puedas valorar tú mismo la vía de construirlo por tu cuenta.

¿El concepto es nuevo para ti? La guía de tecnología de gemelo digital explica los fundamentos.

Qué ofrece realmente Azure Digital Twins

Antes de comparar, conviene precisar qué es lo que estarías sustituyendo. Azure Digital Twins es un servicio de plataforma para modelar entornos. Sus principales piezas son:

• Modelos DTDL: definiciones basadas en JSON-LD de los tipos de gemelo, sus propiedades, telemetría, componentes y relaciones.
• Un grafo de gemelos: instancias de esos modelos conectadas por relaciones, como una planta de un edificio que contiene salas que contienen sensores.
• Un lenguaje de consulta para recorrer y filtrar el grafo.
• Rutas de eventos que envían los cambios de los gemelos a otros servicios de Azure para su procesamiento posterior.

Cabe destacar que no es el lugar al que llegan los datos de los dispositivos. Los mensajes de los dispositivos suelen llegar primero a un servicio de ingesta, y tú escribes el código de unión, a menudo una función serverless, para actualizar las propiedades de los gemelos. También aportas tu propio almacenamiento para el historial, tu propia visualización y tu propia analítica. Dicho de otro modo, es una capa de una solución de gemelo, no la solución completa.

Ese enfoque importa. La mayoría de las alternativas sustituyen la capa de modelado y grafo, mientras que las capas de ingesta, historial y visualización son necesarias en cualquier arquitectura.

Por qué los equipos buscan alternativas

Las motivaciones que más oímos son prácticas, no ideológicas:

1. Portabilidad. Las plantas funcionan en nubes distintas o en local, y el gemelo debe funcionar en todas ellas.
2. Protocolos estándar. Los equipos quieren que dispositivos y gateways hablen MQTT puro en lugar de un SDK específico de una nube.
3. Sencillez. Muchos proyectos necesitan estado en vivo y una jerarquía, no un motor completo de consultas de grafos. Varios servicios gestionados encadenados pueden resultar pesados para eso.
4. Estándares industriales. Los fabricantes pueden preferir la Asset Administration Shell o las estructuras ISA-95 antes que DTDL.
5. Competencias y previsibilidad de costes. Los equipos pequeños prefieren componentes que puedan ejecutar, inspeccionar y entender.

Comparativa de alternativas

La comparativa de herramientas de gemelo digital de código abierto profundiza en Ditto, BaSyx y la parte de visualización, y la guía de la Asset Administration Shell cubre en detalle el modelado AAS.

El enfoque nativo MQTT en la práctica

La alternativa más ligera trata la propia jerarquía de topics MQTT como columna vertebral del gemelo. En un Unified Namespace, cada activo publica su estado en un topic que codifica su posición: site/area/line/cell/asset. La jerarquía te da gratis las relaciones de "contiene", los retained messages te dan gratis el estado actual y los comodines te dan consultas como "todo lo de la línea 2".

Después solo añades lo que la jerarquía no puede expresar: modelos tipados, vínculos cruzados como "la bomba 104 alimenta el tanque 3" e historial.

Este es un servicio mínimo de grafo de gemelos en Python. Se suscribe a un espacio de nombres, construye un árbol de gemelos a partir de las rutas de los topics, guarda el último estado de cada uno y admite una consulta sencilla. Ejecútalo contra el servidor MQTT público gratuito de broker.connectmq.com con tu propio prefijo aleatorio; recuerda que es solo para pruebas y prototipos, no para datos de producción.

import json
import threading

import paho.mqtt.client as mqtt

ROOT = "connectmq/demo/adt-5m1"
twins = {}  # ruta -> {"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()

Aliméntalo con algunos 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 ambos mensajes son retenidos, el servicio de grafo reconstruye el estado actual de cada gemelo en cuanto se conecta, sin una base de datos aparte. Eso es el núcleo de lo que hace un servicio de grafo de gemelos, en unas cuarenta líneas. Para producción añadirías un registro de modelos (archivos DTDL o JSON Schema que describan cada tipo de activo), guardarías el historial en una base de datos de series temporales y expondrías la consulta mediante una API.

Si ya tienes modelos DTDL de un proyecto en Azure, no tienes por qué tirarlos. DTDL es una especificación abierta; puedes conservar los archivos de interfaz como documentación y esquemas de validación, y asignar la telemetría y las propiedades de cada modelo a topics. La guía de DTDL muestra cómo.

Qué pierdes y qué ganas

Sé honesto con los compromisos antes de cambiar.

Pierdes un motor de consultas de grafos gestionado, la validación de modelos integrada y la integración con el resto del ecosistema de Azure. Si tu organización lo ejecuta todo en Azure y necesita consultas complejas de varios saltos sobre muchas entidades, quedarte puede ser la respuesta correcta.

Ganas un gemelo que funciona en cualquier sitio donde funcione MQTT, que en la práctica es en todas partes: gateways de PLC, placas ESP32, Node-RED, Python, navegadores a través de WebSocket. Todos los consumidores leen los mismos datos en vivo. La arquitectura es fácil de explicar, y cada capa, desde el broker hasta el almacenamiento y el 3D, puede sustituirse de forma independiente.

Es habitual un término medio sensato: mantener el espacio de nombres MQTT como sistema de registro del estado en vivo y proyectarlo en la herramienta de grafo o AAS que necesite cada aplicación concreta.

Lista de comprobación para la migración

1. Inventaría tus modelos DTDL y las instancias de gemelos, y anota qué relaciones son jerárquicas y cuáles son vínculos cruzados.
2. Diseña una jerarquía de topics que refleje las relaciones jerárquicas, siguiendo los niveles ISA-95 siempre que sea posible.
3. Apunta los gateways a un broker MQTT y publica el estado como retained messages y la telemetría como mensajes no retenidos.
4. Sustituye las rutas de eventos por suscriptores MQTT: un escritor del historiador, un servicio de alertas, un visor de gemelo digital 3D.
5. Guarda los vínculos cruzados y los metadatos de los modelos en un pequeño servicio de registro o en un repositorio de configuración.
6. Ejecuta en paralelo la ruta antigua y la nueva durante unas semanas y compara el estado antes de pasar los consumidores.

Elegir el broker

En un gemelo nativo MQTT, el broker es el único componente del que depende todo, así que no debería ser un servidor de aficionado debajo de la mesa de alguien. Un broker MQTT gestionado te da endpoints TLS, autenticación y capacidad sin tener que operar la infraestructura.

ConnectMQ admite MQTT 3.1.1 y 5.0, TCP y TLS para los gateways, WebSocket y WebSocket seguro para los gemelos en el navegador, y detecta en su portal topics ISA-95 y Unified Namespace, mostrando los dispositivos por nivel jerárquico. No intenta ser una plataforma de gemelos en sí; conectas tu servicio de grafo, tu historiador y tus visores como clientes MQTT normales, lo que mantiene portable la arquitectura. Si necesitas el broker dentro de tu propia cuenta en la nube, el plan BYOC lo ejecuta allí, gestionado por ConnectMQ.

Construye un gemelo portable en ConnectMQ

Empieza por el espacio de nombres: publica el estado retenido de unos cuantos activos y conecta un visor y un servicio de grafo. Crea un broker Serverless gratuito de ConnectMQ, sin tarjeta de crédito, y tendrás en minutos una base portable para tu gemelo.

Preguntas frecuentes

¿Cuál es la mejor alternativa a Azure Digital Twins?

Depende de lo que necesites. Eclipse Ditto encaja con gemelos centrados en dispositivos con API, Eclipse BaSyx con proyectos de Asset Administration Shell y un stack nativo MQTT con equipos que quieren estado en vivo portable con una infraestructura mínima.

¿Puedo reutilizar mis modelos DTDL en otro sitio?

Sí. DTDL es una especificación abierta, así que los archivos siguen siendo útiles como esquemas y documentación. Puedes asignar la telemetría y las propiedades a topics MQTT y validar los payloads contra ellos.

¿Necesito una base de datos de grafos para un gemelo digital?

No siempre. Una jerarquía de topics cubre las relaciones de pertenencia, y los retained messages cubren el estado actual. Añade un almacén de grafos solo cuando necesites consultas complejas entre muchas entidades con vínculos cruzados.

¿Basta MQTT para un gemelo en producción?

MQTT se encarga de la distribución de datos en vivo. Un gemelo en producción también necesita almacenamiento del historial, un registro de modelos y visualización, que se conectan al broker como clientes MQTT.