EINBLICK IN AEGISSAFEFORGE: VON DER ITEM DEFINITION ZUR FREIGEGEBENEN HARA ARTEFAKT

In unserem vorherigen Beitrag haben wir das Prinzip hinter AegisSafeForge erläutert: Die KI schlägt vor, die Plattform steuert und Menschen entscheiden. Besonders wichtig wird dieses Prinzip, wenn es das Architekturdiagramm verlässt und in einen realen Engineering-Workflow eintritt.

Die Gefährdungsanalyse und Risikobewertung nach ISO 26262 eignet sich gut, um zu zeigen, was das in der Praxis bedeutet.

Die Herausforderung besteht darin, verstreute Projektinformationen in strukturierte Funktionen, Fehlfunktionen, Betriebssituationen, Gefährdungsereignisse, Klassifizierungen, Begründungen und nachgelagerte Safety-Entscheidungen zu überführen.

Ein allgemeiner KI-Assistent kann schnell eine plausibel wirkende Tabelle erzeugen. Plausibilität allein macht diese Tabelle jedoch weder prüfbar noch rückverfolgbar oder zu einer akzeptierten Engineering-Arbeit.

HARA beginnt mit Engineering-Kontext, nicht mit einem leeren Prompt

Der aktuelle Workflow beginnt mit einem Projekt und, sofern relevant, einem System. Teams können einen Requirements Brief sowie unterstützende Projekt- oder Systemdokumente ergänzen, wenn diese verfügbar sind. Anschließend erstellen oder wählen sie eine strukturierte Item Definition aus, bevor HARA-Kandidaten generiert werden.

Dieser Unterschied ist wichtig. Das Modell erhält keine isolierte Anweisung wie „Erstelle eine HARA für ein automatisches Bremssystem“. Die Generierungsanfrage enthält die ausgewählte Item Definition als strukturierte Daten. Abhängig von den bereitgestellten Informationen können dazu Funktionen, Betriebsmodi, Systemgrenzen, Schnittstellen, Umgebungsbedingungen, Annahmen und weiterer safety-relevanter Kontext gehören.

Auch vorhandene HARA-Zeilen werden einbezogen. Dadurch knüpft die Generierung an die bereits geprüfte Tabelle an und kann sich auf fehlende Szenarien konzentrieren, statt jede Anfrage wie eine leere Seite zu behandeln.

Die Plattform kann außerdem relevante Passagen aus Projekt- und Systemdokumenten abrufen, die erfolgreich eingelesen und für den Abruf aktiviert wurden. Gemeinsames Organisationswissen und branchenrelevanter Normenkontext können zusätzliche Fundierung liefern.

Nicht jede hochgeladene Datei wird automatisch verwendet. Sie muss erfolgreich eingelesen, für den Abruf aktiviert, für die Anfrage relevant und innerhalb der Abrufgrenzen ausgewählt sein. Diese Grenze macht den Workflow nachvollziehbar, statt „fundierte KI“ als vages Versprechen zu behandeln.

Vom Kontext zu KI-vorgeschlagenen HARA-Zeilen

Auf Grundlage dieses Kontexts kann AegisSafeForge Kandidatenzeilen für den HARA-Workspace entwerfen. Für eine Analyse nach ISO 26262 kann die KI Funktionen, Fehlverhalten, Betriebssituationen, Gefährdungen, Gefährdungsereignisse, Folgen, Severity, Exposure, Controllability und die Begründungen für diese Vorschläge liefern.

Sie kann außerdem Begründungen auf Zeilen- und Feldebene, Konfidenzinformationen sowie Verweise auf unterstützende Passagen hinzufügen, sofern der abgerufene Kontext diese bereitstellt.

Das Ergebnis ist keine fertige Safety-Analyse. Es ist ein strukturierter Ausgangspunkt, den eine Fachkraft prüfen, hinterfragen, bearbeiten und verbessern kann.

Generierte Zeilen gelangen als KI-Vorschläge in den Workspace und werden als Engineering-Artefakte gespeichert. Sie verschwinden nicht mit einer Chat-Sitzung und werden nicht unbemerkt zu freigegebenen Entscheidungen. Ursprung, Begründungen, Quellen, Status und spätere Änderungen bleiben mit der jeweiligen Zeile verknüpft.

