AUTOSAR-Codebasis mit KI verstehen: Analyse und Grenzen

KI-gestütztes Codeverständnis für gewachsene AUTOSAR-Codebasen

Ja, KI-gestützte Code-Analyse kann eine gewachsene, teils undokumentierte AUTOSAR-Codebasis erklären: Sie beschreibt Modulstrukturen, verfolgt Aufrufpfade, fasst Komponenten in Prosa zusammen und entwirft Kommentare. Ihre Grenze verläuft dort, wo der Quelltext die führende Quelle verliert: bei generiertem RTE- und Basissoftware-Code, dessen Wahrheit in der Toolchain-Konfiguration liegt, bei Makro-Ketten mit bedingter Kompilierung und bei Compiler- und Target-Spezifika. Tragfähig ist der Einsatz als rein lesende Augmentation: Jede Erklärung gilt als Hypothese mit Fundstelle, ein Engineer bestätigt oder verwirft sie, und bestätigtes Wissen fließt in versionierte Dokumentation. sensified ordnet diesen Arbeitsmodus als Triage-Klasse B ein und beschreibt, wie aus geerbtem Code wieder geführtes Wissen wird.

Die Ausgangslage ist in Steuergeräte-Projekten häufiger, als Konferenzvorträge vermuten lassen. Ein Head of Software Engineering oder ein Integrationsverantwortlicher übernimmt eine Codebasis, die über zehn oder fünfzehn Jahre gewachsen ist. Der Architekt der ersten Stunde hat das Unternehmen verlassen, der Kollege, der die Komplextreiber geschrieben hat, ist seit zwei Jahren in Rente. Die Architektur-Dokumentation beschreibt einen Stand von vor drei Major-Releases, und ein erheblicher Teil des Codes stammt ohnehin aus einer Generierungs-Toolchain, deren Konfigurationsstände ihre eigene, nur teilweise nachvollziehbare Geschichte haben. Auf dieser Basis sollen trotzdem neue Funktionen entstehen, Feldfehler analysiert und Lieferungen verantwortet werden. Die Frage liegt nahe, ob KI-gestützte Code-Analyse hier trägt. Dieser Beitrag beantwortet sie mit einem klaren Ja unter Bedingungen und gehört zur Werkzeug-Ebene, deren Überblick der Beitrag zur KI in der Automotive-Softwareentwicklung gibt. Eine Einordnung vorweg: Die Eignungsaussagen in diesem Beitrag sind typisierte Hypothesen aus Projekterfahrung, die je Kunde und Toolchain zu prüfen sind. Über Personen oder deren Leistung trifft dieser Beitrag keine Aussage.

Das geerbte System: vier Artefakt-Welten in einer Codebasis

Wer eine gewachsene AUTOSAR-Codebasis erklären lassen will, muss zuerst verstehen, dass es sich nicht um einen homogenen Quelltext-Bestand handelt. Die AUTOSAR-Architektur trennt Applikationsschicht, Laufzeitumgebung (RTE) und Basissoftware, und jede dieser Schichten hat eine andere Entstehungsgeschichte und damit eine andere Wahrheitsquelle (Herausgeber: AUTOSAR, Classic Platform).

Was tatsächlich im Repository liegt

In einer typischen gewachsenen Codebasis liegen mindestens vier Artefakt-Welten nebeneinander. Erstens handgeschriebene Software-Komponenten der Applikationsschicht, in denen die Fachlogik des Steuergeräts steckt und die über Jahre von wechselnden Händen erweitert wurden. Zweitens generierter Code, allen voran die RTE, die je Steuergerät aus der Konfiguration erzeugt wird und die Applikationssoftware von der Basissoftware entkoppelt. Drittens die konfigurierte Basissoftware selbst, deren Verhalten weniger im C-Code als in den Parameter-Ständen der Toolchain festgelegt ist. Viertens handgeschriebene Komplextreiber, die nach AUTOSAR-Definition nicht standardisierte Funktionalität mit direktem Hardware-Zugriff abdecken, etwa für zeitkritische Sensorik oder spezielle Peripherie. Dazu kommen in fast jedem realen Projekt Reste aus der Vor-AUTOSAR-Zeit, Glue-Code und Build-Skripte, die nie jemand dokumentiert hat.

Warum die Dokumentation nicht mehr trägt

Die Dokumentationslücke entsteht selten aus Nachlässigkeit. Sie entsteht, weil das entscheidende Wissen an Stellen lag, die kein Dokumentationsprozess erfasst hat: in den Köpfen der Wissensträger, in den Konfigurationsentscheidungen der Generierungs-Toolchain und in Übergaben, die unter Termindruck mündlich stattfanden. Die formale Architektur-Doku beschreibt den geplanten Zustand von damals; der Code beschreibt den gelebten Zustand von heute. Zwischen beiden liegen Jahre von Änderungen, Workarounds und Varianten. Genau diese Lücke ist der Arbeitsbereich der KI-gestützten Code-Analyse.

