SPS-Fehlercode-Design: Warum generische Codes die Fehlersuche verlangsamen

Wichtigste Erkenntnisse

• Generische SPS-Fehlercodes („Sensor Fault“, „Comm Error“) zwingen Bediener jedes Mal, von Grund auf neu zu untersuchen.
• Gut gestaltete Fehlercodes benennen Gerät + Zustand + vorgeschlagene Wiederherstellung.
• Eine Codebibliothek + Namenskonvention von vornherein spart über die Lebenszeit hinweg Stunden pro Fehler.
• Die Wartungsrückverfolgbarkeit hängt davon ab, dass Fehlercodes aussagekräftig, durchsuchbar und konsistent sind.

Kurzantwort: Generische Fehlercodes verschwenden Diagnosezeit. Gut gestaltete Codes nennen das spezifische Gerät, den spezifischen Zustand und schlagen einen Wiederherstellungsschritt vor. Die Disziplin kostet anfangs mehr, spart aber dauerhaft Stunden pro Fehler. Siehe auch Design von Ausfallursachen-Codes.

Warum generische Codes versagen

„Sensor Fault“ sagt dem Bediener nichts Handlungsfähiges. Welcher Sensor? Welche Art von Fehler? Was zuerst prüfen?

Ergebnis: Der Bediener muss von Grund auf untersuchen. Die mittlere Diagnosezeit steigt. Die OEE leidet.

Was gute Fehlercodes enthalten

• Konkrete Geräte- oder Zonenkennung.
• Konkreter Zustand (Unterbrechung, außerhalb des zulässigen Bereichs, Kommunikationsverlust).
• Vorgeschlagene erste Prüfung.
• Schweregrad (Warnung, Stopp, Notfall).

Schlechtes Beispiel: FLT_SENSOR. Gutes Beispiel: FLT_PE_INFEED_LOW_LOW mit Beschreibung „Zuführungs-Lichtschranke liest 2 s lang zu niedrig — Linse auf Verschmutzungen prüfen.“

Benennungskonvention

Konsistentes Präfix, Gerät, Zustand. Bediener lernen das Muster.

Codebibliothek

Jeden Fehlercode dokumentieren: ID, Beschreibung, vorgeschlagene Maßnahme, Eskalation. Bediener greifen darauf zu; CMMS verknüpft Arbeitsaufträge mit Codes.

Integration mit CMMS

Fehlercodes liefern den Grund an das CMMS. Berichte zeigen die wichtigsten Fehlercodes pro Linie. Untersuchungen fokussieren sich auf die größten Problemverursacher.

Häufige Fehler

1. Vom Programmierer geschriebene Codes ohne Bediener-Review. Die Codes ergeben für den Programmierer Sinn; nicht für den Bediener um 3 Uhr morgens.

2. Keine Dokumentation. Die Code-Bibliothek existiert nur im Kopf des Programmierers.

3. Generische Sammelkategorien. „Other Fault“ verdeckt die eigentliche Ursache.

4. Codes, die sich zwischen SPS-Revisionen ändern. Historische Daten werden unbrauchbar.

Wie sich das auf die OEE auswirkt

Die Verfügbarkeit in der OEE wird von Ausfallzeiten dominiert. Fehlercodes liefern die Kategorien für Ausfallgründe. Spezifische Codes erzeugen aussagekräftige Pareto-Diagramme; generische Codes erzeugen einen bedeutungslosen „Sensor Fault“-Anteil von 30 %.

Wie eine moderne OEE-Plattform gute Codes unterstützt

Fabrico’s OEE-Modul importiert SPS-Fehlercodes via OPC UA / Modbus, mappt sie auf Reason-Codes und erstellt Pareto-Berichte, die Designverbesserungen vorantreiben.

Sehen Sie, wie Fabrico dies automatisch erfasst — OEE für die Fertigung erkunden oder eine Demo buchen.

Weiterführende Lektüre

• Design von Ausfallursachen-Codes
• SPS vs SCADA vs MES
• Run Rate vs Design Rate
• Line Design vs Line Balancing

Häufig gestellte Fragen

Wer entwirft Fehlercodes?

Die Steuerungs-/Leittechnik in Zusammenarbeit mit Bedienern und der Instandhaltung.

Können vorhandene SPS verbessert werden?

Ja. Bei der nächsten Programmrevision überarbeiten.

Wie viele Fehlercodes pro Linie?

Variabel. Zehner bis Hunderte sind normal.

Sparen gute Codes wirklich Zeit?

Oft Minuten pro Fehler. Kumuliert Stunden pro Woche.