Hardwareentwicklung nach ISO 26262

Teil 5 beschäftigt sich im Kern mit der Hardwareentwicklung nach ISO 26262. Der Entwurf einer Hardwarearchitektur mit passenden Eigenschaften im Sinne der notwendigen Hardwaresicherheitsintegrität entsprechend dem ASIL steht im Mittelpunkt. Es sind Hardware-Sicherheitsanforderungen (HW-S-Req) von der Systemebene abzuleiten und im Hardwaredesign umzusetzen. Dabei sind die erforderlichen Metriken (SPFM / LFM) zu berücksichtigen. Das technische Sicherheitskonzept (TSC) auf Systemebene wird in Hardware und Software aufgeteilt. Dabei kommt ein Hardware-Software-Interface (HSI) als zentrales Schnittstellendokument zum Einsatz.

Planung der Hardwareentwicklung

Haben Sie ein SEooC im technischen Sicherheitskonzept eingeplant ? Dann ist es an der Zeit einen genaueren Blick auf die vom Hardware-Hersteller gelieferten Informationen (FMEA, FTA oder gar bereits vorgefertigte SPFM / LFM) zu werfen um frühzeitig diese Phase der Produktentwicklung planen zu können. Wie gehen Sie mit HW-Sicherheitsmechnismen im Testplan um ? Nicht alles ist mit wirtschaftlichen Aufwand testbar. Welche Fehlerkataloge (Reliability Handbooks) wollen Sie verwenden ? Die Leistungsfähigkeit der HW-Entwicklungs- und Testabteilung ist ausreichend und organisiert passend dem erforderlichen Integritätslevel (ASIL) sicherzustellen.

Die folgenden Phasen im V-Modell für die Hardwareentwicklung nach ISO 26262 sind zu planen:

• Die HW-Sicherheitsanforderungsspezifikation und dessen Verifikation
• Hardwaredesign
• Evaluierung der HW-Metriken (SPFM/LFM)
• Evaluierung im Hinblick auf zufällige Hardware-Fehler die ein Sicherheitsziel verletzen können (für jedes Sicherheitsziel).
• HW Integrations- und Testplan

Die Implementierung des Technischen Sicherheitskonzeptes (TSC) in die Hardware sowie dessen Analyse steht im Fokus. Je nach TSC sind HW-Designmerkmale wie Fehlertoleranz und/oder Fehlerbeherrschung zu spezifizieren und umzusetzen. Dabei ist das Zusammenspiel mit hardwarenahen Software-Elementen zu koordinieren. Erst nachdem die Analysen des ersten HW-Designs durchgeführt sind, kann die Spezifikation an Software-Diagnosemechanismen erfolgen. Planen Sie mindestens 3 Iterationen von FME(D)A, SW-Sicherheitsanforderungsspezifikation (z.B. weitere Diagnosen) und HW-Sicherheitsanforderungspezifikation ein.

Spezifikation von HW-Sicherheitsanforderungen nach ISO 26262

Die Hardware-Sicherheitsanforderungsspezifikation sollte folgende Aspekte berücksichtigen:

• interne Diagnosemechanismen, um zufällige HW-Fehlzustände detektieren zu können mit Zeitverhalten & Diagnosedeckung (z.B. Watchdog)
• Fehlertoleranzeigenschaften eines Elements, im Hinblick auf andere Elemente (z.B. Sensor-Supply vs. µC-Supply als CCF-Maßnahme oder SEooC erfordert externen Abschaltpfad)
• Anforderungen, um Anforderungen anderer Elemente umzusetzen (z.B. Verwendung von BIST eines Sensors erfordert zusätzlich neben den Sensordaten auch ein Diagnose-Interface am µC)
• HW-Sicherheitsmechnismen, welche latente Fehler aufdecken können (z.B. Testsignal mit Zeitverhalten bis die Diagnose anspricht)
• Anforderungen bezüglich der Metrik-Zielwerte
• Maßnahmen, um unspezifisches Verhalten zu verhindern (z.B. Dauer-Reset-Schleife)
• Designmaßnahmen an Steckverbindungen und Leitungen
• Testinterface (z.B. für HIL-Tests)

Verifikation der HW-Sicherheitsanforderungsspezifikation

