Stillstandsgründe-Codes, die Bediener wirklich nutzen

Stillstandsgründe-Codes entscheiden darüber, ob Ihre Stillstandsdaten zu Maßnahmen führen oder nur eine Datenbank füllen. Dieser Leitfaden zeigt, wie Sie einen kurzen, strukturierten Ursachenbaum entwerfen, den Bediener in wenigen Sekunden nutzen können, wie Sie ihn den OEE-Verlusten zuordnen und wie Sie einen Eingabeablauf bauen, der Gründe per MQTT neben den Maschinenzuständen veröffentlicht, die Ihre Sensoren bereits erkennen. Am Ende haben Sie einen Startbaum, ein JSON-Format dafür und funktionierenden Code für die Bedienerseite.

Warum die meisten Listen mit Stillstandsgründen scheitern

Werke starten die Stillstandserfassung meist mit guten Absichten und einer langen Liste. Nach wenigen Monaten zeigen die Daten dasselbe Muster: Ein großer Teil der Stopps ist als „Sonstiges“ codiert, einige wenige Codes werden für alles verwendet und Dutzende nie. Die Ursachen sind vorhersehbar:

• Zu viele Codes. Bediener, die durch eine Liste mit sechzig Optionen scrollen müssen, wählen die erste halbwegs passende.
• Codes nach Abteilungen benannt. „Instandhaltung“ oder „Qualität“ beschreibt, wer zuständig ist, nicht was passiert ist – daraus lässt sich keine Maßnahme ableiten.
• Überlappende Bedeutungen. „Stau“ und „Materialproblem“ passen beide auf eine Fehlzuführung, sodass dasselbe Ereignis je nach Schicht zwei verschiedene Codes erhält.
• Keine Verbindung zur Erkennung. Muss der Bediener zusätzlich Beginn und Ende des Stopps erfassen, bricht die Genauigkeit ein. Die Zeiten sollten von der Maschine kommen; nur der Grund sollte von einem Menschen kommen.

Die Lösung ist eine kurze Hierarchie, präzise Formulierungen und automatische Zustandserkennung.

Grundsätze für gute Stillstandsgründe-Codes

1. Erkennung und Erklärung trennen. Maschinen melden RUNNING und STOPPED automatisch; Bediener beantworten nur das „Warum?“.
2. Einen Baum statt einer flachen Liste verwenden. Zwei oder drei Ebenen: eine Kategorie, ein Grund und optional ein Detail. Jeder Bildschirm zeigt nur eine Handvoll Optionen.
3. Die Ursache benennen, nicht die Abteilung. „Warten auf Material“ ist besser als „Logistik“.
4. Codes gegenseitig ausschließend gestalten. Wenn zwei Codes dasselbe Ereignis beschreiben könnten, fassen Sie sie zusammen oder schreiben Sie eine einzeilige Definition, die sie abgrenzt.
5. Eine kleine, feste oberste Ebene beibehalten. Ordnen Sie die oberste Ebene den OEE-Verlusten zu, damit sich Berichte automatisch verdichten.
6. „Sonstiges“ begrenzen. Verlangen Sie einen Freitextkommentar, wenn „Sonstiges“ gewählt wird, und prüfen Sie diese Kommentare wöchentlich; wiederkehrende werden zu neuen Codes.
7. Maschinenalarme nutzen, wo möglich. Meldet die Steuerung einen Fehlercode, schlagen Sie den passenden Grund vor und lassen ihn vom Bediener bestätigen.
8. Den Baum regelmäßig überprüfen. Entfernen Sie ungenutzte Codes und teilen Sie Codes auf, die zu viel verbergen.

Ein Startbaum für Stillstandsgründe

Nutzen Sie diesen als Ausgangspunkt und passen Sie die zweite Ebene an Ihren Prozess an. Die oberste Ebene lässt sich sauber Verfügbarkeit, Leistung und geplanter Zeit zuordnen.

Fünfzehn Codes in sechs Kategorien passen auf zwei Bildschirme. Manche Werke ergänzen für Störungen eine dritte Ebene (welche Baugruppe ausgefallen ist), aber erst, wenn die zweite Ebene konsequent genutzt wird. Beachten Sie, dass geplante Kategorien getrennt bleiben: Sie sind von der OEE ausgenommen, spielen aber für Vergleiche von OEE und TEEP eine Rolle.

Kurzstopps unterhalb Ihrer Mikrostopp-Schwelle sollten überhaupt keinen Grund abfragen. Sie sind für manuelle Eingabe zu häufig und lassen sich besser über Maschinenfehlercodes erklären, wie im Anwendungsfall Überwachung von Verpackungslinien gezeigt.

Den Baum als Daten speichern