Was KI-gestützte Code-Analyse heute leistet

Sprachmodelle sind gut darin, Quelltext zu lesen und in nachvollziehbare Prosa zu übersetzen. Für den handgeschriebenen Teil einer gewachsenen Codebasis ergibt das drei belastbare Leistungen, die im Alltag eines Integrationsverantwortlichen unmittelbar Zeit sparen.

Struktur erklären und Aufrufpfade verfolgen

Die erste Leistung ist der Überblick. Eine KI-gestützte Analyse beschreibt, welche Module es gibt, welche Verantwortung eine Datei trägt und wie Komponenten zusammenhängen. Sie verfolgt Aufrufpfade über Datei- und Schichtgrenzen hinweg und beantwortet Fragen, die sonst Tage kosten: Wo wird dieses Signal gesetzt, welche Funktionen schreiben auf diesen Zustand, welche Pfade führen von der Botschaftsannahme bis zur Aktuator-Ansteuerung. Sie markiert außerdem Kandidaten für Seiteneffekte und übersetzt Zustandsautomaten, die nur als verschachtelte Switch-Konstrukte existieren, in eine lesbare Ablaufbeschreibung. Das Ergebnis ist keine Wahrheit, es ist eine sehr gute erste Landkarte.

Zusammenfassungen je Modul und Kommentar-Entwürfe

Die zweite Leistung ist die Verdichtung. Je Modul entsteht eine Zusammenfassung in wenigen Absätzen: Zweck, Schnittstellen, Auffälligkeiten, offene Fragen. Solche Zusammenfassungen tragen die Einarbeitung neuer Teammitglieder und die Vorbereitung von Reviews, wenn am Bestand geändert werden muss. Die dritte Leistung sind Entwürfe: Kommentar-Vorschläge für unkommentierte Funktionen, Doku-Kommentare im projektüblichen Format, Beschreibungstexte für Schnittstellen. Alle drei Leistungen haben denselben Charakter: Sie liefern Sichten und Entwürfe, keine freigegebenen Arbeitsprodukte. Was davon in die Dokumentation übergeht, entscheidet ein Mensch.

Die Grenzen: wo der Quelltext nicht die führende Quelle ist

So weit die Stärken. Die Grenzen der KI-Analyse verlaufen nicht dort, wo der Code schwierig wird; sie verlaufen dort, wo der Code aufhört, die maßgebliche Quelle zu sein. In einer AUTOSAR-Codebasis ist das ein großer Teil des Bestands, und wer diese Grenze ignoriert, erzeugt plausible Erklärungen mit falschem Fundament.

Generierter Code: die Wahrheit liegt in der Konfiguration

Die RTE und große Teile der Basissoftware werden aus Konfigurationsständen erzeugt. Eine KI kann das Generat lesen und erklären, was dieser konkrete Stand tut. Sie kann aber nicht aus dem C-Code ableiten, warum die Konfiguration so gewählt wurde, welche Varianten es gibt und was beim nächsten Generatorlauf anders aussehen wird. Eine Quelltext-Erklärung der RTE ist deshalb eine Erklärung mit Verfallsdatum: Nach der nächsten Generierung beschreibt sie einen Stand, den es nicht mehr gibt. Belastbar wird die Analyse erst, wenn sie die Konfigurationsartefakte einbezieht und die Schichtengrenzen kennt, wie sie die Architektur-Beschreibung des Standards definiert (Herausgeber: AUTOSAR, Layered Software Architecture, R22-11). Praktisch heißt das: Fragen zum Generat beantwortet die Analyse mit Verweis auf die Konfiguration, oder sie kennzeichnet die Antwort als Momentaufnahme.

Makro-Magie, Compiler und Target

Die zweite Grenzlinie ist unscheinbarer. Gewachsene Embedded-Codebasen sind voll von verschachtelten Makros, Memory-Mapping-Headern, bedingter Kompilierung und compilerspezifischen Pragmas. Ein Sprachmodell liest den Quelltext, wie er im Repository steht; welche Zweige der Präprozessor für die konkrete Variante tatsächlich aktiviert, steht in der Build-Konfiguration. Dieselbe Vorsicht gilt für alles, was am Target hängt: Laufzeitverhalten, Interrupt-Latenzen, Speicherlayout und die Eigenheiten der Mikrocontroller-Peripherie. Das Modell liest Text, nicht Silizium. Eine gute Analyse benennt diese Stellen als offene Fragen an den Engineer, statt sie mit plausibel klingender Prosa zu füllen.

Der tragfähige Arbeitsmodus: rein lesende Augmentation

