FMEA-MSR

FMEA-MSR

Kurz erklärt

Die FMEA-MSR (Monitoring und System Response) ist eine erweiterte Analysemethode innerhalb des AIAG/VDA-FMEA-Frameworks, die speziell darauf abzielt, die Wirksamkeit von On-Board-Diagnosesystemen und automatisierten Sicherheitsreaktionen im aktiven Feldeinsatz zu bewerten. Während die klassische Design-FMEA (DFMEA) den Fokus auf die strukturelle Vermeidung von Fehlern legt, fokussiert die MSR-Variante auf die Beherrschbarkeit unvorhersehbarer Ereignisse. Sie prüft, ob die Diagnose-Software Fehler detektiert und ob die nachgeschaltete Systemreaktion das Risiko innerhalb der sicherheitskritischen Zeitintervalle wirksam minimiert.

Definition

Die FMEA-MSR ist eine proaktive Methode zur Validierung mechatronischer Sicherheitssysteme. Sie analysiert die Prozesskette: Detektion (Monitoring), Bewertung (Logik) und Korrektur (Systemreaktion). Der zentrale Fokus liegt auf der 'Fehlererkennung bei Betrieb', wobei 'Fehler' hier sowohl Hardware-Defekte als auch softwareseitige Ausfälle oder Umgebungs-Abweichungen umfasst. Methodisch ergänzt sie die ISO 26262, indem sie spezifische Diagnose-Fehlermöglichkeiten in den Fokus rückt, die bei der statischen Hardware-Auslegung oft übersehen werden.

Bedeutung im Fachkontext

In modernen, hochgradig automatisierten Fahrzeugen reicht die rein passive Robustheit (Hardware-Stabilität) nicht mehr aus. Software-Algorithmen übernehmen zunehmend die Sicherheitsverantwortung. Die FMEA-MSR schliesst hier die Lücke, indem sie die Zuverlässigkeit dieser 'intelligente' Sicherheitsbarrieren absichert. Sie ist ein unverzichtbares Instrument für Entwickler von Steuergeräten, Batteriemanagementsystemen und Fahrerassistenzfunktionen, da sie die Anforderungen an die funktionale Sicherheit (Safety) durch strukturierte Analyse der Diagnoseleistung direkt unterstützt.

Input, Verarbeitung, Output, Outcome, Impact

Schritte der Methode in Übersicht

Die FMEA-MSR folgt der harmonisierten Sieben-Schritte-Struktur: 1. Planung und Vorbereitung; 2. Strukturanalyse; 3. Funktionsanalyse; 4. Fehleranalyse; 5. Risikoanalyse; 6. Optimierung; 7. Risikokommunikation.

Beschreibung der Einzelschritte mit Ziel & Vorgehen

Anwendung und Vorgehen

Die Anwendung der FMEA-MSR folgt einer strengen methodischen Logik, die über die statische Betrachtung der DFMEA hinausgeht. Das praktische Vorgehen beginnt dort, wo ein System bereits funktional entworfen wurde, aber die "Intelligenz" der Fehlerbeherrschung validiert werden muss.

Konkrete Umsetzung im Engineering-Prozess:

1. Schnittstellenanalyse: Zunächst werden die Signale identifiziert, die in die Diagnose-Logik einfließen. Hier wird penibel dokumentiert, ob die Sensorwerte (z.B. Temperatur- oder Strommessdaten) physikalisch in der Lage sind, den Fehlerzustand abzubilden.
2. Mapping der Diagnosepfade: Entwickler erstellen ein logisches Modell, das den Pfad vom Auftreten des Fehlers bis zum Erreichen des sicheren Zustands abbildet. Entscheidend ist hierbei das Fault Tolerant Time Interval (FTTI). Die MSR-Analyse prüft, ob die Summe aus Erkennungszeit, Verarbeitungszeit und Reaktionszeit des Aktuators unterhalb dieses kritischen Schwellenwerts liegt.
3. Simulation und Verifikation: Die theoretische Analyse aus der FMEA-MSR wird in modernen Entwicklungsprozessen mit Hardware-in-the-Loop (HiL) Tests verknüpft. Fehlereinspeisungen (Fault Injection) werden genutzt, um die in der FMEA-MSR postulierten Überwachungsraten (M-Werte) praktisch zu verifizieren.
4. Priorisierung durch AP: Anstelle der veralteten Risikoprioritätszahl (RPZ) erfolgt die Bewertung über die Aufgabenpriorität (AP). Diese stützt sich auf die Schwere des Fehlers, die Häufigkeit seines Auftretens im Betrieb und die Wirksamkeit des Monitorings. Eine hohe AP zwingt das Team zur Überarbeitung der Algorithmen oder zur Hardware-Redundanz.

