Aufzeichnungen über Geräteausfälle: Das Zuverlässigkeitsdatenmodell

Ein Ausfallprotokoll ist die strukturierte Aufzeichnung eines einzelnen Ausfallereignisses an einer Anlage, in der die Anlage, der Fehlermodus, die Ursache, die Erkennungsart, Beginn und Ende der Stillstandszeit, die Reparaturdauer und die verwendeten Teile festgehalten werden. Konsistente, codierte Einträge sind die Rohdaten hinter MTBF, MTTR, OEE-Verfügbarkeit und Zuverlässigkeitsanalysen wie FMEA.

Was ist ein Ausfallprotokoll?

Ein Ausfallprotokoll ist die strukturierte Dokumentation eines einzelnen Ausfallereignisses an einer einzelnen Anlage. Es beantwortet, was ausgefallen ist, wie es ausgefallen ist, warum es ausgefallen ist, wie lange es stillstand, was zur Behebung getan wurde und welche Teile verbraucht wurden. Ein Eintrag entspricht einem Ausfall, mit Zeitstempel und Codierung, sodass er später gezählt, sortiert und analysiert werden kann.

Ein Ausfallprotokoll ist nicht dasselbe wie ein Arbeitsauftrag. Der Arbeitsauftrag ist die Anweisung zur Durchführung der Reparatur. Das Ausfallprotokoll ist der Zuverlässigkeitsnachweis, den die Reparatur hinterlässt. Wie Reliabilityweb es ausdrückt: Ohne genaue Ausfalldaten "hat man nur ein Work-Order-Ticket-System", und dieselbe Quelle merkt an, dass "ohne Fehlermodi alles nur eine Ansammlung von Codes ist." Das Protokoll verwandelt ein geschlossenes Ticket in verwertbare Daten.

Das ist wichtig, weil nahezu jede Zuverlässigkeitskennzahl Ihrer Anlage auf diesen Protokollen basiert. Sind die Einträge vage, geraten oder inkonsistent codiert, dann sind MTBF, MTTR und der Verfügbarkeitsanteil der OEE auf Sand gebaut.

Welche Felder gehören in ein Ausfallprotokoll?

Ein vollständiges Ausfallprotokoll erfasst die Anlage, den Ausfall selbst, den Zeitpunkt, die Reaktion und die Ressourcen. Fehlt eines dieser Elemente, bricht eine nachgelagerte Berechnung zusammen. Die folgende Tabelle zeigt die Kernfelder, was jedes erfasst und welches häufige Datenqualitätsproblem damit verbunden ist.

Ein subtiler, aber kritischer Punkt: Stillstandszeit und Reparaturzeit sind verschiedene Felder. Stillstandszeit ist die gesamte Uhrzeit vom Stopp bis zum Neustart, einschließlich Wartezeit auf einen Techniker und Wartezeit auf Teile. Reparaturzeit ist nur die aktive Reparaturarbeit. Die getrennte Speicherung ermöglicht später die Unterscheidung zwischen einer langsam reagierenden Störung und einem schwierig zu behebenden Problem.

Warum müssen Fehlermodus und Ursache getrennte Felder sein?

Weil der Fehlermodus das ist, was ein Techniker beobachtet, und die Ursache das ist, was er schlussfolgert. Der Modus ist in der Regel korrekt. Die Ursache ist oft eine Vermutung. Werden sie in einem Feld zusammengeführt, kann man nie eine zuverlässige Beobachtung von einer hoffnungsvollen Annahme unterscheiden, und die Datenqualität verschlechtert sich stillschweigend.

Die Trennung ermöglicht außerdem die wertvollste Zuverlässigkeitsfrage überhaupt: Tritt derselbe Modus wiederholt aus derselben Ursache auf? Reliabilityweb beschreibt die Falle direkt und warnt davor, dass "das neue Lager, das Sie gerade eingebaut haben, 2–3 Monate später wieder ausfallen könnte, weil die wahre Ursache nicht behoben wurde." Getrennte Felder bringen dieses Muster ans Licht.

Was ist ein Fehlercode und warum ist Taxonomie wichtig?

Ein Fehlercode ist ein standardisierter, auswählbarer Wert aus einer Dropdown-Liste, der einen Ausfall klassifiziert, anstatt ihn im Freitext zu beschreiben. Eine codierte Taxonomie verwandelt tausende von Ausfällen in einen zählbaren Datensatz. Freitext verwandelt sie in einen Haufen nicht durchsuchbarer Notizen.

Der Referenzstandard ist hier ISO 14224, die internationale Norm für die Sammlung und den Austausch von Zuverlässigkeits- und Wartungsdaten für Ausrüstungen. Sie definiert eine gemeinsame Zuverlässigkeitssprache: eine geschichtete Gerätetaxonomie sowie standardisierte Kategorien für Ausfalldaten, einschließlich Ausfallursache und -folge, und Wartungsdaten wie Wartungsmaßnahme und Stillstandszeit. Auch außerhalb der Öl- und Gasindustrie, wo sie entstanden ist, ist ISO 14224 der Maßstab dafür, wie Ausfallprotokolle zu strukturieren sind, damit sie zu einem statistisch gültigen Datensatz zusammenfließen (ISO 14224:2016).

Die praktische Lektion für jede Anlage: Bauen Sie ein kontrolliertes Vokabular von Fehlermodi und Ursachen pro Gerätekategorie auf, erzwingen Sie es mit Dropdowns und machen Sie das Feld Fehlermodus obligatorisch, bevor ein Korrektur-Arbeitsauftrag geschlossen werden kann. Diese eine Regel bewirkt mehr für die Datenqualität als jedes Analysetool.

Wie füttern Ausfallprotokolle MTBF, MTTR und OEE?

