Fünf Zuverlässigkeitstechniken zur Analyse der industriellen Fehlertoleranz

Warum Fehlertoleranz mehr als redundante Hardware erfordert

Jedes industrielle System wird irgendwann Fehler erleben. 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 vielmehr sicherzustellen, dass vorhersehbare Fehler nicht unmittelbar zu unkontrollierten Systemausfällen werden.

Ein fehlertolerantes System kann eine akzeptable Funktion weiterhin bereitstellen, 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 können stattdessen in einen kontrollierten sicheren Zustand übergehen, wenn der weitere Betrieb ein nicht akzeptables Risiko darstellen würde.

Redundante Komponenten sind häufig Bestandteil dieser Strategie, doch allein die Verdopplung von Komponenten 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 aufgrund derselben Verstopfung ausfallen. Die Zuverlässigkeitsanalyse muss daher die vollständige Architektur untersuchen, einschließlich Abhängigkeiten, die auf einer Ausrüstungsliste nicht unmittelbar erkennbar sind.

Für diese Arbeit sind fünf Methoden besonders nützlich. Die Fehlerbaumanalyse untersucht, wie Kombinationen von Ausfällen ein definiertes Top-Ereignis auslösen 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 in zahlreichen möglichen Betriebs- und Ausfallszenarien, während die Ursachenanalyse ermittelt, 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, doch eine konsequente Zuverlässigkeitstechnik kann verhindern, dass sich viele Fehler zu vollständigen Ausfällen entwickeln.

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

Zuverlässigkeitsbegriffe werden häufig ungenau 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 hinweg erfüllt. Verfügbarkeit beschreibt, ob die Anlage bereitsteht, wenn der Prozess sie benötigt. Ein System kann gelegentlich ausfallen und dennoch eine hohe Verfügbarkeit aufrechterhalten, 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, doch 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, bevor sie wissen, welche Leistung nach jedem glaubwürdigen Fehler erhalten bleiben muss.

Ein Verdichterschutzsystem muss beispielsweise möglicherweise nach dem Ausfall eines Sensors weiterhin eine Notauslösefunktion gewährleisten. Ein Prozessleitsystem muss möglicherweise nur den stabilen Betrieb aufrechterhalten, während ein Regler ausgetauscht wird. Eine Stromschutzlösung kann unabhängige Kanäle erfordern, damit ein einzelner gemeinsamer Fehler nicht sowohl den primären als auch den резервierenden Schutz außer Betrieb setzen kann. Zuverlässigkeitstechniken helfen Ingenieuren, diese Anforderungen in prüfbare Designs zu überführen.

Auswahl einer Methode anhand der ingenieurtechnischen Fragestellung

Die fünf Zuverlässigkeitstechniken befassen sich mit unterschiedlichen Teilen desselben Problems. Die FTA 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 ausführt.

Eine RCA 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, Bereitschaftsbetrieb, Leistungseinbußen 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 gewöhnlich mit einer FTA beginnen. Ein Konstruktionsteam, das jeden möglichen Ausfall von Messumformer, Regler und Ventil überprüft, wird mehr von einer FMEA profitieren. Ein Anlagenmanager, der unsichere Instandhaltungsintervalle vergleicht, kann eine Monte-Carlo-Simulation einsetzen, während ein Zuverlässigkeitsingenieur, der die langfristige Verfügbarkeit eines redundanten Reglerpaares 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 innerhalb eines Fehlerbaums werden. Erkenntnisse aus einer RCA können unrealistische Fehlerannahmen in einem Markov-Modell korrigieren. Eine Monte-Carlo-Simulation kann prüfen, wie sich unsichere Wahrscheinlichkeiten auf Schlussfolgerungen aus einer FTA 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 Verlust der Kommunikation mit dem Regler oder ein unkontrollierter Druckanstieg in einem Reaktor. Die Definition muss spezifisch genug 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 weder fest, welche Funktion ausgefallen ist, wie lange der Ausfall andauerte noch welcher Betriebszustand vorlag. Eine bessere Definition wäre beispielsweise „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, identifiziert das Team die unmittelbaren Bedingungen, die es verursachen könnten. Diese Bedingungen werden in Ereignisse 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 voraussetzen, dass mehrere Ereignisse gleichzeitig eintreten.

Der fertiggestellte Fehlerbaum 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 zählt zu den größten praktischen Stärken der Fehlerbaumanalyse (FTA). Es erleichtert die kritische Prüfung verborgener Annahmen, bevor diese in die Auslegung einfließen.

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

Einen Fehlerbaum Schritt für Schritt entwickeln

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

Das Team identifiziert anschließend die unmittelbaren Ursachen. Ein vollständiger Kühlungsverlust kann auftreten, weil alle Pumpen nicht verfügbar sind, der gemeinsame Versorgungssammler blockiert ist oder Absperrventile fehlerhaft schließen. Jede unmittelbare Ursache wird weiter aufgeschlüsselt. Die Nichtverfügbarkeit einer Pumpe kann auf einen Motorausfall, einen Lagerschaden, den Verlust der Ansaugung, einen Ausfall der Steuerung oder den Verlust der Stromversorgung zurückzuführen sein.

Der Prozess wird fortgesetzt, bis eine weitere Dekomposition die Entscheidung nicht mehr verbessern würde. Die Ereignisse auf der untersten 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 Ausfallstellen und unerwartete gemeinsame Abhängigkeiten aufzeigen.

Eine quantitative FTA kombiniert Ereigniswahrscheinlichkeiten entsprechend der Struktur der Verknüpfung. Die Berechnung mag einfach erscheinen, doch Unabhängigkeitsannahmen müssen sorgfältig geprüft werden. Zwei Ereignisse, die dieselbe Stromquelle, Umgebung, Wartungsmaßnahme oder denselben Softwarefehler gemeinsam haben, sind nicht vollständig unabhängig. Werden diese Zusammenhänge ignoriert, kann eine redundante Auslegung deutlich sicherer erscheinen, als sie tatsächlich ist.

