Diagnosefunktion

Kurz erklärt

Die Diagnosefunktion ist ein essenzieller technischer Mechanismus innerhalb der FMEA-MSR (Monitoring and System Response). Sie dient dazu, Fehler oder Funktionsabweichungen während des laufenden Kundenbetriebs in Echtzeit zu detektieren, einzugrenzen und die notwendige Grundlage für eine definierte Systemreaktion zu schaffen, um so Risiken für Sicherheit und Konformität zu minimieren.

Definition

Eine Diagnosefunktion bezeichnet die Gesamtheit aller Hardware- und Software-Elemente eines Systems, die gezielt dazu konzipiert sind, Fehlzustände im Betrieb zu identifizieren. Sie umfasst die Messwerterfassung, die Signalverarbeitung – etwa durch Plausibilitätsprüfungen oder Schwellwertvergleiche – und die Bereitstellung des Diagnoseergebnisses an die Steuereinheit. Im Kontext der FMEA-MSR fungiert die Diagnosefunktion als entscheidende Barriere; sie verbessert die Erkennungsrate (E-Faktor) massiv und reduziert dadurch das verbleibende Risiko, selbst wenn die konstruktive Fehlervermeidung (DFMEA) nicht alle Eventualitäten abdecken konnte.

Bedeutung im Fachkontext

Im modernen Engineering, insbesondere bei hochkomplexen oder autonomen Systemen, ist die Diagnosefunktion der Übergangspunkt von einer präventiven zur reaktiven, aber beherrschten Sicherheit. Während die klassische DFMEA darauf abzielt, Fehlerursachen zu eliminieren, adressiert die FMEA-MSR den Betriebszustand: Die Diagnosefunktion wandelt ein potenziell kritisches Versagen in ein kontrollierbares Ereignis um, indem sie den Status 'Fehler erkannt' aktiv setzt und somit den Übergang in einen sicheren Betriebszustand (Safe State) ermöglicht. Sie ist das Bindeglied zwischen Monitoring und aktiver Systemantwort.

Input, Verarbeitung, Output, Outcome, Impact

Schritte der Methode in Übersicht

Der Prozess der Diagnosefunktion folgt einem vierstufigen, logisch aufeinander aufbauenden Zyklus: 1. Identifikation der Fehlerart, 2. Festlegung der Diagnosekriterien, 3. Bewertung der Diagnosefähigkeit, 4. Validierung der Diagnosefunktion.

Beschreibung der Einzelschritte mit Ziel & Vorgehen

Anwendung und Vorgehen

Die Implementierung einer robusten Diagnosefunktion folgt einem zyklischen Prozess, der eng mit der Systemarchitektur verzahnt ist. Der erste Schritt, die Fehleridentifikation, basiert primär auf den Erkenntnissen aus der Design-FMEA (DFMEA). Hierbei werden jene Fehlermodi extrahiert, die trotz konstruktiver Maßnahmen eine Restwahrscheinlichkeit für den Eintritt während der Nutzungsphase besitzen.

Im zweiten Schritt erfolgt die Festlegung der Diagnosekriterien. Hierbei wird für jeden identifizierten Fehler eine spezifische "Detektionslogik" definiert. Dies geschieht durch die Auswahl geeigneter Sensorik und die Festlegung von Schwellenwerten. Ein klassisches Beispiel ist die Plausibilitätsprüfung: Wenn ein Sensor für die Batterietemperatur physikalisch unmögliche Sprünge (z. B. von 20 °C auf 150 °C in einer Millisekunde) meldet, greift die Diagnosefunktion und markiert das Signal als ungültig, statt den falschen Wert in die Regelung einfließen zu lassen.

Der dritte Schritt, die Bewertung der Diagnosefähigkeit, ist entscheidend für das Risikomanagement. Hier wird der sogenannte E-Faktor (Detection) nach dem AIAG/VDA-Standard vergeben. Die Bewertung orientiert sich nicht mehr an intuitiven Einschätzungen, sondern an der diagnostischen Abdeckung (Diagnostic Coverage). Diese beschreibt den Prozentsatz der potenziellen Fehler, die tatsächlich durch die implementierte Logik erkannt werden.

Abschließend folgt die Validierung der Diagnosefunktion mittels Fault Injection Tests. Dabei werden künstliche Fehler in das laufende System injiziert – etwa durch das bewusste Unterbrechen einer Sensorleitung oder das Manipulieren des Software-Speichers –, um zu prüfen, ob die Diagnosefunktion innerhalb des Fault Tolerant Time Interval (FTTI) reagiert. Die FTTI ist dabei die kritische Zeitspanne, innerhalb derer eine Systemreaktion erfolgen muss, um ein gefährliches Ereignis abzuwenden. Ohne diese Validierung bleibt die Diagnosefunktion eine rein theoretische Annahme.

