From Tool Calling to Engineering Closed-Loop: How AI Agents Land in EV “Three-Electric” System Development

Author: Johnny Liu, CEO at Dowway Vehicle

Published on: July 9, 2026

Read Time: 15 mins

Category: Electric Vehicles, AI Engineering, Model-Based Design (MBD)

Beyond the Chatbot Hype

If your automotive software engineering team looks at frameworks like Hermes Agent or OpenClaw and simply sees a “smarter chatbot,” they are using them wrong. In high-integrity automotive R&D—especially within “Three-Electric” systems (Battery Management System [BMS], Vehicle Control Unit [VCU], and Motor Control Unit [MCU])—an AI’s real value is not to make final decisions for engineers.

Instead, its value lies in its ability to organize file access, tool calling, CLI command execution, browser sandboxing, and enterprise knowledge retrieval into an auditable, deterministic engineering pipeline.

This article explains how AI Agents can bridge the fragmented tools of Model-Based Design (MBD) without compromising safety, tracing a clear path from simple tool calling to a complete engineering closed-loop.

1. The Core Engineering Pain Point: Fragmented Files, Siloed Tools, and Broken Evidence Chains

Any experienced powertrain software engineer knows that a typical control system defect rarely originates in a single, isolated file. Consider this standard troubleshooting scenario:

• Symptom: Under low-temperature conditions, the battery charging power limit drops unexpectedly. This happens alongside sporadic torque limitations and a diagnostic trouble code (DTC) mismatch between the actual controller output and the system specification.

To diagnose this issue, an engineer must concurrently open, parse, and cross-reference a massive, fragmented dataset:

[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)

The Four Levels of Fragmentation

This workflow highlights severe fragmentation across four distinct dimensions:

1. File-Level Fragmentation: Requirements reside in Word or IBM DOORS; control logic lives in MATLAB Simulink models (.slx) and Stateflow charts; bus interfaces are defined in .dbc or .arxml; memory addresses are defined in .a2l; test scripts are written in CAPL or Python; test logs exist in .mdf, .dat, or .csv files.
2. Toolchain Isolation: Engineers must constantly switch contexts. They jump from MATLAB/Simulink (model design) to Vector CANoe (bus simulation), Vector CANape or TsMaster (calibration/measurement), Excel (data mapping), and internal web-based issue trackers (Jira).
3. Semantic Inconsistency: The exact same physical variable (such as target battery charging current) might be named Target_Chg_Curr in the functional requirement specification, bms_I_target in the Simulink model workspace, BMS_TargetCurrent in the CAN DBC signal database, and P_BMS_Chg_Curr_Limit in the calibration A2L file. They often have different sampling rates, scaling factors, units, and valid value ranges.
4. Missing Evidence Chains: A generative AI can easily suggest a hypothetical root cause. However, if that suggestion cannot point to a specific millisecond in a log, a specific signal transition in a trace, a specific path in a Simulink model, or a specific test case ID, it cannot be accepted as an engineering conclusion.

The question is not how smart the LLM is. The question is: Where does the AI Agent stand in the MBD toolchain, how does it access files, when is it allowed to call scripts, and when must it halt to yield control back to a human engineer?

2. The Limits of Traditional Automation vs. The Agentic Boundary

Automotive software departments have used automated scripts (MATLAB APIs, Python DBC parsers, CAPL test suites, CI/CD Jenkins pipelines, and Excel macros) for decades. These tools are highly deterministic, repeatable, and completely auditable.

However, they suffer from high context-switching costs. A Python script can parse a DBC, and a MATLAB script can run a model check, but they do not share semantic context.

The following matrix defines where traditional automation scripts hit a wall and where AI Agents should step in:

Engineering Artifact	Traditional Automation Limits	The AI Agent Boundary
Simulink / Stateflow	Scripts run Static Design Rule Checks (like Model Advisor) and generate XML reports. However, interpreting these reports and linking failures back to system requirements still requires manual work.	The Agent reads the Model Advisor report and the original specification, maps the failures, and generates a prioritized engineering issue list. It never directly edits the model files.
DBC / A2L / MDF	Python or CANape scripts can extract signal lists, but mapping variables across DBC and A2L requires engineers to maintain manual, fragile Excel conversion tables.	The Agent dynamically resolves semantic mapping mismatches by analyzing scaling factors, data types, physical units, and calibration parameter versions across DBC, A2L, and models.
CANoe / CAPL	Automated test benches execute test scripts and export HTML test reports. However, finding the root cause of a “Fail” verdict requires manual tracing of logs.	The Agent scans the CANoe test trace and CAPL log files, isolates the exact failure timestamp, correlates it with diagnostic codes, and drafts CAPL script corrections.
Requirements Specs	Standard scripts can verify if a requirement document has an ID field, but they cannot assess text clarity or map test coverage.	The Agent extracts functional acceptance criteria, matches them with actual test points, and generates an end-to-end traceability matrix draft.
Internal Web Tools	Engineers must manually copy and paste trace logs or diagnostic error codes into Jira, Confluence, or internal knowledge bases.	The Agent uses search and retrieval tools to scan internal databases, cross-references historical issue logs, and records references alongside the source URLs.

3. Reference Architecture: LLMs at the Orchestration Layer

To safely deploy AI Agents in safety-critical systems development (such as ISO 26262 ASIL-D software pipelines), the LLM must reside strictly in the Orchestration Layer, completely isolated from the Safety Execution Loop.

    ┌────────────────────────────────────────────────────────┐
    │                  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 like OpenClaw define tools as structured functions that the Agent can invoke (execution, web retrieval, local search, messaging). Similarly, Hermes Agent uses local sandboxing to run system utilities safely.

For automotive software, we must establish five absolute security guardrails:

1. Read-Only Storage Sandboxing: The Agent must operate on a read-only snapshot or a dedicated git branch of the workspace (./project_snapshot). It must never have write access to production branches, cryptographic keys, or proprietary baseline repositories.
2. Whitelisted Tool Calling: The Agent cannot run raw shell commands. Instead, it must interact with the engineering ecosystem by invoking a whitelist of pre-written, deterministic Python or MATLAB runner scripts.
3. Execution Constraint Logging: Every script execution must run within a strict directory, enforce execution timeout limits, and automatically capture all stdout, stderr, exit codes, and input file hashes. These logs are preserved in an unalterable audit trail.
4. Isolated Browser Profiles: For web retrieval (such as looking up ASAM standard definitions or checking internal Jira boards), the Agent must use a dedicated browser profile that is completely isolated from personal or enterprise SSO credentials.
5. Knowledge Base Tenant Segregation: When connecting to retrieval-augmented generation (RAG) databases containing proprietary calibration guidelines or previous project debugging data, the system must enforce strict role-based access control (RBAC) to prevent cross-customer IP leaks.

4. Step-by-Step Integration: Mapping the Agent to the MBD Toolchain

Let us examine how an AI Agent executes a complete, four-step MBD workflow.

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)

Step 4.1: Requirements Specification to Test Matrix Drafting

The Agent ingests requirements documents (such as markdown or JSON files exported from DOORS). It analyzes each functional clause to extract:

• Pre-conditions (for example, Battery_Temp < -10°C)
• Active inputs (such as Charge_Plug_Detected == TRUE)
• Expected system outputs (such as Max_Chg_Current_Limit == 15A)
• Associated diagnostic conditions.

Rather than trying to write the final code, the Agent outputs a structured Test Matrix Draft in JSON format, defining explicit validation points for subsequent MIL/SIL/HIL testing.

Step 4.2: Model Verification to Issue Checklists

The Agent is blocked from modifying Simulink models (.slx) or Stateflow charts directly. Instead, it invokes a local MATLAB script via the command-line interface. This runner script:

1. Opens MATLAB in a headless session.
2. Runs custom static design rule checkers (such as checking naming conventions or searching for unlinked signal ports).
3. Exports a structured diagnostic report.

The Agent reads this report, cross-references it with the software design guidelines, and generates a structured checklist highlighting errors (such as “Stateflow chart Charge_Manager is missing a default transition path”).

Step 4.3: Semantic Mapping of DBC, A2L, and Calibration Fields

This step matches physical communication signals with internal controller memory. The Agent calls a dedicated Python parser to read the CAN DBC and the controller A2L file.

It then builds a unified variable mapping table and checks for critical discrepancies:

[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]