ai-sw-pl — Vom Source Code zur Funktionalen Sicherheit.
ai-sw-pl ist ein KI-orchestriertes Werkzeug, das ein bestehendes Software-Repository als Eingangspunkt nimmt und Schritt für Schritt die FuSa-Artefakte daraus aufbaut — Funktionsbeschreibung, funktionale Spezifikation, Architektur in FtaDSL/FmeaDSL, FTA, FMEA und System-Tests. Brückenbauer zwischen Entwicklung und Funktionaler Sicherheit.
Was ai-sw-pl ist
ai-sw-pl ist die SW-zentrische Einstiegs-Säule der Risk-Forge- Pipeline. Ausgehend von einem Software-Repository erzeugt es ASPICE-orientierte Spezifikations-Artefakte (SYS.1, SYS.2) sowie eine Architektur-Beschreibung in FtaDSL und FmeaDSL — und übergibt diese Modell-Dateien anschließend an die Risk-Forge- Analyse-Engines (mcsa für FTA, fmea für FMEA). Den Abschluss bilden System-Level-Tests, die deterministisch aus der vervollständigten Spezifikation abgeleitet werden.
Die Pipeline
- SW → Funktionsbeschreibung. Die Software wird gelesen, ihre Funktionalität wird beschrieben.
- Funktionsbeschreibung → funktionale Spezifikation (Gerüst). Aus der Funktionsbeschreibung wird das Spec-Gerüst pro Funktion erzeugt — gegen eine feste Achsen- Checkliste (Eingangsdomäne, Ausgangsdomäne, Sättigung, Fehler-/Fault-Reaktion, Timing, Ressourcengrenzen, Zustand, Nebenläufigkeit). Die Software bleibt in diesem Schritt bewusst draußen — die Spec beschreibt, was die Funktion leisten soll, unabhängig vom Code.
- Spezifikation vervollständigen (refgen). Erst jetzt wird die Software konsultiert, um die offenen Slots zu füllen: deterministisch dort, wo Konstanten/Enums/Array- Grenzen sprechen (grün), interpretativ mit Review-Pflicht dort, wo das LLM Kontrollfluss lesen muss (gelb). Leere Slots = Findings (das Verhalten fehlt im Code).
- Architektur → FtaDSL/FmeaDSL. Aus der vollständigen Spezifikation entsteht die Architektur- Beschreibung in Risk-Forge-DSL.
- FTA, FMEA, Test Cases. mcsa berechnet die Cut-Sets, fmea leitet die FMEA-Tabelle ab, System-Level-Tests entstehen blind zum Code aus der Spezifikation.
Die drei SW-Berührungsmodi
Tragend für ai-sw-pl ist die strikte Trennung der Berührungs- modi mit der SW — sie sorgt für Spezifikation-Implementierung- Unabhängigkeit (ASIL-D-relevant) bereits an der Quelle:
- lesen → beschreiben. SW wird gelesen, Funktionalität beschrieben (Schritt 1).
- ignorieren → Gerüst. Spec-Gerüst entsteht ohne Code-Zugriff (Schritt 2 — Brandmauer an der Quelle).
- konsultieren → füllen. Code wird gezielt zum Füllen der Slots herangezogen (Schritt 3 — typisiertes Füllen nach Vertrauensgrad).
Wie ai-sw-pl in das Portfolio passt
ai-sw-pl ist der Source-Code-Einstieg in die Risk-Forge-Pipeline. Anwender mit einer Idee starten beim riskforge-Chatbot, Anwender mit fertiger Architektur beim rca-studio — und Anwender mit bestehendem Code bei ai-sw-pl. Alle drei Wege münden in dieselbe FtaDSL-Modell-Datei und laufen anschließend durch denselben deterministischen Workflow (FTA → FMEA → Safety Case).
Status
Pilot. ai-sw-pl ist als Python-CLI in der Applied-FuSa-Beratungs-Praxis einsetzbar — kein Self-Service- SaaS, sondern Tool-Substanz im begleiteten Engagement. Heutiger Maßstab am internen Demo-Target ugv-simulation: 10 Module, 90 Anforderungen, 644 System-Level-Tests, 100 % Requirement-Coverage je Modul. Roadmap: Self-Healing, Traceability-Completeness, SaaS-Form als Vision.
Risk-Forge-Workflow im Überblick: Risk-Forge-Plattform-Übersicht →
So sieht ein ai-sw-pl-Lauf aus
Belegt mit echten Artefakten aus dem internen Referenz-
Architektur-Lauf an der acc-simulation-Codebasis:
10 Module, 90 Anforderungen entlang einer fest verdrahteten
9-Achsen-Checkliste, 644 System-Level-Tests, 100 Findings,
34 offene User-Questions. Jede Karte unten öffnet einen der
generierten HTML-Reports — direkt aus dem Lauf, deterministisch
erzeugt, keine Nachbearbeitung.
- Index Übersicht des Laufs — KPIs (90 Requirements, 644 Tests, 100 Findings, 34 User-Questions) und Einstieg in die fünf Artefakte.
- Functional Specification Pro Modul neun-achsige Requirements mit konkreten code-abgeleiteten Werten — grün = deterministisch, gelb = interpretativ (Review-Pflicht).
- Findings Verhalten, das die Spezifikation fordert, das aber im Code nicht implementiert ist — ehrliche Lücken im Klartext.
- User-Questions & Review Kalibrierungs- und Intent-Werte, die das Tool aktiv beim Engineer rückfragt; mehrdeutige Code-Stellen, die menschliches Review brauchen.
- System-Level Test Cases 644 Black-Box-Tests, abgeleitet aus den Anforderungen — blind zum Code, jedes Oracle als REVIEW REQUIRED markiert.
- Coverage-Matrix Deterministische Requirement-→-Test-Vollständigkeit — die grüne Garantie pro Modul.
Whitepaper
Für die ausführliche Einordnung des Tools — vom Brückenbauer- Framing über Phase 1 / Phase 2 bis zur Positionierung gegenüber klassischem Systems Engineering und Zulassungsdruck — gibt es einen technischen Report:
Du hast einen Code, der zur FuSa-Argumentation gebracht werden muss?
Genau dafür gibt es ai-sw-pl. Wir setzen das Tool aktuell ausschließlich im Beratungs-Engagement ein — Pilot-Anfragen sind willkommen, Self-Service folgt später.
Pilot anfragen →