Strukturierter Einstieg in zentrale Begriffe, Abkürzungen und Work Products der funktionalen Sicherheit. Geschrieben für Ingenieure, Projektverantwortliche und Safety-Rollen, die ISO-26262-Begriffe schnell einordnen müssen.
ASIL steht für Automotive Safety Integrity Level. Er beschreibt das erforderliche Sicherheitsintegritätsniveau eines Safety Goals und steuert, wie streng Anforderungen, Architektur, Verifikation, Reviews und Nachweise umgesetzt werden müssen. ASIL reicht von A bis D, wobei ASIL D die höchste methodische Strenge verlangt; QM bedeutet, dass kein ASIL-Pfad nach ISO 26262 fortgeführt wird.
ASIL-Artikel lesenFunktionale Sicherheit bedeutet, dass keine unangemessenen Risiken durch Fehlverhalten elektrischer oder elektronischer Systeme entstehen. Im ISO-26262-Kontext geht es also nicht um jede Form von Fahrzeugsicherheit, sondern um Gefährdungen, die aus fehlerhaftem Verhalten von E/E-Systemen resultieren und durch geeignete Sicherheitsmaßnahmen beherrscht werden müssen.
ISO 26262 ist die zentrale Norm für funktionale Sicherheit von elektrischen und elektronischen Systemen in Straßenfahrzeugen. Sie beschreibt einen Sicherheitslebenszyklus von der Konzeptphase über System-, Hardware- und Softwareentwicklung bis zu Produktion, Betrieb und Außerbetriebnahme. Die Norm arbeitet risikobasiert und nutzt ASIL, um die notwendige Strenge der Sicherheitsaktivitäten festzulegen.
Ein Item ist der betrachtete Funktions- oder Systemumfang, auf den die ISO-26262-Aktivitäten angewendet werden. Es beschreibt, welche Fahrzeugfunktion, Systemgrenzen, Schnittstellen, Betriebsbedingungen und Annahmen betrachtet werden. Eine klare Item-Abgrenzung ist Voraussetzung für HARA, Safety Goals und die spätere Anforderungsableitung.
Ein E/E-System ist ein elektrisches oder elektronisches System im Fahrzeug, zum Beispiel Steuergerät, Sensorik, Aktorik, Kommunikationspfad oder Softwarefunktion. ISO 26262 betrachtet funktionale Sicherheit genau dort, wo Fehlverhalten solcher E/E-Systeme zu sicherheitsrelevanten Gefährdungen führen kann.
QM bezeichnet in der ASIL-Einstufung einen Fall, in dem keine weiteren spezifischen ISO-26262-Aktivitäten für funktionale Sicherheit erforderlich sind. Das bedeutet nicht, dass die Funktion unwichtig ist oder ungetestet bleibt. Es bedeutet nur, dass klassische Qualitätsprozesse und normale Entwicklungsabsicherung aus Sicht der HARA ausreichend sind.
Ein Safety Goal ist ein übergeordnetes Sicherheitsziel auf Item- oder Fahrzeugebene. Es wird aus einem Hazardous Event in der HARA abgeleitet und erhält den zugehörigen ASIL. Safety Goals beschreiben, welches gefährliche Verhalten verhindert oder begrenzt werden muss, ohne bereits die technische Lösung festzulegen.
Ein Work Product ist ein dokumentiertes Ergebnis einer ISO-26262-Aktivität, zum Beispiel HARA, Sicherheitskonzept, Safety Plan, Review-Protokoll oder Testnachweis. Work Products sind die fachliche Grundlage für Reviews, Audits, Assessments und den Safety Case. Entscheidend ist, dass sie aktuell, geprüft und unter Konfigurationskontrolle stehen.
Controllability beschreibt, in welchem Maß ein durchschnittlicher Fahrer oder Verkehrsteilnehmer ein gefährliches Ereignis beherrschen kann, nachdem es eingetreten ist. Bewertet wird ohne Annahme technischer Sicherheitsmechanismen. Kurze Reaktionszeiten, hohe Geschwindigkeit oder schwer erkennbare Situationen führen typischerweise zu einer kritischeren Einstufung.
Exposure beschreibt, wie häufig oder wahrscheinlich eine relevante Betriebssituation im normalen Fahrzeugbetrieb auftritt. Bewertet wird nicht die Wahrscheinlichkeit eines technischen Fehlers, sondern die Häufigkeit der Situation, in der ein Fehlverhalten gefährlich werden kann. Diese Trennung ist wichtig, damit Risiken in der HARA nicht künstlich reduziert werden.
HARA steht für Hazard Analysis and Risk Assessment. Sie identifiziert sicherheitsrelevante Gefährdungen, kombiniert sie mit Betriebssituationen zu Hazardous Events und bewertet diese über Severity, Exposure und Controllability. Ergebnis sind Safety Goals mit ASIL-Einstufung.
HARA-Artikel lesenEin Hazardous Event ist die Kombination aus einer Gefährdung, einer konkreten Betriebssituation und relevanten Randbedingungen. Erst diese Kombination macht ein Risiko bewertbar. Beispiel: Unbeabsichtigtes Lenkmoment ist die Gefährdung; bei hoher Geschwindigkeit im dichten Verkehr wird daraus ein spezifisches Hazardous Event.
Die Item Definition beschreibt den Betrachtungsumfang für die Sicherheitsaktivitäten. Sie enthält Funktion, Betriebsgrenzen, Annahmen, Schnittstellen und relevante Abhängigkeiten des Items. Ohne belastbare Item Definition fehlen der HARA klare Grenzen und die späteren Safety Goals können unscharf werden.
Severity beschreibt die Schwere möglicher Verletzungen, wenn ein Hazardous Event eintritt. Bewertet werden Auswirkungen auf Menschen, nicht Sachschäden oder Komfortverluste. Die Einstufung reicht von keinen Verletzungen bis zu lebensbedrohlichen oder tödlichen Verletzungen.
Das Funktionale Sicherheitskonzept beschreibt, wie die aus der HARA abgeleiteten Safety Goals funktional erfüllt werden sollen. Es enthält Functional Safety Requirements und bleibt noch weitgehend lösungsneutral. Es beantwortet also die Frage, welches sichere Verhalten erforderlich ist, bevor dieses Verhalten technisch im TSK umgesetzt wird.
FSK-Artikel lesenEine Functional Safety Requirement konkretisiert ein Safety Goal auf funktionaler Ebene. Sie beschreibt, welches sichere oder degradierte Verhalten erforderlich ist, bleibt aber noch weitgehend technologie- und architekturneutral. FSRs entstehen im Funktionalen Sicherheitskonzept und müssen eindeutig auf Safety Goals zurückführbar sein.
Eine Hardware Safety Requirement beschreibt sicherheitsrelevante Anforderungen an Hardwareelemente, zum Beispiel an Sensorik, Aktorik, Versorgung, Diagnose oder Überwachung. Sie wird aus technischen Sicherheitsanforderungen abgeleitet und bildet die Grundlage für Hardwarearchitektur, FMEDA, Verifikation und Sicherheitsnachweis.
Eine Software Safety Requirement beschreibt sicherheitsrelevantes Softwareverhalten, zum Beispiel Plausibilisierung, Diagnoseauswertung, Fehlerreaktion, Zustandslogik oder Zeitverhalten. Sie muss verifizierbar, ASIL-konsistent und eindeutig einer übergeordneten technischen Sicherheitsanforderung zugeordnet sein.
Eine Technical Safety Requirement überführt funktionale Sicherheitsanforderungen in konkrete technische Vorgaben auf Systemebene. TSRs beschreiben zum Beispiel Architekturzuordnung, Diagnosemechanismen, Reaktionszeiten, Safe States oder Schnittstellenverhalten. Sie sind die Brücke vom Funktionalen Sicherheitskonzept zur System-, Hardware- und Softwareentwicklung.
Das Technische Sicherheitskonzept konkretisiert die funktionalen Sicherheitsanforderungen auf System- und Architekturebene. Es enthält Technical Safety Requirements, Architekturentscheidungen, Sicherheitsmechanismen und Zuordnungen zu Systemelementen. Es ist die Brücke zur Hardware- und Softwareentwicklung.
TSK-Artikel lesenTraceability ist die nachvollziehbare Verknüpfung von Sicherheitszielen, Anforderungen, Architektur, Implementierung, Tests und Nachweisen. Sie muss vorwärts und rückwärts funktionieren: Man muss zeigen können, wodurch ein Safety Goal umgesetzt wird und warum ein Test oder Work Product sicherheitsrelevant ist. Ohne Traceability wird der Safety Case schwer prüfbar.
Confirmation Measures sind unabhängige Bestätigungsmaßnahmen, mit denen geprüft wird, ob sicherheitsrelevante Work Products, Prozesse und die gesamte Sicherheitsargumentation ausreichend sind. Dazu gehören Confirmation Reviews, Functional Safety Audit und Functional Safety Assessment. Der erforderliche Grad der Unabhängigkeit hängt unter anderem vom ASIL ab.
Das Development Interface Agreement regelt die sicherheitsrelevante Zusammenarbeit zwischen Kunde, Lieferant und gegebenenfalls weiteren Beteiligten. Es legt fest, wer welche Safety-Aktivitäten, Work Products, Nachweise, Annahmen und Schnittstellen verantwortet. Ein wirksames DIA verhindert Lücken und Doppelannahmen in verteilten Entwicklungsprojekten.
Das Functional Safety Assessment bewertet, ob die funktionale Sicherheit des Items ausreichend erreicht wurde. Es betrachtet nicht nur einzelne Dokumente, sondern die gesamte Sicherheitsargumentation inklusive Safety Case, Work Products, offenen Punkten und Nachweisen. Je nach ASIL und Projektkontext ist eine unabhängige Bewertung erforderlich.
Das Functional Safety Audit prüft, ob die angewendeten Prozesse und organisatorischen Maßnahmen zur ISO 26262 passen und im Projekt umgesetzt wurden. Es bewertet also vor allem die Prozesskonformität, Rollen, Planung, Reviews und Safety-Management-Aktivitäten. Es ersetzt nicht die technische Bewertung des Safety Case.
Der Safety Case ist die strukturierte Sicherheitsargumentation eines Items. Er verbindet Claims, Argumente und Evidenzen und zeigt, warum Safety Goals erfüllt, ASIL-klassifizierte Anforderungen umgesetzt und Restrisiken akzeptabel beherrscht sind. Er ist damit die zentrale Grundlage für Assessment und Freigabeempfehlung.
Safety-Case-Artikel lesenDer Safety Plan beschreibt, welche Aktivitäten, Rollen, Verantwortlichkeiten, Meilensteine und Confirmation Measures für funktionale Sicherheit im Projekt vorgesehen sind. Er ist ein Steuerungsdokument des Safety Managements und muss mit Projektfortschritt gepflegt werden. Ein veralteter Safety Plan erzeugt schnell Nachweislücken.
Die Dependent Failure Analysis untersucht abhängige Fehler, die mehrere eigentlich getrennte Sicherheitsmechanismen gleichzeitig betreffen können. Dazu gehören gemeinsame Ursachen, Kaskadeneffekte oder gemeinsame Ressourcen. DFA ist besonders wichtig, wenn Architekturkonzepte auf Redundanz, Unabhängigkeit oder ASIL-Dekomposition beruhen.
Die FMEA ist eine systematische Bottom-up-Analyse möglicher Fehlermodi und ihrer Auswirkungen. Sie hilft, Schwachstellen in Komponenten, Funktionen oder Prozessen zu erkennen und geeignete Maßnahmen abzuleiten. Im ISO-26262-Kontext unterstützt sie die Bewertung systematischer und technischer Fehlerpfade.
Die FMEDA erweitert die FMEA um quantitative Informationen wie Fehlerraten, Diagnoseabdeckung und Sicherheitsmetriken. Sie wird vor allem für Hardware-Sicherheitsnachweise genutzt, um zufällige Hardwarefehler und die Wirksamkeit von Diagnosen zu bewerten. Ihre Ergebnisse fließen typischerweise in Hardware-Metriken und den Safety Case ein.
Die FTA ist eine Top-down-Analyse, die von einem unerwünschten Top Event ausgeht und mögliche Ursachen logisch zerlegt. Sie eignet sich, um Kombinationen von Fehlern zu verstehen, die zu einem sicherheitskritischen Ereignis führen können. Damit ergänzt sie Bottom-up-Methoden wie FMEA oder FMEDA.
Die Release Recommendation ist eine fachliche Freigabeempfehlung aus Sicht der funktionalen Sicherheit. Sie basiert auf Safety Case, offenen Punkten, Verifikations- und Validierungsergebnissen sowie Confirmation Measures. Sie ersetzt keine Managemententscheidung, liefert aber die sicherheitsbezogene Grundlage dafür.
Residual Risk ist das Restrisiko, das nach Umsetzung aller Sicherheitsmaßnahmen verbleibt. In ISO-26262-Projekten muss gezeigt werden, dass dieses Restrisiko akzeptabel ist und kein unangemessenes Sicherheitsrisiko besteht. Der Safety Case macht diese Argumentation nachvollziehbar.
Eine Safety Anomaly ist eine sicherheitsrelevante Abweichung, Auffälligkeit oder offene Fragestellung, die bewertet und kontrolliert werden muss. Sie kann aus Tests, Reviews, Analysen oder Feldbeobachtungen entstehen. Entscheidend ist, dass Auswirkung, Risiko, Entscheidung und Abschluss nachvollziehbar dokumentiert werden.
Start of Production bezeichnet den Übergang in die Serienproduktion. Aus Sicht der funktionalen Sicherheit sollten vor SOP die relevanten Safety-Aktivitäten abgeschlossen, offene Punkte bewertet und der Safety Case ausreichend belastbar sein. SOP ist daher ein wichtiger Bezugspunkt für Assessment und Release Recommendation.