KI-gestützte visuelle Inspektion in der Fertigung: von der Kamera zu Gut/Schlecht über MQTT

Die KI-gestützte visuelle Inspektion nutzt Kameras und trainierte Modelle, um zu entscheiden, ob ein Bauteil in Ordnung oder fehlerhaft ist, und zwar in Liniengeschwindigkeit und ohne Ermüdung des Bedienpersonals. Dieser Artikel erklärt, wie eine Inspektionsstation aufgebaut ist, welche Fehler KI besser erkennt als regelbasierte Bildverarbeitung und wie Sie jedes Gut/Schlecht-Ergebnis über MQTT veröffentlichen, damit Liniensteuerung, Dashboards und Rückverfolgungsdaten synchron bleiben.

Was KI-gestützte visuelle Inspektion leistet

Klassische Bildverarbeitung beruht auf manuell abgestimmten Regeln: eine Kante vermessen, Pixel oberhalb eines Schwellenwerts zählen, mit einer Vorlage vergleichen. Das funktioniert gut für Maßprüfungen an gleichbleibenden Teilen. Schwierig wird es, wenn Fehler in Form und Aussehen variieren, etwa Kratzer, Dellen, Porosität, Verschmutzungen, faltige Etiketten oder ungleichmäßige Schweißnähte, oder wenn sich Beleuchtung und Oberflächenbeschaffenheit im Laufe einer Schicht ändern.

Die KI-gestützte visuelle Inspektion ersetzt oder ergänzt diese Regeln durch ein gelerntes Modell. Je nach Aufgabe handelt es sich um eine von drei Arten:

1. Klassifikation: Das gesamte Bild wird als ok oder ng (not good, also nicht in Ordnung) gekennzeichnet oder einer Fehlerklasse zugeordnet.
2. Objekterkennung oder Segmentierung: Das Modell zeichnet Boxen oder Masken um Fehler, sodass Sie wissen, wo sie liegen und wie groß sie sind.
3. Anomalieerkennung: Das Modell wird überwiegend mit guten Teilen trainiert und markiert alles, was ungewöhnlich aussieht. Das ist wertvoll, wenn fehlerhafte Muster selten sind, was an einer ausgereiften Linie häufig vorkommt.

Das für die Fabrik relevante Ergebnis ist einfach: ein Urteil, eine Konfidenz, der Fehlertyp und eine Kennung, die das Ergebnis einem bestimmten Bauteil zuordnet.

Aufbau einer Inspektionsstation

Eine funktionierende Station ist weit mehr als ein Modell. Die Komponenten, die über Erfolg oder Misserfolg entscheiden, sind meist physischer Natur.

Die Beleuchtung verdient die meiste Aufmerksamkeit. Eine gute Beleuchtung macht Fehler für einen Menschen schon im Rohbild offensichtlich; wenn Sie den Kratzer nicht sehen, wird das Modell ihn kaum zuverlässig lernen.

Das Fehlermodell aufbauen

Der Modell-Workflow folgt einem vorhersehbaren Weg:

1. Bilder an der echten Station sammeln, mit der endgültigen Kamera, Optik und Beleuchtung. Bilder von einem Smartphone auf der Werkbank lassen sich nicht übertragen.
2. Konsistent labeln. Erstellen Sie einen kurzen Fehlerkatalog mit Beispielen für jede Klasse und der Grenze zwischen akzeptabel und Ausschuss. Uneinigkeit zwischen den Labelnden wird zu Rauschen im Modell.
3. Trainieren und validieren mit Bildern, die das Modell noch nie gesehen hat, einschließlich Teilen aus verschiedenen Chargen und Schichten.
4. Den Schwellenwert gemeinsam mit der Qualitätssicherung festlegen. Ein übersehener Fehler (Schlupf) und ein ausgeschleustes Gutteil (Pseudoausschuss) verursachen sehr unterschiedliche Kosten, daher ist der Konfidenz-Schwellenwert eine geschäftliche Entscheidung.
5. Zuerst im Schattenbetrieb laufen lassen: Das Modell veröffentlicht Urteile, löst aber keine Ausschleusung aus, und Sie vergleichen mit der manuellen Prüfung.
6. An der Edge bereitstellen, typischerweise als optimiertes Modell auf einer GPU oder einem Beschleuniger neben der Kamera. Unter ML-Modelle auf Edge-Geräten bereitstellen finden Sie Strategien für Paketierung und Updates.

