Verbindet die ALM-Tools, die ihr bereits nutzt.
Findet jede Lücke. Besteht das Audit.
Wir machen aus eurer Engineering-Toolchain einen einzigen deterministischen Graphen. Jede Anforderung, jeder Test, jedes Quellcode-Symbol ist mit den Normen verknüpft, die euer Produkt regeln. Jede Lücke wird sichtbar, bevor der Assessor sie findet.
Eine Assessment-Schicht über eurer Safety-Engineering-Toolchain.
Sicherheitskritische Systeme zu bauen ist schwer. Zu beweisen, dass sie sicher sind, ist schwerer. Die Artefakte, die ihr braucht — Anforderungen, Designs, Tests, Quellcode, Nachweise — liegen in einem Dutzend Tools verstreut. Das Einzige, was sie zusammenhält, ist die Sorgfalt eures Teams.
Die heutigen Optionen: dem manüllen Audit vertraün (langsam, unvollständig) oder eine AI-Plattform einführen (schnell, plausibel, nicht auditierbar). Keine liefert, was ein Assessor tatsächlich will — deterministische, wiederholbare Beweise, dass jede anwendbare Norm erfüllt ist.
VI ist die Schicht dazwischen. Wir ersetzen weder Polarion, Jama, codeBeamer, EA, MagicDraw, Git noch irgendein anderes Tool, das ihr bereits nutzt. Wir lesen aus ihnen, bauen einen Wissensgraphen und führen deterministische Analysen darüber aus. Gleicher Input — gleicher Output, jedes Mal, jedes Audit.
Wir sind nicht das nächste Siemens oder Elektrobit. Wir bauen nicht die Toolchain. Wir bauen die Schicht, die beweist, dass die Toolchain geliefert hat, was sie liefern sollte.
Vier Fähigkeiten. Ein Fundament.
Derselbe Wissensgraph und dieselbe deterministische Analyse-Engine, angewendet auf vier verschiedene Probleme. Jede Kompetenz ist domänen-agnostisch — was sich ändert, ist der Norm-Korpus, den ihr ladet.
ADAS-Verifikation
Szenario-basierte Verifikation, digitale Zwillinge, OpenSCENARIO-Replay und die HiL/SiL-Brücke. Aus dem KG beweist ihr, welche Szenarien welche Klauseln von ISO 21448 abdecken und welche ODD-Fragmente eure Auslieferung validiert sind.
In ArbeitSafety-KG-Graph
Die Engine in ihrer Kernform. Jedes ALM-Item, jeder Test, jede Norm-Klausel und jedes Quellcode-Symbol werden zu Knoten in einem typisierten Graphen. Wiederholbare Lückenerkennung über den gesamten Engineering-Stack.
ProduktivMBSE-Brücke — MagicDraw & Sparx EA
Plugins für MagicDraw (Cameo) und Sparx Enterprise Architect mit Live-Zugriff auf das SysML/UML-Objektmodell. Diagramme werden zur Analysezeit dynamisch generiert, nicht statisch exportiert. Vergleichbar mit Kenaro — aber in die Assessment-Schicht integriert statt daneben.
In ArbeitTestgenerierung - SWE.4 / SWE.5
Ableitung von Unit-Tests aus dem AST plus Anforderungen, und Integrationstests aus dem Call-Graph plus Anforderungen. Deterministisch, mit Audit-Trail und bereit zum Rückschreiben in euer ALM.
GeplantEine Lücke ist ein Pfad, der nicht existiert. Wir finden sie alle.
Die Engine läuft jede erwartete Kante im Graphen ab — von Klausel zu Anforderung zu Element zu Test zu Code — und meldet jede Stelle, an der die Kette reißt. Sechs Lückentypen, klassifiziert nach Schwere und Schicht.
Verwaiste Anforderung
Eine Anforderung, die weder mit einem Test, einem Designelement noch einer Norm-Klausel verknüpft ist. Höchstes Audit-Risiko.
REQ-SchichtGerissene Trace
Eine Kette, die auf einer Stufe reißt — typischerweise Anforderung-zu-Element oder Element-zu-Test. Der häufigste Fund.
REQ-SchichtVerwaister Test
Ein Testfall ohne Anforderungs-Verknüpfung. Er dokumentiert Aufwand, aber keine Abdeckung — ein Assessor wird ihn abwerten.
REQ-SchichtUnverfolgter Code
Eine Funktion oder Klasse ohne vorgelagerte Anforderungs-Verknüpfung. Ohne Quellcode-Analyse nicht erkennbar.
CODE-SchichtToter Code
Eine Funktion ohne Aufrufer im statischen Call-Graph. Qualitäts- und Zertifizierungs-Kostenfalle.
CODE-SchichtASIL-Mismatch
Funktions-Komplexität (zyklomatisch, Reach) übersteigt, was ihre ASIL-Klasse tragen kann. Vorab-Warnung.
CODE-SchichtEin echter Graph-Walk
3 fehlende Kanten. 1 veralteter Test. 14.198 verifiziert.
Neun Adapter. Ein Graph. Null Exporte.
Wir bewegen eure Daten nicht. Wir lesen sie dort, wo sie leben, normalisieren sie in ein Graph-Modell und verknüpfen sie mit den Normen, die euer Produkt regeln. Eure Tools bleiben die Source of Truth.
Der einzige Adapter, der kompiliert.
Quellcode-Adapter anderer Tools lesen Diffs und Dateinamen. Wir parsen den AST, leiten den LLVM IR ab und verknüpfen jede Funktion mit ihrer Anforderung, ASIL-Klasse und ihrem Testfall. Der Graph reicht bis in die Implementierung, nicht nur in die Dokumentation.
int safety_check(int x) { if (x > LIMIT) { return -1; } return 0; }
FunctionDecl ‘safety_check’ |-- ParmDecl ‘x’ : int L-- CompoundStmt |-- IfStmt | |-- BinaryOperator ‘>’ | L-- CompoundStmt | L-- ReturnStmt -1 L-- ReturnStmt 0
; linked to REQ-0427 - ASIL D define i32 @safety_check(i32 %x) { %cmp = icmp sgt i32 %x, 100 br i1 %cmp, label %then, label %end then: ret i32 -1 end: ret i32 0 }
Vom ALM-Chaos zum auditierbaren Graphen in vier Stufen.
Ein einziger Durchlauf durch die Engine ingestiert alle Adapter, normalisiert die Daten in ein einheitliches Graph-Modell, reichert sie mit den relevanten Klauseln eurer anwendbaren Normen an und erzeugt Lücken-Reports, die ein Auditor wiederholen kann.
Pullen, nicht pushen
Adapter lesen Items, Revisionen und Links aus jedem Qüllsystem über dessen native API. Nichts wird zurückgeschrieben. Nichts wird gespiegelt.
Ein Schema, acht Dialekte
Polarion-Items, Jira-Issues, EA-Elemente, AST-Knoten und IR-Funktionen werden zu Knoten im selben Graph-Modell — typisiert, adressierbar und versionsstabil.
Norm-bewusste Verknüpfung
Klauseln eurer anwendbaren Normen (ISO 26262, ISO 21434, ASPICE, ISO 13849) werden als zweite Schicht geladen und über deterministische, auditierbare Mappings mit Anforderungen verknüpft.
Wiederholbare Lücken-Analyse
Pfad-Walks, Missing-Edge-Detection und Coverage-Berechnung. Gleicher Input → gleicher Output, jedes Mal. Reports enthalten den exakten Graph-Zustand, aus dem sie erzeugt wurden.
flowchart LR
subgraph SRC[" "]
direction TB
A1[Polarion]
A2[codeBeamer]
A3[Jira]
A4[Confluence]
A5[EA / MagicDraw / PlantUML]
A6[Source Code: libclang + LLVM IR]
A7[Git]
end
SRC --> B[Adapter Layer]
B --> C[Graph Model]
N[Norm Layer
ISO 26262 - 21434
21448 - ASPICE - 13849] --> C
C --> D[Analysis Engine]
D --> E[Gap Reports
Traceability Matrix
Coverage Heatmap]
classDef src fill:#f5f1e8,stroke:#e5dfd0,color:#3a4256
class A1,A2,A3,A4,A5,A6,A7 src
classDef core fill:#eef2ff,stroke:#c7d2fe,color:#1e3a8a
class B,C,D,E core
classDef norm fill:#fef3c7,stroke:#fcd34d,color:#b45309
class N norm
Wie eine Norm-Klausel zu einer Graph-Kante wird.
Der einzige Schritt in der Pipeline, der nicht vollständig deterministisch ist, ist der, der ohnehin menschliches Urteil braucht. Hier seht ihr genau, wo das LLM genutzt wird, wo nicht, und was mit seinem Output passiert.
Vorschlag
Ein lokales LLM schlägt Kandidaten-Mappings zwischen einer Norm-Klausel und euren Anforderungen vor. Output ist strukturiertes JSON mit Confidence-Scores — kein Freitext. Das LLM ist durch euren Norm-Korpus beschränkt, nicht durch ein allgemeines Modell.
lokales LLM - strukturierter OutputValidierung
Die Engine prüft jeden Kandidaten strukturell. Falsche ASIL-Klasse? Kein vorgelagerter Link? Fehlender Test? Der Kandidat wird aussortiert. Nur Kandidaten, die tatsächlich in den Graphen passen, überleben.
deterministisch - StrukturcheckFreigabe
Eure Engineers reviewen die verbliebenen Kandidaten. Freigeben, ablehnen oder annotieren. Jede Freigabe erfasst volle Provenienz: welches LLM hat vorgeschlagen, warum hat es die Validierung bestanden, wer hat freigegeben, wann.
Human-in-the-Loop - Audit-TrailAnalyse
Nach der Freigabe wird das Mapping Teil des Graph-Zustands — versioniert, hash-bar, wiederholbar. Die Lücken-Analyse läuft deterministisch über freigegebene Mappings. Kein LLM in diesem Pfad. Niemals.
deterministisch - wiederholbarDas LLM ist niemals die Source of Truth. Es schlägt vor; die Engine validiert; eure Engineers geben frei. Nur freigegebene Mappings gelangen in den Audit-Evidence-Pfad.
Wir raten nicht. Wir beweisen.
Compliance-Artefakte sind Beweise. Beweise müssen wiederholbar sein. Das LLM sitzt im Vorschlags-Schritt, nicht im Beweis-Schritt — und genau das ist der Punkt.
Das LLM ist der Beweis
Ein Modell generiert finale Anforderungen, Hazards oder Testfälle. Der Output ist der Beweis. Der Assessor fragt: "Wie wurde diese Entscheidung getroffen?" Die Antwort ist eine Token-Verteilung, keine reproduzierbare Regel.
- Gleicher Input → unterschiedlicher Output bei jedem Lauf
- Kein Replay-Trail — nur der finale Text
- Model-Drift zwischen Trainingszyklen
- "Halluzinierte" Anforderungen werden zu Findings
Das LLM schlägt vor; Engineers geben frei
Eine Lücke ist eine fehlende Kante in einem bekannten Graphen. Der Graph wird aus euren Tool-Daten, eurem Norm-Korpus und den freigegebenen Mappings eurer Engineers gebaut. Die Analyse ist ein Pfad-Walk über einen hash-baren Zustand. Gleicher freigegebener Zustand → gleicher Output, jedes Audit.
- Jedes freigegebene Mapping ist Teil des Graph-State-Hash
- Reports enthalten die volle Freigabe-Provenienz — wer, wann, warum
- Der Analyse-Pfad enthält kein LLM — nur Pfad-Walks
- Das LLM ist niemals die Source of Truth
Domänen-agnostisch. Norm-bewusst.
Die Engine selbst ist es egal, ob ihr ein Auto, eine Ladestation, ein Medizingerät oder einen Prozess-Controller baut. Was sich ändert, ist der Norm-Korpus, den ihr ladet — Graph-Modell und Analyse bleiben gleich.
Mehrere aktive Deployments. Alle unter NDA.
Die Engine ist kein Pitch-Deck. Sie läuft bei mehreren Tier-1-Zulieferern über verschiedene Domänen — Automotive ADAS, Industriefahrzeuge, Prozess-Automatisierung. Jedes Deployment ist Single-Tenant, auf Kunden-Hardware und air-gapped von jedem Cloud-Dienst.
Was wir öffentlich sagen können
Was das Konzept-Deployment demonstriert
- Echter ALM-Adapter (Jama), der tausende Items ingestiert
- Git für Quellcode-Historie und AST/IR-Schicht
- Mehrere Norm-Korpora als Graph-Schicht geladen
- Alle Berechnung auf Kunden-Hardware, kein externes Netz
- Keine Cloud-LLMs im Analyse-Pfad
Was die Engine bisher getan hat
- Deterministische Wissensgraphen über mehrere Projekte gebaut
- Manülle Stichproben-Audits durch wiederholbare Lücken-Reports ersetzt
- Anforderungen mit Quellcode-Symbolen via libclang + LLVM IR verknüpft
- Traceability-Evidenz in Minuten statt Wochen erzeugt
- Pre-Assessment-Findings Wochen vor dem formalen Review gefangen
Kundenreferenzen, Deployment-Spezifika und Stack-Details sind unter NDA verfügbar. Wir gehen gerne anonymisierte Deployment-Graphen und Beispiel-Reports in einer vertraulichen Umgebung durch.
Eure Daten. Eür Netzwerk. Eure Regeln.
Wir betreiben keine Cloud. Die Engine läuft auf Hardware, die ihr kontrolliert. Drei Deployment-Modi decken das Spektrum von vollständig isoliert bis selektiv assistiert ab.
On-Premises
Die Engine läuft auf Hardware, die ihr bereitstellt. Wir liefern per Container, unterstützen die Installation und übergeben die Schlüssel. Eure IT betreibt den Rest.
Air-gapped
Keine Netzwerkverbindung zwischen der Engine und der Außenwelt. Kein Cloud-LLM, keine Telemetrie, kein Update-Kanal, der nicht eure IT ist.
Hybrid-RAG
Die Graph-Analyse bleibt deterministisch und lokal. Ein optionaler Chat-Endpunkt kann ein kunden-gehostetes LLM für natürlichsprachliche Q&A gegen den Graphen nutzen.
Was nach der Engine kommt.
Die vier Kernkompetenzen sind auf unterschiedlichen Reifestufen live. Hier ist, was in den nächsten 12 Monaten auf der Engineering-Roadmap steht — Fähigkeiten, die die Engine erweitern, nicht ersetzen.
SWE.4 — Software-Unit-Testgenerierung
Ableitung von Unit-Testfällen aus dem Clang-AST plus verknüpften Anforderungen. Deterministisch, rückverfolgbar und bereit zum Rückschreiben in euer ALM.
ASPICE SWE.4SWE.5 — Software-Integrationstestgenerierung
Ableitung von Integrationstestfällen aus dem LLVM-Call-Graph plus verknüpften Anforderungen. Tests nach tatsächlichen Call-Pfaden seqünzieren, nicht per Hand.
ASPICE SWE.5MBSE-Plugin GA
MagicDraw- und Sparx-EA-Plugins gehen von "In Arbeit" zu "General Availability". Objektmodell-Zugriff, dynamische Diagrammgenerierung und Round-Trip mit dem Assessment-Graphen.
SysML - UMLCross-Deployment-Graph-Föderation
Mehrere VI-Deployments (eure, eurer Zulieferer, eurer OEMs) föderieren sich zu einem einzigen Evidenz-Graphen für organisationsübergreifende Assessments. Auf der Datenschicht weiterhin Single-Tenant.
multi-org - federatedDie harten Fragen, ehrlich beantwortet.
Die Fragen, die ein Safety-Assessor, ein Process-Owner oder euer CISO tatsächlich stellen würde. Wenn hier etwas unklar bleibt, fragt uns direkt.
Was passiert, wenn ein Assessor fragt, wie eine Lücke gefunden wurde?
Wir zeigen ihm den Graph-State-Hash, den exakt gewalkten Pfad, die durchlaufenen Klauseln und Anforderungen, und die fehlende Kante, die identifiziert wurde. Der Report ist wiederholbar: gleicher Graph-Zustand, gleiche Lücken-Liste, gleiche Hashes.
Wo genau nutzt ihr ein LLM, und wo nicht?
Das LLM wird an einer Stelle genutzt: im Vorschlags-Schritt, der Kandidaten-Mappings zwischen Norm-Klauseln und euren Anforderungen vorschlägt. Der Output ist strukturiertes JSON mit Confidence-Scores. Alles danach — strukturelle Validierung, menschliche Freigabe, Graph-Speicherung, Lücken-Analyse, Reportgenerierung — ist deterministisch. Kein LLM im Audit-Evidence-Pfad.
Wie lange daürt es bis zum ersten Lücken-Report?
Typischerweise zwei bis vier Wochen ab initialer ALM-Adapter-Konfiguration: eine Woche für Ingestion und Graph-Build, ein bis zwei Wochen für Norm-Verknüpfung und die erste Freigabe-Runde eurer Engineers, dann der erste Lücken-Report. Der Graph läuft von da an weiter.
Mit welchem ALM-Tool sollten wir starten?
Mit dem, das die Source of Truth für eure Anforderungen ist — meist das, auf das eure Assessor zürst verweisen. Weitere Adapter können parallel hinzukommen; die Engine normalisiert sie alle in denselben Graphen. Die Referenzarchitektur geht diese Reihenfolge durch.
Können wir das vollständig air-gapped betreiben?
Ja. Die Engine läuft auf Kunden-Hardware, der Graph liegt in eurem Netz, das LLM (falls genutzt) ist eures. Keine Telemetrie, kein Update-Kanal, der nicht eure IT ist, keine Cloud-Abhängigkeit. Das ist der Standard für mehrere unserer Deployments.
Wie sieht ein Referenz-Deployment tatsächlich aus?
Wir betreiben die Engine bei mehreren Tier-1-Zulieferern in Automotive ADAS, Industriefahrzeugen und Prozess-Automatisierung. Spezifika — Stack, Skalierung, Deployment-Form — sind unter NDA verfügbar. Wir können anonymisierte Deployment-Graphen und Beispiel-Reports in einer vertraulichen Umgebung durchgehen.
Eine Referenzarchitektur anfragen.
Sagt uns eure Rolle, euren Norm-Fokus und die ALM-Tools, die ihr bereits nutzt. Wir senden euch ein Referenzarchitektur-Dokument und schlagen einen 30-minütigen Walkthrough unter NDA vor.
Was ihr zurückbekommt
Ein Referenzarchitektur-Dokument, abgestimmt auf eure Rolle, eure Normen und eure ALM-Landschaft. Wir unterschreiben eine NDA, bevor das Dokument rausgeht.