Sicherheitskritische Entwicklung lebt von einer Eigenschaft: lückenloser Nachvollziehbarkeit. Jede Anforderung muss sich auf ein Sicherheitsziel zurückführen lassen, jedes Sicherheitsziel auf eine identifizierte Gefährdung, und jeder Nachweis auf einen Test. In der Theorie ist das eine saubere Kette. In der Praxis zerfällt sie, sobald die Systeme groß genug werden, und genau hier setzt KI-Unterstützung sinnvoll an. Dieser Beitrag zeigt, wo sie hilft, wo ihre Grenzen liegen und was bei der Tool Qualification nach ISO 26262 zu beachten ist.
Warum Functional Safety an ihre manuellen Grenzen stößt
Ein modernes Fahrzeug bringt typischerweise 150 bis 200 Sicherheitsziele mit, abgeleitet aus 800 bis 1.200 identifizierten Gefährdungen und umgesetzt in 3.000 bis 5.000 Safety Requirements. Solange diese Artefakte von Hand verwaltet werden, wächst der Aufwand nicht linear, sondern überproportional, denn entscheidend sind nicht die einzelnen Elemente, sondern ihre Beziehungen zueinander.
Die Folgen sind aus vielen Projekten bekannt: In der Traceability klaffen Lücken von 25 bis 30 Prozent, die ASIL-Vererbung ist über verschiedene Ebenen hinweg inkonsistent, und nach jeder Designänderung veralten die Impact-Analysen, bevor sie fertig dokumentiert sind. Kein Team arbeitet hier nachlässig, die schiere Zahl der Abhängigkeiten überfordert schlicht die Kapazität, die ein Mensch gleichzeitig im Blick behalten kann.
Der Safety-Wissensgraph als gemeinsame Datenbasis
Der naheliegende Ausweg ist, die Beziehungen nicht länger implizit in Dokumenten zu verstecken, sondern sie explizit zu modellieren. Ein Safety-Wissensgraph tut genau das: Er verbindet Sicherheitsziele, Anforderungen, Tests und Komponenten über typisierte Relationen wie derives_from, allocated_to oder verified_by zu einem durchgängigen Netz. Für ein ASIL-D-System entsteht so ein Graph mit 40.000 bis 50.000 Knoten und 150.000 bis 200.000 Relationen.
Der Wert dieses Graphen liegt weniger in seiner Größe als in dem, was er möglich macht. Weil jede Beziehung maschinenlesbar vorliegt, lassen sich Fragen beantworten, die in einer Dokumentenlandschaft praktisch unbeantwortbar sind: Welche Tests hängen an diesem einen Sicherheitsziel? Welche Komponenten sind betroffen, wenn sich eine Annahme ändert? Wo bricht die Argumentationskette ab? Die KI arbeitet nicht auf Vermutungen, sondern auf einer strukturierten Wahrheit.
ASIL-Dekomposition durch Graph-Traversierung
Den deutlichsten Unterschied macht die Fähigkeit, viele Sicherheitspfade gleichzeitig zu betrachten. Wo eine Ingenieurin im Kopf drei bis fünf Pfade parallel verfolgen kann, traversiert ein KI-Agent mehrere hundert auf einmal und prüft die ASIL-Vererbung über Tausende von Elementen, statt über einige Dutzend.
Konkret wird das bei der ASIL-Dekomposition. Für ein Bremssystem mit ASIL-D-Anforderung lassen sich Tausende möglicher Dekompositionsvarianten durchrechnen, um eine tragfähige Aufteilung, etwa ASIL-B(D) plus ASIL-B(D), mit möglichst geringer Hardware-Redundanz zu finden. Eine Analyse, die manuell zwei bis drei Tage bindet, liefert der Graph in deutlich kürzerer Zeit als Vorschlag. Die Betonung liegt auf Vorschlag: Die KI engt den Lösungsraum ein und begründet ihre Empfehlung, die Entscheidung trifft weiterhin ein qualifizierter Mensch.
Gefahrenanalyse mit historischem Kontext
Die Gefährdungs- und Risikoanalyse profitiert besonders davon, dass ein Wissensgraph Erfahrung speichern kann. Aus Tausenden historischer Gefährdungen lassen sich wiederkehrende Muster destillieren, typische Fahrsituationen, Schweregrad-Korrelationen, Expositions- und Kontrollierbarkeitsprofile. Dieses kondensierte Erfahrungswissen steht bei jeder neuen Analyse zur Verfügung, statt im Gedächtnis einzelner Senior-Ingenieure verborgen zu bleiben.
Auf dieser Basis kann die KI Gefährdungen aus dem Systemkontext heraus vorschlagen: Sie prüft die Systemfunktionen gegen bekannte Fehlerarten, kombiniert Umgebungsfaktoren zu kritischen Szenarien und betrachtet die Interaktionen mit Nachbarsystemen. Das Ergebnis ist keine fertige Gefährdungsanalyse, sondern eine strukturierte, vollständige Vorlage, die das Team gezielt bewertet, mit deutlich geringerem Risiko, eine relevante Gefährdung schlicht zu übersehen.
FMEA durch Fehlerprojektion im Wissensgraphen
Ähnlich funktioniert die Unterstützung bei der FMEA. Hinterlegt ist ein Wissensgraph mit über 50.000 dokumentierten Fehlern aus der Automotive-Historie; für jede neue Komponente identifiziert die KI über Ähnlichkeitsabgleich die relevanten Failure Modes. Statt für einen Mikrocontroller mühsam eine Handvoll Fehlerbilder zusammenzutragen, erhält das Team einen umfassenden, aus realen Fällen abgeleiteten Ausgangspunkt.
Entscheidend ist, dass die Analyse nicht auf der Bauteilebene stehen bleibt. Über mehrere Hierarchieebenen hinweg verfolgt der Graph, wie sich Fehler fortpflanzen, und macht so Cross-Domain-Effekte zwischen Systemen sichtbar, die in getrennten Tabellen leicht unentdeckt bleiben. Die folgende Gegenüberstellung fasst zusammen, wo der Hebel am größten ist:
| FMEA-Aktivität | Manuell | Mit Wissensgraph |
|---|---|---|
| Failure Modes pro Komponente | 15–20 | 180–220 |
| Analysierte Fehlerpfade | 50–100 | 3.000–4.000 |
| RPN-Konsistenz über Projekte | moderat | sehr hoch |
| Zeit für 1.000 Failure Modes | ~20 Tage | 1–2 Tage |
Vom Safety Case zur Tool Qualification
Aus den vernetzten Artefakten lässt sich schließlich der Safety Case konstruieren. Die KI leitet aus dem Graphen Goal-Structuring-Notation-Strukturen ab, ordnet Sicherheitsziele hierarchisch, wendet bewährte Argumentationsstrategien an und verknüpft Testnachweise mit den zugehörigen Anforderungen. Was als manuelle Fleißarbeit Wochen kostet, entsteht so in deutlich kürzerer Zeit als belastbarer Entwurf.
Damit ein solches Werkzeug in einem ISO-26262-Kontext eingesetzt werden darf, muss es allerdings qualifizierbar sein, und hier trennt sich seriöse von oberflächlicher KI-Unterstützung. Drei Eigenschaften sind dafür unverzichtbar:
- Nachvollziehbarkeit: Jede Klassifikation und jede Empfehlung lässt sich bis zu den zugrunde liegenden Entscheidungsknoten und Quellen zurückverfolgen.
- Determinismus: Die sicherheitsrelevante Logik, etwa die ASIL-Vererbungsregeln, läuft über feste, formale Constraints, nicht über probabilistische Sprachmodell-Ausgaben.
- Vollständiger Audit Trail: Alle Analyseentscheidungen sind versioniert und rekonstruierbar.
Wichtig: Die Verantwortung für die Korrektheit der Safety-Artefakte bleibt beim Menschen. KI-Werkzeuge werden nach ISO 26262 als Unterstützungstools klassifiziert, deren Ausgaben qualifizierte Ingenieure prüfen. Die KI generiert Vorschläge, deckt Inkonsistenzen auf und beschleunigt die Routine, die finale Freigabe trifft sie nicht.
Einführung in der Praxis
In der Umsetzung hat sich ein schrittweises Vorgehen bewährt. In den ersten beiden Wochen werden die bestehenden Safety-Artefakte aus den ALM-Tools wie DOORS oder Polarion importiert und zum Graphen verknüpft; schon dieser Schritt deckt erfahrungsgemäß redundante und fehlende Verbindungen auf, die zuvor niemandem aufgefallen waren. In den folgenden Wochen lernt das System aus der Safety-Historie, Gefährdungsmuster, FMEA-Templates, bewährte Safety-Architekturen je ASIL-Level.
Der Aufwand für diesen Aufbau ist real, amortisiert sich aber typischerweise schnell, weil die wiederkehrenden Analysen danach auf einer gepflegten, konsistenten Basis laufen.
Impact-Analyse bei Änderungen
Der spürbarste Vorteil im Alltag zeigt sich bei Änderungen. Wird etwa ein Sicherheitsziel im ASIL hochgestuft, propagiert die Auswirkung in Sekundenbruchteilen durch den Graphen: betroffene abgeleitete Anforderungen, betroffene Komponenten, anzupassende Testfälle und Safety-Analysen werden unmittelbar sichtbar, inklusive einer ersten Abschätzung der Hardware-seitigen Folgen. Statt Tage später eine möglicherweise schon wieder veraltete Impact-Analyse zu erhalten, sieht das Team die Konsequenzen, während die Entscheidung noch diskutiert wird.
Was die Zahlen zeigen
Über acht ASIL-D-Projekte hinweg, die mit Safety-Wissensgraph-Unterstützung durchgeführt wurden, zeigt sich ein konsistentes Bild: Der Aufwand sinkt dort am stärksten, wo zuvor stupide, fehleranfällige Handarbeit dominierte.
| Safety-Aktivität | Traditionell | Mit Wissensgraph |
|---|---|---|
| Gefährdungsanalyse (100 Hazards) | ~10 Personentage | ~3 Personentage |
| Safety Concept | ~15 Personentage | ~6 Personentage |
| FMEA (1.000 Items) | ~20 Personentage | ~5 Personentage |
| Safety Case | ~25 Personentage | ~8 Personentage |
| Impact-Analyse (Änderung) | ~2 Personentage | ~2 Stunden |
Wichtig ist die Lesart dieser Zahlen: Die gewonnene Zeit verschwindet nicht, sie verschiebt sich. Weniger Aufwand für das mechanische Zusammentragen und Abgleichen bedeutet mehr Raum für das, was Safety-Arbeit eigentlich ausmacht, das Bewerten kritischer Entscheidungen und das Durchdenken seltener, gefährlicher Randfälle.
Fazit
KI macht Functional Safety nicht überflüssig, sie macht sie beherrschbar. Ein Safety-Wissensgraph mit Hunderttausenden Relationen erlaubt Analysen, die manuell schlicht nicht durchführbar wären, die parallele Betrachtung Hunderter Safety-Pfade, die systematische ASIL-Dekomposition und die unmittelbare Impact-Analyse über mehrere Hierarchieebenen. Voraussetzung dafür ist eine deterministische, nachvollziehbare und auditierbare Werkzeugbasis, die den Anforderungen der ISO 26262 standhält.