Latenz im Echtzeit-Digital-Twin: Budgets für Visualisierung, Monitoring und Steuerung

Die Latenz eines digitalen Zwillings in Echtzeit entscheidet darüber, ob er sich live oder träge anfühlt und ob er sicher mehr tun kann als nur beobachten. Dieser Artikel erläutert realistische Latenzbudgets für Visualisierungs-, Monitoring- und Steuerungszwillinge, schlüsselt auf, wohin die Millisekunden tatsächlich gehen, zeigt, wie MQTT QoS und der Standort des Brokers die Verzögerung beeinflussen, und liefert ein Skript, mit dem Sie die Ende-zu-Ende-Latenz in Ihrer eigenen Umgebung messen.

Hintergrundwissen zu digitalen Zwillingen im Allgemeinen finden Sie im Leitfaden zur Digital-Twin-Technologie.

"Echtzeit" bedeutet für jeden Zwilling etwas anderes

Es gibt nicht die eine Latenzanforderung für digitale Zwillinge. Das richtige Ziel hängt davon ab, wofür der Zwilling gedacht ist:

Dies sind qualitative technische Richtwerte, keine Normen. Die wichtigste Lehre steckt in der letzten Zeile: Regelkreis- und Sicherheitsfunktionen gehören in SPSen, Sicherheitssteuerungen und lokale Regler, also auf die Feld- und Steuerungsebene im Sinne von ISA-95. Ein mit der Cloud verbundener Zwilling kann überwachen, beraten und Sollwerte anpassen, darf aber niemals das Einzige sein, das zwischen einer Maschine und einem unsicheren Zustand steht.

Woher die Latenz eines Echtzeit-Zwillings kommt

Die Ende-zu-Ende-Latenz ist die Summe aller Stufen zwischen einer physischen Änderung und dem Pixel oder der Aktion, die sie widerspiegelt:

1. Erfassung und Abtastung: Ein Wert, der alle 500 ms abgetastet wird, fügt bis zu 500 ms hinzu, bevor überhaupt jemand weiß, dass er sich geändert hat.
2. Edge-Verarbeitung: SPS-Zykluszeiten, Polling-Intervalle von Gateways und Batching.
3. Puffer beim Publish: Manche Clients bündeln Schreibvorgänge; Totbänder verzögern kleine Änderungen bewusst.
4. Netzwerk-Uplink: Werksnetz, Internetpfad, Mobilfunk- oder Satellitenverbindungen.
5. Verarbeitung im Broker: Die Authentifizierung erfolgt beim Verbindungsaufbau; das Routing eines Publish an die Subscriber ist bei einem gut betriebenen Broker meist nur ein kleiner Teil des Gesamtwerts.
6. Netzwerk-Downlink: vom Broker zum Betrachter oder Konsumenten.
7. Anwendung und Rendering: Parsing, Zustandsaktualisierungen und der nächste Render-Frame.

In der Praxis dominieren die Abtast- und Polling-Intervalle an der Edge sowie die Netzwerkdistanz. Teams optimieren oft den Broker, während ein Gateway die SPS nur einmal pro Sekunde abfragt, was die Reaktionsfähigkeit begrenzt, egal was danach passiert.

Wie MQTT-Einstellungen die Latenz beeinflussen

QoS-Stufen

• QoS 0 sendet die Nachricht einmal ohne Bestätigung. Geringster Overhead und die übliche Wahl für hochfrequente Visualisierungstelemetrie, bei der der nächste Messwert einen verlorenen ersetzt.
• QoS 1 erfordert ein PUBACK. Die Zustellung an Subscriber wird durch die Bestätigung selbst nicht verzögert, aber Neuübertragungen nach Verlusten erhöhen die Verzögerung, und In-Flight-Limits können Lastspitzen drosseln.
• QoS 2 ergänzt pro Nachricht einen vierstufigen Handshake. Setzen Sie es nur ein, wenn Exactly-once-Semantik wirklich nötig ist, was bei Zwillingsdaten selten der Fall ist.

Der Artikel MQTT-QoS-Stufen erklärt beschreibt die Mechanik im Detail.

Verbindungen und Sessions

