Fünf Zuverlässigkeitstechniken zur Analyse der industriellen Fehlertoleranz

Warum Fehlertoleranz mehr als redundante Hardware erfordert

Jedes industrielle System wird früher oder später Fehler aufweisen. Sensoren driften, Stromversorgungen verschleißen, Kommunikationsverbindungen werden instabil, und mechanische Komponenten verschleißen unter wiederholter Belastung. Das Ziel fehlertoleranter Technik besteht daher nicht darin, Anlagen zu schaffen, die niemals ausfallen können. Ziel ist es vielmehr, sicherzustellen, dass vorhersehbare Fehler nicht unmittelbar zu unkontrollierten Systemausfällen werden.

Ein fehlertolerantes System kann eine akzeptable Funktion weiterhin erbringen, nachdem eine oder mehrere Komponenten nicht mehr verfügbar sind. In manchen Anwendungen muss das System die volle Produktion aufrechterhalten. In anderen ist eine verringerte Kapazität akzeptabel, bis die Wartung den ausgefallenen Kanal wiederherstellen kann. Sicherheitstechnische Systeme wechseln stattdessen möglicherweise in einen kontrollierten sicheren Zustand, wenn der weitere Betrieb ein nicht akzeptables Risiko darstellen würde.

Redundante Komponenten sind häufig Teil dieser Strategie, aber eine bloße Duplizierung beweist noch keine Fehlertoleranz. Zwei Steuerungen können weiterhin von einer einzigen Stromversorgung, einem einzigen Netzwerk-Switch oder einer einzigen Softwarekonfiguration abhängen. Zwei Messumformer können dieselbe Impulsleitung nutzen und durch dieselbe Verstopfung ausfallen. Die Zuverlässigkeitsanalyse muss daher die vollständige Architektur untersuchen, einschließlich Abhängigkeiten, die in einer Anlagenliste nicht sofort sichtbar sind.

Fünf Methoden sind für diese Arbeit besonders nützlich. Die Fehlerbaumanalyse untersucht, wie Kombinationen von Ausfällen ein definiertes Top-Ereignis verursachen können. Die Fehlermöglichkeits- und Einflussanalyse untersucht, wie einzelne Komponenten ausfallen können und wie sich diese Ausfälle auf das Gesamtsystem auswirken. Die Monte-Carlo-Simulation untersucht Unsicherheiten anhand vieler möglicher Betriebs- und Ausfallszenarien, während die Ursachenanalyse untersucht, warum ein tatsächliches Ereignis eingetreten ist. Markow-Modelle beschreiben, wie sich reparierbare Systeme im Laufe der Zeit zwischen intakten, beeinträchtigten, ausgefallenen und wiederhergestellten Zuständen bewegen.

Abbildung 1. Industrielle Systeme können nicht jeden Fehler vermeiden, aber eine konsequente Zuverlässigkeitstechnik kann verhindern, dass viele Fehler zu vollständigen Ausfällen werden.

Zuverlässigkeit, Verfügbarkeit, Sicherheit und Wartbarkeit sind nicht dasselbe

Die Zuverlässigkeitsterminologie wird häufig uneinheitlich verwendet, was bei Designprüfungen zu Verwirrung führen kann. Zuverlässigkeit beschreibt die Wahrscheinlichkeit, dass eine Anlage ihre erforderliche Funktion über einen definierten Zeitraum erfüllt. Verfügbarkeit beschreibt, ob die Anlage bereit ist, wenn der Prozess sie benötigt. Ein System kann gelegentlich ausfallen und dennoch eine hohe Verfügbarkeit aufweisen, wenn Reparaturen schnell durchgeführt werden und Ersatzteile sofort verfügbar sind.

Wartbarkeit beschreibt, wie effektiv ein ausgefallenes System diagnostiziert und wiederhergestellt werden kann. Sicherheit beschreibt, ob Ausfälle innerhalb akzeptabler Risikogrenzen für Personal, Umwelt und Ausrüstung bleiben. Diese Eigenschaften beeinflussen einander, aber die Verbesserung einer Eigenschaft verbessert nicht automatisch alle anderen. Eine Schutzabschaltung kann die Produktionsverfügbarkeit verringern und gleichzeitig die Anlagensicherheit deutlich erhöhen.

Fehlertoleranz erstreckt sich über diese Disziplinen hinweg. Sie hängt von Redundanz, Diagnose, Isolierung, Reparaturfähigkeit und kontrollierter Degradation ab. Sie hängt außerdem von einer klaren Definition der erforderlichen Funktion ab. Ingenieure können nicht feststellen, ob ein System fehlertolerant ist, solange sie nicht wissen, welche Leistung nach jedem plausiblen Fehler erhalten bleiben muss.

Ein Verdichterschutzsystem muss beispielsweise möglicherweise nach dem Ausfall eines Sensors weiterhin eine Notabschaltung ermöglichen. Ein Prozessleitsystem muss möglicherweise lediglich einen stabilen Betrieb aufrechterhalten, während eine Steuerung ausgetauscht wird. Ein Stromschutzkonzept kann unabhängige Kanäle erfordern, damit ein einzelner gemeinsamer Fehler nicht sowohl den primären als auch den Reserve-Schutz außer Betrieb setzen kann. Zuverlässigkeitstechniken helfen Ingenieuren, diese Anforderungen in prüfbare Designs zu übersetzen.

Auswahl einer Methode anhand der technischen Fragestellung

Die fünf Zuverlässigkeitstechniken behandeln unterschiedliche Aspekte desselben Problems. Die Fehlerbaumanalyse beginnt mit einem unerwünschten Systemereignis und arbeitet rückwärts zu den Ausfällen, die es verursachen könnten. Die FMEA beginnt mit Komponenten oder Funktionen und verfolgt vorwärts die Folgen jedes Fehlermodus. Die Monte-Carlo-Simulation untersucht die Auswirkungen von Unsicherheit, indem sie das Systemmodell unter vielen zufällig erzeugten Bedingungen wiederholt.

Eine Ursachenanalyse beginnt normalerweise nach einem tatsächlichen Vorfall und nutzt Belege, um sichtbare Symptome von den zugrunde liegenden technischen und organisatorischen Ursachen zu trennen. Die Markov-Modellierung konzentriert sich auf Systemzustände und die Raten, mit denen das System zwischen ihnen wechselt. Sie ist besonders nützlich, wenn Reparatur, Standby-Betrieb, eingeschränkte Leistung und Diagnoseabdeckung die Verfügbarkeit stark beeinflussen.

Die richtige Wahl hängt von der gestellten Frage ab. Ein Team, das untersucht, wie es zu einem vollständigen Kühlungsverlust kommen könnte, wird normalerweise mit einer Fehlerbaumanalyse beginnen. Ein Konstruktionsteam, das jeden möglichen Ausfall von Messumformer, Steuerung und Ventil überprüft, profitiert stärker von einer FMEA. Ein Asset-Manager, der unsichere Instandhaltungsintervalle vergleicht, kann eine Monte-Carlo-Simulation einsetzen, während ein Zuverlässigkeitsingenieur, der die langfristige Verfügbarkeit eines redundanten Steuerungspaars berechnet, möglicherweise ein Markov-Modell bevorzugt.

Diese Methoden ergänzen einander, anstatt austauschbar zu sein. Eine FMEA kann Fehlermodi identifizieren, die später zu Basisereignissen in einem Fehlerbaum werden. Erkenntnisse aus einer Ursachenanalyse können unrealistische Fehlerannahmen in einem Markov-Modell korrigieren. Eine Monte-Carlo-Simulation kann prüfen, wie sich unsichere Wahrscheinlichkeiten auf Schlussfolgerungen aus einer Fehlerbaumanalyse oder auf die Instandhaltungsplanung auswirken.

Die Fehlerbaumanalyse beginnt mit der Konsequenz

Die Fehlerbaumanalyse ist eine deduktive Methode, die mit einem klar definierten unerwünschten Ereignis beginnt. Dieses Ereignis wird als Top-Ereignis bezeichnet. Geeignete Beispiele sind der vollständige Verlust des Kesselspeisewassers, das Versagen einer Turbinenauslösefunktion, der vollständige Ausfall der Kommunikation mit der Steuerung oder ein unkontrollierter Druckanstieg in einem Reaktor. Die Definition muss hinreichend spezifisch sein, um eine aussagekräftige Analyse zu ermöglichen.

Ein Top-Ereignis, das lediglich als „Systemausfall“ beschrieben wird, ist in der Regel zu vage. Es legt nicht fest, welche Funktion ausgefallen ist, wie lange der Ausfall andauerte oder welcher Betriebszustand vorlag. Eine bessere Definition könnte lauten: „Verlust des gesamten Kühlwasserstroms für mehr als sechzig Sekunden während der normalen Produktion.“ Diese Formulierung schafft eine klare Grenze für die Analyse.

Sobald das Top-Ereignis definiert ist, ermittelt das Team die unmittelbaren Bedingungen, die es verursachen könnten. Diese Bedingungen werden in Ereignisse auf niedrigerer Ebene zerlegt, bis die Analyse grundlegende Komponentenausfälle, externe Störungen oder menschliche Handlungen erreicht. Logische Gatter verbinden die Ereignisse und beschreiben, wie sie sich kombinieren. ODER-Gatter zeigen an, dass jedes aufgeführte Ereignis das übergeordnete Ereignis verursachen kann, während UND-Gatter erfordern, dass mehrere Ereignisse gleichzeitig eintreten.

Der fertiggestellte Baum stellt die Ausfalllogik visuell dar. Er ermöglicht es Fachleuten aus den Bereichen Elektrotechnik, Mechanik, Instrumentierung, Verfahrenstechnik, Instandhaltung und Sicherheit, dasselbe System aus einer gemeinsamen Perspektive zu betrachten. Dieses gemeinsame Modell ist eine der größten praktischen Stärken der FTA. Es erleichtert, verborgene Annahmen zu hinterfragen, bevor sie in der Konstruktion verankert werden.