Aus Stärken und Grenzen folgt der Arbeitsmodus. Codeverständnis am Bestand ist ein Fall für die Triage-Klasse B, also rein lesende Augmentation: Das Werkzeug hat keinen Schreibzugriff auf Code oder führende Ablagen und erzeugt keinen eigenen Arbeitsstand. Warum diese Einordnung vor dem Werkzeugkauf stehen sollte, begründet der Beitrag zur Triage zwischen Automatisierung und Augmentation im Engineering. Innerhalb der Klasse B gelten zwei Regeln, die den Unterschied zwischen einem nützlichen und einem gefährlichen Werkzeug ausmachen.

Jede Erklärung ist eine Hypothese mit Fundstelle

Die erste Regel betrifft die Form der Antwort. Jede Erklärung nennt ihre Fundstellen: Datei, Funktion, Versionsstand. Eine Erklärung ohne Fundstelle ist im Serienkontext nicht verwertbar, ganz gleich wie überzeugend sie klingt. Die zweite Hälfte der Regel betrifft den Status: Jede Erklärung gilt als Hypothese, bis ein Engineer sie geprüft hat. Der Prüfaufwand ist dabei um Größenordnungen kleiner als der Erarbeitungsaufwand; eine vorgeschlagene Aufrufkette mit Fundstellen lässt sich in Minuten verifizieren, ihre eigenständige Rekonstruktion hätte Stunden gekostet. Fehlerhafte Erklärungen gehen über einen Feedback-Kanal zurück und schärfen die Analyse. So bleibt der rote Faden gewahrt: Die KI assistiert, der Mensch verantwortet das Urteil.

Bestätigtes Wissen fließt in versionierte Dokumentation

Die zweite Regel macht aus der Analyse einen bleibenden Wert. Bestätigte Erklärungen verschwinden nicht im Chat-Verlauf; sie werden in versionierte Dokumentation überführt: Modul-Beschreibungen, Architektur-Notizen, Kommentare im Code, jeweils über den normalen Review-Prozess. So wächst die Dokumentation dort nach, wo sie gebraucht wird, und jeder Eintrag hat einen menschlichen Autor, der die Verantwortung trägt. Wird diese nachwachsende Doku zusätzlich abfragbar gemacht, entsteht die Brücke zum nächsten Baustein der Werkzeug-Ebene, der abfragbaren Entwicklungsdokumentation mit DOORS-, Polarion- und Confluence-Anbindung. Und wo die eigentlichen Wissensträger das Haus noch nicht verlassen haben, lässt sich derselbe Mechanismus vorbeugend nutzen, wie der Beitrag zur Wissenssicherung vor dem Renteneintritt zeigt.

Was sich im Projektalltag verändert

Richtig aufgesetzt verändert der Baustein drei Dinge im Alltag: Einarbeitung, Fehleranalyse und das Risiko-Profil des Wissens. Er verändert ausdrücklich nicht die Verantwortungsarchitektur des Projekts.

Einarbeitung und Fehleranalyse werden planbarer

Neue Teammitglieder stellen ihre Fragen an die Codebasis, statt erfahrene Kollegen zu unterbrechen, und bekommen Antworten mit Fundstellen, die sie selbst nachvollziehen können. Bei Feldfehlern liefert die Analyse in kurzer Zeit die Landkarte der beteiligten Pfade, auf der die eigentliche Ursachenanalyse aufsetzt. Und das Wissensrisiko sinkt messbar an der Stelle, die im Assessment und im Audit zählt: Es gibt wieder eine dokumentierte, versionierte Beschreibung des Bestands, deren Herkunft nachvollziehbar ist. Wie stark diese Effekte in einem konkreten Projekt ausfallen, ist eine typisierte Hypothese aus Projekterfahrung, die je Kunde und Toolchain zu prüfen ist.

Regelwerk statt Freigabepfad

Weil der Baustein rein lesend arbeitet, braucht er keinen Code-Freigabepfad. Er braucht trotzdem eine Ordnung des Betriebs: eine klare Festlegung, welche Quellen eingebunden sind und mit welchen Zugriffsrechten, einen IP-Schutz-Rahmen, der regelt, dass der Quellcode die vereinbarte Betriebsumgebung nicht verlässt, eine Protokollierung der Abfragen und eine benannte Zuständigkeit je Werkzeug. Für Projekte nach Automotive SPICE (ASPICE) gilt zusätzlich: Dokumentation, die aus bestätigten KI-Erklärungen entsteht, durchläuft dieselben Qualitätsanforderungen wie jede andere Dokumentation, und die Werkzeug-Frage der Funktionalen Sicherheit nach ISO 26262 wird je Werkzeugkette geprüft, auch wenn sie bei rein lesenden Werkzeugen mit Bestätigungspflicht in aller Regel entspannt ausfällt.

Nächste Schritte

