ISO 26262

Sie beschreibt, wie sicherheitsrelevante E/E-Fahrzeugfunktionen in der Serienentwicklung und Serienproduktion geplant, entwickelt, analysiert, verifiziert, validiert, dokumentiert und über den Lebenszyklus abgesichert werden. Besonders relevant ist sie für Fahrzeughersteller, Zulieferer, Entwicklungsdienstleister, Softwareunternehmen, Halbleiterhersteller sowie Qualitäts-, Sicherheits- und Normenverantwortliche in der Automobilindustrie.

Im Normenmanagement spielt ISO 26262 eine wichtige Rolle, weil sie konkrete Erwartungen an Prozesse, Rollen, Nachweise, Dokumentation, Änderungsmanagement und Lieferantensteuerung stellt. Unternehmen müssen sicherstellen, dass die jeweils gültige Normfassung bekannt ist, korrekt bewertet wird und relevante Anforderungen nachvollziehbar in Entwicklungs-, Qualitäts- und Freigabeprozesse einfließen. ISO 26262 fordert zwar kein spezifisches Normenmanagementsystem als solches, in der Praxis ist ein strukturiertes Informationsmanagement jedoch entscheidend, um Anforderungen, Entscheidungen und Nachweise konsistent und assessmentfähig zu steuern.

Was ist ISO 26262?

ISO 26262 trägt den Titel „Road vehicles - Functional safety“ und ist die branchenspezifische Anpassung der grundlegenden Sicherheitsnorm IEC 61508 für die Automobilindustrie. Während IEC 61508 branchenübergreifend für elektrische, elektronische und programmierbare sicherheitsbezogene Systeme gilt, überträgt ISO 26262 diese Grundprinzipien auf Straßenfahrzeuge und deren E/E-Systeme. Die aktuell maßgebliche zweite Ausgabe ist ISO 26262:2018.

Die erste Ausgabe aus dem Jahr 2011 war im Schwerpunkt auf Pkw ausgerichtet. Mit ISO 26262:2018 wurde der Anwendungsbereich erweitert und präzisiert, insbesondere auf Lkw, Busse, Anhänger und Motorräder. Motorräder werden seit der zweiten Ausgabe über Teil 12 adressiert, wobei spezifische Anpassungen für diese Fahrzeugkategorie gelten.

Die Norm konzentriert sich auf Risiken, die durch Fehlverhalten elektrischer oder elektronischer Systeme entstehen können. Dazu zählen beispielsweise Fehler in Steuergeräten, Sensoren, Aktuatoren, Kommunikationsnetzwerken, sicherheitsrelevanter Software oder Halbleiterkomponenten. Da moderne Fahrzeuge zunehmend softwaredefiniert sind und Funktionen über mehrere Komponenten und Domänen hinweg verteilt werden, gewinnt die systematische Anwendung der ISO 26262 weiter an Bedeutung.

Typische Beispiele für Systeme und Funktionen, bei denen ISO 26262 relevant sein kann, sind:

• Brems- und Lenksysteme mit E/E-Anteilen
• Fahrerassistenzsysteme wie Spurhalteassistent, Notbremsassistent oder Abstandsregelung, soweit Fehlfunktionen von E/E-Systemen betrachtet werden
• Airbag- und Rückhaltesysteme
• Batteriemanagementsysteme in Elektro- und Hybridfahrzeugen
• Antriebs- und Energiemanagementfunktionen
• Steuergeräte und sicherheitsrelevante Softwarefunktionen
• Sensorik, Aktorik und Kommunikationssysteme im Fahrzeug
• Halbleiterkomponenten, sofern sie sicherheitsrelevante Funktionen unterstützen

Wichtig ist die Abgrenzung: ISO 26262 behandelt nicht die gesamte Sicherheit eines Fahrzeugs. Ihr Schwerpunkt liegt auf unzumutbaren Risiken aufgrund von Gefährdungen, die durch Fehlverhalten von E/E-Systemen verursacht werden. Risiken durch elektrische Schläge, Feuer, Rauch, Hitze, Strahlung, Toxizität oder rein mechanische Einzelrisiken stehen nicht im primären Fokus, auch wenn sie in der Gesamtsicherheitsbetrachtung eines Fahrzeugs relevant sein können.

Ziel der ISO 26262

Ziel der ISO 26262 ist es, unzumutbare Risiken durch Fehlverhalten sicherheitsrelevanter E/E-Systeme systematisch zu vermeiden oder auf ein akzeptables Maß zu reduzieren. Die Norm adressiert dabei sowohl systematische Fehler, die beispielsweise durch ungeeignete Anforderungen, Entwurfsfehler oder Prozessmängel entstehen, als auch zufällige Hardwarefehler, etwa Ausfälle elektronischer Bauteile während des Betriebs.

ISO 26262 schafft einen methodischen Rahmen, mit dem Sie Gefährdungen identifizieren, Risiken bewerten, Sicherheitsziele ableiten, Sicherheitsanforderungen spezifizieren und die Wirksamkeit der Maßnahmen nachweisen können. Dadurch wird funktionale Sicherheit nicht als nachgelagerte Prüfung verstanden, sondern als integraler Bestandteil von Konzept, Architektur, Entwicklung, Verifikation, Validierung, Produktion, Betrieb und Änderung.

Die Norm unterstützt Sie insbesondere dabei:

• Gefährdungen frühzeitig zu erkennen
• Risiken anhand definierter Kriterien nachvollziehbar zu bewerten
• Sicherheitsziele aus gefährlichen Ereignissen abzuleiten
• funktionale und technische Sicherheitsanforderungen zu spezifizieren
• Sicherheitsanforderungen über System-, Hardware- und Softwareebene hinweg zu verfolgen
• geeignete Entwicklungs-, Verifikations- und Validierungsmethoden auszuwählen
• Sicherheitsmechanismen, Diagnosekonzepte und Degradationsstrategien zu bewerten
• Änderungen kontrolliert auf Sicherheitsauswirkungen zu prüfen
• sicherheitsrelevante Informationen zwischen Herstellern und Zulieferern abzustimmen
• Nachweise für Reviews, Functional Safety Audits, Functional Safety Assessments und interne Freigaben bereitzustellen

Für Unternehmen bedeutet das, dass Sicherheit nicht erst am Ende eines Projekts bestätigt werden kann. Die erforderlichen Aktivitäten, Rollen, Work Products und Bestätigungsmaßnahmen müssen früh geplant, während der Entwicklung umgesetzt und nachvollziehbar dokumentiert werden.

Was bedeutet funktionale Sicherheit?

Funktionale Sicherheit im Sinne der ISO 26262 bedeutet die Abwesenheit unzumutbarer Risiken aufgrund von Gefährdungen, die durch Fehlverhalten elektrischer oder elektronischer Systeme verursacht werden. Entscheidend ist nicht, dass ein System niemals ausfällt. Entscheidend ist, dass relevante Fehlfunktionen erkannt, verhindert, beherrscht oder in einen kontrollierten, risikoreduzierten Zustand überführt werden.

Ein Beispiel ist ein elektronisch unterstütztes Bremssystem. Wenn das System einen internen Fehler erkennt, darf es nicht unkontrolliert reagieren oder eine gefährliche Bremswirkung auslösen. Je nach Sicherheitskonzept kann eine Warnung an die fahrende Person, eine Ersatzfunktion, eine Begrenzung der Funktionalität oder ein definierter degradierter Betriebszustand erforderlich sein.

