Innovations in ADAS/AD Validation: The Evolution of HIL Architectures at Valeo with NI

Martin Zmrhal, Software Tool Development Team Leader, Valeo

Brenda Vargas, Senior Solution Marketing, Transportation Business Unit, NI

Valeo logo

 

Case Study Highlights

 

 

  • The evolution of HIL systems is essential to meet the evolving requirements of new technologies and achieve the goal of safer vehicles on the roads.
  • The Valeo DVS team used three HIL architectures over time, each with unique capabilities to meet ADAS/AD growing complexity.
  • The NI-Valeo collaboration advances ADAS validation with standardized NI PXI systems, ensuring OEMs satisfaction in the dynamic automotive industry.

 

PARK4U®, an Automated Parking System

“At Valeo, we believe that skills, software/hardware alignment, and platform consistency are the keys to cover always-challenging ADAS validation requirements. And we are confident that NI and the NI PXI platform will give us what we need to keep pace with industry challenges and to keep our customer happy by meeting expectations.”

—​Martin Zmrhal, Software Tool Development Team Leader, Valeo

The Challenge

ADAS and AD systems are becoming increasingly complex, and traditional HIL architectures can no longer meet industry needs. Valeo needed a HIL system that could provide the performance, accuracy, and scalability necessary to meet current and future needs.

The Solution

The Valeo DVS team used NI‘s new HIL architecture based on the NI PXI platform plus RDMA technology. The new architecture offers standardization, performance, and accuracy, enabling them to develop and deploy HIL systems more quickly and efficiently while also ensuring the safety and reliability of ADAS/AD systems.​

​​At the Heart of the Mobility Revolution

​The pursuit of replacing human drivers with advanced autonomous systems holds the promise of increased productivity, enhanced comfort, and reduced accidents on our roads. However, this ambitious goal comes with its share of challenges and concerns, particularly related to the critical issues of system failure and safety. Achieving higher levels of vehicle automation demands comprehensive testing against an almost infinite number of real-world scenarios.

 

To address this challenge, automotive companies are endeavoring to continuously develop technologies and validation testing strategies. One of those companies is Valeo, a global leader in automotive technology solutions. Valeo has played a pioneering role in shaping the landscape of electrification, advanced driver assistance systems (ADAS), and autonomous driving (AD). With a legacy of innovation and a commitment to delivering cutting-edge solutions, Valeo’s collaboration with NI is continuously evolving toward a safer future.

 

ADAS and Automated Parking (AP) Overview

​As ADAS system complexity grows, it becomes increasingly challenging to test these systems only in real vehicles. Virtual validation is an industry trend, driven by the need to reduce testing time, costs, and the ability to test extreme scenarios that are challenging in real-world conditions.

 

​This challenge is particularly true in AP systems, which rely on sensor fusion to create a virtual map of the vehicle‘s surroundings to enable autonomous parking maneuvers. Given the complexity of these systems, extensive validation is required, involving thousands of test cases with each software release. However, testing the entire system in the target vehicle is often impossible because of the vehicle’s unavailability before market launch.

 

Valeo Automated Parking ECU Architecture

Figure 1: Valeo Automated Parking ECU Architecture

 

​To overcome the challenges, the Driving Vision Systems (DVS) team at Valeo uses a comprehensive testing approach based on open-loop and closed-loop hardware-in-the-loop (HIL) technology. This approach involves conducting tests of the software running on the electronic control unit (ECU) outside the vehicle, utilizing a dedicated test bench within the laboratory environment:

 

  • Open-Loop Replay HIL—This method involves injecting prerecorded real-road data into the ECU. It is mainly used for testing computer vision algorithms and detection rates.
  • Closed-Loop Virtual HIL—Synthetic sensor data is generated and fed into the ECU. This setup allows for feedback from the ECU to simulate vehicle behavior accurately.

 

​While in-vehicle testing provides real-world dynamics and environments, it is expensive, time-consuming, and subject to various constraints. On the other hand, virtual HIL testing offers advantages in terms of scalability, automation, and cost-efficiency but lacks the realism of real-world scenarios. It‘s important to note that as the fidelity of your simulation environment increases, the closer your HIL testing approaches reality.

 

​The Role of Valeo DVS

Valeo DVS plays a crucial role in developing surround view systems for vehicles, utilizing automotive cameras with fisheye lenses, ultrasonic sensors, and ECUs. These systems are part of the AP and driver assistance functions. Valeo’s Test Tools and Infrastructure team is responsible for delivering validation tools across the product development lifecycle, from R&D design to in-vehicle recording, HIL testing, and end-of-line (EOL) testing in production.

 

