KOMPLETTER LEITFADEN ZUR HARA NACH ISO 26262

HARA steht für Hazard Analysis and Risk Assessment und ist einer der zentralen Arbeitsschritte in ISO 26262. Die HARA verbindet Item Definition, Fehlverhalten, Betriebssituationen, Hazardous Events, Severity, Exposure, Controllability, ASIL und Safety Goals. Sie ist damit nicht nur eine Tabelle, sondern ein Safety-Argument, das später Requirements, Architektur, Verifikation und Safety Case beeinflusst.

Dieser Leitfaden richtet sich an Functional Safety Engineers, Safety Manager, Systemingenieure, OEMs, Tier 1s und Startups, die HARA Software oder ein ISO 26262 Tool evaluieren. Ziel ist ein pragmatischer Workflow: schneller arbeiten, aber Review, Traceability und Engineering-Verantwortung nicht verlieren.

Aegis SafeForge ist eine KI-gestützte Workflow-Plattform für funktionale Sicherheit und Cybersecurity Engineering, HARA, TARA, Requirements Traceability, Artefaktgenerierung, Review Control und auditierbare Engineering-Evidence. Für DACH-Teams ist besonders wichtig, dass KI Vorschläge macht, während Ingenieure prüfen und freigeben.

Was HARA in ISO 26262 bedeutet

Eine HARA identifiziert Hazardous Events, die aus Fehlverhalten eines Items entstehen können. Jedes Hazardous Event wird anhand von Severity, Exposure und Controllability bewertet. Daraus entsteht eine ASIL-Einstufung wie QM, ASIL A, ASIL B, ASIL C oder ASIL D. Diese Einstufung beeinflusst die Strenge der folgenden Safety-Aktivitäten.

Wichtig ist: Eine HARA ist kein isoliertes Dokument. Sie ist die Grundlage für Safety Goals, Functional Safety Requirements, Technical Safety Requirements, Design-Entscheidungen, Verifikation und Safety Case. Deshalb muss eine HARA nachvollziehbar, reviewbar und änderungssicher sein.

Schritt 1: Item Definition sauber erfassen

Die Qualität der HARA hängt stark von der Item Definition ab. Sie beschreibt Funktion, Systemgrenzen, Betriebsmodi, Schnittstellen, Annahmen, Abhängigkeiten und Kontext. Wenn dieser Kontext unklar ist, entstehen später breite oder unprüfbare Hazardous Events.

Eine gute Item Definition beantwortet Fragen wie: Welche Funktion wird analysiert? In welchem Fahrzeugkontext arbeitet sie? Welche Betriebsmodi sind relevant? Welche Schnittstellen und Abhängigkeiten existieren? Welche Annahmen liegen außerhalb des Item-Boundary?

Schritt 2: Fehlverhalten identifizieren

Fehlverhalten beschreibt, wie das Item aus Safety-Sicht falsch reagieren kann. Bei einer Lenkfunktion können das unbeabsichtigte Lenkunterstützung, Verlust der Unterstützung, verzogerte Unterstützung oder Unterstützung in die falsche Richtung sein. Bei Bremsfunktionen können unbeabsichtigtes Bremsen, Verlust einer Assistenz oder verzogerte Verzogerung relevant sein.

Das Fehlverhalten sollte konkret genug sein, um eine Analyse zu ermöglichen, aber nicht schon als detaillierter Komponentenfehler formuliert werden. HARA betrachtet die Auswirkungen auf Item-Ebene. Detailursachen gehoeren später eher in FMEA, FMEDA oder andere Analysen.

Schritt 3: Betriebssituationen und Hazardous Events bilden

Betriebssituationen veraendern das Risiko. Geschwindigkeit, Strassentyp, Verkehrsaufkommen, Wetter, Fahrmanoever und Nutzerzustand beeinflussen Severity, Exposure und Controllability. Ein Funktionsverlust beim Parken ist anders zu bewerten als derselbe Verlust auf der Autobahn.

Ein Hazardous Event kombiniert Fehlverhalten, Betriebssituation und mögliche Konsequenz. Eine gute Formulierung macht diese Kette sichtbar, damit Reviewer prüfen können, ob Szenario, Rating und Safety Goal konsistent sind.

Schritt 4: S, E und C nachvollziehbar bewerten

Severity bewertet möglichen Schaden. Exposure bewertet, wie häufig die Betriebssituation vorkommt. Controllability bewertet, ob Fahrer oder andere Verkehrsteilnehmer den Schaden vermeiden können. Diese Werte sind Engineering-Entscheidungen und müssen nachvollziehbar dokumentiert werden.

KI kann einen ersten Vorschlag für Szenarien und Rationale liefern. Die finale Bewertung muss aber reviewbar bleiben. In SafeForge wird KI-gestütztes Drafting von deterministischer Logik und menschlicher Freigabe getrennt.

Schritt 5: ASIL deterministisch ableiten

ASIL sollte aus Severity, Exposure und Controllability konsistent abgeleitet werden. Diese Logik eignet sich nicht für freie LLM-Entscheidungen. Wenn dieselben S-, E- und C-Werte verwendet werden, muss dasselbe ASIL-Ergebnis entstehen. Genau hier ist deterministische Tool-Logik wichtig.

Schritt 6: Safety Goals schreiben

Safety Goals beschreiben die oberste Safety-Intention zur Beherrschung eines Hazardous Events. Sie sollten klar, reviewbar und auf der richtigen Abstraktionsebene formuliert sein. Ein Safety Goal darf nicht zu früh eine konkrete technische Lösung erzwingen, sondern muss den Weg zu Functional Safety Requirements öffnen.

Das Safety Goal sollte auf die relevanten HARA-Zeilen verlinken und das passende ASIL erben. Wenn mehrere Hazardous Events auf ein Safety Goal abbilden, muss die Herleitung sichtbar bleiben.

Schritt 7: Traceability bis zur Evidence aufbauen

Die HARA entfaltet ihren Wert erst, wenn sie mit Requirements, Architektur, Verifikation und Review-Historie verbunden ist. Hazardous Events müssen zu Safety Goals führen. Safety Goals müssen zu Anforderungen führen. Anforderungen müssen zu Design-Elementen, Tests, Analysen und Evidence führen.

DACH-Teams arbeiten oft in verteilten Toollandschaften. Genau dort bricht Traceability leicht: HARA in Excel, Requirements in einem ALM-System, Reviews per E-Mail und Evidence in Ordnern. Eine dedizierte Funktionale Sicherheit Software reduziert diesen Bruch, wenn sie Traceability während der Arbeit erzeugt.

Typische HARA Fehler

Wo ein KI-gestütztes HARA Tool hilft

KI-gestützte HARA Software kann den Start beschleunigen, Kandidaten für Hazards und Szenarien vorschlagen, Formulierungen normalisieren und fehlende Betriebssituationen sichtbar machen. Der Wert liegt nicht darin, dass KI Safety-Entscheidungen ersetzt. Der Wert liegt darin, dass Experten schneller zu einem reviewbaren ersten Entwurf kommen.

Aegis SafeForge kombiniert KI-gestütztes Drafting mit deterministischer Logik, Review-Gates, Freigabe-Workflows und Traceability. Das macht die Plattform für Teams relevant, die schneller arbeiten wollen, ohne Auditierbarkeit und technische Verantwortung zu verlieren.

FAQ zur HARA