Von der Werkzeugauswahl bis zum geschlossenen Regelkreis: Wie KI-Agenten in die Entwicklung von Elektrofahrzeugsystemen mit drei Elektromotoren Einzug halten

Autor: Johnny Liu, CEO bei Dowway Vehicle

Veröffentlicht am: 9. Juli 2026

Lesezeit: 15 Minuten

Kategorie: Elektrofahrzeuge, KI-Engineering, modellbasiertes Design (MBD)

Jenseits des Chatbot-Hypes

Wenn Ihr Softwareentwicklungsteam im Automobilbereich Frameworks wie Hermes-Agent oder OpenClaw Wer lediglich einen „intelligenteren Chatbot“ sieht, nutzt ihn falsch. In der hochintegrierten Automobilforschung und -entwicklung – insbesondere bei „Drei-Elektro“-Systemen (Batteriemanagementsystem) – ist Vorsicht geboten.[BMS]Fahrzeugsteuergerät[VCU]und Motorsteuereinheit[MCU]— Der eigentliche Wert einer KI besteht nicht darin, endgültige Entscheidungen für Ingenieure zu treffen.

Sein Wert liegt vielmehr in seiner Fähigkeit, Dateizugriff, Toolaufrufe, CLI-Befehlsausführung, Browser-Sandboxing und den Abruf von Unternehmenswissen in einem System zu organisieren. überprüfbare, deterministische Engineering-PipelineDie

Dieser Artikel erklärt, wie KI-Agenten die fragmentierten Werkzeuge des modellbasierten Designs (MBD) verbinden können, ohne Kompromisse bei der Sicherheit einzugehen, und zeichnet einen klaren Weg vom einfachen Werkzeugaufruf bis hin zu einem vollständig geschlossenen Engineering-Kreislauf nach.

1. Das zentrale Problem im Engineering: Fragmentierte Dateien, isolierte Tools und unterbrochene Beweisketten

Jeder erfahrene Softwareentwickler für Antriebssysteme weiß, dass ein typischer Fehler in einem Steuerungssystem selten auf eine einzelne, isolierte Datei zurückzuführen ist. Betrachten Sie folgendes typisches Fehlersuchszenario:

• Symptom: Bei niedrigen Temperaturen sinkt die maximale Ladeleistung der Batterie unerwartet ab. Dies tritt zusammen mit sporadischen Drehmomentbegrenzungen und einer Diskrepanz zwischen dem tatsächlichen Reglerausgang und den Systemvorgaben im Diagnosefehlercode (DTC) auf.

Um dieses Problem zu diagnostizieren, muss ein Ingenieur gleichzeitig einen riesigen, fragmentierten Datensatz öffnen, analysieren und Querverweise herstellen:

[System Requirements] ── (DOORS / Word)
       │
[Software Model]       ── (MATLAB Simulink / Stateflow)
       │
[Network Interfaces]   ── (DBC / ARXML)
       │
[Memory Mapping]       ── (ASAP2 / A2L / Calibration Parameters)
       │
[Real-world Behavior]  ── (Vector CANoe Trace / CANape Logs / MDF4)

Die vier Ebenen der Fragmentierung

Dieser Arbeitsablauf verdeutlicht eine starke Fragmentierung in vier verschiedenen Dimensionen:

1. Dateifragmentierung: Die Anforderungen befinden sich in Word oder IBM DOORS; die Steuerlogik befindet sich in MATLAB Simulink-Modellen (.slx) und Stateflow-Diagrammen; Bus-Schnittstellen werden definiert in .dbc oder .arxml; Speicheradressen sind definiert in .a2lDie Testskripte sind in CAPL oder Python geschrieben; Testprotokolle existieren in .mdf, .dat, oder .csv Dateien.
2. Toolchain-Isolation: Ingenieure müssen ständig zwischen verschiedenen Kontexten wechseln. Sie springen von MATLAB/Simulink (Modellentwurf) zu Vector CANoe (Bussimulation), Vector CANape oder TsMaster (Kalibrierung/Messung), Excel (Datenmapping) und internen webbasierten Problemverfolgungssystemen (Jira).
3. Semantische Inkonsistenz: Dieselbe physikalische Variable (wie z. B. der angestrebte Batterieladestrom) könnte auch so benannt werden Ziel_Änderung_Aktuell in der Spezifikation der funktionalen Anforderungen, bms_I_target im Simulink-Modellarbeitsbereich, BMS_Zielstrom in der CAN DBC-Signaldatenbank und P_BMS_Chg_Curr_Limit in der Kalibrierungsdatei A2L. Sie weisen häufig unterschiedliche Abtastraten, Skalierungsfaktoren, Einheiten und gültige Wertebereiche auf.
4. Fehlende Beweisketten: Eine generative KI kann leicht eine hypothetische Ursache vorschlagen. Kann dieser Vorschlag jedoch nicht auf eine bestimmte Millisekunde in einem Protokoll, einen bestimmten Signalübergang in einer Aufzeichnung, einen bestimmten Pfad in einem Simulink-Modell oder eine bestimmte Testfall-ID verweisen, dann kann nicht als technische Schlussfolgerung akzeptiert werdenDie

Die Frage ist nicht, wie intelligent der LLM-Absolvent ist. Die Frage ist: Wo ist der KI-Agent in der MBD-Toolchain positioniert, wie greift er auf Dateien zu, wann darf er Skripte aufrufen und wann muss er die Kontrolle an einen menschlichen Entwickler zurückgeben?

2. Die Grenzen der traditionellen Automatisierung im Vergleich zur agentischen Grenze

Die Softwareabteilungen der Automobilindustrie nutzen seit Jahrzehnten automatisierte Skripte (MATLAB-APIs, Python-DBC-Parser, CAPL-Testsuiten, CI/CD-Jenkins-Pipelines und Excel-Makros). Diese Tools sind hochgradig deterministisch, reproduzierbar und vollständig nachvollziehbar.

Allerdings sind sie mit hohen Kontextwechselkosten verbunden. Ein Python-Skript kann einen DBC parsen und ein MATLAB-Skript kann eine Modellprüfung durchführen, aber sie teilen keinen semantischen Kontext.

Die folgende Matrix definiert, wo herkömmliche Automatisierungsskripte an ihre Grenzen stoßen und wo KI-Agenten eingreifen sollten:

Technisches Artefakt	Grenzen der traditionellen Automatisierung	Die Grenze des KI-Agenten
Simulink / Stateflow	Skripte führen statische Designregelprüfungen (ähnlich wie Model Advisor) durch und generieren XML-Berichte. Die Interpretation dieser Berichte und die Zuordnung von Fehlern zu Systemanforderungen erfordert jedoch weiterhin manuelle Arbeit.	Der Agent liest den Bericht des Modellberaters und die ursprüngliche Spezifikation, erfasst die Fehler und erstellt eine priorisierte Liste der technischen Probleme. niemals Bearbeitet die Modelldateien direkt.
DBC / A2L / MDF	Mit Python- oder CANape-Skripten lassen sich Signallisten extrahieren, aber die Zuordnung von Variablen zwischen DBC und A2L erfordert von den Ingenieuren die Pflege manueller, fehleranfälliger Excel-Konvertierungstabellen.	Der Agent löst semantische Zuordnungsfehler dynamisch auf, indem er Skalierungsfaktoren, Datentypen, physikalische Einheiten und Kalibrierungsparameterversionen über DBC, A2L und Modelle hinweg analysiert.
Kanu / CAPL	Automatisierte Testumgebungen führen Testskripte aus und exportieren HTML-Testberichte. Die Ermittlung der Ursache eines „Fehler“-Ergebnisses erfordert jedoch die manuelle Auswertung der Protokolle.	Der Agent scannt die CANoe-Testaufzeichnung und die CAPL-Protokolldateien, ermittelt den genauen Fehlerzeitstempel, korreliert ihn mit Diagnosecodes und entwirft Korrekturen für das CAPL-Skript.
Anforderungsspezifikationen	Standard-Skripte können zwar überprüfen, ob ein Anforderungsdokument ein ID-Feld enthält, aber sie können weder die Verständlichkeit des Textes beurteilen noch die Testabdeckung abbilden.	Der Agent extrahiert funktionale Akzeptanzkriterien, gleicht sie mit tatsächlichen Testpunkten ab und generiert einen Entwurf einer durchgängigen Rückverfolgbarkeitsmatrix.
Interne Webtools	Die Ingenieure müssen Trace-Protokolle oder Diagnosefehlercodes manuell in Jira, Confluence oder interne Wissensdatenbanken kopieren und einfügen.	Der Agent verwendet Such- und Abrufwerkzeuge, um interne Datenbanken zu durchsuchen, Querverweise zu historischen Problemprotokollen herzustellen und Referenzen zusammen mit den Quell-URLs zu protokollieren.