Abbildung 2. Ein Fehlerbaum arbeitet rückwärts von einem definierten Top-Ereignis und identifiziert die Kombinationen von Ausfällen auf niedrigerer Ebene, die dieses Ereignis verursachen können.

Fehlerbaumanalyse Schritt für Schritt entwickeln

Die erste praktische Aufgabe besteht darin, die Systemgrenze festzulegen. Ingenieure müssen entscheiden, welche Ausrüstung, Versorgungseinrichtungen, Software, Bediener und externen Dienste in die Analyse einbezogen werden. Eine Untersuchung des Kühlsystems kann Pumpen, Ventile, Stromverteilung, Instrumentierung und Steuerungslogik umfassen. Gegebenenfalls müssen auch die Wasserquelle, Umgebungsbedingungen und Bedienerreaktionen einbezogen werden, wenn diese Faktoren das Top-Ereignis beeinflussen können.

Das Team ermittelt anschließend die unmittelbaren Ursachen. Ein vollständiger Kühlungsverlust kann auftreten, weil alle Pumpen nicht verfügbar sind, der gemeinsame Versorgungssammler verstopft ist oder Absperrventile fehlerhaft schließen. Jede unmittelbare Ursache wird weiter aufgegliedert. Die Nichtverfügbarkeit einer Pumpe kann durch einen Motorausfall, einen Lagerfresser, den Verlust der Ansaugung, einen Ausfall der Steuerung oder einen Verlust der Stromversorgung verursacht werden.

Der Prozess wird fortgesetzt, bis eine weitere Zerlegung die Entscheidung nicht mehr verbessern würde. Ereignisse auf der niedrigsten Ebene werden als Basisereignisse behandelt und können Ausfallwahrscheinlichkeiten oder -raten erhalten. Die logische Struktur kann anschließend qualitativ oder quantitativ ausgewertet werden. Selbst wenn keine genauen numerischen Daten verfügbar sind, kann der Fehlerbaum einzelne Ausfallpunkte und unerwartete gemeinsame Abhängigkeiten aufzeigen.

Eine quantitative FTA kombiniert Ereigniswahrscheinlichkeiten entsprechend der Struktur der Verknüpfungsglieder. Die Berechnung mag einfach erscheinen, doch Unabhängigkeitsannahmen müssen sorgfältig geprüft werden. Zwei Ereignisse, die dieselbe Stromquelle, Umgebung, Instandhaltungsmaßnahme oder denselben Softwarefehler teilen, sind nicht vollständig unabhängig. Werden diese Zusammenhänge ignoriert, kann ein redundantes Design deutlich sicherer erscheinen, als es tatsächlich ist.

Minimalschnittmengen zeigen die gefährlichsten Kombinationen

Eine Schnittmenge ist eine Kombination aus Basisereignissen, die das Top-Ereignis verursacht. Eine minimale Schnittmenge enthält kein unnötiges Ereignis; das Entfernen eines beliebigen Ereignisses würde verhindern, dass das Top-Ereignis eintritt. Diese Kombinationen helfen Ingenieuren, die kürzesten und wichtigsten Ausfallpfade zu identifizieren. Sie sind besonders wertvoll, wenn ein großer Fehlerbaum Hunderte von Ereignissen enthält.

Eine aus einem einzelnen Ereignis bestehende Minimalschnittmenge zeigt, dass ein einziger Ausfall das Top-Ereignis direkt verursachen kann. Solche Ergebnisse verdienen normalerweise sofortige Aufmerksamkeit bei der Auslegung. Das Team kann Redundanz ergänzen, die Isolation verbessern, eine separate Stromversorgung bereitstellen oder eine weitere Schutzebene einführen. Schnittmengen aus zwei oder drei Ereignissen stellen häufig Ausfälle innerhalb redundanter Architekturen dar.

Nicht jede kurze Schnittmenge birgt dasselbe Risiko. Eine Kombination aus zwei Ereignissen mit häufigen Ausfällen kann bedeutsamer sein als ein einzelnes äußerst seltenes externes Ereignis. Auch Erkennungs- und Reparaturzeiten beeinflussen die Bedeutung. Ein unentdeckter Fehler, der monatelang bestehen bleibt, führt zu einem wesentlich längeren Expositionszeitraum als ein Fehler, der sofort erkannt und behoben wird.

FTA-Software kann Minimalschnittmengen nach ihrem berechneten Beitrag ordnen. Ingenieure sollten jedoch weiterhin die physikalische Bedeutung hinter den Zahlen prüfen. Eine mathematisch geringe Wahrscheinlichkeit kann auf schwachen Annahmen oder allgemeinen Daten beruhen, die die tatsächliche Anlage nicht abbilden. Während der gesamten Analyse bleibt technisches Urteilsvermögen erforderlich.

Beispiel: Kesselspeisewasser-Redundanz, die nicht wirklich unabhängig ist

Betrachten wir ein Kraftwerk, das zwei Kesselspeisewasserpumpen betreibt. Jede der beiden Pumpen kann den erforderlichen Mindestdurchfluss aufrechterhalten, sodass das System scheinbar den Ausfall einer Pumpe tolerieren kann. Eine einfache Zählung der Ausrüstung lässt auf vollständige Redundanz schließen. Der Fehlerbaum kann jedoch ein anderes Bild ergeben, sobald gemeinsame Abhängigkeiten berücksichtigt werden.

Beide Pumpenmotoren können über dieselbe elektrische Sammelschiene mit Strom versorgt werden. Beide Pumpen können aus einer gemeinsamen Saugleitung fördern, vom selben Leitsystem abhängig sein oder Befehle von einer einzigen Füllstandsmessung erhalten. Ein einzelner Fehler der Sammelschiene, eine blockierte Saugleitung oder ein fehlerhaftes gemeinsames Signal könnte daher beide Pumpen gleichzeitig außer Betrieb setzen. Die scheinbare Redundanz durch zwei Pumpen würde keinen Schutz gegen diese gemeinsamen Ausfälle bieten.

Die Analyse kann zu mehreren praktischen Verbesserungen führen. Getrennte Stromversorgungen können den Verlust der gemeinsamen Stromversorgung verringern. Unterschiedliche Füllstandsmessungen können die Abhängigkeit von einer einzigen Messumformertechnologie reduzieren. Unabhängige Steuerpfade, verbesserte manuelle Bedienung und eine bessere Überwachung der Ansaugung können die Architektur stärken, ohne unbedingt eine weitere vollständige Pumpe hinzuzufügen.

Dieses Beispiel zeigt, warum die FTA nützlicher ist, als redundante Geräte einfach zu zählen. Sie bewertet, ob die Geräte unter realen Betriebsbedingungen unabhängig bleiben. Außerdem zeigt sie, wo zusätzliche Komplexität einen echten Schutz bietet und wo sie lediglich den Anschein von Schutz erweckt.

Wo die Fehlerbaumanalyse gut funktioniert – und wo nicht

Die FTA ist besonders wirksam für Sicherheitsfunktionen, Schutzsysteme, elektrische Verteilungen, Kommunikationsnetze und andere Anwendungen mit einem klar definierten unerwünschten Ereignis. Ihre visuelle Struktur unterstützt Konstruktionsprüfungen und Gespräche mit Aufsichtsbehörden. Sie kann qualitativ eingesetzt werden, um Schwachstellen aufzudecken, oder quantitativ, um die Wahrscheinlichkeit des Top-Ereignisses zu schätzen.

Die Methode wird weniger wirksam, wenn das Top-Ereignis unzureichend definiert ist. Zudem kann ihre Pflege schwierig werden, wenn der Fehlerbaum auf Tausende von Ereignissen anwächst. Dynamische Abläufe, Wartungsverhalten und wechselnde Betriebszustände können spezielle Gatter oder zusätzliche Modellierungstechniken erfordern. Ein statischer Fehlerbaum beschreibt nicht von Natur aus jede zeitabhängige Beziehung.

Auch menschliche Handlungen erfordern eine sorgfältige Betrachtung. Die Wahrscheinlichkeit einer Bedienerreaktion hängt von der Alarmqualität, der Gestaltung der Verfahren, der Schulung, der Arbeitsbelastung, der verfügbaren Zeit und den Bedingungen der Benutzeroberfläche ab. Die Zuweisung einer einzigen allgemeinen Wahrscheinlichkeit für menschliches Versagen kann diese Unterschiede verschleiern. Bei umfassenden Analysen sollten Fachleute für Human Factors einbezogen werden, wenn die Bedienerhandlung für das Ergebnis maßgeblich ist.

Die FTA ist daher besonders wirksam, wenn sie als Teil eines umfassenderen Zuverlässigkeitsprogramms eingesetzt wird. Die FMEA kann detaillierte Komponentenausfallarten liefern, während Markov- oder Monte-Carlo-Verfahren Reparaturen, Abläufe und Unsicherheiten berücksichtigen können. Kein einzelner Fehlerbaum sollte als vollständige Darstellung sämtlichen Systemverhaltens betrachtet werden.

Die Fehlzustands- und Auswirkungsanalyse beginnt mit der Komponente

Die Fehlzustands- und Auswirkungsanalyse verwendet einen induktiven Ansatz. Statt mit einem Top-Ereignis zu beginnen, startet das Team mit einem Element, einer Funktion oder einem Prozessschritt. Anschließend wird untersucht, wie dieses Element ausfallen könnte und welche Auswirkungen jeder Ausfall lokal und im gesamten System hätte. Diese Vorgehensweise macht die FMEA besonders während der Konstruktion und bei der Überprüfung von Anlagen nützlich.

