ISO 26262 – Road vehicles – Functional safety

ISO 26262 – Road vehicles – Functional safety [1] ist ein internationaler Standard für die funktionale Sicherheit von elektrischen/elektronischen (E/E) Systemen im Kraftfahrzeug​. Die Grundlage dieses Standards ist die Norm: IEC 61508 – Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems [2], adoptiert für die Automobilindustrie.

In den Abschnitten unten werden wir die Inhalte relevant für die System- und Softwareentwicklung von ISO 26262 näher untersuchen.

Falls Sie eine Beratung oder Dienstleistung wünschen, kontaktieren Sie mich gerne:

*1) Um Grafiken zu vergrößern, benutzen Sie die rechte Maustaste und die Option: “Bild in neuem Tab öffnen”.

Für die System- und Softwareentwicklung eines Automotive-Produkts (eines (E/E) Systems) sind besonders die Teile der ISO 26262 interessant:

• Teile: 3, 4 und 6 beinhalten Konzept-, System- und Software-Entwicklungsphasen eines Produkts
• Teile: 8 und 9 beinhalten Unterstützungsprozesse und ASIL-Dekomposition

In diesen Dokumenten kann man Informationen für die entsprechenden Analysen wie HARA, ASIL-Einstufungen, Architekturprinzipien, Verifikationsprinzipien, Nachverfolgbarkeit, Tool-Qualifikation und andere Prozesse mit entsprechenden Arbeitsprodukten finden.

Die Geschichte von ISO 26262 begann in den frühen 2000er, als der Standard 61508 für die ISO 26262-Basis genommen wurde. In weiteren Jahren wurden die Anforderungen aus diesem Standard an die Automotive-Gegebenheiten angepasst.

Seit 2018 gibt es eine umfassende Version des ISO 26262-Dokuments. Aktuell spielt dieses Dokument eine tragende Rolle bei der Entwicklung von Automotive-Produkten.

In dem Text unten kann man eine Zusammenfassung aus dem Standard ISO 26262 (Version 2018) finden, mit Schwerpunkten: System- und Softwareentwicklung in Automotive (fett markiert). Sobald die aktuelle Version dieses Dokuments vorhanden ist, können die Kapitel und Dokumenteninhalte sich unterscheiden.

Hier sind die Teile und kurze Beschreibung aus dem Standard ISO 26262:

ISO 26262 betrachtet die Entwicklung sicherheitsrelevanter Systeme als Sicherheitslebenszyklus, der alle Phasen von der Konzeptfindung bis zur Serienproduktion, Betrieb und Stilllegung umfasst​. Ähnlich wie IEC 61508 nutzt sie ein V-Modell als Referenzprozessmodell für die verschiedenen Entwicklungsebenen​. Dies bedeutet, dass auf jeder Ebene – Fahrzeug/System, Hardware und Software – Entwicklungsphasen (linke V-Seite) und korrespondierende Verifikationsphasen (rechte V-Seite) definiert sind.

Teil 3 der Norm behandelt die Konzeptphase, in der das Item (das zu entwickelnde System) definiert und eine Gefährdungsanalyse durchgeführt wird.

Darauf aufbauend folgen Teil 4 Systementwicklung (inklusive Hardware-Entwurf, Teil 5) und Teil 6 Softwareentwicklung, die aneinander geschachtelte V-Modelle bilden​.

Am Ende des Sicherheitslebenszyklus stehen Produktion, Betrieb, Service und Außerbetriebnahme (Teil 7), in denen ebenfalls Maßnahmen vorgesehen sind, um die funktionale Sicherheit über den gesamten Produktlebenszyklus sicherzustellen.

Während des gesamten Prozesses fordert die Norm definierte Arbeitsergebnisse (z. B. Safety Plan, Anforderungsdokumente, Testberichte) und gibt je nach notwendiger Automotive Safety Integrity Level (ASIL) bestimmte Methoden vor (von „empfohlen“ bis „hoch empfohlen“)​. Wichtig ist, dass der Sicherheitslebenszyklus planmäßig durchlaufen und dokumentiert wird: von der ersten Risikoanalyse über Architektur und Implementation bis zu Verifikation, Validierung und abschließenden Assessments.