Anwendungsgebiete

Die Diagnosefunktion findet heute in nahezu allen sicherheitskritischen Bereichen Anwendung, wobei die Anforderungen je nach Industriezweig stark variieren:

• Automotive: Hier liegt der Fokus auf der Absicherung von Fahrerassistenzsystemen (ADAS) und autonomen Fahrfunktionen. Gemäß der ISO 26262 ist die Diagnosefunktion unabdingbar, um bei Ausfällen von Sensoren oder Aktuatoren einen "Safe State" (z. B. Übernahme durch den Fahrer oder Notstopp) einzuleiten. Die Herausforderung liegt hier in der hohen Rechenlast, die die Steuergeräte bewältigen müssen.
• Industrieautomation: Bei der Überwachung von Robotik-Systemen dient die Diagnosefunktion der Kollisionsvermeidung und Prozesssicherheit. Hier müssen Sensordaten in Echtzeit verarbeitet werden, um bei Abweichungen von der Bahnkurve sofort abzuschalten.
• Medizintechnik: In lebenserhaltenden Geräten, wie etwa Beatmungsgeräten, ist die Diagnosefunktion das letzte Glied in der Sicherheitskette. Hier liegt der Schwerpunkt auf höchster Fehlertoleranz und der sofortigen Alarmierung bei kritischen Abweichungen der Vitalparameter.
• Luft- und Raumfahrt: Hier wird das Redundanzmanagement durch Diagnosefunktionen gesteuert. Die Avionik muss bei einem Komponentenversagen eigenständig entscheiden, welcher redundante Pfad das System weitersteuert, ohne dass die Besatzung manuell eingreifen muss.

Typische Fehler und Missverständnisse

In der Praxis begegnen Entwickler häufig Denkfehlern, die den Nutzen der Diagnosefunktion untergraben:

1. Die Diagnose ersetzt die Konstruktion: Ein weit verbreiteter Irrtum ist die Annahme, man könne durch eine ausgefeilte Diagnose auf eine solide DFMEA verzichten. Eine Diagnosefunktion ist jedoch immer eine "Nachsorge-Maßnahme". Sie macht ein System nicht fehlerfrei, sondern nur beherrschbar.
2. Fehleinschätzung der Wirksamkeit: Viele Entwickler glauben, eine Diagnose sei zu 100 % wirksam, sobald ein Sensor den Fehler bemerkt. Dabei wird oft vergessen, dass auch der Diagnosealgorithmus selbst, die Verkabelung oder der Prozessor ausfallen können.
3. Die Diagnose ohne Analyse: Häufig wird eine Diagnosefunktion als "Black Box" behandelt, ohne die Diagnose selbst einer eigenen Analyse zu unterziehen. Eine Diagnosefunktion muss zwingend auf ihre eigene Fehleranfälligkeit geprüft werden.
4. Verwechslung von Monitoring und Diagnose: Monitoring ist lediglich das passive Beobachten von Werten. Die Diagnosefunktion hingegen beinhaltet die aktive Logik, die bewertet, ob ein Wert innerhalb oder außerhalb der Spezifikation liegt, und löst idealerweise bereits eine automatisierte Systemreaktion aus.
5. Ignorieren der Falsch-Positiv-Rate: Eine zu sensible Diagnose führt zu häufigen Fehlalarmen, was dazu führt, dass Nutzer das System abschalten oder Warnungen ignorieren. Dies stellt ein eigenes, neues Sicherheitsrisiko dar.

Abgrenzung und Grenzen

Die Diagnosefunktion ist ein mächtiges Werkzeug, stößt jedoch an physikalische und wirtschaftliche Grenzen:

• Rechenleistung: Die Komplexität der Algorithmen zur Diagnose darf die für die eigentliche Systemfunktion notwendige Rechenleistung nicht einschränken. In sehr kostensensitiven Produkten ist der Speicherplatz für Diagnose-Software oft begrenzt.
• Physikalische Grenzen: Wenn ein Fehler in einer Weise auftritt, die auch die Sensoren oder die Diagnose-Hardware selbst korrumpiert (Common Cause Failure), kann die Diagnosefunktion versagen.
• Regulatorik: In der Medizintechnik oder Luftfahrt erfordert jede Diagnosefunktion eine aufwendige Zulassung. Je komplexer die Funktion ist, desto schwieriger wird der Nachweis der Konformität gegenüber Zertifizierungsstellen.
• Wartbarkeit: Je mehr Diagnosefunktionen in ein System integriert werden, desto komplexer wird das Gesamtsystem. Dies kann die Fehlersuche bei der Wartung erschweren, da nicht immer klar ist, ob ein Problem in der Applikation oder in der Diagnose-Logik selbst liegt.