Ein Druckmessumformer kann auf verschiedene Arten ausfallen. Sein Ausgang kann zu hohe oder zu niedrige Werte anzeigen, auf einem Wert einfrieren, instabil werden oder vollständig ausfallen. Jeder Modus führt zu einer anderen betrieblichen Folge. Ein zu hoher Messwert kann eine unnötige Abschaltung auslösen, während ein zu niedriger Messwert einen gefährlichen Druckzustand verbergen kann.

Die FMEA zwingt das Team, diese Unterschiede zu beschreiben, anstatt lediglich „Messumformerausfall“ zu dokumentieren. Sie untersucht außerdem bestehende Maßnahmen zur Vermeidung und Erkennung. Die Analyse kann Diagnosen, Vergleichslogik, Funktionstests, Alarme, Überbrückungen oder Bedienerprüfungen identifizieren, die die Folgen verringern. Eine unzureichende Erkennung kann ebenso wichtig werden wie der ursprüngliche Ausfallmodus.

Abbildung 3. Die FMEA bewertet einzelne Ausfallmodi, ihre Auswirkungen, ihren Schweregrad und die verfügbaren Maßnahmen zu ihrer Vermeidung oder Erkennung.

Was ein wirksames FMEA-Arbeitsblatt enthalten sollte

Ein nützliches FMEA-Arbeitsblatt beginnt mit dem betrachteten Element und seiner erforderlichen Funktion. Der Ausfallmodus beschreibt, wie die Funktion verloren gehen, beeinträchtigt oder fehlerhaft ausgeführt werden kann. Die lokale Auswirkung beschreibt, was auf Komponentenebene geschieht, während die Systemauswirkung die weiterreichende betriebliche oder sicherheitstechnische Folge beschreibt. Ursachen und Mechanismen werden getrennt von den Auswirkungen erfasst.

Das Arbeitsblatt dokumentiert außerdem bestehende Schutzmaßnahmen. Präventive Maßnahmen verringern die Wahrscheinlichkeit, dass der Ausfall eintritt. Aufdeckende Maßnahmen erkennen den Ausfall, bevor er eine unzulässige Folge verursacht. Beispiele sind Eigendiagnosen, der Vergleich redundanter Signale, Alarmgrenzen, Funktionstests, Inspektionen und vorausschauende Instandhaltung.

Viele Organisationen vergeben Bewertungen für Schweregrad, Auftretenswahrscheinlichkeit und Entdeckungswahrscheinlichkeit. Diese Werte werden manchmal multipliziert, um eine Risikoprioritätszahl zu ermitteln. Die Zahl kann bei der Priorisierung helfen, sollte jedoch niemals das technische Urteil ersetzen. Unterschiedliche Kombinationen können denselben Wert ergeben, obwohl sich ihre Folgen grundlegend unterscheiden.

Ein seltener katastrophaler Ausfall kann mehr Aufmerksamkeit verdienen als eine häufige geringfügige Unannehmlichkeit, selbst wenn die berechneten Bewertungen ähnlich erscheinen. Der Schweregrad sollte daher unabhängig überprüft werden. Teams sollten außerdem Maßnahmen priorisieren, die den Ausfallmechanismus beseitigen oder die Folgen verringern, statt sich ausschließlich auf zusätzliche Inspektionen zu verlassen.

Beispiel: Redundante SPS-Eingänge mit einer gemeinsamen Schwachstelle

Betrachten Sie zwei digitale Eingangskanäle, die einen Not-Aus-Feldschalter überwachen. Die Architektur erscheint redundant, da zwei SPS-Eingänge das Signal empfangen. Eine FMEA untersucht, ob der gesamte Signalpfad tatsächlich unabhängig ist. Sie berücksichtigt den Feldkontakt, die Verdrahtung, die Eingangsstromversorgung, Klemmenbaugruppen, Module, die Logik und das Diagnoseverhalten.

Mögliche Fehlermöglichkeiten sind eine Unterbrechung, ein Kurzschluss, ein verschweißter Kontakt, ein dauerhaft auf High stehender Kanal, ein dauerhaft auf Low stehender Kanal oder der Verlust der gemeinsamen Eingangsspannungsversorgung. Die Analyse fragt auch, ob eine Abweichung zwischen den Kanälen erkannt wird. Wenn beide Kanäle einen gemeinsamen Feldkontakt und ein gemeinsames Kabel verwenden, wirken sich viele plausible Fehler gleichzeitig auf beide Kanäle aus.

Die Prüfung kann zeigen, dass doppelte Eingangsmodule nur begrenzten zusätzlichen Schutz bieten. Separate Kontakte, überwachte Feldstromkreise, unabhängige Stromversorgungspfade oder unterschiedliche Messprinzipien können erforderlich sein. Das Prüftestverfahren muss außerdem die gesamte Signalkette verifizieren, anstatt nur das SPS-Modul zu testen.

Bei Schutzarchitekturen können Ingenieure außerdem geeignete industrielle Sicherheitsmodule prüfen, die für Diagnoseabdeckung, Redundanz und ein kontrolliertes Ausfallverhalten ausgelegt sind. Die Hardwareauswahl muss dennoch dem vollständigen Sicherheitslebenszyklus folgen und kann keine anwendungsspezifische Analyse ersetzen.

Design-FMEA und Prozess-FMEA behandeln unterschiedliche Risiken

Die Design-FMEA untersucht das entwickelte Produkt oder System. Sie prüft, ob die ausgewählte Architektur, die Komponenten, die Materialien und die Steuerungsfunktionen bestimmungsgemäß funktionieren können. Die Methode wird häufig während der Konzeptentwicklung, der Detailkonstruktion und bei Konstruktionsänderungen angewendet. Am wertvollsten ist sie, bevor Änderungen an der Konstruktion kostspielig werden.

Die Prozess-FMEA untersucht Fertigungs-, Montage-, Installations-, Inbetriebnahme- oder Wartungsaktivitäten. Ein Schaltschrank kann elektrisch korrekt konstruiert sein, doch der Installationsprozess kann dennoch lose Klemmen, vertauschte Polarität, falsche Sicherungsnennwerte oder eine falsche Aderkennzeichnung verursachen. Wartungsarbeiten können zu inkompatibler Firmware, ungeeigneten Ersatzteilen, deaktivierten Alarmen oder weiterhin aktiven Überbrückungen führen.

Diese beiden FMEA-Formen sollten sich gegenseitig ergänzen. Konstruktive Maßnahmen können die Installationsempfindlichkeit verringern, während Prozessmaßnahmen Ausführungsfehler verhindern können, die sich durch die Konstruktion nicht beseitigen lassen. Eine ausschließliche Prüfung der Anlagenkonstruktion lässt viele Risiken über den Lebenszyklus hinweg unberücksichtigt. Eine ausschließliche Prüfung des Arbeitsprozesses kann Schwachstellen verbergen, die bereits in der ursprünglichen Architektur angelegt sind.

Bei kritischen Automatisierungssystemen sollten beide Analysen nach wesentlichen Änderungen aktualisiert werden. Der Austausch einer Steuerung, eine Netzwerkmigration, ein Software-Upgrade oder eine Änderung des Prüftestverfahrens kann neue Fehlermöglichkeiten einführen. Historische Arbeitsblätter sollten nicht unverändert bleiben, während sich die Anlage weiterentwickelt.

FMECA bietet eine formalere Kritikalitätsbewertung

Die Fehlermöglichkeits-, Einfluss- und Kritikalitätsanalyse erweitert die FMEA-Struktur um formale Kritikalitätsberechnungen. Die Methode kann Bauteilausfallraten, Betriebsbeanspruchung, Missionsphasen, Schweregradkategorien und bedingte Wahrscheinlichkeiten verwenden. Sie ist hilfreich, wenn ein großes System zahlreiche Fehlermöglichkeiten enthält und technische Ressourcen auf die wichtigsten Verursacher konzentriert werden müssen.

Kritikalitätsberechnungen hängen stark von der Datenqualität ab. Allgemeine Ausfallratendatenbanken bieten einen Ausgangspunkt, spiegeln jedoch möglicherweise nicht die tatsächliche Installation wider. Temperatur, Vibration, Verunreinigungen, elektrische Belastung, Instandhaltungsqualität und Betriebszyklus beeinflussen allesamt die tatsächliche Leistung. Anlagenspezifische Nachweise sollten allgemeine Annahmen ersetzen, wenn ausreichende Betriebshistorien verfügbar sind.

Die Analyse sollte außerdem zwischen sofort erkannten Ausfällen und Ausfällen unterscheiden, die verborgen bleiben. Ein unbemerkter Ausfall einer Bereitschaftskomponente kann die Produktion möglicherweise erst beeinträchtigen, wenn eine weitere Komponente ausfällt oder eine Anforderung eintritt. Die lange verborgene Exposition kann dazu führen, dass ein relativ seltener Ausfall sehr wichtig wird. Erkennungsintervalle und die Wirksamkeit von Wiederholungsprüfungen müssen daher einbezogen werden.

Die FMECA ist besonders nützlich, wenn ihre Ergebnisse zu Maßnahmen an Konstruktion oder Instandhaltung führen. Eine komplexe Rangfolgetabelle hat nur geringen Wert, wenn sie Architektur, Ersatzteilbestand, Diagnosen, Prüfungen oder Betriebsverfahren nicht beeinflusst. Der Zweck bleibt die praktische Risikominderung und nicht die Berechnung um ihrer selbst willen.

Wo die FMEA gut funktioniert – und wo sie irreführen kann

Die FMEA ermöglicht eine strukturierte komponentenweise Prüfung. Sie lässt sich relativ leicht erklären und unterstützt die Beteiligung von Fachleuten aus Entwicklung, Betrieb, Instandhaltung, Qualität und Sicherheit. Das daraus entstehende Maßnahmenregister kann direkt mit Konstruktionsänderungen, Inspektionen, Diagnosen und Verbesserungen der Instandhaltung verknüpft werden.

