HARA - Gefahren- und Risikoanalyse nach ISO 26262

Die HARA - Das Fundament der Funktionalen Sicherheit

In vielen Projekten beginnt die Diskussion über funktionale Sicherheit mit einer scheinbar einfachen Frage: Was macht das System? Für eine HARA reicht diese Frage nicht aus. Entscheidend ist nicht nur die gewünschte Funktion, sondern auch, welches fehlfunktionale Verhalten in welcher Betriebssituation zu einer Gefährdung von Menschen führen kann.

Die HARA, also die Hazard Analysis and Risk Assessment, ist die systematische Gefährdungs- und Risikobewertung nach ISO 26262. Sie ist der zentrale Einstieg in den Sicherheitslebenszyklus, weil sie aus einer Item Definition sicherheitsrelevante Hazardous Events, deren Risikoklassifikation und daraus abgeleitete Safety Goals mit zugehörigem ASIL erzeugt.

Im Kern beantwortet die HARA drei Fragen: Welche Hazards entstehen aus fehlfunktionalem Verhalten? Wie kritisch sind diese Hazards in realistischen Betriebssituationen? Welche abstrakten Safety Goals müssen festgelegt werden, damit das Risiko beherrscht wird?

Einordnung in den ISO-26262-Ablauf

Die HARA wird nach der Item Definition durchgeführt und liegt vor dem Funktionalen Sicherheitskonzept (FSK). Diese Reihenfolge ist nicht beliebig: Ohne Item Definition fehlt der Betrachtungsumfang, ohne HARA fehlen Safety Goals und ASIL als Grundlage für die spätere Anforderungsableitung.

Der Input ist die Item Definition. Sie beschreibt den funktionalen Umfang, die Betriebsgrenzen, Annahmen und relevanten Schnittstellen des betrachteten Items. Sie muss noch keine technische Architektur enthalten. Im Gegenteil: Eine HARA sollte nicht aus einer bereits festgelegten technischen Lösung heraus argumentieren, weil sonst Sicherheitsmechanismen oder Architekturannahmen zu früh in die Risikobewertung einfließen.

Der Output der HARA umfasst:

• Hazardous Events,
• Risikoklassifikation (S, E, C) je Hazardous Event,
• Safety Goals inklusive ASIL von QM bis ASIL D.

Damit bildet die HARA die Brücke zwischen einer neutralen Beschreibung des Items und den sicherheitsbezogenen Entscheidungen im Projekt. Aus ihr folgt, welche Risiken im weiteren Entwicklungsprozess mit welcher Strenge behandelt werden müssen.

Was in einer HARA bewertet wird

Eine HARA bewertet Risiken, nicht Ursachen. Sie fragt also nicht zuerst, ob ein bestimmter Sensor ausfällt, ein Softwarefehler auftritt oder eine Kommunikationsleitung gestört ist. Sie betrachtet fehlfunktionales Verhalten auf Item-Ebene und kombiniert dieses Verhalten mit einer Betriebssituation und relevanten Umweltbedingungen.

Ein Hazardous Event entsteht aus drei Bausteinen:

• dem Hazard, also der Gefährdung aus fehlfunktionalem Verhalten,
• dem Operating Scenario, also der Betriebssituation,
• den Umwelt- und Randbedingungen, die für die Bewertung relevant sind.

Der Fokus liegt auf Personengefährdung. Sachschäden können projektrelevant sein, sind aber nicht der primäre Bewertungsgegenstand der HARA nach ISO 26262. Ebenso werden Sicherheitsmechanismen des Items in dieser Phase nicht kreditiert. Wenn das System später Diagnosen, Plausibilisierungen oder Abschaltungen enthält, gehören diese Maßnahmen in das Sicherheitskonzept und die technische Umsetzung, nicht in die ursprüngliche HARA-Bewertung.

Diese Trennung ist nicht nur formal. Sie verhindert einen der häufigsten Praxisfehler: Teams argumentieren ein Risiko klein, weil sie bereits eine Lösung im Kopf haben. Eine HARA muss zunächst konservativ bewerten, was ohne Berücksichtigung der späteren Gegenmaßnahmen passieren kann.

Die vier Schritte: Situation, Gefährdung, Safety Goal, ASIL