Die Hardware-Sicherheitsanforderungsspezifikation ist gegen das TSC und insbesondere gegen die Systemdesignspezifikation (z.B. Schnittstellen) zu verifizieren. Weiterhin ist auf Vollständigkeit bezogen auf die technische Sicherheitsanforderungsspezifikation sowie auf die Software-Sicherheitsanforderungsspezifikation zu prüfen. Wenn Sie ein SEooC verwenden, haben Sie alle Annahmen im Safety-Manual in Ihrer Spezifikation berücksichtigt ?

Hardware-Sicherheitsanalysen

Eine FTA/FME(D)A ist in der Hardwareentwicklung nach ISO 26262 ab ASIL C vorgeschrieben und sollte gut geplant sein. Zuerst sind mögliche Fehler der Bauteile im Schaltplan zu klassifizieren. Dazu sind Einfachfehler (SPF), Mehrfachfehler (MPF) und sichere Fehler (SF) zu betrachten. Dies ist nicht einfach in einem komplexen Netzwerk der Elektronikbauteile. Daher ist entweder eine Netzwerkanalyse (z.B. Knotenpotentialanalyse) oder ein zerstörerischer Test durchzuführen. Für jedes SG muss eine Analyse aller Bauteile durchgeführt werden. Insofern ist die Anzahl der Sicherheitsziele (SG) für den Analyseaufwand entscheidend. Teils sind auch – abhängig vom Konzept – Mehrfachfehler höherer Ordnung zu betrachten. Mindestens der Ausfall der Sicherheitsmechanismen als latente Fehler zusammen mit den sicherheitsrelevanten Fehler sollte als Mehrfachfehler betrachtet werden. I.d.R. werden diese Sicherheitsmechanismen einmal pro Fahrzyklus (8h) beim Aufstarten (PreOST) oder Herunterfahren (PostOST) getestet. Daher ist Wissen über die verwendeten Bauteile und deren Fehlercharakteristiken notwendig.

Schauen Sie auch in die IEC 61508 Teil 2 (siehe typische Beispielverteilung der Ausfallarten).

In der Hardwareentwicklung nach ISO 26262 steckt der Teufel im Detail!

Wie verhält sich ein Signal in einem Sensorpfad wenn ein Fehler in der Spannungsversorgung vorliegt ? Welche Art von Fehler, welche Diagnosemöglichkeiten, Fehlertoleranzmerkmale und Fehlerisolationsmerkmale sind in der Architektur vorhanden ? Ist das „Power supply rejection Ratio“ des verwendeten Operationsverstärkers hoch genug um einen Signal-Drift, der zu einer Verletzung eines Sicherheitsziels führt, zu verhindern ? Oder ist ein Digitalbaustein an einen Bus hochohmig, wenn seine Versorgungsspannung ausfällt ? Ist genügend Zeit durch Energiekapazität in allen Zuständen eingeplant, um Fehlerdaten in den persistenten Speicher zu laden bei Spannungsschwankungen ? Viele Fragen, die Teils nur durch Testen beantwortet werden können oder durch Erfahrung.

Die Metriken (SPFM, LFM)

Ziel der Hardwaresicherheitsanalysen ist es, die Hardwarearchitektur und die Bauteile noch vor der eigentlichen Hardwareentwicklung nach ISO 26262 zu beurteilen im Hinblick auf Robustheit gegenüber Einfach- und Mehrfachfehler. Dies geschiet durch Metriken, welche auch am Ende die Grundlage zur Berechnung der Ausfallwahrscheinlichkeit (PFH) bzw. die Restfehlerwahrscheinlichkeit bildet.

Dazu sind die Metrik-Zielwerte mit steigendem ASIL [B,C,D] proportional.

• B: SPFM ≥90%, LFM ≥60%, 1000 FIT
• C: SPFM ≥97%, LFM ≥80%, 100 FIT
• D: SPFM ≥99%, LFM ≥90%, 10 FIT