Auch bei einem elektrischen Lenksystem ist funktionale Sicherheit zentral. Fällt ein Sensor aus oder liefert widersprüchliche Werte, muss das System verhindern, dass ein ungewollter Lenkeingriff entsteht. Dafür können redundante Sensoren, Plausibilitätsprüfungen, Diagnosefunktionen, Fehlerreaktionszeiten oder mechanische Rückfallebenen notwendig sein.

Der Begriff „sicherer Zustand“ sollte im Fahrzeugkontext vorsichtig verwendet werden. Anders als in stationären Industrieanlagen gibt es im Straßenverkehr nicht immer einen eindeutig sicheren Zustand, weil Geschwindigkeit, Umgebung, Fahrmanöver und Verkehrssituation variieren. Häufig geht es daher um einen kontrollierten, risikoreduzierten oder degradierten Betriebszustand, der die Gefährdung in der konkreten Situation beherrschbar macht.

Anwendungsbereich der ISO 26262

ISO 26262:2018 gilt für sicherheitsrelevante elektrische und elektronische Systeme in der Serienentwicklung und Serienproduktion von Straßenfahrzeugen. Dazu zählen insbesondere Pkw, Lkw, Busse, Anhänger und Motorräder. Mopeds sind vom Anwendungsbereich ausgenommen. Einzelanfertigungen, Prototypen, Sonderfahrzeuge oder nicht serienmäßig entwickelte Systeme können gesondert zu bewerten sein.

Motorräder sind seit ISO 26262:2018 grundsätzlich über Teil 12 adressiert. Dieser Teil enthält Anpassungen, die den Besonderheiten von Motorrädern Rechnung tragen, etwa bei Fahrdynamik, Beherrschbarkeit und typischen Betriebssituationen. Die frühere Formulierung, Motorräder seien nur abhängig vom Normteil relevant, wäre daher zu ungenau.

Typische Anwendungsbereiche sind:

• sicherheitsrelevante E/E-Systeme in Pkw, Lkw, Bussen, Anhängern und Motorrädern
• Steuergeräte, Sensoren, Aktuatoren und Kommunikationsnetzwerke
• sicherheitsrelevante Hardware- und Softwarekomponenten
• E/E-Architekturen und domänenübergreifende Fahrzeugfunktionen
• Antriebs-, Brems-, Lenk-, Energie- und Rückhaltesysteme mit E/E-Anteilen
• sicherheitsrelevante Halbleiter, Microcontroller und System-on-Chip-Komponenten
• Plattformelemente, Softwarekomponenten oder generische Bausteine, die in sicherheitsrelevanten Funktionen eingesetzt werden

Nicht im Mittelpunkt stehen rein mechanische, hydraulische oder pneumatische Systeme, sofern sie nicht durch elektrische oder elektronische Funktionen gesteuert oder überwacht werden. In der Praxis sind moderne Fahrzeugsysteme jedoch häufig eng mit Elektronik und Software verbunden. Dadurch kann ISO 26262 auch dann relevant werden, wenn ein System auf den ersten Blick mechanisch oder hydraulisch geprägt erscheint.

Für das Normenmanagement ist die Abgrenzung des Anwendungsbereichs besonders wichtig. Sie sollten früh klären, welche Produkte, Plattformen, Komponenten, Derivate und Projekte unter ISO 26262 fallen. Eine unklare Abgrenzung führt später häufig zu Lücken in der Sicherheitsargumentation, fehlenden Nachweisen oder aufwendiger Nacharbeit.

Aufbau der ISO 26262

ISO 26262 besteht aus zwölf Teilen, die unterschiedliche Aspekte des Sicherheitslebenszyklus abdecken. Die Norm beschreibt damit nicht nur technische Anforderungen, sondern auch organisatorische, methodische und dokumentarische Erwartungen. Für eine belastbare Anwendung sollten Sie die Teile nicht isoliert betrachten, sondern im Zusammenspiel aus Rollen, Prozessen, Analysen und Work Products.

Die zwölf Teile der ISO 26262:2018 sind:

1. Teil 1 - Vocabulary: Begriffe und Definitionen
2. Teil 2 - Management of functional safety: Management der funktionalen Sicherheit
3. Teil 3 - Concept phase: Konzeptphase
4. Teil 4 - Product development at the system level: Produktentwicklung auf Systemebene
5. Teil 5 - Product development at the hardware level: Produktentwicklung auf Hardwareebene
6. Teil 6 - Product development at the software level: Produktentwicklung auf Softwareebene
7. Teil 7 - Production, operation, service and decommissioning: Produktion, Betrieb, Service und Außerbetriebnahme
8. Teil 8 - Supporting processes: Unterstützende Prozesse
9. Teil 9 - Automotive Safety Integrity Level oriented and safety oriented analyses: ASIL-orientierte und sicherheitsbezogene Analysen
10. Teil 10 - Guidelines on ISO 26262: Allgemeine Leitlinien zur Anwendung der Norm
11. Teil 11 - Guidelines on application of ISO 26262 to semiconductors: Leitlinien zur Anwendung auf Halbleiter
12. Teil 12 - Adaptation of ISO 26262 for motorcycles: Anpassung der Norm für Motorräder

Teil 10 enthält allgemeine Erläuterungen und Anwendungshinweise, während Teil 11 gezielt auf Halbleiter eingeht. Bei Halbleitern ist besonders wichtig, dass sie häufig als Safety Element out of Context entwickelt werden. Das bedeutet, dass Annahmen über den späteren Einsatzkontext dokumentiert und später im konkreten Fahrzeugprojekt geprüft werden müssen.

In der Praxis kann ein Projekt technisch überzeugende Lösungen entwickeln und dennoch nicht ausreichend ISO-26262-konform sein, wenn Rollen, Entscheidungen, Analysen, Anforderungen oder Bestätigungsmaßnahmen nicht nachvollziehbar dokumentiert sind. Die Norm verlangt ein durchgängiges Zusammenspiel aus Sicherheitsmanagement, Entwicklungsprozessen, technischen Sicherheitskonzepten, Konfigurationsmanagement, Verifikation, Validierung und Freigabe.

Zentrale Begriffe: Item, HARA und Sicherheitsziele

Ein zentraler Ausgangspunkt der ISO 26262 ist das Item. Ein Item ist das betrachtete System oder die betrachtete Funktion auf Fahrzeugebene, für das oder die eine Sicherheitsanalyse durchgeführt wird. Die Item Definition beschreibt Zweck, Funktionalität, Systemgrenzen, Schnittstellen, Betriebsmodi, Abhängigkeiten, Umgebungsbedingungen und Annahmen.

Die Item Definition ist entscheidend, weil sie den Betrachtungsumfang der HARA festlegt. Wenn das Item zu eng beschrieben ist, können relevante Wechselwirkungen übersehen werden. Wenn es zu breit beschrieben ist, werden Analysen unübersichtlich und schwer beherrschbar. Eine klare Item Definition ist daher eine der wichtigsten Grundlagen für Safety Goals, Sicherheitsanforderungen und spätere Nachweise.

Die HARA, also Hazard Analysis and Risk Assessment, identifiziert gefährliche Ereignisse und bewertet sie anhand von drei Faktoren:

• Severity: Schwere möglicher Verletzungen
• Exposure: Wahrscheinlichkeit, dass sich das Fahrzeug in einer relevanten Betriebssituation befindet
• Controllability: Möglichkeit der beteiligten Personen, die Gefahr zu beherrschen oder zu vermeiden

Exposure beschreibt nicht die Wahrscheinlichkeit des Fehlers selbst. Es geht vielmehr darum, wie wahrscheinlich die relevante Fahrsituation oder Betriebssituation ist, in der eine Fehlfunktion zu einem gefährlichen Ereignis führen kann. Aus der Kombination von Severity, Exposure und Controllability wird über die ASIL-Matrix eine Einstufung abgeleitet.