Bei sehr großen Systemen kann die Methode repetitiv werden. Teams verbringen möglicherweise übermäßig viel Zeit mit der Dokumentation von Ausfallarten mit geringem Nutzen und übersehen dabei Wechselwirkungen im System. Die traditionelle FMEA untersucht zudem meist jeweils nur einen Ausfall. Mehrere gleichzeitige Ausfälle und sequenzabhängige Ereignisse werden möglicherweise nicht klar erfasst.

Bewertungssysteme bergen ein weiteres Risiko. Teams können Bewertungen anpassen, um eine gewünschte Priorität zu erreichen, oder die endgültige Zahl als objektiver ansehen als das zugrunde liegende Urteil. Eine niedrige Bewertung beweist nicht, dass ein Ausfall akzeptabel ist. Ereignisse mit hoher Schwere, Ausfälle gemeinsamer Ursache und behördliche Anforderungen sollten separat geprüft werden.

Die Qualität einer FMEA hängt von den Personen ab, die sie durchführen. Ein von einem Konstrukteur erstelltes Arbeitsblatt kann praktische Gegebenheiten übersehen, die Bedienern und Technikern bekannt sind. Aussagekräftige Untersuchungen verbinden Konstruktionswissen mit tatsächlicher Instandhaltungshistorie und Betriebserfahrung.

Die Monte-Carlo-Simulation verwandelt Unsicherheit in eine Verteilung

Berechnungen zur industriellen Zuverlässigkeit umfassen häufig unsichere Eingangsgrößen. Die Lebensdauer von Komponenten variiert, die Reparaturdauer ändert sich, die Lieferung von Ersatzteilen ist unvorhersehbar, und Umweltbelastungen beeinflussen das Ausfallverhalten. Ein einzelner Durchschnittswert kann diese Schwankungen nicht immer abbilden. Die Monte-Carlo-Simulation begegnet diesem Problem durch wiederholte Zufallsstichproben.

Zunächst erstellt der Ingenieur ein Systemmodell und weist unsicheren Variablen Wahrscheinlichkeitsverteilungen zu. Anschließend erzeugt die Simulation zahlreiche mögliche Kombinationen. In einem Durchlauf kann angenommen werden, dass eine Pumpe nach 8.000 Stunden ausfällt und innerhalb von vier Stunden repariert wird. In einem anderen Durchlauf kann ein späterer Ausfall auftreten, jedoch mit einer wesentlich längeren Reparaturdauer, weil das benötigte Ersatzteil nicht verfügbar ist.

Nach Tausenden oder Millionen von Durchläufen bilden die Ergebnisse eine Verteilung. Das Modell kann erwartete Ausfallzeiten, Produktionsverluste, die Systemverfügbarkeit, die Wahrscheinlichkeit eines erfolgreichen Einsatzes, den Ersatzteilbedarf oder die Instandhaltungskosten schätzen. Es kann außerdem die Wahrscheinlichkeit extremer Ergebnisse aufzeigen, die in einem einzigen Durchschnittswert verloren gingen.

Abbildung 4. Die Monte-Carlo-Simulation bewertet zahlreiche zufällig generierte Ausfall- und Reparaturszenarien, um eine Bandbreite möglicher Ergebnisse zu schätzen.

Erstellung eines verlässlichen Monte-Carlo-Zuverlässigkeitsmodells

Die Qualität der Simulation hängt vom Systemmodell ab. Das Modell muss Komponenten, Betriebsregeln, Ausfallverteilungen, Reparaturverhalten, Abhängigkeiten, Standby-Logik und Instandhaltungsressourcen abbilden. Es kann außerdem Wetter, Produktionsbedarf, logistische Verzögerungen und menschliche Reaktionen einbeziehen, wenn diese Faktoren die Systemleistung beeinflussen.

Jeder simulierte Durchlauf bildet das System im Zeitverlauf ab. Komponenten fallen gemäß den Stichproben aus den Verteilungen aus, Reparaturen beginnen, sobald Ressourcen verfügbar sind, und das Modell zeichnet auf, ob das System betriebsbereit, eingeschränkt funktionsfähig oder nicht verfügbar bleibt. Durch die Wiederholung des Prozesses entstehen Schätzungen für verschiedene Leistungskennzahlen.

Eine Validierung ist unerlässlich. Das Team sollte das Modell mit vereinfachten Berechnungen, bekannten Betriebsfällen und historischen Ergebnissen der Anlage vergleichen. Unerwartete Ergebnisse sollten untersucht und nicht einfach akzeptiert werden, nur weil sie von einer Software stammen. Eine visuell beeindruckende Simulation kann dennoch falsch sein, wenn die zugrunde liegende Logik unvollständig ist.

Eine Sensitivitätsanalyse hilft dabei festzustellen, welche Annahmen das Ergebnis bestimmen. Wenn die Reparaturzeit einen wesentlich größeren Einfluss als die Ausfallrate hat, kann das Management möglicherweise größeren Nutzen aus einer besseren Ersatzteilverfügbarkeit und einer schnelleren Diagnose ziehen. Wenn die Wahrscheinlichkeit eines gemeinsamen Ausfalls dominiert, bringt das Hinzufügen weiterer identischer Komponenten möglicherweise nur wenig Nutzen.

Auswahl von Wahrscheinlichkeitsverteilungen, die dem Ausfallmechanismus entsprechen

Eine Exponentialverteilung setzt eine konstante Ausfallrate voraus. Sie kann für einige elektronische Komponenten während ihrer Nutzungsdauer geeignet sein. Eine Weibull-Verteilung ist flexibler und kann Frühausfälle, zufällige Ausfälle oder Verschleißverhalten darstellen. Lognormalverteilungen eignen sich häufig für Reparaturdauern und Prozesse, die von mehreren sich multiplizierenden Faktoren beeinflusst werden.

Die Wahl sollte den physikalischen Mechanismus und nicht die Bequemlichkeit der Software widerspiegeln. Ein verschleißbedingter Lagerausfall folgt naturgemäß nicht demselben Verhalten wie ein zufälliger Kommunikationsfehler. Die Verwendung einer konstanten Ausfallrate für beide Fälle kann Langzeitprognosen verfälschen. Zuverlässigkeitsingenieure sollten die Betriebshistorie und die Ausfallmechanismen prüfen, bevor sie die Verteilung auswählen.

Historische Daten müssen häufig bereinigt werden. Instandhaltungssysteme können einen geplanten Austausch mit einem Funktionsausfall verwechseln. Ausfalldaten werden möglicherweise beim Eröffnen des Arbeitsauftrags eingetragen und nicht beim Auftreten des Fehlers. Auch Anlagennamen, Betriebsstunden und Fehlercodes können zwischen verschiedenen Standorten uneinheitlich sein.

Begrenzte Daten verhindern keine Analyse, doch die Unsicherheit sollte sichtbar bleiben. Experteneinschätzungen, Lieferanteninformationen und Branchendatenbanken können frühe Schätzungen unterstützen. Das Modell sollte einen realistischen Bereich testen, statt eine unsichere Annahme als präzise Tatsache darzustellen.

Beispiel: Verfügbarkeit einer Station mit drei Kompressoren

Betrachten wir eine Station mit drei Gaskompressoren. Zwei Einheiten werden für die volle Produktion benötigt, während die dritte Reservekapazität bereitstellt. Jede Maschine weist unterschiedliche Betriebsstunden, eine andere Wartungshistorie und eine andere Kühlleistung auf. Da die Station nur über ein spezialisiertes Wartungsteam verfügt, kann immer nur eine größere Reparatur gleichzeitig durchgeführt werden.

Ersatzlager benötigen mehrere Tage für die Lieferung, und Ausfälle des Kühlsystems treten bei hohen Umgebungstemperaturen häufiger auf. Diese Wechselwirkungen lassen sich nur schwer mit einer einfachen Verfügbarkeitsgleichung abbilden. Ein Monte-Carlo-Modell kann Kompressorausfälle, Reparaturdauern, Wetterperioden, die Verfügbarkeit von Technikern und Verzögerungen in der Logistik simulieren.

Die Ergebnisse können eine Verfügbarkeit bei voller Kapazität, einen Betrieb mit reduzierter Kapazität und einen vollständigen Stationsausfall zeigen. Das Management kann alternative Investitionen vergleichen. Die Lagerung zusätzlicher Lager kann extreme Ausfallzeiten möglicherweise wirksamer reduzieren als die Einstellung eines weiteren allgemeinen Wartungstechnikers. Eine höhere Zuverlässigkeit der Kühlung kann größeren Nutzen bringen als der Austausch eines ansonsten funktionsfähigen Kompressors.

Das Modell kann auch Wartungsintervalle testen. Kürzere vorbeugende Wartungsintervalle können Ausfälle reduzieren, erhöhen jedoch möglicherweise die geplante Stillstandszeit und die durch Wartungsarbeiten verursachten Fehler. Mit der Simulation lassen sich beide Effekte innerhalb desselben Betriebsmodells bewerten.

Wo die Monte-Carlo-Simulation gut funktioniert – und wo sie scheitert

Monte-Carlo-Methoden sind besonders leistungsfähig, wenn viele unsichere Variablen miteinander interagieren. Sie können komplexe Logistikprozesse, Reparaturwarteschlangen, Wettereinflüsse, Produktionsnachfrage und Instandhaltungsentscheidungen abbilden. Die resultierende Verteilung liefert mehr Informationen als ein einzelner Durchschnittswert. Außerdem unterstützt sie risikobasierte Entscheidungen, indem sie die Wahrscheinlichkeit schwerwiegender, aber selten auftretender Ergebnisse aufzeigt.

Die größte Schwäche ist die Glaubwürdigkeit des Modells. Eine komplizierte Simulation kann falsches Vertrauen schaffen, weil ihre Ergebnisse numerisch präzise erscheinen. Das Programm berechnet lediglich die Folgen der Annahmen, die der Analyst eingegeben hat. Fehlende Abhängigkeiten oder unrealistische Verteilungen können zu irreführenden Ergebnissen führen.