Minimale Schnittmengen zeigen die gefährlichsten Kombinationen

Eine Schnittmenge ist eine Kombination grundlegender Ereignisse, die das Top-Ereignis verursacht. Eine minimale Schnittmenge enthält kein unnötiges Ereignis; das heißt, das Entfernen eines beliebigen Ereignisses würde das Auftreten des Top-Ereignisses verhindern. 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 minimale Schnittmenge aus einem einzelnen Ereignis zeigt an, dass ein einziger Ausfall das Top-Ereignis unmittelbar verursachen kann. Solche Ergebnisse erfordern normalerweise sofortige Aufmerksamkeit bei der Auslegung. Das Team kann Redundanz hinzufügen, die Trennung 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 weist dasselbe Risiko auf. 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 unbemerkt bleibt, führt zu einem deutlich längeren Expositionszeitraum als ein Fehler, der sofort erkannt und behoben wird.

FTA-Software kann Schnittmengen nach ihrem berechneten Beitrag einstufen. 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 widerspiegeln. Während der gesamten Analyse bleibt ingenieurtechnisches Urteilsvermögen erforderlich.

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

Betrachten wir ein Kraftwerk, in dem zwei Kesselspeisewasserpumpen betrieben werden. Jede der beiden Pumpen kann den erforderlichen Mindestdurchfluss aufrechterhalten, sodass das System scheinbar den Ausfall einer Pumpe verkraften kann. Eine einfache Zählung der Betriebsmittel 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 denselben elektrischen Bus mit Strom versorgt werden. Beide Pumpen können aus einer gemeinsamen Saugleitung fördern, vom selben Steuerungssystem abhängen oder Befehle von einer einzigen Füllstandsmessung erhalten. Ein einzelner Busfehler, 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 das Risiko eines vollständigen Stromausfalls verringern. Unterschiedliche Füllstandmessungen können die Abhängigkeit von einer einzigen Transmittertechnologie reduzieren. Unabhängige Regelpfade, ein verbesserter manueller Betrieb und eine bessere Überwachung der Ansaugung können die Architektur stärken, ohne zwangsläufig eine weitere vollständige Pumpe hinzuzufügen.

Dieses Beispiel zeigt, warum die FTA nützlicher ist als das bloße Zählen redundanter Geräte. 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 effektiv 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 regulatorische Gespräche. Sie kann qualitativ eingesetzt werden, um Schwachstellen aufzudecken, oder quantitativ, um die Wahrscheinlichkeit des Top-Ereignisses zu schätzen.

Die Methode wird weniger effektiv, wenn das Top-Ereignis schlecht definiert ist. Außerdem kann ihre Pflege schwierig werden, wenn der Baum auf Tausende von Ereignissen anwächst. Dynamische Abläufe, Wartungsverhalten und sich ändernde 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 Reaktion des Bedieners hängt von der Qualität der Alarme, der Gestaltung der Verfahren, der Schulung, der Arbeitsbelastung, der verfügbaren Zeit und den Bedingungen an der Benutzeroberfläche ab. Die Zuweisung einer einzigen allgemeinen Wahrscheinlichkeit für menschliches Versagen kann diese Unterschiede verschleiern. Bei ernsthaften Analysen sollten Spezialisten für menschliche Faktoren einbezogen werden, wenn die Handlung des Bedieners für das Ergebnis entscheidend ist.

Die FTA ist daher besonders wirkungsvoll, wenn sie als Teil eines umfassenderen Zuverlässigkeitsprogramms eingesetzt wird. Die FMEA kann detaillierte Ausfallarten von Komponenten liefern, während Markov- oder Monte-Carlo-Verfahren Reparatur, Ablauf und Unsicherheiten berücksichtigen können. Kein einzelner Fehlerbaum sollte als vollständige Darstellung sämtlicher Systemverhalten betrachtet werden.

Die Fehler-Möglichkeits- und Einfluss-Analyse beginnt mit der Komponente

Die Fehler-Möglichkeits- und Einfluss-Analyse (FMEA) 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 gefragt, wie dieses Element ausfallen könnte und welche Auswirkungen jeder Ausfall lokal und im gesamten System hätte. Diese Vorgehensweise macht die FMEA besonders bei der Entwicklung und der Anlagenüberprüfung nützlich.

Ein Drucktransmitter kann auf mehrere verschiedene Arten ausfallen. Sein Ausgangssignal kann nach oben oder unten driften, auf einem Wert einfrieren, instabil werden oder vollständig ausfallen. Jeder Ausfallmodus hat eine andere betriebliche 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, statt lediglich „Ausfall des Messumformers“ 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 Konsequenz verringern. Eine unzureichende Erkennung wird oft ebenso wichtig wie die ursprüngliche Ausfallart.

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

Was ein effektives FMEA-Arbeitsblatt enthalten sollte

Ein nützliches FMEA-Arbeitsblatt beginnt mit dem Element und seiner erforderlichen Funktion. Die Ausfallart 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 umfassendere betriebliche oder sicherheitstechnische Konsequenz beschreibt. Ursachen und Mechanismen werden getrennt von den Auswirkungen erfasst.

Das Arbeitsblatt dokumentiert außerdem bestehende Schutzmaßnahmen. Vorbeugende Maßnahmen verringern die Wahrscheinlichkeit des Auftretens eines Ausfalls. Entdeckungsmaßnahmen erkennen den Ausfall, bevor er eine unzulässige Konsequenz verursacht. Beispiele sind Selbstdiagnosen, 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 aber niemals das technische Urteil ersetzen. Unterschiedliche Kombinationen können dieselbe Punktzahl ergeben, obwohl ihre Konsequenzen grundlegend verschieden sind.

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 Konsequenz verringern, statt sich ausschließlich auf zusätzliche Prüfungen zu verlassen.

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

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

