IoT-Qualitätskontrolle in der Fertigung: Echtzeitprüfung mit Inline-Sensoren und MQTT

IoT-Qualitätskontrolle in der Fertigung bedeutet, Produkt- und Prozessqualität kontinuierlich an der Linie zu messen, statt Probleme erst bei der Endprüfung oder durch eine Kundenreklamation zu entdecken. Dieser Leitfaden zeigt, welche Inline-Sensoren Sie einsetzen, wie Sie deren Messwerte per MQTT veröffentlichen, wie Sie Spezifikationsprüfungen in Echtzeit durchführen und wie derselbe Datenstrom die statistische Prozesslenkung und die Rückverfolgbarkeit speist.

Von der Stichprobe zu kontinuierlichen Qualitätsdaten

Klassische Qualitätskontrolle beruht auf Stichproben: Ein Prüfer entnimmt pro Stunde einige Teile, misst sie im Labor oder an einem Messplatz und trägt die Ergebnisse in eine Tabelle oder ein Qualitätssystem ein. Das funktioniert, hat aber bekannte Schwächen. Probleme, die zwischen zwei Stichproben beginnen, bleiben bis zur nächsten Prüfung unbemerkt. Ergebnisse kommen spät und lassen sich schwer mit den genauen Prozessbedingungen verknüpfen, unter denen das Teil entstand. Und die Daten erreichen selten rechtzeitig die Menschen, die handeln könnten.

Vernetzte Qualitätskontrolle verändert drei Dinge:

1. Abdeckung. Inline-Sensoren und automatische Messmittel prüfen jedes Teil oder einen hohen Anteil der Teile, nicht nur eine Handvoll pro Schicht.
2. Latenz. Ergebnisse liegen innerhalb von Sekunden vor, sodass die Linie angehalten oder nachjustiert werden kann, bevor die nächsten hundert Teile entstehen.
3. Kontext. Jeder Messwert wird mit Seriennummer, Maschine, Rezeptur und Prozessparametern übertragen, wodurch Fehler zu erklärbaren Ereignissen werden.

Woher Qualitätsdaten kommen

Die letzten beiden Zeilen werden leicht übersehen. Qualitätsprobleme werden fast immer durch Prozessbedingungen verursacht; erst wenn Sie Temperatur, Druck oder Liniengeschwindigkeit zusammen mit dem Messwert erfassen, ist später eine Ursachenanalyse möglich.

Eine MQTT-Architektur für die IoT-Qualitätskontrolle in der Fertigung

MQTT passt gut zu Qualitätsdaten, weil ein Messwert meist mehrere Abnehmer hat: die Linienanzeige, das SPC-Dashboard des Qualitätsingenieurs, die Rückverfolgbarkeitsdatenbank und eventuell das MES. Mit Publish/Subscribe veröffentlicht das Messmittel einmal, und jeder Abnehmer abonniert unabhängig. Der Artikel Was ein MQTT-Broker macht erklärt das Muster im Detail.

Ein typischer Ablauf:

1. Sensoren, Messmittel und Prüfstationen sind an ein Edge-Gateway angebunden (eine SPS, ein Industrie-PC mit Node-RED oder ein kleiner Python-Dienst).
2. Das Gateway ergänzt Seriennummer, Station, Rezeptur und Zeitstempel und veröffentlicht eine Nachricht pro Messung oder pro Teil.
3. Ein Qualitätsdienst abonniert, prüft jeden Wert gegen die Spezifikationsgrenzen und veröffentlicht ein Urteil.
4. Ein Historian oder ein Datenbank-Subscriber speichert alles für SPC und Rückverfolgbarkeit.
5. Dashboards abonnieren Live-Werte und Urteile.

Topic-Design

Folgen Sie einer Hierarchie im Stil von ISA-95 und trennen Sie Rohmesswerte von Urteilen:

acme/plant1/assembly/line3/station40/quality/measurement
acme/plant1/assembly/line3/station40/quality/verdict
acme/plant1/assembly/line3/station40/quality/spec        (retained)

Diese Hierarchie macht die Qualitätsdaten zum Teil eines Unified Namespace (UNS): Unternehmen, Werk, Bereich, Linie und Station aus ISA-95 werden zu Topic-Ebenen, sodass Qualitätswerte direkt neben Maschinenzuständen und Prozessdaten derselben Station liegen. Die aktive Spezifikation als Retained Message zu veröffentlichen, ist ein nützlicher Kniff. Jeder Abnehmer, der sich verbindet, erfährt sofort die aktuellen Grenzen für diese Station, und ein Rezepturwechsel erfordert nur die Veröffentlichung einer neuen Spezifikation.