Die HARA folgt einer klaren Schrittlogik, die sich in jedem Projekt wiederfindet. Jeder Schritt reduziert eine andere Unsicherheit im Workshop.

1. Situation: Wo und unter welchen Bedingungen?

Die Situation ist zunächst neutral. Sie beschreibt noch keine Gefährdung und keinen Fehler.

Beispiele:

• Das Fahrzeug fährt mit 120 km/h auf der Autobahn im dichten Verkehr.
• Das Fahrzeug wird innerorts mit etwa 50 km/h im normalen Verkehrsfluss betrieben.

Wichtig ist, die Situation nicht zu grob und nicht zu kleinteilig zu wählen. “Fahren” ist meist zu breit. “Kurvenfahrt bei 73 km/h auf nasser Fahrbahn bei Nacht” kann zu spezifisch sein, wenn dadurch die Bewertung künstlich zersplittert. Eine tragfähige Granularität ist fachlich unterscheidbar und bleibt zugleich arbeitsfähig.

2. Hazard: Was geht schief?

Ein Hazard ist fehlfunktionales Verhalten des Items, das in der betrachteten Situation zu Schaden führen kann. Die Kombination aus Situation und Hazard ergibt das Hazardous Event.

Beispiel: Autobahnfahrt plus unbeabsichtigtes Beschleunigen. Die Fehlfunktion allein ist noch kein vollständig bewertbares Ereignis, weil ihre Kritikalität stark von der Situation abhängt. Unbeabsichtigtes Beschleunigen beim Rangieren ist anders zu bewerten als unbeabsichtigtes Beschleunigen bei hoher Geschwindigkeit im dichten Verkehr.

3. Safety Goal: Was muss verhindert werden?

Aus relevanten Hazardous Events werden Safety Goals abgeleitet. Ein Safety Goal ist ein abstraktes Sicherheitsziel auf Fahrzeug- oder Item-Ebene. Es beschreibt, welches gefährliche Verhalten verhindert oder begrenzt werden muss, ohne bereits die technische Umsetzung festzulegen.

Ein Safety Goal ist deshalb lösungsneutral. Es legt nicht fest, welcher Sensor plausibilisiert, welche Softwarearchitektur verwendet oder welcher Aktuator abgeschaltet wird. Es beschreibt das Sicherheitsziel, das später im Funktionalen Sicherheitskonzept in Functional Safety Requirements verfeinert wird.

4. ASIL: Wie kritisch ist das Risiko?

Der ASIL wird aus der Bewertung von Severity, Exposure und Controllability abgeleitet und dem Safety Goal zugewiesen. Er beschreibt das erforderliche Sicherheitsintegritätsniveau. Ein typisches Beispiel ist S3 x E4 x C3, was in der ASIL-Matrix zu ASIL D führt.

Der ASIL bezieht sich auf Safety Goals, nicht auf Komponenten. Eine Komponente kann Anforderungen mit unterschiedlichen ASIL-Bezügen tragen, doch die HARA weist den ASIL zunächst dem Safety Goal zu.

Severity, Exposure und Controllability richtig verstehen

Die Bewertung über S, E und C ist keine mathematische Multiplikation, sondern eine klassifizierende Bewertung anhand normativer Kategorien und Matrixlogik. Gerade deshalb muss im Workshop sauber dokumentiert werden, warum ein Wert gewählt wurde.

Severity: Schwere möglicher Verletzungen

Die Severity (S) beschreibt die Schwere der möglichen Verletzungen, die aus einem gefährlichen Ereignis resultieren können. Sie bewertet ausschließlich die Auswirkungen auf Menschen und nicht den Sachschaden oder die Systembeeinträchtigung. Damit beantwortet die Severity die Frage, wie gravierend die möglichen Verletzungen sind, wenn das gefährliche Ereignis eintritt.

Gemäß ISO 26262-3 ist die Severity einer der drei gleichrangigen Parameter der Risikobewertung neben Exposure (E) und Controllability (C). Die Bewertung erfolgt unter konservativen Annahmen:

• Es wird angenommen, dass das gefährliche Ereignis vollständig eingetreten ist.
• Es wird keine Wirksamkeit von Sicherheitsmechanismen berücksichtigt.
• Es wird von einer realistischen, aber ungünstigen Unfallkonstellation ausgegangen.