Ausfallprotokolle sind die Eingabedaten für die wichtigen Zuverlässigkeitskennzahlen. Jede Kennzahl ist ein einfacher Quotient, aber jeder Begriff in diesem Quotienten stammt direkt aus Ihren Protokollen, weshalb die Qualität der Protokolle die Qualität der Kennzahlen bestimmt.

Die Formeln sind bewusst einfach. MTBF ist die Gesamtbetriebszeit geteilt durch die Anzahl der Ausfälle, und MTTR ist die Gesamtreparaturzeit geteilt durch die Anzahl der Reparaturen (LogicMonitor). Beachten Sie, dass beide von einer genauen Zählung der Ausfälle abhängen. Werden kleine Stopps nicht erfasst, ist Ihre Ausfallanzahl zu gering und MTBF erscheint künstlich gut. Sind die Stillstandszeitstempel schlampig, ist die Verfügbarkeit falsch. Für eine tiefere Behandlung siehe unsere Guides zu MTBF und MTTR und zu ungeplanter Stillstandszeit.

Wie ermöglichen saubere Protokolle FMEA und Zuverlässigkeitsanalysen?

Eine Fehlermöglichkeits- und -einflussanalyse (FMEA) ist nur so gut wie die Ausfallhistorie, auf der sie basiert. FMEA bewertet Risiken anhand von Schwere, Auftretenshäufigkeit und Entdeckbarkeit. Ihre Ausfallprotokolle liefern die realen Auftretensdaten (wie oft jeder Modus tatsächlich vorkommt) und die Entdeckungsdaten (wie der Ausfall gefunden wurde). Ohne codierte Protokolle sind diese Bewertungen Meinungen. Mit ihnen sind es Belege.

Saubere Protokolle treiben auch die Kritikalitätsbewertung von Anlagen voran und ermöglichen den Aufbau eines datenbasierten präventiven Wartungsprogramms statt eines kalenderbasierten Ratespiels. Ein wiederkehrender Fehlermodus an einer kritischen Anlage ist der klassische Auslöser, reaktive Reparatur in eine geplante PM-Aufgabe zu überführen.

Was sind die häufigsten Datenqualitätsprobleme bei Ausfallprotokollen?

Das häufigste Problem ist die vermutete Ursache: Ein Techniker schließt den Auftrag ab, wählt eine plausible Ursache aus der Dropdown-Liste und macht weiter. An zweiter Stelle stehen fehlende Protokolle, bei denen kurze Stopps nie erfasst werden. Zusammen verfälschen sie sowohl die Ursachendaten als auch die Ausfallanzahl, weshalb Reliabilityweb berichtet, dass "70 Prozent aller CMMS-Installationen niemals erfolgreich eine grundlegende Ausfallanalyse durchgeführt haben."

Verwenden Sie diese Checkliste, um die Disziplin Ihrer eigenen Ausfallprotokollierung zu prüfen:

• Fehlermodus verpflichtend bei jedem Abschluss eines Korrektur-Arbeitsauftrags, ausgewählt aus einer kontrollierten Liste.
• Getrennte Felder für Fehlermodus, Ursache und durchgeführte Maßnahme, niemals ein zusammengeführter Freitext.
• Zeitstempel beim Ereignis erfasst, nicht aus dem Gedächtnis am Schichtende rekonstruiert.
• Kurze Stopps gezählt, damit die Ausfallanzahl real ist (siehe das Framework der sechs großen Verluste).
• Eine kontrollierte Taxonomie pro Gerätekategorie, idealerweise an die Struktur von ISO 14224 angelehnt.
• Ursache auf Beweislage basierend, nicht der bequemste Dropdown-Wert.

Wie sorgt Fabrico dafür, dass Ausfallprotokolle akkurat und nicht geraten sind?

Die meisten CMMS-Ausfallprotokolle werden nachträglich von einem Techniker getippt, der rekonstruiert, was passiert ist. Fabrico ändert die Datenquelle. Da Fabrico direkt an Maschinen-PLCs angebunden ist, werden die Beginn- und Endzeitstempel der Stillstandszeit automatisch von der Linie erfasst und nicht manuell eingegeben, sodass die Verfügbarkeitsdaten, die die OEE speisen, präzise statt gerundet sind.

Für das schwierigste Feld von allen, die Ursache, nutzt Fabrico Computer Vision, um die wahre Ursache eines Stillstands zu erfassen im Moment des Auftretens. Das eliminiert das größte Risiko für Datenqualität in jedem Zuverlässigkeitsdatenmodell: eine vermutete Ursache, die Stunden später protokolliert wird. Der Fehler wird dann zu einem priorisierten, teilebereiten digitalen Arbeitsauftrag auf dem Telefon des Technikers, mit QR-erzwungenen Checklisten, sodass die Korrekturmaßnahme und die verwendeten Teile erfasst werden, während der Auftrag ausgeführt wird, nicht erst danach.

Das Ergebnis ist ein geschlossener Fault-to-Fix-Prozess, bei dem das Ausfallprotokoll ein Nebenprodukt der Arbeit ist und von vornherein genau ist. Als in der EU entwickeltes System mit EU-Datenresidenz hält Fabrico diese Zuverlässigkeitsdaten innerhalb klarer Governance-Grenzen. [EINGEFÜGTER VERIFIZIERTER NACHWEIS – Bediener zur Bestätigung]

Wenn Ihre Ausfallprotokolle voller vermuteter Ursachen und gerundeter Zeitstempel sind, sind auch Ihre MTBF- und OEE-Zahlen nur Vermutungen. Sehen Sie, wie Fabrico die wahre Ursache erfasst und jeden Ausfall in saubere, analysebereite Daten verwandelt.