ISO 26262

Ablauf in der Entwicklung

(Normbegriffe durch 'Apostrophe’ hervorgehoben)

Eine (Neu-)Entwicklung nach und mit der ISO 26262 lässt sich grob in folgenden Schritten beschreiben:

1. Das Produkt respektive 'Item' wird definiert und zweckmäßig von anderen Systemen abgegrenzt, Voranalysen zum Gefährdungspotential bei Fehlfunktion dieses Items (unkritische Items wie beispielsweise Klimasteuergerät werden nicht weiter betrachtet)
2. Definition von Sicherheitszielen ('safety goals') für das Item, die den Versagensmodus reflektieren, z. B. für ESP „Das abrupte Anfahren des Fahrzeugs muss vermieden werden.“, oder für Abblendlicht „Eine ungewollte Deaktivierung des Abblendlichtes auf beiden Seiten muss verhindert werden.“
3. Gefahr- und Risikoanalyse ('HARA'), drei Faktoren - Ausgesetztsein oder Wahrscheinlichkeit ('E0'-'E4') und Kontrollierbarkeit ('C0'-'C3') einer individuellen Fahrsituation, das Schadensausmaß ('S0'-'S3') - gehen in eine quantitative Bestimmung mit ein, exemplarisch:
   1. keine oder nur sehr geringe Gefahren, die ohne Anwendung der Norm auskommt und nur ein Fall für das Qualitätsmanagement ('QM') sind, beispielsweise ein einseitiger Ausfall des Abblendlichts auf der Straße innerorts, der vom Fahrer voll kontrollierbar ist (es wird unterstellt, dass dieser die Möglichkeit hat, schnell an die Seite zu fahren, ein 'C0' führt automatisch zu 'QM')
   2. ASIL ('Automotive Safety Integrity Level’) Einstufung A bis D, für die die Norm anzuwenden ist, beispielsweise ein beidseitiger Ausfall des Abblendlichts, der bei Nacht auf der Autobahn sehr gefährlich wäre. ASIL D ist hierbei das höchstmögliche Level, bedingt sehr aufwändige Maßnahmen und wird normalerweise nur angewandt bei höchst kritischen Fahrzeugbestandteilen wie Lenkung oder Bremsen.
4. Funktionsarchitektur unter Berücksichtigung der Sicherheitsanforderungen festlegen, ggf. mit Hilfe von Methodiken wie FMEA oder FTA
5. Systemarchitektur festlegen, welche die gewählte technische Umsetzung widerspiegelt; die ASIL-Einstufung für kritische Fahrsituationen (d. h. das Sicherheitsziel) propagiert sich mit genannten Schritten im V-Modell immer weiter „nach unten“ bis hin zur 'software unit' und kann unter Umständen durch Dekomposition und Einbringung von Redundanzen herabgestuft werden.

Nicht alle von der Norm empfohlenen Methoden müssen bei der Entwicklung eines Produktes angewendet werden und nicht alle geforderten Arbeitsprodukte müssen in der Form erstellt werden. Es gilt die Prämisse, die Norm an die eigene Organisation anzupassen, jedoch nicht die gesamte Organisation an die Norm. Im Produkthaftungsfall gilt aber die Norm als Untergrenze des Stands der Technik (siehe weiter unten).

Maßnahmen

Damit sich bei der Entwicklung keine Fehler einschleichen, setzt die Norm bei der Entwicklung der Komponenten an:

• Risiken werden nach ihrer Bedeutung bewertet, an deren Ende eine ASIL-Einstufung steht. Ziel ist die Minimierung der Risiken eines Fahrzeugs oder einer seiner Komponenten auf ein „gesellschaftlich akzeptiertes Maß“.
• Zur Vermeidung systematischer Fehler werden unterschiedliche Methoden vorgeschlagen. Die Empfehlungen hängen vom ASIL ab, mit höherem ASIL steigen die Anforderungen. Für Risiken, die mit QM bewertet wurden, schlägt die Norm keine eigenen Maßnahmen vor, sondern verweist auf die Maßnahmen, die durch das Qualitätsmanagementsystem des entwickelnden Unternehmens bereits vorgegeben sind. Liegt ein systematischer Fehler vor, ist dieser in allen Produkten vorhanden. So sind beispielsweise Softwarefehler stets systematische Fehler, ebenso wie Konstruktionsfehler.
• Zur Vermeidung zufälliger Fehler erwartet die Norm ab ASIL B eine quantitative Bewertung der elektronischen Komponenten (Hardware). Dabei wird das Produkt nach Ausfallwahrscheinlichkeit, Ausfallart und Umgebungsbedingungen mit einer Failure modes, effects, and diagnostic analysis (FMEDA, nach Teil 5, Annex D der Norm) oder einer Fehlerbaumanalyse untersucht. Aus dieser Untersuchung werden Diagnosen abgeleitet, die gefährliche Zustände rechtzeitig erkennen und verhindern sollen – beispielsweise durch eine Selbstabschaltung des Produktes oder durch frühzeitige Warnung.

Abgrenzung

Die ISO hat die Sicherheit im Sinne der Eigensicherheit (Schutz der Umwelt vor dem Produkt) im Fokus, daher funktionale Sicherheit. Die „normale“ Funktion kann dabei durchaus im Sinne der Sicherheit eingeschränkt oder auch abgeschaltet werden (Systemreaktion).

Es reicht dabei nicht aus, dass die Funktion korrekt ausgeführt wird, sondern Ziel der Entwicklung muss auch sein, dass sie im richtigen Kontext ausgeführt wird bzw. nicht in der falschen Situation ausgeführt wird. Löst beispielsweise der Airbag in einer Unfallsituation aus, ist die Funktion einwandfrei. Löst er dagegen bei normaler Fahrt aus, mag die Funktion an sich einwandfrei sein. Das Auslösen führt jedoch zu einer Gefährdung der Insassen und in der Folge ggf. auch zur Gefährdung anderer Verkehrsteilnehmer, da der Fahrer das Fahrzeug nicht mehr kontrollieren kann.

Die ISO ist daher als Richtlinie für die Absicherung speziell in der Funktion zu sehen. Umfang der Absicherung von Risiko und Beherrschbarkeit hängt von der Fehlfunktion ab und wird nach den Kriterien in Teil 3 (siehe unten) bestimmt.

Fokus der Norm:

• Die Entwicklung von Kraftfahrzeugen aus Serienproduktion und dort speziell auf elektrische, elektronische und programmierbare Komponenten.
• Die ISO betrifft sowohl das Fahrzeug als Ganzes, wie auch Komponenten von Zulieferern. Die Norm unterscheidet bei den Methodenempfehlungen nicht zwischen Zulieferern und Kraftfahrzeugherstellern (OEMs).

Andere Punkte schließt die Norm von einer Betrachtung aus:

• Was nicht zur spezifizierten Funktion gehört, ist nicht im Fokus der Norm. So ist die Gefahr von Verbrennungen am Motor nicht Teil der Funktion (Hitzeentwicklung am Motorblock oder Auspuff ist keine Motorfunktion, sondern „Abfallprodukt“). Die Risikominimierung bei nicht-funktionalen Gefahren ist Teil der allgemeinen Produktsicherheit und bleibt Aufgabe jedes Herstellers, aber die Maßnahmen der ISO 26262 müssen dazu nicht herangezogen werden.

Gegenbeispiel: Hauptfunktion einer Sitzheizung ist die Erwärmung, daher wären Verbrennungen Folge eines Fehlers in der Hauptfunktion.

• Für mechanische, hydraulische und pneumatische Komponenten schlägt die Norm keine Methoden vor.
• Cyber Security, also Schutz des Produktes vor der Umwelt, wird in ISO/SAE 21434, SAE J3061 und UNECE R 155 behandelt.
• SOTIF (safety of the intended functionality) im Sinne der ISO 21448, legt den Fokus auf vorhersehbaren Fehlgebrauch durch den Fahrer sowie auf Unfälle, die ausdrücklich nicht durch Komponentenversagen, sondern aufgrund von unerwarteten und in der Entwicklung nicht geplanten Betriebssituationen hervorgerufen werden.

Rechtliche Verbindlichkeit

Derzeit (Stand Januar 2025) gibt es keine gesetzliche Pflicht zur Anwendung der ISO 26262, sie gilt jedoch als Stand der Technik. Da nach der Norm auch zugelieferte Komponenten berücksichtigt werden müssen, verlangen in der Praxis fast alle Automobilhersteller von ihren Zulieferern die Anwendung in neuen Projekten, um für Aufträge nominiert zu werden, so dass sich die Norm durch die gesamte Zulieferkette zieht.

Neben der Reduktion von Risiken ist ein weiterer Zweck der Norm, im Falle eines Produkthaftungs-Prozesses die Grundlage für den Nachweis einer sorgfältigen Entwicklung zu schaffen. Dies ist besonders deshalb erforderlich, weil im Produkthaftungsfall der geschädigte Endverbraucher die Beweislastumkehr in Anspruch nehmen kann, d. h. der Endverbraucher weist den Eintritt eines Schadenereignisses nach und der Hersteller bzw. Inverkehrbringer muss nun eine sorgfältige Entwicklung nachweisen und darstellen, dass „…der Fehler nach dem Stand der Wissenschaft und Technik in dem Zeitpunkt, in dem der Hersteller das Produkt in den Verkehr brachte, nicht erkannt werden konnte“.

Die Verpflichtung des Herstellers auf den Stand von Wissenschaft und Technik wurde vom Bundesgerichtshof im Airbag-Urteil festgestellt. Da die ISO 26262 sich aufgrund der eigenen Definition der Entwicklung sicherheitsrelevanter Komponenten dient, lässt demnach eine ASIL-Einstufung im Entwicklungsprozess keinen Rückgriff auf den Stand der Technik oder die allgemein anerkannten Regeln der Technik zu. Die Definition dessen, was Stand von Wissenschaft und Technik bedeutet, hat das Bundesverfassungsgericht im Kalkar-Urteil dargelegt. Da die Produkthaftung in den EU-Staaten auf der Richtlinie (EU) 2024/2853 (EU-Produkthaftungsrichtlinie) beruht, bestehen auch in anderen Mitgliedsstaaten ähnliche Regelungen wie in Deutschland.

Part 1: Vocabulary

Teil 1 erklärt die Begriffe (Abschnitt 3) und Abkürzungen (Abschnitt 4), die in der Normenreihe verwendet werden.

Part 2: Management of functional safety

Teil 2 beinhaltet die geforderten Managementtätigkeiten während der unterschiedlichen Phasen des Sicherheitslebenszyklus eines Produktes, das E/E (elektrische/elektronische) Systeme beinhaltet. Des Weiteren werden die organisatorischen Voraussetzungen genannt, die erfüllt sein müssen, damit das zu entwickelnde System gemäß dem geforderten ASIL ('automotive safety integrity level’) entwickelt werden kann. Auf das Bewusstsein einer Sicherheitskultur wird gesondert eingegangen.

Part 3: Concept phase

Teil 3 enthält Anforderungen bezüglich der Durchführung einer Gefährdungsanalyse und Risikoabschätzung ('hazard analysis and risk assessment’ oder 'HARA'). Dazu müssen zunächst die potentiellen Gefährdungen ('hazards’) des Systems identifiziert werden. Dies geschieht durch Betrachtung möglicher Fehlfunktionen des untersuchten Systems in spezifischen Fahrsituationen, die als gefährlich erachtet werden.

In einem weiteren Schritt wird für jede identifizierte Gefährdung einzeln die Schwere der Auswirkung ('severity’ – 'S’), die Häufigkeit der Fahrsituation ('exposure’ – 'E’) und die Beherrschbarkeit der Fehlfunktion in der jeweiligen Fahrsituation z. B. durch den Fahrer ('controllability’ – 'C’) mittels Codebooks und Erfahrungswerten abgeschätzt (z. B. E-Parameter nach VDA 702). Daraus ergibt sich die Sicherheitsanforderungsstufe, die von ASIL A (niedrigste Einstufung) bis ASIL D (höchste Einstufung) klassifiziert. Die Sicherheitsanforderungsstufe bzw. der ASIL erfordern im Weiteren zusätzliche Maßnahmen in der Entwicklung, sie vererben sich immer weiter „nach unten“ im V-Modell bis hin zur kleinsten Einheit die die ISO kennt, der 'software unit' (s. Teil 6 der ISO 26262), d. h. solange keine Dekomposition stattfindet (s. Teil 9 der ISO 26262). Aus dem Arbeitsprodukt 'HARA' leiten sich die 'safety goals' (Sicherheitsziele) ab, aus welchen die Sicherheitsanforderungen formuliert werden. Ist das Risiko so gering, dass die Anwendung der Norm nicht erforderlich ist, wird es dem QM ('quality management') zugeordnet. Anders als zum Beispiel in der IEC 61508 geschieht die Risikoanalyse in der ISO 26262 mittels einer festgelegten, qualitativen Methodik.

Part 4–6: System, Hardware, Software

Die Teile 4, 5 und 6 behandeln die technischen Entwicklungsprozesse auf Systemebene, Hardwareebene und Softwareebene in Anlehnung an geschachtelte V-Modelle und definieren für die einzelnen Abschnitte Vorgehensweisen und Arbeitsergebnisse ('work products’). Diese Teile gehen insbesondere auf Architekturentscheidungen ein, für welche die Sicherheitsanforderungen allokiert werden, die Vorgehensweise ist formaler und nicht mehr so abstrakt im Unterschied zu den vorangegangenen Teilen der Norm. Teil 4 gibt unter anderem Vorgaben für die Spezifikation eines HSI oder Hardware-Software-Interface und kann als Überbau zu den Teilen 5 und 6 verstanden werden.

Für die umzusetzenden Anforderungen werden Methoden aufgelistet, die je nach ASIL als no recommendation for or against its usage, recommended (empfohlen) oder highly recommended (stark empfohlen) eingestuft werden. Es können jedoch auch andere, nicht genannte Methoden verwendet werden, wenn deren Wirksamkeit zur Erfüllung der jeweiligen Anforderung begründet werden kann. Besitzt eine Komponente keine Software, wie Relais, Nockenschaltwerke, ASICs und andere nicht-Software-programmierbare Bausteine, sind diese immer noch im Fokus der ISO 26262 Teile 4 und 5, sofern sie an sicherheitsrelevanten Funktionen beteiligt sind.

Die Software lässt sich für 'stand-alone tests' als Ganzes sinnvoll bis zur 'software unit' zerlegen. Für die Hardware fehlt ein entsprechendes Äquivalent da 'stand-alone tests' für 'hardware parts' oder 'subparts' (die Norm gibt hier als Beispiele ALU oder Flipflops) aus Safety Sicht nicht zielführend sind. Hier würde schnell jeder statistische Rahmen gesprengt (die Prämisse lautet, Hardwarefehler sind grundsätzlich statistischer, Softwarefehler sind immer systematischer Natur), meist wird daher generisch von 'hardware elements' gesprochen, was Teile oder ganze Systeme von Hardware umfassen kann und die in der Praxis als komplette Baugruppen qualifiziert werden, da nur Lieferanten und Unterlieferanten Statistiken zu Fehlerraten und dergleichen besitzen. Diese müssen sich ihrerseits wiederum an der Norm orientieren, und ihre Hardware-Architekturen zum Beispiel mit Methoden wie FMEA oder FTA absichern.

Ein zentraler Begriff für die Absicherung von Hardware ist 'Failures In Time', abgekürzt 'FIT' - die Definition der Norm für FIT lautet ein Ausfall in einer Milliarde (10^9) Betriebsstunden (oder äquivalent 10^(-9) Ausfälle je Betriebsstunde).

Part 7: Production, operation, service and decommissioning

Teil 7 beinhaltet das prinzipielle Vorgehen beim Erstellen eines Produktions- und Kontrollplans für sicherheitsrelevante Systeme, um die Anforderungen an die Funktionale Sicherheit beim Produktionsprozess sicherzustellen. Weiterhin werden Anforderungen für Betrieb, Wartung, Reparatur und die Stilllegung gestellt, welche Schädigung von Personen vermeiden sollen. Beispielsweise müssen Hochvolt-Komponenten bei der Reparatur oder Airbags und Gurtstraffer wegen der Explosivstoffe beim Ausbau zwecks Verschrottung berücksichtigt werden.

Viele Bereiche der ISO 26262-7 werden bereits durch ein QMS nach IATF 16949 abgedeckt. Beispiel ISO 26262-7:2018 5.1 a Anmerkung: „...abgedeckt durch Konformitätsnachweis IATF 16949...“. Konformitätsnachweis meint eine Zertifizierung des QMS.

Part 8: Supporting processes

Hinweis: Der Zusatz im Sinne der Norm weist darauf hin, dass manche Begriffe in diesem Teil von der Norm nicht ganz so verstanden werden, wie es in allgemein gehaltenen Definitionen üblich ist. Daher wurde auf Interwiki-Links verzichtet.

Teil 8 beschreibt unterstützende Prozesse, die zwar nicht für die Funktionale Sicherheit entwickelt wurden, die aber im Hinblick auf die Funktionale Sicherheit besonders ergänzt oder berücksichtigt werden sollen. Dazu gehören insbesondere:

• Das 'Development Interface Agreement’, eine spezielle Leistungsschnittstellenvereinbarung für die Aktivitäten der Funktionalen Sicherheit zwischen verschiedenen Interessengruppen, insbesondere zwischen Kunde und Lieferant.
• Das Anforderungsmanagement bezogen auf sicherheitsrelevante Anforderungen. Hier wird die Notation von Anforderungen und die Vererbung des ASIL von Anforderungen auf abgeleitete Anforderungen beschrieben
• Konfigurationsmanagement, also die Nachverfolgbarkeit der verschiedenen Entwicklungsstände des Produkts und was man wann und womit dem Kunden ausgeliefert hat.
• Das Änderungsmanagement im Sinne der Norm verlangt, dass Änderungen strukturiert und nachverfolgbar in die Entwicklungsarbeit einfließen müssen. Die Ursache für Änderungen können erkannte Probleme oder Änderungswünsche des Kunden sein. Wegen der vielen beteiligten Personen ist eine strukturierte und nachverfolgbare Bearbeitung von Produkt- und Spezifikationsänderungen, die Wiederholung von Tests sowie die Überarbeitung von Arbeitsprodukten erforderlich.
• Bei der Verifikation sollen Arbeitsprodukte ('work products’) überprüft werden, so dass eventuelle Fehler früh erkannt werden. Die einfachste Form ist das Vier-Augen-Prinzip.
• Für das Dokumentenmanagement im Sinne der Norm sollen Aufbau und Ablage von Dokumenten geplant und dokumentiert werden
• Bei Software-Werkzeugen („Tools“), also Programmen, die an der Produktentwicklung beteiligt sind, aber als Software nicht selbst im Fahrzeug mitfahren, soll das Vertrauen, welches man ihnen für die einwandfreie Produktentwicklung entgegenbringen kann, bestimmt werden („Tool Confidence Level“). Beispiele: Ein Testtool kann Bugs in der eigentlichen Software übersehen, ein Compiler kann selbst einen Bug in die Software einbringen. Bei zu geringem Vertrauen werden Maßnahmen zur Toolqualifizierung empfohlen.
• Hardware-Komponenten sollen hinsichtlich ihrer Risiken bewertet werden, in dem beispielsweise auf Eigenarten untersucht wird, die für die gewünschte Funktion problematisch sein könnten. Beispiel wäre ein Sensor und die Drift seiner Messwerte während einer beschleunigten Alterung.
• Das 'Proven-in-use’-Argument ist eine Möglichkeit, Produkte und Komponenten zu verwenden, die zwar nicht nach ISO 26262 entwickelt wurden, aber schon länger an Endkunden verkauft werden. Um zu zeigen, dass eine solche Komponente betriebsbewährt ist, darf nur ein sehr geringer Anteil von gefährlichen Ausfällen aufgetreten sein.
• Speziell für Nutzfahrzeuge und Omnibusse gibt es Empfehlungen, um Komponenten, die nicht nach ISO entwickelt wurden, über eine Schnittstelle anzusprechen oder als Teil zu integrieren.

Part 9: Automotive Safety Integrity Level (ASIL)-oriented and safety-oriented analyses

Teil 9 beinhaltet die Regeln der ASIL-Dekomposition als Methodik des ASIL „Tailoring“, wenn ein (Teil-)System in redundante Komponenten zerlegt wird, um den ASIL herabzustufen und damit den Entwicklungsaufwand zu reduzieren. Hierfür müssen diese Komponenten ausreichend unabhängig voneinander sein, worauf der Teil 9 im Weiteren eingeht. Für Hardwarekomponenten sind aufgrund der Natur der möglichen Ausfälle (zufällige Ausfälle, d. h. 'random failures') spezielle Regeln zu beachten. Bei der Analyse abhängiger Ausfälle unterscheidet die Norm zwischen zwei Ausfallszenarien:

• 'Cascading failures’: Ein Ausfall pflanzt sich durch mehrere folgende Komponenten fort, z. B. falscher Sensorwert → fehlerhafte Regelung → falsche Systemreaktion
• 'Common cause failures’: mehrere Komponenten sind zur gleichen Zeit beeinträchtigt, beispielsweise durch Unterspannung oder EMV Einstrahlung

Part 10: Guidelines on ISO 26262

Teil 10 beinhaltet Erläuterungen und weiterführende Information zu einigen Bereichen des Standards und schafft damit mehr Klarheit über den Umgang mit den übrigen Teilen. Dieser Teil ist informativ, nicht normativ.

Part 11: Guidelines on application of ISO 26262 to semiconductors

Teil 11 wurde mit der Ausgabe 2018 hinzugefügt und ist nur informativ, nicht normativ. Da auf dem Markt immer mehr Komponenten angeboten werden, die unterschiedliche Funktionen als SoC oder SiP integrieren, haben die Käufer solcher Chips nur über die Schnittstellen Zugriff, was die Erkennung von Fehlern begrenzt. Daher ist dieser Teil speziell für Halbleiterhersteller mit Kunden aus dem Automotive-Bereich interessant, um beispielsweise Sensoren und Mikrocontroller kompatibel zu einem bestimmten ASIL-Niveau als Safety Element Out of Context (SEooC) zu entwickeln und anzubieten.

Part 12: Adaptation of ISO 26262 for motorcycles

Teil 12 wurde ebenfalls mit der Ausgabe 2018 hinzugefügt und geht speziell auf Krafträder ein. Nach Definition sind Motorräder Zweiräder und Trikes mit nicht mehr als 800 kg Gesamtmasse und einem Motor. „Mopeds“ sind ausdrücklich und grundsätzlich ausgenommen

Der ASIL bei Motorrädern wird auf die gleiche Art wie bei den anderen Fahrzeugarten aus 'severity’, 'exposure’ und 'controllability’ als 'MSIL’ ('motorcycle safety integrity level’) bestimmt. Dann wird er um eine Stufe reduziert, so dass aus ASIL A ein ASIL QM wird und der höchste ASIL nur noch ASIL C sein kann. Durch diese Umschreibung von MSIL auf ASIL können dann die Methoden der übrigen Teile angewendet werden, sofern Teil 12 keine eigenen Methoden vorgibt.