Technischer Report: ai-sw-pl als nachträglicher Brückenbauer zwischen Safety-Zielen, Engineering-Artefakten und Zulassungsdokumentation

ai-sw-pl ist ein KI-orchestriertes Functional-Safety-Tool zur automatisierten Analyse bestehender C/C++-Codebasen. Das Tool erzeugt aus der realen Implementierung in einem durchgängigen Lauf einen Funktionsbericht des Ist-Zustands, daraus abgeleitete funktionale Anforderungen auf SYS.1-artigem Niveau, eine funktionale Architektur auf SYS.2-artigem Niveau, automatisch generierte und ausgeführte Catch2-Tests sowie eine semantische Traceability-Completeness-Prüfung über Requirements, Dekomposition, Tests und Code.

Der technische Mehrwert des Werkzeugs liegt nicht in einer oberflächlichen Code-Zusammenfassung, sondern in der strukturierten Rekonstruktion fehlender Engineering-Artefakte aus einer vorhandenen Implementierung. Damit adressiert ai-sw-pl eine typische Ausgangslage in Bestands- und Start-up-Projekten: Das System ist funktional lauffähig, es existieren Quellcode, Einzelarchitekturen, Stakeholder-Anforderungen und häufig auch erste Safety-Analysen, jedoch keine konsistente, vertikal verlinkte Entwicklungskette von Anforderungen über Architektur und Verifikation bis in die Implementierung.

1. Funktionsumfang und Arbeitsweise des Tools

ai-sw-pl arbeitet in zwei aufeinanderfolgenden Phasen. In Phase 1 analysiert das Tool die bestehende Codebasis bottom-up und erstellt eine konsolidierte Ist-Beschreibung des realen Softwareverhaltens. In Phase 2 werden aus diesem Ist-Bild funktionale Soll-Artefakte und Verifikationsartefakte erzeugt.

1.1 Phase 1: Ist-Analyse des bestehenden Systems

Die erste Phase umfasst Repository-Scan, Shared-Context-Erkennung, dateibasierte Bündelung, parallele Modul-Analyse und anschließende Architektur-Synthese. Ergebnis ist ein technischer Funktionsbericht, der nicht beschreibt, was das System laut Spezifikation tun sollte, sondern was die Software gemäß ihrer tatsächlichen Implementierung heute wirklich tut.

Dieser Funktionsbericht enthält insbesondere:

• Systemüberblick, Ausführungsmodell und Datenflüsse.
• Modulbeschreibungen mit Zweck, Schnittstellen, Algorithmen, Parametrierungen und Annahmen.
• Spezifikations- bzw. Ableitungs-Lücken (specification_gaps): Stellen, an denen sich aus dem Code keine eindeutige Spezifikation ableiten lässt, beispielsweise divergente Typdefinitionen, fehlende Defaults oder mehrdeutige Abhängigkeiten. Diese Lücken sind keine Bug-Reports, sondern Hinweise auf nicht eindeutig ableitbare Spezifikationsanteile; bei nicht akzeptierten Lücken blockiert die Pipeline vor Phase 2.

Damit entsteht eine belastbare technische Ist-Dokumentation, die in vielen Projekten entweder gar nicht existiert oder gegenüber dem realen Codezustand bereits deutlich veraltet ist.

1.2 Phase 2: Ableitung funktionaler Soll-Artefakte und Verifikation

Auf Basis des in Phase 1 erzeugten Ist-Bilds leitet ai-sw-pl in Phase 2 eine hierarchische Anforderungssicht sowie eine funktionale Architektur ab. Die SYS.1-artige Ebene besteht aus strukturierten, hierarchischen funktionalen Requirements mit Traceability zu Modulen und Schnittstellen sowie vorgeschlagener Verifikationsmethode. Die SYS.2-artige Ebene besteht aus einer funktionalen Architektur in DSL-Form mit Funktionen, Ports, Signalverbindungen sowie Fehler- und Wirkbeziehungen als Grundlage für FTA- und FMEA-Inputs.