Mögliche Ausfallarten sind ein offener Stromkreis, ein Kurzschluss, ein verschweißter Kontakt, ein dauerhaft auf High liegender Kanal, ein dauerhaft auf Low liegender Kanal oder der Verlust der gemeinsamen Eingangsspannungsversorgung. Die Analyse untersucht außerdem, ob eine Abweichung zwischen den Kanälen erkannt wird. Wenn beide Kanäle einen Feldkontakt und ein Kabel gemeinsam nutzen, betreffen viele plausible Ausfälle beide Kanäle gleichzeitig.

Die Überprüfung kann zeigen, dass duplizierte Eingangsmodule nur einen begrenzten zusätzlichen Schutz bieten. Separate Kontakte, überwachte Feldstromkreise, unabhängige Stromversorgungspfade oder diversitäre 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 auch 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 wie vorgesehen arbeiten können. Die Methode wird üblicherweise während der Konzeptentwicklung, der Detailauslegung und bei Konstruktionsänderungen angewendet. Besonders wertvoll ist sie, bevor sich die Auslegung nur noch mit hohem Aufwand ändern lässt.

Die Prozess-FMEA untersucht Fertigungs-, Montage-, Installations-, Inbetriebnahme- oder Wartungsaktivitäten. Ein Schaltschrank kann über eine korrekte elektrische Auslegung verfügen, doch der Installationsprozess kann weiterhin lose Klemmen, eine vertauschte Polarität, falsche Sicherungsnennwerte oder eine fehlerhafte Leiterkennzeichnung verursachen. Wartungsarbeiten können fehlerhafte Firmware, ungeeignete Ersatzteile, deaktivierte Alarme oder weiterhin aktive Überbrückungen verursachen.

Diese beiden FMEA-Formen sollten sich gegenseitig ergänzen. Konstruktive Maßnahmen können die Empfindlichkeit gegenüber der Installation verringern, während Prozessmaßnahmen Ausführungsfehler verhindern können, die sich durch die Konstruktion nicht ausschließen lassen. Eine ausschließliche Überprüfung der Anlagenauslegung lässt viele Risiken über den gesamten Lebenszyklus unberücksichtigt. Eine ausschließliche Überprü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 um sie herum weiterentwickelt.

FMECA ermöglicht eine formalere Kritikalitätsbewertung

Die Fehler-, Einfluss- und Kritikalitätsanalyse erweitert die FMEA-Struktur um formale Kritikalitätsberechnungen. Die Methode kann Komponentenausfallraten, Betriebsbeanspruchung, Missionsphasen, Schweregradkategorien und bedingte Wahrscheinlichkeiten verwenden. Sie ist nützlich, wenn ein großes System zahlreiche Fehlermöglichkeiten aufweist und die technischen Ressourcen auf die wichtigsten Verursacher konzentriert werden müssen.

Kritikalitätsberechnungen hängen stark von der Datenqualität ab. Allgemeine Datenbanken zu Ausfallraten bieten einen Ausgangspunkt, spiegeln die reale Installation jedoch möglicherweise nicht wider. Temperatur, Vibration, Verunreinigungen, elektrische Belastung, Wartungsqualität und Einschaltdauer beeinflussen die tatsächliche Leistung. Wenn ausreichende Betriebserfahrungen vorliegen, sollten anlagenspezifische Nachweise allgemeine Annahmen ersetzen.

Die Analyse sollte außerdem zwischen sofort erkannten Ausfällen und Ausfällen unterscheiden, die verborgen bleiben. Ein ruhender Ausfall in einem Bereitschaftssystem kann die Produktion erst dann beeinträchtigen, wenn eine andere Komponente ausfällt oder eine Anforderung eintritt. Die lange unbemerkte Exposition kann einen relativ seltenen Ausfall äußerst wichtig machen. Erkennungsintervalle und die Wirksamkeit von Nachweisprüfungen müssen daher einbezogen werden.

Die FMECA ist am nützlichsten, wenn ihre Ergebnisse zu Maßnahmen in der Konstruktion oder Instandhaltung führen. Eine komplexe Ranglistentabelle hat wenig Wert, wenn sie keinen Einfluss auf Architektur, Ersatzteile, Diagnostik, Prüfungen oder Betriebsverfahren nimmt. 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 bietet eine strukturierte komponentenweise Überprü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, Diagnostik 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 damit, Ausfallarten mit geringem Nutzen zu dokumentieren, während sie Systemwechselwirkungen übersehen. Die traditionelle FMEA untersucht zudem meist jeweils nur einen Ausfall. Mehrere gleichzeitige Ausfälle und sequenzabhängige Ereignisse werden möglicherweise nicht eindeutig erfasst.

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

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

Die Monte-Carlo-Simulation macht aus Unsicherheit 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 Umgebungsbelastungen beeinflussen das Ausfallverhalten. Ein einzelner Durchschnittswert kann diese Schwankungen nicht immer abbilden. Die Monte-Carlo-Simulation begegnet diesem Problem durch wiederholte Zufallsstichproben.

Der Ingenieur erstellt zunächst ein Systemmodell und weist den unsicheren Variablen Wahrscheinlichkeitsverteilungen zu. Anschließend erzeugt die Simulation viele mögliche Kombinationen. Bei einem Durchlauf kann angenommen werden, dass eine Pumpe nach 8.000 Betriebsstunden ausfällt und innerhalb von vier Stunden repariert wird. Ein anderer Durchlauf kann einen späteren Ausfall, aber eine deutlich längere Reparatur ergeben, weil das benötigte Ersatzteil nicht verfügbar ist.

Nach Tausenden oder Millionen von Durchläufen bilden die Ergebnisse eine Verteilung. Das Modell kann die erwartete Ausfallzeit, den Produktionsverlust, die Systemverfügbarkeit, die Wahrscheinlichkeit eines erfolgreichen Missionsabschlusses, den Bedarf an Ersatzteilen oder die Instandhaltungskosten schätzen. Es kann auch die Wahrscheinlichkeit extremer Ergebnisse aufzeigen, die in einem einzigen Durchschnittswert verborgen blieben.

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

Erstellung eines glaubwürdigen 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, Produktionsnachfrage, logistische Verzögerungen und menschliche Reaktionen berücksichtigen, wenn diese Faktoren die Systemleistung beeinflussen.

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