Payload-Design

{
  "ts": "2026-10-16T09:31:07.412Z",
  "serial": "A3-2610-004812",
  "recipe": "HOUSING-B",
  "characteristic": "bore_diameter_mm",
  "value": 22.012,
  "unit": "mm",
  "gauge": "G-40-1",
  "process": {"spindle_temp_c": 31.4, "coolant_temp_c": 21.8}
}

Nehmen Sie die Serien- oder Chargennummer in jede Nachricht auf, verwenden Sie explizite Einheiten und halten Sie ein Merkmal pro Nachricht oder ein klar benanntes Objekt von Merkmalen pro Teil. Vermeiden Sie positionsbasierte Arrays, deren Bedeutung nur in jemandes Kopf existiert.

Spezifikationsprüfungen in Echtzeit

Der einfachste sinnvolle Qualitätsdienst vergleicht jeden Wert mit seiner unteren und oberen Spezifikationsgrenze und veröffentlicht ein Urteil. Das folgende Python-Beispiel (paho-mqtt 2.x) hält Spezifikationen in Retained Messages vor, sodass eine Grenzwertänderung nie einen Neustart erfordert. Es läuft gegen den Öffentlichen MQTT-Broker; ersetzen Sie das Präfix durch Ihre eigene eindeutige ID.

import json
import paho.mqtt.client as mqtt

PREFIX = "connectmq/demo/b6a0e4/line3"
specs = {}  # Station -> {Merkmal: {"lsl":..., "usl":...}}

def on_connect(client, userdata, flags, reason_code, properties):
    client.subscribe(f"{PREFIX}/+/quality/spec", qos=1)
    client.subscribe(f"{PREFIX}/+/quality/measurement", qos=1)

def on_message(client, userdata, msg):
    station = msg.topic.split("/")[4]
    data = json.loads(msg.payload)

    if msg.topic.endswith("/spec"):
        specs[station] = data
        print("spec loaded for", station, data)
        return

    limits = specs.get(station, {}).get(data["characteristic"])
    if limits is None:
        verdict = "no_spec"
    elif limits["lsl"] <= data["value"] <= limits["usl"]:
        verdict = "pass"
    else:
        verdict = "fail"

    out = {"ts": data["ts"], "serial": data["serial"],
           "characteristic": data["characteristic"], "value": data["value"],
           "verdict": verdict}
    client.publish(f"{PREFIX}/{station}/quality/verdict", json.dumps(out), qos=1)
    if verdict != "pass":
        print("NOT PASS", out)

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="qc-checker-b6a0e4")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=60)
client.loop_forever()

Veröffentlichen Sie zum Testen eine Spezifikation und einen Messwert über die Kommandozeile:

mosquitto_pub -h broker.connectmq.com -p 1883 -i spec-b6a0e4 -q 1 -r \
  -t "connectmq/demo/b6a0e4/line3/station40/quality/spec" \
  -m '{"bore_diameter_mm": {"lsl": 21.990, "usl": 22.020}}'

mosquitto_pub -h broker.connectmq.com -p 1883 -i gauge-b6a0e4 -q 1 \
  -t "connectmq/demo/b6a0e4/line3/station40/quality/measurement" \
  -m '{"ts":"2026-10-16T09:31:07Z","serial":"A3-2610-004812","characteristic":"bore_diameter_mm","value":22.012}'

Für einfache Grenzen können Sie ganz auf Code verzichten: Die Schwellwert-Alarmregeln im ConnectMQ-Portal überwachen ein numerisches Feld und protokollieren jede Überschreitung im Alarmprotokoll. Der codebasierte Dienst wird nützlich, wenn Grenzen von der Rezeptur abhängen oder Urteile für andere Systeme zurückveröffentlicht werden müssen.

Mehr als Gut/Schlecht: Drift früh erkennen

Auch ein Teil innerhalb der Spezifikation kann ein Warnsignal sein. Kriechen Bohrungsdurchmesser wegen Werkzeugverschleiß Richtung obere Grenze, bleiben Gut/Schlecht-Prüfungen bis zum ersten Ausfall grün. Die statistische Prozesslenkung (SPC) löst das, indem sie das Prozessverhalten statt einzelner Teile beobachtet und Trends, Verschiebungen und zunehmende Streuung erkennt, während noch jedes Teil gut ist. Das Tutorial zu Echtzeit-SPC baut Regelkarten auf genau diesem Messwertstrom auf.

