Digitaler Zwilling mit MQTT: Echtzeit-Zustand an Ihren Zwilling streamen

Einen digitalen Zwilling mit MQTT zu kombinieren ist der direkteste Weg, ein virtuelles Modell im Gleichschritt mit realen Anlagen zu halten. In diesem Leitfaden erfahren Sie, warum das Publish/Subscribe-Modell von MQTT so gut zu Zwillingen passt, wie Sie Topics, Retained State, Präsenz und Befehle gestalten und wie Sie den Live-Zustand mit lauffähigem Python und JavaScript in einen browserbasierten Zwilling streamen.

Wenn das Zwillingskonzept neu für Sie ist, beginnen Sie mit dem Leitfaden zur Digital-Twin-Technologie.

Warum MQTT zu digitalen Zwillingen passt

Ein Zwilling braucht von seinem Transport drei Dinge: Aktualisierungen mit geringer Latenz, eine Möglichkeit für Nachzügler, den aktuellen Zustand zu erhalten, und lose Kopplung, damit neue Konsumenten hinzukommen können, ohne die Geräte anzufassen. MQTT liefert alle drei bereits im Protokoll.

HTTP-Polling hingegen zwingt jeden Viewer, eine API ständig abzufragen, und lässt trotzdem Lücken zwischen den Abfragen. Message Queues für die Backend-Verarbeitung haben oft weder Retained State noch Browser-Konnektivität. Deshalb stellen so viele Zwillingsplattformen einen MQTT-Broker ins Zentrum.

Topics für einen digitalen Zwilling mit MQTT entwerfen

Der Topic-Baum ist das Adressierungsschema Ihres Zwillings. Spiegeln Sie die physische Hierarchie und enden Sie mit einer Nachrichtenklasse:

connectmq/demo/<id>/factory1/line1/cnc1/telemetry   stream, not retained
connectmq/demo/<id>/factory1/line1/cnc1/state       current state, retained
connectmq/demo/<id>/factory1/line1/cnc1/status      online/offline, retained + last will
connectmq/demo/<id>/factory1/line1/cnc1/cmd         commands, never retained
connectmq/demo/<id>/factory1/line1/cnc1/cmd/ack     command results

In der Industrie hat sich dafür der Unified Namespace (UNS) durchgesetzt: Der MQTT-Broker hält den aktuellen Zustand aller Anlagen in einer einzigen Topic-Struktur, die der ISA-95-Ausrüstungshierarchie (Enterprise → Site → Area → Line → Cell) folgt, etwa acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur. Der Zwilling ist dann einfach ein weiterer Konsument dieses UNS, neben MES, SCADA und ERP. Wie Sparkplug B dabei hilft, beschreibt Sparkplug B und Unified Namespace.

Regeln, die später Ärger ersparen:

• Verwenden Sie für Topic-Ebenen stabile Kennungen, keine Anzeigenamen. Namen ändern sich, IDs nicht.
• Legen Sie Einheiten und Zeitstempel in den Payload, nicht in das Topic.
• Halten Sie jeden Payload klein und auf ein Asset fokussiert.
• Setzen Sie bei Befehlen nie das Retain-Flag. Ein retained cmd würde bei jedem Reconnect eines Geräts erneut ausgeführt.

Eine ausführlichere Betrachtung, wie Topics auf das Asset-Modell abgebildet werden, finden Sie unter Architektur digitaler Zwillinge.

Retained Messages als Gedächtnis des Zwillings

Wenn ein Viewer den Zwilling öffnet, sollte er nicht auf den nächsten Telemetrietakt warten müssen, um jede Maschine anzuzeigen. Wird der Zustand mit gesetztem Retain-Flag publiziert, speichert der Broker die letzte Nachricht pro Topic und liefert sie beim Abonnieren sofort aus. Das Tutorial zum Retained-MQTT-Zustand baut auf diese Weise einen vollständigen Zwilling; hier die Kernidee in Python mit paho-mqtt 2.x:

import json
import random
import time
import paho.mqtt.client as mqtt

PREFIX = "connectmq/demo/b72e/factory1/line1/cnc1"

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="cnc1-sim-b72e")
client.will_set(f"{PREFIX}/status", payload="offline", qos=1, retain=True)
client.connect("broker.connectmq.com", 1883)
client.loop_start()

client.publish(f"{PREFIX}/status", "online", qos=1, retain=True)

try:
    while True:
        state = {
            "ts": int(time.time() * 1000),
            "spindle_rpm": random.randint(7800, 8200),
            "feed_mm_min": random.randint(900, 1100),
            "tool": 4,
            "mode": "AUTO",
        }
        client.publish(f"{PREFIX}/state", json.dumps(state), qos=0, retain=True)
        time.sleep(1)