Ergänzend erzeugt das Tool automatisch Testfälle in Form von Catch2-Tests, baut diese und führt sie aus. Catch2 ist dabei ein etabliertes C++-Test-Framework; die generierten Catch2-Tests sind automatisierte Unit- oder Modultests, die erwartetes Verhalten formalisieren und dieses Verhalten gegen die Implementierung prüfen.

Ein zentrales Unterscheidungsmerkmal von ai-sw-pl ist der anschließende semantische Traceability-Completeness-Check. Dieser bewertet je Requirement, ob Dekomposition, Architektur, Testabdeckung und beobachteter Code inhaltlich zueinander passen, wo Abdeckungslücken bestehen und an welchen Stellen Anforderungen nur teilweise oder widersprüchlich implementiert sind.

2. Einordnung aus Safety-Sicht

In sicherheitsrelevanten Projekten beginnt die Argumentation typischerweise top-down: mit Item-Verständnis, HARA/HARE, Safety Goals und daraus abgeleiteten Functional Safety Requirements. In der Praxis vieler Start-ups und wachsender Bestandsprojekte endet diese Logik jedoch häufig an der Grenze zwischen Safety-Arbeit und Engineering-Umsetzung.

Das typische Problem lautet nicht, dass keine Safety-Ziele existieren, sondern dass deren technische Kaskadierung unvollständig geblieben ist. Safety Goals und Functional Safety Requirements sind fachlich definiert, hängen aber operativ „in der Luft”, weil die erforderliche Weiterführung in Systemanforderungen, technische Anforderungen, Architektur, Allokation, Softwareanforderungen und Verifikation nicht durchgängig hergestellt wurde.

An dieser Stelle ist die Rollenverteilung klar zu benennen: Die Entwicklung entlang eines adäquaten Engineering-Prozesses, beispielsweise nach ASPICE oder vergleichbarer Disziplin, ist Bringschuld des Engineering und nicht Aufgabe des Safety Engineers. Die Aufgabe des Safety Engineers ist die Herleitung und Bewertung der sicherheitsrelevanten Zielgrößen, Mechanismen und Nachweise; Engineering muss diese Anforderungen in belastbare System- und Software-Artefakte, Designentscheidungen und Verifikation überführen.

ai-sw-pl ersetzt diese Engineering-Verantwortung nicht. Der Nutzen des Tools besteht vielmehr darin, eine fehlende oder unvollständig dokumentierte Engineering-Kette nachträglich aus der vorhandenen Implementierung zu rekonstruieren und damit Safety-Ziele technisch anschlussfähig zu machen.

3. ai-sw-pl als nachträglicher Brückenbauer

Der operative Nutzen von ai-sw-pl lässt sich präzise als „nachträglicher Brückenbauer” beschreiben. Ausgehend vom existierenden Code erzeugt das Tool eine bottom-up rekonstruierte SYS.1-/SYS.2-Sicht (SYS.1: funktionale Anforderungsebene, SYS.2: funktionale Architekturebene), die als Systemebene insbesondere den Zusammenhang zwischen Safety-Artefakten und realem Implementierungsstand herstellt.

Diese Brückenfunktion hat drei wesentliche Wirkungen:

3.1 Wiederankopplung von Safety-Zielen an die reale Implementierung

Nach manueller Verknüpfung der bottom-up erzeugten SYS.1-Anforderungen mit vorhandenen Safety Goals und Functional Safety Requirements wird erstmals systematisch sichtbar, welche Funktionen, Schnittstellen, Datenpfade, Überwachungsmechanismen, Plausibilisierungen und Zustandslogiken die bestehenden Safety-Anforderungen tatsächlich stützen. Ebenso wird sichtbar, wo Safety Goals und FSR bislang keinen hinreichend belastbaren technischen Anker im realen System besitzen.