Für ein SG mit ASIL D sind also mindestens 99% der sicherheitsrelevanten Einfachfehler des Systems/Items sicher zu beherrschen und mindestens 90% aller latenten Fehler (z.B. Diagnosefunktion im Betrieb ausgefallen) zu erkennen. Die bestimmungsgemäße Funktion des Items darf nur 10 FIT Restausfallwahrscheinlichkeit haben. Damit wäre eine Rohfehlerrate von ca. 1000 FIT die obere Grenze dessen, was an sicherheitsrelevanten Bauteilen in Summe in der Hardwareentwicklung verwendet werden kann.

Das TSC bestimmt den roten Faden in der Hardwareentwicklung nach ISO 26262

Je nach notwendiger System-Fehlercharakteristik im TSC, ist je Fehlermode eines Bauteils (z.B. Widerstand ist hochohmig, hat Kurzschluss oder hat Drift [50-200% Nominalwert]) zu entscheiden, wie der Fehler sich auswirkt und wie die Fehlereaktion gemäß Sicherheitsziel erfolgen muss. Haben Sie ein System mit Fail-Safe-Charakteristik, müssen Sie den sicheren Zustand (Abschaltung) im Fehlerfall immer erreichen und aufrecht erhalten. Bei Fail-Operational-Systemen sind i.d.R. Energien zum Erhalt des sicheren Zustandes, welcher i.d.R. die bestimmungsgemäße Funktion des Items ist, notwendig. Diese Energien kommen als interne Quelle oder unabhängigen externen Energiequellen oft in mehrkanaligen Systemen zum Einsatz.

Beispiel Fail Safe: Sie haben eine Synchronmaschine (Motor) und das System verliert aufgrund Kurzschluss seine Hauptenergiequelle. Sie müssen genügend Energie zum Abbau der Ankerenergie bereithalten, um unkontrolliertes Bremsen durch Brückenkurzschlüsse in der Leistungstufe (B6-IGBT/MOSFET) hervorgerufen durch Latch-Up-Effekte zu verhindern.

Beispiel Fail Operational: Sie müssen einen Kanal sicher abschalten, um einen anderen Kanal (überdimensioniert) die Übernahme der Funktion vollständig zu gewährleisten.

Nach der Fehleranalyse und der Klassifizierung kommt der Sicherheitsmechnismus (SM)

Haben Sie alle Bauteile mit Ihren eindeutigen IDs (z.B. R15, C12, T1 usw…)  aus dem Schaltplan in die FME(D)A Tabelle eingetragen und deren Roh-Fehlerraten aus den Reliability-Handbook/Standard gemäß dem Betriebsprofil und die Fehlemodi zusammengetragen, so ist es nun erdorderlich den voraussichtlich wirkenden Sicherheitsmechnismus (SM) je Bauteil und Fehlermode zu benennen. Wenn dieser nicht in der Spezifikation auf Systemebene des TSC spezifiziert ist, muss dies nach einer Erstbewertung (FME(D)A-Analyse<->Spezifikation-Iteration) als Spezifikation im Rahmen einer Modifikation in die Entwicklung des nächsten Prototypen (A,B,C Sample) und/oder der nächsten Softwareversion des Items einfließen.

Den Diagnosedeckungsgrad bestimmen

Nun ist der Sicherheitsmechanismus nach seinem Diagnosedeckungsgrad (DC = Diagnostic Coverage) zu bewerten. Dazu sind Kataloge in ISO 26262 Teil 5, Annex D vorhanden, welche die Anforderungen an das Fehlermodell mit steigendem Deckungsgrad auflisten. Wenn Sie die Fehlermodi Drift, Oszillation, Unter-/Überspannung und Spannungsspitzen eines Bauteils erkennen mit einem SM, dann dürfen Sie ein DC von 99% (HIGH) ansetzen. Es sind 3 diskrete Stufen des DCs möglich:

• LOW = 60%
• MEDIUM = 90%
• HIGH = 99%

Dekomposition & Hardwaredesign

Die Dekomposition findet i.d.R. bereits auf funktionaler Ebene im Funktionalen Sicherheitskonzept (FSC) in der Konzeptphase oder auf technischer Ebene im Technischen Sicherheitskonzept (TSC) statt. Je nach Item-/Systemcharakteristik, welche im Kern durch die angewandte Technologie bestimmt wird, sind mehrere „Entwicklungswege“ eines Items möglich. Mit der Dekomposition wird die Struktur der bestimmungsgemäßen Funktion zerlegt, um daraus ein passendes Sicherheitskonzept zu entwickeln. Dies wird folglich als bestimmendes Merkmal in die endgültige Systemarchitektur einfließen.

