Una arquitectura de gemelo digital clara es lo que separa un gemelo que escala a cientos de activos de una demo que se hunde a partir del quinto. Esta guía recorre una arquitectura de referencia capa por capa, desde los sensores y los gateways edge, pasando por una columna vertebral de mensajería, hasta los almacenes de estado, los modelos y la visualización 3D, para que puedas diseñar un stack en el que cada pieza tenga una sola tarea y pueda sustituirse de forma independiente.
Para los conceptos que hay detrás de los gemelos, consulta nuestra guía de tecnología de gemelo digital.
Las seis capas de una arquitectura de gemelo digital
La mayoría de los gemelos que funcionan, sea cual sea el fabricante o el framework que usen, acaban teniendo estas capas:
| Capa | Responsabilidad | Tecnología típica |
|---|---|---|
| 1. Dispositivo y edge | Leer sensores y controladores, normalizar, almacenar en búfer | PLC, ESP32, Raspberry Pi, gateways edge |
| 2. Mensajería | Mover datos y comandos en tiempo real, desacoplar productores y consumidores | Broker MQTT |
| 3. Estado | Guardar el valor actual de cada propiedad | Topics retenidos, almacén clave-valor, servicio de gemelos |
| 4. Histórico | Almacenar series temporales para tendencias y analítica | Base de datos de series temporales |
| 5. Modelo | Describir activos, relaciones, unidades y comportamiento | Jerarquía de activos, DTDL, AAS, modelos físicos o de ML |
| 6. Visualización y aplicaciones | Mostrar el gemelo y actuar sobre él | Dashboards, visores 3D web, apps móviles |
La regla de diseño clave: las capas se comunican entre sí mediante contratos bien definidos (topics y esquemas de payload), nunca mediante atajos privados. Eso es lo que te permite cambiar un dashboard por un visor 3D o añadir un proceso de analítica sin tocar el firmware de los dispositivos.
Capa 1: dispositivo y edge
Los activos físicos rara vez hablan un idioma cómodo para un gemelo. Un controlador CNC expone OPC UA o un protocolo del fabricante; una bomba antigua tiene una señal de 4–20 mA hacia un PLC; un sensor nuevo puede funcionar sobre un ESP32. La capa edge salva esa distancia.
Responsabilidades en el edge:
- Traducción de protocolos de Modbus, OPC UA o bus de campo a MQTT.
- Normalización a unidades y nombres coherentes, para que
spindle_rpmsignifique lo mismo en todas partes. - Banda muerta y control de frecuencia, publicando un valor solo cuando cambia de forma significativa o a un intervalo fijo.
- Búfer cuando cae el enlace, para después reenviar los datos con sus marcas de tiempo originales.
Pon las marcas de tiempo en origen. Un gemelo que solo sabe cuándo recibió el broker un valor no puede distinguir una red lenta de una máquina lenta.
Capa 2: la columna vertebral de mensajería
La capa de mensajería es la columna vertebral de la arquitectura de gemelo digital. Todos los productores publican en ella y todos los consumidores se suscriben a ella, lo que significa que los dispositivos nunca necesitan saber quién está mirando. Un broker MQTT es la opción más habitual porque te ofrece:
- Topics jerárquicos que reflejan la jerarquía de activos.
- Comodines, para que un visor de nivel de línea se suscriba a
plant1/line2/#y reciba todas las máquinas. - Retained messages que entregan al instante el último estado a los nuevos suscriptores.
- Niveles de QoS para equilibrar garantías de entrega y sobrecarga.
- Mensajes Last Will para que el gemelo sepa cuándo desaparece un dispositivo.
Un buen diseño de topics sigue una jerarquía al estilo ISA-95 que termina en una clase de mensaje:
<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
Separa telemetry (un flujo, no retenido), state (valores actuales, retenido) y cmd (comandos, nunca retenidos). Mezclarlos es la fuente más común de errores en los gemelos, como un comando obsoleto que se vuelve a enviar a un dispositivo tras reconectarse. Nuestra guía de gemelo digital con MQTT profundiza en estos patrones.
Gestionar tú mismo el broker implica ocuparte de los certificados TLS, la autenticación, el escalado y la monitorización. Un broker MQTT gestionado como ConnectMQ elimina ese trabajo para que el equipo pueda centrarse en el gemelo en sí.
Capa 3: estado
La capa de estado responde a una sola pregunta: ¿cuál es ahora mismo el valor actual del activo? Hay tres opciones habituales:
- Topics MQTT retenidos. Cada activo o propiedad tiene un retained message. Sencillo, sin infraestructura adicional, y los visores reciben el estado completo al conectarse. Se detalla en usar retained messages de MQTT como estado del gemelo digital.
- Un servicio de gemelos. Un servicio dedicado, como Eclipse Ditto o un microservicio propio, se suscribe a la telemetría y mantiene un documento JSON por activo que expone mediante una API.
- Un almacén en memoria o clave-valor alimentado por un suscriptor, útil cuando muchas aplicaciones consultan el estado por API en lugar de por MQTT.
Para muchos equipos la respuesta correcta es empezar con topics retenidos y pasar a un servicio de gemelos cuando se necesiten consultas, control de acceso por activo o gestión de estado deseado frente a estado reportado. Consulta sincronización de estado del gemelo digital para esos patrones.
Capa 4: histórico
El estado en vivo no basta para tendencias, análisis de causa raíz o machine learning. Un suscriptor de histórico escucha los topics de telemetría y escribe en una base de datos de series temporales. Herramientas como Telegraf, Node-RED o un pequeño servicio en Python actúan para ello como clientes MQTT normales:
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]
# Sustitúyelo por una escritura en tu base de datos de series temporales
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()
Mantén los escritores de histórico independientes de la ruta en vivo. Si la base de datos va lenta, la vista 3D no debería sufrir retrasos.
Capa 5: el modelo
La capa de modelo convierte números en significado. Como mínimo es un registro de activos: qué activos existen, cómo se relacionan (la planta de Querétaro contiene la línea de envasado, que contiene la máquina), qué propiedades tiene cada uno y en qué unidades. Los gemelos más avanzados añaden:
- Esquemas formales como interfaces DTDL o submodelos de Asset Administration Shell.
- Valores derivados como el OEE, la eficiencia o la vida útil restante.
- Modelos de simulación o de ML que predicen el comportamiento y lo comparan con la realidad.
Guarda el modelo separado del flujo de datos, versiónalo y referéncialo desde los topics mediante IDs de activo estables. Cuando se sustituye una máquina, el modelo cambia, pero el contrato de topics puede mantenerse igual.
Capa 6: visualización y aplicaciones
La capa superior es lo que ve la gente: dashboards, escenas 3D, apps móviles y consolas de alertas. Los visores de gemelo digital 3D en el navegador se conectan directamente al broker por WebSocket seguro, se suscriben a la rama correspondiente, cargan el estado retenido al conectarse y después animan la escena a medida que llegan los mensajes en vivo. Con MQTT.js son unas pocas líneas:
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);
}
El ejemplo apunta al servidor MQTT público gratuito de ConnectMQ, válido para pruebas y prototipos, nunca para datos de producción. En producción, usa credenciales limitadas a visores de solo lectura y mantén la publicación de comandos detrás de un backend que valide las peticiones.
Checklist de arquitectura de gemelo digital
Antes de construir, confirma cada punto:
- Jerarquía de topics definida y documentada, con clases separadas para telemetría, estado y comandos.
- Esquema de payload por tipo de activo, con unidades y marcas de tiempo de origen.
- Estado retenido para cada propiedad que un visor necesite al cargar.
- Mensajes Last Will para que los activos desconectados aparezcan como desconectados.
- Escritor de histórico desacoplado de la ruta en vivo.
- Modelo de activos versionado e identificado por IDs estables.
- TLS en todo lo que esté fuera de la red de planta, credenciales únicas por dispositivo o gateway.
- Ruta de comandos con confirmaciones y timeouts.
Dónde encaja ConnectMQ en la arquitectura
ConnectMQ cubre la capa de mensajería: un broker MQTT en la nube con MQTT 3.1.1 y 5.0, TLS en el 8883, WebSocket seguro en el 8084 para visores en el navegador, retained messages y, en los planes de pago, suscripciones compartidas para escalar consumidores. También detecta jerarquías de topics ISA-95 y puede decodificar Sparkplug B y republicarlo en topics ISA-95, lo que simplifica el contrato entre el edge y el gemelo. Los almacenes de estado, las bases de datos de histórico y los servicios de modelo siguen siendo componentes tuyos que se conectan como clientes MQTT. La demo de gemelo digital 3D de ConnectMQ muestra la capa de visualización de esta arquitectura funcionando en vivo sobre WSS.
Empieza tu arquitectura de gemelo digital en ConnectMQ
Regístrate en app.connectmq.com, elige el plan Serverless gratuito sin tarjeta de crédito, crea un broker y usa las credenciales generadas para conectar tu gateway edge y tu primer visor. El cliente en el navegador y el explorador de topics en vivo te permiten validar tu diseño de topics antes de escribir una sola línea de código de visualización.
Preguntas frecuentes
¿Cuál es la capa más importante de una arquitectura de gemelo digital?
La capa de mensajería y contrato de datos. Si los topics y los payloads están bien diseñados, todas las demás capas pueden construirse, sustituirse o escalarse de forma independiente.
¿Necesito una base de datos aparte para el estado del gemelo?
Al principio no. Los retained messages de MQTT pueden guardar el estado actual de muchos gemelos; añade un servicio o almacén de gemelos cuando necesites consultas, control de acceso por activo o gestión del estado deseado.
¿Deben los visores 3D conectarse directamente al broker MQTT?
Para vistas en vivo de solo lectura, conectarse por WebSocket seguro es sencillo y rápido. Enruta los comandos a través de un backend que los valide y audite.
¿Cómo gestiona una arquitectura de gemelo digital los dispositivos desconectados?
Usa mensajes Last Will de MQTT para publicar un estado de desconexión, almacena datos en búfer en el edge durante las caídas e incluye marcas de tiempo de origen para que los datos que llegan tarde se sitúen correctamente.
