Ein KI-gestützter digitaler Zwilling kombiniert ein lebendiges, synchronisiertes Modell eines physischen Assets oder Prozesses mit Machine-Learning-Modellen, die vorhersagen, was als Nächstes passiert, und vorschlagen, was zu tun ist. Dieser Erklärartikel zeigt, wo KI einem Zwilling echten Mehrwert bringt, wie die Daten- und Inferenzarchitektur aussieht, wenn der Zwilling per MQTT gespeist wird, und wie Sie einen kleinen Anomaliedetektor bauen, den Sie noch heute ausführen können.
Vom Spiegel zum Berater: Was KI einem digitalen Zwilling hinzufügt
Ein einfacher digitaler Zwilling ist ein Spiegel. Er zeigt den aktuellen Zustand eines Assets: Temperaturen, Drehzahlen, Zustände und Alarme, synchronisiert aus der realen Welt. Das allein ist nützlich, überlässt die Interpretation aber den Menschen.
Machine Learning macht aus dem Spiegel einen Berater. Es kann:
- Erkennen, was Menschen übersehen, etwa eine subtile Kombination von Signalen, die einem Fehler vorausgeht
- Vorhersagen, wie sich Werte entwickeln: Restlebensdauer, Energiebedarf, Produktqualität, Durchsatz
- Schätzen, was nicht direkt gemessen wird (Soft Sensors), etwa ein Qualitätsmerkmal, das aus Prozessparametern abgeleitet wird
- Optimieren, indem es innerhalb von Grenzen untersucht, welche Sollwerte eine Zielgröße verbessern würden
Der Zwilling liefert, was ML-Modelle am dringendsten brauchen: saubere, kontextualisierte, zeitlich abgeglichene Daten mit einer klaren Asset-Struktur. Das Modell liefert, was dem Zwilling fehlt: Voraussicht. Grundlagen zu Zwillingen finden Sie im Leitfaden zur Digital-Twin-Technologie.
Arten von KI in digitalen Zwillingen
| Verfahren | Was es tut | Typischer Einsatz im Zwilling | Datenbedarf |
|---|---|---|---|
| Anomalieerkennung | Markiert Verhalten, das vom Normalen abweicht | Frühwarnung vor Fehlern, Prüfung der Datenqualität | Überwiegend normale Betriebsdaten |
| Regression / Prognose | Sagt einen Zahlenwert für die Zukunft voraus | Energiebedarf, Temperatur, Restlebensdauer | Historie mit der Zielgröße |
| Klassifikation | Ordnet eine Kategorie zu | Fehlerart, Qualität i. O./n. i. O. | Gelabelte Beispiele je Klasse |
| Soft Sensors | Leiten eine nicht gemessene Größe ab | Produktqualität, Viskosität, Verschleiß | Regelmäßige Labor- oder Referenzmessungen |
| Surrogatmodelle | Schnelle Näherung einer physikalischen Simulation | Echtzeit-Was-wäre-wenn statt langsamer Simulation | Simulationsläufe |
| Optimierung / Reinforcement Learning | Findet bessere Sollwerte oder Pläne | Energieoptimierung, Rezeptabstimmung | Zuverlässiges Prozessmodell, strikte Grenzen |
Die meisten produktiven Einsätze stützen sich heute auf die ersten drei Zeilen. Anomalieerkennung ist oft der beste Einstieg, weil sie keine gelabelten Ausfälle braucht, die in gut geführten Werken selten sind.
Architektur: MQTT als Nervensystem des Zwillings
Ein KI-gestützter digitaler Zwilling hat zwei Datenpfade, die sich ein Backbone teilen:
- Live-Pfad. Sensoren, SPSen und Edge-Gateways veröffentlichen an einen MQTT-Broker. Der Zustandsdienst des Zwillings und der Inferenzdienst abonnieren. Inferenzergebnisse (Anomalie-Scores, Prognosen, Empfehlungen) werden auf MQTT-Topics zurück veröffentlicht, wo Zwillings-Viewer, Alarmierung und andere Systeme sie aufgreifen.
- Trainingspfad. Ein Subscriber schreibt alle Daten in eine Zeitreihendatenbank oder einen Data Lake. Data Scientists trainieren Modelle offline auf dieser Historie und spielen dann neue Modellversionen in den Inferenzdienst ein.
Das gemeinsame Backbone ist idealerweise ein Unified Namespace (UNS): ein Topic-Baum, dessen Ebenen der ISA-95-Anlagenhierarchie folgen (Enterprise → Site → Area → Line → Cell), etwa acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur. So finden Zwilling, MES und KI-Dienste jeden Wert an derselben Adresse, und Modellausgaben landen direkt neben den Messwerten des Assets. Ein vereinfachtes Topic-Layout entlang der Asset-Hierarchie:
connectmq/plant1/press-line/press4/telemetry raw features from the edge
connectmq/plant1/press-line/press4/state operating context
connectmq/plant1/press-line/press4/ai/anomaly model output
connectmq/plant1/press-line/press4/ai/forecast model output
Modellausgaben per MQTT zu veröffentlichen, ist wichtig. So werden KI-Ergebnisse zu vollwertigen Zwillingsdaten, sichtbar im selben Viewer und Topic-Baum wie die Messwerte, und mehrere Konsumenten können reagieren, ohne das Modell zu kennen. MQTT-5-Funktionen helfen dabei: Message Expiry verhindert, dass eine alte Prognose als aktuell angezeigt wird, und Shared Subscriptions (in den kostenpflichtigen Serverless-Tarifen von ConnectMQ und darüber) lassen mehrere Inferenz-Worker einen Datenstrom mit hohem Volumen teilen.
Ein Wort zu den Rollen: Der Broker transportiert Daten. ConnectMQ zum Beispiel ist ein verwalteter MQTT-Broker und führt selbst keine ML-Modelle aus; Ihre Inferenzdienste verbinden sich als gewöhnliche MQTT-Clients. Diese Trennung ist gesund, denn Sie können jedes ML-Framework nutzen und Modelle an der Edge oder in der Cloud einsetzen, ohne das Daten-Backbone zu ändern.
Inferenz an der Edge oder in der Cloud?
| Faktor | Inferenz an der Edge | Inferenz in der Cloud |
|---|---|---|
| Latenz | Sehr gering, funktioniert offline | Abhängig vom Netzwerk |
| Modellgröße | Durch Hardware begrenzt | Große Modelle möglich |
| Flottenweites Lernen | Schwieriger | Einfach, sieht alle Assets |
| Hochgeladenes Datenvolumen | Gering (Merkmale, Ergebnisse) | Größer |
| Updates | Brauchen Deployment-Werkzeuge je Standort | Zentral |
Ein verbreiteter Hybridansatz: Leichtgewichtige Anomaliemodelle an der Edge veröffentlichen Scores sofort; aufwendigere Prognosen und Flottenvergleiche laufen zentral. Beide veröffentlichen ihre Ergebnisse an denselben Broker, sodass es dem Zwilling egal ist, wo die Inferenz stattfand.
Praxis: ein Streaming-Anomaliedetektor
Dieses Beispiel nutzt den kostenlosen öffentlichen MQTT-Broker unter broker.connectmq.com mit simulierten Daten. Es verwendet den Isolation Forest von scikit-learn, trainiert auf den ersten Minuten "normaler" Daten und bewertet danach jede neue Nachricht. Der öffentliche MQTT-Broker ist für Tests und Prototypen gedacht: Verwenden Sie dort nur simulierte Daten und keine Produktionsdaten, da jeder sie lesen kann.
Abhängigkeiten installieren:
pip install "paho-mqtt>=2.0" scikit-learn numpy
Das Skript simuliert eine Presse, trainiert auf normalem Verhalten und speist dann einen Fehler ein:
import json
import random
import threading
import time
import uuid
import numpy as np
import paho.mqtt.client as mqtt
from sklearn.ensemble import IsolationForest
RUN = "ai-6b2d" # change to your own unique id
BASE = f"connectmq/demo/{RUN}/plant1/press4"
TRAIN_SAMPLES = 120
buffer = []
model = None
def simulate(pub):
start = time.time()
while True:
faulty = time.time() - start > 180 # fault appears after 3 minutes
force = random.gauss(800, 15) + (60 if faulty else 0)
temp = random.gauss(55, 0.8) + (4 if faulty else 0)
cycle = random.gauss(4.0, 0.05)
pub.publish(f"{BASE}/telemetry", json.dumps({"forceKn": force, "oilTempC": temp, "cycleS": cycle}))
time.sleep(1)
def on_connect(client, userdata, flags, reason_code, properties):
client.subscribe(f"{BASE}/telemetry")
print("Inference service connected:", reason_code)
def on_message(client, userdata, msg):
global model
d = json.loads(msg.payload)
x = [d["forceKn"], d["oilTempC"], d["cycleS"]]
if model is None:
buffer.append(x)
if len(buffer) >= TRAIN_SAMPLES:
model = IsolationForest(n_estimators=100, contamination=0.01, random_state=0).fit(np.array(buffer))
print("Model trained on", len(buffer), "samples")
return
score = float(-model.score_samples(np.array([x]))[0]) # higher means more anomalous
is_anomaly = bool(model.predict(np.array([x]))[0] == -1)
result = {"score": round(score, 3), "anomaly": is_anomaly, "modelVersion": "iforest-v1", "ts": time.time()}
client.publish(f"{BASE}/ai/anomaly", json.dumps(result), qos=1)
if is_anomaly:
print("ANOMALY", result)
svc = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=f"ai-svc-{uuid.uuid4().hex[:6]}")
svc.on_connect = on_connect
svc.on_message = on_message
svc.connect("broker.connectmq.com", 1883, keepalive=30)
sim = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=f"press-sim-{uuid.uuid4().hex[:6]}")
sim.connect("broker.connectmq.com", 1883, keepalive=30)
sim.loop_start()
threading.Thread(target=simulate, args=(sim,), daemon=True).start()
svc.loop_forever()
In den ersten zwei Minuten sammelt der Dienst Trainingsdaten. Nach drei Minuten erhöht der simulierte Fehler Presskraft und Öltemperatur, und auf dem Topic ai/anomaly erscheinen die ersten Anomalien. Ein Zwillings-Viewer, der dieses Topic abonniert, kann die Presse nach Score einfärben. Beachten Sie, dass die Modellausgabe eine Version enthält, sodass Sie immer wissen, welches Modell ein Ergebnis erzeugt hat.
Praktische Checkliste für einen KI-gestützten digitalen Zwilling
- Definieren Sie die Entscheidung, die die KI unterstützen soll, und wer danach handelt.
- Schaffen Sie zuerst die Datenbasis: einheitliche Topics, Zeitstempel, Einheiten und Betriebskontext.
- Speichern Sie die Historie vom ersten Tag an mit einem separaten Subscriber; auf Daten, die Sie nicht aufbewahrt haben, können Sie nicht trainieren.
- Beginnen Sie mit Anomalieerkennung oder einfacher Prognose, bevor Sie Optimierung angehen.
- Veröffentlichen Sie Modellausgaben per MQTT mit Modellversion und Zeitstempel.
- Überwachen Sie die Modellqualität im Zeitverlauf; trainieren Sie neu, wenn sich Prozesse, Produkte oder Sensoren ändern.
- Lassen Sie bei Empfehlungen, die Sollwerte ändern, Menschen mitentscheiden, und setzen Sie Grenzwerte im Steuerungssystem durch, nicht im Modell.
- Sichern Sie die Pipeline ab: privater Broker, TLS, eigene Zugangsdaten für jeden Dienst.
Stolpersteine, die Sie vermeiden sollten
- KI vor Daten. Die meisten KI-Zwillingsprojekte, die ins Stocken geraten, scheitern an inkonsistenten Daten, nicht an einem schwachen Modell.
- Training auf gemischten Betriebszuständen. Segmentieren Sie nach Produkt, Drehzahl oder Modus oder nehmen Sie diese als Merkmale auf.
- Unbemerkte Modelldrift. Sensoren werden getauscht und neu kalibriert; ein auf altem Verhalten trainiertes Modell markiert das neue Normal als Anomalie.
- Nicht erklärbare Alarme. Bediener ignorieren Alarme, die sie nicht verstehen. Veröffentlichen Sie die beitragenden Signale zusammen mit dem Score.
KI ist der natürliche nächste Schritt nach Predictive Maintenance mit dem digitalen Zwilling mit trendbasierten Modellen und baut auf der in ISA-95 digitaler Zwilling beschriebenen Struktur auf. Einen breiteren Kontext zu Machine Learning mit vernetzten Geräten bietet KI und IoT.
Schaffen Sie die Datenbasis für Ihren KI-gestützten digitalen Zwilling
KI ist nur so gut wie der Datenstrom dahinter. ConnectMQ bietet ein sicheres MQTT-5-Backbone mit TLS, WebSocket-Zugang und ISA-95-fähigen Topic-Ansichten, bereit für Ihre Inferenzdienste zum Abonnieren und Veröffentlichen. Erstellen Sie einen kostenlosen Serverless-Broker unter app.connectmq.com, ohne Kreditkarte, und beginnen Sie, die Daten zu sammeln, aus denen Ihre Modelle lernen werden.
Häufig gestellte Fragen
Was ist ein KI-gestützter digitaler Zwilling?
Ein digitaler Zwilling, erweitert um Machine-Learning-Modelle, die auf Basis der Live- und Historiendaten, die den Zwilling synchronisieren, Anomalien erkennen, künftiges Verhalten prognostizieren oder Maßnahmen empfehlen.
Führt der MQTT-Broker die KI-Modelle aus?
Nein. Der Broker transportiert Daten. Inferenzdienste an der Edge oder in der Cloud abonnieren Telemetrie-Topics, führen Modelle aus und veröffentlichen die Ergebnisse zurück an den Broker.
Was ist der beste erste KI-Anwendungsfall für einen digitalen Zwilling?
Anomalieerkennung ist meist der einfachste Einstieg, weil sie überwiegend mit normalen Betriebsdaten trainiert werden kann und nicht viele gelabelte Ausfälle erfordert.
Wie halte ich KI-Vorhersagen im Zwilling aktuell?
Veröffentlichen Sie Vorhersagen mit Zeitstempel und Modellversion, nutzen Sie die Message Expiry von MQTT 5, damit veraltete Ergebnisse verschwinden, und trainieren Sie Modelle neu, wenn sich Prozess oder Sensoren ändern.



