Virtual Testing
Virtual Testing

Virtual testing - a game changer in vehicle development

Software-defined vehicle (SDV): no longer a buzzword in the automotive industry, but the new standard. The resulting challenges are complex. For example, how can costs be reduced in vehicle development while at the same time substantially increasing development speed? How can high quality be guaranteed despite the increasing complexity of electronics and the explosion of source code within the control units? And how can the ongoing digitalization of vehicles and the necessary acceleration of time-to-market be achieved? The answer is: virtual testing.

How does virtual testing work?

The idea is to set up and operate test platforms without the use of physical (vehicle) hardware. Composite and integration testing does not involve working with the code of individual software modules, but rather looks at the overall integration of the vehicle software as a black box and at a functional level from the customer's (driver's) perspective.

A modern vehicle consists not just of a single control unit, but of more than 100 different control units. In virtual testing, the digital twins of these control units are integrated into a virtual test platform and tested there. In contrast to the hardware-based test approach, this process can start early in development and run continuously ("continuous testing"), as the software can be validated completely virtually without hardware. In addition, the use of cloud technologies allows us to scale up to almost any size.

And why is this now a game changer?

Virtual testing shows its greatest strength in the design of the test platforms. Platforms built with hardware are often very static and only designed for a few use cases. The design of virtual test benches is dynamic and can be configured and modified as required. In fact, with extensive virtualization of the ECU, we can also carry out very hardware-related content such as bus conformity, diagnostics and various fault simulations. This means that the vECU offers great added value not only in development, but also in production and after sales, where various use cases can be mapped.

So-called Level 3 and Level 4 vECUs can even be coupled with real test benches under certain conditions. This means that a hardware setup can be expanded in a targeted manner. With a good test concept, test cases can also be transferred from a real test bench to a virtual test bench.

What does this mean in concrete terms?

Imagine that the change of a single line of code or the release of an ECU leads to fully automated validation of the entire vehicle domain or even the virtual vehicle (vCAR). Virtual testing detects errors at an early stage and significantly improves software quality before it reaches the hardware ECUs.

Sounds complicated?

It is, but fortunately we know our stuff. We help you to think about the safeguarding of functions as early as the design stage of the software architecture. If test concepts are developed at an early stage that harmonize the various integration levels of the virtual control units with the integration levels of existing hardware platforms, not only can a significant cost reduction be achieved, but the development speed can also be substantially increased.

A complete virtual vehicle (vCAR) is just as much our goal as responding quickly and efficiently to requirements in the areas of OTA, connected mobility, in-car apps, automotive security and many other software-defined solutions.

Virtual testing in 55 seconds. Watch the video!

Would you like to understand more about what is behind a vECU and what the levels 1-4 mean?

vECUs enable the simulation of productive software on extended computer hardware, which accelerates development in various phases and significantly improves software quality.

Classification of virtual control units

Level-0 vECU

Exclusively the controller model, e.g. as MATLAB Simulink.

No focus in the area of virtual validation.

Level-1 vECU

Productive SWC (application code) with partially generated basic software.
Communication via signal level.

Example: Individual applications within the vECU (e.g. ESC) or in combination with other software components.

Level-2 vECU

As Level 1, supplemented by simulated basic software, which also offers communication capabilities at bus or network level.

Example: Ideal for securing application code and bus communication, including use with restbus models or comparable applications.

Level-3 vECU

Contains SWC and productive basic software, i.e. fully comparable with the real ECU, apart from the hardware level.

Example: Contains maximum productive code of the real ECU, optimal for the functional validation of almost all functions, with the exception of the hardware level.