Halten Sie den Baum in einem einzigen JSON-Dokument und veröffentlichen Sie ihn als Retained Message per MQTT. Jedes Bedienterminal abonniert ihn; einen Code zu ändern bedeutet also, eine Nachricht zu aktualisieren, statt Apps neu zu installieren.

{
  "version": 3,
  "min_prompt_seconds": 180,
  "categories": [
    {"id": "BRK", "label": "Breakdown", "loss": "availability", "reasons": [
      {"code": "BRK-MECH", "label": "Mechanical failure"},
      {"code": "BRK-ELEC", "label": "Electrical or control fault"},
      {"code": "BRK-TOOL", "label": "Tooling or fixture failure"}
    ]},
    {"id": "CHG", "label": "Changeover", "loss": "availability", "reasons": [
      {"code": "CHG-PROD", "label": "Product changeover"},
      {"code": "CHG-TOOL", "label": "Tool change"},
      {"code": "CHG-FAI", "label": "First-article approval"}
    ]},
    {"id": "WAIT", "label": "Waiting", "loss": "availability", "reasons": [
      {"code": "WAIT-MAT", "label": "Waiting for material"},
      {"code": "WAIT-OPR", "label": "Waiting for operator"},
      {"code": "WAIT-QA", "label": "Waiting for quality release"}
    ]},
    {"id": "PLN", "label": "Planned", "loss": "planned", "reasons": [
      {"code": "PLN-BRK", "label": "Break or meeting"},
      {"code": "PLN-PM", "label": "Planned maintenance"},
      {"code": "PLN-NOS", "label": "No orders scheduled"}
    ]},
    {"id": "OTH", "label": "Other", "loss": "availability", "reasons": [
      {"code": "OTH", "label": "Other", "comment_required": true}
    ]}
  ]
}

Veröffentlichen Sie ihn einmal (retained) auf einem Topic auf Werksebene. Auf dem Öffentlichen MQTT-Broker verwenden Sie dafür Ihr eigenes zufälliges Präfix:

mosquitto_pub -h broker.connectmq.com -p 1883 -i reasons-admin-b3z5 -r -q 1 -t "connectmq/demo/b3z5/plant1/config/downtime-reasons" -f reasons.json

In einem Unified Namespace (UNS) gehört ein solches Konfigurations-Topic auf die Standortebene der ISA-95-Hierarchie, während Zustände und Gründe unter dem Topic der jeweiligen Maschine (Bereich → Linie → Zelle) liegen.

Der Eingabeablauf für Bediener

Am besten funktioniert in der Fertigung ein ablaufgesteuerter Dialog:

1. Der Maschinensensor oder die SPS veröffentlicht STOPPED auf dem Zustands-Topic der Maschine. Die Zeiterfassung startet automatisch. Die Sensorseite beschreibt der Beitrag zur Erfassung von Maschinenstillständen.
2. Dauert der Stopp länger als min_prompt_seconds, zeigt das Terminal an der Maschine den Kategoriebildschirm.
3. Der Bediener tippt auf eine Kategorie, dann auf einen Grund. Zwei Tipps, wenige Sekunden.
4. Das Terminal veröffentlicht den Grund auf dem reason-Topic der Maschine zusammen mit der Startzeit des Stopps, damit der Logger ihn auch bei verspätetem Eintreffen dem richtigen Ereignis zuordnen kann.
5. Läuft die Maschine wieder an, wird das offene Ereignis geschlossen. Wurde kein Grund eingegeben, sieht der Schichtleiter es am Schichtende in einer Liste „ungeklärt“.

Hier ist der Kern eines browserbasierten Terminals mit MQTT.js über sicheres WebSocket. Das Rendern der Schaltflächen überlassen wir Ihrem UI-Framework; entscheidend ist die MQTT-Logik.

import mqtt from "mqtt";

const PREFIX = "connectmq/demo/b3z5/plant1";
const MACHINE = "stamping/press04";
const client = mqtt.connect("wss://broker.connectmq.com:8084/mqtt", {
  clientId: "terminal-press04-" + Math.random().toString(16).slice(2, 8),
  protocolVersion: 5,
});

let tree = null;
let stoppedAt = null;
let promptTimer = null;

client.on("connect", () => {
  client.subscribe(`${PREFIX}/config/downtime-reasons`, { qos: 1 });
  client.subscribe(`${PREFIX}/${MACHINE}/state`, { qos: 1 });
});

client.on("message", (topic, payload) => {
  const data = JSON.parse(payload.toString());
  if (topic.endsWith("/downtime-reasons")) {
    tree = data;
    return;
  }
  if (data.state === "STOPPED" && stoppedAt === null) {
    stoppedAt = Date.now();
    promptTimer = setTimeout(() => showCategories(tree.categories), tree.min_prompt_seconds * 1000);
  } else if (data.state === "RUNNING") {
    clearTimeout(promptTimer);
    stoppedAt = null;
  }
});