Teams können einen ersten Satz generieren, inkrementelle Kandidaten anfordern, Zeilen manuell hinzufügen und geeignete Zeilen einzeln oder gesammelt prüfen und freigeben. Der Workflow reduziert den Aufwand der leeren Seite, ohne dem Modell Entscheidungsbefugnis zu übertragen.

ASIL wird nicht vom Modell übernommen

Eine der wichtigsten Grenzen des Workflows betrifft den ASIL.

Die KI kann Werte für Severity, Exposure und Controllability vorschlagen und erläutern, weshalb sie diese Klassifizierungen für angemessen hält. Der in AegisSafeForge gespeicherte ASIL wird jedoch anhand der ISO-26262-Matrix der Plattform deterministisch aus S, E und C abgeleitet.

Die Berechnung wird beim Speichern oder Aktualisieren von HARA-Inhalten erneut ausgeführt und bei der Freigabe nochmals geprüft. Dieselben Eingaben führen daher zum selben von der Plattform abgeleiteten Ergebnis; der ASIL wird nicht als uneingeschränkte Modellmeinung übernommen.

Dadurch entsteht eine bewusste Aufgabenteilung.

Die KI übernimmt den semantischen Entwurf. Sie schlägt anhand des verfügbaren Kontexts Szenarien, Beschreibungen, Klassifizierungen und Begründungen vor.

Die Plattform übernimmt wiederholbare Kontrollen. Sie leitet den ASIL ab, validiert erforderliche Daten, setzt Lebenszyklusbedingungen durch, dokumentiert die Herkunft und steuert, ob ein Artefakt nachgelagert verwendet werden darf.

Die Fachkraft übernimmt die Bewertung. Sie entscheidet, ob das Szenario glaubwürdig und vollständig ist, ob S, E und C für das reale Item gerechtfertigt sind und ob die Zeile freigegeben werden soll.

Die deterministische Berechnung hebt die Engineering-Verantwortung nicht auf. Sie sorgt dafür, dass die Konsequenz der akzeptierten Eingaben konsistent, prüfbar und reproduzierbar ist.

Review ist Teil des Artefakts

In AegisSafeForge ist die Prüfung kein Hinweistext unter generiertem Inhalt. Sie ist Teil des Artefaktlebenszyklus.

HARA-Zeilen können unter anderem die Status KI-Vorschlag, von Nutzenden erstellt, bearbeitet, Prüfung erforderlich, Änderungen angefordert, Klärung angefordert, Änderungen umgesetzt, freigegeben und veraltet durchlaufen. Diese Status beeinflussen, welche nächsten Schritte die Plattform zulässt.

KI-generierte Zeilen benötigen vor der Freigabe Quellenangaben. Eine Zeile mit angeforderten Änderungen muss vor der Freigabe den Status Änderungen umgesetzt durchlaufen. Freigegebene Zeilen können nicht direkt bearbeitet werden. Veraltete Zeilen lassen sich nicht manuell ändern, als hätte es keine Veränderung gegeben. Offene Auswirkungsaufgaben oder Traceability-Blocker können eine Freigabe verhindern.

Identität der freigebenden Person, Zeitstempel, Verlauf der Statusübergänge und Begründungen können am Artefakt erhalten bleiben. Die Plattform stellt derzeit nicht jede Zeile als vollständige Thread-Diskussion dar, bewahrt jedoch die Review-Entscheidungen, die den Engineering-Status der Zeile bestimmen.

Das ist die praktische Bedeutung von „Menschen entscheiden“. Die finale Autorität ist kein Satz in einer KI-Richtlinie. Sie zeigt sich in expliziten Aktionen, gespeichertem Status, identifizierbaren prüfenden Personen und konkreten Workflow-Konsequenzen.

Von freigegebenen HARA-Zeilen zu rückverfolgbaren Safety Goals

Die Freigabe einer HARA-Zeile ändert mehr als ein Status-Badge. Sie bestimmt, ob die Zeile zu vertrauenswürdigem Input für den nächsten Schritt werden kann.

Sobald mindestens eine HARA-Zeile freigegeben ist, wird der Safety-Goal-Workspace verfügbar. Safety Goals entstehen als eigenständige Arbeitsergebnisse aus freigegebenen HARA-Zeilen, die mit der ausgewählten Item Definition verknüpft sind — nicht aus ungeprüften Vorschlägen an anderer Stelle der Tabelle.

Die Beziehung zwischen HARA und Safety Goal wird als explizite Artefaktverknüpfung gespeichert. Bevor ein Safety Goal freigegeben werden kann, verlangt die Plattform echte Links zu freigegebenen HARA-Zeilen und prüft, ob sein ASIL dem höchsten ASIL dieser verknüpften Zeilen entspricht.