Aus gefährlichen Ereignissen werden Sicherheitsziele abgeleitet. Sicherheitsziele sind übergeordnete sicherheitsbezogene Anforderungen auf Fahrzeugebene, die verhindern sollen, dass ein gefährliches Ereignis eintritt oder unbeherrschbar wird. Sie bilden die Brücke zwischen Risikoanalyse und Sicherheitskonzept.

ASIL: Automotive Safety Integrity Level

ASIL steht für Automotive Safety Integrity Level. Die ASIL-Einstufung wird im Rahmen der HARA zunächst gefährlichen Ereignissen beziehungsweise den daraus abgeleiteten Sicherheitszielen zugeordnet. Anschließend wird der ASIL auf funktionale Sicherheitsanforderungen, technische Sicherheitsanforderungen sowie Hardware- und Softwareanforderungen vererbt oder im Rahmen zulässiger Konzepte angepasst.

Es gibt vier ASIL-Stufen:

• ASIL A: niedrigste Sicherheitsanforderungsstufe innerhalb der ISO-26262-Klassifikation
• ASIL B
• ASIL C
• ASIL D: höchste Sicherheitsanforderungsstufe

Zusätzlich gibt es die Einstufung QM. QM bedeutet, dass aus der betrachteten HARA für das analysierte gefährliche Ereignis keine besonderen Sicherheitsanforderungen nach ISO 26262 abgeleitet wurden. QM bedeutet jedoch nicht, dass eine Funktion unwichtig ist, ohne Sorgfalt entwickelt werden darf oder ISO 26262 im Projekt keinerlei Rolle spielt. Es bedeutet lediglich, dass für diesen Betrachtungsfall kein ASIL abgeleitet wurde und übliches Qualitätsmanagement ausreichend sein kann.

Ein Beispiel: Eine Fehlfunktion, die bei hoher Geschwindigkeit zu einem ungewollten Lenkeingriff führt, kann je nach Verletzungsschwere, Exposure und Controllability eine hohe ASIL-Einstufung erhalten. Eine Komfortfunktion ohne sicherheitskritische Auswirkung kann dagegen als QM eingestuft werden. Entscheidend ist immer das konkrete gefährliche Ereignis im definierten Betriebs- und Nutzungskontext.

Die ASIL-Klassifikation beeinflusst zahlreiche Projektentscheidungen. Sie bestimmt unter anderem die erforderlichen Methoden, die Tiefe von Analysen, die Unabhängigkeit von Bestätigungsmaßnahmen, die Teststrategie, die Anforderungen an Hardwarekennzahlen und die Art der Nachweisführung. Deshalb sollten ASIL-Herleitungen transparent dokumentiert, versioniert und bei Änderungen am Item oder an Annahmen erneut geprüft werden.

Sicherheitsanforderungen: Safety Goals, FSR und TSR

ISO 26262 unterscheidet verschiedene Ebenen von Sicherheitsanforderungen. Sicherheitsziele, Functional Safety Requirements und Technical Safety Requirements haben unterschiedliche Aufgaben und sollten nicht vermischt werden. Eine klare Trennung erleichtert die Traceability und verhindert Lücken zwischen Risikoanalyse, Architektur und Umsetzung.

Safety Goals sind übergeordnete Sicherheitsziele, die aus der HARA abgeleitet werden. Sie beschreiben, welches gefährliche Ereignis vermieden oder beherrscht werden muss. Sie sind meist auf Fahrzeugebene formuliert und tragen den aus der HARA abgeleiteten ASIL.

Functional Safety Requirements, kurz FSR, leiten aus den Safety Goals funktionale Maßnahmen ab. Sie beschreiben, welche sicherheitsbezogenen Funktionen, Reaktionen oder Zustände erforderlich sind, ohne bereits vollständig festzulegen, wie diese technisch umgesetzt werden. Beispiele sind Diagnoseanforderungen, Fahrerwarnungen, Degradationsstrategien oder Anforderungen an eine sichere Reaktion.

Technical Safety Requirements, kurz TSR, übertragen die funktionalen Sicherheitsanforderungen in technische Anforderungen an Systemarchitektur, Komponenten, Schnittstellen, Hardware und Software. Aus ihnen entstehen anschließend konkrete Hardware Safety Requirements und Software Safety Requirements. Eine typische Traceability führt vom Hazardous Event über Safety Goal, FSR, TSR, Hardware- oder Softwareanforderung bis zum Testnachweis und zur Sicherheitsvalidierung.

Sicherheitslebenszyklus nach ISO 26262

ISO 26262 betrachtet Sicherheit über den gesamten Sicherheitslebenszyklus. Dieser beginnt nicht erst bei der technischen Umsetzung, sondern bereits in der frühen Konzeptphase. Dadurch sollen sicherheitskritische Risiken früh erkannt und nicht erst kurz vor Serienfreigabe entdeckt werden.

Typische Phasen sind:

1. Item Definition
   Beschreibung der betrachteten Funktion, Systemgrenzen, Schnittstellen, Betriebsbedingungen, Abhängigkeiten und Annahmen.
2. Gefahren- und Risikoanalyse
   Identifikation gefährlicher Ereignisse und Bewertung anhand von Severity, Exposure und Controllability.
3. Festlegung von Sicherheitszielen
   Ableitung übergeordneter Safety Goals mit zugeordnetem ASIL.
4. Funktionales Sicherheitskonzept
   Beschreibung, wie Sicherheitsziele auf funktionaler Ebene erreicht werden, etwa durch Diagnose, Warnungen, Degradation, Redundanz oder Plausibilisierung.
5. Technisches Sicherheitskonzept
   Übertragung der funktionalen Anforderungen in technische Lösungen, Architekturen, Schnittstellen und Komponentenanforderungen.
6. Hardware- und Softwareentwicklung
   Umsetzung der Sicherheitsanforderungen in Komponenten, Steuergeräten, Softwaremodulen, Kommunikationsmechanismen und Sicherheitsmechanismen.
7. Verifikation und Validierung
   Nachweis, dass Anforderungen korrekt umgesetzt wurden und das Item im vorgesehenen Einsatzkontext die Sicherheitsziele erfüllt.
8. Produktion, Betrieb, Service und Außerbetriebnahme
   Sicherstellung, dass funktionale Sicherheit auch nach Serienstart, bei Wartung, Reparatur, Softwareupdates, Feldbeobachtung und Änderungen erhalten bleibt.

Für das Informationsmanagement bedeutet das: Anforderungen aus ISO 26262 müssen über viele Phasen, Teams, Dokumente und IT-Systeme hinweg nachvollziehbar bleiben. Besonders wichtig ist die Rückverfolgbarkeit von Normanforderungen über interne Vorgaben bis hin zu Projektartefakten, Analysen, Testergebnissen, Reviews und Freigaben.

Safety Plan, Rollen und Verantwortlichkeiten

Der Safety Plan ist ein zentrales Planungsdokument in ISO-26262-Projekten. Er beschreibt, welche Aktivitäten zur funktionalen Sicherheit durchgeführt werden, wann sie stattfinden, wer verantwortlich ist, welche Work Products entstehen und welche Bestätigungsmaßnahmen erforderlich sind. Der Safety Plan sollte eng mit der Projektplanung, Meilensteinplanung, Lieferantenplanung und Freigabestrategie verbunden sein.

Typische Inhalte eines Safety Plans sind:

• Sicherheitsaktivitäten und Zeitpunkte
• Rollen und Verantwortlichkeiten
• relevante Normteile und anzuwendende Prozesse
• geplante Work Products
• Verifikations- und Validierungsaktivitäten
• Confirmation Reviews, Functional Safety Audits und Functional Safety Assessments
• Schnittstellen zu Lieferanten und Development Interface Agreements
• Konfigurations-, Änderungs- und Variantenmanagement
• Eskalationswege und Freigabeschritte

Typische Rollen sind Functional Safety Manager, Safety Engineer, System Architect, Hardware Safety Engineer, Software Safety Engineer, Projektleitung, Qualitätsverantwortliche, Konfigurationsverantwortliche und Assessor. Je nach ASIL und Organisationsstruktur fordert die Norm unterschiedliche Grade der Unabhängigkeit für bestimmte Bestätigungsmaßnahmen. Diese Unabhängigkeit sollte bereits in der Planung berücksichtigt werden.

Unklare Verantwortlichkeiten zählen zu den häufigsten Ursachen für Lücken in ISO-26262-Projekten. Wenn nicht festgelegt ist, wer Sicherheitsanforderungen freigibt, Analysen aktualisiert, Lieferantennachweise bewertet oder Abweichungen entscheidet, entstehen spätere Konflikte. Eine saubere Rollen- und Schnittstellenklärung ist daher nicht nur organisatorisch, sondern unmittelbar sicherheitsrelevant.

Typische Nachweise und Work Products

ISO 26262 fordert zahlreiche dokumentierte Arbeitsergebnisse, häufig als Work Products bezeichnet. Sie dienen dazu, Entscheidungen, Analysen, Anforderungen und Nachweise transparent zu machen. Work Products sind keine reine Formalität, sondern Bestandteil der Sicherheitsargumentation und Grundlage für Reviews, Functional Safety Audits, Functional Safety Assessments und interne Freigaben.

Beispiele für typische Work Products sind:

• Safety Plan
• Item Definition
• Gefahren- und Risikoanalyse
• Sicherheitsziele
• funktionales Sicherheitskonzept
• technisches Sicherheitskonzept
• Hardware-Sicherheitsanforderungen
• Software-Sicherheitsanforderungen
• Architektur- und Schnittstellenbeschreibungen
• Verifikations- und Validierungsberichte
• Testpläne und Testergebnisse
• Reviewnachweise
• Nachweise aus Functional Safety Audits und Functional Safety Assessments
• Sicherheitsanalysen wie FMEA, FTA oder FMEDA
• Nachweise zur Werkzeugbewertung und Werkzeugqualifikation
• Konfigurations-, Freigabe- und Änderungsdokumentation
• Safety Case

Der Safety Case ist in ISO 26262:2018 als strukturiertes Work Product besonders wichtig. Er ist nicht nur eine lose Sammlung von Dokumenten, sondern eine nachvollziehbare Sicherheitsargumentation. Er zeigt, wie Sicherheitsziele, Anforderungen, Architekturentscheidungen, Analysen, Tests, Reviews und Freigaben zusammen belegen, dass das Item hinsichtlich funktionaler Sicherheit ausreichend abgesichert ist.

Nachweise richten sich in der Praxis primär an interne Freigabegremien, Kunden, Assessoren, Auditoren und an die eigene Haftungsargumentation. ISO 26262 ist in der Regel keine direkte Typgenehmigungsnorm. Dennoch kann die Norm als anerkannter Stand der Technik eine wichtige Rolle spielen, wenn es um Produkthaftung, Sorgfaltspflichten und die Begründung technischer Entscheidungen geht.

Confirmation Measures: Reviews, Audits und Assessments

ISO 26262 unterscheidet verschiedene Bestätigungsmaßnahmen, die nicht beliebig austauschbar sind. Confirmation Reviews prüfen ausgewählte Work Products darauf, ob sie die Anforderungen der Norm und des Safety Plans erfüllen. Sie betreffen beispielsweise die HARA, Sicherheitskonzepte, Sicherheitsanalysen oder den Safety Case.

Functional Safety Audits bewerten, ob die angewendeten Prozesse zur funktionalen Sicherheit geeignet umgesetzt wurden. Dabei geht es um die Prozesskonformität, etwa Sicherheitsplanung, Konfigurationsmanagement, Änderungsmanagement, Anforderungsmanagement, Verifikation, Validierung und Lieferantenschnittstellen. Ein Audit betrachtet also stärker die Prozessdurchführung als ein einzelnes technisches Ergebnis.

Functional Safety Assessments beurteilen, ob die funktionale Sicherheit des Items insgesamt angemessen erreicht wurde. Sie betrachten die Sicherheitsargumentation, zentrale Work Products, offene Punkte, Abweichungen und die Eignung der getroffenen Maßnahmen. Je nach ASIL sind bestimmte Unabhängigkeitsgrade erforderlich, sodass die bewertende Person oder Organisation ausreichend unabhängig vom Entwicklungsteam sein muss.

Systematische Fehler und zufällige Hardwarefehler

ISO 26262 unterscheidet systematische Fehler und zufällige Hardwarefehler. Systematische Fehler entstehen durch Mängel in Spezifikation, Architektur, Implementierung, Integration, Verifikation, Validierung oder Prozessen. Sie werden vor allem durch geeignete Entwicklungsprozesse, Reviews, Analysen, Methoden, qualifizierte Mitarbeitende und kontrollierte Änderungen reduziert.

Zufällige Hardwarefehler entstehen durch physikalische Ausfälle von Hardwareelementen während des Betriebs. Beispiele sind Ausfälle elektronischer Bauteile, Kurzschlüsse, offene Verbindungen oder Alterungseffekte. Diese Fehler werden durch Hardware-Sicherheitsanalysen, Diagnosemechanismen, Redundanzen, Überwachung, Fehlerreaktionen und quantitative Kennzahlen adressiert.

Wichtige Hardwarekennzahlen sind:

• SPFM: Single Point Fault Metric zur Bewertung von Einzelfehlern
• LFM: Latent Fault Metric zur Bewertung latenter Mehrpunktfehler
• PMHF: Probabilistic Metric for random Hardware Failures zur Bewertung zufälliger Hardwareausfälle über die Zeit
• Diagnoseabdeckung: Anteil der Fehler, die durch Sicherheitsmechanismen erkannt oder beherrscht werden
• Sicherheitsmechanismen: technische Maßnahmen wie Watchdogs, Plausibilitätsprüfungen, Redundanz, Speicherprüfungen oder Spannungsüberwachung

Diese Kennzahlen sind besonders bei höheren ASIL-Stufen relevant. Sie ersetzen jedoch keine saubere Systemarchitektur und keine qualitative Analyse. Quantitative Metriken, FMEA, FMEDA und FTA müssen zusammen ein plausibles Bild der Hardware-Sicherheit ergeben.

ASIL-Dekomposition

ASIL-Dekomposition ist ein Konzept, mit dem Sicherheitsanforderungen unter bestimmten Bedingungen auf unabhängige Elemente verteilt werden können. Ziel ist nicht, Sicherheitsanforderungen beliebig zu reduzieren, sondern eine Architektur so zu gestalten, dass zwei ausreichend unabhängige Maßnahmen gemeinsam das Sicherheitsziel erfüllen. Die Norm stellt dafür strenge Anforderungen an Unabhängigkeit und Freiheitsgrade gegenüber abhängigen Ausfällen.

Ein typisches Beispiel ist die Aufteilung einer ASIL-D-Anforderung auf zwei unabhängige Pfade mit niedrigeren ASIL-Anforderungen, sofern die Architektur und die Sicherheitsargumentation dies zulassen. Dabei müssen Common-Cause-Fehler, gemeinsame Ressourcen, gemeinsame Stromversorgung, Kommunikationsabhängigkeiten und Softwarekopplungen sorgfältig analysiert werden.