3. Referenzarchitektur: LLMs auf der Orchestrierungsschicht

Um KI-Agenten sicher in der Entwicklung sicherheitskritischer Systeme (wie z. B. ISO 26262 ASIL-D Software-Pipelines) einzusetzen, muss sich das LLM strikt im Orchestrierungsebene, vollständig isoliert von SicherheitsausführungsschleifeDie

    ┌────────────────────────────────────────────────────────┐
    │                  HUMAN ENGINEER (Review)               │
    └───────────────────────────▲────────────────────────────┘
                                │
               [State / Logs]   │   [Approve / Correct]
                                │
    ┌───────────────────────────▼────────────────────────────┐
    │             LLM ORCHESTRATION LAYER (Agent)            │
    │  - Plan Formulation        - Context Assembly          │
    │  - Semantic Mapping        - Reasoning & Tool-calling  │
    └───────────────────────────┬────────────────────────────┘
                                │
            [Authorized Tool Calls] / [Structured Outputs]
                                │
    ┌───────────────────────────▼────────────────────────────┐
    │               AUDITABLE EXECUTION LAYER                │
    │  ┌───────────────────────┐   ┌───────────────────────┐  │
    │  │  Sandboxed Environment│   │   Whitelisted Tools   │  │
    │  │  - Read-Only Snapshots│   │   - MATLAB / CANoe APIs│  │
    │  │  - Isolated Browsers  │   │   - Python/CAPL Parsers│  │
    │  └───────────────────────┘   └───────────────────────┘  │
    └────────────────────────────────────────────────────────┘

Frameworks wie OpenClaw Werkzeuge werden als strukturierte Funktionen definiert, die der Agent aufrufen kann (Ausführung, Webabfrage, lokale Suche, Nachrichtenübermittlung). Ebenso Hermes-Agent nutzt lokale Sandboxing-Umgebungen, um Systemdienstprogramme sicher auszuführen.

Für Automobilsoftware müssen wir fünf absolute Sicherheitsvorkehrungen treffen:

1. Read-Only Storage Sandboxing: Der Agent muss auf einem schreibgeschützten Snapshot oder einem dedizierten Git-Branch des Arbeitsbereichs ausgeführt werden (./project_snapshotEs darf niemals Schreibzugriff auf Produktionszweige, kryptografische Schlüssel oder proprietäre Baseline-Repositories haben.
2. Aufruf von Tools auf der Whitelist: Der Agent kann keine direkten Shell-Befehle ausführen. Stattdessen muss er mit dem Entwicklungs-Ökosystem interagieren, indem er eine Whitelist vorgefertigter, deterministischer Python- oder MATLAB-Runner-Skripte aufruft.
3. Protokollierung von Ausführungsbeschränkungen: Jede Skriptausführung muss innerhalb eines festgelegten Verzeichnisses erfolgen, Ausführungszeitlimits müssen eingehalten werden und alle Daten müssen automatisch erfasst werden. stdout, stderr, Exit-Codes und Hashes der Eingabedateien. Diese Protokolle werden in einem unveränderlichen Audit-Trail gespeichert.
4. Isolierte Browserprofile: Für den Webabruf (z. B. zum Nachschlagen von ASAM-Standarddefinitionen oder zum Überprüfen interner Jira-Boards) muss der Agent ein dediziertes Browserprofil verwenden, das vollständig von persönlichen oder unternehmensweiten SSO-Anmeldeinformationen isoliert ist.
5. Mandantensegmentierung der Wissensdatenbank: Beim Anschluss an RAG-Datenbanken (Retrieval-Augmented Generation), die proprietäre Kalibrierungsrichtlinien oder Debugging-Daten aus früheren Projekten enthalten, muss das System eine strikte rollenbasierte Zugriffskontrolle (RBAC) durchsetzen, um IP-Leaks zwischen Kunden zu verhindern.

4. Schrittweise Integration: Zuordnung des Agenten zur MBD-Toolchain

Lassen Sie uns untersuchen, wie ein KI-Agent einen vollständigen, vierstufigen MBD-Workflow ausführt.

Step 1: Parse Specs ──► Step 2: Scan Model ──► Step 3: Align Signals ──► Step 4: Parse Logs
 (Requirements to         (MATLAB Report         (DBC to A2L          (CANoe Trace
   Test Matrix)            Analyzer)               Mapping)             to Evidence)

Schritt 4.1: Anforderungsspezifikation zur Erstellung der Testmatrix

Der Agent verarbeitet Anforderungsdokumente (z. B. Markdown- oder JSON-Dateien, die aus DOORS exportiert wurden). Er analysiert jede Funktionsklausel, um Folgendes zu extrahieren:

• Vorbedingungen (zum Beispiel Batterietemperatur < -10 °C)
• Aktive Eingaben (wie z. B. Ladestecker erkannt == WAHR)
• Erwartete Systemausgaben (wie z. B. Max_Chg_Current_Limit == 15A)
• Zugehörige Diagnosebedingungen.

Anstatt den endgültigen Code zu schreiben, gibt der Agent eine strukturierte Ausgabe aus. Entwurf der Testmatrix im JSON-Format, wobei explizite Validierungspunkte für nachfolgende MIL/SIL/HIL-Tests definiert werden.

Schritt 4.2: Modellverifizierung zur Erstellung von Checklisten

Der Agent ist daran gehindert, Simulink-Modelle zu modifizieren (.slx) oder Stateflow-Diagramme direkt. Stattdessen ruft es ein lokales MATLAB-Skript über die Befehlszeilenschnittstelle auf. Dieses Runner-Skript:

1. Öffnet MATLAB in einer Headless-Sitzung.
2. Führt benutzerdefinierte statische Designregelprüfungen durch (z. B. Überprüfung von Namenskonventionen oder Suche nach nicht verknüpften Signalanschlüssen).
3. Exportiert einen strukturierten Diagnosebericht.

Der Agent liest diesen Bericht, gleicht ihn mit den Software-Designrichtlinien ab und erstellt eine strukturierte Checkliste, die Fehler hervorhebt (z. B. „Zustandsflussdiagramm“). Charge_Manager fehlt ein Standardübergangspfad”).

Schritt 4.3: Semantische Zuordnung von DBC-, A2L- und Kalibrierungsfeldern

In diesem Schritt werden die physikalischen Kommunikationssignale mit dem internen Speicher des Controllers abgeglichen. Der Agent ruft einen speziellen Python-Parser auf, um die CAN-DBC- und die Controller-A2L-Datei zu lesen.

Anschließend wird eine einheitliche Variablenzuordnungstabelle erstellt und auf kritische Abweichungen geprüft:

[Signal: BMS_Target_I] ── (DBC Unit: Ampere | Scale: 0.1 | Offset: 0)
                                 VS
[Parameter: Target_I_Cal] ── (A2L Unit: Ampere | Scale: 0.01 | Offset: -40)
                                 ▲
                         [Agent Flags Mismatch]