ISO 26262

ISO 26262
Bereich	Straßenfahrzeuge
Titel	Road vehicles – Functional safety
Teile	12, siehe Inhalt
Erstveröffentlichung	November 2011
Letzte Ausgabe	Dezember 2018
Klassifikation	01.040.43, 43.040.10

Die ISO 26262 („Road vehicles – Functional safety“) ist eine ISO-Norm für sicherheitsrelevante elektrische/elektronische Systeme in Kraftfahrzeugen. Die ISO 26262 definiert ein Vorgehensmodell zusammen mit geforderten Aktivitäten und Arbeitsprodukten („work products“) sowie anzuwendenden Methoden in Entwicklung und Produktion. Häufig wird auch von 'Funktionaler Sicherheit’ kurz 'FuSi’ oder auch 'Functional Safety’, kurz 'FuSa’ gesprochen.

Nach einem längeren Vorlauf wurde die erste Version der Norm 2011 in Kraft gesetzt. Seit Dezember 2018 ist die „Second Edition“ verfügbar, die in Zitaten als ISO 26262:2018 gekennzeichnet wird. Die ISO bietet diese Norm nur in englischer Sprache an.

Die Umsetzung der Norm soll die Funktionale Sicherheit eines Systems mit elektrischen/elektronischen Komponenten im Kraftfahrzeug gewährleisten. Damit ist die Norm eine Anpassung der IEC 61508 an die spezifischen Produkte im Automobilbereich.

Unterschiede zwischen erster und zweiter Ausgabe

Ein wesentlicher Unterschied zwischen der ersten (2011) und zweiten (2018) Ausgabe ist der Anwendungsbereich. Während sich die erste Ausgabe auf Fahrzeuge beschränkte, die in Serienproduktion sind und max. 3,5 t Gesamtmasse erreichen, wurde die Ausgabe 2018 auf Serienfahrzeuge (Pkw), Lkw, Busse, Anhänger (sofern mit elektronischen Steuergeräten ausgerüstet) und Motorräder erweitert. Beide Ausgaben schließen Prototypen, Rennfahrzeuge oder Spezialfahrzeuge für Leute mit Behinderungen von der Normenanwendung aus. Die jeweilige Norm ist nicht anwendbar auf Systeme, die vor der ersten Ausgabe 2011 entwickelt wurden bzw. auf Erweiterungen (Fahrzeugkategorien) und Änderungen zur ersten Ausgabe in der zweiten Ausgabe 2018.

Die Version 2018 enthält zusätzlich die Teile 11 und 12, die im Abschnitt Inhalt genauer beschrieben werden.

Beide Normen schließen die Anwendungen auf Sonderfahrzeuge aus, die typischerweise in Kleinstserien oder Einzelfertigung entstehen. Dazu nennt die Norm als Beispiel Behindertenfahrzeuge.

Anwendungsbereich und Hintergrund

Mit der stetig wachsenden Komplexität elektronischer Komponenten in Fahrzeugen steigt auch die Möglichkeit von Fehlfunktionen. Ist eine sicherheitsrelevante Komponente von einer solchen Fehlfunktion betroffen, können im schlimmsten Fall Menschen getötet werden. Würde z. B. ein ESP-Steuergerät in einem Kraftfahrzeug bei zügiger Fahrt unerwartet eine Vollbremsung auslösen, könnte dies zu einem Auffahrunfall führen. Um das Risiko von Gefahr bringenden Fehlfunktionen von sicherheitsrelevanten Elektronik-Systemen zu minimieren, sollten diese unter Berücksichtigung einschlägiger Normen entwickelt werden.

In der Vergangenheit galt die Empfehlung, elektrische/elektronische Systeme, die eine sicherheitsrelevante Funktion in Automobilen ausführen und deren Ausfall ein maßgebliches Risiko für Mensch oder Umwelt bedeutet, auf Basis der IEC 61508 zu entwickeln. Diese Norm ist generisch auf sicherheitsrelevante Produkte, wie ein Sicherheitsschaltrelais für eine Notstromabschaltung, anwendbar. Da dieser Standard für moderne Automotive-Anwendungen nicht ausreichend bzw. nicht spezifisch genug ist, wurde eine neue Norm erstellt.

