Generative KI in der Fertigung: praxisnahe Anwendungsfälle auf Basis von Anlagendaten

Generative KI in der Fertigung ist dann am wertvollsten, wenn sie auf echten Anlagendaten statt auf Allgemeinwissen aufsetzt. Dieser Artikel stellt Anwendungsfälle vor, die sich in der realen Werkhalle bewähren, beschreibt die Datenanbindung, die sie benötigen, und die Leitplanken, die ein Sprachmodell nützlich statt riskant machen. Am Ende wissen Sie, mit welchem Projekt Sie beginnen sollten und wie Sie es per MQTT mit Live-Maschinendaten versorgen.

Warum Projekte mit generativer KI in der Fertigung ins Stocken geraten

Die meisten frühen Experimente wirken in der Demo beeindruckend und verlaufen dann im Sand. Das Muster ist bekannt: Jemand kopiert ein paar Alarmcodes in ein Chatfenster, erhält eine plausible Erklärung, und das Team schließt daraus, dass das Modell die Maschinen „kennt“. Eine Woche später erklärt es selbstbewusst einen Alarm, den es auf dieser Steuerung gar nicht gibt.

Das eigentliche Problem ist die fehlende Verankerung in Daten (Grounding). Ein großes Sprachmodell verfügt über breites Wissen zu CNC-Maschinen, SPSen und Qualitätsmethoden, weiß aber nichts über Ihre Linie 3, Ihr Rezept für Teil 4711 oder die Tatsache, dass der Ofen in der Nachtschicht immer zehn Grad zu heiß läuft. Ohne diesen Kontext füllt es die Lücke mit Vermutungen.

Die sinnvolle Frage lautet also nicht „Was kann generative KI?“, sondern „Welche Aufgaben bestehen hauptsächlich darin, vorhandene Daten und Dokumente in Text zu verwandeln, und wo können wir dem Modell diese Daten zuverlässig bereitstellen?“ Diese Umformulierung führt zu einer kurzen Liste von Anwendungsfällen, die funktionieren.

Anwendungsfälle, die heute funktionieren

Schichtberichte und Stillstandszusammenfassungen

Das ist der einfachste Erfolg. In jedem Werk gibt es jemanden, der die letzte halbe Stunde einer Schicht damit verbringt zusammenzutragen, was passiert ist: welche Maschinen standen, warum, wie viele Teile produziert wurden und worauf die nächste Schicht achten sollte. Die Daten liegen bereits als Maschinenzustände und Zähler vor. Ein kleiner Dienst kann die Ereignisse der Schicht sammeln, eine strukturierte Zusammenfassung erstellen (Zahlen im Code berechnet, nicht vom Modell) und das Sprachmodell bitten, daraus lesbaren Fließtext zu machen.

Die wichtige Designentscheidung lautet: Das Modell schreibt, es rechnet nicht. Berechnen Sie OEE, Stillstandsminuten und Stückzahlen in Python oder SQL, übergeben Sie sie als Fakten und weisen Sie das Modell an, nur diese Werte zu verwenden. Eine ausführlichere Anleitung zu diesem Muster finden Sie unter LLM-Zusammenfassungen von Sensordaten.

Assistenten für die Fehlersuche

Wenn eine Maschine um 3 Uhr nachts Alarm schlägt, braucht der Techniker die passende Handbuchseite, den letzten ähnlichen Vorfall und den aktuellen Zustand der zugehörigen Signale. Ein Assistent für die Fehlersuche ruft diese Informationen ab und präsentiert sie zusammen mit einer vorgeschlagenen Checkliste. Kern ist die Suche über Handbücher und frühere Tickets, weshalb dieser Anwendungsfall meist auf Retrieval-Augmented Generation für Industriedaten aufbaut.

Der Live-Anteil ist ebenso wichtig wie die Dokumente. Ein Assistent, der „Spindeltemperatur steigt seit 20 Minuten, Kühlmittelfluss um 02:41 Uhr gesunken“ sieht, macht weit bessere Vorschläge als einer, der nur die Alarmnummer kennt.

Hilfe bei Code und Integration

Ingenieure verbringen erstaunlich viel Zeit mit dem Schreiben von Verbindungscode: einer Node-RED-Funktion zum Umformen eines Payloads, einem Python-Subscriber, einer SQL-Abfrage für einen Bericht. Sprachmodelle können so etwas gut entwerfen, wenn sie echte Beispiele sehen. Geben Sie dem Modell einen Beispiel-Payload aus MQTT und Ihre Topic-Konvention, und es entwirft in Sekunden einen Parser. Behandeln Sie das Ergebnis wie Code von einem neuen Kollegen: prüfen, mit dem öffentlichen MQTT-Broker testen und dann übernehmen.

Industrielle Copiloten