3.2 Sichtbarmachung von System-Level-Lücken und Realisierungslücken

Die manuelle Verknüpfung von bottom-up SYS.1-Artefakten mit SG und FSR macht nicht nur Implementierungsdetails transparent, sondern auch Lücken auf Systemebene. Sichtbar werden insbesondere jene Stellen, an denen Safety-Anforderungen zwar auf Konzept- oder Analyseebene existieren, aber in Architektur, Dekomposition, Signalverträgen, Fehlermoden, Testabdeckung oder Traceability unzureichend abgedeckt sind.

Damit entsteht eine belastbare Grundlage für fachlich priorisierte Gap-Analysen, beispielsweise entlang folgender Fragen:

• Welche SG und FSR besitzen bereits eine erkennbare technische Realisierung im System?
• Welche Safety-Anforderungen sind nur teilweise oder widersprüchlich umgesetzt?
• Welche sicherheitsrelevanten Funktionen existieren faktisch im Code, ohne in der bisherigen Safety-Kaskade sauber adressiert zu sein?
• Welche Nachweise und Tests fehlen, um aus Safety-Sicht eine belastbare Argumentation zu führen?

3.3 Ermöglichung eines iterativen Verifikations- und Verbesserungszyklus

Durch die Erzeugung von Requirements, Architektur, Tests und Traceability-Befunden wird eine Ausgangsbasis geschaffen, auf deren Grundlage iterativ verbessert werden kann. Neue oder geschärfte FSR, nachgezogene Designentscheidungen und ergänzte Safety-Mechanismen lassen sich gegen eine rekonstruierte technische Struktur prüfen, anstatt gegen eine nur implizit verstandene Codebasis.

4. Relevanz für Start-ups mit Zulassungsdruck

Für Start-ups mit fahrbereitem System, vorhandener Software und ersten regulatorischen sowie sicherheitsbezogenen Anforderungen ist das zentrale Problem häufig nicht die fehlende Funktion, sondern die fehlende Konsistenz der Herstellerdokumentation. Gerade in regulierten Umfeldern entscheidet jedoch nicht allein die reale Funktionalität, sondern die Fähigkeit, diese in einer konsistenten, nachvollziehbaren und prüfbaren Dokumentationskette gegenüber Prüforganisationen darzustellen.

ai-sw-pl adressiert genau dieses Risiko, indem das Tool aus der bestehenden Implementierung jene technischen Zwischenartefakte generiert, die für eine belastbare Herstellerdokumentation typischerweise nachträglich mit hohem Aufwand erstellt werden müssten. Dazu zählen insbesondere die Ist-Beschreibung des Systems, funktionale Anforderungen, funktionale Architektur, Testbasis, Traceability-Befunde sowie strukturierte Inputs für FTA- und FMEA-Betrachtungen.

Der geschäftliche Nutzen ist direkt: Die Zeit bis zu einer TÜV-diskussionsfähigen, konsistenten technischen Dokumentationsbasis wird deutlich reduziert. Anstatt monatelang Architektur- und Funktionsdokumente rückwirkend manuell aus dem Code zu extrahieren, liegt kurzfristig eine technisch strukturierte Ausgangsbasis vor, die anschließend durch Safety- und Engineering-Experten normgerecht ergänzt, validiert und in die gewünschte Herstellerdokumentation überführt werden kann.

5. Kundennutzen in zwei Dimensionen

5.1 Rechtzeitige Herstellung zulassungsrelevanter Dokumentationsfähigkeit

Der primäre Kundennutzen besteht in der Beschleunigung auf dem Weg von einer bestehenden Codebasis zu einer konsistenten, prüffähigen technischen Herstellerdokumentation. ai-sw-pl liefert keine automatische ISO-26262- oder ISO-21448-Konformität, erzeugt jedoch genau die Engineering-Artefakte, deren Fehlen in der Praxis die termingerechte Zulassung gefährdet.