Die Severity ist damit keine Wahrscheinlichkeitsbetrachtung, sondern eine reine Auswirkungsbewertung.

Bewertet werden mögliche Verletzungen von Fahrzeuginsassen, also Fahrer und Passagiere, sowie von anderen Verkehrsteilnehmern wie Fußgängern, Radfahrern oder Fahrern anderer Fahrzeuge. Berücksichtigt werden:

• Art der Verletzung, von leicht bis tödlich,
• Anzahl potenziell betroffener Personen,
• typische Unfallfolgen in der betrachteten Betriebssituation.

Nicht berücksichtigt werden reine Sachschäden, wirtschaftliche Folgen sowie Komfort- oder Verfügbarkeitsverluste.

Die ISO 26262 definiert vier Severity-Stufen:

• S0 - keine Verletzungen: keine gesundheitsrelevanten Auswirkungen.
• S1 - leichte bis mäßige Verletzungen: ohne dauerhafte Beeinträchtigung, beispielsweise Prellungen oder leichte Schnittwunden.
• S2 - schwere Verletzungen mit Überlebenswahrscheinlichkeit: ernsthafte Verletzungen, möglicherweise mit bleibenden Folgen, jedoch nicht unmittelbar lebensbedrohlich.
• S3 - lebensbedrohliche oder tödliche Verletzungen: eine oder mehrere Personen sind potenziell tödlich verletzt.

Mit zunehmender Geschwindigkeit, Fahrzeugmasse und Interaktion mit ungeschützten Verkehrsteilnehmern steigt die Severity typischerweise schnell auf S3.

Die Severity ist konsequent konservativ zu bewerten. Die Norm fordert, dass die Einstufung auf realistischen Unfallannahmen, bekannten biomechanischen Grenzen und typischen Verkehrsunfallszenarien basiert. Wesentliche Grundsätze sind:

• Worst credible case statt absolutem Extremfall,
• kein Herausargumentieren über seltene Randbedingungen,
• bereits die Möglichkeit tödlicher Verletzungen rechtfertigt eine Einstufung als S3.

Eine zu niedrige Severity-Bewertung ist einer der häufigsten systematischen Fehler in der HARA und führt unmittelbar zu einer Unterschätzung des Sicherheitsrisikos.

Exposure: Wahrscheinlichkeit des Auftretens einer Betriebssituation

Die Exposure (E) beschreibt die Wahrscheinlichkeit, mit der eine relevante Betriebssituation auftritt, in der ein identifiziertes Fehlverhalten des Items zu einem gefährlichen Ereignis führen kann. Bewertet wird ausschließlich die Betriebssituation, nicht die Wahrscheinlichkeit eines technischen Fehlers oder einer Systemstörung.

Die Bewertung der Exposure erfolgt unabhängig vom Item-Design und basiert auf einer repräsentativen Nutzung des Fahrzeugs in den Zielmärkten. Wesentlich ist dabei:

• Die Failure Rate des Items wird nicht betrachtet.
• Es wird angenommen, dass jedes Fahrzeug mit dem Item ausgestattet ist.
• Die Anzahl der im Feld befindlichen Fahrzeuge darf nicht zur Reduktion der Exposure herangezogen werden.

Die Exposure wird abgeschätzt auf Basis:

• der Häufigkeit bestimmter Betriebssituationen wie Überholen, Abbiegen oder Stadtverkehr,
• der Dauer, über die sich das Fahrzeug typischerweise in einer solchen Situation befindet, beispielsweise Autobahnfahrt oder Stop-and-go-Verkehr.

ISO 26262 unterscheidet hierfür fünf Expositionsklassen:

• E0 - unglaublich (incredible): Betriebssituationen, die als extrem unwahrscheinlich oder praktisch ausgeschlossen gelten, beispielsweise Naturkatastrophen. Für E0 ist keine ASIL-Ableitung erforderlich.
• E1 - sehr geringe Wahrscheinlichkeit.
• E2 - geringe Wahrscheinlichkeit.
• E3 - mittlere Wahrscheinlichkeit.
• E4 - hohe Wahrscheinlichkeit: Situationen, die während fast jeder Fahrt oder über einen signifikanten Anteil der Betriebszeit auftreten.