Eine häufige Fehlinterpretation ist, ASIL-Dekomposition als pauschales Mittel zur Aufwandsreduzierung zu betrachten. Das ist riskant. Wenn die Unabhängigkeit nicht überzeugend belegt ist oder verdeckte Abhängigkeiten bestehen, kann die Dekomposition in einem Assessment nicht tragfähig sein.

Safety Element out of Context und Halbleiter

Safety Element out of Context, kurz SEooC, bezeichnet ein sicherheitsrelevantes Element, das unabhängig von einem konkreten Fahrzeugsystem entwickelt wird. Das kann ein Steuergerät, eine Softwarekomponente, ein Plattformmodul, ein Sensor, ein Microcontroller oder ein System-on-Chip sein. Da der endgültige Einsatzkontext noch nicht vollständig bekannt ist, werden Annahmen über die Nutzung, Schnittstellen, Sicherheitsanforderungen und Betriebsbedingungen dokumentiert.

SEooC ist besonders wichtig für Zulieferer und Halbleiterhersteller. Ein Halbleiter kann Sicherheitsmechanismen bereitstellen, etwa Lockstep-Kerne, Speicherfehlerkorrektur, Überwachungsfunktionen oder Diagnosefunktionen. Ob diese Mechanismen für ein konkretes Fahrzeugprojekt ausreichen, hängt jedoch vom tatsächlichen Einsatzkontext, der Systemarchitektur und den Sicherheitsanforderungen ab.

ISO 26262 Teil 11 enthält Leitlinien zur Anwendung der Norm auf Halbleiter. Dabei spielen Annahmen über den Einsatzkontext, Safety Manuals, FMEDA, Diagnoseabdeckung, Fehlermodelle und Integrationshinweise eine große Rolle. Der Integrator muss prüfen, ob die Annahmen des SEooC mit dem konkreten Item übereinstimmen oder ob zusätzliche Maßnahmen erforderlich sind.

Proven in Use und Werkzeugqualifikation

ISO 26262 erlaubt unter bestimmten Bedingungen eine Argumentation über Nutzungsbewährung, häufig als „proven in use“ bezeichnet. Dabei wird begründet, dass ein Element aufgrund ausreichender Felderfahrung, stabiler Nutzung, bekannter Einsatzbedingungen und geringer beobachteter Ausfallraten für den vorgesehenen sicherheitsbezogenen Einsatz geeignet ist. Diese Argumentation setzt belastbare Daten und eine gute Vergleichbarkeit des Einsatzkontexts voraus.

Proven in Use ist kein Freibrief, um Sicherheitsaktivitäten zu umgehen. Wenn der neue Einsatzkontext wesentlich vom bisherigen Einsatz abweicht, wenn Felddaten unvollständig sind oder wenn sicherheitskritische Anforderungen neu hinzukommen, reicht eine Nutzungsbewährung allein meist nicht aus. Sie ist eine mögliche Argumentationslinie innerhalb einer umfassenden Sicherheitsbewertung.

Auch Entwicklungswerkzeuge können sicherheitsrelevant sein. ISO 26262 betrachtet Werkzeugketten beispielsweise in Softwareentwicklung, modellbasierter Entwicklung, Codegenerierung, Testautomatisierung, Anforderungsmanagement und statischer Analyse. Wenn ein Werkzeug Fehler einführen oder vorhandene Fehler nicht erkennen kann und diese Fehler sicherheitsrelevant sein können, muss das Tool Confidence Level bewertet werden.

Je nach Tool Confidence Level kann eine Werkzeugqualifikation erforderlich sein. Dabei wird nachgewiesen, dass das Werkzeug für den vorgesehenen Einsatz geeignet ist oder dass seine Risiken durch zusätzliche Maßnahmen beherrscht werden. Beispiele sind Validierung des Werkzeugs, Einschränkung des Einsatzbereichs, unabhängige Prüfungen, Plausibilitätskontrollen oder zusätzliche Tests der erzeugten Ergebnisse.

Konfigurationsmanagement, Varianten und Softwareupdates

Konfigurationsmanagement ist ein zentraler unterstützender Prozess der ISO 26262. Sie müssen nachvollziehen können, welche Anforderungen, Architekturstände, Softwareversionen, Hardwarestände, Analysen, Testnachweise und Freigaben zusammengehören. Ohne kontrollierte Konfigurationen ist ein belastbarer Safety Case kaum möglich.

Besonders anspruchsvoll wird dies bei Plattformen, Derivaten und Varianten. Eine Sicherheitsanalyse für eine Fahrzeugplattform gilt nicht automatisch unverändert für jedes Derivat. Unterschiedliche Sensoren, Aktuatoren, Softwarestände, Fahrzeugmassen, Märkte, Betriebsbedingungen oder Kundenfunktionen können Auswirkungen auf HARA, Sicherheitskonzept, Diagnoseabdeckung und Validierung haben.

Softwareupdates nach Serienstart erhöhen die Anforderungen an Änderungsmanagement und Nachweisführung. Over-the-Air-Updates können sicherheitsrelevante Funktionen verändern, Diagnoseverhalten beeinflussen oder neue Abhängigkeiten schaffen. Deshalb müssen Post-SOP-Änderungen systematisch bewertet, getestet, freigegeben und mit dem bestehenden Safety Case verknüpft werden.

In diesem Kontext sind ISO 24089 für Softwareupdate Engineering und UNECE R156 für Softwareupdate-Managementsysteme besonders relevant. ISO 26262 bleibt wichtig, wenn ein Update Auswirkungen auf funktionale Sicherheit hat. In der Praxis müssen Updateprozesse, Konfigurationsmanagement, Cybersecurity und Functional Safety eng zusammenarbeiten.

ISO 26262 und Änderungsmanagement

Fahrzeugentwicklung dauert häufig mehrere Jahre, und auch nach Serienstart verändern sich Systeme weiter. Während eines Projekts können sich Normen, Kundenanforderungen, Systemarchitekturen, Softwarestände, Lieferantenkomponenten oder gesetzliche Rahmenbedingungen ändern. Jede relevante Änderung kann Auswirkungen auf funktionale Sicherheit haben.

ISO-26262-konformes Änderungsmanagement sollte sicherstellen, dass Sie Änderungen systematisch bewerten. Dazu gehören insbesondere:

• Identifikation der Änderung und ihres Auslösers
• Bewertung sicherheitsrelevanter Auswirkungen
• Prüfung betroffener Anforderungen, Analysen und Nachweise
• Entscheidung über notwendige Re-Analysen oder zusätzliche Tests
• Aktualisierung von Sicherheitskonzepten, Work Products und Freigaben
• Bewertung von Auswirkungen auf Varianten und Derivate
• Dokumentation der Entscheidung und der verantwortlichen Personen

Ein Beispiel aus der Praxis: Wird ein Sensor durch ein neues Modell ersetzt, kann dies Auswirkungen auf Diagnoseabdeckung, Reaktionszeiten, Plausibilitätsprüfungen, Fehlerraten oder Annahmen im Safety Manual haben. Auch wenn die Funktion nach außen unverändert wirkt, kann eine sicherheitsbezogene Neubewertung erforderlich sein.

Ein strukturiertes Informationsmanagement hilft Ihnen, solche Abhängigkeiten früh zu erkennen. Wenn Anforderungen, Komponenten, Analysen, Konfigurationen und Nachweise miteinander verknüpft sind, können Sie die Auswirkungen von Änderungen schneller und belastbarer bewerten.