Die 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 akzeptiert werden, nur weil sie aus einer Software stammen. Eine visuell beeindruckende Simulation kann dennoch falsch sein, wenn die zugrunde liegende Logik unvollständig ist.

Die Sensitivitätsanalyse hilft dabei, die Annahmen zu identifizieren, die das Ergebnis bestimmen. Wenn die Reparaturzeit einen wesentlich größeren Einfluss als die Ausfallrate hat, kann das Management möglicherweise größeren Nutzen daraus ziehen, die Verfügbarkeit von Ersatzteilen und die Diagnosegeschwindigkeit zu verbessern. Wenn die Wahrscheinlichkeit eines gemeinsamen Ursprungs dominiert, bringt das Hinzufügen weiterer identischer Komponenten möglicherweise nur einen geringen Nutzen.

Auswahl von Wahrscheinlichkeitsverteilungen, die zum Ausfallmechanismus passen

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

Die Auswahl sollte den physikalischen Mechanismus und nicht die Bequemlichkeit der Software widerspiegeln. Ein verschleißbedingter Lagerausfall folgt nicht automatisch 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 Ausfallmechanismen untersuchen, bevor sie die Verteilung auswählen.

Historische Daten müssen häufig bereinigt werden. Instandhaltungssysteme können einen geplanten Austausch mit einem Funktionsausfall verwechseln. Als Ausfalldatum wird möglicherweise das Datum der Eröffnung des Arbeitsauftrags eingetragen und nicht das tatsächliche Auftreten des Fehlers. Anlagennamen, Betriebsstunden und Fehlercodes können außerdem standortübergreifend uneinheitlich sein.

Begrenzte Daten verhindern keine Analyse, aber die Unsicherheit sollte sichtbar bleiben. Experteneinschätzungen, Lieferanteninformationen und Branchendatenbanken können frühe Schätzungen unterstützen. Das Modell sollte eine realistische Bandbreite prüfen, 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 als Reservekapazität dient. Jede Maschine weist unterschiedliche Betriebsstunden, eine eigene Instandhaltungshistorie und eine andere Kühlleistung auf. Da die Station nur über ein spezialisiertes Instandhaltungsteam verfügt, kann jeweils nur eine größere Reparatur 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 einzigen 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 die Verfügbarkeit bei voller Kapazität, einen Betrieb mit reduzierter Kapazität und den vollständigen Ausfall der Station ausweisen. Das Management kann alternative Investitionen vergleichen. Die Bevorratung zusätzlicher Lager kann extreme Stillstandszeiten möglicherweise wirksamer reduzieren als die Einstellung eines weiteren allgemeinen Instandhaltungstechnikers. Eine höhere Zuverlässigkeit der Kühlung kann größeren Nutzen bringen als der Austausch eines ansonsten intakten Kompressors.

Mit dem Modell lassen sich auch Instandhaltungsintervalle prüfen. Kürzere präventive Intervalle können Ausfälle reduzieren, aber zugleich die geplante Stillstandszeit und durch die Instandhaltung verursachte Fehler erhöhen. Die Simulation ermöglicht es, beide Effekte innerhalb desselben Betriebsmodells zu bewerten.

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

Monte-Carlo-Methoden sind besonders leistungsfähig, wenn viele unsichere Variablen miteinander interagieren. Sie können komplexe Logistikabläufe, Warteschlangen bei Reparaturen, Wettereffekte, 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 seltener Ereignisse aufzeigt.

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

Eine Simulation erfordert außerdem genügend Durchläufe, um stabile Schätzwerte zu erzielen. Wahrscheinlichkeiten seltener Ereignisse können spezielle Stichprobenverfahren erfordern, da eine gewöhnliche Zufallssimulation eine praktisch unrealistisch große Anzahl von Durchläufen benötigen würde. Es sollten Konfidenzintervalle angegeben werden, damit die Nutzer die statistische Unsicherheit verstehen.

Die Methode ist daher besonders wertvoll, wenn die Modelllogik, Datenquellen und Einschränkungen transparent bleiben. Zuverlässigkeitsentscheidungen sollten nicht auf einer Grafik beruhen, deren Annahmen dem Betriebs- und Ingenieurpersonal 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 aufgetreten ist. Sie geht über die Identifizierung der beschädigten Komponente hinaus. Ein Motor kann ausfallen, weil ein Lager festgefressen ist, doch der Austausch des Lagers stellt lediglich den Betrieb wieder her. Die Untersuchung muss ermitteln, warum das Lager diesen Zustand erreicht hat.

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

RCA trennt daher Symptome, direkte physikalische Ursachen, beitragende Bedingungen und zugrunde liegende Schwachstellen des Systems. Diese Unterscheidung verhindert, dass die Organisation jede Reparatur als dauerhafte Lösung betrachtet. Außerdem liefert sie Erkenntnisse, mit denen sich künftige FMEA, FTA, die Instandhaltungsplanung und Betriebsverfahren verbessern lassen.

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 können Module austauschen und Prozessbedingungen können sich ändern. Steuerungsprotokolle können frühere Ereignisse überschreiben, während beschädigte Komponenten vor ihrer Untersuchung entsorgt werden können. Ein disziplinierter RCA-Prozess beginnt daher mit der Sicherung von Beweismitteln.

Das Team sollte Historian-Trends, Alarmlisten, Ereignisprotokolle der Steuerungen, Relaisaufzeichnungen, Arbeitsaufträge, Fotos, beschädigte Teile, Softwareversionen, Konfigurationsdateien und Beobachtungen des Bedienpersonals zusammentragen. Jede Information sollte nach Quelle und Zeitpunkt gekennzeichnet werden. Physische Beweismittel sollten unter kontrollierten Bedingungen aufbewahrt werden, bis die Untersuchung ergibt, ob eine weitere Prüfung erforderlich ist.

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