Die Norm fordert ausdrücklich, dass jede Exposure-Einstufung mit einer nachvollziehbaren Begründung (Rationale) hinterlegt wird. Diese kann sich stützen auf:

• typische Fahrprofile,
• statistische Nutzungsannahmen,
• Markt- und Einsatzannahmen, beispielsweise urbane oder außerörtliche Nutzung,
• Erfahrungswerte aus vergleichbaren Fahrzeugfunktionen.

Eine zu feingranulare Aufteilung von Betriebssituationen kann zu einer künstlichen Reduktion der Exposure und damit zu einer unangemessenen Absenkung des ASIL führen. Die Norm empfiehlt deshalb die Aggregation ähnlicher Betriebssituationen, sofern sie sicherheitstechnisch vergleichbar sind.

Die Exposure beantwortet, wie häufig sich das Fahrzeug in einer Situation befindet, in der ein gefährliches Ereignis auftreten könnte. Sie trifft keine Aussage über die Schwere möglicher Verletzungen (Severity) oder die Beherrschbarkeit durch Fahrer und Verkehrsteilnehmer (Controllability).

Controllability: Beherrschbarkeit eines gefährlichen Ereignisses

Die Controllability (C) beschreibt die Fähigkeit der beteiligten Personen, ein gefährliches Ereignis durch angemessenes und rechtzeitiges Handeln zu vermeiden oder dessen Auswirkungen zu begrenzen, nachdem die Gefährdung eingetreten ist. Im Fokus steht in der Regel der Fahrer, in bestimmten Fällen auch andere Verkehrsteilnehmer wie Fußgänger, Radfahrer oder Fahrer anderer Fahrzeuge.

Nach ISO 26262 ist die Controllability einer der drei gleichberechtigten Risikoparameter neben Severity (S) und Exposure (E). Sie wird unter der Annahme bewertet, dass die betrachtete Fehlfunktion bereits aufgetreten ist. Wesentliche normative Grundsätze sind:

• Es wird kein korrektes Systemverhalten angenommen.
• Es wird kein zusätzliches sicherheitsgerichtetes Design unterstellt.
• Die Bewertung erfolgt ohne Annahmen zu zukünftigen Sicherheitsmaßnahmen.

Die Controllability ist damit keine Designbewertung, sondern eine situations- und menschenbezogene Risikoeinschätzung. Sie beantwortet die Frage, wie wahrscheinlich es ist, dass ein durchschnittlicher Fahrer oder Verkehrsteilnehmer das gefährliche Ereignis beherrschen kann.

In die Bewertung fließen unter anderem ein:

• Zeit zur Reaktion, also das Reaktionsfenster,
• Möglichkeit zur Wahrnehmung der Situation,
• erforderliche Fahrkompetenz,
• Komplexität der notwendigen Gegenmaßnahme,
• Verkehrs- und Umweltbedingungen.

Nicht betrachtet werden:

• diagnostische Fähigkeiten des Systems,
• Fehlertoleranzmechanismen,
• Warn- oder Notfallfunktionen, da diese in das Sicherheitskonzept gehören.

Die ISO 26262 unterscheidet vier Controllability-Klassen:

• C0 - beherrschbar in jeder Situation: keine sicherheitsrelevante Gefährdung; kann als harmlos betrachtet werden.
• C1 - einfach beherrschbar: Die große Mehrheit der Fahrer oder Verkehrsteilnehmer kann das Ereignis ohne besondere Schwierigkeiten kontrollieren.
• C2 - normalerweise beherrschbar: Die Mehrheit kann reagieren, jedoch sind erhöhte Aufmerksamkeit oder schnelle Reaktionen erforderlich.
• C3 - schwer oder nicht beherrschbar: Nur wenige oder keine Personen können das Ereignis beherrschen; häufig sehr kurze Reaktionszeit oder komplexe Gegenmaßnahmen.

Mit steigender Controllability-Klasse nimmt die Unbeherrschbarkeit und damit das Risiko signifikant zu.

Die ISO 26262 verlangt, dass jede Controllability-Einstufung mit einer plausiblen, nachvollziehbaren Begründung versehen wird. Diese basiert typischerweise auf Annahmen zu:

• durchschnittlicher Fahrerfahrung, also keinem Profi- oder Extremfall,
• realistischen Reaktionszeiten,
• typischem Verkehrsverhalten,
• bekannten menschlichen Limitierungen.

C3 ist der Regelfall, wenn ein Ereignis plötzlich, ohne Vorwarnung und bei höherer Geschwindigkeit auftritt. C1 oder C2 setzen voraus, dass eine klare Wahrnehmung und ausreichend Zeit für eine Reaktion vorhanden sind.

Eine zu optimistische Bewertung der Controllability führt zu einer systematischen Unterschätzung des ASIL und widerspricht dem sicherheitsorientierten Ansatz der Norm. Die Controllability ist der einzige HARA-Parameter, der explizit den menschlichen Faktor berücksichtigt.

Ein Beispiel aus der ASIL-Logik: S3, E2 und C3 führen zu ASIL B. Bei S3, E4 und C3 liegt typischerweise ASIL D nahe.

Safety Goal und Functional Safety Requirement trennen

Ein häufiger Übergabefehler entsteht, wenn Safety Goals bereits wie Anforderungen formuliert werden. Diese Vermischung macht die spätere Ableitung unscharf.

Ein Safety Goal beschreibt, was auf Fahrzeug- oder Item-Ebene sicher sein muss. Beispiel: Unbeabsichtigtes Beschleunigen des Fahrzeugs muss verhindert werden. Es ist abstrakt, gefährdungsorientiert und ASIL-klassifiziert.

Ein Functional Safety Requirement beschreibt, wie dieses Ziel funktional erreicht wird. Beispiel: Das System muss ein Plausibilitätsmonitoring für Fahrpedalsignale bereitstellen oder bei inkonsistentem Signal innerhalb einer definierten Zeit in einen sicheren Zustand übergehen. Diese Anforderungen entstehen im Funktionalen Sicherheitskonzept und müssen tracebar auf das Safety Goal zurückführen.

Die HARA liefert also nicht den vollständigen Anforderungssatz. Sie liefert die Safety Goals und deren ASIL. Der nächste Schritt ist die saubere Verfeinerung im Funktionalen Sicherheitskonzept.

Durchlaufendes Beispiel: elektrische Lenkunterstützung

Die Bewertungslogik wird greifbar, sobald sie an einem konkreten Item entlang läuft. Betrachtet wird eine elektrische Lenkunterstützung, kurz EPS.

Das Item ist die elektrische Lenkunterstützung. Ihre Funktion besteht darin, den Fahrer durch Bereitstellung eines Lenkmoments zu unterstützen. Der betrachtete Betrieb ist öffentlicher Straßenverkehr im Geschwindigkeitsbereich von 0 bis 140 km/h.

Eine relevante Fehlfunktion ist ein unbeabsichtigtes Lenkmoment ohne Fahrerwunsch. Daraus ergibt sich als Hazard eine unbeabsichtigte Richtungsänderung des Fahrzeugs während der Fahrt.

In einer kritischen Betriebssituation, etwa bei höherer Geschwindigkeit im öffentlichen Straßenverkehr, kann dieses Hazardous Event schwerwiegende Folgen haben. Die Exposure kann mit E4 bewertet werden, wenn die Fahrsituation sehr häufig ist. Die Severity kann S3 erreichen, wenn lebensgefährliche oder tödliche Verletzungen plausibel sind. Die Controllability kann C3 sein, wenn ein durchschnittlicher Fahrer die plötzliche Richtungseinleitung kaum beherrschen kann.

Die resultierende Einstufung E4, S3, C3 führt zu ASIL D. Das Safety Goal kann lauten: Die elektrische Lenkunterstützung darf kein unbeabsichtigtes Lenkmoment oberhalb eines definierten Grenzwerts erzeugen.

Dieses Safety Goal ist bewusst noch keine technische Lösung. Ob das Projekt später Momentenbegrenzung, Sensorplausibilisierung, Diagnosen, Watchdogs, redundante Pfade oder Degradationsstrategien einsetzt, wird in den folgenden Sicherheitskonzepten festgelegt.

Typische Fehler in HARA-Workshops

Viele HARA-Probleme entstehen nicht durch fehlendes Normwissen, sondern durch unklare Workshop-Disziplin.