Anwendungsgebiete

Die FMEA-MSR ist das Instrument der Wahl für hochgradig vernetzte, elektronische Systeme. Ihre Anwendung erstreckt sich über kritische Fahrzeugdomänen:

• Batteriemanagementsysteme (BMS): Hier ist die FMEA-MSR essentiell, um thermische Instabilitäten (Thermal Runaway) durch frühzeitige Zellspannungs- und Temperaturüberwachung zu verhindern. Sie bewertet, ob das BMS im Fehlerfall rechtzeitig die Schütze trennt.
• Elektrische Antriebsstränge: Analyse von Inverter-Fehlern. Wenn Leistungshalbleiter kurzschließen, muss die MSR-Logik das System in einen sicheren Zustand (Torque-Off) überführen, bevor unkontrollierte Drehmomente auftreten.
• Fahrerassistenzsysteme (ADAS): Bei autonomen Funktionen bewertet die MSR die Plausibilitätsprüfungen der Sensordaten. Kann das System einen Sensor-Drift (z.B. bei einer Kamera oder Radar) erkennen und rechtzeitig an den Fahrer übergeben oder das Fahrzeug sicher zum Stillstand bringen?
• Embedded Software-Plattformen: Überwachung von Speicherfehlern oder Watchdog-Funktionen. Hier liegt der Fokus darauf, ob ein eingefrorener Softwareprozess erkannt und durch einen Reset oder Notlauf-Modus kompensiert wird.

Typische Fehler und Missverständnisse

In der Praxis treten bei der Anwendung der FMEA-MSR wiederholt Denkfehler auf, die das Sicherheitsniveau gefährden:

• Verwechslung mit der DFMEA: Ein häufiger Fehler ist die Annahme, die FMEA-MSR könne eine DFMEA ersetzen. Die DFMEA verhindert, dass ein Fehler entsteht (Vermeidung), während die MSR sicherstellt, dass ein trotz Vermeidung auftretender Fehler das System nicht zerstört (Beherrschung).
• Fokus auf Statik: Teams vergessen oft, dass MSR ein dynamischer Prozess ist. Eine Diagnose, die nur beim Fahrzeugstart prüft, ob ein Sensor funktioniert, ist keine vollständige MSR. MSR muss den Betriebszustand (Monitoring in Runtime) abdecken.
• Fehleinschätzung der Überwachungsrate (M): Häufig werden Diagnosesysteme als "perfekt" eingestuft. In der Realität haben Diagnosealgorithmen jedoch Latenzzeiten und Toleranzen, die in der M-Bewertung zwingend berücksichtigt werden müssen.
• RPZ-Denken: Das Festhalten an der Risikoprioritätszahl ist ein schwerer Fehler. Die AP-Matrix des AIAG/VDA-Handbuchs ist explizit auf die Risikostruktur der MSR zugeschnitten und darf nicht durch alte mathematische Ansätze verwässert werden.

Abgrenzung und Grenzen

Die FMEA-MSR ist kein Allheilmittel. Ihre Grenzen sind durch die Systemarchitektur und die physikalischen Gesetzmäßigkeiten klar definiert:

• Kein Ersatz für ISO 26262: Die FMEA-MSR ist ein komplementäres Werkzeug. Die funktionale Sicherheit nach ISO 26262 erfordert eine deutlich tiefere formale Analyse (wie FMEDA), um Sicherheitsintegritätslevel (ASIL) zu rechtfertigen.
• Rein mechatronischer Fokus: Die Methode setzt eine elektronische Diagnoselogik voraus. Rein mechanische Fail-Safe-Systeme (z.B. eine Sollbruchstelle oder ein rein mechanisches Ventil) lassen sich mit der Logik von "Monitoring und System Response" kaum sinnvoll abbilden.
• Latenz-Limitierung: Die Methode stößt an ihre Grenzen, wenn die physikalische Prozessgeschwindigkeit höher ist als die technische Machbarkeit der Sensorik und Aktorik. Wenn die FTTI kürzer ist als die Zeit, die der Controller zur Berechnung des Fehlers benötigt, kann die FMEA-MSR dies zwar aufzeigen, aber nicht durch "Optimierung" lösen – hier ist ein grundlegendes Re-Design der Architektur erforderlich.