Automotive development is undergoing unprecedented change: exploding software complexity, faster OTA updates, diverse user experience demands. Traditional "develop-test-deliver" pipelines are struggling. CI/CD, as the core of Agile, is increasingly adopted in automotive R&D—especially among new EV makers.

But cars aren't phones. Whether software "actually works" must be validated in real hardware environments. This raises a key question: how does automotive CI/CD extend to hardware—achieving a true closed loop from code to vehicle validation?

Why HIL Is Critical for Automotive CI/CD

In traditional software, validating code means running unit tests, integration tests, and UI tests. In automotive, this is far from enough.

Smart cockpits, autonomous driving, powertrain control—all are deeply coupled with hardware. Even bug-free code can fail due to slow CAN frames or abnormal sensor readings. Only validation in real or simulated hardware environments determines whether software is deliverable.

This is where HIL (Hardware-in-the-Loop) comes in—it simulates vehicle hardware and external environments, letting ECUs run in a "realistic" setting for systematic validation.

But problems remain:

HIL benches are expensive—hundreds of thousands each

Concurrent development means frequent code commits, test request backlogs, severe queuing

Benches are scattered: busy benches run 24/7 and still can't keep up; idle benches sit unused

Test results lack traceability to V-model left-side docs—no real closed loop

We need a better solution.

3-Layer Architecture: Central Scheduling + HIL Cluster + Traceable ALM

To solve these challenges, we built a 3-layer test architecture: Central Scheduling System + HIL Test Cluster + Traceability-Enhanced ALM.

1. Central Scheduling: Optimal Resource Allocation

The scheduling system manages all test resources: each HIL bench's configuration, status, software version; pending tasks in the queue; distribution of test tools (Polartest, CANoe, ECU-TEST, Python scripts).

When a developer triggers CI (code commit, merge request, or manual trigger), the system automatically analyzes required resources, calls the right bench, installs the build-under-test, and runs test tools. The scheduler also dynamically balances load—benches neither idle nor jammed.

2. Test Cluster: From Single Points to Elastic Testing

The cluster consists of multiple HIL benches, each with a test PC (running tools like Polartest), test boards, and I/O interfaces. Unified scheduling turns these benches from "local services" into a "shared resource pool," dramatically improving utilization.

3. ALM: Closing the Loop Between Test Results and Requirements

Traditional test reports only answer: pass or fail? But in the vehicle V-model context, we care more about:

Which requirement does this failing test case map to?

Which architecture blocks are affected?

Did this test plan fully cover all critical requirements?

The scheduling system feeds test reports into the ALM, enabling: automatic result parsing, auto-linking to requirements/architecture/design, visualized coverage reports, and one-click navigation from test results to requirement details.

Test reports are no longer isolated static PDFs or HTML files—they become dynamic, interactive, traceable, closed-loop digital assets.

Practical Takeaways: How to Build This from Scratch

Start Small with Focused Benches

Don't start with 100 benches. Pick key subsystems (parking, HMI interaction), build 1-2 automated benches to validate the flow, then scale gradually.

Build the Scheduling System First

Prioritize the central scheduling system to connect the flow, then gradually add test nodes from different vendors and toolchains.

"Pin-in" ALM Traceability

Don't change existing docs and tools—use APIs to achieve doc parsing and navigation.

Data-Driven Optimization

Build test execution logs, failure cause statistics, and resource utilization analysis to dynamically optimize test strategies and bench configurations.