ISO 26262-5 Leitfaden zur Hardwareentwicklung: Anforderungen, Metriken und Tests

• AutorJohnny Liu (CEO bei Dowway Vehicle)
• Datum7. Juli 2026
• KategorieFunktionale Sicherheit im Automobilbereich / Hardwareentwicklung

Moderne Autos sind vollgepackt mit komplexer Elektronik. Je intelligenter die Fahrzeuge werden, desto zuverlässiger müssen die Platinen und Siliziumchips im Inneren sein.

Ich habe jahrelang an Fahrzeughardware gearbeitet. Ich weiß, wie aufwendig die Einhaltung der funktionalen Sicherheitsbestimmungen sein kann. Dieser Leitfaden führt Sie durch den Prozess. ISO 26262-5 (Hardwareentwicklung) Wir verwenden klare, praktische Schritte. Wir werden alles abdecken, von den Anforderungen bis hin zu Kennzahlen wie SPFM, LFM und PMHF.

1. Die drei wichtigsten Hardware-Sicherheitsaktivitäten

Um die Sicherheit von Fahrzeugsystemen zu gewährleisten, reicht es nicht aus, einfach darauf zu hoffen, dass die Hardware funktioniert. Wir müssen sie so konstruieren, dass sie auch mit Ausfällen umgehen kann.

ISO 26262-5 beschreibt drei Hauptaktivitäten, die Sie durchführen müssen:

1. Integrieren Sie das technische Sicherheitskonzept in die Hardware.
2. Analysieren Sie mögliche Hardwarefehler und ermitteln Sie deren Auswirkungen.
3. Eng mit dem Softwareteam zusammenarbeiten.

Die Logik hinter Klausel 8 und Klausel 9

Der Standard verwendet zwei unterschiedliche Klauseln, um die Sicherheit Ihrer Hardware zu messen:

• Abschnitt 8 (Hardwarearchitekturmetriken)Diese Klausel verwendet zwei Prozentwerte – Single-Point Fault Metric (SPFM) und Latent Fault Metric (LFM) –, um zu messen, wie gut Ihr Hardware-Design und Ihre Sicherheitsmechanismen mit zufälligen physikalischen Ausfällen umgehen.
• Klausel 9 (Bewertung zufälliger Hardwareausfälle)Diese Klausel betrachtet das Gesamtrisiko. Sie verwendet entweder eine mathematisch aufwändige Wahrscheinlichkeitsberechnung (PMHF) oder eine Schnittmengenanalyse, um zu prüfen, ob das Risiko, ein Sicherheitsziel zu verletzen, gering genug ist.

2. Einrichtung Ihrer Hardware-Sicherheitsanforderungen (HSR)

Dein Hardware-Sicherheitsanforderungen (HSR) muss sich direkt aus Ihren technischen Sicherheitsanforderungen (TSR) auf Systemebene ergeben. Sie müssen außerdem eine detaillierte Hardware-Software-Schnittstelle (HSI) Spezifikation zur Veranschaulichung der Wechselwirkung zwischen physischen Bauteilen und Code.

Ihr HSR muss fünf Schlüsselbereiche abdecken:

1) Interne Fehlerkontrolle

Ihre Anforderungen müssen festlegen, wie interne Fehler in Ihren Hardwareeinheiten behandelt werden. Dies umfasst Methoden zum Abfangen temporärer Störungen (transienter Fehler) mithilfe von Tools wie Watchdogs und Timern.

2) Widerstandsfähigkeit gegenüber äußeren Einflüssen

Die Hardware muss Ausfälle außerhalb ihrer eigenen Platine überstehen. Wenn beispielsweise ein externes elektronisches Steuergerät (ECU) ausfällt, müssen die Eingänge Ihrer ECU Probleme wie offene Stromkreise oder Kurzschlüsse in der Stromversorgung (KL30) abfangen können.

3) Abgleich zwischen den Einheiten