Die Inferenz gehört an die Edge, weil die Ausschleusungsentscheidung fallen muss, bevor das Teil das Ausschleusfenster verlässt. Vollständige Bilder in die Cloud zu senden kostet Latenz und Bandbreite ohne jeden Nutzen. Über das Netzwerk wandert das Ergebnis. Der Vergleich Edge AI vs. Cloud AI behandelt diesen Zielkonflikt ausführlicher.

Warum MQTT für Ergebnisse der KI-gestützten visuellen Inspektion

Ein Inspektionsurteil hat mehrere Konsumenten: die SPS oder Liniensteuerung, die die Ausschleusung auslöst, das MES oder die Rückverfolgungsdatenbank, die das Ergebnis einer Seriennummer zuordnet, eine Andon-Tafel, ein Qualitäts-Dashboard und während der Inbetriebnahme womöglich der Laptop eines Ingenieurs. Punkt-zu-Punkt-Verbindungen zu jedem davon sind fehleranfällig. Mit Publish/Subscribe veröffentlicht die Station einmal, und jeder Konsument abonniert, was er braucht.

MQTT passt hier gut, weil es schlank ist, QoS 1 für eine Zustellung mindestens einmal unterstützt und es erlaubt, einen Stationsstatus als Retained Message zu veröffentlichen, sodass ein später gestartetes Dashboard sofort weiß, ob die Station online ist. Topic-Hierarchien nach den ISA-95-Ebenen geben jedem Ergebnis eine klare Adresse. Das ist das Prinzip eines Unified Namespace (UNS): Enterprise → Site → Area → Line → Cell wird zur Topic-Struktur auf dem MQTT-Broker, sodass die Prüfstation in einem deutschen Werk etwa unter acme/werk-stuttgart/montage/linie-2/pruefzelle-1/ergebnis publiziert, direkt neben den Maschinendaten derselben Linie. Im Beispiel unten sieht das so aus:

connectmq/plant1/assembly/line2/inspect1/result
connectmq/plant1/assembly/line2/inspect1/status
connectmq/plant1/assembly/line2/inspect1/stats
connectmq/plant1/assembly/line2/inspect1/cmd/threshold

ConnectMQ erkennt Topics im Stil von ISA-95 und UNS und zeigt Geräte in seiner Geräteansicht nach Unternehmen, Standort, Bereich, Linie und Zelle an, was die Navigation in einer wachsenden Zahl von Inspektionsstationen erleichtert. Wenn Sie an der Linie bereits Sparkplug B einsetzen, erklärt der Leitfaden zu Sparkplug B und Unified Namespace, wie beide Topic-Stile nebeneinander bestehen.

Gestaltung des Ergebnis-Payloads

Verwenden Sie eine Nachricht pro geprüftem Teil, klein und selbstbeschreibend:

{
  "partId": "SN-24-104877",
  "ts": "2026-10-16T09:41:07.312Z",
  "verdict": "ng",
  "defect": "scratch",
  "confidence": 0.93,
  "bbox": [412, 188, 470, 214],
  "model": "housing-defects-v7",
  "threshold": 0.80,
  "inferenceMs": 18,
  "imageRef": "inspect1/2026-10-16/SN-24-104877.jpg"
}

Die Felder model und threshold machen Ergebnisse auch Monate später rückverfolgbar: Wenn eine Kundenreklamation eintrifft, können Sie zeigen, welche Modellversion das Teil mit welcher Einstellung bewertet hat. Das Bild selbst bleibt im lokalen Speicher oder wandert in einen Bildspeicher; die MQTT-Nachricht enthält eine Referenz, nicht die Pixel.

Beispiel: Inspektionsergebnisse in Python veröffentlichen