Evolution of HIL Architectures in ADAS/AD Validation

​The dynamic landscape in this area has driven the continuous evolution of HIL architectures. These systems have adapted to meet the evolving needs of the industry, ensuring that they remain at the forefront of new technological advancements and the ever-expanding requirements.

 

​Currently, the Valeo DVS team uses three different HIL architectures collaboratively developed with NI, each contributing unique testing capabilities.

 

​Multisystem eXtension Interface (MXI)-Based HIL

​This first generation of the HIL system developed by the Valeo DVS team uses an in-house simulation engine called Vosstrex, which is tailored to Valeo’s sensor set. The system consists of a set of models of a fisheye camera and ultrasonic sensors, feeding the synthetic data from the Windows-based simulation PC to the NI PXI system and the ECU.

 

​Specifically on the camera sensor, they render the synthetic data from the simulation engine; the data passes via an interprocess communication to a LabVIEW application to the NI PXI system by using MXI Express. In the PXI system, the FlexRIO FPGAs act as the interface between the software and hardware, emulating authentic camera signals and low-level data that are then supplied to the ECU.

 

Loop MXI-Based HIL Architecture Diagram

Figure 2: Closed-Loop MXI-Based HIL Architecture Diagram

 

 

​The architecture effectively serves their primary use case, involving low-speed maneuvers like parking, making it suitable for their specific needs. Furthermore, their Vosstrex simulation, while providing sufficient visual fidelity, offers a solid foundation for further enhancements.

 

​However, this architecture does face certain challenges. The primary one is the throughput limitations of the MXI interface, restricting data transfer rates. Additionally, the absence of time synchronization among the three key components—cameras, ultrasonic data, and vehicle metrics—poses another limitation. Despite these challenges, the system remains functional for their intended low-speed applications and the advancements in third-party simulation engines offer opportunities for even more realistic simulations in the future.

 

​Currently Valeo has around 50 HIL testers supporting nine Valeo sites worldwide, providing testing for more than 12 OEM projects. This HIL system helped to establish a system validation framework at an early stage of the project and provided full ownership of the source code to Valeo. Thanks to their capability to develop in LabVIEW, they can continue to make improvements to the entire system, including the FPGA implementation and simulation engine, as the projects continue to evolve.

 

HIL Farm at Valeo Site

 

Figure 3: HIL Farm at Valeo Site

 

 

​HDMI-Based HIL

​The need to evolve the MXI-based HIL architecture system was triggered by a requirement from a premium European OEM. Part of the requirements were to simulate 12 high-megapixel cameras, which meant quadruple the bandwidth of the previous system, and utilize two different simulation engines operating on Linux. By collaborating with NI, Valeo architected a solution that met these criteria.

 

Twelve-Camera Simulation Architecture

​Figure 4: Twelve-Camera Simulation Architecture

 

 

The configuration in Figure 4 employs four PCs and 12 graphics cards, with each GPU dedicated to simulating an individual camera. A Linux-based PC executes the simulation, running the camera sensor model for each of those 12 cameras. The physical GPU outputs are connected to the PXI FPGAs using HDMI connections, involving several conversions in this transmission path. Specifically, it includes an initial conversion from HDMI to Serial Digital Interface (SDI), followed by a subsequent conversion from SDI to MIPI CSI. An additional FPGA is introduced into the workflow to facilitate this conversion process. After these conversions are completed, the data can be fed into the automotive video interface for FPD-Link III (PXIe-1486) and GMSL2 (PXIe-1487), with the FPGAs serving as the crucial software-to-hardware interfaces responsible for emulating the sensor signals that act as inputs to the ECU.

 

HDMI-Based Camera Sensor Simulation

 

Figure 5: HDMI-Based Camera Sensor Simulation

 

 

In terms of bandwidth, the system operates at a rate of 4.5 gigabytes per second for injecting video data into the ECU. One notable advantage of this setup is its simulation agnosticism. While in this case the Linux-based simulation engine is being used, the same data path could support data from other simulation providers. The additional FPGA required for the HDMI->SDI conversion does add cost, but it also adds the capability for further processing of the image data in this new data path. 

 