Halten Sie Verbindungen dauerhaft offen. Ein Neuverbinden für jeden Publish verursacht TCP- und TLS-Handshakes, die mehr kosten können als alles andere zusammen. Stellen Sie das Keepalive so ein, dass tote Verbindungen schnell erkannt werden, und nutzen Sie einen Last Will, damit Betrachter sehen, wenn ein Gerät ausfällt, statt veralteten Werten zu vertrauen.

Payload- und Topic-Größe

Kleine Payloads werden schneller serialisiert und übertragen, besonders auf eingeschränkten Verbindungen. MQTT-5-Topic-Aliase ersetzen lange Topic-Strings nach der ersten Nachricht durch kurze Ganzzahlen, was bei tiefen ISA-95-Topic-Pfaden über langsame Uplinks hilft. Solche Pfade entstehen typischerweise in einem Unified Namespace (UNS), in dem die Anlagenhierarchie Enterprise → Site → Area → Line → Cell die Topic-Struktur bildet, etwa acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur. Die Tiefe kostet im UNS dank Aliasen kaum Latenz, bringt aber Ordnung, die Zwillinge und MES gleichermaßen nutzen. Siehe MQTT-5-Funktionen und Sparkplug B und Unified Namespace.

Retained Messages für die gefühlte Latenz

Retained-Zustände machen Aktualisierungen nicht schneller, beseitigen aber die schlimmste gefühlte Verzögerung: das Warten nach dem Öffnen eines Zwillings, bis jedes Asset einmal veröffentlicht hat. Mit Retained-Zustand erscheint die vollständige Szene sofort beim Subscribe. Das Tutorial Digitaler Zwilling mit Retained MQTT zeigt, wie es geht.

Broker-Standort und Netzwerkdistanz

Jeder Netzwerk-Hop erhöht die Verzögerung, und physische Entfernung verlängert die Round-Trip-Zeit auf eine Weise, die keine Software beseitigen kann. Praktische Empfehlungen:

1. Platzieren Sie den Broker netzwerktechnisch nahe an den meisten Publishern und Konsumenten.
2. Wenn die Geräte in einem Werk stehen und die Betrachter weltweit verteilt sind, priorisieren Sie bei Steuerungszwillingen die Geräteseite und akzeptieren Sie bei der Visualisierung zusätzliche Verzögerung für die Betrachter.
3. Bei strengen Anforderungen sollten Sie einen Broker in Ihrem eigenen Cloud-Konto oder Ihrer Region in Betracht ziehen. ConnectMQ bietet Dedicated-Cluster und BYOC-Deployments in Ihrem Cloud-Konto, von ConnectMQ verwaltet, für Teams, die kontrollieren müssen, wo der Broker läuft.
4. Vermeiden Sie Hairpinning: Ein Betrachter im Werk sollte nicht über eine weit entfernte Region geleitet werden, um eine drei Meter entfernte Maschine zu sehen, wenn lokale Latenz wichtig ist; nutzen Sie dafür eine lokale Anzeige, die von der Edge gespeist wird.

Ende-zu-Ende-Latenz messen

Messen Sie, bevor Sie optimieren. Dieses Python-Skript veröffentlicht Nachrichten mit Zeitstempel, abonniert dasselbe Topic und meldet die Round-Trip-Latenz über den Broker. Da derselbe Rechner sendet und empfängt, beeinflusst Uhrenabweichung das Ergebnis nicht.

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")

Das Skript sendet fünf Nachrichten pro Sekunde und bleibt damit unter dem Limit des öffentlichen MQTT-Brokers von 10 Nachrichten pro Sekunde und Client. Führen Sie es aus den Netzwerken aus, die Ihre Geräte und Betrachter tatsächlich nutzen, zu verschiedenen Tageszeiten, und vergleichen Sie QoS 0 mit QoS 1. Berichten Sie Perzentile, nicht nur Mittelwerte: Ein Zwilling, der im Schnitt schnell ist, aber beim 99. Perzentil hängt, wirkt trotzdem unzuverlässig.