Für Management und Programmverantwortung bedeutet dies geringeres Terminrisiko in Richtung Zulassung. Für Engineering und Safety bedeutet es eine deutlich verbesserte Anschlussfähigkeit zwischen Stakeholder-Anforderungen, Safety-Konzept, technischer Umsetzung und Verifikationsnachweisen.

5.2 Transparenz über Vollständigkeits- und Konsistenzlücken mit Safety-Bezug

Der zweite zentrale Kundennutzen ist die strukturierte Sichtbarmachung von Vollständigkeits- und Konsistenzlücken mit direktem System- und Safety-Bezug. Über den Traceability-Completeness-Check und die in Phase 1 gemeldeten Spezifikations-/Ableitungs-Lücken identifiziert ai-sw-pl insbesondere, wo Requirements, Architektur, Tests und beobachteter Code inhaltlich auseinanderlaufen: nur teilweise oder widersprüchlich umgesetzte Anforderungen, fehlende Testabdeckung je Requirement, nicht eindeutig ableitbare Spezifikationsanteile sowie System-Level-Inkonsistenzen zwischen den vier Sichten Requirements ↔ Dekomposition ↔ Tests ↔ Code.

Diese Befunde haben einen unmittelbaren geschäftlichen Wert, weil sie technische Risiken frühzeitig in bearbeitbare Engineering-Maßnahmen überführen. Sie ermöglichen die gezielte Schließung jener Lücken, die einer belastbaren Safety-Argumentation und damit einer rechtzeitigen Zulassung im Weg stehen.

6. Positionierung und Claim-Richtung

ai-sw-pl ist weder ein Ersatz für klassischen Systems Engineering-Prozess noch ein zertifiziertes Safety-Tool im Sinne von ISO 26262. Die Stärke des Werkzeugs liegt vielmehr darin, aus einer bestehenden Implementierung mit hoher technischer Detailtiefe eine strukturierte Rekonstruktion jener Artefakte zu erzeugen, die für Safety, Engineering und Zulassung gemeinsam benötigt werden.

In dieser Positionierung ergeben sich die folgenden belastbaren Claim-Richtungen:

• ai-sw-pl verkürzt den Weg von bestehendem Code zu einer konsistenten, technisch fundierten Herstellerdokumentation.
• ai-sw-pl wirkt als nachträglicher Brückenbauer zwischen vorhandenen Safety-Zielen und dem realen Implementierungsstand.
• ai-sw-pl macht Vollständigkeits- und Konsistenzlücken zwischen Requirements, Architektur, Tests und Code sichtbar, bevor sie in Audit, Verifikation oder Zulassung zum kritischen Problem werden.
• ai-sw-pl schafft die technische Ausgangsbasis für eine nachvollziehbare Verbindung von Safety-Analyse, Architektur, Tests und Code.

7. Zusammenfassung

ai-sw-pl ist insbesondere für Projekte mit funktionierendem Produkt, aber unvollständig dokumentierter Engineering-Kette relevant. Das Tool rekonstruiert aus dem realen Codezustand jene SYS.1-/SYS.2-artigen Anforderungen, Architekturen, Tests und Traceability-Beziehungen, die erforderlich sind, um Safety-Artefakte an die Implementierung anzukoppeln, Vollständigkeits- und Konsistenzlücken systematisch sichtbar zu machen und eine prüffähige Herstellerdokumentation deutlich schneller aufzubauen.

Gerade für Start-ups mit Zulassungsdruck entsteht daraus ein klarer strategischer Nutzen: geringeres Dokumentations- und Terminrisiko, höhere Transparenz über Vollständigkeits- und sicherheitsrelevante Lücken sowie eine belastbare technische Basis, um vorhandene Safety-Arbeit in eine konsistente, auditierbare und zulassungsrelevante Systemdokumentation zu überführen.