ISO 26262 und Anforderungen an Lieferanten

In der Automobilindustrie arbeiten Hersteller und Zulieferer eng zusammen. ISO 26262 betrifft daher häufig die gesamte Lieferkette. Sicherheitsanforderungen müssen nicht nur intern beherrscht werden, sondern auch zwischen Unternehmen klar vereinbart und nachvollziehbar umgesetzt sein.

Wichtig sind eindeutige Vereinbarungen zu:

• Sicherheitsanforderungen und ASIL-Einstufungen
• Schnittstellen zwischen Systemen und Komponenten
• Annahmen über den Einsatzkontext
• Verantwortlichkeiten im Sicherheitslebenszyklus
• Entwicklungs-, Analyse- und Prüfmethoden
• bereitzustellenden Work Products und Nachweisen
• Eskalationswegen bei Abweichungen
• Änderungs- und Freigabeprozessen
• Konfigurations- und Versionsmanagement
• Rechten und Pflichten bei Functional Safety Audits oder Assessments

Ein typisches Dokument ist das Development Interface Agreement, kurz DIA. Darin wird festgelegt, wer welche Aufgaben im Sicherheitslebenszyklus übernimmt. Das betrifft beispielsweise Analysen, Verifikationen, Sicherheitsanforderungen, Dokumentationspflichten, SEooC-Annahmen, Lieferantennachweise und Freigabeschritte.

Fehlen solche Vereinbarungen, entstehen schnell Lücken in der Sicherheitsargumentation. Ein OEM kann Nachweise erwarten, die ein Zulieferer nicht eingeplant hat. Umgekehrt kann ein Zulieferer Annahmen über die Systemumgebung treffen, die beim Fahrzeughersteller nicht zutreffen. Solche Unklarheiten führen häufig zu Verzögerungen, Nacharbeit oder Findings in Assessments.

Verhältnis zu anderen Normen und Standards

ISO 26262 steht nicht isoliert. Moderne Fahrzeugfunktionen verbinden funktionale Sicherheit, Cybersecurity, Softwarequalität, künstliche Intelligenz, Datenmanagement, Updatefähigkeit und Produkthaftung. Deshalb müssen Sie häufig mehrere Normen, Standards und Regelwerke gemeinsam betrachten.

Wichtige Bezüge sind:

• IEC 61508: Grundnorm für funktionale Sicherheit
• ISO 21448 / SOTIF: Sicherheit der beabsichtigten Funktion
• Automotive SPICE: Prozessbewertung in Software- und Systementwicklung
• ISO/SAE 21434: Cybersecurity Engineering für Straßenfahrzeuge
• IATF 16949: Qualitätsmanagement in der Automobilindustrie
• ISO 24089: Softwareupdate Engineering für Straßenfahrzeuge
• UNECE R155: Cybersecurity-Managementsystem
• UNECE R156: Softwareupdate-Managementsystem

Ein häufiger Fehler ist die Annahme, ISO 26262 decke alle Sicherheitsfragen moderner Fahrzeuge ab. Das ist nicht der Fall. Die Norm behandelt vor allem Risiken durch Fehlfunktionen von E/E-Systemen. Themen wie Cybersecurity, Softwareupdates, künstliche Intelligenz oder die Sicherheit der beabsichtigten Funktion müssen ergänzend betrachtet werden.

Bei ADAS und automatisierten Fahrfunktionen ist die Abgrenzung zu SOTIF besonders wichtig. Ein System kann technisch fehlerfrei funktionieren und dennoch eine Verkehrssituation falsch interpretieren, ein Objekt nicht erkennen oder außerhalb seiner Leistungsgrenzen arbeiten. Solche Risiken betreffen typischerweise ISO 21448, während ein fehlerhafter Sensorwert, ein Softwaredefekt oder ein Ausfall eines Steuergeräts in den Bereich der ISO 26262 fallen kann.

Auch Cybersecurity und Functional Safety beeinflussen sich gegenseitig. Ein Cyberangriff kann eine sicherheitskritische Fahrzeugfunktion manipulieren, während ein Sicherheitsmechanismus aus Functional-Safety-Sicht die Angriffsfläche oder die Updatefähigkeit beeinflussen kann. In der Praxis sind gemeinsame Risikoanalysen, Safety-Security-Co-Engineering, abgestimmte Anforderungen und klare Konfliktlösungen erforderlich.

ISO-26262-Konformität, Assessments und Produkthaftung

ISO 26262 kennt kein allgemeines Produktzertifikat, das für jede Markteinführung zwingend erforderlich wäre. In der Praxis werden jedoch häufig Functional Safety Assessments, Functional Safety Audits, kundenspezifische Freigaben oder projektspezifische Konformitätsbewertungen durchgeführt. Umfang und Tiefe hängen vom Projekt, ASIL, Kundenanforderungen und organisatorischem Kontext ab.

Eine positive Bewertung bedeutet nicht, dass ein Produkt absolut sicher ist. Sie zeigt vielmehr, dass die angewendeten Prozesse, Analysen, Sicherheitsmaßnahmen und Nachweise im Rahmen der definierten Bewertung als angemessen betrachtet wurden. Offene Punkte, Abweichungen und Annahmen müssen dabei transparent behandelt werden.

Obwohl ISO 26262 nicht pauschal gesetzlich verpflichtend ist, gilt sie in der Automobilindustrie als anerkannter Stand der Technik für funktionale Sicherheit von E/E-Systemen. Damit kann sie für Produkthaftung, Sorgfaltspflichten, Kundenverträge und interne Freigabeentscheidungen eine erhebliche Bedeutung haben. Wer von der Norm abweicht, sollte die Gründe und alternativen Maßnahmen nachvollziehbar dokumentieren.

Bedeutung von ISO 26262 im Normenmanagement

ISO 26262 stellt hohe Anforderungen an den kontrollierten Umgang mit Normen, Anforderungen und Nachweisen. Ein strukturiertes Normenmanagement verbindet die externe Normenwelt mit internen Prozessen, Richtlinien, Projektdokumenten und Verantwortlichkeiten Ihres Unternehmens. Es sorgt dafür, dass relevante Anforderungen nicht nur bekannt sind, sondern in der Organisation wirksam umgesetzt werden können.

Unternehmen müssen unter anderem klären:

• Welche Normversion ist für ein Projekt verbindlich?
• Welche Normteile sind relevant?
• Welche Anforderungen gelten für bestimmte Systeme, Komponenten oder Plattformen?
• Welche internen Prozesse setzen diese Anforderungen um?
• Wer ist für Bewertung, Umsetzung, Prüfung und Freigabe verantwortlich?
• Wie werden Änderungen an Normen erkannt und bewertet?
• Wie werden Normanforderungen in Entwicklung, Qualitätssicherung und Lieferantenmanagement übertragen?
• Wie wird die Umsetzung dokumentiert und nachgewiesen?
• Wie werden projektübergreifende Erfahrungen und Interpretationen der Norm verfügbar gemacht?

Ein digitales Informationsmanagementsystem kann Sie dabei unterstützen, Normdokumente, Geltungsbereiche, Verantwortlichkeiten, Änderungsinformationen und interne Bewertungen zentral zu verwalten. Besonders wertvoll ist die Verknüpfung von Normanforderungen mit internen Richtlinien, Prozessbeschreibungen, Projektvorlagen, Risikobewertungen, Anforderungen und Nachweisen.

Dadurch reduzieren Sie das Risiko, dass veraltete Normstände verwendet, relevante Anforderungen übersehen oder Normänderungen zu spät bewertet werden. Gleichzeitig verbessern Sie die Nachvollziehbarkeit, weil klar erkennbar ist, welche Anforderungen gelten, wie sie interpretiert wurden und welche Maßnahmen daraus entstanden sind.

