La latence d'un jumeau numérique temps réel détermine s'il paraît vivant ou à la traîne, et s'il peut sans danger faire plus qu'observer. Cet article présente des budgets de latence réalistes pour les jumeaux de visualisation, de supervision et de contrôle, détaille où passent réellement les millisecondes, montre comment la QoS MQTT et l'emplacement du broker influent sur le délai, et vous fournit un script pour mesurer la latence de bout en bout sur votre propre installation.
Pour les bases sur les jumeaux en général, lisez le guide de la technologie du jumeau numérique.
« Temps réel » ne signifie pas la même chose pour tous les jumeaux
Il n'existe pas d'exigence de latence unique pour les jumeaux numériques. La bonne cible dépend de la fonction du jumeau :
| Fonction du jumeau | Ce qui compte | Latence de bout en bout généralement acceptable |
|---|---|---|
| Visualisation 3D ou animée | Le mouvement paraît continu et synchronisé avec la réalité | Bien moins d'une seconde ; quelques centaines de ms donnent une impression de direct |
| Tableaux de bord de supervision opérationnelle | Les opérateurs voient les changements rapidement | Environ une seconde à quelques secondes |
| Alarmes et notifications | Les défauts remontent avant que quelqu'un ne se déplace | Quelques secondes |
| Contrôle de supervision (consignes, marche/arrêt) | Les commandes de l'opérateur prennent effet rapidement et sont confirmées | Moins d'une seconde à deux secondes, avec acquittement |
| Contrôle en boucle fermée ou de sécurité | Réponse déterministe | Millisecondes, traité localement, pas via un jumeau cloud |
Il s'agit de plages d'ingénierie qualitatives, pas de normes. La leçon importante se trouve dans la dernière ligne : les fonctions en boucle fermée et de sécurité relèvent des automates et des contrôleurs locaux. Un jumeau connecté au cloud peut superviser, conseiller et ajuster des consignes, mais il ne doit jamais être le seul rempart entre une machine et un état dangereux.
D'où vient la latence d'un jumeau numérique temps réel
La latence de bout en bout est la somme de toutes les étapes entre un changement physique et le pixel ou l'action qui le reflète :
- Mesure et échantillonnage : une valeur échantillonnée toutes les 500 ms ajoute jusqu'à 500 ms avant que quiconque sache qu'elle a changé.
- Traitement edge : cycles de scrutation des automates, intervalles d'interrogation des passerelles et regroupement.
- Mise en tampon à la publication : certains clients regroupent les écritures ; les bandes mortes retardent volontairement les petites variations.
- Liaison montante réseau : réseau de l'usine, chemin Internet, liaisons cellulaires ou satellite.
- Traitement par le broker : l'authentification a lieu à la connexion ; le routage d'une publication vers les abonnés ne représente généralement qu'une faible part du total sur un broker bien exploité.
- Liaison descendante réseau : du broker vers l'afficheur ou le consommateur.
- Application et rendu : analyse, mise à jour de l'état et image de rendu suivante.
En pratique, ce sont les intervalles d'échantillonnage et d'interrogation côté edge et la distance réseau qui dominent. Les équipes optimisent souvent le broker alors qu'une passerelle interroge l'automate une fois par seconde, ce qui plafonne la réactivité quoi qu'il se passe en aval.
Comment les paramètres MQTT influent sur la latence
Niveaux de QoS
- QoS 0 envoie le message une seule fois, sans acquittement. C'est le surcoût le plus faible et le choix habituel pour la télémétrie de visualisation à haute fréquence, où l'échantillon suivant remplace celui qui est perdu.
- QoS 1 exige un PUBACK. La remise aux abonnés n'est pas retardée par l'acquittement lui-même, mais les retransmissions après une perte ajoutent du délai, et les limites de messages en vol peuvent freiner les rafales.
- QoS 2 ajoute une poignée de main en quatre étapes par message. Ne l'utilisez que lorsqu'une sémantique « exactement une fois » est vraiment nécessaire, ce qui est rare pour les données d'un jumeau.
L'article les niveaux de QoS MQTT expliqués en détaille le fonctionnement.
Connexions et sessions
Gardez les connexions persistantes. Se reconnecter à chaque publication ajoute les poignées de main TCP et TLS, qui peuvent coûter plus que tout le reste réuni. Réglez le keepalive pour détecter rapidement les connexions mortes, et utilisez un last will pour que les afficheurs voient quand un appareil décroche au lieu de se fier à des valeurs périmées.
Taille du payload et du topic
Les petits payloads se sérialisent et se transmettent plus vite, surtout sur des liaisons contraintes. Les alias de topic de MQTT 5 remplacent les longues chaînes de topic par de courts entiers après le premier message, ce qui aide pour les chemins de topic ISA-95 profonds sur des liaisons montantes lentes. Voir les fonctionnalités de MQTT 5.
Retained messages et latence perçue
L'état retenu ne rend pas les mises à jour plus rapides, mais il supprime le pire délai perçu : l'attente, après l'ouverture d'un jumeau, que chaque équipement ait publié au moins une fois. Avec un état retenu, la scène complète apparaît immédiatement à l'abonnement. Le tutoriel jumeau numérique et retained messages MQTT montre comment faire.
Emplacement du broker et distance réseau
Chaque saut réseau ajoute du délai, et la distance physique ajoute un temps aller-retour qu'aucun logiciel ne peut supprimer. Conseils pratiques :
- Placez le broker au plus près, du point de vue réseau, de la majorité des éditeurs et des consommateurs.
- Si les appareils sont dans une seule usine et les utilisateurs dans le monde entier, privilégiez le côté appareils pour les jumeaux de contrôle et acceptez un délai supplémentaire côté afficheurs pour la visualisation.
- Pour des exigences strictes, envisagez un broker dans votre propre compte ou votre propre région cloud. ConnectMQ propose des clusters Dedicated et des déploiements BYOC dans votre compte cloud, gérés par ConnectMQ, pour les équipes qui doivent maîtriser l'endroit où tourne le broker.
- Évitez les allers-retours inutiles : un afficheur dans l'usine ne devrait pas passer par une région lointaine pour voir une machine située à trois mètres si la latence locale compte ; utilisez dans ce cas un écran local alimenté par l'edge.
Mesurer la latence de bout en bout
Mesurez avant d'optimiser. Ce script Python publie des messages horodatés et s'abonne au même topic, en indiquant la latence aller-retour via le broker. Comme la même machine envoie et reçoit, le décalage d'horloge n'affecte pas le résultat.
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")
Le script envoie cinq messages par seconde, dans la limite du serveur MQTT public gratuit de 10 messages par seconde et par client ; ce serveur sert aux tests et aux prototypes, pas aux données de production. Exécutez-le depuis les réseaux qu'utilisent réellement vos appareils et vos afficheurs, à différents moments de la journée, et comparez QoS 0 et QoS 1. Indiquez des percentiles, pas seulement des moyennes : un jumeau rapide en moyenne mais qui se fige au 99e percentile paraît toujours peu fiable.
Pour une véritable latence aller simple de l'appareil à l'afficheur, incluez l'horodatage source dans chaque payload de télémétrie, synchronisez les horloges avec NTP et calculez la différence dans l'afficheur. Affichez l'âge de chaque valeur dans l'interface : c'est l'indicateur de latence le plus honnête dont puisse disposer un opérateur.
Checklist d'optimisation de la latence
- Définissez le budget de latence par fonction du jumeau avant de choisir la technologie.
- Raccourcissez les intervalles d'interrogation et d'échantillonnage edge pour les signaux qui pilotent les visuels ou le contrôle.
- Utilisez QoS 0 pour la télémétrie à haute fréquence et QoS 1 pour les changements d'état et les commandes.
- Gardez les connexions MQTT persistantes ; évitez les schémas une connexion par message.
- Réglez judicieusement les paramètres de session TLS et le keepalive pour que les reconnexions restent rares.
- Retenez l'état courant pour que les afficheurs fassent le rendu instantanément au chargement.
- Découplez le traitement des messages du rendu et interpolez entre les échantillons.
- Mesurez des percentiles sur les réseaux réels et affichez l'âge des valeurs dans le jumeau.
- Gardez la sécurité et le contrôle en boucle fermée en local, jamais dépendants du chemin cloud.
Comment ConnectMQ s'intègre à votre budget de latence
ConnectMQ fournit un broker MQTT managé, un broker MQTT cloud avec des connexions MQTT 3.1.1 et 5.0 persistantes sur TCP, TLS, WebSocket et WebSocket sécurisé, de sorte que les appareils et les jumeaux dans le navigateur partagent un même chemin à faible surcoût. Les retained messages permettent un chargement instantané des scènes, les alias de topic MQTT 5 réduisent le surcoût sur les arborescences de topics profondes, et les déploiements Dedicated ou BYOC vous laissent choisir où tourne le broker. Notre démo de jumeau numérique 3D anime une usine en direct via WSS en appliquant exactement ces principes. Pour comprendre le rôle d'un broker MQTT dans ce chemin, consultez notre introduction ; pour les modèles de données des jumeaux, lisez jumeau numérique avec MQTT et architecture d'un jumeau numérique.
Mesurez la latence de votre jumeau sur ConnectMQ
Exécutez le script ci-dessus sur le serveur MQTT public gratuit, puis recommencez sur votre propre broker. Créez-en un gratuitement avec le plan Serverless sur app.connectmq.com, sans carte bancaire, passez au port 8883 avec vos identifiants générés et comparez les chiffres obtenus depuis les réseaux réels de vos appareils.
Questions fréquentes
Quelle latence faut-il pour un jumeau numérique temps réel ?
Cela dépend de sa fonction : la visualisation paraît en direct à quelques centaines de millisecondes, la supervision tolère environ une seconde ou plus, et le contrôle en boucle fermée exige des réponses à la milliseconde qui relèvent des contrôleurs locaux, pas des jumeaux cloud.
La QoS 1 de MQTT ajoute-t-elle beaucoup de latence ?
En général peu dans des conditions normales, car les messages sont transmis avant la fin de l'acquittement. Les délais apparaissent surtout lorsque des paquets sont perdus et retransmis ou que les limites de messages en vol sont atteintes.
Quelle est la principale source de latence d'un jumeau numérique ?
Souvent les intervalles d'échantillonnage et d'interrogation edge, plus la distance réseau, et non le broker. Mesurez chaque étape avant d'optimiser.
Comment montrer la latence aux opérateurs ?
Incluez un horodatage source dans chaque message et affichez l'âge de chaque valeur dans le jumeau, en mettant en évidence les valeurs plus anciennes que prévu.
