Industrieller KI-Copilot für Bediener mit Live-MQTT-Daten

Ein industrieller KI-Copilot ist ein Assistent, mit dem Bediener Fragen in natürlicher Sprache stellen können, etwa „Warum ist Linie 2 nach der Mittagspause langsamer geworden?“, und Antworten erhalten, die auf echten Anlagendaten beruhen. In diesem Leitfaden erfahren Sie, wie ein solcher Copilot aufgebaut ist, warum ein gut strukturierter ISA-95-Topic-Baum in einem Unified Namespace (UNS) die wichtigste Zutat ist und wie Sie einen reinen Lese-Copiloten an Live-MQTT-Daten anbinden, ohne ihn an die Maschinen zu lassen.

Was ein industrieller KI-Copilot tatsächlich tut

Der Begriff „Copilot“ wird lose verwendet, daher lohnt sich Präzision. In einer Anlage erledigt ein nützlicher Copilot vier Dinge:

Beantwortet Statusfragen aus Live-Daten: aktuelle Geschwindigkeit, Temperatur, Alarmzustand, letztes Gutteil.
Erklärt Zusammenhänge, indem er Live-Werte mit Dokumenten kombiniert: die SOP zu einem Fehlercode, die Wartungshistorie einer Pumpe, die Checkliste für den Produktwechsel.
Fasst zusammen – Schichten, Alarme und Stillstände in einer Sprache, die ein Schichtleiter in eine Übergabenotiz kopieren kann.
Schlägt nächste Schritte vor, überlässt Entscheidung und Handlung aber einem Menschen.

Was er zumindest anfangs nicht tun sollte, ist Befehle zu erteilen. Ein Copilot, der liest, ist ein Produktivitätswerkzeug. Ein Copilot, der auf Anlagen schreibt, ist ein Steuerungssystem und erfordert ein anderes Maß an Engineering, das wir in unserem Leitfaden zur sicheren KI-Steuerung von IoT-Geräten behandeln.

Das große Sprachmodell (LLM) selbst weiß nichts über Ihre Anlage. Alles, was die Antwort korrekt macht, stammt aus den Daten, die Sie ihm zum Zeitpunkt der Frage übergeben. Deshalb ist die Architektur rund um das Modell weit wichtiger als die Wahl des Modells.

Warum strukturierte Live-Daten einen Datendump schlagen

Der naive Ansatz ist, eine CSV-Datei mit Tags zu exportieren und in den Prompt zu kopieren. Das scheitert schnell: Tag-Namen wie PLC3_DB12_W4 bedeuten einem Modell nichts, der Schnappschuss ist veraltet, bis jemand die Antwort liest, und das Kontextfenster füllt sich mit irrelevanten Werten.

Ein nach ISA-95 strukturierter Namensraum löst alle drei Probleme. Wenn jeder Wert unter einem Pfad wie acme/plant1/assembly/line2/press4/temperature liegt, trägt die Hierarchie selbst Bedeutung. Das Modell erkennt, dass press4 zu line2 gehört, die wiederum zu assembly gehört. Eine Frage zu „Linie 2“ lässt sich ganz natürlich auf einen Topic-Filter acme/plant1/assembly/line2/# abbilden. Genau das ist der UNS: Die ISA-95-Ebenen Unternehmen → Standort → Bereich → Linie → Zelle bilden die Topic-Struktur auf dem MQTT-Broker, in einem deutschen Werk etwa acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur. Unser Artikel zu MQTT Sparkplug B und dem Unified Namespace erklärt das Konzept im Detail.

Datenansatz	Aktualität	Bedeutung für das LLM	Kontextkosten
Roher SPS-Tag-Export	Veralteter Schnappschuss	Gering, kryptische Namen	Hoch
Nur Historian-Abfrage	Gut für Historie, langsam für „jetzt“	Mittel	Mittel
ISA-95-MQTT-Topics mit retained Werten	Live	Hoch, Hierarchie ist selbstbeschreibend	Gering, Filter nach Teilbaum
ISA-95-Topics plus Dokumentabruf	Live plus Verfahren	Am höchsten	Gering bis mittel

