Wie KI das Design von Automobil-Elektronik-Softwarearchitekturen neu gestaltet? Umfassende Analyse des Softwarearchitektur-Design-Agenten
2 months ago
Das größte Problem für Teams, die an der Softwarearchitektur von Automobil-Elektronik arbeiten, ist nicht das Architekturdesign selbst, sondern dass die Dokumentation erst beginnt, wenn das Design abgeschlossen ist.
Ein hundertseitiges Anforderungsdokument, eine kundenspezifische Vorlage (Word + Excel), plus ASPICE SWE.3, funktionale Sicherheit ASIL-Zuweisung, Schichtenarchitektur (Anwendungsschicht → Dienstschicht → Abstraktionsschicht → Treiberschicht) und andere normative Anforderungen – der Architekt muss Anforderungen einzeln aufschlüsseln, Schichtdiagramme zeichnen, Schnittstellenmatrizen definieren, dynamische Zeitabläufe schreiben und Anforderungsrückverfolgung markieren.
Eine Runde für eine Version der Anforderungen, eine weitere Runde bei Änderungen – man ist immer im Hintertreffen.
Die Erstellung von Softwarearchitekturdokumenten wird zu einem immer deutlicheren Engpass im Entwicklungsprozess der Automobil-Elektronik.
Es ist langsam, weil die Schichtendesign-Dimensionen vielfältig sind, die Schnittstellenbeziehungen komplex und die normativen Einschränkungen streng; es ist schwierig, weil die Abdeckung der Vollständigkeit, die Anforderungsrückverfolgung und die Konsistenz der Überprüfung schwer allein durch menschliche Erfahrung langfristig sicherzustellen sind.
Was der Softwarearchitektur-Design-Agent lösen möchte, ist, die Erstellung von Architekturdokumenten von "Wochen" auf "Stunden" zu komprimieren und das Architekturteam von sich wiederholenden Aufgaben zu befreien, damit es mehr Zeit für wichtigere Architekturentscheidungen, Designüberprüfungen und Optimierungen aufwenden kann.
1. Schmerzpunkte: Warum das manuelle Schreiben von Architekturdokumenten schwierig ist
Lassen Sie uns das Problem aufschlüsseln: Die Schwierigkeiten beim manuellen Schreiben von Softwarearchitekturdokumenten für die Automobil-Elektronik konzentrieren sich auf fünf Punkte.
Erstens: Zu viele Schichten, manuelle Vollständigkeit ist unrealistisch.
Eine vollständige Middleware-Architektur umfasst vier Schichten: Anwendungsschicht, Dienstschicht, Abstraktionsschicht und Treiberschicht. Jede Schicht hat mehrere Unterarchitekturen, Dutzende von Komponenten und Hunderte von Softwareeinheiten.
Jede Komponente muss eine Funktionsbeschreibung, Schnittstellenliste, ASIL-Stufe, Entwicklungstyp und Abhängigkeiten definieren – selbst bei sorgfältiger manueller Arbeit ist es schwer, Lücken zu vermeiden.
Zweitens: Zu viele Vorlagen, die Anforderungen der Auftraggeber sind unterschiedlich.
Die Architekturvorlagen verschiedener OEMs unterscheiden sich stark im Format:
- Manche verlangen Word-Spezifikationen + Excel-Schnittstellenmatrix;
- Andere verlangen PlantUML-Architekturdiagramme + Markdown-Text.
Es gibt Dutzende von Platzhaltern wie <XX>, <XXX> in den Vorlagen, deren manuelles Ersetzen zeitaufwändig und fehleranfällig ist.
Ganz zu schweigen davon, dass nach einer Aktualisierung der Vorlage durch den Auftraggeber die Formatierung erneut angepasst werden muss.
Drittens: Zu viele Normen, Abdeckung durch Gedächtnis ist unzuverlässig.
ASPICE SWE.3 hat klare Anforderungen an die Prüfelemente für das detaillierte Softwaredesign (O-1~O-9), und die funktionale Sicherheitsnorm hat strenge Einschränkungen für ASIL-Zuweisung und Isolation.
Welche Prüfpunkte abgedeckt werden müssen, welche Anti-Patterns vermieden werden müssen – langfristig auf menschliche Erfahrung angewiesen zu sein, birgt hohe Risiken.
Viertens: Sobald sich die Anforderungen ändern, muss die Dokumentation überarbeitet werden.
Nach einer Aktualisierung des Anforderungsdokuments muss das Architekturdesign synchron angepasst werden.
Aber es fehlt oft eine klare Verbindung zwischen "welche Anforderungen geändert wurden" und "welche Komponenten betroffen sind".
Ein Übersehen von Änderungen führt nicht sofort zu einem Fehler, sondern hinterlässt stillschweigend Risiken in der späteren Entwicklung.
Noch kniffliger ist, dass beim Vergleich von zwei Architekturversionen der manuelle Abgleich von Schnittstellensignalen, Abhängigkeiten und Ressourcenzuweisungen einen enormen Arbeitsaufwand erfordert und leicht zu Auslassungen führt.
Fünftens: Hohe Überprüfungskosten, je später desto leichter Abweichungen.
Ob ein Architekturentwurf vernünftig ist, muss normalerweise gleichzeitig mit Anforderungen, Schnittstellen, Normen und historischen Erfahrungen abgeglichen werden.
Bei Dutzenden von Komponenten kann man noch einzeln prüfen, bei Hunderten wird aus "gründlicher Überprüfung" leicht eine "Formatkontrolle".
Schlimmer noch: Die Umsetzung von Überprüfungskommentaren fehlt oft eine Rückkopplung – wurde geändert, was wurde geändert, wurden neue Probleme eingeführt? Die Nachverfolgungskosten sind hoch.
Die ersten drei Punkte beeinträchtigen die Effizienz, die letzten beiden bergen Qualitätsrisiken.
Und der vierte Punkt – die Synchronisation der Dokumentation nach Anforderungsänderungen und die Analyse von Versionsunterschieden – ist genau der Bereich, der in stark rückverfolgbaren Bereichen wie der Automobil-Elektronikarchitektur am wichtigsten ist und am schwersten durch menschliche Arbeit stabil abgedeckt werden kann.
2. Szenario 1: Vorwärtsdesign der Systemsoftwarearchitektur – von einem Anforderungsdokument zur vollständigen Spezifikation
Dies ist das Kern-Szenario, das den "Effizienzunterschied" am besten zeigt.
Nehmen wir ein typisches Cockpit-Domain-Controller-Projekt:
Das Anforderungsdokument umfasst über 80 Seiten und deckt mehrere Funktionsbereiche ab: Energieverwaltung, Kommunikationsverwaltung, Diagnoseverwaltung, Zustandsverwaltung usw.
Bei der manuellen Erstellung der Architekturspezifikation muss der Architekt die Anforderungen einzeln aufschlüsseln, nach der Vier-Schichten-Architektur schichten, Unterarchitekturen und Komponenten definieren, für jede Funktionsbeschreibung und Schnittstellendefinition schreiben, Architektur- und Zeitablaufdiagramme zeichnen, die Schnittstellenmatrix ausfüllen und die Anforderungsrückverfolgung herstellen.
Ein erfahrener Architekt benötigt für diese Arbeit normalerweise zwei bis vier Wochen.
Früher: Wochenlanges manuelles Schreiben
Der Architekt musste die Anforderungen einzeln analysieren, das Design schichten, Dokumente schreiben, Diagramme zeichnen und Korrektur lesen.
Bei einer Änderung der Anforderungen musste der Einflussbereich erneut überprüft werden.
Jetzt: Generierung in Stunden
Der Architekt reicht lediglich das Anforderungsdokument und die Vorlage des Auftraggebers ein. Der Agent erledigt automatisch die Anforderungsanalyse, das Schichtendesign, die Schnittstellendefinition, das dynamische Szenario-Design und die Dokumentgenerierung. Das Ergebnis ist eine vollständige Word-Spezifikation, eine Excel-Schnittstellenmatrix und PlantUML-Architekturdiagramme.
Der Architekt beginnt nicht mehr mit einem leeren Dokument, sondern überprüft, überarbeitet und bestätigt auf Basis der generierten Ergebnisse.
Aber wichtiger als "schnell" ist die Wirkung:
- Vollständiger: Vollständige Rückverfolgung von Anforderungen zur Architektur, dynamische Szenarien und Ressourcenanalysen werden nicht mehr nur "geschrieben, wenn man daran denkt"
- Konsistenter: Die Struktur, Nummerierung und Terminologie des gesamten Dokuments sind einheitlich, und verschiedene Projekte können denselben Lieferstandard einhalten
- Normgerechter: Automatische Ausrichtung an die Dokumentationsanforderungen von ASPICE SWE.3, klare Schichtentrennung, keine grundlegenden Probleme wie schichtübergreifende Aufrufe
- Bessere Rückverfolgbarkeit: Die Zuordnung jeder Anforderung zu jedem Architekturelement ist auf einen Blick ersichtlich, bei Anforderungsänderungen können schnell die anzupassenden Komponenten identifiziert werden
3. Szenario 2: BSW-Basissoftwarearchitektur – AUTOSAR-Modul-Level-Design
Während sich die Middleware-Architektur auf "Schichtenkomponenten" konzentriert, konzentriert sich die BSW-Architektur (Basissoftware) auf das Modul-Level und API-Funktions-Level-Design von AUTOSAR CP.
Auch dies ist ein häufiges Schmerzpunktszenario.
Die BSW-Architekturspezifikation muss die von jedem Basismodul bereitgestellten API-Funktionen einzeln auflisten – Funktionsname, Parametertyp und -bedeutung, Rückgabewert, Aufrufbeziehungen – und zusätzlich Aufgabenperioden, Interrupt-Vektoren und die Compiler-Umgebung (OS- und Compiler-Version) ergänzen.
Diese Informationen sind über Code, Datenblätter und das Wissen der Ingenieure verstreut. Das manuelle Zusammenstellen in Textform ist fast so mühsam wie das Suchen von Bugs, nur um die Funktionssignaturen abzugleichen.
Der Agent geht direkt vom Anforderungsdokument aus, identifiziert automatisch die am Projekt beteiligten BSW-Module und generiert gemäß der Vorlage eine vollständige BSW-Architekturspezifikation.
Das Ergebnis enthält:
- API-Funktionsdefinitionen für jedes Modul
- Aufgaben- und Interrupt-Konfiguration
- Compiler-Umgebungsbeschreibung
- Rückverfolgungstabelle von Anforderungen zur Architektur
Die Wirkung ist direkt:
Früher musste man Code durchsuchen und mündlich bestätigen, um Funktionssignaturen zu ergänzen. Jetzt werden sie strukturiert ausgegeben, und das Team hat ein gemeinsames "Basis-Dokument".
Bei neuen Modulen fragt man nicht mehr "Wie hat das damals der alte Li entworfen?", sondern schaut in die Spezifikation.
4. Szenario 3: Anpassung an Auftraggeber-Vorlagen – keine Angst mehr vor Vorlagenwechseln
Der Wechsel der Auftraggeber-Vorlage ist ein weiterer "Albtraum" für Architekten.
Verschiedene OEMs, verschiedene Projektphasen – die Vorlagenformate sind sehr unterschiedlich.
Jedes Mal, wenn sich die Vorlage ändert, bedeutet das eine Runde aufwändiger Formatierungsanpassungen.
Aber dieses Problem ist im Wesentlichen kein "Architekturdesign"-Problem, sondern ein Problem der "Kopplung von Daten und Format".
Architekturdaten – Komponentendefinitionen, Schnittstellenmatrix, dynamische Szenarien – ändern sich nicht, nur weil die Vorlage eine neue Version hat; die Zeit wird damit verbraucht, dieselben Daten nach der neuen Vorlage neu zu layouten und zu korrigieren.
Der Agent entkoppelt diese beiden Dinge:
Die beim Architekturdesign erzeugten Daten bleiben strukturiert, und die Vorlagenanpassung erfolgt automatisch als "Daten in Format füllen".
Egal ob Word-Spezifikation oder Excel-Schnittstellenmatrix, der Agent erkennt automatisch die Kapitelstruktur und Platzhalter der Vorlage, füllt die Architekturdaten genau an die entsprechenden Stellen ein und behält gleichzeitig die ursprünglichen Schriftarten, Absätze und Tabellenstile der Vorlage bei.
Dies bringt drei Kernvorteile:
Erstens: Null Nacharbeit bei Vorlagenwechsel.
Der Auftraggeber wechselt die Vorlage, der Architekt muss nicht Kapitel für Kapitel neu layouten.
Einfach die neue Vorlage einreichen, der Agent durchläuft den Prozess und gibt die Spezifikation im neuen Format aus. Die Architekturdaten bleiben unverändert, das Format wird automatisch angepasst.
Zweitens: Ein Datensatz, mehrere Formatausgaben.
Dieselben Architekturentwurfsdaten können gleichzeitig nach der Vorlage von OEM A als Word, nach der Vorlage von OEM B als Excel und nach der internen Überprüfungsvorlage als Markdown ausgegeben werden.
Keine Notwendigkeit mehr, mehrere Dokumentensätze für verschiedene Abnehmer zu pflegen.
Drittens: Inhalt und Format getrennt verwalten.
Der Architekt konzentriert sich auf den Designinhalt, während Formatfragen wie Tabellenspaltenanzahl, Kapitelreihenfolge und Stildetails vom Agenten automatisch behandelt werden.
Ausfüllhinweise in der Vorlage werden automatisch entfernt, Platzhalter automatisch ersetzt, Diagramme automatisch eingebettet – der Mensch muss nicht Zeile für Zeile prüfen und reparieren.
Schlussbemerkung
Das Ziel des Softwarearchitektur-Design-Agenten ist es nie, den Architekten zu ersetzen.
Es soll die sich wiederholenden, mechanischen und geduldigsten Teile der Architekturdokumenterstellung ersetzen – Anforderungen aufschlüsseln, Vorlagen ausfüllen, Diagramme zeichnen, Rückverfolgung markieren, Prüfungen durchführen;
Und den Menschen die Entscheidungen überlassen, die wirklich Erfahrung und Urteilsvermögen erfordern:
- Auswahl des Architekturansatzes
- Bewertung von Design-Trade-offs
- Qualitätssicherung bei Überprüfungen
Besonders in einem Bereich wie der Automobil-Elektronik-Softwarearchitektur mit strengen Normen, starken Schichten und hoher Rückverfolgbarkeit liegt der größte Wert nicht nur darin, "schnell zu schreiben", sondern die Architekturdokumentation stabiler, konsistenter und leichter in den technischen Kreislauf des Teams zu integrieren:
- Jedes Dokument ist nachvollziehbar
- Jede Änderung ist rückverfolgbar
- Jede Überprüfung hat eine Grundlage
Wenn der Architekt nicht mehr von leeren Dokumenten und Auftraggeber-Vorlagen eingeschränkt wird, beginnt die wirklich wichtige Arbeit erst.