ISO 26262 in digitalen Informationsmanagementsystemen

Die praktische Umsetzung von ISO 26262 erzeugt eine große Menge an Informationen: Normanforderungen, interne Richtlinien, Sicherheitsanalysen, Anforderungen, Testnachweise, Lieferantendokumente, Freigaben, Änderungsbewertungen und Assessmentberichte. Ohne geeignete Strukturen entstehen schnell Medienbrüche, redundante Datenbestände und unklare Verantwortlichkeiten.

Digitale Informationsmanagementsysteme können Sie dabei unterstützen, ISO-26262-relevante Informationen strukturiert zu erfassen, zu verknüpfen und aktuell zu halten. Besonders hilfreich sind Funktionen wie:

• zentrale Verwaltung relevanter Normen und Normversionen
• Zuordnung von Normanforderungen zu internen Prozessen und Projekten
• Rollen- und Verantwortlichkeitsmanagement
• Änderungsbenachrichtigungen und Bewertungsworkflows
• Verknüpfung mit Anforderungen, Risiken, Tests und Nachweisen
• Versions- und Freigabemanagement
• Audit-Trails und Nachvollziehbarkeit von Entscheidungen
• Such- und Filterfunktionen für Normteile, Anforderungen und Work Products
• Reporting für Management, Projektleitung, Qualitätssicherung und Assessments

Der Nutzen zeigt sich besonders bei wiederkehrenden Projekten, Plattformentwicklungen und internationalen Entwicklungsnetzwerken. Wenn Norminterpretationen, Vorlagen, Bewertungsentscheidungen und Nachweise strukturiert verfügbar sind, können Teams schneller arbeiten und konsistenter dokumentieren. Das reduziert Aufwand im einzelnen Projekt und verbessert die Governance über mehrere Produktlinien und Standorte hinweg.

Agile Entwicklung und ISO 26262

Agile Entwicklung und ISO 26262 schließen sich nicht aus. Entscheidend ist, dass iterative Arbeitsweisen mit klarer Sicherheitsplanung, nachvollziehbaren Anforderungen, definierten Reviews, kontrollierten Änderungen und belastbarer Nachweisführung verbunden werden. Agile Teams müssen sicherstellen, dass sicherheitsrelevante Entscheidungen nicht nur im Sprint-Kontext getroffen, sondern langfristig rückverfolgbar dokumentiert werden.

Kontinuierliche Integration, automatisierte Tests und kurze Feedbackzyklen können die funktionale Sicherheit sogar unterstützen. Voraussetzung ist, dass Testabdeckung, Toolvertrauen, Konfigurationsstände, Freigaben und Abweichungen kontrolliert werden. Sicherheitsanforderungen dürfen nicht in allgemeinen Backlogs untergehen, sondern müssen eindeutig gekennzeichnet, priorisiert und mit den relevanten Safety Work Products verknüpft sein.

Besonders wichtig ist die Synchronisation zwischen Safety Plan und agiler Projektplanung. Wenn Sicherheitsanalysen, Architekturentscheidungen oder Validierungsaktivitäten zu spät erfolgen, entstehen Lücken, die sich durch spätere Iterationen nur schwer schließen lassen. Agile Flexibilität ersetzt daher nicht die strukturierte Sicherheitsargumentation.

Best Practices für den Umgang mit ISO 26262

Für eine wirksame Anwendung der ISO 26262 helfen klare Prozesse, eine belastbare Dokumentationsstruktur und ein aktives Normenmanagement. Besonders bewährt hat sich, Normanforderungen bereits in der Konzept- und Architekturphase zu analysieren. Frühe Analysen reduzieren spätere Nacharbeit und verhindern, dass Sicherheitskonzepte nachträglich in eine bereits festgelegte Architektur eingepasst werden müssen.

Verantwortlichkeiten sollten eindeutig festgelegt werden. Rollen wie Functional Safety Manager, Safety Engineer, System Architect, Hardware Safety Engineer, Software Safety Engineer, Qualitätssicherung, Projektleitung und Lieferantenmanagement müssen wissen, welche Entscheidungen sie treffen und welche Nachweise sie liefern. Auch Eskalationen, Freigaben und Unabhängigkeitsanforderungen sollten früh geklärt werden.

ASIL-Einstufungen sollten immer nachvollziehbar dokumentiert werden. Unklare HARA-Ergebnisse führen später häufig zu Diskussionen mit Kunden, Assessoren oder internen Freigabegremien. Ebenso wichtig ist eine durchgängige Traceability von Hazardous Event über Safety Goal, FSR, TSR, Hardware- und Softwareanforderung bis zu Testnachweis und Safety Case.

Lieferanten sollten früh eingebunden werden. Stimmen Sie Sicherheitsanforderungen, ASIL-Einstufungen, SEooC-Annahmen, Safety Manuals und Work Products rechtzeitig ab, besonders bei komplexen Komponenten oder sicherheitsrelevanten Halbleitern. Späte Klärungen führen häufig zu Konflikten über Verantwortlichkeiten und Lieferumfänge.

Dokumentation sollte projektbegleitend entstehen. In ISO-26262-Projekten ist Dokumentation Teil des Sicherheitsnachweises und nicht nur Vorbereitung auf ein Assessment. Wenn HARA, Sicherheitskonzepte, Reviews, Änderungen oder Testentscheidungen erst nachträglich rekonstruiert werden, sinkt die Qualität der Sicherheitsargumentation erheblich.

Häufige Findings in Audits und Assessments

In Functional Safety Audits und Functional Safety Assessments treten bestimmte Schwachstellen besonders häufig auf. Dazu gehört eine unklare Item Definition, bei der Systemgrenzen, Schnittstellen, Betriebsmodi oder Annahmen nicht ausreichend beschrieben sind. Wenn der Betrachtungsumfang unscharf ist, wirkt sich das auf HARA, Sicherheitsziele und Sicherheitskonzept aus.

Ein weiteres typisches Finding ist fehlende oder lückenhafte Traceability. Wenn nicht nachvollziehbar ist, wie ein Safety Goal in funktionale, technische, Hardware- und Softwareanforderungen überführt wurde, wird die Sicherheitsargumentation schwach. Dasselbe gilt, wenn Testnachweise nicht eindeutig den Anforderungen zugeordnet sind.

Häufig finden Assessoren auch unvollständige HARA-Ergebnisse, unklare ASIL-Begründungen oder nicht aktualisierte Analysen nach Änderungen. Besonders kritisch sind Änderungen an Sensorik, Aktorik, Software, Diagnosen oder Betriebsbedingungen, wenn deren Sicherheitsauswirkungen nicht systematisch bewertet wurden.

Bei Lieferantenprojekten treten oft unklare DIA-Verantwortlichkeiten auf. Wenn nicht festgelegt ist, wer Sicherheitsanalysen, Safety Manuals, Verifikationsnachweise oder Freigaben liefert, entstehen Lücken. Weitere häufige Findings sind verspätete Safety-Validierung, unzureichende Werkzeugbewertung, fehlende Konfigurationskontrolle und nicht ausreichend unabhängige Bestätigungsmaßnahmen.

Typische Missverständnisse

Bei ISO 26262 treten in der Praxis einige Missverständnisse besonders häufig auf. Wenn Sie diese früh vermeiden, verbessern Sie die Qualität Ihrer Sicherheitsarbeit und reduzieren Projektrisiken. Besonders wichtig ist, ISO 26262 nicht als reine Dokumentationsnorm zu verstehen, sondern als methodischen Rahmen für sicherheitsbezogene Entscheidungen.

