Growing Requirements

It is still unclear when autonomous driving will become part of everyday road traffic. It will likely be a longer, evolutionary process, since the challenges are immense (Fig. 1) and must be all tackled in parallel:

• High software share: The cost of software is becoming increasingly dominant compared to hardware. ADAS/AD functions are largely implemented in software and integrated into a software-defined vehicle (SDV) to quickly pass on constant improvements to customers through updates.

• Growing importance of artificial intelligence: A dominant portion of the software stack will be AI-based. There is already a broad spectrum of different approaches here, ranging from a modular AD stack with an AI perception part, through end-to-end visual-language (VL) black-box models, to multimodal and explorative visual-language-action (VLA) models in the more distant future.
• Zonal, HPC‑based architectures: In order to meet the requirements of SDV and AD, the E/E vehicle architecture is also undergoing a revolutionary change, away from many ECUs distributed in the vehicle for specific tasks, towards zonal ECU architectures with a few powerful central high-performance computers (HPCs) that take over this multitude of central vehicle functions, process them in parallel, and also ensure redundancy for safe operation.
• Growing integration demands for sensors: Depending on the AD level, the degree of integration of vehicle sensors increases rapidly, often with a large number of specific interfaces, especially for cameras. For level 3, up to 30 sensors can be expected (6-8 cameras, 3-5 radars, at least one lidar, up to 16 ultrasounds), and for level 4, well over 40 (12 cameras, 10 radars, 4 lidars, 20 ultrasounds).

Managing Increasing Validation Effort

Due to the growing challenges, the cost of validating ADAS/AD functions for vehicle manufacturers and suppliers will increase exponentially and is estimated to be at least half of the total development costs in many cases in the coming years. This development will be intensified by the enormous pressure that vehicle manufacturers are under to bring new functions to the road at ever shorter intervals.

Coping with the enormous amount of testing required in an acceptable amount of time requires a new approach to the validation and vehicle approval process. This includes, among other things:

• Shift‑left testing: With shift-left, testing activities take place much earlier in the software development process. This means a significant shift from traditional to digital validation and homologation. Much of the testing and, to a certain extent, the assurance of conformity with applicable regulations are being shifted from real-world test drives to complex, but much more cost-effective, physics-based simulation environments. The ADAS/AD validation strategy includes SIL, HIL/VIL, and fleet tests, which are used in parallel and deliberately overlapping, according to their respective suitability. 
• DevOps‑based development: Based on an optimized DevOps-based development process (development loop) including end-to-end traceability, continuous software integration, deployment, validation, digital homologation, and over-the-air (OTA) updates, software can be delivered faster, more stable, and more continuously.
• Compliance with norms and ISO standards: In addition to functional safety in accordance with ISO 26262 and cybersecurity (ISO/SAE 21434), there is a particular focus on the risk-based verification of safety in accordance with SOTIF (ISO 21448). SOTIF (Safety of the Intended Functionality) focuses on reducing unknown risks to an acceptable level by converting them into known and controllable risks, or even into completely safe states. This is done with the help of scenario-based tests, which are thus becoming increasingly important and are finding their way into the validation-process by means of vehicle fleets, as well as SIL and HIL.

How will the role distribution between SIL and HIL look for ADAS/AD testing?

Due to better scalability and reproducibility compared to real test drives, SIL followed by HIL forms an essential part of ADAS/AD validation. SIL testing designed for operation in a cloud environment allows for maximum scalability and is used across the board for functional testing of the ADAS/AD chain of effects from perception to trajectory planning. The test execution can be easily parallelized and parameterized, allowing a large number of scenarios to be covered in a relatively short time with the corresponding availability of cloud capacity.

However, when it comes to modeling realistic time effects and emulating real hardware, SIL can reach its limits today. Modeling hardware effects is time-consuming, requires expert knowledge, and results in complex models that significantly slow down test execution at run time and thus counteract the benefits of SIL. The use of real ECUs eliminates this problem in HIL testing. In addition, HIL testing has other advantages – including the reliability of real-time validation of ADAS functionalities and the safeguarding of system performance, to name just a few (see Fig. 3 for further details).   

HIL testing is therefore already, and will remain in the future, an established and integral part of the holistic validation strategy for ADAS/AD, despite the higher costs and complexity compared to SIL.
 

What are the main test approaches for ADAS/AD validation via HIL?

There are two main complementary test approaches for validating ADAS/AD on the HIL simulator: data replay, also known as hardware reprocessing or open-loop HIL, and closed-loop HIL, often referred to as ADAS HIL or raw data HIL for short. Both test approaches access the same source data, but to different extents. The source data can be:

• The real scenarios recorded via the vehicle fleet
• Real scenarios enhanced by suitable augmentation methods such as AI, for example, with changed weather conditions such as rain or snowfall
• Synthetic scenarios derived from real images or generated from scratch

This raw data is fed to the systems under test (SUT) via the same sensor interfaces that will be available later in the vehicle (camera, radar, lidar, ultrasound). In addition, temporary so-called Design for Test (DfT) interfaces are often used during the development phase, which provide partially interpreted or abstracted data such as object lists. This can contribute to better structuring and simplification of the test task and is used in modular AD stacks where perception, sensor fusion, and planning algorithms run independently of each other.  

Data replay and closed-loop HIL are used with different focuses due to their specific advantages and depending on the type of ADAS/AD stack. Data replay is predominantly used from perception to function activation because the focus here is on the use of real recorded data. Closed-loop HIL, on the other hand, allows the validation of the entire chain of effects with a particular focus on planning and classic control algorithms.

How is uniform evaluation ensured?

For the evaluation of the maturity level of the test candidate and the homologation of the ADAS/AD functions, it is essential to be able to evaluate and compare the test results in a uniform manner, regardless of the test approach (SIL, HIL, or real test drive via fleet) and across different test methods (data replay, closed-loop test). This is mainly carried out on the basis of so-called key performance indicators (KPI). These are SUT-specific criteria that are defined in advance by responsible function owners and allow objective statements to be made about SUT performance, robustness, etc.

Efficient Testing with dSPACE

For validating ADAS/AD in HIL, dSPACE offers a comprehensive range of solutions (Fig. 5), which meet specific requirements such as synchronous feeding of sensor data or physics-based sensor simulation in real time. More details, with a special focus on the test approaches presented above and an outlook on the future challenges of HIL validation in the context of ADAS/AD, will follow in the second part of this article.