Signale von der Prozessseite helfen ebenfalls. Ein steigender Bohrungsdurchmesser, der mit der Spindeltemperatur korreliert, deutet auf thermische Ausdehnung hin; einer, der mit der Schnittzahl korreliert, weist auf die Werkzeugverschleißüberwachung als Lösung.

Rückverfolgbarkeit gibt es gratis dazu

Da jede Nachricht eine Seriennummer trägt, erhalten Sie durch das Speichern des Datenstroms in einer Datenbank einen Qualitätsdatensatz pro Teil: welche Station es gemessen hat, mit welchem Messmittel, unter welcher Rezeptur und welchen Prozessbedingungen. Wird ein Fehler beim Kunden gefunden, beantworten Sie die Frage „Welche anderen Teile wurden unter denselben Bedingungen gefertigt?“ in Minuten. Der Leitfaden zum Rückverfolgbarkeitssystem in der Fertigung behandelt Datenbankseite, Genealogie und Ereignisdesign.

Checkliste für die Umsetzung

1. Beginnen Sie mit einem kritischen Merkmal an einer Station, idealerweise einem, das bereits Ausschuss oder Reklamationen verursacht.
2. Digitalisieren Sie die Messung mit einem vernetzten Messmittel oder Sensor; vermeiden Sie das Abtippen von Werten.
3. Ergänzen Sie Kontext am Edge: Seriennummer, Rezeptur, Station, Messmittel-ID, Zeitstempel.
4. Veröffentlichen Sie mit QoS 1, damit Messwerte bei Netzwerkaussetzern nicht unbemerkt verloren gehen.
5. Veröffentlichen Sie Spezifikationen als Retained Messages pro Station und Rezeptur.
6. Ergänzen Sie einen Urteilsdienst und zeigen Sie Ergebnisse innerhalb von Sekunden an der Linie an.
7. Speichern Sie alles in einer Datenbank für SPC und Rückverfolgbarkeit; der Broker ist ein Transportmittel, kein Archiv.
8. Sichern Sie das System ab: private Broker-Zugangsdaten, TLS und die Best Practices für MQTT-Sicherheit auf jedem Gateway.

Das Qualitäts-Rückgrat hosten

Qualitätsdaten sind geschäftskritisch und oft vertraulich, daher ist der öffentliche Demo-Broker nur für Experimente gedacht. In der Produktion gibt ein verwalteter MQTT-Broker jeder Station authentifizierten, verschlüsselten Zugang, ohne dass Sie Broker-Server betreiben, und der Live-Topic-Explorer im ConnectMQ-Portal macht es leicht zu prüfen, ob jede Station das veröffentlicht, was Sie erwarten. Den werksweiten Kontext beschreibt der Leitfaden zu Smart Manufacturing.

Betreiben Sie Ihre Qualitätsdaten mit ConnectMQ

ConnectMQ bietet einen privaten MQTT-5-Broker mit TLS, Retained Messages, QoS 1 und 2 in den kostenpflichtigen Tarifen, einem Live-Topic-Explorer und Schwellwert-Alarmregeln. Erstellen Sie einen Broker im kostenlosen Serverless-Tarif unter app.connectmq.com, ganz ohne Kreditkarte, und verbinden Sie noch heute Ihre erste Qualitätsstation.

Häufig gestellte Fragen

Was ist IoT-Qualitätskontrolle in der Fertigung?

Sie bezeichnet den Einsatz vernetzter Sensoren, Messmittel und Prüfstationen, um Qualität kontinuierlich an der Linie zu messen, wobei die Ergebnisse in Echtzeit mit Bedienern, Ingenieuren und Qualitätssystemen geteilt werden.

Welches Protokoll sollten Qualitätsstationen verwenden?

MQTT eignet sich gut, weil ein Messwert gleichzeitig von Dashboards, SPC, Datenbanken und dem MES genutzt werden kann, ohne Punkt-zu-Punkt-Integrationen.

Muss ich jedes Teil messen?

Nicht immer. Messen Sie jedes Teil dort, wo automatische Sensoren das günstig machen, und digitalisieren Sie anderswo manuelle Stichprobenprüfungen. Der größte Gewinn entsteht oft dadurch, jeden Messwert mit Kontext anzureichern.

Worin unterscheidet sich das von SPC?

Spezifikationsprüfungen bewerten einzelne Teile als gut oder schlecht. SPC beobachtet das Prozessverhalten über die Zeit und erkennt Drift und Verschiebungen, bevor Teile ausfallen.