Stellen Sie sicher, dass Ihre Sicherheitsanforderungen mit den Sicherheitsanforderungen benachbarter Hardwarekomponenten im Fahrzeug übereinstimmen und gut zusammenarbeiten.

4) Fehlererkennung und -signalisierung

Ihr Design muss Fehler schnell erkennen und melden. Sie müssen Anforderungen formulieren, die häufige physikalische Fehler erkennen, darunter:

• Offene Pins
• Kurzschluss gegen Masse
• Kurzschluss gegen Strom

5) Regeln zur Designverifizierung

Die HSR sollte Sie nicht auf einen bestimmten Sicherheitsmechanismus festlegen. Stattdessen muss sie die Regeln definieren, anhand derer Sie die Konstruktion später überprüfen werden. Diese Regeln umfassen:

• UmweltgrenzenTemperatur, Vibrationen und elektromagnetische Störungen (EMI).
• Betriebsbedingungen: Spannungsbereiche der Stromversorgung und die zu erwartende Lebensdauer (Missionsprofile).
• Komponentenspezifische RegelnAnforderungen an spezifische Mikrochips oder Leistungstreiber.

3. Hardware-Design: Von der Architektur zu den Schaltplänen

Beim Hardware-Design geht es von der Gesamtarchitektur bis hin zu den eigentlichen Schaltplänen.

Architektur im großen Ganzen

Ihre Architektur zeigt alle Ihre Hardware-Einheiten und wie diese miteinander verbunden sind.

• ASIL-VererbungJede Hardwareeinheit muss die Sicherheitsanforderungen des höchsten ihr zugewiesenen Automotive Safety Integrity Level (ASIL) erfüllen.
• Rückverfolgbarkeit ist entscheidend.Sie müssen Ihre Anforderungen vom übergeordneten HSR bis hin zum kleinsten Funktionsbaustein auf Ihrer Leiterplatte nachvollziehen können. Diese bidirektionale Rückverfolgbarkeit ist die Kernregel sowohl von ISO 26262 als auch von ASPICE.
• Halte es einfachUm Designfehler zu vermeiden, gestalten Sie Ihr Layout modular, halten Sie die Blöcke in angemessener Größe und vermeiden Sie unnötige Komplexität.
• UmweltstressSie müssen reale Faktoren wie Hitze, Vibrationen, Feuchtigkeit, Staub und elektromagnetische Störungen (EMI) von anderen Fahrzeugkomponenten berücksichtigen. Diese Aspekte gehören in Ihre Designverifizierungsplan-Tests (DVP) (EMV-, elektrische und umweltbedingte Lebenszyklustests).

Detaillierter Schaltplan

Wenn Sie mit dem Zeichnen von Linien in Ihrem Schaltplan beginnen, beachten Sie folgende Regeln:

1. Aus der Vergangenheit lernen: Orientieren Sie sich an der Sicherheitskultur Ihres Unternehmens und nutzen Sie die Erkenntnisse aus früheren Projekten (siehe ISO 26262-2:2018, Abschnitt 5.4.7).
2. Körperliche Überlastung vermeidenEntwerfen Sie Ihre Schaltungen so, dass sie elektrischem Rauschen, Hitze und Feuchtigkeit standhalten.
3. Bleiben Sie im Rahmen.: Stellen Sie sicher, dass alle Teile innerhalb ihrer spezifizierten Umgebungsgrenzen arbeiten.
4. Robuste Methoden anwenden: Verwenden Sie zuverlässige Qualitätsmanagement-Verfahren (QM). Dazu gehören die konservative Bauteilauswahl, die Reduzierung der Bauteilleistung (Betrieb der Bauteile unterhalb ihrer maximalen Leistungsgrenzen) und die Worst-Case-Schaltungsanalyse (WCCA).

4. Hardware-Sicherheitsanalyse: Klassifizierung von Fehlern

Um herauszufinden, wo Ihre Hardware ausfallen könnte, müssen Sie eine Sicherheitsanalyse durchführen. Diese Analyse basiert auf … ISO 26262-9:2011 Abschnitt 8Die