Kombinieren Sie die drei genannten Punkte, und Sie erhalten, was Anbieter einen industriellen KI-Copiloten nennen: eine Oberfläche, über die ein Bediener Fragen stellt, Zusammenfassungen erhält und Maßnahmen entwirft. Beginnen Sie mit reinem Lesezugriff. Sollwerte oder Befehle aus einem Modell heraus zu schreiben, ist ein eigenes, deutlich schwierigeres Problem mit eigenen Schutzmechanismen.

Die Datengrundlage: Anlagendaten per MQTT streamen

Jeder der genannten Anwendungsfälle hängt von aktuellen, strukturierten Daten ab. MQTT passt hier hervorragend, weil Maschinen, Gateways und Edge-Geräte bereits dorthin veröffentlichen und beliebig viele Konsumenten abonnieren können, ohne die Maschinen anzufassen.

Die tragfähigste Struktur dafür ist ein Unified Namespace (UNS): Die ISA-95-Gerätehierarchie (Enterprise → Site → Area → Line → Cell) wird zur Topic-Struktur auf dem MQTT-Broker, etwa acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur. SPS-Gateways, OPC-UA-Server, MES und KI-Dienste lesen und schreiben dann an einer gemeinsamen Stelle, statt über Punkt-zu-Punkt-Schnittstellen verbunden zu sein. Wie Sparkplug B in dieses Bild passt, erklärt der Beitrag zu Sparkplug B und dem Unified Namespace. Ein vereinfachtes Beispiel nach den ISA-95-Ebenen, das sowohl Menschen als auch Modelle lesen können:

connectmq/factory1/production/line1/cnc1/telemetry
connectmq/factory1/production/line1/cnc1/state
connectmq/factory1/production/line1/cnc1/alarms

Ein typischer Telemetrie-Payload:

{
  "ts": "2026-10-16T02:41:12Z",
  "spindleTempC": 61.4,
  "coolantFlowLpm": 8.2,
  "spindleLoadPct": 74,
  "partCount": 1532
}

Lesbare Topic-Namen erfüllen einen doppelten Zweck: Sie helfen Menschen in einem Topic-Explorer und liefern dem Modell Kontext gratis. Ein Modell, das line1/cnc1/alarms sieht, muss nicht erst erklärt bekommen, um welche Daten es sich handelt. Und weil der UNS den aktuellen Zustand jeder Maschine an einer Stelle bündelt, braucht ein KI-Dienst nur ein einziges Wildcard-Abonnement pro Werk oder Linie, um seinen Kontext aufzubauen.

Ein minimaler Schicht-Collector in Python

Der folgende Dienst abonniert einen ganzen Standort, hält den letzten Zustand pro Maschine vor und zählt Alarme. Am Schichtende würde er diese strukturierte Zusammenfassung an das von Ihnen verwendete LLM übergeben. Er nutzt den öffentlichen MQTT-Broker unter broker.connectmq.com, der nur für Tests und Prototypen gedacht ist; verwenden Sie daher nur synthetische Daten.

import json
import time
import uuid
from collections import defaultdict

import paho.mqtt.client as mqtt

PREFIX = "connectmq/demo/genai-7f3a"
latest = {}
alarm_counts = defaultdict(int)


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


def on_message(client, userdata, msg):
    parts = msg.topic.split("/")
    machine = "/".join(parts[-3:-1])  # z. B. line1/cnc1
    kind = parts[-1]
    try:
        payload = json.loads(msg.payload)
    except json.JSONDecodeError:
        return
    if kind == "alarms":
        alarm_counts[machine] += 1
    else:
        latest.setdefault(machine, {}).update(payload)


def build_summary():
    return {
        "machines": latest,
        "alarmCounts": dict(alarm_counts),
        "generatedAt": time.strftime("%Y-%m-%dT%H:%M:%SZ", time.gmtime()),
    }


client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
                     client_id=f"shift-collector-{uuid.uuid4().hex[:8]}")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=60)
client.loop_start()

try:
    while True:
        time.sleep(60)
        summary = build_summary()
        print(json.dumps(summary, indent=2))
        # `summary` mit einem Prompt wie diesem an Ihr LLM übergeben:
        # "Write a shift report using ONLY these facts. Do not invent numbers."
except KeyboardInterrupt:
    client.loop_stop()
    client.disconnect()

Beachten Sie, dass der Broker hier keinerlei KI-Arbeit leistet. ConnectMQ transportiert die Daten zuverlässig; der Collector und das Modell sind Ihre eigenen Dienste, die sich als gewöhnliche MQTT-Clients verbinden. Diese Trennung ist gesund: Sie können Modelle austauschen, ohne die Maschinen anzufassen.

Leitplanken, die generative KI nützlich halten

Eine nummerierte Checkliste, die sich für jedes Pilotprojekt mit generativer KI in der Fertigung lohnt:

1. Fakten hinein, Text heraus. Berechnen Sie alle Zahlen außerhalb des Modells und weisen Sie es an, nur die bereitgestellten Werte zu verwenden.
2. Quelle angeben. Lassen Sie das Modell das Topic, Dokument oder Ticket nennen, aus dem jede Aussage stammt, und zeigen Sie das dem Nutzer.
3. Zuerst nur lesen. Keine Befehls-Topics in Reichweite des Modells, bis sich die Nur-Lesen-Version Vertrauen erarbeitet hat.
4. Menschliche Freigabe für Aktionen. Entwirft das Modell einen Arbeitsauftrag oder eine Sollwertänderung, gibt ein Mensch sie frei. Muster für die Befehlsseite finden Sie unter Sichere KI-Steuerung von IoT-Geräten.
5. Prompts und Antworten protokollieren. Sie brauchen sie, um falsche Antworten zu analysieren und Prompts zu verbessern.
6. Sensible Daten privat halten. Verwenden Sie für echte Anlagendaten einen privaten Broker mit Zugangsdaten, niemals einen öffentlichen MQTT-Broker.
7. Nutzen messen. Fragen Sie die Bediener, ob ihnen die Zusammenfassung Zeit gespart hat; streichen Sie Anwendungsfälle, bei denen das nicht der Fall ist.

Wo das Modell laufen soll

Gehostete LLM-APIs sind der schnellste Einstieg und für Zusammenfassungen nicht sensibler Daten gut geeignet. Werke mit strengen Datenrichtlinien betreiben offene Modelle oft lokal; ein On-Premises-Server mit einer lokalen Modell-Runtime, der den Werks-Broker abonniert, kann das leisten, ohne dass Daten den Standort verlassen. In beiden Fällen ist der Datenpfad derselbe: Maschinen veröffentlichen an den Broker, ein Subscriber baut den Kontext auf, das Modell schreibt Text, und das Ergebnis geht zurück an ein Topic, ein Ticketsystem oder eine E-Mail.

Wenn Sie die übergreifende Architektur aus Modellen, Edge-Geräten und Brokern planen, zeigt der Leitfaden zu KI und IoT, wo welcher Modelltyp hingehört.

Die Infrastruktur richtig aufsetzen

Sobald mehrere Dienste dieselben Anlagendaten lesen, wird der Broker zu einer gemeinsamen Abhängigkeit. Er sollte daher keine vergessene virtuelle Maschine unter irgendeinem Schreibtisch sein. Ein verwalteter MQTT-Broker bietet TLS, Zugangsdaten und Monitoring, ohne dass Sie den Server selbst betreiben müssen. ConnectMQ erkennt außerdem ISA-95- und UNS-Topics und kann Sparkplug-B-Daten in lesbare ISA-95-Topics umveröffentlichen – genau die Art von Struktur, die Anlagendaten für Menschen und Modelle leichter nutzbar macht.

Für Prototypen können Sie mit dem öffentlichen MQTT-Broker unter broker.connectmq.com den Collector und die Prompts mit simulierten Daten entwickeln, bevor irgendetwas die Produktion berührt.

Starten Sie Ihre Anlagendaten-Pipeline mit ConnectMQ

Generative KI ist nur so gut wie die Daten, die Sie ihr geben. Erstellen Sie unter app.connectmq.com einen privaten Broker im kostenlosen Serverless-Tarif, ganz ohne Kreditkarte, verbinden Sie ein Gateway oder einen Simulator und beobachten Sie im Live-Topic-Explorer, wie die Topics eintreffen. Sobald die Daten fließen, ist Ihr erster Schichtberichtsgenerator die Arbeit eines Nachmittags.

Häufig gestellte Fragen

Was ist das beste erste Projekt mit generativer KI in einer Fabrik?

Automatisierte Schicht- oder Stillstandszusammenfassungen. Die Daten liegen bereits vor, das Ergebnis ist leicht zu überprüfen, und ein falscher Satz kostet wenig, weil ein Mensch ihn liest, bevor er handelt.

Kann ein Sprachmodell Maschinen direkt steuern?

Das sollte es nicht – zumindest nicht ohne strenge Grenzen und menschliche Freigabe. Beginnen Sie mit Assistenten mit reinem Lesezugriff und ergänzen Sie Befehlspfade nur mit Validierung, Positivlisten und Bestätigungsschritten.

Enthält ConnectMQ KI-Funktionen?

Nein. ConnectMQ ist der MQTT-Broker, der die Anlagendaten transportiert; Ihre LLM-Anwendung verbindet sich als normaler MQTT-Client, sodass Sie das Modell frei wählen können.

Wie verhindere ich, dass das Modell Zahlen erfindet?

Berechnen Sie jede Kennzahl im Code, übergeben Sie die Ergebnisse als strukturierte Fakten und weisen Sie das Modell an, nur diese Werte zu verwenden. Werden die Ausgaben während des Pilotprojekts mit den Quelldaten abgeglichen, fallen verbleibende Probleme auf.