Über diese Links kann eine prüfende Person ein Safety Goal zu den begründenden HARA-Entscheidungen zurückverfolgen: zu den beitragenden Gefährdungen und Gefährdungsereignissen, ihren S-/E-/C-Klassifizierungen, dem abgeleiteten ASIL und dem Review-Status jeder Quellzeile.

Die Kette setzt sich von Safety Goals zu Functional Safety Requirements, Technical Safety Requirements und Arbeiten an Verifikationsevidenz fort. Freigabegates in jeder Stufe bewahren die Unterscheidung zwischen Entwurf und akzeptierter vorgelagerter Entscheidung. Dadurch lässt sich prüfen, welche Safety-Entscheidung eine Anforderung oder einen Evidenzplan stützt.

Ein vereinfachtes Beispiel für automatische Notbremsung

Betrachten wir eine vereinfachte automatische Notbremsfunktion. Dies ist ein illustratives Beispiel, keine Kundendaten und keine vollständige Projektanalyse.

Die Funktion erkennt eine unmittelbar bevorstehende Kollision und fordert eine Notverzögerung an. Die Fehlfunktion besteht darin, dass die erforderliche Notbremsung nicht angefordert wird. Die Betriebssituation ist eine Stadtfahrt mit 50 km/h, während eine Person einen Fußgängerüberweg betritt.

Das Gefährdungsereignis ist der Ausfall der automatischen Notbremsung bei einer unmittelbar bevorstehenden Kollision mit einer Person. Die mögliche Folge sind lebensbedrohliche oder tödliche Verletzungen.

Eine Fachkraft könnte Severity S3, Exposure E4 und Controllability C3 vorschlagen. Aus diesen akzeptierten Eingaben leitet die Plattform deterministisch ASIL D ab.

Ein beispielhaftes Safety Goal könnte lauten: „Der Ausfall der erforderlichen Notbremsung bei einer unmittelbar bevorstehenden Kollision muss verhindert oder beherrscht werden, sodass das Fahrzeug einen von der Fahrerin oder dem Fahrer kontrollierbaren sicheren Zustand erreicht.“

Das Beispiel verdeutlicht die Aufgabenteilung, macht die Einstufungen jedoch nicht allgemeingültig. Severity, Exposure und Controllability bleiben projektspezifische Engineering-Entscheidungen, die anhand des realen Items, des Betriebskontexts, der Annahmen und der Evidenz fachlich begründet werden müssen.

Traceability von der Item Definition über Safety Goals hinaus

Eine HARA-Tabelle ist nur eine Ansicht eines verknüpften Engineering-Artefakts.

AegisSafeForge bewahrt die Zuordnung zu Projekt und Item Definition, die Identität der HARA-Zeile, die Herkunft aus KI-Generierung, Begründungen, Quellenangaben, Review-Status, Nutzeridentität, Zeitstempel, Inhalts-Hash und Zeilenversion. Abgerufene Evidenz kann Quelldokument, Abschnitt, Seite, Datenblock und unterstützenden Ausschnitt beibehalten.

Item Definition → HARA-Zeile → Safety Goal → Functional Safety Requirement → Technical Safety Requirement → Verifikationsevidenz

Explizite Links tragen die akzeptierte Entscheidung weiter. Prüfende Personen können nachvollziehen, welche HARA-Zeilen ein Safety Goal stützen, welche Anforderungen daraus hervorgehen und welche Evidenz diese Anforderungen verifizieren soll. Linkverlauf, Auswirkungsereignisse, Behebungsaufgaben und Vergleiche mit Tabellen-Baselines schaffen zusätzliche Governance, wenn sich Beziehungen oder Quellinhalte ändern.

Eine aktuelle Grenze bleibt bestehen: Jede HARA-Zeile behält ihre Zuordnung zur Item Definition, doch die kanonische Trace-Verknüpfung von der Item Definition zur HARA wird noch nicht durchgängig automatisch erstellt. Wir vervollständigen diese Verbindung, statt heute eine vollständig automatische Ende-zu-Ende-Traceability zu behaupten. Die nachgelagerten Links von HARA zu Safety Goals und Anforderungen bilden bereits die kontrollierte Trace-Kette, auf der wir aufbauen.

Auf dem Weg zu gesteuerten Änderungsauswirkungen