except KeyboardInterrupt:
    client.publish(f"{PREFIX}/status", "offline", qos=1, retain=True)
    client.loop_stop()
    client.disconnect()

Der Last Will auf dem Topic status ist wichtig. Stürzt der Simulator ab oder bricht das Netzwerk weg, publiziert der Broker für Sie offline, und weil die Nachricht retained ist, sieht auch jeder später geöffnete Viewer die Maschine als offline.

Den Zwilling in den Browser streamen

Ein browserbasierter 3D- oder 2D-Zwilling verbindet sich über Secure WebSocket auf Port 8084 mit dem Pfad /mqtt. Dieses MQTT.js-Beispiel abonniert die gesamte Linie und aktualisiert ein Zwillingsmodell im Speicher, das Ihr Rendering-Code in jedem Frame auslesen kann:

import mqtt from "mqtt";

const prefix = "connectmq/demo/b72e/factory1/line1";
const twin = new Map();

const client = mqtt.connect("wss://broker.connectmq.com:8084/mqtt", {
  clientId: "twin-viewer-" + Math.random().toString(16).slice(2, 10),
  protocolVersion: 5,
  clean: true,
});

client.on("connect", () => {
  client.subscribe(`${prefix}/+/state`);
  client.subscribe(`${prefix}/+/status`);
});

client.on("message", (topic, payload) => {
  const parts = topic.split("/");
  const asset = parts[parts.length - 2];
  const kind = parts[parts.length - 1];
  const current = twin.get(asset) || {};
  if (kind === "status") {
    current.online = payload.toString() === "online";
  } else {
    Object.assign(current, JSON.parse(payload.toString()));
  }
  twin.set(asset, current);
  console.log(asset, current);
});

Entkoppeln Sie die Nachrichtenverarbeitung vom Rendering. Nachrichten aktualisieren das Modell, die Render-Schleife liest das Modell. So bleiben die Bildraten flüssig, auch wenn Nachrichten stoßweise eintreffen.

Payload-Design für Zwillingsnachrichten

Topics sagen Konsumenten, wohin ein Wert gehört; Payloads sagen ihnen, was er bedeutet. Einige Konventionen halten einen wachsenden Zwilling beherrschbar:

• Fügen Sie einen Quellzeitstempel ein (ts in Millisekunden), in jeder Zustands- und Telemetrienachricht. Viewer können dann das Alter jedes Werts anzeigen und Aktualisierungen in falscher Reihenfolge ignorieren.
• Verwenden Sie einheitliche Feldnamen und Einheiten für Assets desselben Typs, idealerweise dokumentiert in einem Schema oder einer Modellierungssprache wie DTDL.
• Senden Sie den vollständigen Zustand auf dem State-Topic, keine Teil-Patches. Ein retained Teil-Patch würde einem neuen Viewer nur ein halbes Bild liefern.
• Halten Sie Payloads kompakt. JSON ist leicht zu debuggen und für die meisten Zwillinge gut geeignet; wechseln Sie nur dann zu einer binären Kodierung, wenn die Bandbreite tatsächlich knapp ist.
• Ergänzen Sie ein Feld für die Schemaversion, wenn sich Payloads weiterentwickeln können, damit alte und neue Geräte während eines Rollouts koexistieren können.

Diese Regeln kosten am Anfang nichts und ersparen erhebliche Nacharbeit, sobald Dutzende Asset-Typen und mehrere konsumierende Anwendungen vom selben Datenstrom abhängen.

Befehle: den Kreis schließen

Ein beobachtender Zwilling wird zum bedienenden Zwilling, sobald er Befehle senden kann. Das sichere Muster:

1. Die Anwendung publiziert einen Befehl mit einer Correlation ID auf .../cmd mit QoS 1, nicht retained.
2. Das Gerät validiert und führt ihn aus und publiziert dann das Ergebnis mit derselben ID auf .../cmd/ack.
3. Das Gerät aktualisiert seinen retained state, den jeder Viewer sieht.
4. Die Anwendung bricht mit einem Timeout ab, wenn keine Bestätigung eintrifft.

MQTT 5 macht das mit den Eigenschaften Response Topic und Correlation Data sauberer, dazu mit Message Expiry, damit ein zu lange liegengebliebener Befehl verworfen statt verspätet ausgeführt wird. Details finden Sie unter MQTT-5-Funktionen. Zur Behandlung von Soll- und Ist-Zustand lesen Sie Zustandssynchronisation digitaler Zwillinge.