export function submitReason(code, comment = "") {
  const msg = { code, comment, stop_started: stoppedAt, entered: Date.now() };
  client.publish(`${PREFIX}/${MACHINE}/reason`, JSON.stringify(msg), { qos: 1 });
  hidePrompt();
}

function showCategories(categories) {
  // Je Kategorie eine große Schaltfläche rendern, dann die Gründe der gewählten Kategorie,
  // und submitReason(reason.code) aufrufen, wenn ein Grund angetippt wird.
  console.log("Prompt operator with", categories.map((c) => c.label));
}

function hidePrompt() {
  console.log("Prompt closed");
}

Wenn Sie Low-Code bevorzugen, lässt sich derselbe Ablauf einfach in Node-RED mit Dashboard-2.0-Schaltflächen und einem mqtt out-Node umsetzen, konfiguriert auf broker.connectmq.com mit Port 1883 für Tests oder 8883 mit TLS in der Produktion.

Einführung und Pflege der Codes

• Zwei Wochen Pilotbetrieb auf einer Linie. Beobachten Sie, welche Codes genutzt werden, welche nie und was unter „Sonstiges“ eingetragen wird.
• Mit echten Beispielen schulen. Zeigen Sie Bedienern fünf aktuelle Stopps und lassen Sie sie gemeinsam codieren. Meinungsverschiedenheiten decken mehrdeutige Codes auf.
• Ergebnisse zurückspielen. Zeigen Sie die häufigsten Gründe wöchentlich an der Linie. Bediener erfassen bessere Daten, wenn sie sehen, dass diese genutzt werden.
• Den Baum versionieren. Behalten Sie das Feld version bei und speichern Sie es mit jedem Grund, damit Berichte nach Codeänderungen korrekt bleiben.
• Bezeichnungen übersetzen, nicht Codes. In mehrsprachigen Werken bleiben die Codes stabil, und Sie ergänzen Bezeichnungsfelder pro Sprache, damit Berichte unabhängig von der Terminalsprache korrekt aggregieren.
• Zeitpunkt der Eingabe prüfen. Vergleichen Sie, wann der Grund eingegeben wurde und wann der Stopp begann. Gründe, die lange nach dem Wiederanlauf erfasst werden, sind weniger zuverlässig und deuten auf Probleme beim Prompt-Timing oder bei der Personalbesetzung hin.

Da der Baum als eine Retained Message auf Ihrem ConnectMQ-Broker liegt, aktualisiert eine neue Version jedes Terminal beim nächsten Verbindungsaufbau, und der Topic-Explorer im Portal zeigt genau, welche Version aktiv ist.

Hosting des Datenflusses

Während der Konzeption reicht der Öffentliche MQTT-Broker unter broker.connectmq.com. Für die Produktion gehören Gründe und Zustände auf einen privaten Broker. ConnectMQ bietet einen verwalteten MQTT-Broker mit Zugangsdaten pro Client und sicherem WebSocket auf Port 8084, sodass sich Browser-Terminals direkt und ohne Backend verbinden. Mit dem Live-Topic-Explorer im Portal prüfen Sie leicht, ob die Gründe auf den richtigen Topics ankommen. Wie Stillstandsgründe in ein umfassenderes Werksprogramm passen, zeigt der Leitfaden zu Smart Manufacturing.

Starten Sie mit ConnectMQ

Registrieren Sie sich kostenlos unter app.connectmq.com, erstellen Sie ohne Kreditkarte einen Serverless-Broker, veröffentlichen Sie Ihren Ursachenbaum und verbinden Sie noch heute Ihr erstes Bedienterminal.

Häufig gestellte Fragen

Wie viele Stillstandsgründe-Codes sollten wir haben?

So wenige, dass Bediener mit zwei Tipps wählen können: meist fünf bis sieben Kategorien mit je drei bis fünf Gründen. Erweitern Sie die Liste nur, wenn die Kommentare unter „Sonstiges“ eine wiederkehrende Ursache zeigen.

Sollen Bediener Start- und Endzeiten eingeben?

Nein. Lassen Sie die Maschine Stopps automatisch erkennen und fragen Sie den Bediener nur nach dem Grund. Manuelle Zeiterfassung ist die Hauptquelle ungenauer Stillstandsdaten.

Was soll mit Stopps ohne Grund passieren?

Zeigen Sie sie dem Schichtleiter am Schichtende als ungeklärt an. Ein hoher Anteil ungeklärter Stopps bedeutet meist, dass die Codes oder das Prompt-Timing nachgebessert werden müssen.

Können Maschinenalarme die Bedienereingabe ersetzen?

Teilweise. Alarmcodes erklären viele Störungen und Mikrostopps gut, aber Wartezeiten, Umrüstungen und Materialprobleme brauchen weiterhin eine menschliche Antwort.