Befragungen der Bediener sollten zeitnah, aber sorgfältig durchgeführt werden. Personen erinnern sich möglicherweise an Abläufe und Zusammenhänge, die von automatisierten Systemen nicht erfasst wurden. Ihre Aussagen sollten als Beweismittel und nicht als Schuldzuweisung behandelt werden. Ziel ist es, die Betriebsumgebung zu verstehen, in der die Entscheidungen getroffen wurden.

Erstellen der Ereigniszeitleiste vor der Ursachensuche

Eine belastbare Zeitleiste trennt verifizierte Fakten von Interpretationen. Sie dokumentiert, was vor, während und nach dem Ausfall geschehen 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. Daten mit hoher zeitlicher Auflösung aus der Ereignisfolgenaufzeichnung können zeigen, dass Druckschwankungen, eine Stromstörung oder ein Kommunikationsverlust früher begonnen haben. Die Zeitleiste hilft dabei, Ursache und Folge zu unterscheiden.

Sobald die Abfolge verstanden ist, kann das Team Werkzeuge wie die 5-Warum-Methode, Fischgrätendiagramme, Barrierenanalyse, Änderungsanalyse oder Kausalfaktorendiagramme 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 einem Werk kommt es wiederholt zu Ausfällen eines Frequenzumrichters, der ein Förderband steuert. Nach jedem Ereignis ersetzt die Instandhaltung den Antrieb, und die Produktion wird wieder aufgenommen. 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. Die Temperaturverläufe des Schaltschranks zeigen einen längeren Betrieb oberhalb des bevorzugten Bereichs. Die Inspektion ergibt verstopfte Filter, einen eingeschränkten Luftstrom und starke Staubansammlungen im Bereich des Kühlwegs.

Aus der Wartungshistorie geht hervor, dass die regelmäßige Filterreinigung nach einer Änderung des Personalbestands aus dem vorbeugenden Wartungsplan gestrichen wurde. Der Antrieb ist das ausgefallene Bauteil, aber die überhöhte Schaltschranktemperatur ist die unmittelbare physikalische Ursache. Eingeschränkte Belüftung und die fehlende Wartungsaufgabe sind beitragende organisatorische Ursachen.

Die Korrekturmaßnahme sollte daher über einen weiteren Austausch des Antriebs hinausgehen. Das Werk kann die Filterwartung wieder aufnehmen, 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 RCA-Berichte werden bei der Planung von Korrekturmaßnahmen schwach. Teams empfehlen möglicherweise zusätzliche Schulungen, ohne nachzuweisen, dass unzureichende Kenntnisse das Problem waren. Sie überarbeiten möglicherweise Verfahren, obwohl das eigentliche Problem in einer mangelhaften Anlagenauslegung liegt. Sie fügen möglicherweise Inspektionen hinzu, die den tatsächlichen Ausfallmechanismus nicht erkennen können.

Jede Maßnahme sollte eine verifizierte Ursache oder einen beitragenden Umstand 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. Der Betrieb 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 der Zuverlässigkeitsverbesserung.

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

Menschliches Versagen ist selten eine vollständige Grundursache

„Bedienfehler“ und „Instandhaltungsfehler“ 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 Elemente auf dem Bildschirm nahezu identisch aussehen. Ein Techniker kann das falsche Teil einbauen, weil die Kennzeichnung uneinheitlich ist. Ein Vorgesetzter kann die Instandhaltung aufschieben, weil die Organisation eine unterbrechungsfreie Produktion belohnt, aber kein realistisches Zeitfenster für einen Stillstand bereitstellt.

Das Verständnis dieser Bedingungen hebt die individuelle Verantwortung nicht auf. Es verhindert, dass dasselbe System eine andere Person zum selben Fehler führt. Eine auf Schuldzuweisung ausgerichtete Untersuchung mag dem unmittelbaren Bedürfnis nach Verantwortlichkeit genügen, lässt die grundlegende Schwäche jedoch unangetastet.

Eine wirksame RCA 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 Menschen einfach nur anzuweisen, vorsichtiger zu sein.

Wo die Ursachenanalyse gut funktioniert – und wo nicht

RCA verwandelt praktische Betriebserfahrungen in präventives Wissen. Sie kann Konstruktionsschwächen, Instandhaltungslücken, Verfahrensprobleme und organisatorischen Druck 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 weitreichenden Folgen können sich nicht ausschließlich darauf verlassen, aus Fehlern zu lernen. Proaktive Methoden wie FMEA und FTA sind weiterhin notwendig. RCA sollte sie ergänzen, indem Annahmen anhand von Erkenntnissen aus dem tatsächlichen Betrieb aktualisiert werden.

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, dass Schlussfolgerungen unsicher bleiben. Gute Berichte trennen klar zwischen bestätigten Ursachen, beitragenden Faktoren, Hypothesen und offenen Fragen.

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

Markov-Modelle verfolgen das System durch sich verändernde Zustände

Die Markov-Modellierung stellt ein System anhand definierter Betriebszustände dar. Ein einfaches System kann nur einen Betriebszustand und einen Ausfallzustand enthalten. Ein fehlertolerantes System benötigt in der Regel 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ändigen Betrieb in einen degradierten Zustand versetzen. Ein weiterer Ausfall kann es vom degradierten Zustand in den Zustand der Nichtverfügbarkeit versetzen. Eine Reparaturrate kann es in den vollständigen Betrieb zurückführen. Das Modell berechnet die Wahrscheinlichkeit, mit der sich das System im Laufe der Zeit in jedem einzelnen Zustand befindet.

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

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

Ein Zwei-Zustände-Modell vermittelt das Grundprinzip

Das einfachste Markov-Modell enthält einen Betriebszustand und einen Ausfallzustand. Die Ausfallrate steuert den Übergang vom Betrieb in den Ausfall. Die Reparaturrate steuert den Übergang zurück in den Betrieb. Anhand dieser Übergänge kann das Modell die Verfügbarkeit während eines festgelegten Zeitraums 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 nach dem Ausfall eines Kanals weiterarbeiten. Das System bleibt funktionsfähig, verliert jedoch seine Redundanz. Es befindet sich nun in einem degradierten Zustand und ist einem weiteren Ausfall stärker ausgesetzt.