Am Anfang der Entwicklung steht die Gefährdungsanalyse und Risikoabschätzung (Hazard Analysis and Risk Assessment, HARA). Dabei werden zunächst alle potenziellen Hazards (Gefährdungen) identifiziert, die durch Fehlfunktionen des betrachteten Systems in bestimmten Situationen entstehen können​.

Für jede identifizierte Gefahr wird das Risiko qualitativ bewertet, basierend auf drei Faktoren: der Schwere des potenziellen Schadens (Severity), der Häufigkeit bzw. Exposition der entsprechenden Fahrsituation (Exposure) und der Beherrschbarkeit (Controllability), also wie gut der Fahrer (oder andere Maßnahmen) die Situation noch kontrollieren könnte​.

Aus der Kombination dieser drei Faktoren ergibt sich eine Einstufung der Gefahr in eine Safety Integrity Level-Klasse. ISO 26262 legt hierfür vordefinierte Tabellen zugrunde, anhand derer jede Hazard-Bewertung auf einem Automotive Safety Integrity Level (ASIL) von A bis D oder auf QM (Quality Management) abgebildet wird​.

ASIL D steht für das höchste Risiko und verlangt die strengsten Sicherheitsmaßnahmen, wohingegen ASIL A geringere Risiken repräsentiert. Ist das Risiko so niedrig, dass spezielle Maßnahmen der Norm nicht erforderlich sind, wird es als QM (kein ASIL, rein durch Qualitätsmanagement abgedeckt) eingestuft​.

Zu bemerken ist, dass die HARA alle möglichen Gefährdungen systematisch abdeckt und für jedes Hazard ein Sicherheitsziel definiert. Ein Safety Goal ist ein oberstes Sicherheitsziel auf Fahrzeugebene, das beschreibt, welcher gefährliche Zustand unter allen Umständen zu vermeiden ist. Dieses Safety Goal erbt die ASIL-Einstufung des zugrundeliegenden Hazards. Damit bildet die HARA die Grundlage für alle weiteren Sicherheitsanforderungen.

Auf dem Bild unten kann man eine HARA-Analyse für einen Punkt (eine Gefährdungssituation) eines Beispiels: Fensterheber-ECUs finden. Zum Dokument gehören viel mehr Informationen, weitere Punkte zur Gefahrsituation-Analyse (alle möglichen Situationen müssen analysiert und bewertet werden). Des Weiteren müssen auch formelle Aspekte, wie Deckblatt mit Angaben zur Dokumentversion, Dokumentautor, Änderungshistorie etc. eingehalten werden.

Das Wesentliche von der Auswertung ist aber auf der Tabelle gezeigt:

Wichtig ist zu beachten, dass die Entscheidungen zum Tabellenbefüllen, insbesondere SEC-Klassifizierung, gut dokumentiert werden. Hier wurde es anhand von Kommentaren gelöst.

Brauchen Sie in Ihrem Projekt eine Unterstützung im Bereich Funktionalen Sicherheit oder HARA, kontaktieren Sie mich gerne:

Aus den Safety Goals werden in der Konzeptphase funktionale Sicherheitsanforderungen abgeleitet, die im funktionalen Sicherheitskonzept (FSC) festgehalten werden. Diese Anforderungen beschreiben auf Systemebene, was das System tun muss, um die Safety Goals zufriedenzustellen – unabhängig von konkreter Umsetzungstechnologie. Anschließend, in der Systementwicklungsphase (Teil 4), erfolgt die Erstellung des technischen Sicherheitskonzepts (TSC). Dabei werden die funktionalen Anforderungen in technische Sicherheitsanforderungen umgesetzt, die konkreter auf Hardware-/Software-Teile des Systems bezogen sind​.

Die technische Ebene legt fest, wie das System die Sicherheitsfunktionen erfüllen wird (z. B. durch Hinzufügen von Fehlererkennungsmechanismen, redundante Auslegung von Komponenten oder Festlegen von sicheren Zuständen). Die TSC-Anforderungen werden auf die jeweiligen Architektur-Elemente (Hardware und Software) gemappt​.

Schließlich werden im Software-Entwicklungsprozess (Teil 6) daraus die Software-Sicherheitsanforderungen abgeleitet, welche die notwendigen Sicherheitsfunktionen und -mechanismen auf Software-Ebene definieren (z. B. Überwachungsroutinen, Plausibilitätsprüfungen in der Software). ISO 26262 verlangt, dass die ASIL-Einstufung in die abgeleiteten Anforderungen vererbt wird​.