Zu den Anwendern der ISO 26262 gehören Automobilhersteller, Automobilzulieferer und Prüfinstitute. Möchte beispielsweise ein Automobilhersteller oder -zulieferer ein sicherheitsrelevantes System bzw. eine Komponente entwickeln, so wird der Auftraggeber in der Regel die Anwendung einer Sicherheitsnorm wie beispielsweise der ISO 26262 verlangen. Um die Funktionale Sicherheit des Produkts zu gewährleisten, wird von der ISO 26262 ab einer entsprechenden Sicherheitsstufe gefordert, dass eine von der Entwicklung organisatorisch unabhängige Stelle hinzugezogen wird. Auch hier macht der Auftraggeber häufig Vorgaben, so dass beispielsweise bei ASIL D die Prüfung durch ein externes Prüfinstitut verlangt wird.

Ablauf in der Entwicklung

(Normbegriffe durch 'Apostrophe’ hervorgehoben)

Der Start einer Entwicklung nach ISO 26262 lässt sich in folgenden Schritten beschreiben:

1. Der Fahrzeughersteller, der sein Produkt in den Markt bringt (= an Endverbraucher verkauft) untersucht Umstände und Situationen, in denen das Fahrzeug Menschen verletzen oder töten könnte.
2. Definition von Sicherheitszielen ('safety goals’), die das ungewollte Verhalten beschreiben, z. B. „Ungewolltes Anfahren des Fahrzeugs vermeiden.“
3. Risiko bestimmen und bewerten, z. B.
   1. ungefährlich, beispielsweise ein Klimasteuergerät,
   2. geringe Gefahren 'ASIL’ 'QM’, die ohne Anwendung der Norm auskommt, oder die
   3. Einstufung von ASIL ('Automotive Safety Integrity Level’) A bis ASIL D, für die die Norm anzuwenden ist.
4. Komponenten (der Zulieferer) identifizieren, die dazu beitragen könnten, z. B. „Motor beschleunigt ungewollt“ oder „Automatisches Getriebe verlässt von selbst P oder N“
5. Den Lieferanten von Komponenten die geforderte Funktion als Sicherheitsanforderung ('safety requirement’), den ASIL und einige weitere Informationen mitteilen, um sie in die sicherheitsgerichtete Entwicklung einzubinden.

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, wie es die Norm fordert. Dazu gibt es zwei Ansätze:

• Tailoring: Die Norm selbst schlägt für verschiedene Aufgaben oft mehrere Methoden als Alternativen vor. Daher wird zu Beginn eines Entwicklungsprojektes festgelegt, welche Methoden angewendet werden und begründet, welche entfallen können.
• Mapping: Wenn Inhalte nicht in dem Dokument niedergelegt werden, welches die Norm fordert, kann ein Plan erstellt werden, der zuordnet, in welchem Dokument die von der Norm geforderten Arbeitsprodukte aufzufinden sind.

Maßnahmen

Symbolische Darstellung: (A) zeigt das gewünschte Ergebnis, (B) die Abweichung durch systema­tische, und (C) zufällige Fehler

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, und 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 der 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.

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 wurde, sondern Ziel der Entwicklung muss auch sein, dass sie im richtigen Kontext ausgeführt wurde bzw. in der falschen Situation nicht von selbst 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 einwandfrei sein, aber im falschen Kontext könnte es ein Problem der funktionalen Sicherheit sein. Die Folgen für den Kopf des Fahrers sind jedoch, betrachtet man nur die Wirkung des Airbags, in beiden Fällen gleich.

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 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 12.2021) gibt es keine gesetzliche Pflicht zur Anwendung der ISO 26262. 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 EG-Richtlinie 85/374 EG beruht, ist davon auszugehen, dass in anderen Mitgliedsstaaten ähnliche Regelungen wie in Deutschland gelten.

Inhalt

ISO 26262:2011 hatte zehn Teile. Die aktuell gültige ISO 26262:2018 wurde um zwei Teile ergänzt, wobei die Struktur und Inhalte der ersten zehn Teile im Wesentlichen erhalten blieb.

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 Systems, welches E/E-Subsysteme (Elektrik/Elektronik-Subsysteme) 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.

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’). 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 gefährlich wären. 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’) abgeschätzt. Daraus ergibt sich die Sicherheitsanforderungsstufe, die von ASIL A bis ASIL D klassifiziert wird und in Abhängigkeit vom ASIL zusätzliche Maßnahmen in der Entwicklung erfordert. Ist das Risiko so gering, dass die Anwendung der Norm nicht erforderlich ist, erhält die Gefährdung die Zuordnung ASIL QM. Anders als zum Beispiel in der IEC 61508 geschieht die Risikoanalyse in der ISO 26262 mittels einer festgelegten, qualitativen Methodik. Aus einer vorgegebenen Tabelle lässt sich dann für jede Gefährdung die Einstufung QM oder ASIL A bis D ablesen.

Der ASIL steigt von A nach D und damit steigt auch der Aufwand, den die Methoden der Norm vorgeben und die in den nachfolgenden Teilen spezifiziert sind.

Part 4–6: System, Hardware, Software

Die Teile 4, 5 und 6 behandeln die Entwicklungsprozesse auf Systemebene, Hardwareebene und Softwareebene in Anlehnung an geschachtelte V-Modelle und definieren für die einzelnen Abschnitte Vorgehensweisen und Arbeitsergebnisse ('work products’). 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 (sehr 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.

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, also Programmen, die irgendwie an der Produktentwicklung beteiligt sind, soll die Zuverlässigkeit hinsichtlich undokumentierter Programmfehler (Bugs) betrachtet werden. Dazu werden Maßnahmen zur Überprüfung 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, die 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, wenn ein (Teil-)System logisch oder physisch als in Komponenten zerlegt betrachtet wird, um Funktionen zu separieren und gegenseitige Beeinflussung auszuschließen. Weiterhin geht es um Analysen abhängiger Ausfälle. Hier 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’: Ein Fehler beeinflusst mehrere Komponenten gleichzeitig, Auslöser können beispielsweise falscher Takt oder falsche Spannung sein, die jedes Bauteil betreffen kann.

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.

Schlüsselbegriffe der Norm

Die folgenden Begriffe sind meist keine exklusive Schöpfung der ISO 26262, sie kennzeichnen allerdings den Fokus dieser Norm. Entsprechend der einzigen Sprachversion der Norm werden diese Begriffe in englischer Sprache und der üblichen deutschen Verwendung angegeben:

• Item: Das Item ist ein System oder eine Kombination von Systemen. Für einen Zulieferer bezeichnet das Item dessen Lieferumfang.

• System im Sinne der Norm kann das Fahrzeug als Ganzes oder auch eine Komponente sein. Da Fahrzeuge aus vielen Komponenten von Fremdfirmen (Zulieferern) bestehen, hat jeder dieser Zulieferer ein System (in der Norm auch als Component bezeichnet) als Teil des Gesamtsystems, das entwickelt werden muss.

Ein System besteht wenigstens aus einem Sensor, Logik (Steuerung, Regler) und einem Aktor.

• Safety Goal ist ein Sicherheitsziel, welches auf Ebene des Fahrzeugs gestellt wird. Ein safety goal beschreibt, was nicht eintreten darf, weil unter ungünstigen Umständen eine Person verletzt oder getötet werden könnte.

Beispiel: Wenn ein Fahrzeug fehlerbedingt in die falsche Richtung anfährt, könnte jemand verletzt werden. Das safety goal könnte so formuliert werden: „Nicht fehlerbedingt in die falsche Richtung anfahren“. Daraus leitet der Fahrzeughersteller für verschiedene Komponenten Sicherheitsanforderungen („safety requirements“) ab, so z. B.

• Der Motor darf nicht rückwärts anlaufen (nur E-Maschinen und alte 2-Takt-Motoren)
• Das automatische Getriebe darf von selbst keinen Fahrtrichtungswechsel, also R nach D oder D nach R, vornehmen (nur in Verbindung mit Verbrennungsmotoren)

Da Motor und Getriebe alleine nicht fähig sind, eine Person zu verletzen, können sie kein safety goal haben, sondern nur abgeleitete safety requirements.

ASIL-Berechnung (Algorithmus)

• ASIL: Der bereits erwähnte ASIL wird in den verschiedenen Teilen der Norm genutzt, um Maßnahmen zu empfehlen. Vor allem in Teil 5 (Hardware) und Teil 6 (Software) finden sich zahlreiche Tabellen mit Methoden und Empfehlungen, die vom ASIL abhängig sind.

Beispielsweise wird eine deduktive Analyse wie die FTA (Fault Tree Analysis, Fehlerbaumanalyse) erst ab ASIL C und D besonders empfohlen.

Die Einstufung ist das Ergebnis einer Gefahren- und Risikoanalyse und bewegt sich zwischen QM (keine Anwendung der von der Norm empfohlenen Maßnahmen notwendig) bis zu den höchsten Anforderungen mit ASIL D. An Gefährdungen der Klasse QM sind keine Anforderungen gestellt, die über das übliche Qualitätsmanagement des Systemherstellers hinausgehen, und ihre Beherrschung kann deshalb durch eine erfolgreiche Umsetzung einer Qualitätsmanagementnorm, wie zum Beispiel der ISO 9001 oder der ISO/TS 16949 nachgewiesen werden.

• Safe State, Sicherer Zustand: Wenn ein System durch seine Eigendiagnose eine Funktionsstörung erkennt, soll es in einen Zustand wechseln, in dem keine Gefahr mehr vom System ausgeht. Dieser sichere Zustand ist von der Art des Gesamtsystems abhängig. Bei einer Motorsteuerung eines Pkw könnte dies der Zustand „Motor aus“ sein.
• Fault Tolerant Time Interval, Fehlertoleranzzeit: Wenn ein Fehler vom System durch Eigendiagnose erkannt wird, muss der sichere Zustand erreicht werden, bevor ein System gefährlich ausfallen kann.

Beispiel: Wenn eine Getriebesteuerung 50 ms braucht, um die Kupplung zu öffnen, den Gang zu wechseln und die Kupplung wieder zu schließen, dann könnte der Fehler „Ungewolltes Einlegen eines Ganges aus dem Leerlauf/Stillstand ohne Fahrereingriff“ frühestens nach 50 ms auftreten, weil das Fahrzeug erst mit dem Schließen der Kupplung anfahren könnte. Der Mikroprozessor der Steuerung muss also mindestens einmal alle 50 ms prüfen und erkennen, ob die Leistungsendstufe für den Motor der Kupplungssteuerung sich durch einen Fehler verselbständigt haben könnte und in der Lage wäre, von alleine einen Gang einzulegen.

• Freedom from Interference, Rückwirkungsfreiheit: Hier geht es darum, dass Komponenten voneinander unabhängig arbeiten.

Beispiel: Nutzen alle Komponenten die gleiche Spannungsversorgung und weicht die tatsächliche Spannung von der Sollspannung ab, so ist die Rückwirkungsfreiheit nicht gegeben, beispielsweise wenn die Spannung als Referenz für Messungen der absoluten Spannung dient.

Beispiel: Ein Softwaremodul, welches eine sicherheitsrelevante Berechnung ausführt und den Wert speichert, muss beim Rückruf der gespeicherten Daten sicherstellen, dass diese zwischenzeitlich nicht verändert wurden, indem es die Daten in mehreren Kopien ablegt oder bei jedem Lesen und Schreiben Prüfsummen vergleicht bzw. erstellt.

Dieses und weniger offensichtliche Abhängigkeiten soll eine „Dependent failure analysis“ aufdecken. Daraus kann entweder eine Designänderung folgen oder eine Begründung, warum das ohne Auswirkung ist (beispielsweise weil alle Messungen ratiometrisch sind)

• Hardware Architectural Metrics, Hardwaremetriken: Bei den Metriken geht es darum, dass das System (gegebenenfalls jedes elektronische Bauteil im System) auf seine Ausfallmöglichkeiten hin untersucht wird. Dabei ist zu bewerten, wie häufig ein zufälliger Ausfall eines Bauteils das ganze System in einen unsicheren Zustand bringen könnte. Aus dieser Analyse soll dann abgeleitet werden, an welchen Stellen die Ausfallsicherheit des Systems verbessert werden kann und ob ein gewisses Niveau erreicht wird.

Die Norm schlägt zwei Wege vor, diese Ausfallwahrscheinlichkeiten zu berechnen. Wichtigste Hilfsmittel sind dabei Fehlermodelle, die die Ausfallarten von Bauteilgattungen (wie Transistoren, Kondensatoren, Widerstände) beschreiben und Ausfallraten aus anderen Normenwerken (z. B. Siemensnorm SN 29500, siehe auch Failure in Time). Die Zusammenfassung erfolgt in einer FMEDA oder einer FTA.

• Proven-in-Use, Betriebsbewährtheit: Wenn Komponenten eines Systems wiederverwendet werden sollen oder einige Zeit vor Inkrafttreten der Norm erfolgreich und fehlerfrei von Kunden verwendet wurden, kann man mit dieser Erfahrung den Entwicklungsaufwand bei Wiederverwendung reduzieren. Je nach Bedeutung können von der Norm geforderte Nachweise oder Maßnahmen entfallen. Voraussetzung ist eine Produktbeobachtung und die Analyse der Ausfälle, die in der Hand des Kunden aufgetreten sind. Komponenten können Hardwarekomponenten und Softwaremodule sein, aber auch Teile einer früher erarbeiteten Dokumentation, die selbst nur dem Nachweis einer sicheren Entwicklung dient. Je nach Tiefe der vorliegenden Daten kann jedoch meist nur eine Argumentation der Betriebsbewährtheit auf das Gesamtgerät, in einem bestimmten Kontext, angewendet werden. Der Absturz der Ariane 5 hat gezeigt, dass selbst Komponenten mit Nachweisen, die in einem bewährten System eingesetzt wurden, in einem anderen System zu unsicheren Zuständen führen können. Die „Proven-in-Use“ Argumentation kann nur in ganz spezifischen Fällen, mit eindeutigen diagnostischen Daten, als Nachweis herangezogen werden.

Literatur

• Hans-Leo Ross, „Functional Safety for Road Vehicles“, Springer International Publishing Switzerland 2016, ISBN 978-3-319-33360-1
• Steffen Herrmann, Dirk Dürholz, Ralf Stärk, „SAFETY Essentials: ISO 26262 auf einen Blick – kompakt vermittelt (E/E Engineering Essentials)“, Kugler Maag Cie, Kornwestheim, 2014, ISBN 978-3-9815078-1-2
• Marco Heinz Schlummer, „Beitrag zur Entwicklung einer alternativen Vorgehensweise für eine Proven-in-Use-Argumentation in der Automobilindustrie“, Dissertation an der Bergischen Universität Wuppertal, 2012
• Martin Hillenbrand, „Funktionale Sicherheit nach ISO 26262 in der Konzeptphase der Entwicklung von Elektrik / Elektronik Architekturen von Fahrzeugen“, Dissertation am Karlsruher Institut für Technologie, 2012, ISBN 978-3-86644-803-2
• Johannes Matheis, „Abstraktionsebenenübergreifende Darstellung von Elektrik/Elektronik-Architekturen in Kraftfahrzeugen zur Ableitung von Sicherheitszielen nach ISO 26262“, Dissertation am Karlsruher Institut für Technologie, 2009, ISBN 978-3-8322-8968-3, Link zum Abstract
• Beispiel für eine Gefahren- und Risikoanalyse von Frederik Walderyd „Hazard identification and safety goals on power electronics in hybrid vehicles (PDF; 1,4 MB)“ (englisch), Master Thesis an der Chalmers University of Technology, Göteborg 2010
• Literatur in der Deutschen Nationalbibliothek mit Bezug zu zur ISO 26262 bzw. Funktionalen Sicherheit

Weblinks

• Überblicksartikel zur ISO 26262 auf elektronikpraxis.de
• Artikel zur Überarbeitung und Erweiterung der ISO 26262 auf elektronikpraxis.de
• Airbag-Urteil. (PDF) Aktenzeichen VI ZR 107/08. Bundesgerichtshof, abgerufen am 5. Januar 2022 (deutsch).