Das Hinzufügen des degradierten Zustands ermöglicht es dem Modell zu berechnen, wie häufig und wie lange das System ohne vollständigen Schutz betrieben wird. Die Reparaturgeschwindigkeit wird äußerst wichtig. Ein System mit zuverlässigen Komponenten kann dennoch übermäßig viel Zeit im degradierten Zustand verbringen, wenn die Fehlerdiagnose, die Lieferung von Ersatzteilen oder die Genehmigung von Wartungsarbeiten zu langsam erfolgt.

Das Modell kann außerdem zwischen erkannten und nicht erkannten 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 auch 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 bedeutet, dass beide Controller funktionsfähig sind. Zustand zwei bedeutet, dass ein Controller ausgefallen ist, während der zweite die Steuerung aufrechterhält. Zustand drei bedeutet den Ausfall beider Controller und die vollständige Nichtverfügbarkeit der Steuerung.

Das Modell umfasst die Ausfallrate jedes Controllers sowie die Reparaturrate nach der Erkennung. Es kann außerdem einen 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 möglicherweise fast das ganze Jahr über den Prozess steuern, während es eine beträchtliche Anzahl von Stunden mit nur einem funktionsfähigen Controller verbringt. Diese Belastung durch den eingeschränkten Zustand kann für eine kritische Anwendung unzulässig sein.

Das Modell kann Verbesserungsstrategien vergleichen. Ein schnellerer Austausch von Ersatzgeräten kann die Belastung durch den eingeschränkten Zustand wirksamer reduzieren als das Hinzufügen eines dritten Controllers. Eine bessere Diagnose kann größeren Nutzen bringen als eine geringfügige Verringerung der Hardware-Ausfallrate. Die Markov-Analyse macht diese Zielkonflikte messbar.

Standby-Geräte benötigen mehr als einen Zustand für aktive Ausfälle

Standby-Redundanz führt zu zusätzlichem Verhalten. Eine Standby-Pumpe kann stillstehen, bis die Betriebspumpe ausfällt. Die Standby-Einheit kann einen verborgenen Fehler aufweisen, beim Start ausfallen oder auf ein Problem in der Umschaltlogik stoßen. Auch Absperrventile können den erforderlichen Stellungswechsel nicht ausführen.

Ein Markov-Modell kann Zustände für aktive Geräte im fehlerfreien Zustand, nicht verfügbare Standby-Geräte, Umschaltfehler, reduzierte Kapazität und den vollständigen Systemausfall enthalten. Durch eine Funktionsprüfung wird das System von einem unbekannten Ruhezustand in Richtung eines bekannten Zustands bewegt. Das Intervall zwischen den Prüfungen beeinflusst, wie lange verborgene Ausfälle möglich bleiben.

Wartungsrichtlinien können innerhalb derselben Struktur bewertet werden. Kürzere Prüfintervalle 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 Prüfungen immer besser sind.

Die Standby-Analyse sollte auch die Reparaturlogistik berücksichtigen. Der Ausfall einer Standby-Komponente unterbricht die Produktion möglicherweise nicht sofort, sodass die Reparatur verzögert werden kann. Durch diese Verzögerung bleibt das System ungeschützt, wenn die aktive Einheit später ausfällt. Operative Prioritäten beeinflussen daher die Zuverlässigkeit ebenso stark wie die Hardwareeigenschaften.

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

Ein einfaches Markov-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 entsprechen dieser Näherung während eines begrenzten Zeitraums recht gut.

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 annähern, während für eine genauere Darstellung möglicherweise semi-Markovsche oder andere Modelle erforderlich sind.

Die Zustandsraumexplosion ist eine weitere Herausforderung. Jeder Zustand einer Komponente kann die Anzahl der möglichen Systemzustände vervielfachen. Eine komplexe redundante Anlage kann schnell Tausende oder Millionen von Kombinationen hervorbringen. Möglicherweise sind Modellreduktion, Gruppierung oder Simulation erforderlich, damit die Analyse handhabbar bleibt.

Das Modell sollte ausreichend detailliert sein, um die Entscheidung zu unterstützen, ohne jede physische Veränderung abzubilden. Übermäßige Komplexität führt zu Problemen bei Wartung und Validierung. Ein zu einfaches Modell verbirgt wichtiges Verhalten, während ein zu detailliertes Modell nicht mehr erklärbar ist.

Wo die Markov-Modellierung gut funktioniert – und wo nicht

Die Markov-Modellierung eignet sich gut für reparierbare redundante Systeme, Bereitschaftsausrüstung, degradierte Betriebsarten und Diagnoseabdeckung. Sie unterstützt die Verfügbarkeitsanalyse und zeigt, wie die Reaktion auf Wartungsmaßnahmen die Systemexposition verändert. Sie ist besonders nützlich, wenn die Abfolge von Ausfall- und Reparaturzuständen von Bedeutung ist.

Die Methode hängt von korrekten Zustandsdefinitionen und Übergangsraten ab. Annahmen konstanter Raten spiegeln Alterung, Umgebungsbedingungen oder die Qualität der Wartung möglicherweise nicht wider. Ausfälle gemeinsamer Ursache müssen ausdrücklich dargestellt werden, anstatt sie in unabhängigen Komponentenausfallraten 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 Ausfällen gemeinsamer Ursache variieren. Ein Design, das nur unter einer einzigen optimistischen Annahme akzeptabel erscheint, ist nicht robust.

Markov-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

Die fünf Methoden bieten den größten Nutzen, wenn sie miteinander verknüpft sind. FMEA kann während der Entwicklung detaillierte Ausfallarten von Komponenten identifizieren. Anschließend kann die FTA ermitteln, welche Kombinationen zu einem kritischen Systemereignis beitragen. Die 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, die Lieferung von Ersatzteilen, Wetterbedingungen und die Arbeitsbelastung der Instandhaltung prüfen. Eine RCA liefert nach realen Ausfällen Belege und kann Annahmen aufdecken, die in den ursprünglichen Modellen übersehen wurden. Die Modelle sollten anschließend aktualisiert und nicht als historische Dokumente unverändert beibehalten werden.