However, this configuration comes with certain limitations. Firstly, the HDMI interface presents challenges, requiring a rather complex conversion toolchain to transition from HDMI to SDI and then to CSI. Ultimately, it shares a similar limitation with the previous setup where there is no synchronization between the camera data and ultrasonics or additional vehicle bus simulation. Most importantly, this HIL system cannot be effectively employed as an open-loop replay HIL, rendering it unsuitable for replaying pre-captured data using the GPUs.

 

Video Injection Pipeline Architecture

Figure 6: Video Injection Pipeline Architecture

 

RDMA-Based HIL

The latest generation offered by NI is referred to as the RDMA HIL system using remote direct memory access over converged Ethernet (RoCE). This system is built on RDMA, an interface employed for seamless data exchange between the host PC and NI PXI. RDMA establishes an Ethernet-based connection that facilitates video data transfer with low latency, high bandwidth, and eliminates the need for memory copies by enabling a direct link between computer memory and the PXI real-time controller memory. From a high-level architectural perspective, the data flow begins with the simulation PC, transmitted over RDMA to the PXI real-time controller located within a PXI chassis that houses the necessary FPGAs responsible for feeding the ECU. This system can operate as open-loop and closed-loop configuration, allowing the replaying of precaptured data as well as feedback to be integrated back into the real-time controller.

 

RDMA Open-Loop Replay HIL

​Figure 7: RDMA Open-Loop Replay HIL

 

This architecture delivers the highest throughput performance observed so far, with a single RDMA module capable of providing up to 6.25 gigabytes per second of data transfer. Another significant advantage lies in the unified architecture for both open-loop and closed-loop HIL setups, where the distinction primarily revolves around data source selection—whether it originates from storage files or simulation, allowing reusability. However, the main advantage lies in the introduction of precise synchronization mechanisms, aligning video data seamlessly with vehicle bus signals. This synchronization extends beyond cameras to cover various sensors, delivering a comprehensive and synchronized dataset. Valeo, for instance, is actively evaluating the incorporation of these HIL systems, potentially replacing existing MXI HILs as part of their future strategy.

However, there are some factors to consider when using RDMA. Your simulation engine must be compatible with RDMA, which requires calling an RDMA client library DLL from the simulation engine. In cases where integrating an external DLL with your simulation engine is not feasible, an alternative is to employ HDMI-to-RDMA converters. This approach essentially creates a hybrid setup that combines elements from the previous configuration, but with the caveat of introducing additional latency and jitter, due to the extra conversion step (HDMI-to-RDMA).

 

A Comprehensive Solution: NI AD Software Development Kit (SDK)

The NI RDMA-based HIL system is designed to be simulator-agnostic, serving all customer requirements. This versatility is made possible through the utilization of the NI AD software development kit (SDK). The SDK facilitates rapid integration between sensors' bus emulation and simulation software. The provided AD SDK is a set of plugins that offer a consistent interface, simplifying integration across the simulator provider and the AD HIL system. Leveraging LabVIEW and gRPC support, the SDK provides a simulation API, offering a well-defined interface for seamless integration. This approach empowers third-party simulator companies to work within their familiar tools, enabling them to create straightforward test points that support debugging and CI/CD processes. This, in turn, contributes to the reduction of the complexity of system communication between the simulation software and the ADAS HIL system, giving the power to the end user to choose which simulator provider to utilize.

 

NI and Valeo Collaboration

The partnership between NI and Valeo consists of R&D collaboration, early access to NI prototypes, engineering services, and turnkey HIL system development. This collaboration has allowed Valeo to stay at the forefront of ADAS validation.

 

The NI PXI platform enabled the Valeo team to achieve standardized validation systems worldwide and reuse testing components by taking advantage of the modularity, accurate time synchronization, and support for essential automotive interfaces that the platform provides.

 

Conclusion

The evolution of HIL systems at Valeo, in collaboration with NI, showcases the importance of adapting testing methodologies to meet the challenges introduced by increasingly complex ADAS/AD systems. The RDMA-based HIL system represents a significant step forward, offering high throughput and synchronization capabilities. Valeo remains committed to leveraging the NI systems to address the evolving needs of ADAS/AD validation, ensuring the satisfaction of their customers in the ever-changing automotive industry.

 

The registered trademark Linux® is used pursuant to a sublicense from LMI, the exclusive licensee of Linus Torvalds, owner of the mark on a worldwide basis.

 

 

An NI Partner is a business entity independent from NI and has no agency or joint-venture relationship and does not form part of any business associations with NI.