FMEA, FTA und Safety Case sind die methodischen Säulen funktionaler Sicherheit, doch im Alltag bricht der rote Faden zwischen ihnen auf. VPATH AI verbindet diese Methoden auf einem gemeinsamen Product Knowledge Graph zu einem zusammenhängenden Arbeitsfeld, prüft Konsistenz und Vollständigkeit kontinuierlich und hält die Safety-Argumentation nach ISO 26262, ISO 14971 und DO-178C aktuell.
Funktionale Sicherheit verlangt mehrere Analysen parallel: Eine Gefährdungs- und Risikoanalyse identifiziert die Gefährdungen und bestimmt die geforderte Sicherheitsstufe (ASIL, SIL, DAL oder Risikoklasse). Eine FMEA analysiert die Ausfallarten von Komponenten. Eine FTA verfolgt von einem unerwünschten Ereignis aus die kausalen Pfade rückwärts. Der Safety Case führt alle Analysen zu einem Argumentationsstrang zusammen. Jede Methode hat ihre eigene Werkzeuglandschaft und Sprache, und sobald sich die Architektur ändert, müssten alle vier mitwandern. In der Praxis tun sie das selten konsequent.
Diese Effekte sind keine Garantien. Sie hängen vom Reifegrad der eingebundenen Datenquellen ab und davon, dass das Team die KI-Vorschläge konsequent prüft.
Solange Architektur, Anforderungen, FMEA-Einträge, FTA-Bäume, Gefährdungstabellen und Safety-Case-Argumente in getrennten Tools liegen, kann KI bestenfalls einzelne Aufgaben beschleunigen. Sobald diese Artefakte im Product Knowledge Graph explizit verknüpft sind, kann sie etwas tun, was bisher nicht möglich war: Konsistenz und Vollständigkeit über alle Methoden hinweg kontinuierlich prüfen.
Alle Werkzeuge greifen auf dieselbe Datenbasis zu, und ihre Ergebnisse fließen wieder in den Graphen zurück. Wenn sich die Architektur ändert, propagiert die Änderung durch alle Safety-Artefakte: Welche Gefährdungseinträge betroffen sind, welche FMEA-Annahmen neu zu prüfen sind, welche FTA-Bäume zu aktualisieren sind und welche Safety-Case-Argumente nachgebessert werden müssen, wird sichtbar, ohne dass jemand die Tools manuell synchronisiert.
Für jede Top-Level-Gefährdung werden kausale Fehlerbäume aus der Systemarchitektur abgeleitet. Die quantitative Auswertung liefert Ausfallwahrscheinlichkeiten, die qualitative identifiziert Single-Points-of-Failure und Common-Cause-Failures. Die Bäume bleiben im Knowledge Graph mit Architektur und Sicherheitszielen verknüpft und werden bei jeder Änderung auf Aktualität geprüft, statt als statisches Modell zu veralten.
Aus den Gefährdungen und FTA-Pfaden leitet die App Sicherheitsanforderungen ab, die die Risiken mitigieren: Diagnose-Mechanismen, Redundanzen, Safe-State-Strategien und Maßnahmen gegen systematische Fehler. Das Konzept wird gegen die Architektur geprüft und ist keine PDF-Anlage, sondern eine mit Architekturkomponenten und Verifikationstests verknüpfte Menge an Anforderungen. Bei einer Änderung wird sichtbar, ob die Sicherheitsfunktion noch gewahrt ist.
Jede Sicherheitsanforderung und jedes Sicherheitsziel wird im Knowledge Graph durchgängig mit Architekturkomponenten, Implementierung und Verifikationstests verknüpft. So lässt sich lückenlos nachweisen, dass die Implementierung die Sicherheitsanforderungen und -ziele tatsächlich erfüllt — und bei jeder Änderung wird sichtbar, wo ein Nachweis fehlt oder bricht. Die Traceability-Matrix ist kein nachträglich gepflegtes Dokument, sondern entsteht direkt aus den Beziehungen im Graphen.
Die Methodik der Safety-Analyse ist branchenübergreifend identisch, die normativen Rahmenbedingungen unterscheiden sich. Die Apps adressieren die spezifischen Anforderungen jeder Branche über hinterlegte Norm-Ontologien.
ISO 26262 verlangt für jede Funktion die ASIL-Klassifikation und die daraus folgende Reife von FMEA, FTA und Safety Case. ASPICE setzt zusätzliche Reife-Anforderungen an den Engineering-Prozess. Die Safety-Argumentation läuft typischerweise gemeinsam mit der Cybersecurity-Argumentation nach ISO/SAE 21434.
ISO 14971 ist der Rahmen, in dem die Risikoanalyse mit der MDR-Konformität verknüpft wird; IEC 62304 für Software und ISO 13485 für das QM-System bilden den weiteren Rahmen. Die Methodik passt sich vor allem auf die Post-Market-Surveillance-Pflicht an, die laufende Auswirkungen auf die Risikoanalyse hat.
Ab dem 20. Januar 2027 löst die EU-Verordnung 2023/1230 die Maschinenrichtlinie 2006/42/EG ab. Sie verlangt eine Risikobeurteilung nach EN ISO 12100 mit erweiterten Anforderungen zu KI-Komponenten und Cybersecurity.
DO-178C verlangt für jede Software die DAL-Einstufung mit den daraus folgenden Verifikationsobjektiven; DO-254 ergänzt die Hardware-Seite. Die Methodik von FTA und Safety Case ist übertragbar, mit Anpassungen an die DO-spezifische Terminologie.
Sobald Safety- und Security-Analyse auf demselben Knowledge Graph sitzen, werden Wechselwirkungen sichtbar, die in getrennten Tools verborgen bleiben. Eine Manipulationsmöglichkeit über eine Netzwerkschnittstelle wird zur Safety-Verletzung, sobald sie eine sicherheitsrelevante Funktion betrifft. Eine Safety-Maßnahme, die einen sicheren Zustand erzwingt, kann als Angriffsvektor missbraucht werden, wenn der Angreifer die Erzwingung des Safe State auslösen kann.
Wenn der Safety Concept Generator eine Maßnahme vorschlägt, prüft die App im Graphen, ob sie mit den verbundenen Cybersecurity-Anforderungen kompatibel ist. Entsteht ein Konflikt, wird er sichtbar markiert, und das Team kann Safety und Security gemeinsam betrachten.
Safety-Analyse ist die Disziplin, in der die Folgen einer Fehleinschätzung oft erst spät sichtbar werden, manchmal Jahre nach Auslieferung. Die Verantwortung für Vollständigkeit und Angemessenheit bleibt deshalb beim Safety-Engineer, der die geforderte Reife (ASIL bei ISO 26262, SIL bei IEC 61508, Risikoklasse bei ISO 14971) trägt. Die drei Apps und TRiAS sind als Vorbereitungs- und Konsistenzwerkzeuge konzipiert, nicht als Entscheidungsinstanz: Sie generieren Gefährdungsvorschläge aus Bibliotheken, prüfen Vollständigkeit gegen Norm-Anforderungen, machen Konflikte sichtbar und verbinden die Methoden-Säulen. Die fachliche Freigabe trifft das Safety-Team. Jede KI-generierte oder KI-veränderte Aussage trägt im Graphen ihre Provenance, was die Audit-Argumentation gegenüber Behörden und Benannten Stellen deutlich vereinfacht.
Während Fault Tree Analyzer, FMEA/FTA Automator und Safety Concept Generator als Apps auf der Plattform entstehen, ist die FMEA-Welt bei VPATH AI über das eigenständige Produkt TRiAS abgedeckt: die KI-gestützte FMEA-Plattform für Design-FMEA und Process-FMEA. Identifizierte Gefährdungen und Risiken wandern als Auslöser in die FMEA, FMEA-Ergebnisse speisen den Safety Case, und der Safety Concept Generator prüft die Konsistenz zur FMEA. So ist FMEA kein Silo neben anderen Silos, sondern Teil einer integrierten Safety-Argumentation.
Mehr zu TRiASEin sinnvoller Einstieg orientiert sich am akuten Schmerz. Voraussetzung ist weder eine umgebaute Tool-Landschaft noch eine fertige MBSE-Methodik.
Ist FMEA der akute Schmerz, beginnt der Pilot mit TRiAS. Soll die Gefährdungs- und Risikoanalyse aufgebaut oder modernisiert werden, startet er mit dem Fault Tree Analyzer. Steht die nächste Norm-Auditierung an, beginnt er beim Safety Concept Generator und dem Safety Case.
In den ersten Wochen werden die relevanten Datenquellen angebunden und der bestehende Stand der Safety-Analyse aufgenommen. Bestehende Gefährdungsanalysen, FMEAs und Safety Cases werden importiert und mit der Architektur verknüpft.
Die App liefert ihre ersten Vorschläge, das Team validiert, und der Workflow zwischen den Methoden wird einmal vollständig durchlaufen. Erst danach erweitert sich der Einsatz auf weitere Funktionen, weitere Produkte und tiefere Automatisierung.
ISO 26262 (Automotive Functional Safety), ISO 14971 (Medical Device Risk Management), IEC 61508 (industrielle Funktionale Sicherheit), DO-178C (Avionics-Software) und DO-254 (Avionics-Hardware) sowie EN ISO 12100 (Maschinenbau, in Verbindung mit der EU-Maschinenverordnung 2023/1230). Die jeweilige Norm-Ontologie wird im Projekt-Setup hinterlegt; methodisch ist der Workflow identisch.
TRiAS ist das eigenständige Produkt für Design-FMEA und Process-FMEA, mit Anbindung an Polarion, DOORS und Codebeamer und mit KI-gestützter kontinuierlicher FMEA-Pflege. In der Safety-Analyse-Architektur ist TRiAS eng mit dem Safety Concept Generator und dem FMEA/FTA Automator integriert: Gefährdungs- und Risikoanalysen speisen die FMEA, FMEA-Erkenntnisse fließen in den Safety Case, der Safety Concept Generator prüft die Konsistenz zur FMEA. Mehr Details auf der TRiAS-Produktseite.
Der FMEA/FTA Automator unterstützt die Strukturierung von Safety-Case-Argumenten nach GSN oder vergleichbaren Notationen. Argument-Bäume entstehen aus den im Graphen vorhandenen Belegen (FMEA, FTA, Verifikationstests), Lücken werden sichtbar. Der Safety Case ist damit kein einmalig erstelltes Dokument, sondern ein lebendes Artefakt, das mit der Implementierung Schritt hält.
Beide Disziplinen arbeiten auf demselben Product Knowledge Graph, sodass Safety- und Security-Analyse, Safety Concept und Security Concept, Safety-Verifikation und Security-Validierung strukturell verknüpft sind. Konflikte zwischen Safety- und Security-Maßnahmen werden sichtbar, sobald sie entstehen. Die enge Verschränkung ist gerade im Automotive-Bereich relevant, wo ISO 26262 und ISO/SAE 21434 parallel anzuwenden sind.
Ja. Bestehende Gefährdungsanalysen (typischerweise Excel oder dedizierte Tool-Exporte), FMEAs (APIS IQ, PLATO, MS Excel) und Safety Cases (Word, GSN-Werkzeuge) werden in den Knowledge Graph importiert und mit der Architektur verknüpft. Die App schlägt anschließend Verfeinerungen vor, statt vorhandene Inhalte zu ersetzen. Sie behalten die Hoheit über Ihren bestehenden Safety-Bestand.
Ein abgegrenzter Pilot (eine Funktion oder eine Maschine, ein Team) liefert in der Regel innerhalb von sechs bis acht Wochen erste produktiv nutzbare Ergebnisse. Bei FMEA mit TRiAS sind die Einführungszeiten oft kürzer, weil das Produkt reifer ist. Die Skalierung auf weitere Funktionen und Produkte erfolgt anschließend schrittweise.
Als Pilotkunde begleiten wir die Einführung von Anfang an und entwickeln die Lösung gemeinsam an Ihrem Use Case weiter.