Diese Analyse hilft Ihnen, Ihr Design frühzeitig zu verfeinern und Ihre Arbeit später zu überprüfen. Sie ist obligatorisch für Systeme, die auf … abzielen. ASIL (B), C oder DDie

Ihre Sicherheitsanalyse muss drei Arten von Fehlern berücksichtigen:

• Sichere Fehler: Fehler, die Ihre Sicherheitsziele nicht direkt verletzen.
• Einzelpunktfehler (SPF) / Restfehler (RF)Die
• Mehrpunktfehler (MPF) (einschließlich wahrgenommener, festgestellter und latenter Fehler).

In den meisten realen Projekten können Sie Ihre Mehrpunktanalyse auf Folgendes beschränken: Doppelpunktfehler (Zwei unabhängige Fehler treten gleichzeitig auf). Sie müssen nicht jede mögliche Kombination von zwei ausfallenden Teilen analysieren. Konzentrieren Sie sich stattdessen auf Kombinationen, bei denen ein Fehler ein zentrales Hardwareteil betrifft und der zweite Fehler den Sicherheitsmechanismus außer Kraft setzt, der dieses Teil schützen soll.

Einzelpunktfehler (SPF)

Ein SPF ist ein physikalischer Ausfall einer einzelnen Hardwarekomponente, der von keinem Sicherheitsmechanismus erkannt wird und direkt dazu führt, dass das System ein Sicherheitsziel verletzt.

Um nachzuweisen, dass Sie die Sicherheitslücken für ASIL (B), C oder D-Systeme geschlossen haben, müssen Sie Folgendes nachweisen:

• A) Zuverlässige SicherheitsmechanismenEs gibt Sicherheitsmechanismen, die das System schützen oder in einen sicheren Zustand versetzen können. Dies muss innerhalb der Systeme geschehen. Fehlertolerantes Zeitintervall (FTTI)Die
• B) Hohe diagnostische AbdeckungSie müssen berechnen, wie viele Restfehler Ihre Diagnosegeräte aufspüren können.

Wichtige Gestaltungsregeln für SPFs:

• Die FTTI-Regel: Wenn Ihr Diagnosetest zu lange dauert oder der Sicherheitsmechanismus zu lange braucht, um zu reagieren, und die Gesamtzeit länger ist als Ihre FTTI, ist der Mechanismus ungültig.
• Überprüfung beim EinschaltenWenn ein Fehler nur beim Start erkannt werden kann, müssen Sie Ihre Selbsttests sofort nach dem Einschalten des Fahrzeugs und vor Fahrtbeginn durchführen.
• Analytische Werkzeuge: Verwenden Sie eine Fehlermöglichkeits- und Einflussanalyse (FMEA) oder eine Fehlerbaumanalyse (FTA), um Ihre Berechnungen zu belegen.
• BewertungsniveauJe nach den verwendeten Komponenten können Sie den Chip als Ganzes analysieren oder die Ausfallmechanismen einzelner Pins genauer untersuchen.

Latente Fehler

Ein latenter Fehler ist ein mehrstufiger Ausfall, der von den Sicherheitsmechanismen nicht erkannt wird und vom Fahrer nicht bemerkt werden kann. Mit der Zeit summieren sich diese versteckten Fehler und können zu plötzlichen Systemausfällen führen, wenn ein zweites Bauteil ausfällt.

Um nachzuweisen, dass Sie sich gegen versteckte Fehler abgesichert haben, müssen Sie Folgendes zeigen:

• A) FahrerbenachrichtigungDas System kann den ersten Fehler erkennen und den Fahrer innerhalb eines akzeptablen Zeitraums warnen, bevor ein zweiter Fehler auftritt.
• B) Gemessene AbdeckungSie müssen Ihre Diagnoseabdeckung für diese versteckten Fehler bewerten und berechnen.

Wichtige Entwurfsregeln für latente Fehler:

• Wenn Ihr Diagnosetestintervall zuzüglich Ihrer Reaktionszeit länger ist als das für die Mehrpunkt-Fehlererkennung definierte Zeitfenster, wird der Fehler als nicht erfasst (latent) betrachtet.
• Verwenden Sie eine quantitative FMEA oder FTA, um Ihr mathematisches Modell zu erstellen.

Überprüfung: Die Beziehung zwischen 3a/3b und 1a/1b

Bei der Designverifizierung werden Standardmethoden angewendet. 3a und 3b Sie dienen als spezifische Prüfverfahren für Umwelt- und Robustheitsprinzipien. Nutzen Sie sie, um Ihre grundlegenden Verifizierungsmethoden zu ergänzen und zu stärken. 1a und 1bDie

5. Kennzahlen und Ausfallraten der Hardwarearchitektur

Um externen Prüfern nachzuweisen, dass Ihr Entwurf sicher ist, müssen Sie seine architektonischen Kennzahlen berechnen.

Wo finde ich Daten zur Ausfallrate (FIT)?

Ausfallraten lassen sich nicht erfinden. Sie müssen Ihre FIT-Daten (Failure in Time) aus einer dieser drei Quellen beziehen:

Quelle 1: Anerkannte Industriestandards

Dies ist die gängigste Methode, um Ausfallraten von Bauteilen zu ermitteln. Sie können Folgendes verwenden:

• SN 29500 (Siemens-Standard, weit verbreitet in der Automobilindustrie).
• IEC/TR 62380 oder IEC 61709Die
• MIL HDBK 217 F Mitteilung 2 oder RIAC HDBK 217Die
• UTE C80-811Die
• NPRD95Die
• EN 50129:2003 Anhang C oder IEC 62061:2005 Anhang DDie
• RIAC FMD97 oder MIL HDBK 338Die

Quelle 2: Feldrückgabedaten

Sie können reale Daten von Fahrzeugen im Straßenverkehr verwenden, aber Ihre Daten müssen ein hohes Konfidenzniveau aufweisen.

Quelle 3: Strukturierte Expertenbeurteilung

Falls keine Daten vorliegen, können Sie strukturierte Beurteilungen von Ingenieursexperten heranziehen. Sie müssen die genauen Gründe und Kriterien, die deren Beurteilung zugrunde gelegt haben, schriftlich festhalten.

Metrische Zielvorgaben für ASIL-Stufen

Um ein Audit zu bestehen, muss Ihr Entwurf die folgenden Mindestanforderungen erfüllen:

Metrisch	ASIL B	ASIL C	ASIL D
Single-Point Fault Metric (SPFM)	$\ge 90\%$	$\ge 97\%$	$\ge 99\%$
Latente Fehlermetrik (LFM)	$\ge 60\%$	$\ge 80\%$	$\ge 90\%$
Wahrscheinlichkeit eines zufälligen Hardwareausfalls (PMHF)	$<lt; 10^{-7} \text{ h}^{-1}$ (100 FIT)	$<lt; 10^{-7} \text{ h}^{-1}$ (100 FIT)	$<10^{-8} \text{ h}^{-1}$ (10 FIT)

6. Den Regelkreis schließen: Hardware-Sicherheitstests

Sie können sich nicht allein auf Dokumente und Berechnungen verlassen. Sie müssen Ihre Hardware physisch testen, um verbleibende Konstruktionsfehler aufzudecken.

Um Ihre Sicherheitsmechanismen zu überprüfen, schreiben Sie Testfälle basierend auf diesen drei Testmethoden:

A. Funktionstests

Dieser Test beweist, dass Ihre Platine unter normalen Bedingungen ordnungsgemäß funktioniert. Sie geben normale Eingangssignale ein und prüfen, ob die Ausgaben Ihren Spezifikationen entsprechen. Sollte etwas nicht stimmen, müssen Sie die Ursache analysieren.

B. Fehlereinspritzungstest

