ISO 26262, ISO 14971, DO-178C: Wer sicherheitskritische Produkte entwickelt, lebt mit der Norm. VPATH AI prüft Ihr Produktwissen kontinuierlich gegen die relevanten Norm-Anforderungen, identifiziert Lücken nach Kritikalität und generiert Audit-Nachweise direkt aus dem vernetzten Engineering-Wissen.
Ein modernes sicherheitskritisches Produkt bringt Tausende Anforderungen, Hunderte Software-Komponenten und Dutzende relevanter Norm-Abschnitte mit. Solange diese Beziehungen in Dokumenten, Tabellen und Tool-Silos verteilt liegen, wächst der Pflegeaufwand nicht linear, sondern überproportional. Jede Änderung an einer Anforderung kann das ASIL-Level verschieben, jede neue Software-Version öffnet Traceability-Lücken, jeder Team-Wechsel verlagert implizites Norm-Wissen aus dem Unternehmen.
Diese Zahlen sind Richtwerte, keine Garantien. Sie entstehen aus dem Zusammenspiel von gepflegter Datenqualität und einem Team, das die KI-Vorschläge konsequent prüft.
Der Arbeitsablauf ist immer derselbe, unabhängig von der Norm. Entscheidend: Er läuft nicht einmal pro Jahr, sondern bei jeder relevanten Änderung. Compliance wird damit zum Dauerzustand statt zum Sprint vor dem Audit.
Die Norm-Anforderungen werden nicht als PDF abgelegt, sondern als formal prüfbare Regeln in einer Referenz-Ontologie modelliert.
Anforderungen, Architektur, Code, Tests aus Polarion, DOORS, Enterprise Architect, Cameo, Jira, Azure DevOps oder einfachen Word-/Excel-Quellen werden in den Knowledge Graph importiert und ontologisch verlinkt.
Abweichungen werden sichtbar, sobald sie entstehen: fehlende Sicherheitsziele, lückenhafte Traceability, inkonsistente ASIL-Vererbung, priorisiert nach Kritikalität.
Die für das Audit benötigten Nachweise werden aus den vernetzten Daten zusammengestellt, inklusive der für die jeweilige Norm üblichen Aufbereitung (z. B. GSN für den Safety Case nach ISO 26262).
ASIL-Analyse über Graph-Traversierung statt Excel-Tabellen: konsistente Vererbung über alle Ebenen, Dekompositionsvarianten mit ihren Implikationen, Unterstützung der Gefährdungs- und Risikoanalyse aus historischer Gefährdungs-Bibliothek. Der Safety Case in Goal-Structuring-Notation entsteht aus den verknüpften Artefakten.
Die Risikomanagement-Akte wird automatisch gepflegt: Jede Anforderungs-Änderung, jede neue Test-Auswertung, jeder Feldbericht aus der Post-Market-Surveillance löst die relevanten Aktualisierungen aus, inklusive MDR-Verknüpfung mit Klinischer Bewertung und PMS.
Tiefe Traceability bis zur einzelnen Codezeile mit Coverage-Nachweisen (Statement, Decision, MC/DC). Lücken in der bidirektionalen Traceability werden sichtbar, sobald sie entstehen. Tool Qualification (TQL-1 bis TQL-5) wird aus dem Graphen vorbereitet.
Über die drei Leitnormen hinaus deckt dieselbe Mechanik weitere Standards ab: IEC 61508 mit ihren Ableitungen (EN 50128 Schienenverkehr, IEC 62061 Maschinensicherheit) sowie ISO/SAE 21434 für Automotive-Cybersecurity, als eigene Norm-Ontologien hinterlegbar.
Jede Entität im Product Knowledge Graph trägt ihre Herkunft mit sich: Aus welchem Anforderungsdokument extrahiert, aus welchem Polarion-Workitem importiert, von welchem Ingenieur erfasst, von welchem KI-Agenten vorgeschlagen und von wem freigegeben, wann genau, mit welcher Modell-Version. Diese Informationen sind nicht Metadaten am Rand, sie sind Teil der Entität selbst. Jeder Audit-Nachweis ist bis zur Quelle rückverfolgbar, jede KI-Empfehlung ist mit ihrer Begründung und ihrer Freigabe-Historie verbunden.
Das ist die Grundvoraussetzung für eine Tool Qualification nach ISO 26262 (TCL-Klassifikation) oder eine Tool Qualification nach DO-330: Die Werkzeugkette muss deterministisch, nachvollziehbar und versioniert sein. Probabilistische Sprachmodell-Ausgaben werden bei sicherheitsrelevanter Logik (etwa der ASIL-Vererbung) deshalb nicht eingesetzt, diese läuft über formale, prüfbare Constraints.
Die Verantwortung für die Korrektheit der Compliance-Aussagen bleibt beim Menschen. Die Compliance-App fungiert in der ISO-26262-Logik als Unterstützungswerkzeug, dessen Ausgaben qualifizierte Sicherheitsverantwortliche prüfen. Sie deckt Inkonsistenzen auf, schlägt Sicherheitsmaßnahmen vor und beschleunigt die Routine. Die finale Freigabe (ob ein Sicherheitsziel ausreichend ist, ob ein Restrisiko akzeptabel ist, ob ein Tool im konkreten Kontext qualifiziert eingesetzt wird) trifft sie nicht. Dieser Schnitt ist die Grundlage dafür, dass KI im sicherheitskritischen Engineering überhaupt einsetzbar ist. Eine Compliance-App, die Verantwortung übernimmt, wäre weder qualifizierbar noch versicherbar.
Voraussetzung ist kein vorhandener Knowledge Graph, der entsteht im Zuge der Einführung. Auch ein Tool-Wechsel ist nicht erforderlich: Anforderungen können in Polarion, DOORS Next Generation, Codebeamer oder einfach in Word und Excel verbleiben.
Anforderungen, Architektur und Tests aus den ALM-Tools werden in den Graphen importiert und ontologisch verlinkt. Bereits dieser Schritt deckt erfahrungsgemäß Traceability-Lücken auf, die zuvor niemandem aufgefallen waren.
Die für das nächste Audit relevante Norm wird als Ontologie hinterlegt und gegen den Bestand geprüft. Das Ergebnis: priorisierte Findings statt eines Pauschal-Audits am Ende des Projekts.
Weitere Normen, weitere Produktlinien, tiefere Automatisierung. Ein klar abgegrenztes Pilotprojekt (eine Norm, eine Produktlinie, ein Team) läuft typischerweise sechs bis acht Wochen vom Kick-off bis zu den ersten belastbaren Ergebnissen.
Wer DFMEA, PFMEA und FMEDA gemäß ISO 26262 sauber führen will, findet in TRiAS (unserem Technischen Risiko-Analyse-System) die KI-gestützte FMEA-Lösung, die kontinuierlich aus dem Knowledge Graph speist. Compliance-App und TRiAS arbeiten auf derselben Engineering Intelligence Platform.
Mehr zu TRiASISO 26262 (Automotive), ISO 14971 (Medizintechnik) und DO-178C (Aerospace) sind als Norm-Ontologien direkt verfügbar. Verwandte Normen wie IEC 61508, EN 50128, IEC 62304 und ISO/SAE 21434 lassen sich auf derselben Basis ergänzen. Wenn Sie eine branchenspezifische Norm benötigen, sprechen Sie uns an, die Aufnahme einer Norm-Ontologie ist Teil der Standard-Einführungsprojekte.
Die Compliance-App ist als Unterstützungswerkzeug konzipiert. Die sicherheitsrelevante Logik, insbesondere die ASIL-Vererbung, läuft über formale, deterministische Constraints, nicht über probabilistische KI-Ausgaben. Jede KI-Empfehlung ist nachvollziehbar, jeder Audit-Nachweis ist versioniert und rückverfolgbar. Damit sind die Voraussetzungen für die TCL-Klassifikation gegeben; die konkrete Qualifikation im Projektkontext begleiten wir gemeinsam.
Nein. Der Knowledge Graph entsteht im Zuge der Einführung. Ihr bestehendes Anforderungs-, Architektur- und Test-Wissen wird importiert und ontologisch verlinkt. In den ersten Wochen werden dabei in aller Regel bereits Lücken sichtbar, die der bisherigen Tool-Landschaft entgangen sind.
Ja. Unsere Konnektoren importieren und synchronisieren bidirektional mit DOORS Next Generation, Siemens Polarion, Codebeamer und Jama Connect. Auch einfache Quellen wie Word, Excel oder SharePoint werden gelesen. Sie behalten Ihre gewohnte Arbeitsumgebung.
Für jeden im Audit relevanten Sachverhalt (etwa „Welche Tests decken Sicherheitsziel SG-007 ab?") liefert die App eine Antwort mit Quellen: betroffene Artefakte, Herkunftsangabe (Mensch oder KI-Agent), Zeitstempel und Versionsstand. Diese Belege werden in der für die jeweilige Norm üblichen Form (etwa GSN für den Safety Case nach ISO 26262) aufbereitet.
Ein klar abgegrenztes Pilotprojekt (eine Norm, eine Produktlinie, ein Team) läuft in der Regel über sechs bis acht Wochen vom Kick-off bis zu den ersten belastbaren Ergebnissen. Die Skalierung auf weitere Normen und Teams erfolgt anschließend schrittweise.
Sehen Sie in einer 30-minütigen Demo, wie ein Compliance-Check gegen Ihre Norm aussieht, mit anonymisierten Beispieldaten oder in einer geschützten Sandbox mit einem Ausschnitt Ihrer eigenen Engineering-Artefakte.