Simulationen erfordern außerdem ausreichend viele Durchläufe, um stabile Schätzwerte zu erzielen. Wahrscheinlichkeiten für seltene Ereignisse können spezielle Stichprobenverfahren erfordern, da eine gewöhnliche Zufallssimulation eine praktisch unüberschaubar große Zahl an Durchläufen benötigen würde. Konfidenzintervalle sollten angegeben werden, damit die Nutzer die statistische Unsicherheit verstehen.

Die Methode ist daher besonders wertvoll, wenn Modelllogik, Datenquellen und Einschränkungen transparent bleiben. Zuverlässigkeitsentscheidungen sollten nicht auf einer Grafik basieren, deren Annahmen dem Betriebs- und Engineering-Personal nicht erklärt werden können.

Die Root-Cause-Analyse beginnt nach dem Ereignis

Die Root-Cause-Analyse untersucht, warum ein tatsächlicher Ausfall, ein Qualitätsproblem oder ein Sicherheitsereignis eingetreten ist. Sie geht über die Identifizierung der beschädigten Komponente hinaus. Ein Motor kann ausfallen, weil ein Lager festgelaufen ist, aber der Austausch des Lagers stellt lediglich den Betrieb wieder her. Die Untersuchung muss feststellen, warum das Lager diesen Zustand erreicht hat.

Zu den tieferliegenden Ursachen können Verunreinigungen, falsche Schmierung, unsachgemäße Lagerung, Beschädigungen bei der Installation, übermäßige Prozessbelastung oder versäumte Inspektionen gehören. Auch organisatorische Bedingungen können dazu beitragen. Instandhaltungsaufgaben können gestrichen worden sein, Ersatzteile ungeeignet gewesen sein oder der Produktionsdruck kann Korrekturarbeiten verzögert haben.

RCA trennt daher Symptome, direkte physische Ursachen, beitragende Bedingungen und zugrunde liegende Systemschwächen. Diese Unterscheidung verhindert, dass die Organisation jede Reparatur als dauerhafte Lösung betrachtet. Außerdem liefert sie Erkenntnisse, die zukünftige FMEA, FTA, die Instandhaltungsplanung und Betriebsverfahren verbessern können.

Abbildung 5. RCA verfolgt einen Ausfall über das sichtbare Symptom hinaus zurück und identifiziert die technischen und organisatorischen Bedingungen, die sein Auftreten ermöglicht haben.

Beweismittel müssen gesichert werden, bevor die Anlage zum Normalbetrieb zurückkehrt

Industrielle Beweismittel können schnell verschwinden. Bediener können Alarme zurücksetzen, Techniker Module austauschen und sich Prozessbedingungen ändern. Steuerungsprotokolle können frühere Ereignisse überschreiben, während beschädigte Komponenten vor der Untersuchung entsorgt werden können. Ein disziplinierter RCA-Prozess beginnt daher mit der Beweissicherung.

Das Team sollte Verlaufstrends aus dem Historian, Alarmlisten, Ereignisprotokolle der Steuerungen, Relaisaufzeichnungen, Arbeitsaufträge, Fotos, beschädigte Teile, Softwareversionen, Konfigurationsdateien und Beobachtungen des Bedienpersonals sammeln. Jedes Element sollte anhand seiner Quelle und seines Zeitpunkts identifiziert werden. Physische Beweismittel sollten unter Kontrolle bleiben, bis die Untersuchung feststellt, ob eine weitere Prüfung erforderlich ist.

Der Zeitsynchronisierung sollte besondere Aufmerksamkeit gewidmet werden. Eine Steuerung, ein Historian, ein Schutzrelais, ein Server und ein Instandhaltungssystem können unterschiedliche Zeitstempel aufzeichnen. Ermittler müssen diese Unterschiede korrigieren, bevor sie die Ereignisabfolge erstellen. Andernfalls kann ein späterer Alarm fälschlicherweise als auslösendes Ereignis erscheinen.

Bedienerinterviews sollten zeitnah, aber sorgfältig durchgeführt werden. Menschen erinnern sich möglicherweise an Abläufe und Zusammenhänge, die automatisierte Systeme nicht erfasst haben. Ihre Aussagen sollten als Beweismittel und nicht als Schuldzuweisung behandelt werden. Ziel ist es, die Betriebsumgebung zu verstehen, in der Entscheidungen getroffen wurden.

Die Ereigniszeitachse erstellen, bevor man nach dem Warum fragt

Eine belastbare Zeitachse trennt verifizierte Fakten von Interpretationen. Sie dokumentiert, was vor, während und nach dem Ausfall passiert ist. Jedes Ereignis sollte mit einer Quelle verknüpft sein, etwa einem Historian-Wert, einem Alarmprotokoll, einer Wartungsmaßnahme, einem Foto oder einer Zeugenaussage. Lücken und Widersprüche sollten sichtbar bleiben.

Der erste Alarm, der dem Bediener angezeigt wird, ist nicht immer das erste physische Ereignis. Alarmfluten können die auslösende Bedingung unter Hunderten von Folgemeldungen verbergen. Hochauflösende Sequenzdaten können zeigen, dass Druckinstabilität, eine Netzstörung oder ein Kommunikationsverlust früher begonnen hat. Die Zeitachse hilft dabei, Ursache und Folge zu unterscheiden.

Sobald die Abfolge verstanden ist, kann das Team Methoden wie die Fünf-Warum-Fragen, Fischgrätendiagramme, Barrierenanalysen, Änderungsanalysen oder Diagramme der kausalen Faktoren einsetzen. Einfache Ereignisse lassen sich durch eine kurze Ursachenkette erklären. Komplexe Vorfälle umfassen in der Regel mehrere miteinander wechselwirkende technische und organisatorische Bedingungen.

Die Untersuchung sollte nicht enden, nachdem eine plausible Erklärung gefunden wurde. Alternative Hypothesen sollten anhand der Belege geprüft werden. Nicht belegte Annahmen sollten weiterhin als Annahmen gekennzeichnet und nicht als bestätigte Ursachen dargestellt werden.

Beispiel: Wiederholte Ausfälle von Frequenzumrichtern

In einer Anlage kommt es wiederholt zu Ausfällen eines Frequenzumrichters, der ein Förderband steuert. Nach jedem Ereignis tauscht die Instandhaltung den Antrieb aus, und die Produktion läuft wieder normal. Einige Monate später fällt ein weiterer Antrieb aus. Der wiederholte Austausch deutet darauf hin, dass der Antrieb selbst möglicherweise nicht das vollständige Problem darstellt.

Das RCA-Team vergleicht die Ausfalldaten mit Umwelt- und Wartungsaufzeichnungen. Die meisten Ausfälle traten während heißer Sommerperioden auf. Temperaturverläufe des Schaltschranks zeigen einen längeren Betrieb oberhalb des bevorzugten Bereichs. Die Inspektion zeigt verstopfte Filter, einen eingeschränkten Luftstrom und starke Staubablagerungen rund um den Kühlweg.

Die Wartungshistorie zeigt, dass die regelmäßige Filterreinigung nach einer Änderung der Personalstärke aus dem vorbeugenden Wartungsplan entfernt wurde. Der Antrieb ist das ausgefallene Bauteil, aber eine überhöhte Schaltschranktemperatur ist die direkte physikalische Ursache. Eingeschränkte Belüftung und die fehlende Wartungsaufgabe sind beitragende sowie organisatorische Ursachen.

Die Korrekturmaßnahme sollte daher über den Austausch eines weiteren Frequenzumrichters hinausgehen. Das Werk kann die Filterwartung wiederherstellen, Temperaturalarme installieren, die Schaltschrankkühlung verbessern und die Auslegung des Gehäuses überprüfen. Die Wirksamkeit sollte während der nächsten Hochtemperaturperiode überprüft werden.

Korrekturmaßnahmen müssen mit verifizierten Ursachen verknüpft sein

Viele Berichte zu Ursachenanalysen werden bei der Planung von Korrekturmaßnahmen unzureichend. Teams empfehlen möglicherweise zusätzliche Schulungen, ohne nachzuweisen, dass unzureichende Kenntnisse vorlagen. Sie überarbeiten möglicherweise Verfahren, obwohl das eigentliche Problem in einer mangelhaften Anlagenauslegung liegt. Sie führen möglicherweise Inspektionen ein, die den tatsächlichen Ausfallmechanismus nicht erkennen können.

Jede Maßnahme sollte eine verifizierte Ursache oder einen nachgewiesenen beitragenden Faktor adressieren. Sie sollte einen Verantwortlichen, ein Abschlussdatum und eine festgelegte Verifizierungsmethode haben. Die Organisation sollte zwischen vorübergehender Eindämmung, Korrekturmaßnahme und langfristiger Präventivmaßnahme unterscheiden. Die Wiederaufnahme der Produktion ist nicht dasselbe wie die Verhinderung eines erneuten Auftretens.

Die Wirksamkeit muss nach der Umsetzung überprüft werden. Eine abgeschlossene Maßnahme ist nicht automatisch erfolgreich. Das Werk sollte bestätigen, ob die Ausfallwahrscheinlichkeit gesunken ist, ob die neue Kontrolle angewendet wird und ob sie ein weiteres Risiko eingeführt hat. Dieses Feedback schließt den Kreislauf zur Verbesserung der Zuverlässigkeit.

Bei schwerwiegenden Untersuchungen kann eine unabhängige Überprüfung erforderlich sein. Teams, die eng in das Ereignis eingebunden sind, können durch frühere Annahmen oder organisatorischen Druck beeinflusst werden. Eine externe oder funktionsübergreifende Überprüfung kann die Analyse hinterfragen, bevor die endgültigen Schlussfolgerungen akzeptiert werden.

Menschliches Versagen ist selten eine vollständige Grundursache