Dieses Beispiel simuliert die Stationsschleife mit paho-mqtt 2.x. Ersetzen Sie run_model() durch Ihren echten Inferenzaufruf. Es veröffentlicht Ergebnisse mit QoS 1, einen Retained-Status online/offline mit Last Will und regelmäßige Ausbeutestatistiken.

import json
import random
import time
import uuid
from datetime import datetime, timezone

import paho.mqtt.client as mqtt

HOST, PORT = "broker.connectmq.com", 1883
RUN_ID = uuid.uuid4().hex[:8]
BASE = f"connectmq/demo/{RUN_ID}/plant1/assembly/line2/inspect1"
MODEL = "housing-defects-v7"
threshold = 0.80


def run_model(image=None):
    """Stand-in for real inference: returns (label, confidence, bbox)."""
    if random.random() < 0.08:
        return random.choice(["scratch", "dent", "missing_screw"]), random.uniform(0.6, 0.99), [412, 188, 470, 214]
    return "ok", random.uniform(0.85, 0.99), None


def on_connect(client, userdata, flags, reason_code, properties):
    print("connected:", reason_code)
    client.publish(f"{BASE}/status", "online", qos=1, retain=True)
    client.subscribe(f"{BASE}/cmd/threshold", qos=1)


def on_message(client, userdata, msg):
    global threshold
    try:
        value = float(msg.payload)
        if 0.5 <= value <= 0.99:
            threshold = value
            print("threshold set to", threshold)
    except ValueError:
        print("ignored invalid threshold", msg.payload)


client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=f"inspect1-{RUN_ID}")
client.will_set(f"{BASE}/status", "offline", qos=1, retain=True)
client.on_connect = on_connect
client.on_message = on_message
client.connect(HOST, PORT, keepalive=30)
client.loop_start()

ok = ng = 0
try:
    for n in range(1, 10_000):
        start = time.perf_counter()
        label, conf, bbox = run_model()
        inference_ms = round((time.perf_counter() - start) * 1000, 1)
        verdict = "ng" if label != "ok" and conf >= threshold else "ok"
        ok, ng = (ok + 1, ng) if verdict == "ok" else (ok, ng + 1)
        part_id = f"SN-{RUN_ID}-{n:06d}"
        result = {
            "partId": part_id,
            "ts": datetime.now(timezone.utc).isoformat(timespec="milliseconds"),
            "verdict": verdict,
            "defect": None if label == "ok" else label,
            "confidence": round(conf, 3),
            "bbox": bbox,
            "model": MODEL,
            "threshold": threshold,
            "inferenceMs": inference_ms,
        }
        client.publish(f"{BASE}/result", json.dumps(result), qos=1)
        if n % 20 == 0:
            stats = {"ok": ok, "ng": ng, "yield": round(ok / (ok + ng), 4)}
            client.publish(f"{BASE}/stats", json.dumps(stats), qos=1, retain=True)
        time.sleep(0.5)   # stays well under the public broker's 10 msg/s per client
finally:
    client.publish(f"{BASE}/status", "offline", qos=1, retain=True)
    client.loop_stop()
    client.disconnect()

Beobachten Sie die Ergebnisse in einem anderen Terminal und ersetzen Sie die ID durch die aus dem Topic:

mosquitto_sub -h broker.connectmq.com -p 1883 -i qa-viewer-91c2 \
  -t 'connectmq/demo/<run-id>/plant1/assembly/line2/inspect1/#' -v

Der öffentliche MQTT-Broker eignet sich gut, um Payload und Topic-Design in Tests und Prototypen auszuprobieren, ist aber für alle offen und nicht für Produktionsdaten gedacht. Produktive Inspektionsdaten gehören auf einen privaten Broker mit TLS auf Port 8883 und den Zugangsdaten und der Client ID, die für die Station ausgegeben wurden.

Den Kreis zur Liniensteuerung schließen