Für die echte Einweg-Latenz vom Gerät zum Betrachter nehmen Sie den Quellzeitstempel in jede Telemetrie-Payload auf, synchronisieren die Uhren per NTP und berechnen die Differenz im Viewer. Zeigen Sie das Alter jedes Werts in der Oberfläche an; es ist der ehrlichste Latenzindikator, den ein Bediener bekommen kann.

Checkliste zur Latenzoptimierung

1. Legen Sie das Latenzbudget je Zweck des Zwillings fest, bevor Sie Technologie auswählen.
2. Verkürzen Sie Polling- und Abtastintervalle an der Edge für Signale, die Visualisierung oder Steuerung antreiben.
3. Nutzen Sie QoS 0 für hochfrequente Telemetrie und QoS 1 für Zustandsänderungen und Befehle.
4. Halten Sie MQTT-Verbindungen dauerhaft offen; vermeiden Sie Muster mit einer Verbindung pro Nachricht.
5. Setzen Sie TLS-Session-Einstellungen und Keepalive sinnvoll, damit Neuverbindungen selten sind.
6. Halten Sie den aktuellen Zustand als Retained, damit Viewer beim Laden sofort rendern.
7. Entkoppeln Sie die Nachrichtenverarbeitung vom Rendering und interpolieren Sie zwischen Messwerten.
8. Messen Sie Perzentile in realen Netzwerken und zeigen Sie das Alter der Werte im Zwilling an.
9. Halten Sie Sicherheits- und Regelkreissteuerung lokal, niemals abhängig vom Cloud-Pfad.

Wie ConnectMQ in Ihr Latenzbudget passt

ConnectMQ bietet einen Cloud-MQTT-Broker mit dauerhaften MQTT-3.1.1- und 5.0-Verbindungen über TCP, TLS, WebSocket und Secure WebSocket, sodass Geräte und Browser-Zwillinge einen gemeinsamen Pfad mit geringem Overhead nutzen. Retained Messages sorgen für sofort geladene Szenen, MQTT-5-Topic-Aliase reduzieren den Overhead bei tiefen Topic-Bäumen, und mit Dedicated- oder BYOC-Deployments wählen Sie selbst, wo der Broker läuft. Unsere 3D-Digital-Twin-Demo animiert eine Fabrik live über WSS mit genau diesen Mustern. Was ein MQTT-Broker leistet, erklärt unsere Einführung; zu Datenmustern für Zwillinge lesen Sie Digitaler Zwilling mit MQTT und Digital-Twin-Architektur.

Messen Sie die Latenz Ihres Zwillings auf ConnectMQ

Führen Sie das obige Skript gegen den öffentlichen MQTT-Broker aus und wiederholen Sie es dann mit Ihrem eigenen Broker. Erstellen Sie einen kostenlos im Serverless-Tarif unter app.connectmq.com, ohne Kreditkarte, wechseln Sie mit Ihren generierten Zugangsdaten auf Port 8883 und vergleichen Sie die Werte aus Ihren realen Gerätenetzwerken.

Häufig gestellte Fragen

Welche Latenz braucht ein digitaler Zwilling in Echtzeit?

Das hängt vom Zweck ab: Visualisierung wirkt bei einigen hundert Millisekunden live, Monitoring verträgt etwa eine Sekunde oder mehr, und Regelkreissteuerung braucht Reaktionen im Millisekundenbereich, die in lokale Steuerungen gehören, nicht in Cloud-Zwillinge.

Erhöht MQTT QoS 1 die Latenz stark?

Unter normalen Bedingungen meist kaum, weil Nachrichten weitergeleitet werden, bevor die Bestätigung abgeschlossen ist. Verzögerungen entstehen vor allem, wenn Pakete verloren gehen und neu übertragen werden oder In-Flight-Limits erreicht sind.

Was ist die größte Latenzquelle bei digitalen Zwillingen?

Oft die Abtast- und Polling-Intervalle an der Edge plus die Netzwerkdistanz, nicht der Broker. Messen Sie jede Stufe, bevor Sie optimieren.

Wie kann ich Bedienern die Latenz anzeigen?

Nehmen Sie einen Quellzeitstempel in jede Nachricht auf und zeigen Sie das Alter jedes Werts im Zwilling an, wobei Sie Werte hervorheben, die älter als erwartet sind.