MQTT passt hier ideal, weil der Broker bereits den letzten retained Wert jedes Topics hält. Ein Copilot-Dienst kann den Teilbaum abonnieren, der ihn interessiert, einen Schnappschuss im Arbeitsspeicher halten und dem Modell nur den für die Frage relevanten Teil übergeben.

Referenzarchitektur für einen industriellen KI-Copiloten

Ein praxistauglicher Aufbau besteht aus fünf Teilen:

Edge-Publisher: SPS-Gateways, Sparkplug-B-Edge-Nodes oder kleine Python-Dienste veröffentlichen Maschinendaten an den Broker.
Der MQTT-Broker in der Mitte. ConnectMQ erkennt ISA-95- und UNS-Topics und kann Sparkplug-B-Payloads dekodieren und in lesbare ISA-95-Topics erneut veröffentlichen, zum Beispiel wird spBv1.0/factory1/DDATA/line1/cnc1 zu connectmq/factory1/production/line1/cnc1/telemetry. Genau dieser erneut veröffentlichte Baum hat die Form, mit der ein Sprachmodell gut umgehen kann.
Ein Copilot-Dienst, der sich als gewöhnlicher MQTT-Client mit dem Broker verbindet, rein lesend abonniert und einen Live-Schnappschuss pflegt.
Tools, die das LLM aufrufen kann, etwa get_area_snapshot(path) oder list_active_alarms(line). Das Modell fragt den Broker nie direkt ab; es fragt Ihren Code.
Ein Dokumentindex für Verfahren und Handbücher – das Gebiet von Retrieval-Augmented Generation für Industriedaten.

Der Copilot-Dienst ist Ihr Code, läuft auf Ihrer Infrastruktur und spricht mit dem LLM-Anbieter Ihrer Wahl. ConnectMQ ist die Messaging-Schicht; es führt das Modell nicht aus. Diese Trennung ist gesund: Sie können Modelle wechseln, ohne die Anlage anzufassen.

Wenn Ihnen die Rolle des Brokers in diesem Bild neu ist, bietet unsere Erklärung, was ein MQTT-Broker tut, einen schnellen Einstieg.

Die Live-Kontextschicht in Python bauen

Den Kern des Copiloten bildet ein kleiner Dienst, der einen Teil des Topic-Baums im Arbeitsspeicher spiegelt und als Tool bereitstellt. Das folgende Beispiel nutzt paho-mqtt 2.x und den öffentlichen MQTT-Broker, sodass Sie es sofort ausführen können; er ist für Tests und Prototypen gedacht, nicht für Produktionsdaten. Ersetzen Sie das Präfix durch Ihre eigene zufällige ID.

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

BROKER = "broker.connectmq.com"
PREFIX = "connectmq/demo/k7f3q9/plant1"   # eigene Zufalls-ID verwenden
snapshot = {}
lock = threading.Lock()

def on_connect(client, userdata, flags, reason_code, properties):
    print("connected:", reason_code)
    client.subscribe(f"{PREFIX}/#", qos=1)

def on_message(client, userdata, msg):
    try:
        value = json.loads(msg.payload)
    except ValueError:
        value = msg.payload.decode(errors="replace")
    with lock:
        snapshot[msg.topic] = {"value": value, "received": time.time()}

def get_area_snapshot(path: str, max_age_s: int = 300) -> dict:
    """Tool exposed to the LLM: latest values under an ISA-95 path."""
    base = f"{PREFIX}/{path.strip('/')}"
    now = time.time()
    with lock:
        return {
            topic[len(PREFIX) + 1:]: {
                "value": entry["value"],
                "age_s": round(now - entry["received"]),
                "stale": now - entry["received"] > max_age_s,
            }
            for topic, entry in snapshot.items()
            if topic == base or topic.startswith(base + "/")
        }

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="copilot-reader-k7f3q9")
client.on_connect = on_connect
client.on_message = on_message
client.connect(BROKER, 1883, keepalive=60)
client.loop_start()

if __name__ == "__main__":
    time.sleep(3)
    print(json.dumps(get_area_snapshot("assembly/line2"), indent=2))

Damit es etwas zu lesen gibt, veröffentlichen Sie in einem anderen Terminal einige retained Werte:

mosquitto_pub -h broker.connectmq.com -p 1883 -i seed-k7f3q9 -r -q 1 \
  -t connectmq/demo/k7f3q9/plant1/assembly/line2/press4/temperature -m '{"c": 71.4}'
mosquitto_pub -h broker.connectmq.com -p 1883 -i seed-k7f3q9 -r -q 1 \
  -t connectmq/demo/k7f3q9/plant1/assembly/line2/press4/state -m '"RUNNING"'

Drei Designentscheidungen in diesem Code sind wichtiger, als sie aussehen:

Alter und Aktualität werden mit jedem Wert zurückgegeben. Ein LLM meldet eine zwei Stunden alte Temperatur bereitwillig als aktuell. Wird Veraltung explizit gemacht, kann das Modell „keine aktuellen Daten“ sagen, statt Sicherheit vorzutäuschen. Beachten Sie, dass ein retained Wert, der beim Abonnieren zugestellt wird, einen frischen Empfangszeitstempel erhält; für eine strenge Veraltungsprüfung sollten Sie daher einen Quellzeitstempel in den Payload aufnehmen.
Pfade sind relativ und eingegrenzt. Das Tool liest ausschließlich unterhalb von PREFIX, sodass ein verwirrtes Modell nicht in andere Namensräume abschweifen kann.
Der Dienst ist rein lesend. Er abonniert und veröffentlicht nie auf Anlagen-Topics.

Anschließend registrieren Sie get_area_snapshot als Tool (Funktion) bei der von Ihnen verwendeten LLM-API. Unser Leitfaden zu LLM Function Calling für IoT führt durch das Muster für Tool-Schemas, und wenn Sie eine Standardschnittstelle bevorzugen, stellt ein MCP-Server für MQTT dieselbe Fähigkeit jedem kompatiblen Client zur Verfügung.

Den Copiloten für Anlagenfragen prompten

Der System-Prompt sollte den Namensraum beschreiben, nicht die Daten. So etwas funktioniert gut:

You are an assistant for operators at plant1.
Live data is organised as <area>/<line>/<cell>/<signal>, for example assembly/line2/press4/temperature.
Use get_area_snapshot(path) to read live values. Never guess a value you did not read.
If a value is marked stale, say so. You cannot change any equipment. For actions, tell the operator what to check.
Answer in short sentences and quote the topic path for every number you mention.

Das Modell aufzufordern, für jede Zahl den Topic-Pfad zu nennen, ist eine günstige und wirkungsvolle Gewohnheit. Bediener können jede Aussage im Live-Topic-Explorer überprüfen, und falsche Antworten lassen sich leicht erkennen und melden.

Design-Checkliste für einen industriellen KI-Copiloten

Bevor Sie einen Copiloten einem Schichtteam zeigen, gehen Sie diese Liste durch:

Qualität des Namensraums: Folgen die Topics einem UNS nach ISA-95 und sind sie bis auf Signalebene einheitlich benannt, mit Einheiten im Payload oder im Namen?
Retained Werte: Veröffentlicht jedes Zustands-Topic retained, damit ein neuer Subscriber sofort aktuelle Werte sieht?
Reine Lese-Zugangsdaten: Nutzt der Copilot-Dienst eigene Zugangsdaten, die nie für Befehls-Topics verwendet werden?
Umgang mit Veraltung: Enthält jedes Tool-Ergebnis das Alter, und weist der Prompt das Modell an, es zu beachten?
Nachvollziehbarkeit: Nennt jede Antwort Topic-Pfade oder Dokumentquellen?
Protokollierung: Werden Fragen, Tool-Aufrufe und Antworten zur Überprüfung protokolliert, unter Beachtung von DSGVO und Betriebsvereinbarungen, wenn Bedienerfragen personenbezogen sind?
Umfang: Ist der Copilot auf die Linien und Bereiche beschränkt, für die der Benutzer verantwortlich ist?
Eskalation: Sagt der Copilot dem Bediener, wen er anrufen soll, wenn er nicht antworten kann?

Häufige Fallstricke

Halluzinierte Messwerte. Das Modell füllt Lücken mit plausiblen Zahlen. Gegenmaßnahme: die Anweisung „niemals raten“ plus Tool-Ergebnisse, die fehlende Daten klar ausweisen.