„ISO 26262 ist nur ein Entwicklungsthema.“
Das stimmt nicht. Die Norm betrifft auch Management, Produktion, Betrieb, Service, Lieferantensteuerung, Änderungsprozesse, Konfigurationsmanagement und Dokumentation. Funktionale Sicherheit ist eine organisationsweite Aufgabe.

„ASIL D bedeutet automatisch, dass ein Produkt sicher ist.“
ASIL D beschreibt eine hohe Sicherheitsanforderungsstufe. Sicherheit entsteht aber erst durch korrekte Analyse, geeignete Architektur, wirksame Maßnahmen, sorgfältige Prüfung und belastbare Nachweisführung.

„QM bedeutet unwichtig.“
Auch wenn ein gefährliches Ereignis als QM eingestuft wird, gelten weiterhin Qualitätsanforderungen. QM heißt nicht, dass keine Sorgfalt erforderlich ist. Es bedeutet nur, dass aus der betrachteten HARA kein ASIL abgeleitet wurde.

„Die Norm kann erst am Ende geprüft werden.“
Eine nachträgliche Prüfung reicht meist nicht aus. ISO 26262 verlangt, dass Sicherheit systematisch über den gesamten Lebenszyklus geplant, umgesetzt und dokumentiert wird. Wer erst am Ende prüft, entdeckt Lücken häufig zu spät.

„Cybersecurity ist vollständig Teil von ISO 26262.“
Nur indirekt. Cybersecurity wird vor allem durch ISO/SAE 21434 adressiert. Beide Themen können sich jedoch gegenseitig beeinflussen, etwa wenn ein Cyberangriff eine sicherheitskritische Fahrzeugfunktion beeinträchtigen kann.

„ADAS-Sicherheit ist vollständig durch ISO 26262 abgedeckt.“
Das ist zu kurz gegriffen. ISO 26262 behandelt Fehlfunktionen von E/E-Systemen. Wahrnehmungsgrenzen, Fehlinterpretationen von Verkehrssituationen oder unzureichende Leistungsfähigkeit einer beabsichtigten Funktion gehören typischerweise in den Bereich SOTIF nach ISO 21448.

Häufige Fragen zu ISO 26262

Was regelt ISO 26262?

ISO 26262 regelt die funktionale Sicherheit elektrischer und elektronischer Systeme in Straßenfahrzeugen. Sie beschreibt Prozesse, Methoden, Rollen und Nachweise, mit denen unzumutbare Risiken durch Fehlverhalten von E/E-Systemen vermieden oder reduziert werden sollen.

Für wen ist ISO 26262 relevant?

Die Norm ist relevant für Fahrzeughersteller, Zulieferer, Entwicklungsdienstleister, Softwareunternehmen, Halbleiterhersteller sowie Qualitäts-, Sicherheits- und Normenverantwortliche. Sie betrifft alle Organisationen, die an sicherheitsrelevanten E/E-Funktionen in der Serienentwicklung oder Serienproduktion von Straßenfahrzeugen beteiligt sind.

Für welche Fahrzeuge gilt ISO 26262:2018?

ISO 26262:2018 gilt für sicherheitsrelevante E/E-Systeme in Straßenfahrzeugen wie Pkw, Lkw, Bussen, Anhängern und Motorrädern. Motorräder werden über Teil 12 mit spezifischen Anpassungen adressiert. Mopeds sind vom Anwendungsbereich ausgenommen.

Was bedeutet ASIL in ISO 26262?

ASIL steht für Automotive Safety Integrity Level. Die Einstufung wird im Rahmen der HARA gefährlichen Ereignissen beziehungsweise Sicherheitszielen zugeordnet und anschließend auf Sicherheitsanforderungen vererbt. Die Stufen reichen von ASIL A bis ASIL D, wobei ASIL D die höchste Sicherheitsanforderungsstufe darstellt.

Was bedeutet QM in ISO 26262?

QM bedeutet, dass aus der betrachteten HARA keine besonderen Sicherheitsanforderungen nach ISO 26262 abgeleitet wurden. Das heißt nicht, dass die Funktion unwichtig ist oder ohne Qualitätsmaßnahmen entwickelt werden darf. Es bedeutet nur, dass für diesen Betrachtungsfall kein ASIL erforderlich ist.

Ist ISO 26262 gesetzlich verpflichtend?

ISO 26262 ist nicht pauschal gesetzlich verpflichtend und in der Regel keine direkte Typgenehmigungsnorm. In der Automobilindustrie gilt sie jedoch als anerkannter Stand der Technik für funktionale Sicherheit von E/E-Systemen. Dadurch kann sie vertraglich, kundenseitig, haftungsbezogen oder praktisch verbindlich sein.

Was ist der Unterschied zwischen ISO 26262 und ISO 21448?

ISO 26262 behandelt Risiken durch Fehlverhalten elektrischer und elektronischer Systeme. ISO 21448, auch SOTIF genannt, behandelt Risiken, die entstehen können, obwohl das System technisch korrekt funktioniert, etwa durch Wahrnehmungsgrenzen, falsche Interpretation einer Fahrsituation oder unzureichende Leistungsfähigkeit eines Fahrerassistenzsystems.

Welche Rolle spielt Normenmanagement bei ISO 26262?

Normenmanagement hilft Ihnen dabei, relevante Normteile, Versionen, Anforderungen, Änderungen und interne Bewertungen zentral zu verwalten. Gerade bei ISO 26262 ist das wichtig, weil viele Anforderungen projektübergreifend umgesetzt, dokumentiert und in Reviews, Functional Safety Audits oder Functional Safety Assessments nachgewiesen werden müssen.

Was ist ein Safety Case?

Ein Safety Case ist eine strukturierte Sicherheitsargumentation. Er zeigt anhand von Sicherheitszielen, Anforderungen, Analysen, Tests, Reviews, Freigaben und weiteren Nachweisen, warum ein Item hinsichtlich funktionaler Sicherheit als ausreichend abgesichert betrachtet werden kann.

Was ist eine HARA?

HARA steht für Hazard Analysis and Risk Assessment, also Gefahren- und Risikoanalyse. Dabei werden gefährliche Ereignisse identifiziert und anhand von Severity, Exposure und Controllability bewertet. Die HARA bildet die Grundlage für Sicherheitsziele und ASIL-Einstufungen.

Was ist ein DIA in ISO-26262-Projekten?

DIA steht für Development Interface Agreement. Dieses Dokument regelt die Aufgabenverteilung zwischen beteiligten Organisationen, zum Beispiel zwischen Fahrzeughersteller und Zulieferer. Es legt fest, wer welche Sicherheitsaktivitäten, Annahmen, Nachweise, Analysen und Freigaben verantwortet.

Was ist ein SEooC?

SEooC steht für Safety Element out of Context. Damit ist ein sicherheitsrelevantes Element gemeint, das ohne vollständige Kenntnis des späteren Fahrzeugsystems entwickelt wird. Der Hersteller dokumentiert Annahmen über den Einsatzkontext, die später im konkreten Projekt geprüft werden müssen.

Was passiert, wenn eine ISO-26262-Anforderung nicht erfüllt wird?

Dann muss bewertet werden, welches Risiko daraus entsteht und ob alternative Maßnahmen möglich sind. Abweichungen sollten dokumentiert, begründet und durch verantwortliche Stellen freigegeben werden. In sicherheitskritischen Bereichen kann eine Nichterfüllung erhebliche Auswirkungen auf Freigabe, Haftung, Kundenabnahme und Projektlaufzeit haben.