Moderne Fahrzeuge bestehen aus komplexen E/E-Systemen: Steuergeräte, Sensoren, Aktoren, Software und vernetzte Funktionen arbeiten im Verbund. Damit diese Technik unter allen Umständen sicher bleibt, setzt die Branche auf ISO 26262 – Funktionale Sicherheit in der Automobilindustrie. Der internationale Standard überträgt die Prinzipien der allgemeinen Norm IEC 61508 auf die Realität von Straßenfahrzeugen und gibt klare Prozesse, Nachweise und technische Maßnahmen vor, um unakzeptables Risiko zu vermeiden und Restgefahren systematisch zu reduzieren.
Spis Treści
Warum ISO 26262 – Funktionale Sicherheit in der Automobilindustrie heute unverzichtbar ist
Seit der Erstveröffentlichung 2011 hat sich ISO 26262 zum De-facto-Rahmenwerk für sicherheitsrelevante Fahrzeugfunktionen entwickelt. Die Ausgabe 2018 erweitert den Geltungsbereich von Pkw auf nahezu alle Straßenfahrzeuge – inklusive Nutzfahrzeuge, Busse und Motorräder (ohne Mofas) – und adressiert zusätzlich Halbleiter und weitere Spezialthemen. Die Norm verfolgt ein Ziel: Ingenieurteams sollen Risiken, die aus Fehlfunktionen von Elektronik und Software entstehen, früh erkennen, richtig bewerten und mit geeigneten Gegenmaßnahmen auf ein akzeptables Niveau senken. Das Ergebnis sind robuste Architekturen, nachvollziehbare Entwicklungsprozesse und Fahrzeuge, die Sicherheit nicht dem Zufall überlassen.
Im Fokus stehen reale Betriebsbedingungen: wechselnde Umgebungen, Bedienfehler, Abnutzung, zufällige Hardwarefehler und softwarebedingte Fehlfunktionen. ISO 26262 verlangt deshalb nicht nur technische Lösungen wie Redundanz und Diagnose, sondern auch organisatorische Voraussetzungen – von der Kompetenz der Beteiligten über die Qualifikation von Werkzeugen bis hin zu unabhängigen Prüfungen. Wer die Norm ernst nimmt, verankert Sicherheit als Eigenschaft der gesamten Wertschöpfungskette.
ASIL: Risikoklassifizierung verständlich erklärt
Eines der Schlüsselelemente der Norm ist ASIL, der Automotive Safety Integrity Level. Er gibt vor, wie streng Teams eine Funktion auslegen und absichern müssen. Die Skala reicht von QM (nur Qualitätsmanagement, keine zusätzlichen Sicherheitsanforderungen) über ASIL A, B, C bis D. ASIL D steht für die strengsten Anforderungen und betrifft Funktionen, deren Fehlverhalten schwere bis lebensgefährliche Folgen haben kann.
ASIL und ISO 26262 – Funktionale Sicherheit in der Automobilindustrie: S, E, C im Zusammenspiel
Teams bestimmen ASIL während der Hazard Analysis and Risk Assessment (HARA). Sie bewerten jedes potenzielle Gefährdungsszenario entlang der Dimensionen:
- Severity (S): Wie schwerwiegend könnten die Folgen sein?
- Exposure (E): Wie häufig tritt die zu dem Szenario führende Situation real auf?
- Controllability (C): In welchem Maße kann der Fahrer oder die Fahrerin die Situation kontrollieren?
Die Kombination dieser drei Faktoren führt zur ASIL-Einstufung für das jeweilige Risiko. Daraus leiten Ingenieurinnen und Ingenieure Sicherheitsziele, Architekturprinzipien und Validierungsstrategien ab.
Praxisbeispiele für ASIL A bis D
Typische ASIL-D-Funktionen sind Airbags, ABS/ESP oder elektrisches Lenken – hier kann ein Ausfall unmittelbar die Insassensicherheit gefährden. Solche Funktionen verlangen konsequente Fehlerdiagnosen, geeignete Fallbacks und oft auch Redundanz. Weniger kritische Funktionen, etwa bestimmte Komfort- oder Beleuchtungsfunktionen, landen häufig in ASIL A oder sogar QM, wenn die HARA niedrige Risiken belegt. Die Priorisierung sorgt dafür, dass Teams den höchsten Aufwand dort treiben, wo er den größten Sicherheitsgewinn bringt.
Der Sicherheitslebenszyklus nach ISO 26262 – Funktionale Sicherheit in der Automobilindustrie
ISO 26262 strukturiert den kompletten Sicherheitslebenszyklus – von der Idee bis zum Feldbetrieb: Konzept, Systementwurf, Hardware- und Softwareentwicklung, Integration, Tests, Produktion, Betrieb, Service und Außerdienststellung. Auf jedem Schritt fordert die Norm konkrete Ergebnisse: definierte Sicherheitsziele, abgeleitete Systemanforderungen, nachweisbare HW/SW-Architekturen, verifizierte Implementierungen und eine dokumentierte Sicherheitsargumentation (Safety Case). So bleibt über den gesamten Lebenszyklus klar nachvollziehbar, wie das Produkt Risiken mindert und Sicherheitsziele erreicht.
Aufbau der Norm: Teile 1 bis 10 im Überblick
Die Ausgabe 2018 umfasst neun normative Teile (1–9) plus Leitlinien (Teil 10). Zusammen bilden sie ein in sich stimmiges Gerüst. Die folgenden Abschnitte fassen die Kernthemen für die universelle Anwendung zusammen.
Teil 1–2: Begriffe und Management
Teil 1 vereinheitlicht Terminologie und stellt sicher, dass alle Beteiligten denselben Begriffsapparat nutzen (z. B. Fehler, Ausfall, Gefährdung). Teil 2 definiert das Management der funktionalen Sicherheit auf Organisations- und Projektebene: Sicherheitskultur, Rollen, Kompetenzen, Planung, Überwachung, Bestätigungsmaßnahmen und Compliance-Bewertungen.
Teil 3–4: Konzept und Systementwicklung nach ISO 26262 – Funktionale Sicherheit in der Automobilindustrie
In Teil 3 definieren Teams das Item (Systemabgrenzung), führen HARA durch und legen Safety Goals fest. Teil 4 setzt diese Ziele in Systemarchitekturen und abgeleitete Sicherheitsanforderungen um, weist sie Komponenten zu und plant Systemtests sowie die Sicherheitsvalidierung auf Fahrzeugebene.
Teil 5–6: Hardware und Software in ISO 26262 – Funktionale Sicherheit in der Automobilindustrie
Teil 5 richtet den Blick auf Hardware: Architekturen, Annahmen zu Ausfallraten, Metriken wie SPFM (Single Point Fault Metric) und LFM (Latent Fault Metric), Fehlererkennungsmechanismen und Verifikation. Teil 6 adressiert die Software: Anforderungen an Architektur, Codierregeln, statische/dynamische Analysen, Tests (Unit, Integration, System) sowie Kriterien für die Abdeckung. Beide Teile fordern eine enge Verzahnung von Anforderungen, Umsetzung und Nachweisen.
Teil 7–8: Produktion, Betrieb, unterstützende Prozesse
Teil 7 stellt sicher, dass die Serie das Sicherheitsniveau aus der Entwicklung reproduziert: Fertigungsprüfungen, End-of-Line-Tests, Rückmeldeschleifen aus dem Feld, Service-Informationen und kontrollierte Änderungen. Teil 8 bündelt Querschnittsthemen wie Konfigurations- und Änderungsmanagement, Dokumentation, Lieferantensteuerung, Qualifikation von Softwarewerkzeugen und Bewertung vorhandener Komponenten (Proven in Use).
Teil 9–10: Analysen und Leitfäden zu ISO 26262 – Funktionale Sicherheit in der Automobilindustrie
Teil 9 liefert Methoden wie ASIL-Dekomposition, Freedom-from-Interference-Regeln für gemischte ASIL-Level in einem Steuergerät, Dependent-Failure-Analysen sowie die Einordnung klassischer Verfahren (FMEA, FTA) im ISO-26262-Kontext. Teil 10 gibt Auslegungshilfen und Beispiele – hilfreich für Interpretation und pragmatische Umsetzung.
Methoden und Analysen in ISO 26262 – Funktionale Sicherheit in der Automobilindustrie
Der Weg zur Konformität führt über nachvollziehbare, wiederholbare Analysen. Zentral stehen HARA für die frühe Risikobewertung und, darauf aufbauend, technische Analysen auf System-, Hardware- und Softwareebene. Teams kombinieren Top-down- (FTA) und Bottom-up-Methoden (FMEA, FMEDA), um Fehlerursachen und -auswirkungen systematisch zu verstehen. Dependent-Failure-Analysen decken gemeinsame oder korrelierte Ausfälle auf, die Redundanz sonst unterlaufen könnten.
Ein gut strukturierter Safety Case verbindet alle Nachweise: von den Safety Goals über Architekturentscheidungen und Tests bis zu Produktionskontrollen. Er beantwortet die Kernfrage: Warum ist das Produkt gemessen an seinen Risiken ausreichend sicher? Die Antwort entsteht aus klaren Argumentationsketten und evidenzbasierten Referenzen auf Anforderungen, Reviews, Analysen und Testberichte.
Halbleiter, Softwarewerkzeuge und Lieferkette im Kontext von ISO 26262 – Funktionale Sicherheit in der Automobilindustrie
Die Ausgabe 2018 erweitert den Blick auf Halbleiterkomponenten. Moderne SoCs, Beschleuniger und analoge Frontends prägen die Systemarchitektur. Teams müssen Annahmen zu Ausfallmechanismen, Diagnoseabdeckung und Sicherheitsmechanismen der Bausteine verstehen und im Gesamtsystem belegen. Oft liefern Hersteller Sicherheitshandbücher und FMEDA-Daten, die in die HW-Analysen einfließen.
Auch Werkzeuge beeinflussen das Ergebnis: Compiler, Code-Generatoren, Modellierungs- und Testumgebungen können Fehler einführen. ISO 26262 fordert deshalb eine risikobasierte Qualifikation von Softwaretools. Teams beurteilen, welche Toolfehler relevante Artefakte verfälschen könnten, und legen Maßnahmen fest – vom zusätzlichen Review bis zur formalen Toolqualifikation.
Die Lieferkette bleibt ein weiterer Erfolgsfaktor. Schnittstellenvereinbarungen (z. B. Safety Requirements, ASIL-Zuordnungen, Diagnosekonzepte) schaffen Klarheit zwischen OEM und Zulieferern. Reife Prozesse für Konfigurations- und Änderungsmanagement sichern, dass Anpassungen über alle Partner hinweg synchron und nachvollziehbar bleiben.
Typische Stolpersteine und Best Practices auf dem Weg zur Konformität
- Früh starten: Beginne die HARA in der Konzeptphase. Späte Anpassungen an Architektur und Schnittstellen kosten unverhältnismäßig viel Zeit und Budget.
- Traceability durchgängig halten: Verknüpfe Safety Goals, Anforderungen, Architektur, Implementierung, Tests und Nachweise lückenlos.
- Unabhängigkeit planen: Lege früh fest, wer Reviews, Assessments und Bestätigungsmaßnahmen unabhängig durchführt.
- Architektur absichern: Nutze Diagnosemechanismen, Redundanz, Plausibilitätsprüfungen und Freedom from Interference für gemischte ASIL-Level.
- Tool- und Komponentennachweise beschaffen: Plane die Qualifikation relevanter Tools und die Beschaffung von Sicherheitsdokumenten für Halbleiter und Drittkomponenten ein.
- Änderungen kontrollieren: Etabliere ein klares Change Management mit Auswirkungsanalysen auf ASIL, Safety Case und Testpläne.
Diese Grundsätze erhöhen die Planungssicherheit, reduzieren Rework und beschleunigen die Freigabe. Sie helfen zudem, Audits und Assessments auf Anhieb zu bestehen.
Von der Theorie zur Serie: So setzen Teams ISO 26262 effizient um
Erfolgreiche Projekte folgen einem klaren Pfad. Zuerst entsteht die Item Definition mit Systemgrenzen, Schnittstellen und Betriebsbedingungen. Darauf baut die HARA mit Szenarien, S/E/C-Bewertungen und Safety Goals auf. Es folgen funktionale Sicherheitskonzepte und die Systemarchitektur mit Zuweisung von Anforderungen an Subsysteme und Komponenten. Parallel planen Teams die Nachweise: Analysen, Tests, Reviews, Bestätigungsmaßnahmen.
In der HW- und SW-Entwicklung setzen die Teams die abgeleiteten Sicherheitsanforderungen um, messen Diagnoseabdeckung und Architekturmetriken, härten Schnittstellen ab und verifizieren gegen definierte Kriterien. Integration und Systemtests prüfen Normal- und Fehlerszenarien, Fault-Injection belegt Diagnose- und Fallback-Wirkung. Vor SOP stellen Produktionstests und Feldbeobachtungskonzepte sicher, dass das Sicherheitsniveau in die Serie übergeht und im Betrieb gehalten wird.
Ein praxistauglicher Safety Case wächst inkrementell mit. Er sammelt evidenzbasierte Argumente und Referenzen – statt sie am Ende hektisch zusammenzutragen. Diese Disziplin beschleunigt Freigaben und verringert Projektrisiken spürbar.
Unser Beitrag zu ISO 26262 – Funktionale Sicherheit in der Automobilindustrie Projekten
Wir kennen den Weg von der ersten Risikoanalyse bis zur End-of-Line-Prüfung. Wir unterstützen Teams dabei, HARA effizient aufzusetzen, ASIL korrekt abzuleiten, Architekturen zu härten und den Safety Case belastbar zu gestalten. Wir qualifizieren Werkzeuge, moderieren Lieferantenschnittstellen und begleiten Audits sowie Assessments. So wird funktionale Sicherheit nicht zum Add-on, sondern zur integrierten Eigenschaft Deines Produkts.
FAQ
Die Norm deckt den gesamten Sicherheitslebenszyklus für E/E-Systeme in Straßenfahrzeugen ab: HARA und Sicherheitsziele, System-, Hardware- und Softwareentwicklung, Verifikation/Validierung, Produktion, Betrieb und Außerdienststellung.
Teams bestimmen ASIL in der HARA anhand von Severity, Exposure und Controllability. Der resultierende Level (QM, A, B, C, D) steuert Strengegrad von Architektur, Entwicklung, Tests und unabhängigen Maßnahmen.
IEC 61508 ist die branchenübergreifende Baselnorm. ISO 26262 adaptiert sie für Fahrzeuge: eigene Begriffe, HARA/ASIL, fahrzeugspezifische Prozesse und Metriken sowie Anforderungen an Produktion und Feldbetrieb.
Nein. Ergibt die HARA ein niedriges Risiko, reicht QM (Quality Management). Zusätzliche Sicherheitsanforderungen sind dann nicht nötig – gute Entwicklungs- und Qualitätsprozesse genügen.
Bewerte Toolrisiken (mögliche Fehlereinwirkungen), wähle Maßnahmen (z. B. zusätzliche Reviews, Testfallduplikation, formale Qualifikation) und dokumentiere Eignung sowie Restrestrisiko im Projektkontext.
Funktionale Sicherheit und Cybersecurity beeinflussen sich gegenseitig. Sicherheitsziele dürfen nicht durch Angriffe ausgehebelt werden; umgekehrt dürfen Security-Maßnahmen Sicherheitsfunktionen nicht beeinträchtigen. Teams stimmen beide Disziplinen früh ab.