Dieser Test beweist, dass Ihre Sicherheitsmechanismen im Fehlerfall tatsächlich funktionieren. Sie beschädigen die Platine physisch oder simulieren einen Fehler (z. B. durch Kurzschließen eines Pins gegen Masse) und beobachten die Reaktion des Systems. Dies ist die beste Methode, um die Reaktionszeiten der Sicherheitsmechanismen zu überprüfen.

C. Elektrische Prüfung

Dieser Test überprüft Ihr Design über den gesamten Betriebsspannungsbereich. Sie betreiben die Platine unter Hochspannung, Niederspannung und plötzlichen Spannungsspitzen, um ihre Stabilität sicherzustellen.

Umweltstresstests

Sie müssen außerdem testen, wie gut die Hardware externen physikalischen Belastungen standhält. Dazu gehören Tests mit starker Vibration, Temperaturwechseltests (von Tiefsttemperaturen bis zu hohen Temperaturen) und Tests mit starker elektromagnetischer Verträglichkeit (EMV).

Schlussbetrachtung

Funktionale Sicherheit ist ein iterativer Prozess. Man beginnt mit den Anforderungen, entwirft die Schaltungen, analysiert sie mithilfe von FMEAs und Berechnungen und verifiziert anschließend alles durch praktische Tests. Werden dabei Schwachstellen entdeckt, wird der Entwurf überarbeitet und erneut getestet. Durch diesen Zyklus entwickeln wir Fahrzeuge, die wirklich sicher und robust sind.

Häufig gestellte Fragen

Frage 1: Was passiert, wenn Ihre Diagnoseprüfung und die Sicherheitsreaktion länger dauern als das Fehlertoleranzintervall (FTTI)?

KurzantwortDer Sicherheitsmechanismus ist ungültig, weil er das System nicht rechtzeitig schützen kann.

DetailsTritt ein Fehler auf und dauert die Diagnose zu lange, kann das System abstürzen oder sich gefährlich verhalten, bevor die Sicherheitsmechanismen eingreifen können. Die gesamte Reaktionszeit – vom Zeitpunkt des Auftretens des physischen Fehlers bis zum Erreichen eines sicheren Systemzustands – muss stets kürzer sein als die Fehlertoleranzzeit (FTTI).

Frage 2: In welchem ​​Verhältnis stehen die Verifizierungsmethoden 3a/3b und 1a/1b gemäß ISO 26262-5 zueinander?

KurzantwortDie Methoden 3a und 3b sind spezifische, zielgerichtete Prüfungen, die Sie zur Unterstützung und Stärkung Ihrer grundlegenden Designprüfungen 1a und 1b verwenden.

DetailsDie Methoden 1a (Überprüfung der Umgebungsgrenzen) und 1b (Anwendung von Auslegungsregeln wie Leistungsreduzierung und WCCA) bilden Ihre grundlegenden Auslegungspraktiken. Die Methoden 3a und 3b dienen als zweite Verifizierungsebene. Sie konzentrieren sich auf spezifische physikalische Ausfallpunkte und Umgebungsbedingungen, um sicherzustellen, dass bei der ursprünglichen Auslegung nichts übersehen wurde.

Frage 3: Warum ist der SN 29500-Standard so beliebt für die Berechnung von Hardware-Ausfallraten?

KurzantwortEs handelt sich um die vertrauenswürdigste und am weitesten verbreitete Ausfallratendatenbank in der automobilen Lieferkette.

DetailsWährend Normen wie MIL-HDBK-217F oder IEC/TR 62380 nützlich sind, liefert SN 29500 (entwickelt von Siemens) äußerst realistische und aktuelle Ausfallraten für moderne Siliziumchips und passive Bauelemente. Durch die Verwendung dieser Norm stellen Sie sicher, dass Ihre Berechnungen den Anforderungen von Automobilherstellern und Tier-1-Zulieferern im Rahmen von Audits zur funktionalen Sicherheit entsprechen.