Ein erster Fehler ist die abhängige Bewertung von S, E und C. Wenn Severity bereits mit Blick auf vermeintliche Beherrschbarkeit relativiert oder Exposure mit Blick auf eine angenommene Fehlerwahrscheinlichkeit reduziert wird, verzerrt das Ergebnis. Die Parameter müssen unabhängig begründet werden.

Ein zweiter Fehler ist eine zu grobe Betrachtung der Fehlfunktionen. Wenn mehrere funktional unterschiedliche Fehlverhalten in einem Hazard zusammengefasst werden, verschwimmen Betriebssituationen, Ursachen und mögliche Safety Goals. Das Ergebnis reduziert Risiken nicht ausreichend, weil die spätere Anforderungsableitung unpräzise bleibt.

Der umgekehrte Fehler ist eine übermäßig granulare Betrachtung. Zu viele Spezialfälle erzeugen eine HARA, die kaum noch reviewbar ist und in der sich Teams in Detailvarianten verlieren. Eine tragfähige HARA erkennt, wann ein Szenario tatsächlich eine andere Bewertung braucht und wann es nur eine Variante derselben Bewertungslogik ist.

Ein dritter Fehler ist fehlende HARA-Prozessexpertise. Die fachlichen Systemexperten kennen die Funktion, aber die methodische Bewertung nach ISO 26262 braucht Moderation, klare Begriffe und Erfahrung mit Grenzfällen.

Ein vierter Praxisfehler ist eine zu optimistische Bewertung, um ASIL und Entwicklungsaufwand klein zu halten. Das geschieht selten offen, aber häufig implizit: Controllability wird großzügig ausgelegt, Exposure mit Fehlerwahrscheinlichkeit verwechselt oder Safety Goals so formuliert, dass sie später weniger Aufwand erzeugen. Eine belastbare HARA ist konservativ. Bei begründeten Zweifeln wird die höhere Klasse gewählt.

Was eine belastbare HARA im Projekt leistet

Eine belastbare HARA schafft Klarheit, bevor Architekturentscheidungen teuer werden. Sie dokumentiert, welche Hazardous Events relevant sind, warum S, E und C so bewertet wurden und welche Safety Goals daraus folgen. Sie macht sichtbar, welcher ASIL den weiteren Entwicklungsprozess steuert und wo besondere Nachweistiefe erforderlich ist.

Sie ist außerdem ein Kommunikationsinstrument. Engineering, Safety Management, Projektleitung und Lieferanten können anhand der HARA nachvollziehen, warum bestimmte Anforderungen, Reviews, Tests und Analysen notwendig sind. Damit wird die HARA nicht zu einem Pflichtdokument, sondern zu einem Steuerungsartefakt für die Konzeptphase.

Für die weitere Einordnung lohnt der Blick auf die ASIL-Einstufung: Dort wird die Matrixlogik hinter Severity, Exposure und Controllability vertieft. Für die konkrete Weiterführung der Safety Goals ist anschließend das Funktionale Sicherheitskonzept entscheidend.

Fazit

Die HARA ist der methodische Startpunkt für funktionale Sicherheit nach ISO 26262. Sie identifiziert Hazards aus fehlfunktionalem Verhalten, bewertet Hazardous Events über Severity, Exposure und Controllability und leitet daraus Safety Goals inklusive ASIL ab.

Ihre Qualität entscheidet darüber, ob die spätere Sicherheitsarbeit auf einem tragfähigen Fundament steht. Zu grobe Fehlfunktionen, unsaubere S/E/C-Begründungen oder zu früh eingerechnete Sicherheitsmechanismen führen zu schwachen Safety Goals und später zu Lücken in FSK, TSK, Verifikation und Safety Case.

Eine belastbare HARA bleibt lösungsneutral, konservativ und nachvollziehbar. Genau dadurch schafft sie die Grundlage, auf der funktionale Sicherheitsanforderungen, Architekturentscheidungen und Nachweise belastbar aufgebaut werden können.

Gerade bei komplexen E/E-Systemen zeigt sich der Wert einer HARA nicht im Formular, sondern in der Stabilität der Entscheidungen, die daraus entstehen. Je früher Annahmen, Grenzfälle und Begriffe geklärt sind, desto tragfähiger werden Safety Goals, Anforderungen und spätere Nachweise.