Safety-Arbeit hört nach der Freigabe nicht auf, sich zu verändern. Funktionen entwickeln sich weiter, Betriebsmodi ändern sich, Annahmen werden überarbeitet und Fachkräfte gewinnen neue Erkenntnisse.

AegisSafeForge enthält bereits die Grundlage für eine gesteuerte Weitergabe von Änderungsauswirkungen über verknüpfte Artefakte. Die Impact Engine kann aktive nachgelagerte Beziehungen durchlaufen, Links als veraltet markieren, Abhängigkeitspfade dokumentieren, Auswirkungsereignisse erzeugen, freigegebene Artefakte erhalten, betroffene Nachfolgeentwürfe anlegen und Behebungsaufgaben eröffnen. Relevante ungelöste Auswirkungen können Freigaben oder nachgelagerte Generierung verhindern.

Dieses Erhaltungsverhalten ist wichtig. Freigegebene Arbeit wird nicht stillschweigend überschrieben, weil sich ein vorgelagerter Wert geändert hat. Der freigegebene Datensatz bleibt erhalten, während die entstandene Auswirkung in einem neuen kontrollierten Workflow bearbeitet wird.

Die automatische Weitergabe einer Änderung der Item Definition in die HARA hängt derzeit jedoch von der Verknüpfung zwischen Item Definition und HARA ab, die noch nicht durchgängig erstellt wird. Deshalb beschreiben wir die Änderungsauswirkung als implementierte Grundlage, die wir über den gesamten Lebenszyklus weiter verbinden und validieren — nicht als heute bereits vollständig geschlossenen Regelkreis.

Was wir als Nächstes stärken

Der Einsatz von KI im Safety Engineering erfordert Transparenz über Grenzen ebenso wie über Fähigkeiten.

Die Dokumentenfundierung hängt derzeit von erfolgreichem Einlesen und Relevanzbewertung ab. Strukturierte Anforderungsobjekte werden noch nicht direkt an die HARA-Generierung übergeben. Die semantische Duplikaterkennung ist noch keine deterministische Kontrolle, und die Validierung zulässiger Einstufungswerte muss über die vorhandenen Pflichtfeld- und ASIL-Prüfungen hinaus weiter gestärkt werden.

Wir verbessern außerdem die Regenerierung ausgewählter Zeilen in der aktiven HARA-Oberfläche, die serverseitige Durchsetzung von Freigaberollen, einheitliche Bereitschaftsregeln für generische und offizielle Exporte sowie eine klarere UI-Unterstützung für neue Versionen und die Bearbeitung von Auswirkungen.

Schließlich verfügt das Qualifizierungspaket für das HARA-Werkzeug über eine definierte Baseline und einen Evidenzplan; manuelle Ausführungsevidenz und die unabhängige Freigabe durch Functional Safety sind jedoch noch in Arbeit. Wir bezeichnen den Workflow heute nicht als werkzeugqualifiziert.

Das sind keine Fußnoten, die verborgen werden sollen. Sie gehören zur Vorbereitung der Plattform auf reale Safety-Engineering-Umgebungen, in denen Produktversprechen ebenso prüfbar sein müssen wie die von der Plattform erzeugten Artefakte.

Beschleunigung ohne Übertragung von Autorität

Unser Ziel ist nicht, HARA zu automatisieren. Wir wollen den Weg vom Projektkontext zu einer prüfbaren und rückverfolgbaren HARA strukturierter gestalten und das fachliche Urteil bei jeder safety-relevanten Entscheidung bewahren.

KI kann Teams helfen, die leere Seite zu überwinden. Deterministische Logik kann wiederholbare Kontrollen konsistent machen. Workflow-Status und Traceability können verhindern, dass ein Vorschlag unbemerkt zur akzeptierten Wahrheit wird. Die Fachkraft muss das Item jedoch weiterhin verstehen, das Szenario hinterfragen, die Einstufungen begründen und die Entscheidung verantworten.

So wenden wir unser Produktprinzip in AegisSafeForge an: Die KI schlägt vor, die Plattform steuert und Menschen entscheiden.

Wir suchen Pilotpartner, die AegisSafeForge mit repräsentativen Projektdaten testen, die Einbindung des gesteuerten Workflows in bestehende Safety-Engineering-Prozesse bewerten und seine Auswirkungen auf Entwurf, Review, Änderungskontrolle und Traceability-Aufwand messen.