„Bedienfehler“ und „Wartungsfehler“ tauchen häufig in oberflächlichen Untersuchungen auf. Diese Bezeichnungen beschreiben, wer die letzte Handlung ausgeführt hat, erklären aber nicht, warum diese Handlung wahrscheinlich wurde. Menschen arbeiten innerhalb von Benutzeroberflächen, Verfahren, Personalbesetzung, Produktionsanforderungen, Schulungssystemen und Anlagenauslegungen. Die Untersuchung sollte all diese Bedingungen prüfen.

Ein Bediener kann die falsche Steuerung auswählen, weil zwei Bildschirmelemente nahezu identisch aussehen. Ein Techniker kann das falsche Teil einbauen, weil die Kennzeichnung uneinheitlich ist. Ein Vorgesetzter kann Wartungsarbeiten aufschieben, weil die Organisation eine ununterbrochene Produktion belohnt, aber kein realistisches Zeitfenster für einen Anlagenstillstand bereitstellt.

Das Verständnis dieser Bedingungen hebt die individuelle Verantwortung nicht auf. Es verhindert, dass dasselbe System eine andere Person zum gleichen Fehler führt. Eine auf Schuldzuweisung ausgerichtete Untersuchung mag ein unmittelbares Bedürfnis nach Verantwortungszuweisung befriedigen, lässt aber die zugrunde liegende Schwachstelle möglicherweise unangetastet.

Eine wirksame Ursachenanalyse untersucht, wie das System die Entscheidung beeinflusst hat. Sie fragt, ob Alarme verständlich, Verfahren praktikabel, die Arbeitsbelastung angemessen und die erforderlichen Werkzeuge verfügbar waren. Diese Fragen führen zu besseren Korrekturmaßnahmen, als die Menschen einfach nur anzuweisen, vorsichtiger zu sein.

Wo die Ursachenanalyse gut funktioniert – und wo nicht

Die Ursachenanalyse wandelt reale Betriebserfahrungen in präventives Wissen um. Sie kann Konstruktionsschwächen, Lücken in der Instandhaltung, Verfahrensprobleme und organisatorische Zwänge aufdecken, die in Prognosestudien übersehen wurden. Ihre Ergebnisse können Zuverlässigkeitsmodelle und Standards für künftige Projekte verbessern.

Die Methode ist reaktiv, weil sie nach einem Ereignis beginnt. Branchen mit schwerwiegenden Folgen können sich nicht ausschließlich darauf verlassen, aus Ausfällen zu lernen. Proaktive Methoden wie FMEA und FTA bleiben notwendig. Die Ursachenanalyse sollte sie ergänzen, indem sie Annahmen mit Erkenntnissen aus dem tatsächlichen Betrieb aktualisiert.

Untersuchungen können außerdem subjektiv werden. Bestätigungsfehler können dazu führen, dass Teams die erste passende Erklärung bevorzugen. Fehlende Belege können dazu zwingen, Schlussfolgerungen unsicher zu halten. Gute Berichte trennen klar zwischen bestätigten Ursachen, beitragenden Faktoren, Hypothesen und offenen Fragen.

Der Nutzen einer Ursachenanalyse hängt von der konsequenten Umsetzung ab. Eine technisch fundierte Untersuchung bringt wenig Nutzen, wenn Maßnahmen verzögert, abgeschwächt oder nie überprüft werden. Das Engagement des Managements ist daher ebenso wichtig wie die analytische Kompetenz.

Markov-Modelle verfolgen das System durch wechselnde Zustände

Die Markov-Modellierung stellt ein System anhand definierter Betriebszustände dar. Ein einfaches System kann nur einen betriebsbereiten und einen ausgefallenen Zustand enthalten. Ein fehlertolerantes System benötigt normalerweise zusätzliche Zustände wie vollständig redundant, degradiert, ausgefallen, in Reparatur oder auf ein Ersatzteil wartend. Übergänge verbinden diese Zustände.

Eine Ausfallrate kann das System vom vollständig betriebsbereiten in einen degradierten Zustand überführen. Ein weiterer Ausfall kann es vom degradierten in den nicht verfügbaren Zustand überführen. Eine Reparaturrate kann das System in den vollständig betriebsbereiten Zustand zurückführen. Das Modell berechnet die Wahrscheinlichkeit, mit der sich das System im Zeitverlauf in jedem Zustand befindet.

Diese Struktur eignet sich besonders für reparierbare Systeme. Sie kann Redundanz, Bereitschaftsanlagen, Diagnoseabdeckung, Reaktionszeiten der Instandhaltung und teilweise Produktionskapazität abbilden. Anders als eine einfache Zuverlässigkeitsformel zeigt sie, wie lange das System nach dem ersten Ausfall möglicherweise gefährdet bleibt.

Abbildung 6. Markov-Modelle beschreiben, wie sich Systeme zwischen intakten, degradierten, ausgefallenen und reparierten Zuständen bewegen.

Ein Zwei-Zustands-Modell liefert das Grundprinzip

Das einfachste Markov-Modell enthält einen betriebsbereiten Zustand und einen ausgefallenen Zustand. Die Ausfallrate steuert den Übergang vom betriebsbereiten in den ausgefallenen Zustand. Die Reparaturrate steuert den Übergang zurück in den betriebsbereiten Zustand. Aus diesen Übergängen kann das Modell die Verfügbarkeit über einen definierten Zeitraum oder unter stationären Bedingungen schätzen.

Dieses Modell eignet sich für einfache reparierbare Anlagen, beschreibt jedoch die meisten redundanten Automatisierungssysteme nicht vollständig. Ein zweikanaliger Controller kann den Betrieb fortsetzen, nachdem ein Kanal ausgefallen ist. Das System bleibt funktionsfähig, verliert jedoch seine Redundanz. Es befindet sich nun in einem degradierten Zustand und ist einem zweiten Ausfall stärker ausgesetzt.

Durch das Hinzufügen des degradierten Zustands kann das Modell berechnen, wie oft und wie lange das System ohne vollständigen Schutz arbeitet. Die Reparaturgeschwindigkeit wird dadurch besonders wichtig. Ein System mit zuverlässigen Komponenten kann dennoch übermäßig viel Zeit im degradierten Zustand verbringen, wenn Fehlerdiagnose, Lieferung von Ersatzteilen oder die Genehmigung der Wartung langsam erfolgen.

Das Modell kann außerdem zwischen erkannten und unerkannten Ausfällen unterscheiden. Ein erkannter Kanalausfall kann eine sofortige Reparatur auslösen. Ein unerkannter Fehler kann verborgen bleiben, bis eine Anforderung oder ein weiterer Ausfall eintritt. Die Diagnoseabdeckung verändert die Übergangsstruktur und damit die berechnete Verfügbarkeit und das Risiko.

Beispiel: Ein dual-redundantes Controller-Paar

Betrachten wir zwei Controller, die als redundantes Paar angeordnet sind. Zustand eins steht für zwei gesunde Controller. Zustand zwei steht für einen ausgefallenen Controller, während der zweite weiterhin die Steuerung übernimmt. Zustand drei steht für den Ausfall beider Controller und die vollständige Nichtverfügbarkeit der Steuerung.

Das Modell umfasst die Ausfallrate jedes Controllers und die Reparaturrate nach der Erkennung. Es kann außerdem Umschaltfehler, einen gemeinsamen Stromausfall und einen gemeinsamen Softwarefehler berücksichtigen. Diese zusätzlichen Übergänge verhindern, dass die Analyse von perfekter Unabhängigkeit ausgeht.

Die Ergebnisse können zwischen der Verfügbarkeit vollständiger Redundanz und der funktionalen Verfügbarkeit unterscheiden. Das System kann während des größten Teils des Jahres in der Lage bleiben, den Prozess zu steuern, während es eine erhebliche Anzahl von Stunden nur einen gesunden Controller aufweist. Diese Belastung durch den degradierten Zustand kann für eine kritische Anwendung unzulässig sein.

Das Modell kann Strategien zur Verbesserung vergleichen. Ein schnellerer Austausch von Ersatzteilen kann die Belastung durch den degradierten Zustand wirksamer verringern als das Hinzufügen eines dritten Controllers. Eine bessere Diagnose kann einen größeren Nutzen bringen als eine geringfügige Senkung der Hardware-Ausfallrate. Die Markow-Analyse macht diese Zielkonflikte messbar.

Standby-Ausrüstung benötigt mehr als nur einen Zustand für aktive Ausfälle

Redundanz im Standby-Betrieb führt zu zusätzlichem Verhalten. Eine Standby-Pumpe kann stillstehen, bis die Betriebspumpe ausfällt. Die Standby-Einheit kann einen verborgenen Fehler aufweisen, nicht starten oder auf ein Problem in der Umschaltlogik stoßen. Auch Absperrventile können daran scheitern, in die erforderliche Stellung zu fahren.

Ein Markow-Modell kann Zustände für aktive gesunde Ausrüstung, nicht verfügbare Standby-Ausrüstung, Umschaltfehler, reduzierte Kapazität und den vollständigen Systemausfall enthalten. Eine Wiederholungsprüfung führt das System von einem unbekannten Ruhezustand in Richtung eines bekannten Zustands. Das Intervall zwischen den Tests beeinflusst, wie lange verborgene Ausfälle möglich bleiben.

Wartungsrichtlinien können innerhalb derselben Struktur bewertet werden. Kürzere Testintervalle verbessern die Erkennung verborgener Fehler, erhöhen jedoch den Wartungsaufwand und können zusätzliche Fehler verursachen. Das Modell kann diese gegenläufigen Effekte vergleichen, anstatt davon auszugehen, dass häufigere Tests immer besser sind.

Die Standby-Analyse sollte auch die Reparaturlogistik einbeziehen. Eine ausgefallene Standby-Komponente unterbricht die Produktion möglicherweise nicht sofort, sodass sich die Reparatur verzögern kann. Dadurch bleibt das System ungeschützt, wenn die aktive Einheit später ausfällt. Betriebliche Prioritäten beeinflussen die Zuverlässigkeit daher ebenso stark wie die Eigenschaften der Hardware.