Ein Beispiel: Sie haben ein Item, welches eine bestimmungsgemäße Funktion ausführt. An der Funktion sind Sensoren, Auswerteinheiten (Logik) und Aktoren beteiligt. Wenn Sie diese Funktion frühzeitig in der Konzeptphase herunterbrechen auf Teilfunktionen und diese dann den Elementen wie Sensoren, Logik und Aktoren zuordnen, können Sie z.B. die Sensoren als ASIL QM(D) und die Logik als ASIL D (D) dekomponieren. Bei Fail-Operational-Anwendungen mit ASIL D ist z.B. die bestimmungsgemäße Funktion zweikanalig auszuführen und dann als Dekomposition nach ASIL D (D) je Kanal zu dekomponieren. Weiterhin haben Sie die Möglichkeit bei Fail-Safe-Charakteristik durch Dekomposition den Funktionskanal als ASIL QM (C) und einen Überwachungskanal als ASIL C (C) auszuführen.

Die Dekomposition ist im weiteren Entwicklungsverlauf ein Redundanzmerkmal, welches enorme Konsequenzen nach sich zieht. Auf Hardwarebene tauchen dann nicht funktionale Sicherheitsanforderungen zur Wechselwirkungsfreiheit und Unabhängigkeit auf. Weitere Auswirkungen finden sich im Feld der Maßmnahmen zur Vermeidung systematischer Fehler. Zum einen ist auf QM-Elemente weniger Entwicklungsaufwand notwendig, zum anderen muss mehr auf systematische Fehlerquellen geachtet werden. Inbesondere bei homogener Redundanz in mehrkanaligen Strukturen ist das Mittel der homogenen Redunanz nicht ausreichend.

Evaluation der Hardware-Metriken (SPFM/LFM)

Ist die Hardwarearchitektur bzw. das Hardwaredesign des Items für das Sicherheitsziel Robust und sind die Sicherheitsmechanismen (SM) in der Lage, Einfachfehler (SPF) latente Fehler (LF) und Restfehler (RF), welche das Sicherheitsziel verletzen, ausreichend zu vermeiden ? Dazu sind eine Reihe von Anforderungen zu prüfen:

• Begründete Verwendung des DCs für SPF und RF („keine Pauschale Ansetzen“)
• Nutzung von anerkannten Fehlerraten-Datenbanken (Reliability-Handbooks/Standards) oder anderen Quellen mit adäquatem Konfidenzniveau
• Argumentation durch zusätzliche SM bei unbekannten Bauteil-Fehlerraten
• Einhaltung der Zielwerte für JEDES Sicherheitsziel (SG)
• Verifikationsbericht für JEDES Sicherheitsziel (SG)

Der Assessor achtet auch auf rechnerische Verzerrungen der Metriken. Wenn Sie z.B. den Anteil sicherer Fehler durch unnötige und am SG unbeteiligte Bauteile künstlich aufblähen, liegt dieser Fall vor.

Ausfallraten und deren Arten (Hard-Error vs Soft-Error)

Bisher wurden nur sogannete Hard-Error-Rates als Fehlerraten erwähnt. Dies sind statische Fehlerbilder, d.h. ihr auftreten ist dauerhaft. Dann gibt es noch die transienten Fehler, welche als sogenannte Soft-Error-Rates bezeichnet werden. Dies sind kurzzeitig und sporadisch auftretende Fehlerbilder. Diese wirken sich nicht immer unmittelbar aus. Die Bewertung findet i.d.R. qualitativ statt und orientiert sich an der verwendeten Technologie. Beispiel: Das Item berechnet einmalig einen Referenzwert, und dabei kommt es zu einem transienten Fehler in der ALU der Recheneinheit. Der Wert wird falsch, aber als gültiges Datum im Speicher als Referenz abgelegt. Wenn nun zeitlich und räumlich mehrfach der Wert berechnet wird und diversitär abgelegt und geprüft wird, ist dieser Fehler beherrschbar.

Evaluation zur Verletzung der Sicherheitsziele