Ob KI-gestütztes Codeverständnis in Ihrem Projekt der richtige erste Baustein ist, hängt von Codebasis, Toolchain und Wissenslage ab und lässt sich nicht pauschal entscheiden. Der geordnete Einstieg sieht so aus:

1. Überblick lesen: Der Beitrag zur KI in der Automotive-Softwareentwicklung ordnet das Codeverständnis in die vier Einsatzfelder der Werkzeug-Ebene ein.
2. Vorgehen prüfen: Die Seite zur AI-Transformation im Automotive Engineering beschreibt, wie aus einzelnen Bausteinen ein geführtes Transformationsvorhaben wird.
3. Gespräch vereinbaren: In einem Qualifying-Call klären wir, ob Codebasis, Toolchain und Ausgangslage Ihres Projekts zum Vorgehen passen.

Häufige Fragen

Die folgenden Antworten fassen die Position von sensified zum KI-gestützten Codeverständnis in gewachsenen AUTOSAR-Codebasen zusammen. Sie beschreiben typisierte Einsatzmuster; wie sie in einem konkreten Projekt liegen, wird je Kunde und Toolchain geprüft.

Kann KI eine undokumentierte, gewachsene Codebasis erklären?

Ja, für den handgeschriebenen Teil der Codebasis leistet KI-gestützte Analyse heute Struktur-Erklärungen, Aufrufpfad-Verfolgung, Zusammenfassungen je Modul und Kommentar-Entwürfe. Jede Erklärung gilt dabei als Hypothese mit Fundstelle, die ein Engineer bestätigt, bevor sie in Dokumentation übergeht. Bei generiertem Code und Toolchain-Konfiguration ist die Aussagekraft begrenzt, weil der Quelltext dort nicht die führende Quelle ist.

Versteht ein Sprachmodell generierten AUTOSAR-Code wie die RTE?

Es kann das Generat lesen und beschreiben, was der konkrete Stand tut. Die Entwurfsentscheidung liegt aber in der Konfiguration der Toolchain, und nach dem nächsten Generatorlauf beschreibt die Erklärung einen Stand, den es nicht mehr gibt. Belastbare Antworten zu RTE und Basissoftware beziehen deshalb die Konfigurationsartefakte ein oder sind als Momentaufnahme gekennzeichnet.

Verändert die KI-Analyse den Code?

Nein. Codeverständnis am Bestand ist rein lesende Augmentation (Triage-Klasse B): kein Schreibzugriff auf Code oder führende Ablagen, kein eigener Arbeitsstand. Kommentar- und Doku-Entwürfe gelangen ausschließlich über den normalen Review- und Versionierungsprozess in die Arbeitsprodukte, mit einem menschlichen Autor als Verantwortlichem.

Wie geht das Team mit falschen Erklärungen um?

Falsche Erklärungen sind eingeplant, deshalb gilt jede Antwort als Hypothese, bis ein Engineer sie geprüft hat. Fundstellen machen die Prüfung schnell: Eine vorgeschlagene Aufrufkette lässt sich in Minuten verifizieren. Erkannte Fehler gehen über einen Feedback-Kanal zurück und verbessern die Analyse; Antworten ohne Fundstelle werden grundsätzlich nicht verwertet.

Verlässt unser Quellcode bei der Analyse das Haus?

Das ist eine Frage des Betriebsmodells und wird vor der Einführung festgelegt. Je nach IP- und Kundenvorgaben läuft die Analyse auf eigener Infrastruktur, in einer vertraglich abgesicherten EU-Umgebung oder in einer vom Kunden freigegebenen Cloud. Zum Regelwerk gehören außerdem definierte Quellen, Zugriffsrechte und eine Protokollierung der Abfragen.

Braucht das Analyse-Werkzeug eine Tool-Qualifizierung nach ISO 26262?

Die Tool-Vertrauensbetrachtung wird je Werkzeugkette geprüft und dokumentiert. Ein rein lesendes Werkzeug, dessen Ergebnisse erst nach Bestätigung durch einen Engineer in Arbeitsprodukte einfließen, hat einen wirksamen Fehlererkennungs-Pfad, entsprechend fällt die Einstufung in aller Regel niedrig aus. Die Prüfung selbst ersetzt das nicht; sie gehört zur Ordnung des Betriebs.

Ersetzt die KI-Analyse die Einarbeitung neuer Entwickler?

Nein, sie beschleunigt sie. Neue Teammitglieder bekommen Antworten mit Fundstellen und eine Landkarte des Bestands, das Verständnis erarbeiten sie sich weiterhin selbst, unter anderem durch das Prüfen der Hypothesen. Das erfahrene Team wird von Unterbrechungen entlastet und bleibt zugleich die Instanz, die bestätigt, was in die versionierte Dokumentation übergeht.