Der Ausschleusaktor sollte nicht von einem Umweg über die Cloud abhängen. In den meisten Werken signalisiert die Station die Ausschleusung selbst direkt über I/O oder einen Feldbus an die SPS, und MQTT transportiert dasselbe Urteil für alles andere: Zählung, Rückverfolgbarkeit, Dashboards und Alarme. Wo eine SPS oder ein Edge-Controller das Ergebnis-Topic tatsächlich abonniert, halten Sie den Broker nah an der Linie oder stellen Sie sicher, dass die Ausschleuslogik bei einem Verbindungsabbruch in einen sicheren Zustand fällt.

Einige Regeln halten das System verlässlich:

1. Veröffentlichen Sie eine Ausschleusbestätigung vom Sensor der Weiche, damit Sie ng-Urteile mit tatsächlichen Ausschleusungen abgleichen können.
2. Nehmen Sie die Modellversion in jede Nachricht auf und halten Sie ein status-Topic als Retained Message vor, das das aktive Modell beschreibt.
3. Beschränken Sie, wer an cmd/-Topics veröffentlichen darf, und validieren Sie jeden Befehlswert auf der Station, wie es das Beispiel für den Schwellenwert tut.
4. Lösen Sie bei einer Drift der Ausbeute Alarm aus. Ein plötzlicher Rückgang der Ausbeute ist oft ein Beleuchtungs- oder Kameraproblem und kein echtes Qualitätsproblem.

Schwellenwert-Alarmregeln in ConnectMQ können numerische Werte wie die Ausbeute in einer Statistiknachricht überwachen und Alarme im Alarmprotokoll festhalten. So bemerken Sie Drift schnell, ohne einen separaten Monitoring-Dienst aufzubauen.

Häufige Probleme in der Produktion

Für verwandte Vision-Projekte lesen Sie über YOLO-Objekterkennung über MQTT, den Leitfaden zu Jetson Nano und MQTT und den Grundlagenleitfaden zu KI und IoT.

Verbinden Sie Ihre Inspektionsstationen mit ConnectMQ

Jede Station, jedes Dashboard und jeder Rückverfolgungs-Writer braucht einen zuverlässigen Treffpunkt. ConnectMQ bietet Ihnen einen verwalteten MQTT-Broker mit TLS, MQTT 5, einer ISA-95-Geräteansicht und Schwellenwert-Alarmen, ohne dass Sie Broker-Infrastruktur im Werksnetz betreiben müssen. Erstellen Sie einen Broker im kostenlosen Serverless-Plan unter app.connectmq.com, ohne Kreditkarte, und wechseln Sie zu einer Dedicated- oder BYOC-Bereitstellung, wenn die Linie in Produktion geht. Wenn Sie noch evaluieren, ist der öffentliche MQTT-Broker ein guter Ort, um den Payload zu prototypisieren.

Häufig gestellte Fragen

Wie viele Bilder brauche ich, um ein Modell für KI-gestützte visuelle Inspektion zu trainieren?

Das hängt davon ab, wie vielfältig Teile und Fehler sind. Beginnen Sie mit Bildern von der echten Station, decken Sie jede Fehlerklasse und die normale Variation ab und ergänzen Sie Beispiele, sobald das Modell im Schattenbetrieb etwas übersieht.

Sollten Bilder über MQTT gesendet werden?

In der Regel nicht. Senden Sie Urteil, Konfidenz und eine Bildreferenz über MQTT und speichern Sie Bilder lokal oder in einem Objektspeicher, denn große Binärnachrichten stoßen an die Größenlimits des Brokers und verlangsamen jeden Abonnenten.

Kann KI-gestützte visuelle Inspektion die regelbasierte Bildverarbeitung ersetzen?

Nicht immer. Präzise Maßprüfungen erledigen Regeln nach wie vor am besten, während KI variable optische Fehler übernimmt. Viele Stationen kombinieren beides und veröffentlichen ein einziges Urteil.

Welche QoS sollten Inspektionsergebnisse verwenden?

QoS 1 ist die übliche Wahl, weil für die Rückverfolgbarkeit jedes Ergebnis ankommen muss. Gestalten Sie das Einfügen in die Datenbank anhand der Teile-ID idempotent, damit gelegentliche Duplikate keinen Schaden anrichten.