Die Markow-Annahme sorgt sowohl für Einfachheit als auch für Einschränkungen

Ein einfaches Markow-Modell nimmt an, dass das künftige Übergangsverhalten vom aktuellen Zustand und nicht von der vollständigen Vorgeschichte abhängt. Diese Annahme vereinfacht die Mathematik und erfordert häufig konstante Übergangsraten. Einige Industrieanlagen lassen sich während eines begrenzten Zeitraums hinreichend gut durch diese Näherung beschreiben.

Alterung und kumulierte Schäden können diese Annahme verletzen. Ein stark abgenutztes Lager weist künftig nicht dasselbe Ausfallverhalten auf wie ein neues Lager, selbst wenn beide derzeit in Betrieb sind. Zusätzliche Degradationszustände können die Alterung näherungsweise abbilden, während für eine genauere Darstellung möglicherweise semi-Markowsche oder andere Modelle erforderlich sind.

Die Zustandsraumexplosion ist eine weitere Herausforderung. Jeder Zustand einer Komponente kann die Anzahl möglicher Systemzustände vervielfachen. Eine komplexe redundante Anlage kann schnell Tausende oder Millionen von Kombinationen erzeugen. Um die Analyse beherrschbar zu halten, können Modellreduktion, Gruppierung oder Simulation erforderlich sein.

Das Modell sollte genügend Details enthalten, um die Entscheidung zu unterstützen, ohne jede physische Abweichung abzubilden. Übermäßige Komplexität führt zu Problemen bei Pflege und Validierung. Ein zu einfaches Modell verbirgt wichtiges Verhalten, während ein zu detailliertes Modell nicht mehr erklärbar ist.

Wo die Markow-Modellierung gut funktioniert – und wo nicht

Die Markow-Modellierung eignet sich gut für reparierbare redundante Systeme, Standby-Ausrüstung, degradierte Betriebsarten und Diagnoseabdeckung. Sie unterstützt die Verfügbarkeitsanalyse und zeigt, wie die Reaktion der Instandhaltung die Systemexposition verändert. Sie ist besonders nützlich, wenn die Abfolge von Ausfall- und Reparaturzuständen eine Rolle spielt.

Die Methode hängt von korrekten Zustandsdefinitionen und Übergangsraten ab. Annahmen konstanter Raten bilden Alterung, Umgebungsvariationen oder die Qualität der Instandhaltung möglicherweise nicht ab. Ausfälle gemeinsamer Ursache müssen explizit dargestellt werden, statt sie in unabhängigen Komponentenraten zu verbergen.

Die Ergebnisse sollten durch eine Sensitivitätsanalyse gestützt werden. Das Team sollte prüfen, wie sich die Schlussfolgerungen ändern, wenn Ausfallraten, Reparaturzeiten, Diagnoseabdeckung und Annahmen zu gemeinsamen Ursachen variieren. Ein Design, das nur unter einer einzigen optimistischen Annahme akzeptabel erscheint, ist nicht robust.

Markow-Modelle sind analytische Werkzeuge und kein physischer Nachweis. Tests, Betriebserfahrungen, FMEA und FTA bleiben erforderlich. Das Modell hilft beim Vergleich von Strategien, kann jedoch die Verifizierung der tatsächlichen Architektur nicht ersetzen.

Die fünf Methoden als ein Zuverlässigkeitssystem nutzen

Die fünf Verfahren bieten den größten Nutzen, wenn sie miteinander verknüpft sind. Eine FMEA kann während der Auslegung detaillierte Ausfallarten von Komponenten ermitteln. Anschließend kann eine FTA bestimmen, welche Kombinationen zu einem kritischen Systemereignis beitragen. Eine Markov-Modellierung kann beschreiben, wie sich das System nach dem ersten Ausfall und während der Reparatur verhält.

Eine Monte-Carlo-Simulation kann unsichere Eingaben wie Reparaturdauern, Ersatzteillieferungen, Wetter und die Auslastung der Instandhaltung prüfen. Eine RCA liefert nach realen Ausfällen Belege und kann Annahmen aufdecken, die die ursprünglichen Modelle übersehen haben. Die Modelle sollten anschließend aktualisiert werden, statt als historische Dokumente unverändert zu bleiben.

Angenommen, eine FTA behandelt zwei Controllerausfälle als unabhängig. Eine spätere RCA zeigt, dass beide Controller ausfielen, nachdem ein Instandhaltungstechniker dieselbe fehlerhafte Konfiguration geladen hatte. Der Fehlerbaum muss ein gemeinsames Instandhaltungsereignis ergänzen. Auch Markov- und Monte-Carlo-Modelle sollten die neue Abhängigkeit berücksichtigen.

Dieser Rückkopplungsprozess schafft ein kontinuierliches Zuverlässigkeitsprogramm. Prädiktive Analysen unterstützen die Auslegung, Betriebserfahrungen prüfen die Annahmen, und Untersuchungsergebnisse verbessern die nächste Generation von Modellen. Zuverlässigkeitsarbeit wird dadurch zu einem Bestandteil des Systemlebenszyklus statt zu einer einmaligen Projektanforderung.

Ausfälle gemeinsamer Ursache können eine gesamte redundante Architektur außer Kraft setzen

Ausfälle gemeinsamer Ursache beeinträchtigen mehrere Kanäle durch eine zugrunde liegende Bedingung. Gemeinsame Stromversorgung, Kühlung, Netzwerkinfrastruktur, Software, Umwelteinflüsse und Instandhaltungspraktiken sind häufige Beispiele. Diese Ausfälle sind besonders gefährlich, weil sie eine auf dem Papier robust wirkende Redundanz außer Kraft setzen können.

Eine räumliche Trennung verringert einige gemeinsame Ursachen. Unterschiedliche Geräte oder Software können andere Ursachen reduzieren. Eine unabhängige Verifizierung kann Instandhaltungs- und Konfigurationsfehler verringern. Diversität erhöht jedoch auch die Komplexität von Schulungen, Ersatzteilhaltung, Tests und Integration.

Die richtige Lösung hängt vom Risiko ab. Der Einsatz verschiedener Controllertechnologien kann gemeinsame Softwareausfälle verringern, aber neue Herausforderungen bei Kommunikation und Instandhaltung schaffen. Getrennte Stromversorgungen bieten möglicherweise nur wenig Nutzen, wenn sich beide weiterhin im selben überschwemmungsgefährdeten Schaltschrank befinden. Zuverlässigkeitsmethoden helfen dabei, zu ermitteln, welche Diversitätsmaßnahmen glaubwürdige Ausfallmechanismen wirksam adressieren.

Annahmen zu Ausfällen gemeinsamer Ursache sollten in jedem quantitativen Modell sichtbar sein. Redundante Kanäle als vollkommen unabhängig zu behandeln, führt fast immer zu einem zu optimistischen Ergebnis. Betriebserfahrungen und Ergebnisse der Ursachenanalyse liefern wertvolle Belege für die Schätzung dieser Abhängigkeiten.

Die Diagnoseabdeckung bestimmt, wie lange das System verwundbar bleibt

Ein redundantes System lässt sich nicht effektiv verwalten, wenn Ausfälle unentdeckt bleiben. Die Diagnoseabdeckung beschreibt den Anteil der relevanten Fehler, die durch automatische oder manuelle Kontrollen erkannt werden. Eine hohe Abdeckung verringert die Zeit, in der das System unbemerkt eingeschränkt leistungsfähig ist. Außerdem ermöglicht sie es der Instandhaltung, die Redundanz wiederherzustellen, bevor ein weiterer Ausfall eintritt.

Diagnoseaussagen müssen sorgfältig geprüft werden. Eine Steuerung kann interne Prozessorfehler erkennen, aber nicht jeden Fehler in der Feldverdrahtung. Ein Kommunikationsmodul kann den vollständigen Verlust einer Verbindung erkennen, aber möglicherweise eine fehlerhafte Datenzuordnung nicht feststellen. Eine Stromversorgung kann nach einem vollständigen Ausfall der Ausgangsleistung einen Alarm auslösen, aber keine Warnung vor einer schleichenden Verschlechterung liefern.

Mit Funktionstests werden Fehler abgedeckt, die durch kontinuierliche Diagnosen nicht erkannt werden. Das Prüfintervall beeinflusst die Exposition. Längere Intervalle ermöglichen, dass unerkannte Fehler länger bestehen bleiben, während sehr kurze Intervalle den Wartungsaufwand und das durch die Prüfung verursachte Risiko erhöhen. FMEA, Markov-Analysen und Betriebserfahrungen können ein ausgewogenes Intervall unterstützen.

Die Prüfung muss die vollständige Funktion abdecken. Das Aktivieren eines SPS-Eingangs beweist nicht, dass der Feldschalter, die Verdrahtung, die Logik, der Ausgang und das Stellglied am Ende alle ordnungsgemäß funktionieren. Die Zuverlässigkeitsanalyse sollte genau festlegen, welche Fehler durch die jeweilige Diagnose oder den Funktionstest erkannt werden können.

Die Reparaturzeit ist oft ebenso wichtig wie die Ausfallrate

Zuverlässigkeitsprogramme konzentrieren sich häufig darauf, die Ausfallhäufigkeit von Komponenten zu reduzieren. In fehlertoleranten Systemen kann die Reparaturzeit ebenso wichtig sein. Nach dem Ausfall des ersten Kanals kann das System weiterarbeiten, bleibt jedoch gefährdet. Lange Reparaturverzögerungen erhöhen die Wahrscheinlichkeit, dass ein zweiter Ausfall zu einem vollständigen Verlust führt.