Angenommen, eine FTA behandelt zwei Ausfälle von Steuergeräten als unabhängig. Eine RCA zeigt später, dass beide Steuergeräte 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 lebendiges Zuverlässigkeitsprogramm. Prädiktive Analysen steuern die Entwicklung, Betriebserkenntnisse prüfen die Annahmen, und Untersuchungsergebnisse verbessern die nächste Generation von Modellen. Zuverlässigkeitsarbeit wird so zu einem Bestandteil des Systemlebenszyklus statt zu einer einmaligen Projektanforderung.

Gemeinsam verursachte Fehler können eine gesamte redundante Architektur außer Kraft setzen

Gemeinsam verursachte Fehler wirken sich über eine gemeinsame zugrunde liegende Bedingung auf mehrere Kanäle aus. Gemeinsame Stromversorgung, Kühlung, Netzwerkinfrastruktur, Software, Umwelteinflüsse und Instandhaltungspraktiken sind häufige Beispiele. Diese Fehler sind besonders gefährlich, weil sie eine Redundanz außer Kraft setzen können, die auf dem Papier robust erscheint.

Räumliche Trennung verringert einige gemeinsame Ursachen. Unterschiedliche Geräte oder Software können andere Ursachen reduzieren. Eine unabhängige Verifizierung kann Fehler bei Instandhaltung und Konfiguration verringern. Diversität erhöht jedoch auch den Aufwand für Schulungen, Ersatzteile, Prüfungen und die Integrationskomplexität.

Die richtige Lösung hängt vom Risiko ab. Der Einsatz unterschiedlicher Steuerungstechnologien kann das Risiko gemeinsamer Softwarefehler verringern, aber neue Herausforderungen bei Kommunikation und Instandhaltung schaffen. Separate Netzteile bieten möglicherweise nur einen geringen Nutzen, wenn sich beide im selben überschwemmungsgefährdeten Schaltschrank befinden. Zuverlässigkeitsmethoden helfen dabei, die Diversitätsmaßnahmen zu ermitteln, die auf plausible Fehlerszenarien abzielen.

Annahmen zu gemeinsam verursachten Fehlern sollten in jedem quantitativen Modell sichtbar sein. Die Behandlung redundanter Kanäle als vollständig unabhängig führt fast immer zu einem zu optimistischen Ergebnis. Betriebserfahrungen und Ergebnisse der Ursachenanalyse liefern wertvolle Hinweise zur Schätzung dieser Abhängigkeiten.

Die Diagnoseabdeckung bestimmt, wie lange das System gefährdet bleibt

Ein redundantes System kann nicht effektiv verwaltet werden, wenn Fehler 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 in einem beeinträchtigten Zustand bleibt. Außerdem ermöglicht sie es der Instandhaltung, die Redundanz wiederherzustellen, bevor ein weiterer Fehler auftritt.

Diagnostische Aussagen müssen sorgfältig geprüft werden. Ein Steuergerät kann interne Prozessorfehler erkennen, aber nicht jeden Fehler in der Feldverdrahtung. Ein Kommunikationsmodul kann den vollständigen Verlust der Verbindung erkennen, aber eine fehlerhafte Datenzuordnung möglicherweise nicht. Ein Netzteil kann nach einem vollständigen Ausfall der Ausgangsleistung einen Alarm auslösen, aber keine allmähliche Verschlechterung ankündigen.

Nachweisprüfungen decken Fehler ab, die von der kontinuierlichen Diagnose nicht erkannt werden. Das Prüfintervall beeinflusst die Exposition. Längere Intervalle ermöglichen es, dass unerkannte Ausfälle länger bestehen bleiben, während sehr kurze Intervalle den Wartungsaufwand und das durch Prüfungen verursachte Risiko erhöhen. FMEA, Markow-Analysen und Betriebserfahrungen können ein ausgewogenes Intervall unterstützen.

Die Prüfung muss die vollständige Funktion abdecken. Die Aktivierung eines SPS-Eingangs beweist nicht, dass der Feldschalter, die Verdrahtung, die Logik, der Ausgang und das abschließende Stellglied ordnungsgemäß funktionieren. Die Zuverlässigkeitsanalyse sollte genau festlegen, welche Fehler durch die jeweilige Diagnose oder den jeweiligen Nachweis test 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 verringern. In fehlertoleranten Systemen kann die Reparaturzeit ebenso wichtig sein. Nach dem Ausfall des ersten Kanals kann das System weiterarbeiten, bleibt jedoch anfällig. Lange Reparaturverzögerungen erhöhen die Wahrscheinlichkeit, dass ein zweiter Ausfall zum vollständigen Verlust führt.

Diagnose, Genehmigungen, Verfügbarkeit von Technikern, Ersatzteile, Zutrittsgenehmigungen und Produktionsbedingungen beeinflussen allesamt die Wiederherstellungszeit. Ein Bauteil kann in fünfzehn Minuten ausgetauscht werden, nachdem das passende Ersatzteil den Schaltschrank erreicht hat. Die tatsächliche Stillstandszeit kann sich dennoch über Tage erstrecken, wenn das Ersatzteil international beschafft werden muss.

Verbesserte Diagnosefunktionen 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. Markow- und Monte-Carlo-Modelle können den Nutzen dieser Verbesserungen quantifizieren.

Die beste Investition in die Zuverlässigkeit besteht nicht immer in leistungsfähigerer Hardware. In manchen Systemen bringt eine Verkürzung der Reparaturzeit eine größere Risikominderung 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 Leitsystems hängt von mehr als nur dem Zentralprozessor ab. Ingenieure sollten Controller, I/O-Module, Kommunikationsnetzwerke, Stromversorgungen, Server, Bedienerstationen, Zeitsynchronisation, Feldschnittstellen und unterstützende Versorgungseinrichtungen überprüfen. Jedes gemeinsam genutzte Element kann zu einer gemeinsamen Abhängigkeit werden.