QoS für Zwillingsdaten wählen

1. Schnelle Telemetrie für Animation: QoS 0. Ein verpasster Frame wird durch den nächsten ersetzt.
2. Zustandsänderungen und Alarme: QoS 1, damit sie bei kurzen Verbindungsabbrüchen nicht verloren gehen.
3. Befehle: QoS 1 mit idempotenter Verarbeitung und Correlation IDs. QoS 2 wird selten gebraucht, wenn Befehle idempotent sind.

Der Artikel MQTT-QoS-Stufen erklärt behandelt die Abwägungen ausführlich.

Wie ConnectMQ einen 3D-Live-Zwilling antreibt

ConnectMQ betreibt eine 3D-Web-Demo eines digitalen Zwillings einer kleinen Fabrik mit CNC-Maschine, Roboterarm, Ofen, Tank, Förderband und Pumpe. Simulierte Assets publizieren ihren Zustand an den Broker, und die 3D-Szene abonniert über Secure WebSocket, genau mit den oben beschriebenen Mustern: hierarchische Topics, Retained State für sofortiges Laden und Live-Aktualisierungen, die die Animation antreiben.

Für Ihren eigenen Zwilling bietet ConnectMQ einen verwalteten MQTT-Broker mit MQTT 3.1.1 und 5.0, TLS auf Port 8883 und WSS auf Port 8084 mit einem Let's-Encrypt-Zertifikat, sodass sich Browser-Viewer ohne Zertifikatswarnungen verbinden. Der Live-Topic-Explorer im Portal und die Geräteansicht nach ISA-95-Ebenen helfen Ihnen zu prüfen, ob jedes Asset dort publiziert, wo es soll. Experimentieren Sie zunächst mit Demodaten auf dem kostenlosen öffentlichen MQTT-Broker, der für Tests und Prototypen gedacht ist, und wechseln Sie für echte Produktionsdaten zu eigenen Zugangsdaten.

Fehlersuche bei MQTT-Setups für digitale Zwillinge

• Der Viewer zeigt bis zur ersten Aktualisierung nichts an. Der Zustand wird nicht mit gesetztem Retain-Flag publiziert.
• Ein Gerät führt nach dem Neustart immer wieder einen alten Befehl aus. Ein Befehl wurde retained. Löschen Sie ihn, indem Sie einen leeren Retained-Payload auf dieses Topic publizieren, und hören Sie auf, Befehle zu retainen.
• Assets bleiben nach einem Stromausfall „online". Kein Last Will konfiguriert, oder das Keepalive ist zu lang.
• Der Browser kann sich nicht verbinden. Prüfen Sie die wss://-URL, Port 8084 und den Pfad /mqtt.
• Ruckelnde Animation. Das Rendering ist an die Nachrichtenverarbeitung gekoppelt, oder die Telemetrierate ist für flüssige Bewegungen zu niedrig; interpolieren Sie zwischen den Messwerten.

Verbinden Sie Ihren digitalen Zwilling mit ConnectMQ

Erstellen Sie unter app.connectmq.com einen Broker im kostenlosen Serverless-Plan ohne Kreditkarte, kopieren Sie den generierten Benutzernamen, das Passwort und die Client ID und richten Sie Simulator und Viewer darauf aus. Innerhalb weniger Minuten streamt Ihr Live-Zwilling über MQTT.

Häufig gestellte Fragen

Warum MQTT statt REST für einen digitalen Zwilling?

MQTT schiebt Aktualisierungen über eine persistente Verbindung in dem Moment aus, in dem sie entstehen, und hält den neuesten Zustand in Retained Messages vor, während REST Polling erfordert und zusätzliche Latenz und Last erzeugt.

Kann sich ein Browser für einen 3D-Zwilling direkt mit MQTT verbinden?

Ja. Browser verbinden sich über MQTT über WebSocket, zum Beispiel wss://broker.connectmq.com:8084/mqtt, mit einer Bibliothek wie MQTT.js.

Sollte ich Telemetrie retainen oder nur den Zustand?

Retainen Sie das Topic für den aktuellen Zustand, damit Viewer sofort laden; lassen Sie hochfrequente Telemetrieströme ohne Retain, um Verwechslungen zwischen Datenstrom und Momentaufnahme zu vermeiden.

Wie zeige ich im Zwilling an, dass ein Gerät offline geht?

Konfigurieren Sie eine Last-Will-Nachricht auf einem retained Status-Topic. Der Broker publiziert sie automatisch, wenn das Gerät die Verbindung unerwartet verliert.