In recent years, the research and application of Advanced Driver Assistance Systems (ADAS) technology have rapidly developed in various related fields, indicating that automobiles are quickly entering a new ADAS world. The application scenarios of ADAS require its related functions to undergo sufficiently reliable testing to ensure that autonomous vehicles can operate safely and without risk. Therefore, testing for ADAS systems has become a highly concerning issue.
The technology of Autonomous Driving (AD) presents significant challenges for the development of ECUs in the automotive industry. The increasing integration of AD technology in automotive research and development has greatly increased the complexity of the entire vehicle electronic system. Firstly, the complexity of hardware: modern vehicles utilize a large number of high-performance sensors such as cameras, millimeter-wave radars, and LiDARs to accurately detect the vehicle’s environment under various complex external conditions, meaning the more sensors, the better. Secondly, the complexity of software: the data provided by sensors needs to be fused and processed in real-time by high-performance processors and graphics processors within the AD ECU. AD ECUs typically use operating systems that comply with POSIX specifications, such as QNX, PikeOS, or INTEGRITY OS, which can support IT industry software environments that were previously unused in automotive ECU development. For example, TensorFlow and ROS (Robot Operating System) can be used in the development of autonomous driving functions for artificial intelligence analysis and machine learning.
The complex hardware and software environments of ECUs in autonomous driving systems ultimately reflect in the testing phase of the system release process; even just the software itself and its related autonomous driving functions require far more than simple testing and validation programs.
Verification Methods for Autonomous Driving Functions
It is estimated that verifying autonomous driving functions requires millions or even billions of kilometers of driving tests on actual roads. Considering the potential dangers to pedestrians on the road and the reproducibility of tests, the workload for real-world tests using actual vehicles is enormous and inefficient. Therefore, there is currently a preference for conducting high-efficiency autonomous driving function testing in simulated laboratory environments. It should be noted that the simulation models used in laboratories can only provide approximations of real physical environments, and the verification of autonomous driving functions must adequately combine virtual platform testing with real-world road testing.
The core of the ECU in the ADAS system is the control algorithms or software part. Therefore, some ADAS system simulation tests may adopt virtual testing focused solely on software logic, known as Software-in-the-Loop (SiL) testing. The SiL testing environment needs to operate independently of ECU hardware on one hand; on the other hand, it needs to simulate the testing environment for the software, including target vehicles, vehicle behavior, external environments, and relevant sensor actuators. Additionally, it needs to cover extra testing requirements such as “automated execution.” The overall testing work can be subdivided into multiple individual sub-tasks, each of which currently has professional tools that can cover implementation. During the testing process, standardized interfaces can be used to integrate various professional tools to build a complete testing environment, allowing users to not need to understand the technical details of communication between tools.
Figure 1 shows a typical configuration of the ADAS testing solution based on the Vector toolchain, where the system under test (SUT) is realized through a virtual environment simulation. PREEvision supports requirement management and test data management, responsible for managing testing specifications and results within the toolchain; vTESTstudio is an automated testing script integrated development environment used to develop test cases and generate executable test units; CANoe supports bus analysis, simulation, and testing, serving as the testing execution platform in the system, integrating data from various tools and controlling test execution; DYNA4 is a professional virtual road testing and simulation solution tool responsible for simulating the driving environment in the toolchain. Testing can be manually controlled or executed automatically, and once testing is completed, the testing toolchain will automatically create test reports and store test results in the test data management system. This solution ensures end-to-end traceability from testing requirements to test results.
Taking the emergency braking function testing as an example to illustrate the setup and configuration of the SiL testing system. As shown in Figure 2, the SUT is an AUTOSAR Adaptive ECU based on Linux, which needs to communicate with sensors and actuators via SOME/IP. The testing system includes a sensor gateway and an actuator gateway: the sensor gateway receives data from speed and distance sensors and communicates with the emergency braking ECU via SOME/IP; the control signals sent by the ECU are transmitted to the brake and accelerator pedals through the actuator gateway. The entire testing system uses DYNA4 to simulate the driving environment and sensors, while CANoe simulation nodes simulate the sensor gateway and actuator gateway to achieve communication with the SUT and relevant testing.
Lane Departure Warning HiL Testing System
In addition to fully simulated SiL testing, the ECU software also needs to undergo integration testing with sensors and real hardware. At this point, a Hardware-in-the-Loop (HiL) testing solution can be adopted. HiL testing requires the integration of real ECUs and sensors in a simulated vehicle environment. ADAS systems require real-time data interaction between the ECU and sensors, necessitating the establishment of a high-performance real-time simulation system, such as using Vector’s VT System and VN series bus interface cards to establish electrical connections between the ECU, sensors, and the testing host computer.
Below, we introduce an efficient and scalable HiL testing system built using Vector tools, which is also applicable for testing other ADAS ECUs. The Lane Departure Warning (LDW) system aims to warn the driver visually, audibly, or through vibration when the vehicle deviates from its current lane, mainly consisting of an LDW ECU and a camera, usually installed on the side of the vehicle or in the rearview mirror.
The testing system mainly includes five components: CANoe, DYNA4, LDW ECU, Force Feedback Wheel, and bus interface cards. These components communicate with each other to achieve testing functionalities.
CANoe serves as the execution platform for testing, providing a simulated environment and controlling the entire testing operation.
DYNA4 software simulates the autonomous driving environment, responsible for building virtual driving environments, including vehicle models, driver models, traffic environment models, and sensor models, among others. The parameters of each model can be further refined through the software. During the testing process, the display synchronously shows specific animation details, such as various landscape details or other road users in the surrounding road environment.
The LDW ECU (including the camera sensor) is placed in front of the DYNA4 display, allowing it to capture the animated scenes simulated in DYNA4 as if in a real vehicle. The LDW ECU software receives and processes image data and issues warnings via the CAN bus when the vehicle deviates from the lane.
The Force Feedback Wheel receives control information to display warning messages in the form of vibration feedback.
The bus interface card achieves the physical connection between the software running platform PC and the LDW ECU and Force Feedback Wheel. In the example, the VN1610 is used to build a CAN bus communication network, ensuring the real-time transmission of ECU control signals. Vector provides various bus interface cards to support communication of different bus types and high-performance modular IO boards to achieve synchronized processing of IO signals. For tests with high real-time requirements, time-critical tasks can be addressed using VN8900/VT6000 real-time processing modules or CANoe dedicated industrial computers that support Extended Real Time (ERT) technology for high-performance simulation testing.
The entire testing work can be achieved with simple software configuration: DYNA4 is responsible for building the vehicle and environment models in the testing system; subsequently, the models are compiled into DLL files seamlessly imported into CANoe as a simulation node; CANoe simulates the residual bus and exchanges communication data with the ECU, controlling the execution of tests; testing scripts can be written using vTESTstudio. The testing process can be set for manual/semi-automatic control or set for automatic execution. Detailed testing steps and data flows are monitored in real-time within CANoe, and customizable test reports are automatically generated at the end.
Outlook
Leveraging its advantages in development, management, simulation, and testing toolchains, Vector provides cost-effective ADAS system testing solutions. The solution is based on the powerful CANoe and professional vehicle simulation software DYNA4: CANoe supports various bus communications and residual bus simulations, and its rich testing API interfaces can quickly realize automated testing; DYNA4 software comes with a rich library of driver assistance models, allowing users to efficiently and quickly set up using ready-made components without complex custom operations.
Additionally, ADAS/AD functions can be distributed across multiple ECUs. From the perspective of testing engineers, software functions appear more critical than ECUs that act as closed black boxes. A Service-Oriented Architecture (SOA) provides a communication foundation for various functional components, allowing these components to communicate independently of hardware or operating systems. The future of ADAS systems will pose more challenges to testing tools.
Click “Read the original text” for more content!