A continuous development story for AEB systems

Modern automotive development is increasingly defined by one central challenge: how to deliver highly complex, safety-critical software faster, without compromising quality. This becomes particularly evident in advanced driver assistance systems (ADAS) such as automated emergency braking (AEB), where even a minor defect can have significant consequences.

To illustrate how this challenge can be addressed, let us follow a single, continuous use case through the entire development process from initial failure to validated solution, while highlighting how a shift-left strategy fundamentally transforms the workflow.

The story begins in a high-fidelity driving simulator, where a vehicle navigates a detailed suburban environment. The scene is realistic: an intersection, limited visibility and a sudden, unexpected event. A child steps into the street from a blind spot just after the vehicle passes the junction.

Although the driver reacts quickly, the situation reveals a critical flaw. The AEB system fails to intervene due to a software error, resulting in a near miss that could easily translate into an accident under real-world conditions. This defect ultimately leads to a product recall, requiring a fix that must be validated comprehensively before an over-the-air update can be deployed.

At this point, the limitations of traditional validation approaches become apparent. Physical proving ground testing is expensive, time-consuming and difficult to scale, making it increasingly incompatible with the shortened development cycles of modern automotive programs.

To address these challenges, the shift-left approach moves testing activities earlier into the development lifecycle. Instead of waiting for late-stage validation, potential issues are identified and resolved at the earliest possible point.

This shift transforms the development process into a continuous validation pipeline, structured around three key phases

1. model-in-the-loop (MIL),
2. software-in-the-loop (SIL) and
3. hardware-in-the-loop (HIL).

Each phase adds a new level of realism and integration while maintaining a consistent testing foundation.

After the AEB defect is fixed, the process begins by validating the core braking algorithm. This stage, known as model-in-the-loop, focuses on the functional correctness of the algorithm itself, which is typically developed in environments such as MATLAB.

A major advantage of this phase is the ability to integrate realistic test scenarios early on. Standardized test cases, such as those defined by NCAP, can be executed directly in virtual simulation environments like CarMaker, effectively replicating proving ground conditions without requiring physical infrastructure.

To further increase efficiency, simulation is scaled using cloud-based platforms such as VIRTO. It enables large volumes of parameterized test cases to be executed in parallel, often overnight, with results automatically fed back into development workflows. By integrating these processes into CI/CD pipelines, validation becomes continuous and highly automated.

At the end of this stage, the AEB algorithm has been thoroughly validated in isolation and under a wide range of conditions, establishing a robust functional foundation.

With the core algorithm verified, the focus shifts to the full ECU software stack. In modern automotive systems, the AEB software component is part of a complex architecture. This architecture includes not only application software, but also the runtime environment and basic software layers, often aligned with AUTOSAR standards.

In the software-in-the-loop stage, a virtual ECU replicates this entire software stack, allowing it to be tested within a closed-loop simulation of the vehicle and its environment. Platforms such as Synopsys Silver enable the execution of virtual ECUs and their seamless integration with simulation tools such as CarMaker.

At this stage, validation extends beyond pure functionality. Engineers can analyze how the system behaves under realistic communication and fault conditions. Effects such as message delays, dropped CAN frames or checksum errors can be introduced deliberately to evaluate robustness. Depending on the complexity of the system, different integration methods are applied. They range from direct model coupling to message-based communication via virtual bus systems.

Despite this increased level of detail, SIL maintains the efficiency advantages of virtual testing. Simulations can still run faster than real time, be executed in parallel and integrated into automated pipelines. The comprehensive validation of the full software system hence becomes possible before any hardware is involved.

While virtual testing covers a significant portion of validation, certain aspects require interaction with real hardware. This includes hardware-specific timing behavior and integration characteristics that cannot be fully captured in a purely virtual environment.

In the hardware-in-the-loop stage, the real ECU is connected to a simulated vehicle environment running in real time. Traditionally, such setups have been expensive and limited in scalability. Modern approaches however significantly reduce these constraints.

By combining a simulation solution like CarMaker with a real-time hardware platform such as Xpack, the surrounding vehicle systems can be simulated with only the ECU itself physically present. This enables efficient restbus simulation without requiring full vehicle hardware. Depending on the use case, setups can range from comprehensive HIL test benches to more lightweight configurations using standard PCs and communication interfaces.

To further improve efficiency, multiple HIL systems can be operated in parallel as part of a HIL farm: test cases are distributed across systems, managed centrally and integrated into automated pipelines. This brings scalability closer to that of virtual environments.

One of the key strengths of this development approach is its continuity. The same critical scenario from the beginning – a child crossing the street – can be consistently reproduced and evaluated across all stages of the process:

• MIL: Validate the algorithmic behavior
• SIL: Test the interaction within the full software stack
• HIL: Confirm correct system behavior when deployed on real hardware

This seamless transition between stages ensures that knowledge and test coverage are preserved throughout the development lifecycle. Rather than isolated validation steps, the process becomes an integrated workflow where each stage builds upon the previous one. Furthermore, it minimizes redundant validation activities by preventing requirements from being tested multiple times across different stages, thereby avoiding unnecessary duplication of effort.

This is a key advantage of an end-to-end test strategy, especially in combination with VIRTO, as it establishes a high level of transparency and traceability, enabling all stakeholders to clearly understand which tests have already been performed, at which stage, by which methods and with what results.

The shift-left strategy does more than accelerate development timelines. It fundamentally changes how quality and safety are achieved in automotive systems.

By validating early, continuously and across multiple levels of abstraction, issues are not just detected, they are prevented from propagating throughout the system. This reduces risk, lowers costs and improves overall reliability.

Returning to the driving simulator, the impact becomes tangible. The same scenario that previously exposed a critical failure now demonstrates an accurately functioning system: As the child steps onto the road, the AEB responds instantly, and the vehicle brakes safely in time. What was once a near miss becomes a success story, not because the issue was fixed at the end, but because it was addressed at the very beginning of the development process.

For visual impressions of the use case I guided you through, please take a look at the video below.