Redundante Controller können sich ein I/O-Rack teilen. Redundante Server können von einem Netzwerk-Switch oder einem Speichersystem abhängen. Netzwerke für dezentrale I/Os können separate Kommunikationskanäle verwenden, die durch dieselbe physische Trasse verlaufen. Eine vollständige Analyse muss die Funktion vom Feldgerät bis zur abschließenden Stellaktion verfolgen.

Das erforderliche Verhalten nach einem Ausfall muss klar definiert werden. Der Prozess kann unter dem verbleibenden Controller weiterlaufen, in den manuellen Betrieb wechseln oder eine kontrollierte Abschaltung einleiten. Das Wartungspersonal muss wissen, wie der ausgefallene Kanal identifiziert und das System wiederhergestellt werden kann, ohne den intakten Kanal zu beeinträchtigen.

Organisationen, die Steuerungs-Upgrades 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 Produktmerkmalen orientieren.

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

Die quantitative Zuverlässigkeitsanalyse ist nur so aussagekräftig wie die zugrunde liegenden Daten. Instandhaltungsaufzeichnungen sollten zwischen Funktionsausfall, geplantem Austausch, Inspektion und Änderung unterscheiden. Das Ausfalldatum sollte den Zeitpunkt angeben, zu dem die Funktion verloren ging, während das Wiederherstellungsdatum den Zeitpunkt angeben sollte, zu dem der Betrieb tatsächlich wieder verfügbar war.

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

Auch die Betriebsbeanspruchung muss berücksichtigt werden. Eine kontinuierlich laufende Pumpe kann nicht direkt mit einer Standby-Pumpe verglichen werden, die nur während Tests läuft. Temperatur, Luftfeuchtigkeit, Verunreinigungen, Vibrationen, elektrische Beanspruchung und Prozesslast können Unterschiede zwischen ansonsten identischen Komponenten erklären.

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

Ein praxisnaher Workflow zur Verbesserung der Zuverlässigkeit

Ein Zuverlässigkeitsprojekt sollte mit der Definition der erforderlichen Funktion und Systemgrenze beginnen. Das Team muss festlegen, welche Leistung im Normalbetrieb und nach jedem plausiblen Fehler erforderlich ist. Es sollte Zeichnungen, Handbücher, Instandhaltungshistorien, Betriebsanweisungen, Alarmaufzeichnungen und frühere Vorfallberichte zusammentragen.

Die FMEA kann anschließend Ausfallarten auf Komponentenebene und schwache 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, Instandhaltung und Logistik abbilden kann.

Historische Vorfälle sollten mittels RCA untersucht werden. Die Erkenntnisse sollten zur Aktualisierung der Konstruktionsanalysen und quantitativen Annahmen verwendet werden. Maßnahmen sollten nach Auswirkung, Wahrscheinlichkeit, Erkennbarkeit, Exposition, Reparaturdauer und Kosten priorisiert werden.

Jede Maßnahme benötigt einen Verantwortlichen, ein Abschlussdatum und eine Wirksamkeitsprüfung. Die Analysen sollten nach wesentlichen Änderungen an der Ausrüstung, Software-Upgrades, Prozessänderungen oder Änderungen der Instandhaltungsstrategie aktualisiert werden. Zuverlässigkeit ist eine fortlaufende technische Disziplin und kein Bericht, der einmal erstellt und abgelegt wird.

Die Fragen, die schwache Aussagen zur Fehlertoleranz aufdecken

Eine gründliche Überprüfung klärt, 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 untersucht, wie unerkannte Fehler erkannt werden und wie lange das System vor einer Reparatur im beeinträchtigten Zustand verbleiben darf.

Das Team sollte Komponenten mit langen Wiederbeschaffungszeiten identifizieren und feststellen, ob ein einziger Wartungsfehler mehrere Kanäle beeinträchtigen kann. Software- und Konfigurationsabhängigkeiten sollten genauso berücksichtigt werden wie die 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 möglichst durch Anlagendaten belegt werden. Korrekturmaßnahmen sollten nach ihrer Umsetzung verifiziert werden. Wiederkehrende Prüfungen sollten die vollständige Schutzfunktion und nicht nur die Reaktion einzelner Geräte nachweisen.

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 Wartungsmöglichkeiten.

Abschließende Betrachtung

Fehlertoleranz ist unerlässlich, wenn Ausfallzeiten, unsicheres Verhalten oder ein Kontrollverlust nicht akzeptiert werden können. Redundanz allein macht ein System jedoch nicht zuverlässig. Ingenieure müssen Fehlermodi, gemeinsame Abhängigkeiten, Diagnoseabdeckung, den eingeschränkten Betrieb, das Reparaturverhalten und die betrieblichen Folgen verstehen.

Die Fehlerbaumanalyse zeigt, wie Kombinationen von Ausfällen ein kritisches Ereignis verursachen können. Die FMEA bietet eine systematische Untersuchung einzelner Fehlermodi und ihrer Auswirkungen. Die Monte-Carlo-Simulation bewertet unsichere Szenarien, während die Ursachenanalyse reale Ausfälle in präventives 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 bilden sie einen starken Rahmen für die Zuverlässigkeit. Designstudien sollten anhand von Betriebserfahrungen aktualisiert werden, und Erkenntnisse aus Vorfällen sollten zukünftige Modelle verbessern. Die Ergebnisse müssen Architektur, Wartung, Ersatzteile, Prüfungen, Schulungen und Verfahren beeinflussen.

Das Ziel besteht nicht darin, ein System zu schaffen, in dem niemals ein Fehler auftritt. Das Ziel ist, Fehler frühzeitig zu erkennen, ihre Folgen einzudämmen, die erforderliche Funktion zu erhalten und die vollständige Leistungsfähigkeit vorhersehbar wiederherzustellen. Das ist die praktische Bedeutung industrieller Fehlertoleranz.