Zu viel Kontext. Die gesamte Anlage in jede Anfrage zu kippen ist langsam und verwirrt das Modell. Lassen Sie das Modell das Tool mit einem engen Pfad aufrufen und fassen Sie numerische Reihen zusammen, bevor Sie sie zurückgeben.

Verwechslung von Einheiten. Ein Wert 71.4 ohne Einheit lädt zu Fehlern ein. Nehmen Sie Einheiten in den Payload ({"c": 71.4}) oder in Metadaten auf, die das Tool zurückgibt.

Sensible Daten auf öffentlichen Brokern. Der öffentliche MQTT-Broker unter broker.connectmq.com ist für jeden lesbar, der das Topic errät. Für diese Demo ist das in Ordnung, aber produktive Anlagendaten gehören auf einen privaten Broker mit eigenen Zugangsdaten.

Den Copiloten als Autorität behandeln. Bediener sollten ihn als schnellen Kollegen sehen, der Bildschirme liest, nicht als Sicherheitssystem. Lassen Sie Alarmbehandlung und Verriegelungen, wo sie sind.

Den Copiloten mit Produktionsdaten betreiben

Der Schritt von der Demo zu einer echten Linie bedeutet hauptsächlich, die Verbindung zu ändern. Erstellen Sie im ConnectMQ-Portal einen Broker, kopieren Sie die generierten Zugangsdaten und verbinden Sie sich über TLS:

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="YOUR_CLIENT_ID")
client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.tls_set()  # der System-CA-Speicher vertraut dem Let's-Encrypt-Zertifikat
client.connect("broker.connectmq.com", 8883, keepalive=60)

Ein verwalteter MQTT-Broker streicht den Broker von Ihrer Liste der Systeme, die gepatcht und überwacht werden müssen, sodass sich das Team auf die Qualität des Namensraums und den Copiloten selbst konzentrieren kann. Einen breiteren Blick darauf, wie KI und Messaging zusammenpassen, bietet der Leitfaden zu KI und IoT, und zu Hosting-Optionen lesen Sie mehr über den Ansatz eines Cloud-MQTT-Brokers.

Geben Sie Ihrem Copiloten einen Live-Namensraum der Anlage

Ein Copilot braucht eine saubere, live verfügbare, gut strukturierte Datenquelle, bevor er ein größeres Modell braucht. ConnectMQ bietet Ihnen einen verwalteten MQTT-Broker mit ISA-95-Topic-Erkennung, Sparkplug-B-Dekodierung und einem Live-Topic-Explorer, in dem Sie prüfen können, was der Copilot sieht. Erstellen Sie einen kostenlosen Serverless-Broker unter app.connectmq.com, ohne Kreditkarte, und richten Sie den oben gezeigten Lesedienst darauf aus.

Häufig gestellte Fragen

Enthält ConnectMQ einen KI-Copiloten?

Nein. ConnectMQ ist der MQTT-Broker, der die Live-Daten liefert. Der Copilot ist Ihr eigener Dienst, der sich als MQTT-Client verbindet und das LLM Ihrer Wahl aufruft.

Sollte ein industrieller KI-Copilot Maschinen steuern dürfen?

Nicht am Anfang. Beginnen Sie rein lesend, weisen Sie Genauigkeit und Nutzen nach und fügen Sie erst später streng abgesicherte, vom Menschen bestätigte Aktionen mit Allowlists, Ratenbegrenzung und Audit-Logs hinzu.

Warum hilft die ISA-95-Struktur einem Sprachmodell?

Die Hierarchie aus Unternehmen, Standort, Bereich, Linie und Zelle wird im UNS zur Topic-Struktur und gibt jedem Wert einen selbstbeschreibenden Pfad, sodass das Modell eine Frage zu „Linie 2“ auf einen präzisen Topic-Filter abbilden kann, statt kryptische Tag-Namen zu erraten.

Kann der Copilot auch historische Daten nutzen?

Ja. Live-MQTT-Werte beantworten „Was passiert gerade?“, während ein Historian oder eine Zeitreihendatenbank „Was ist passiert?“ beantwortet. Stellen Sie beides als separate Tools bereit, damit das Modell die richtige Quelle wählt.

Industrieller KI-Copilot für Bediener: Antworten auf Live-ISA-95-Daten stützen