Wichtigste Erkenntnisse
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.
„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.
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.“
Konsistentes Präfix, Gerät, Zustand. Bediener lernen das Muster.
Jeden Fehlercode dokumentieren: ID, Beschreibung, vorgeschlagene Maßnahme, Eskalation. Bediener greifen darauf zu; CMMS verknüpft Arbeitsaufträge mit Codes.
Fehlercodes liefern den Grund an das CMMS. Berichte zeigen die wichtigsten Fehlercodes pro Linie. Untersuchungen fokussieren sich auf die größten Problemverursacher.
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.
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 %.
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.
Die Steuerungs-/Leittechnik in Zusammenarbeit mit Bedienern und der Instandhaltung.
Ja. Bei der nächsten Programmrevision überarbeiten.
Variabel. Zehner bis Hunderte sind normal.
Oft Minuten pro Fehler. Kumuliert Stunden pro Woche.
Kurzantwort: Generische Fehlercodes verschwenden Diagnosezeit. Gut gestaltete Codes nennen das spezifische Gerät, die konkrete Bedingung und schlagen einen Wiederherstellungsschritt vor. Die Disziplin kostet anfänglich mehr und spart dafür dauerhaft Stunden pro Fehler.
"Sensor Fault" sagt dem Bediener nichts Handlungsfähiges. Welcher Sensor? Welche Art von Fehler? Was zuerst prüfen?
Ergebnis: Der Bediener untersucht von Grund auf neu. Die mittlere Diagnosezeit steigt. Die OEE leidet.
Schlechtes Beispiel: FLT_SENSOR. Gutes Beispiel: FLT_PE_INFEED_LOW_LOW mit Beschreibung "Infeed photo-eye reading low for 2s, check lens for debris."
Konsistenter Präfix, Gerät, Zustand. Bediener lernen das Muster.
Dokumentieren Sie jeden Fehlercode: ID, Beschreibung, vorgeschlagene Maßnahme, Eskalation. Bediener schlagen nach; das CMMS verknüpft Arbeitsaufträge mit den Codes.
Fehlercodes liefern den CMMS‑Grund. Berichte zeigen die häufigsten Fehlercodes pro Linie. Untersuchungen zielen auf die schlimmsten Ursachen ab.
1. Vom Programmierer verfasste Codes ohne Rücksprache mit den Bedienern. 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 Auffangkategorien. "Other Fault" verschleiert die tatsächliche Ursache.
4. Codes, die sich zwischen SPS‑Revisionen ändern. Historische Daten werden unbrauchbar.
Die Verfügbarkeit im OEE wird von Ausfallzeiten dominiert. Fehlercodes speisen die Kategorisierung der Ausfallgründe. Spezifische Codes erzeugen aussagekräftige Pareto-Analysen; generische Codes erzeugen einen bedeutungslosen "Sensor Fault"-Anteil von 30%.
Das OEE-Modul von Fabrico liest SPS-Fehlercodes über OPC UA / Modbus ein, ordnet sie auf Grundcodes zu und erstellt Pareto-Berichte, die Verbesserungen im Design vorantreiben.
Die Steuerungstechnik mit Einbeziehung von Bedienern und Instandhaltung.
Ja. Bei der nächsten Programmrevision refaktorisieren.
Variabel. Zehner bis Hunderte sind normal.
Oft Minuten pro Fehler. Kumuliert Stunden pro Woche.
Anmeldung
Blog