Diagnose, Genehmigungen, die Verfügbarkeit von Technikern, Ersatzteile, Zugangsgenehmigungen und die Produktionsbedingungen beeinflussen alle die Wiederherstellungszeit. Der Austausch einer Komponente kann fünfzehn Minuten dauern, nachdem das richtige Ersatzteil den Schaltschrank erreicht hat. Die tatsächliche Ausfallzeit kann sich dennoch über Tage erstrecken, wenn das Ersatzteil international beschafft werden muss.

Verbesserte Diagnosen können die Zeit zur Fehlerlokalisierung verkürzen. Standardisierte Module und vorkonfigurierte Ersatzteile können die Austauschzeit reduzieren. Lokale Lagerbestände, klare Eskalationsverfahren und technische Unterstützung aus der Ferne können logistische Verzögerungen verkürzen. Markov- und Monte-Carlo-Modelle können den Nutzen dieser Verbesserungen quantifizieren.

Die beste Investition in die Zuverlässigkeit ist nicht immer robustere Hardware. In manchen Systemen führt eine Verkürzung der Reparaturzeit zu einer stärkeren Risikoreduzierung als eine geringfügige Verbesserung der Ausfallrate von Komponenten. Die Analyse sollte beide Optionen vergleichen.

Anwendung der Zuverlässigkeitsanalyse auf DCS- und SPS-Architekturen

Die Zuverlässigkeit eines Steuerungssystems hängt von mehr als nur dem Zentralprozessor ab. Ingenieure sollten Steuerungen, I/O-Module, Kommunikationsnetzwerke, Stromversorgungen, Server, Bedienerstationen, die Zeitsynchronisierung, Feldschnittstellen und unterstützende Versorgungseinrichtungen überprüfen. Jedes gemeinsam genutzte Element kann zu einer gemeinsamen Abhängigkeit werden.

Redundante Steuerungen können sich ein I/O-Rack teilen. Redundante Server können von einem Netzwerk-Switch oder einem Speichersystem abhängen. Remote-I/O-Netzwerke können separate Kommunikationskanäle verwenden, die über dieselbe physische Trasse verlaufen. Eine vollständige Analyse muss der Funktion vom Feldgerät bis zur abschließenden Steueraktion folgen.

Das erforderliche Verhalten nach einem Ausfall sollte klar definiert werden. Der Prozess kann mit dem verbleibenden Controller fortgesetzt, auf manuellen Betrieb umgeschaltet oder kontrolliert heruntergefahren werden. Das Wartungspersonal muss wissen, wie der ausgefallene Kanal identifiziert und das System wiederhergestellt wird, ohne den funktionsfähigen Kanal zu beeinträchtigen.

Organisationen, die Steuerungsmodernisierungen planen, können auch typische Komponenten von DCS-Steuerungssystemen prüfen, die in Prozessautomatisierungsarchitekturen eingesetzt werden. Die Komponentenauswahl sollte sich stets an den Zuverlässigkeitsanforderungen der gesamten Anwendung und nicht an isolierten Produkteigenschaften orientieren.

Zuverlässige Modelle hängen von zuverlässigen Wartungsdaten ab

Die quantitative Zuverlässigkeitsanalyse ist nur so aussagekräftig wie die zugrunde liegenden Daten. Wartungsaufzeichnungen sollten Funktionsausfall, geplanten Austausch, Inspektion und Änderung unterscheiden. Das Ausfalldatum sollte den Zeitpunkt des Funktionsverlusts darstellen, während das Wiederherstellungsdatum angeben sollte, wann der Betrieb tatsächlich wieder verfügbar war.

Die Identitäten der Anlagen müssen im Historian, im Wartungssystem, in den Zeichnungen und in der Ersatzteildatenbank konsistent bleiben. Ausfallcodes sollten Mechanismen statt vager Symptome beschreiben. „Stillstand“ bietet nur geringen analytischen Nutzen, während „Lagerschaden infolge von Schmierstoffverunreinigung“ die zukünftige Modellierung und Prävention unterstützt.

Auch die Betriebsexposition muss berücksichtigt werden. Eine kontinuierlich laufende Pumpe kann nicht direkt mit einer Stand-by-Pumpe verglichen werden, die nur während Tests läuft. Temperatur, Feuchtigkeit, Verunreinigung, Vibration, elektrische Belastung und Prozesslast können Unterschiede zwischen ansonsten identischen Komponenten erklären.

Die Datenbereinigung sollte als ingenieurtechnische Arbeit und nicht als administrative Vorbereitung betrachtet werden. Falsche Klassifizierungen können Ausfallraten, Reparaturverteilungen und Modellschlussfolgerungen verfälschen. Analysten sollten ungewöhnliche Ergebnisse gemeinsam mit Wartungs- und Betriebspersonal prüfen, bevor sie diese akzeptieren.

Ein praxisorientierter Workflow zur Verbesserung der Zuverlässigkeit

Ein Zuverlässigkeitsprojekt sollte mit der Definition der erforderlichen Funktion und der Systemgrenze beginnen. Das Team muss festlegen, welche Leistung während des Normalbetriebs und nach jedem glaubwürdigen Fehler erforderlich ist. Es sollte Zeichnungen, Handbücher, Wartungshistorien, Betriebsanweisungen, Alarmaufzeichnungen und frühere Vorfallberichte zusammentragen.

Die FMEA kann anschließend Ausfallarten auf Komponentenebene und Schwachstellen bei den Erkennungskontrollen identifizieren. Die FTA kann kritische Top-Ereignisse und gemeinsame Abhängigkeiten untersuchen. Die Markov-Modellierung kann degradierte Zustände und die Reaktion auf Reparaturen bewerten, während die Monte-Carlo-Simulation Unsicherheiten bei Ausfällen, Wartung und Logistik abbilden kann.

Historische Vorfälle sollten mithilfe einer RCA überprüft werden. Die Erkenntnisse sollten zur Aktualisierung der Designanalysen und quantitativen Annahmen genutzt werden. Maßnahmen sollten nach Auswirkung, Wahrscheinlichkeit, Erkennbarkeit, Exposition, Reparaturzeit und Kosten priorisiert werden.

Jede Maßnahme benötigt einen Verantwortlichen, einen Fertigstellungstermin und eine Wirksamkeitsprüfung. Die Analysen sollten nach größeren Änderungen an Anlagen, Softwareaktualisierungen, Prozessänderungen oder Änderungen der Instandhaltungsstrategie aktualisiert werden. Zuverlässigkeit ist eine fortlaufende ingenieurtechnische Disziplin und kein Bericht, der einmal erstellt und abgelegt wird.

Die Fragen, die schwache Aussagen zur Fehlertoleranz offenlegen

Eine gründliche Überprüfung fragt, welche Funktion verfügbar bleiben muss und welche Fehler das System tolerieren kann. Sie prüft, ob redundante Kanäle physisch, elektrisch und logisch unabhängig sind. Außerdem wird gefragt, wie latente Fehler erkannt werden und wie lange das System vor einer Reparatur in einem beeinträchtigten Zustand bleiben darf.

Das Team sollte Komponenten mit langen Wiederbeschaffungszeiten identifizieren und ermitteln, ob ein einziger Instandhaltungsfehler mehrere Kanäle beeinflussen kann. Software- und Konfigurationsabhängigkeiten sollten die gleiche Aufmerksamkeit erhalten wie Hardware. Bediener müssen verstehen, wie sich das System nach einem Fehler verhält und welche manuellen Maßnahmen weiterhin möglich sind.

Annahmen zu Ausfällen und Reparaturen sollten nach Möglichkeit durch Betriebsdaten aus der Anlage gestützt werden. Korrekturmaßnahmen sollten nach ihrer Umsetzung verifiziert werden. Funktionsprüfungen sollten die vollständige Schutzfunktion nachweisen und nicht nur die Reaktion einzelner Geräte.

Diese Fragen sind wertvoller als die allgemeine Aussage, dass das System redundant ist. Sie verknüpfen die Fehlertoleranz mit der tatsächlichen Architektur, der Betriebsumgebung und den Instandhaltungsmöglichkeiten.

Abschließende Betrachtung

Fehlertoleranz ist unverzichtbar, wenn Stillstandszeiten, unsicheres Verhalten oder ein Kontrollverlust nicht akzeptiert werden können. Redundanz allein schafft jedoch kein zuverlässiges System. Ingenieure müssen Fehlerarten, gemeinsame Abhängigkeiten, Diagnoseabdeckung, beeinträchtigten Betrieb, Reparaturverhalten und betriebliche Folgen verstehen.

Die Fehlerbaumanalyse zeigt, wie Kombinationen von Ausfällen ein kritisches Ereignis verursachen können. Die FMEA bietet eine systematische Untersuchung einzelner Fehlerarten und ihrer Auswirkungen. Die Monte-Carlo-Simulation bewertet unsichere Szenarien, während die Ursachenanalyse reale Ausfälle in vorbeugendes Wissen umwandelt. Die Markov-Modellierung erklärt, wie reparierbare Systeme zwischen intakten, beeinträchtigten, ausgefallenen und wiederhergestellten Zuständen wechseln.

Jede Methode hat Einschränkungen, doch gemeinsam bieten sie einen soliden Rahmen für die Zuverlässigkeit. Auslegungsstudien sollten anhand von Betriebserfahrungen aktualisiert werden, und Erkenntnisse aus Vorfällen sollten künftige Modelle verbessern. Die Ergebnisse müssen Architektur, Instandhaltung, Ersatzteile, Prüfungen, Schulungen und Verfahren beeinflussen.

Das Ziel besteht nicht darin, ein System zu schaffen, das niemals einen Fehler aufweist. Ziel ist es, Fehler frühzeitig zu erkennen, ihre Folgen einzudämmen, die erforderliche Funktion aufrechtzuerhalten und die volle Leistungsfähigkeit planbar wiederherzustellen. Das ist die praktische Bedeutung industrieller Fehlertoleranz.