Das heißt, ohne spezielle Maßnahmen (siehe ASIL-Dekomposition unten) behalten untergeordnete Anforderungen zunächst den ASIL des übergeordneten Safety Goals. Jede Ebene der Anforderungen muss dokumentiert und mit den anderen verknüpft werden (Stichwort Traceability, siehe unten), sodass nachweisbar ist, dass alle identifizierten Gefahren durch entsprechende Anforderungen und Maßnahmen bis hinunter zur Implementierung abgedeckt sind​.

Letztlich bildet diese Hierarchie an Sicherheitsanforderungen das Rückgrat der funktionalen Sicherheit: Sie stellt sicher, dass vom Gesamtfahrzeug bis zur Code-Ebene alle sicherheitsrelevanten Aspekte berücksichtigt werden.

Die Automotive Safety Integrity Level (ASIL)-Einstufung (A, B, C, D) einer Funktion bestimmt maßgeblich die Strenge der anzuwendenden Entwicklungsprozesse und Methoden. ASIL D ist dabei die höchste Kritikalität und stellt die strengsten Anforderungen, während ASIL A die geringsten zusätzlichen Anforderungen bedeutet (alles unterhalb ASIL A wird als QM rein durch normales Qualitätsmanagement abgedeckt)​.

So fordert die Norm beispielsweise ab höheren ASIL vermehrt empfohlene Maßnahmen zur Fehlervermeidung und -entdeckung. Für ASIL D sind viele Methoden als hoch empfohlen eingestuft, wohingegen für ASIL A einige als optional gelten​.

Konkret heißt es, mit höherem ASIL steigt der Dokumentationsaufwand, die Tiefe der durchzuführenden Analysen und Tests sowie die erforderliche Unabhängigkeit bei Prüfungen. Ein einfaches Beispiel: Zur Vermeidung systematischer Fehler (z. B. Software-Bugs) schlägt die Norm je nach ASIL unterschiedliche Verifikationsmethoden vor – bei ASIL D etwa strenge Reviews, formale Modellprüfungen oder statistische Tests, bei ASIL A genügen unter Umständen einfachere Maßnahmen​.

Für als QM eingestufte Elemente gibt die Norm keine spezifischen FuSi-Maßnahmen vor, hier greift lediglich das allgemeine Qualitätsmanagement des Herstellers​.

Ein besonderer Mechanismus der ISO 26262 ist die ASIL-Dekomposition (beschrieben in Teil 9 der Norm). Darunter versteht man die Aufteilung einer hochkritischen Funktion in mehrere unabhängige Teilfunktionen oder Komponenten, um deren individuelle ASIL-Einstufung zu verringern​.

Beispielsweise könnte ein Safety Goal, das eigentlich ASIL D erfordert, auf zwei redundante Teilsysteme verteilt werden, die jeweils nur ASIL B erfüllen müssen – sofern garantiert ist, dass diese Teilsysteme wirklich unabhängig voneinander wirken (keine gemeinsamen Ursachen für Ausfälle) und gemeinsam das ursprüngliche Sicherheitsziel erfüllen. ISO 26262 gibt hierfür strikte Regeln vor: Die Aufteilung (Dekomposition) ist nur zulässig, wenn die Komponenten ausreichend voneinander entkoppelt sind und abhängige Ausfälle beherrscht werden​.

