Eine Verpackungslinie zu überwachen heißt vor allem, die Stopps zu erfassen, die niemand aufschreibt: ein verklemmtes Etikett, eine umgefallene Flasche, ein Kartonaufrichter, der auf Zuschnitte wartet. Dieser Anwendungsfall zeigt, wie Sie jeden Stopp und jede Geschwindigkeitsänderung an einer Verpackungslinie über MQTT erfassen, Kurzstopps automatisch klassifizieren und die Maschine finden, die die Ausbringung tatsächlich begrenzt. Am Ende haben Sie ein einfaches Ereignismodell, einen funktionierenden Kurzstopp-Detektor und eine Liste, was Sie mit den Ergebnissen tun.
Warum Verpackungslinien ihre Verluste verbergen
Verpackungslinien sind Ketten schneller Maschinen, verbunden durch Förderbänder und Staustrecken. Steht eine Maschine 20 Sekunden, fängt der Puffer das ab, die Linie läuft weiter, und niemand protokolliert es. Passiert dasselbe vierzigmal pro Schicht, läuft der Puffer leer, die vorgelagerte Maschine staut sich, und die Linie wird langsamer. Handschriftliche Protokolle erfassen die langen Störungen, aber die kurzen, häufigen Stopps und die Maschinen, die unter Nenngeschwindigkeit laufen, sind auf Papier meist unsichtbar.
Diese versteckten Verluste sind oft größer als die Störungen, die alle Aufmerksamkeit bekommen. Verpackungslinien gehören daher zu den Bereichen, in denen sich automatische Datenerfassung am schnellsten auszahlt: Die Signale liegen in den Maschinen-SPSen bereits vor, und das Muster zeigt sich erst, wenn jedes Ereignis aufgezeichnet wird.
Stoppkategorien, die Sie trennen müssen
Nicht jeder Stopp ist die Schuld der Maschine. Eine sinnvolle Überwachung der Verpackungslinie unterscheidet:
| Kategorie | Definition | Typische Ursache |
|---|---|---|
| Kurzstopp | Maschine steht kürzer als ein Schwellwert (oft unter 2 bis 5 Minuten), ohne Instandhaltung behoben | Staus, Fehleinzüge, Fehlauslösungen von Sensoren |
| Störung | Stopp über dem Schwellwert oder mit Instandhaltungsbedarf | Mechanischer oder elektrischer Ausfall |
| Mangel (starved) | Maschine bereit, aber kein Produkt kommt an | Stopp vorgelagert oder leerer Puffer |
| Stau (blocked) | Maschine bereit, aber Ausgang zurückgestaut | Stopp nachgelagert oder voller Puffer |
| Geschwindigkeitsverlust | Läuft, aber unter Nenngeschwindigkeit | Bediener hat Geschwindigkeit reduziert, instabiler Einlauf |
| Geplanter Stopp | Umrüstung, Reinigung, Pause | Geplante Tätigkeit |
Mangel und Stau sind der Schlüssel. Ein Verschließer im Mangel hat kein Verschließer-Problem; die Ursache liegt vorgelagert. Ohne diese Trennung sieht jede Maschine schlecht aus, und der echte Engpass bleibt verborgen.
Signale und Nachrichtendesign
Die SPS jeder Maschine stellt meist Bits für Laufen, Störung, Mangel und Stau bereit, dazu einen Geschwindigkeitswert und Zähler. Publizieren Sie bei jeder Änderung ein Zustandsereignis und periodisch eine Zählernachricht:
connectmq/demo/<your-id>/plant2/pack3/<machine>/state
connectmq/demo/<your-id>/plant2/pack3/<machine>/counts
{"state": "STOPPED", "cause": "FAULT", "code": 214, "speed": 0, "ts": 1792140125.42}
{"infeed": 120544, "outfeed": 120391, "reject": 153, "speed": 312, "rated_speed": 400, "ts": 1792140130.0}
Verwenden Sie im Stillstand die cause-Werte FAULT, STARVED, BLOCKED und PLANNED. Der Störungs-code stammt aus der maschineneigenen Alarmliste und liefert für viele Stopps einen Grund, ohne das Bedienpersonal zu fragen. Zeitstempel sollten an der Edge mit Sub-Sekunden-Genauigkeit gesetzt werden, weil Kurzstopps kurz sind und die Reihenfolge zählt.
Die Topic-Struktur plant2/pack3/<machine> folgt der ISA-95-Hierarchie Standort → Bereich/Linie → Maschine. Genau diese Hierarchie bildet in einem Unified Namespace (UNS) das Rückgrat auf dem Broker, sodass MES, Historian und Dashboards die Ereignisse jeder Verpackungslinie an derselben Stelle finden – mehr dazu unter Sparkplug B und Unified Namespace.
Ein Kurzstopp-Detektor in Python
Dieser Subscriber hört auf das Zustands-Topic jeder Maschine, misst beim Wiederanlauf die Dauer jedes Stopps, klassifiziert ihn und publiziert ein Zusammenfassungsereignis. Außerdem führt er eine Strichliste pro Maschine, die Sie jede Minute an ein Dashboard senden könnten.
import json
import time
from collections import defaultdict
import paho.mqtt.client as mqtt
PREFIX = "connectmq/demo/p9x2c6/plant2/pack3"
MICRO_STOP_SECONDS = 120
stopped_since = {} # machine -> (start_ts, cause, code)
tally = defaultdict(lambda: defaultdict(lambda: {"count": 0, "seconds": 0.0}))
def on_connect(client, userdata, flags, reason_code, properties):
client.subscribe(f"{PREFIX}/+/state", qos=1)
def on_message(client, userdata, msg):
machine = msg.topic.split("/")[-2]
event = json.loads(msg.payload)
ts = event.get("ts", time.time())
if event["state"] == "STOPPED" and machine not in stopped_since:
stopped_since[machine] = (ts, event.get("cause", "UNKNOWN"), event.get("code"))
return
if event["state"] == "RUNNING" and machine in stopped_since:
start, cause, code = stopped_since.pop(machine)
duration = ts - start
if cause == "FAULT":
category = "MICRO_STOP" if duration < MICRO_STOP_SECONDS else "BREAKDOWN"
else:
category = cause # STARVED, BLOCKED, PLANNED
bucket = tally[machine][category]
bucket["count"] += 1
bucket["seconds"] += duration
summary = {
"machine": machine,
"category": category,
"code": code,
"duration": round(duration, 1),
"ended": ts,
}
client.publish(f"{PREFIX}/{machine}/stop", json.dumps(summary), qos=1)
print(summary)
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="microstop-p9x2c6")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=30)
client.loop_forever()
Testen Sie ihn ohne echte Linie, indem Sie Ereignisse von Hand publizieren:
mosquitto_pub -h broker.connectmq.com -p 1883 -i tester-p9x2c6 -t "connectmq/demo/p9x2c6/plant2/pack3/labeler/state" -m '{"state":"STOPPED","cause":"FAULT","code":214,"speed":0,"ts":1792140125.4}'
mosquitto_pub -h broker.connectmq.com -p 1883 -i tester-p9x2c6 -t "connectmq/demo/p9x2c6/plant2/pack3/labeler/state" -m '{"state":"RUNNING","speed":380,"ts":1792140143.9}'
Der Detektor gibt einen MICRO_STOP von 18,5 Sekunden für den Etikettierer mit Störungscode 214 aus. Jedes Stoppereignis ist jetzt ein Datensatz, den Sie speichern, visualisieren und nach Code summieren können.
Geschwindigkeitsverluste finden
Stopps sind nur die halbe Geschichte. Eine Linie mit einer Nennleistung von 400 Einheiten pro Minute, die mit 330 läuft, um einen launischen Etikettierer bei Laune zu halten, verliert in jeder Laufminute Kapazität, und kein Stoppprotokoll zeigt das. Vergleichen Sie in der Zählernachricht speed mit rated_speed und summieren Sie die Differenz nur, solange die Maschine läuft. Ein einfacher Tagesbericht „durch Geschwindigkeit verlorene Minutenäquivalente“ pro Maschine ist oft eine Überraschung: Bediener reduzieren die Geschwindigkeit aus guten Gründen, doch diese Gründe lassen sich beheben, sobald sie sichtbar sind.
Geschwindigkeitsverluste und Kurzstopps bilden zusammen die Leistungskomponente der OEE. Der Leitfaden zur OEE-Berechnung zeigt, wie sie sich mit Verfügbarkeit und Qualität verbinden.
Analyse-Checkliste: von Daten zu Maßnahmen
Sobald eine Woche Daten vorliegt, arbeiten Sie diese Liste ab:
- Den Engpass finden. Die Maschine mit der geringsten Mangel- und Stauzeit ist meist der Engpass. Verbesserungen an anderer Stelle erhöhen die Linienausbringung nicht.
- Kurzstopps nach Maschine und Störungscode im Pareto darstellen. Oft verursachen wenige Codes die meisten Stopps am Engpass.
- Das zeitliche Muster prüfen. Stopps, die sich nach Umrüstungen oder zu bestimmten Zeiten häufen, deuten auf Einstell- oder Materialprobleme hin.
- Das Pufferverhalten betrachten. Ist der Engpass häufig im Mangel, ist der vorgelagerte Puffer womöglich zu klein oder die vorgelagerte Maschine zu unzuverlässig.
- Geschwindigkeitseinstellungen überprüfen. Vergleichen Sie Ist- und Nenngeschwindigkeit jeder Maschine und fragen Sie, warum die Lücke besteht.
- Langen Stopps Gründe zuordnen. Kurzstopps erklären sich über Störungscodes, Störungen brauchen aber einen menschlichen Grund. Eine strukturierte Liste von Stillstandsgründen hält diese Einträge verwertbar.
Die Daten an der Linie anzeigen
Ein großer Bildschirm neben der Linie mit dem Zustand jeder Maschine, der aktuellen Kurzstoppzahl der Schicht und den drei häufigsten Störungscodes verändert das Verhalten schnell, weil das Bedienpersonal den Effekt einer justierten Führungsschiene oder eines nachgestellten Sensors noch in derselben Schicht sieht. Das Tutorial zum Dashboard für die Überwachung von Produktionslinien zeigt, wie Sie eines aus diesen Topics bauen.
Den Datenfluss dimensionieren
Verpackungslinien erzeugen mehr Ereignisse, als die meisten erwarten; es lohnt sich daher, die Nachrichtenrate vor dem Go-live abzuschätzen. Eine typische Linie hat fünf bis acht Maschinen. Jede publiziert bei jeder Änderung eine Zustandsnachricht und alle paar Sekunden eine Zählernachricht. In einer schlechten Schicht kann ein einzelner Etikettierer Dutzende Male pro Stunde stoppen, doch selbst dann bleibt die Summe überschaubar: wenige Nachrichten pro Sekunde für die ganze Linie, jede deutlich unter einem Kilobyte.
Einige Designentscheidungen halten das so:
- Zustände nur bei Änderung publizieren. Niemals einen unveränderten Zustand alle 100 ms abfragen und neu publizieren.
- Zähler in festem, langsamem Intervall senden. Alle fünf oder zehn Sekunden reicht, weil Zähler kumulativ sind.
- Störungstexte aus der Payload heraushalten. Senden Sie den numerischen Code und halten Sie die Beschreibungstabelle im Analysedienst.
- Einen Client pro Gateway verwenden. Ein einzelnes Gateway, das mehrere SPSen ausliest, kann alle Maschinen-Topics über eine Verbindung publizieren und spart so Verbindungen in Ihrem Broker-Plan.
Mit diesem Muster trägt ein einziger ConnectMQ-Serverless-Broker bequem eine Verpackungslinie, den Detektor, einen Historian und ein paar Anzeigen, und weitere Linien fügen Sie durch Erweitern des Topic-Baums hinzu, ohne etwas neu zu bauen.
Auf einen privaten Broker umziehen
Nutzen Sie für den Prototyp den Öffentlichen MQTT-Broker und ziehen Sie die echte Linie dann auf einen privaten Broker um, damit Produktionsdaten für andere nicht lesbar sind. ConnectMQ bietet einen verwalteten MQTT-Broker, mit dem sich jedes SPS-Gateway, der Detektor und das Dashboard mit ausgegebenen Zugangsdaten über TLS verbinden. Die 25 Verbindungen des kostenlosen Plans Serverless (Free) reichen für eine Verpackungslinie, und die kostenpflichtigen Pläne skalieren mit QoS 2, größeren Nachrichten und Shared Subscriptions, wenn Sie mehrere Detektor-Instanzen parallel betreiben. Die übergreifende Roadmap für Industrie 4.0 behandelt der Leitfaden zur Smart Manufacturing.
Mit ConnectMQ starten
Registrieren Sie sich unter app.connectmq.com, legen Sie einen kostenlosen Serverless-Broker an, ohne Kreditkarte, verbinden Sie Ihre erste Verpackungsmaschine und beginnen Sie, die Kurzstopps zu zählen, die Ihre Linie bisher verborgen hat.
Häufig gestellte Fragen
Was zählt an einer Verpackungslinie als Kurzstopp?
Ein kurzer Stopp, den das Bedienpersonal ohne Instandhaltung behebt, typischerweise unter einem Schwellwert von wenigen Minuten. Legen Sie einen Schwellwert für das Werk fest und halten Sie ihn konstant, damit Trends vergleichbar bleiben.
Muss das Bedienpersonal Gründe für Kurzstopps eingeben?
Nein. Kurzstopps sind für manuelle Eingabe zu häufig; nutzen Sie stattdessen die Störungscodes der Maschine. Reservieren Sie Eingaben des Bedienpersonals für längere Stopps.
Warum Mangel und Stau von Störungen trennen?
Weil eine Maschine im Mangel oder Stau auf einen Nachbarn reagiert. Diese Zeiten als ihren eigenen Stillstand zu zählen, verbirgt den echten Engpass.
Wie schnell müssen die Daten sein?
Zustandsänderungen sollten sofort mit Edge-Zeitstempeln publiziert werden. Sub-Sekunden-Genauigkeit ist nützlich, weil viele Kurzstopps nur Sekunden dauern.