Ziel ist es, ein Evaluationskriterium herzuleiten, um die Verletzung des Sicherheitszieles durch zufällige Hardwarefehler quantitativ zu bewerten. Dabei ist das Risiko durch die Restfehler-Wahrscheinlichkeit mittels der probabilistischen Methoden am Stand der Technik orientiert zu bewerten. Dabei ist die durchschnittliche Ausfallwahrscheinlichkeit pro Stunde, genauer ausgedrückt die mittlere System-Ausfallrate, welche die Verletzung eines Sicherheitszieles ausdrückt, auf die erwartete Betriebsdauer zu berechnen. Dies kann z.B. durch eine quantitative FTA erfolgen. Dabei müssen folgende Aspekte in die Betrachtung einfließen:

• Architektur
• Einfachfehler (SPF) und Restfehler (RF)
• Mehrfachfehler (MPF Latent: mindestens Bauteilfehler plus SM(Diagnose))
• Diagnosedeckungsgrade welche den Restfehler (RF) begründen
• Diagnosedeckungsgrade welche latente Mehrfachfehler (MPF L) begründen
• Einwirkdauer latenter Mehrfachfehlern (von ms bis vollständiger Betriebszeit (Missiontime z.B. 15.000 h))

Bei der probabilistischen Methode sind das Konfidenzniveau der Ausfallraten und die Verteilungsdichtefunktionen der Fehlermodi wichtige Grundfpeiler. Bei der Schätzung zur Ausfallwahrscheinlichkeit (Unzuverlässigkeit) kann für die Verteilung bei zufälligen Systemausfällen mit einer Exponentialverteilung mit konstanter Ausfallrate gerechnet werden. Für komplexere Betrachtungen wie zeitabhängige Ausfallmechanismen oder Lebensdauervorgänge sind i.d.R. Weibullverteilungen anzunehmen.

Bei mehrkanaligen Strukturen sind schnell komplexere Methoden wie Markov-Modelle angebracht. Dabei wird oft der der Fehler gemacht, dass die Markov-Modelle im eingeschwungenden Zustand stationär berechnet werden. Dies führt zu stark optimistischen Ergebnissen. Zur besseren Abbildung der Realität sind jedoch transiente Berechnungen in erweiterten Markov-Modellen aufgrund absorbierender Zustände erforderlich, welche den Rechenaufwand deutlich erhöhen.

Entwicklung des Hardware-Designs

Ziel dieser Phase ist es, das umzusetzen, was auch spezifiziert wurde. Dabei sind jedoch auch eine Reihe von Randbedingungen zu beachten. In der Hardwareentwicklung nach ISO 26262 ist das Feld der elektromagnetischen Verträglichkeit (EMV / EMC) eine wichtige Säule in der Funktionalen Sicherheit. Beachten Sie auch Testinterfaces wie z.B. die Nutzungsmöglichkeit einer Boundary-Scan-Architektur oder echtzeitfähige Schnittstellen bzw. debugging-Interfaces für Fehlerinjektionen auf physikalischer Ebene. Je nach Teststrategie, ist die Leistungsfähigkeit des Testinterfaces im HW-Design für HIL-Testfälle sicherzustellen.

Hardwareintegration und Tests

Ziel ist es die Hardware zu integrieren bis zum vollständigen Item. Gleichzeitig sind Tests durchzuführen. Die Koordination erfolgt nach ISO 26262 Teil 4-5, während die Aktivitäten nach ISO 26262 Teil 8-9 ausgeführt werden. Die Integration udn das Testen erfolgt auf den initialen ASIL des Items. Die Dekomposition entfaltet also keine Wirkung im rechten V-Modell.

Die Testfallherleitung kann ASIL-Abhängig durch Analyse der Anforderungen, Randwertproblemanalyse nach ISO-16750 bzw. ISO11452 erfolgen oder auch die Generation und Analyse von Aquivalenzklassen enthalten. Für den Testnachweis von Sicherheitsmechnismen sind i.d.R. Fault Injection Tests erforderlich, sofern nicht modellbasiert ein Nachweis notwendig ist, aufgrund nicht Testbarkeit. Weiterhin sind z.B. auch EMC und ESD-Tests erforderlich.