In Teil 9 werden Dependent Failure Analysen gefordert, um sicherzustellen, dass weder kaskadierende Fehler (Ausfall einer Komponente führt zu Folgefehlern in der nächsten​ noch Common Cause-Fehler (gemeinsame Ursache legt beide redundanten Stränge lahm) das Gesamtsystem kompromittieren​.

ASIL-Dekomposition beeinflusst die Architektur und kann Entwicklungskosten senken, da Teilkomponenten mit niedrigerem ASIL oft mit weniger Aufwand entwickelt und getestet werden können. Allerdings muss der Nachweis geführt werden, dass die Voraussetzungen (Unabhängigkeit, Fehlerausschluss gemeinsamer Ursachen) erfüllt sind. Insgesamt gilt: je höher der erforderliche ASIL, desto mehr Rigorosität in Prozessen, Methoden und Bestätigungsmaßnahmen verlangt die Norm, um ein angemessenes Sicherheitsniveau nachweislich zu erreichen.

Beispiel: Verschiedene Fahrzeugsysteme und deren typische ASIL-Einstufungen. Hochkritische Funktionen wie Lenkung, Bremse oder Antriebssteuerung werden meist als ASIL D eingestuft, während weniger sicherheitsrelevante Systeme (z. B. Fensterheber, Klima) oft nur QM oder ASIL A erreichen. Die ASIL-Einstufung bestimmt die Strenge der anzuwendenden Entwicklungs- und Absicherungsmaßnahmen.

Während der Systementwicklungsphase (ISO 26262 – Teil 4) wird aus dem funktionalen Sicherheitskonzept (FSC) ein Systemdesign für die Sicherheitsanforderungen entwickelt (TSC).

In der Liste unten sind spezielle Designprinzipien aufgelistet, welche zum Einsatz kommen können. Dazu zählen zum Beispiel:

• Redundanzen:
  • kritische Funktionen werden doppelt ausgeführt, um Ausfälle auffangen zu können
• Fehlererkennung und -behandlung:
  • z. B. Plausibilitätsprüfungen, Selbsttests, Watchdog-Überwachung
• fehlertolerante Zustände:
  • Festlegen eines sicheren Zustands, in den das System bei erkannter Störung übergeht, etwa Notlauf oder Abschaltung, sowie
• Aufteilung in unabhängige Kanäle:
  • um Fehlerausbreitung zu verhindern, siehe ASIL-Dekomposition oben

Das technische Sicherheitskonzept beschreibt, wie diese Mechanismen im System umgesetzt werden, und spezifiziert Schnittstellen zwischen Hardware und Software (Hardware-Software-Interface Spezifikation), damit klar ist, welche Sicherheitsfunktion von welcher Domäne übernommen wird​.

Die Systemarchitektur wird iterativ durch Sicherheitsanalysen überprüft. ISO 26262 verlangt, dass bewährte Analyseverfahren, wie FMEA (Failure Mode and Effects Analysis) oder FTA (Fault Tree Analysis) auf Systemebene angewendet werden, um zu verifizieren, dass die geplante Architektur die Sicherheitsanforderungen erfüllt​.

Ein wesentliches Element ist außerdem die Berücksichtigung von zeitlichen Anforderungen (z. B. Fehlertoleranzzeitintervalle – innerhalb welcher Zeit ein Fehler erkannt und gemindert werden muss) und von Leistungsbegrenzungen (etwa Notbremsen in X ms).

Durch diese Analysen können potenzielle Schwachstellen oder einzelne Fehlerfälle identifiziert werden, die das Sicherheitsziel gefährden könnten. Diese Schwachstellen (Gefährdungen) sollen in der Architektur (und Anforderungen) entsprechend angepasst werden (z. B. zusätzliche Diagnose-Möglichkeiten einbauen, Komponenten anpassen). Dieser Vorgang wird so lange wiederholt, bis alle Sicherheitslücken abgedeckt sind​.

Ein Spezialthema im Kontext der Systemarchitektur ist die Einbeziehung von Halbleiter-Komponenten (Mikrocontroller, ASICs etc.), da moderne Fahrzeuge oft komplexe SoCs mit mehreren integrierten Funktionen verwenden. Teil 11 der ISO 26262-Norm (nur als Leitfaden, nicht normativ) liefert hierzu Hinweise für Halbleiterhersteller, wie sie ihre Komponenten als Safety Element out of Context (SEooC) entwickeln können (sollen)​.

Wenn ein solches Bauteil in einem eigenen Produkt verwendet wird, sollte vom Chip-Hersteller ein Safety Manual verlangt werden. Dieses Safety Manual beschreibt, bis zu welchem ASIL die Komponente verwendet werden kann und welche Betriebsbedingungen bzw. Annahmen für den sicheren Einsatz gelten.

Dort sind unterschiedliche Maßnahmen für die Funktionale Sicherheit: z. B. bestimmte Selbsttests des Mikrochips, Einschränkungen, Diagnose-Möglichkeiten etc. vorhanden.

Insgesamt stellt das technische Sicherheitskonzept sicher, dass die abstrakten Sicherheitsanforderungen in eine realisierbare technische Lösung überführt werden.

Der Softwareentwicklungsprozess und die Arbeitsprodukte für ein sicherheitsrelevantes Automotive-Produkt sind in ISO 26262 – Teil 6 beschrieben. Als Erstes werden aus den technischen Sicherheitsanforderungen die Software-Sicherheitsanforderungen spezifiziert. Sie beinhalten die Information, welche Sicherheitsfunktionen implementiert werden sollen und welche Sicherheitsmechanismen auf der Softwareebene nötig sind. Aus diesen Sicherheitsanforderungen wird die Softwarearchitektur abgeleitet.

Wichtig bei der Entwicklung der Softwarearchitektur, spezielle Designrichtlinien beizubehalten. Eine von den wichtigsten ist das Freedom from Interference (FFI) Prinzip. Das Prinzip besagt, dass die sicherheitskritische Software von der nicht sicherheitskritischen Software nicht beeinflusst werden soll (etwa durch getrennte Laufzeiten oder Speicherschutzmechanismen).

In der Implementierungsphase werden die Software-Einheiten gemäß dieser Architektur entwickelt. ISO 26262 fordert hierbei den neuesten Stand der Programmiertechniken und -richtlinien. Beispielsweise wird für ASIL-relevante Software nahezu immer die Einhaltung von Codestandards wie MISRA-C/C++ empfohlen, um typische Programmierfehler zu vermeiden.

Weiterhin sollen dynamische Eigenschaften wie Speicherbedarf und Zeitverhalten analysiert werden, um sicherzustellen, dass die Software im vorgesehenen Betrieb sicher funktioniert (keine Überläufe, keine unkontrollierten Zeitzustandsänderungen etc.). Werkzeuge wie Compiler, Code-Generatoren oder modellbasierte Entwicklungsumgebungen, die in der Softwareentwicklung verwendet werden, müssen ggf. qualifiziert werden (siehe unten: Tool-Qualifikation).

Nach dem Coding erfolgen Modultests (Unit-Tests), um jede Software-Einheit auf korrekte Funktion zu prüfen. Hierbei werden abhängig vom ASIL verschiedene Testmethoden und strenge Maßstäbe angesetzt – etwa erfordert ASIL D typischerweise strukturierte Tests mit hohem Codeabdeckungsgrad (z. B. MC/DC – Modified Condition/Decision Coverage)​, während bei ASIL A funktionale Tests mit geringerem Abdeckungsgrad ausreichend sein können.

Es folgt die Software-Integration, bei der die Module zusammengeführt und Schnittstellen getestet werden (Integrationstests). Schließlich wird die vollständige Software gegen die Software-Anforderungen verifiziert (Software-Qualifikationstest). Diese Schritte entsprechen der rechten Seite des V-Modells auf Software-Ebene: Jede Entwurfsstufe wird durch entsprechende Teststufen abgesichert, um sicherzustellen, dass die implementierte Software die spezifizierten Anforderungen korrekt erfüllt.

Auf jeder Ebene der Softwareentwicklung verlangt ISO 26262 auch Verifikationsaktivitäten neben dem Testen, z. B. Reviews des Codes und der Designs durch unabhängige Kollegen (Vier-Augen-Prinzip)​ sowie statische Analysen. Insbesondere sollten Softwarearchitektur und -anforderungen bereits vor der Umsetzung geprüft werden, um Fehler frühzeitig zu erkennen (Verifikation-Reviews). Dadurch sollen systematische Fehler in der Softwareentwicklung – die bei sicherheitsrelevanter Software kritisch sind – so weit wie möglich vermieden bzw. früh entdeckt werden.

Die Norm ISO 26262 verlangt eine lückenlose Rückverfolgbarkeit (Traceability) aller sicherheitsrelevanten Anforderungen und Artefakte. Angefangen bei der Rückverfolgbarkeit der Anforderungen auf der System-Ebene (HARA): Jedes Safety Goal sollte zu verknüpften funktionalen (FSC) und technischen Sicherheitsanforderungen (TSC) führen, weiter zu Software-/Hardware-Anforderungen, zu Design-Elementen und schließlich zu Testfällen, welche die Implementierung verifizieren.

In jeder Entwicklungsebene (SYS, SW) muss erkennbar sein, welches vorheriges Element aus anderer Entwicklungsebene diese Ebene adressiert. Beispielsweise muss man aus einem Testergebnis zurückschließen können, welche Anforderung damit verifiziert wurde, und umgekehrt von einer Anforderung sehen können, in welchem Test sie geprüft wird​.

Die Sicherheitsanalysen und Architekturelemente sollen ebenfalls nachvollziehbar verknüpft sein. Dies ermöglicht im Fehlerfall oder bei einer Änderung eine Auswirkungsanalyse: Wenn sich eine Anforderung ändert oder ein Fehler festgestellt wird, kann man durch die Traceability sofort alle abhängigen Artefakte (Design, Code, Tests) identifizieren, überprüfen und gegebenenfalls anpassen.

In der Praxis werden dafür Requirements-Management-Tools eingesetzt (z. B. DOORS, Polarion, Jama etc.), die die Vernetzung der Anforderungen und Artefakte handhaben. Traceability ist der Schlüssel zum Nachweis der Normkonformität, da ein Safety Case zeigen muss, dass alle identifizierten Risiken durch Anforderungen mitigiert und getestet sind. Ferner verlangt ISO 26262 auch die Nachverfolgbarkeit der Konfigurationen (Versionen) – was das Konfigurationsmanagement behandelt.

In modernen Entwicklungsprozessen kommen vielfältige Software-Tools zum Einsatz (z. B. zur Anforderungspflege, Modellierung, Codegenerierung, Testautomatisierung). ISO 26262 Teil 8 fordert eine Bewertung und ggf. Qualifizierung der Werkzeuge, sofern deren Fehlfunktion die Sicherheit des Endprodukts beeinflussen könnte.

Man muss also einschätzen, ob ein Tool durch einen versteckten Fehler systematische Fehler ins Produkt einbringen oder solche Fehler übersehen könnte​. Ein Beispiel dafür: Ein automatischer Code-Generator, der fehlerhaften Code erzeugt, kann einen systematischen Fehler in allen Produkten einbringen. Ebenso könnte ein Test-Tool, das falsche Testergebnisse liefert, und einen Fehler unerkannt lassen.

Für solche Tools definiert ISO 26262 den Tool Confidence Level (TCL) basierend auf der möglichen Auswirkung und Verwendung. Je nach TCL-Auswertung sind Maßnahmen zur Qualifizierung erforderlich. Dies können z. B. zusätzliche Tests des Tools sein, ein zertifizierter Entwicklungsprozess des Toolherstellers oder redundante Prüfungen der Tool-Ergebnisse.

Das Ziel ist, ausreichendes Vertrauen zu gewinnen, dass das Tool zuverlässig arbeitet bzw. Fehler keine Sicherheitslücken verursachen. In der Praxis z. B. ist der Compiler in der Regel nicht aufwendig qualifiziert, da die Tests die Compilerfehler meistens aufdecken (TCL niedrig). Hingegen bei einem Modellgenerator für ASIL D Software wird man eine formale Qualifikation durchführen oder auf bereits vom Hersteller qualifizierte Tools zurückgreifen. ISO 26262 gibt hier einen Leitfaden, um systematisch zu entscheiden, welche Tools eine Qualifizierung abschließen müssen und in welchem Umfang. Letztlich stellt die Werkzeugqualifikation sicher, dass die Entwicklungswerkzeuge selbst nicht zur Achillesferse der Sicherheitsstrategie werden.

In dem Artikel: ISO 26262 – Tool Validierung ist beschrieben, wie die Vorgehensweise für eine Tool-Validierung aussehen kann.

In diesem Abschnitt kann man die Links auf die wichtigen praxisorientierten Beispiele für die Arbeitsprodukte aus ISO 26262 untersuchen:

• Systemarchitektur (in Praxis)
• (Teil-)Ausschnitt aus TSC für Fensterheber-ECU
• (Teil-)Ausschnitt aus Safety Analysis and Analysis of Dependent Failures at SW-level für Fensterheber-ECU
• ISO 26262 – Safety Measures (Sicherheitsmaßnahmen)