In sicherheitskritischen Systemen, insbesondere in der Automobilindustrie und anderen Branchen mit hohen Sicherheitsanforderungen, sind quantitative Metriken zur Beurteilung der Hardware-Sicherheit essenziell. Die funktionale Sicherheit sorgt dafür, dass elektronische Systeme auch bei auftretenden Fehlern weiterhin sicher arbeiten oder in einen sicheren Zustand übergehen. In der ISO26262 werden diese Metriken in diesem Bereich mit LFM (Latent Fault Metric), PMHF (Probabilistic Metric for Hardware Failures) und SPFM (Single Point Fault Metric) bezeichnet. Wir zeigen exemplarisch den Design-Prozess einer Hardware rund um diese Metriken.
LFM: Erkennung latenter Fehler
LFM beschreibt, wie gut ein System versteckte, latente Fehler erkennt, bevor sie zu gefährlichen Situationen führen können. Latente Fehler bleiben zunächst unbemerkt, können jedoch in Kombination mit anderen Defekten zu einem Versagen führen. Beispielsweise kann ein defekter Sensor erst dann kritisch werden, wenn ein zweiter redundanter Sensor ebenfalls ausfällt. In der Automobilindustrie fordert ISO 26262 für die höchste Sicherheitsstufe (ASIL D) eine LFM von bis zu 90 %. Dies wird durch regelmäßige Selbsttests, Redundanzkonzepte und Überwachungsmechanismen erreicht, die helfen, solche Fehler frühzeitig zu erkennen.
PMHF: Wahrscheinlichkeit gefährlicher Hardware-Ausfälle
PMHF gibt an, mit welcher Wahrscheinlichkeit zufällige Hardwarefehler im Laufe der Zeit auftreten und eine sicherheitskritische Funktion beeinträchtigen können. Elektronische Komponenten unterliegen einer statistischen Ausfallrate, die durch Faktoren wie Alterung, Umweltbedingungen oder zufällige Defekte beeinflusst wird. PMHF wird oft in FIT-Werten (Failures in Time, Fehler pro 10⁹ Betriebsstunden) ausgedrückt. Ein typischer Grenzwert für ASIL D liegt unter 10−8 Fehlern pro Stunde. Um diesen Wert zu erreichen, sind Maßnahmen wie die Auswahl zuverlässiger Bauteile, Schutzmechanismen und robuste Fehlerdiagnosesysteme notwendig.
SPFM: Vermeidung gefährlicher Einzelpunktfehler
SPFM hingegen beschreibt, wie viele potenziell gefährliche Einzelpunktfehler durch das System erkannt oder kompensiert werden. Ein Single-Point-Fault ist ein Fehler, der ohne weitere Schutzmaßnahmen direkt zu einem sicherheitskritischen Versagen führen kann. Beispielsweise würde ein defekter Airbag-Sensor ohne Redundanz oder Fehlererkennung dazu führen, dass der Airbag nicht auslöst. Um solche Szenarien zu verhindern, fordert ISO 26262 für hohe Sicherheitsstufen eine SPFM von über 99 %, um sicherzustellen, dass nahezu alle potenziell gefährlichen Einzelpunktfehler erkannt oder vermieden werden. Redundanzsysteme, Fehlererkennungsmechanismen und Schutzschaltungen tragen dazu bei, dieses Ziel zu erreichen.
Residual Faults - Restfehler-Metrik
Ein Residual Fault (RF), also ein Restfehler, ist ein Fehler, der trotz implementierter Sicherheitsmechanismen im System verbleibt. Diese Fehler sind nicht vollständig eliminiert worden und können potenziell zu sicherheitskritischen Ereignissen führen.
Restfehler entstehen, wenn:
- Ein Fehler nicht ausreichend von einem Sicherheitsmechanismus erkannt oder kompensiert wird.
- Die Diagnoseabdeckung (Diagnostic Coverage, DC) unzureichend ist.
- Es keine redundante Schutzmaßnahme für diesen Fehler gibt.
Die Anforderungen an diese Metriken steigen mit dem Automotive Safety Integrity Level (ASIL), wobei höhere ASIL-Stufen strengere Vorgaben haben. Die folgende Tabelle zeigt die Grenzwerte für ASIL B, C und D in der ISO 26262:
| Metrik | ASIL B | ASIL C | ASIL D |
|---|---|---|---|
| PMHF | < 10⁻⁷ h⁻¹ (100 FIT) | < 10⁻⁷ h⁻¹ (100 FIT) | < 10⁻⁸ h⁻¹ (10 FIT) |
| SPFM | ≥ 90 % | ≥ 97 % | ≥ 99 % |
| LFM | ≥ 60 % | ≥ 80 % | ≥ 90 % |
Entwicklung von sicherheitskritischer Hardware
Die Philosophie der Hardwareentwicklung nach ISO 26262 unterscheidet sich nicht grundlegend von bewährten ingenieurtechnischen Praktiken. Die Norm setzt auf einen iterativen Entwicklungsprozess, bei dem sich durch zunehmende Erfahrung die Anzahl der Iterationen verringert. Dieser Ansatz ermöglicht eine frühzeitige Identifikation und Behebung potenzieller Sicherheitsrisiken, wodurch die Qualität und Zuverlässigkeit des Endprodukts verbessert wird.
Iterativer Entwicklungsprozess
Wir zeigen im folgenden Beispiel einen iterativen Hardware-Entwicklungsprozess, der anhand dieser Metriken einem definierten Safety Integrity Level nachkommt.
Der Entwicklungsprozess beginnt mit der ersten Iteration, in der das Safety Goal (Sicherheitsziel) definiert und daraus eine funktionale Sicherheitsanforderung abgeleitet wird. In unserem Beispiel soll ein System entwickelt werden, welches eine Kühl- und Überlastfunktion mit dem Sicherheitsgrad ASIL-C aktiviert.
Safety Goal: Verhindern einer Überhitzung des Systems (ASIL C)
Derived FS Requirement: Aktivieren eines Kühlventilators, sobald die Temperatur einen definierten Schwellenwert überschreitet.
In dieser frühen Phase wird noch keine detaillierte Fehleranalyse durchgeführt, sondern das grundlegende Sicherheitskonzept festgelegt.
Erste Festlegungen und Fehleranalyse
Der naheliegendste Ansatz in dieser Phase ist ein sehr einfaches Design aus Sensor, Mikrocontroller und Aktor (Lüfter).
Erstes vereinfachtes Design
In der ersten Iteration wird eine detaillierte Fehleranalyse durchgeführt. Dabei werden die einzelnen Komponenten des Systems betrachtet, um die Wahrscheinlichkeit von Ausfällen zu bestimmen.
| Komponente | FIT | FMD | Residual Faults | MPF-L |
| Sensor | 1 | 100 % | 1 | |
| MCU | 100 | 50 % | 50 | |
| Fan | 10 | 50 % | 5 | |
| Total | 111 | 56 |
-
Single-Point Fault Metric (SPFM): 1-(56/111) = 49,5 % → unzureichend
-
Latent Fault Metric (LFM): irrelevant in dieser Phase
-
PMHF: 56 FIT
Diese erste Analyse zeigt, dass das System noch nicht sicher genug ist, da die SPFM unter den geforderten Werten liegt. In den nächsten Iterationen müssen daher Sicherheitsmechanismen eingeführt werden, um die Fehlererkennung und -bewältigung zu verbessern.
Einführung von Sicherheitsmechanismen
Um die in identifizierten Sicherheitsprobleme zu beheben, wird in der zweiten Iteration ein Watchdog (WD) als zusätzlicher Sicherheitsmechanismus integriert. Dieser dient dazu, potenzielle Fehlfunktionen der MCU zu überwachen und bei Fehlern das System in einen sicheren Zustand zu überführen.
Zweite Design-Schleife
| Komponente | FIT | FMD | Residual Faults | MPF-L |
| Sensor | 1 | 100 % | 1 | |
| MCU | 100 | 50 % | 5 | 45 |
| Fan | 10 | 50 % | 5 | |
| Watchdog (WD) | 10 | 100 % | 10 | |
| Total | 121 | 11 | 55 |
-
Single-Point Fault Metric (SPFM): 1-(11/121) = 90,9 % → deutliche Verbesserung
-
Latent Fault Metric (LFM): 1-(55/(121-11)) = 50 %
-
PMHF: 11+55 = 66 FIT
Durch die Einführung des Watchdogs als Sicherheitsmechanismus mit einer Diagnoseabdeckung (D.C.) von 90 % konnte die SPFM signifikant verbessert werden. Allerdings liegt die LFM mit 50 % noch unterhalb der Anforderungen für höhere ASIL-Level. In der nächsten Iteration müssen daher weitere Verbesserungen vorgenommen werden, um die Latent Fault Metric weiter zu erhöhen.
Verbesserung von Latent Faults
Um Latent Faults zu identifizieren, nehmen wir (durchaus plakativ) an, dass mit einer Warnleuchte oder einem anderen Signalindikator einem Fahrer diese angezeigt werden. Die Warnleuchte verbessert damit die Latent Fault Metric (LFM), weil sie dazu beiträgt, unerkannte Fehler sichtbar zu machen.
Design-Schleife mit LED
Latente Fehler werden zumeist erst in Kombination mit einem weiteren Fehler zu einem sicherheitskritischen Zustand führen. Ohne eine Warnanzeige könnten diese Fehler über lange Zeit bestehen, ohne dass eine Korrektur erfolgt. Die Warnleuchte sorgt dafür, dass solche Fehler von außen wahrgenommen werden.
| Komponente | FIT | FMD | Residual Faults | MPF-L |
| Sensor | 1 | 100 % | 1 | |
| MCU | 100 | 50 % | 5 | |
| Fan | 10 | 50 % | 5 | |
| Watchdog (WD) | 10 | 100 % | ||
| Warnleuchte | 1 | 100 % | 10 | |
| Total | 121 | 11 | 10 |
-
Single-Point Fault Metric (SPFM): 1-(11/121) = 90,9 % → stabil geblieben
-
Latent Fault Metric (LFM): 1-(10/(121-11)) = 90,1 % → deutliche Verbesserung
-
PMHF: 11+10 = 21 FIT
Durch die Einführung der Warnleuchte konnte die Latent Fault Metric (LFM) auf über 90 % gesteigert werden, was eine signifikante Verbesserung darstellt. Dadurch entspricht das System nun den Anforderungen für ASIL B.
Redundanz einführen
Um die Sicherheit weiter zu erhöhen und ASIL C zu erreichen, wird in der vierten Iteration (n=4) eine zweite Lüftereinheit hinzugefügt. Diese sorgt für zusätzliche Redundanz, sodass ein Ausfall eines einzelnen Lüfters nicht zur Überhitzung des Systems führt.
| Komponente | FIT | FMD | RF | MPF-L |
| Sensor | 1 | 100 % | 1 | |
| MCU | 100 | 50 % | 0,5 | |
| Fan 1 | 10 | 50 % | 5 | |
| Fan 2 | 10 | 50 % | 5 | |
| Watchdog (WD) | 10 | 100 % | 10 | |
| Warnleuchte | 1 | 100 % | ||
| Total | 131 | 1,5 | 20 |
-
Single-Point Fault Metric (SPFM): 1-(1.5/131) = 98,8 % → deutliche Verbesserung
-
Latent Fault Metric (LFM): 1-(20/(131-1.5)) = 84,5 %
-
PMHF: 1.5+20 = 21.5 FIT
Durch die Einführung eines zweiten Lüfters konnte die Single-Point Fault Metric (SPFM) auf 98,8 % verbessert werden, wodurch das System den Anforderungen für ASIL C entspricht. Die Redundanz stellt sicher, dass das System auch dann funktionsfähig bleibt, wenn ein einzelnes Kühlgebläse ausfällt. Damit wurde eine weitere Sicherheitsstufe erreicht, und das System erfüllt nun strengere Anforderungen an die funktionale Sicherheit.
Fazit
Der vorliegende Artikel zeigt, dass durch gezielte Verbesserungen an der Systemarchitektur schrittweise höhere Sicherheitsstufen erreicht werden können. Dieser Prozess zeigt, dass funktionale Sicherheit keine einmalige Designentscheidung ist, sondern ein iterativer, analytischer Ansatz, der durch Fehlermodellierung und schrittweise Verbesserungen optimiert wird. In der Praxis ermöglicht dies die Entwicklung robuster sicherheitskritischer Systeme, die den Anforderungen der ISO 26262 entsprechen.
Kommentieren