La latencia de un gemelo digital en tiempo real decide si el gemelo se percibe vivo o lento, y si puede hacer con seguridad algo más que observar. Este artículo explica presupuestos de latencia realistas para gemelos de visualización, monitorización y control, desglosa en qué se van realmente los milisegundos, muestra cómo afectan al retardo el QoS de MQTT y la ubicación del broker, y te ofrece un script para medir la latencia de extremo a extremo en tu propia instalación.
Para una introducción general a los gemelos, lee la guía de tecnología de gemelo digital.
"Tiempo real" significa cosas distintas según el gemelo
No existe un único requisito de latencia para los gemelos digitales. El objetivo adecuado depende de para qué sirve el gemelo:
| Finalidad del gemelo | Qué importa | Latencia de extremo a extremo aceptable típica |
|---|---|---|
| Visualización 3D o animada | El movimiento parece continuo y acompasado con la realidad | Bastante menos de un segundo; unos cientos de ms ya parecen en vivo |
| Paneles de monitorización operativa | Los operarios ven los cambios con rapidez | De un segundo a unos pocos segundos |
| Alarmas y notificaciones | Los fallos aparecen antes de que alguien se acerque a la máquina | Segundos |
| Control supervisor (consignas, arranque/parada) | Las órdenes del operario se aplican rápido y se confirman | De menos de un segundo a un par de segundos, con confirmación |
| Control en lazo cerrado o de seguridad | Respuesta determinista | Milisegundos, gestionado localmente, no a través de un gemelo en la nube |
Son rangos de ingeniería cualitativos, no normas. La lección importante está en la última fila: las funciones de lazo cerrado y de seguridad pertenecen a los PLC y a los controladores locales. Un gemelo conectado a la nube puede supervisar, aconsejar y ajustar consignas, pero nunca debe ser lo único que separe a una máquina de un estado inseguro.
De dónde viene la latencia del gemelo digital en tiempo real
La latencia de extremo a extremo es la suma de todas las etapas entre un cambio físico y el píxel o la acción que lo refleja:
- Detección y muestreo: un valor muestreado cada 500 ms añade hasta 500 ms antes de que nadie sepa que ha cambiado.
- Procesamiento en el edge: ciclos de scan del PLC, intervalos de sondeo del gateway y agrupación por lotes.
- Búfer de publicación: algunos clientes agrupan escrituras; las bandas muertas retrasan los cambios pequeños por diseño.
- Enlace de subida: red de planta, ruta por internet, enlaces celulares o por satélite.
- Procesamiento en el broker: la autenticación se hace al conectar; enrutar una publicación a los suscriptores suele ser una parte pequeña del total en un broker bien gestionado.
- Enlace de bajada: del broker al visor o consumidor.
- Aplicación y renderizado: parseo, actualizaciones de estado y el siguiente fotograma.
En la práctica, dominan los intervalos de muestreo y sondeo en el edge y la distancia de red. Es habitual que los equipos optimicen el broker mientras un gateway consulta el PLC una vez por segundo, lo que limita la capacidad de respuesta pase lo que pase aguas abajo.
Cómo afectan los ajustes de MQTT a la latencia
Niveles de QoS
- QoS 0 envía el mensaje una vez y sin confirmación. Es la opción de menor sobrecarga y la habitual para telemetría de visualización de alta frecuencia, donde la siguiente muestra sustituye a la que se pierda.
- QoS 1 exige un PUBACK. La entrega a los suscriptores no se retrasa por la propia confirmación, pero las retransmisiones tras una pérdida añaden retardo y los límites de mensajes en vuelo pueden frenar las ráfagas.
- QoS 2 añade un intercambio de cuatro pasos por mensaje. Úsalo solo cuando la semántica de entrega exactamente una vez sea realmente necesaria, algo poco frecuente con datos de gemelos.
El artículo niveles de QoS de MQTT explicados cubre el funcionamiento.
Conexiones y sesiones
Mantén las conexiones persistentes. Reconectar en cada publicación añade los handshakes de TCP y TLS, que pueden costar más que todo lo demás junto. Configura el keepalive para que las conexiones caídas se detecten pronto y usa un last will para que los visores sepan cuándo se desconecta un dispositivo en lugar de fiarse de valores obsoletos.
Tamaño del payload y del topic
Los payloads pequeños se serializan y transmiten más rápido, sobre todo en enlaces limitados. Los topic aliases de MQTT 5 sustituyen las cadenas de topic largas por enteros cortos después del primer mensaje, lo que ayuda con rutas de topic ISA-95 profundas en enlaces de subida lentos. Consulta funcionalidades de MQTT 5.
Retained messages para la latencia percibida
El estado retenido no acelera las actualizaciones, pero elimina el peor retardo percibido: la espera tras abrir un gemelo hasta que todos los activos han publicado al menos una vez. Con estado retenido, la escena completa aparece en cuanto te suscribes. El tutorial gemelo digital con retained MQTT muestra cómo hacerlo.
Ubicación del broker y distancia de red
Cada salto de red añade retardo, y la distancia física añade un tiempo de ida y vuelta que ningún software puede eliminar. Recomendaciones prácticas:
- Sitúa el broker cerca, en términos de red, de donde están la mayoría de publicadores y consumidores.
- Si los dispositivos están en una planta y los visores repartidos por el mundo, prioriza el lado de los dispositivos en los gemelos de control y acepta un retardo extra para los visores en la visualización.
- Para requisitos estrictos, plantéate un broker dentro de tu propia cuenta o región en la nube. ConnectMQ, como broker MQTT gestionado, ofrece clústeres Dedicated y despliegues BYOC en tu cuenta en la nube, operados por ConnectMQ, para los equipos que necesitan controlar dónde se ejecuta el broker.
- Evita el hairpinning: un visor en planta no debería pasar por una región lejana para ver una máquina a tres metros si la latencia local importa; en ese caso usa una pantalla local alimentada desde el edge.
Medir la latencia de extremo a extremo
Mide antes de optimizar. Este script de Python publica mensajes con marca de tiempo y se suscribe al mismo topic, informando de la latencia de ida y vuelta a través del broker. Como la misma máquina envía y recibe, la desviación de relojes no afecta al resultado.
import json
import statistics
import time
import uuid
import paho.mqtt.client as mqtt
TOPIC = f"connectmq/demo/{uuid.uuid4().hex[:8]}/latency"
SAMPLES = 50
results = []
def on_connect(client, userdata, flags, reason_code, properties):
client.subscribe(TOPIC, qos=0)
def on_message(client, userdata, msg):
sent = json.loads(msg.payload)["t"]
results.append((time.perf_counter() - sent) * 1000)
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=f"latency-{uuid.uuid4().hex[:8]}")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883)
client.loop_start()
time.sleep(1)
for _ in range(SAMPLES):
client.publish(TOPIC, json.dumps({"t": time.perf_counter()}), qos=0)
time.sleep(0.2)
time.sleep(1)
client.loop_stop()
client.disconnect()
if results:
results.sort()
print(f"samples: {len(results)}")
print(f"median: {statistics.median(results):.1f} ms")
print(f"p95: {results[int(len(results) * 0.95) - 1]:.1f} ms")
print(f"max: {results[-1]:.1f} ms")
El script envía cinco mensajes por segundo, dentro del límite de 10 mensajes por segundo por cliente del servidor MQTT público gratuito, que sirve para pruebas y no para datos de producción. Ejecútalo desde las redes que usan realmente tus dispositivos y visores, a distintas horas del día, y compara QoS 0 con QoS 1. Informa de percentiles, no solo de medias: un gemelo rápido de media pero que se atasca en el percentil 99 sigue pareciendo poco fiable.
Para medir la verdadera latencia en un sentido, del dispositivo al visor, incluye la marca de tiempo de origen en cada payload de telemetría, sincroniza los relojes con NTP y calcula la diferencia en el visor. Muestra la antigüedad de cada valor en la interfaz; es el indicador de latencia más honesto que puede tener un operario.
Lista de comprobación para optimizar la latencia
- Define el presupuesto de latencia según la finalidad de cada gemelo antes de elegir tecnología.
- Acorta los intervalos de sondeo y muestreo en el edge para las señales que alimentan visualizaciones o control.
- Usa QoS 0 para telemetría de alta frecuencia y QoS 1 para cambios de estado y comandos.
- Mantén las conexiones MQTT persistentes; evita los patrones de conexión por mensaje.
- Ajusta con sensatez las sesiones TLS y el keepalive para que las reconexiones sean raras.
- Retén el estado actual para que los visores rendericen al instante al cargar.
- Desacopla el manejo de mensajes del renderizado e interpola entre muestras.
- Mide percentiles en redes reales y muestra la antigüedad de los valores en el gemelo.
- Mantén el control de seguridad y en lazo cerrado en local, nunca dependiente de la ruta a la nube.
Cómo encaja ConnectMQ en tu presupuesto de latencia
ConnectMQ ofrece un broker MQTT en la nube con conexiones persistentes MQTT 3.1.1 y 5.0 sobre TCP, TLS, WebSocket y WebSocket seguro, de modo que los dispositivos y los gemelos en el navegador comparten una misma ruta de baja sobrecarga. Los retained messages permiten cargas de escena instantáneas, los topic aliases de MQTT 5 reducen la sobrecarga en árboles de topics profundos y los despliegues Dedicated o BYOC te permiten elegir dónde se ejecuta el broker. Nuestra demo de gemelo digital 3D anima una fábrica en vivo sobre WSS usando exactamente estos patrones. Para entender qué hace un broker MQTT en esta ruta, consulta nuestra introducción; para patrones de datos de gemelos, lee gemelo digital con MQTT y arquitectura de gemelo digital.
Mide la latencia de tu gemelo en ConnectMQ
Ejecuta el script anterior contra el servidor público y repítelo después contra tu propio broker. Crea uno gratis en el plan Serverless en app.connectmq.com, sin tarjeta de crédito, cambia al puerto 8883 con las credenciales generadas y compara las cifras desde las redes reales de tus dispositivos.
Preguntas frecuentes
¿Qué latencia necesita un gemelo digital en tiempo real?
Depende de su finalidad: la visualización parece en vivo con unos cientos de milisegundos, la monitorización tolera alrededor de un segundo o más, y el control en lazo cerrado necesita respuestas de milisegundos que corresponden a controladores locales, no a gemelos en la nube.
¿QoS 1 de MQTT añade mucha latencia?
Normalmente poca en condiciones normales, porque los mensajes se reenvían antes de que se complete la confirmación. Los retardos aparecen sobre todo cuando se pierden paquetes y se retransmiten o cuando se alcanzan los límites de mensajes en vuelo.
¿Cuál es la mayor fuente de latencia de un gemelo digital?
A menudo los intervalos de muestreo y sondeo en el edge más la distancia de red, no el broker. Mide cada etapa antes de optimizar.
¿Cómo puedo mostrar la latencia a los operarios?
Incluye una marca de tiempo de origen en cada mensaje y muestra la antigüedad de cada valor en el gemelo, resaltando los valores más antiguos de lo esperado.
