Test method, device, storage medium and equipment of autonomous driving domain controller
Patent Information
- Application Number
- CN202510463319.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-04-14
- Publication Date
- 2026-10-20
AI Technical Summary
[0039]在所述故障预测模型包括所述故障分类模型的情况下，所述故障预测结果包括故障预测类型；
Smart Images
Figure HDA0005357786690000011 
Figure HDA0005357786690000012 
Figure HDA0005357786690000021
Abstract
Description
Technical Field
[0001] This application relates to the field of vehicle testing technology, and more specifically, to a testing method, apparatus, storage medium, and device for an autonomous driving domain controller. Background Technology
[0002] The Autonomous Driving Control Unit (ADCU) is the core decision-making unit of an autonomous driving system. It is responsible for fusing data from multiple sensors (such as cameras, LiDAR, and millimeter-wave radar) to perform real-time environmental perception, path planning, and control command generation. Its functional safety and reliability directly affect the safety of autonomous vehicles. Testing the ADCU is crucial because its algorithm logic, hardware performance, and fault tolerance under abnormal scenarios must be rigorously verified to meet functional safety standards and ensure the safety of occupants and other road users. However, current verification of the ADCU mainly relies on real-vehicle testing, which is limited by high testing costs and poor fault controllability. Summary of the Invention
[0003] This application provides a testing method, apparatus, storage medium, and device for an autonomous driving domain controller, which can improve the controllability of fault injection while reducing testing costs, thereby improving the reliability of autonomous driving domain controller testing.
[0004] The specific technical solution is as follows:
[0005] In a first aspect, embodiments of this application provide a testing method for an autonomous driving domain controller, the method comprising:
[0006] Static fault data is injected into the collected raw vehicle driving data, the vehicle driving data with injected static fault data is replayed, and dynamic fault data is injected during the data replay process.
[0007] When the data type to be tested includes the first data type, the real vehicle driving data of the first data type is transmitted to the autonomous driving domain controller ADCU for playback, wherein the first data type is a data type that only needs to be transmitted unidirectionally to the ADCU;
[0008] When the data type to be tested includes the second data type, the real vehicle driving data of the second data type is transmitted to the ADCU as the initial data, and the virtual vehicle interacts with the ADCU to realize the playback of the real vehicle driving data of the second data type. The second data type is a data type that requires bidirectional communication with the ADCU.
[0009] Record and replay the process, and verify the recorded ADCU results.
[0010] As can be seen from the above scheme, the autonomous driving domain controller testing method provided in this application only requires, after collecting the original real vehicle driving data, to directly inject the static fault data to be verified into the original real vehicle driving data in an external electronic device independent of the vehicle. Then, the data is played back, and dynamic fault data is injected during the playback process. For data transmitted in one direction, it can be directly transmitted to the ADCU to achieve data playback. For data that requires bidirectional interactive transmission, it can be played back by simulating communication between a virtual vehicle and the ADCU. Finally, the playback process is recorded for verification. This application embodiment not only eliminates the need for real vehicle testing, reducing testing costs, but also allows for the injection of any required static or dynamic faults according to testing needs, improving the controllability of fault generation and thus improving the reliability of autonomous driving domain controller testing.
[0011] In one possible implementation, the method further includes, prior to interacting with the ADCU via a virtual vehicle:
[0012] Create an initial virtual vehicle, and based on the testing requirements, create at least one virtual actuator within the initial virtual vehicle to generate the final virtual vehicle.
[0013] As can be seen from the above scheme, the embodiments of this application construct virtual vehicles in a modular manner, which can quickly configure specific actuators according to different test objectives (such as braking system failure, steering delay, etc.) without having to repeatedly build a complete vehicle model, greatly improving the adaptation efficiency of test scenarios.
[0014] In one possible implementation, the method for collecting the original real-vehicle driving data includes:
[0015] After inserting a CAN card into the actual vehicle and connecting the electronic device to the actual vehicle via the high-speed serial computer expansion bus standard PCIE, the data is converted into rostopic for recording, thereby obtaining the CAN data in the original actual vehicle driving data;
[0016] And / or, based on the data relay function of the switch of the ADCU in the actual vehicle, receive other actual vehicle driving data other than the CAN data via Ethernet.
[0017] In one possible implementation, during data playback, dynamic fault data is injected, including:
[0018] During the data playback process, the target data information of the ADCU is collected in real time and input into the pre-trained fault prediction model to obtain the fault prediction result. The target data information includes input and output data and / or system status information. The fault prediction model is trained based on historical real vehicle driving data including fault data.
[0019] Based on the fault prediction results and testing requirements, dynamic fault data is injected into the actual vehicle driving data into which static fault data is injected.
[0020] As can be seen from the above scheme, the embodiments of this application can improve the rationality and efficiency of dynamic fault injection by using a pre-trained fault prediction model to predict the target data information generated by ADCU during the data playback process.
[0021] In one possible implementation, the fault prediction model includes a fault classification model and / or a fault intensity prediction model;
[0022] When the fault prediction model includes the fault classification model, the fault prediction result includes the fault prediction type;
[0023] When the fault prediction model includes the fault intensity prediction model, the fault prediction result includes the fault prediction intensity.
[0024] As can be seen from the above scheme, the embodiments of this application predict faults by using fault classification models and / or fault intensity prediction models, which can improve the diversity of fault injection.
[0025] Secondly, embodiments of this application provide a testing apparatus for an autonomous driving domain controller, the apparatus comprising:
[0026] The data acquisition unit is used to collect raw real-vehicle driving data.
[0027] The fault injection unit is used to inject static fault data into the original real vehicle driving data, replay the real vehicle driving data with injected static fault data, and inject dynamic fault data during the data replay process.
[0028] The data playback unit is used to transmit real-vehicle driving data of the first data type to the Advanced Driver Controller Unit (ADCU) for playback when the data type to be tested includes a first data type, wherein the first data type is a data type that only needs to be transmitted unidirectionally to the ADCU; and to transmit real-vehicle driving data of the second data type as initial data to the ADCU when the data type to be tested includes a second data type, and to interact with the ADCU through a virtual vehicle to realize the playback of real-vehicle driving data of the second data type, wherein the second data type is a data type that requires bidirectional communication with the ADCU.
[0029] The recording unit is used to record the playback process;
[0030] The verification unit is used to verify the recorded ADCU results.
[0031] In one possible implementation, the device further includes:
[0032] A creation unit is used to create an initial virtual vehicle before interacting with the ADCU via the virtual vehicle, and to create at least one virtual actuator in the initial virtual vehicle according to test requirements, thereby generating the final virtual vehicle.
[0033] In one possible implementation, the method for acquiring the original vehicle driving data includes: inserting a CAN card into the vehicle, connecting the electronic device to the vehicle via the high-speed serial computer expansion bus standard PCIE, converting the data into rostopic for recording, and obtaining the CAN data in the original vehicle driving data; and / or, based on the data relay function of the switch of the ADCU in the vehicle, receiving other vehicle driving data besides the CAN data via Ethernet.
[0034] In one possible implementation, the fault injection unit includes:
[0035] The acquisition module is used to acquire target data information of the ADCU in real time during data playback, wherein the target data information includes input and output data and / or system status information;
[0036] The prediction module is used to input the target data information into a pre-trained fault prediction model to obtain a fault prediction result, wherein the fault prediction model is trained based on historical real vehicle driving data including fault data.
[0037] The fault injection module is used to inject dynamic fault data into the real vehicle driving data into which static fault data is injected, based on the fault prediction results and test requirements.
[0038] In one possible implementation, the fault prediction model includes a fault classification model and / or a fault intensity prediction model;
[0039] When the fault prediction model includes the fault classification model, the fault prediction result includes the fault prediction type;
[0040] When the fault prediction model includes the fault intensity prediction model, the fault prediction result includes the fault prediction intensity.
[0041] As can be seen from the above scheme, the autonomous driving domain controller testing device provided in this application only needs to directly inject the static fault data to be verified into the original real vehicle driving data in an external electronic device independent of the vehicle after collecting the original real vehicle driving data. Then, the data is played back, and dynamic fault data is injected during the playback process. For data transmitted in one direction, it can be directly transmitted to the ADCU to realize data playback. For data that requires bidirectional interactive transmission, it can realize data playback by simulating communication between the virtual vehicle and the ADCU. Finally, the playback process is recorded for verification. This application embodiment not only eliminates the need for real vehicle testing, reducing testing costs, but also allows for the injection of any required static or dynamic faults according to testing needs, improving the controllability of fault generation and thus improving the reliability of autonomous driving domain controller testing.
[0042] Thirdly, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon that, when executed by a processor, implements the method as described in any possible implementation of the first aspect.
[0043] Fourthly, embodiments of this application provide an electronic device, the electronic device comprising:
[0044] One or more processors;
[0045] The processor is coupled to a storage device for storing one or more programs;
[0046] When the one or more programs are executed by the one or more processors, the electronic device performs the method as described in any possible implementation of the first aspect.
[0047] Fifthly, embodiments of this application provide a computer program product containing instructions that, when executed on a computer or processor, cause the computer or processor to perform the method described in any possible implementation of the first aspect. Attached Figure Description
[0048] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are merely some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without any creative effort.
[0049] Figure 1 A flowchart illustrating a testing method for an autonomous driving domain controller provided in an embodiment of this application;
[0050] Figure 2 A block diagram illustrating the composition of a testing apparatus for an autonomous driving domain controller provided in this application embodiment;
[0051] Figure 3 This is a schematic diagram of the structure of an electronic device or computer device provided in an embodiment of this application. Detailed Implementation
[0052] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.
[0053] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. The terms "comprising" and "having," and any variations thereof, in the embodiments and drawings of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices.
[0054] This application provides a testing method for an autonomous driving domain controller, such as... Figure 1 As shown, this method can be applied to electronic devices or computer equipment, such as industrial computers. The method mainly includes:
[0055] S110: Inject static fault data into the collected raw vehicle driving data, replay the vehicle driving data with injected static fault data, and inject dynamic fault data during the data replay process.
[0056] The acquisition of raw vehicle driving data includes: inserting a CAN (Controller Area Network) card into the vehicle, connecting electronic devices to the vehicle via PCIE (High-Speed Serial Computer Expansion Bus standard), converting the data into rostopic for recording, and obtaining CAN data from the raw vehicle driving data; and / or, receiving other vehicle driving data via Ethernet based on the data relay function of the switch of the ADCU (Autonomous Driving Control Unit) in the vehicle.
[0057] Rostopic is a command-line tool in ROS used for managing and debugging topics, with its core concepts revolving around ROS's communication mechanisms. ROS (Robot Operating System) is an open-source meta-operating system designed specifically for robot software development. Its core goal is to simplify the development process of robot systems, improve code reusability, and enhance cross-platform collaboration efficiency.
[0058] Other real-vehicle driving data includes data other than CAN data, specifically including LiDAR point cloud data, Radar point cloud data, HMI (Human Machine Interface) interaction data, camera encoded data, etc. This embodiment of the application can add data relay functionality by configuring the switch in the ADCU, forwarding the required input data such as LiDAR point cloud data, Radar point cloud data, HMI interaction data, and camera encoded data to the electronic device, enabling the data recording device to complete data recording functions in both the actual vehicle and the test bench.
[0059] The difference between static and dynamic fault data lies in whether the fault data is generated offline and statically, or generated during operation. Static fault data is generated offline and statically, while dynamic fault data is generated during operation. The latter is primarily because the fault parameters are dynamic and need to be calculated in real-time based on the system status.
[0060] Data playback: Recorded vehicle driving data (such as sensor signals and control commands) are re-inputted into the system under test (such as ECU and autonomous driving algorithm) to simulate the real operating environment for offline or laboratory testing.
[0061] During the playback of real vehicle driving data containing injected static fault data, it is possible to observe whether the system recognizes static faults (such as dashboard warnings and log records) and whether the control strategy is adjusted (such as enabling backup sensors or switching to degraded mode).
[0062] When injecting dynamic fault data, it can be injected based on preset injection rules or based on a fault prediction model. The process of injecting dynamic fault data based on a fault prediction model includes: during data playback, real-time acquisition of target data information of the ADCU, inputting the target data information into a pre-trained fault prediction model to obtain fault prediction results; and injecting dynamic fault data into the real vehicle driving data into which static fault data is injected, based on the fault prediction results and test requirements.
[0063] The target data information includes input and output data and / or system status information. Input data includes: sensor signals received by the ADCU (such as vehicle speed, steering angle) and control commands (such as throttle opening); output data includes: actuator commands issued by the ADCU (such as braking pressure, motor torque); system status information includes: internal operating parameters (such as algorithm confidence, controller load rate, communication latency).
[0064] The fault prediction model is trained using historical real-vehicle driving data, which includes fault data. This historical driving data contains both normal operating conditions and manually labeled fault events (such as fault timestamps, types, and intensities). The fault prediction model includes a fault classification model and / or a fault intensity prediction model. When the fault prediction model includes a fault classification model, the fault prediction result includes the fault prediction type; when the fault prediction model includes a fault intensity prediction model, the fault prediction result includes the fault prediction intensity.
[0065] Among them, fault classification models (such as LSTM / Transformer-based time series classification) are used to identify whether the current state matches a known fault mode (such as sensor failure or communication interruption). Fault severity prediction models (such as regression models / survival analysis) are used to predict the potential severity of the fault (such as signal offset or fault duration).
[0066] In addition, testing requirements include: pre-setting test objectives, such as verifying the recovery capability of specific fault combinations. Based on the fault prediction results and testing requirements, the specific implementation process of injecting dynamic fault data into the real vehicle driving data containing static fault data can include: if the fault classification model detects a "Type A fault", then inject the associated dynamic fault (such as the intermittent interference of Type B that often accompanies Type A fault); if the fault intensity prediction model predicts that "the fault intensity is about to exceed the threshold", then inject a dynamic fault simulating that intensity in advance to test the system limits.
[0067] This application's embodiments improve the rationality and efficiency of dynamic fault injection by using a pre-trained fault prediction model to predict faults in the target data information generated by the ADCU during data playback. Predicting faults using fault classification models and / or fault intensity prediction models can enhance the diversity of fault injection.
[0068] S120: If the data type to be tested includes the first data type, transmit the real vehicle driving data of the first data type to the autonomous driving domain controller ADCU for playback.
[0069] The first data type is one that only needs to be transmitted unidirectionally to the ADCU, without requiring the ADCU to provide feedback or control over the data source. This type of data typically includes environmental perception data and vehicle status information, with the ADCU acting solely as a receiver for data processing and decision-making. Environmental perception data includes camera video streams, LiDAR point clouds, millimeter-wave radar target lists, and static road information from high-precision maps (such as lane lines and traffic signs). Vehicle status information includes acceleration and angular velocity signals from the IMU (Inertial Measurement Unit), wheel speed sensors, and steering wheel angle sensor signals.
[0070] This application embodiment provides the ADCU with an input environment consistent with actual driving by replaying historically collected first-type data. It reproduces specific scenarios (such as extreme weather and complex traffic flow) in a laboratory environment, avoiding the high costs and uncontrollable risks of real-vehicle testing.
[0071] S130: When the data type to be tested includes a second data type, the real vehicle driving data of the second data type is transmitted to the ADCU as the initial data, and the virtual vehicle interacts with the ADCU to realize the playback of the real vehicle driving data of the second data type.
[0072] The second data type is the type that requires bidirectional communication with the ADCU. This type of data typically involves control commands and feedback loops. The ADCU not only receives inputs but also generates commands based on the system status and issues execution results, forming a dynamic interaction. This mainly includes control commands and execution feedback, dynamic environment interaction, resource management, and status synchronization.
[0073] For example, in control commands and execution feedback, when the control command includes an accelerator / brake command sent by the ADCU, the execution feedback includes the actual torque and braking pressure returned by the actuator; in dynamic environment interaction, when the virtual vehicle simulates an external vehicle to send an intelligent driving request command, the ADCU responds.
[0074] In this embodiment of the application, the method for creating a virtual vehicle may include: creating an initial virtual vehicle, and creating at least one virtual actuator in the initial virtual vehicle according to testing requirements, thereby generating a final virtual vehicle.
[0075] In the specific implementation process, a virtual vehicle node can be created first based on the project, vehicle model, handshake protocol, etc., and then multiple virtual executor nodes can be created in the vehicle node according to the configuration. Each executor uses a state machine to simulate and executes in an independent thread. It triggers state transitions based on the ADCU signal and provides state feedback.
[0076] The functions of the completed virtual vehicle include: (1) simulating the handshake behavior of various actuators and intelligent driving domain controllers; (2) simulating the communication behavior of HMI and ADCU; and (3) simulating the calibration status and data of sensors.
[0077] For the initialization process of some modules in the ADCU (including the MCU (Microcontroller Unit), etc.), which requires handshake operations with the actuator and has timing requirements, simple data playback may lead to instability. An intermediate module is needed to ensure the reliability of the handshake. For data that does not include the intelligent driving initialization process, it is necessary to implement a simulation of the intelligent driving initialization process. The logic for simulating calibration updates when vehicle-side sensors are replaced also needs to be implemented.
[0078] Signals requiring handshake interaction are routed through the Virtual Vehicle, while other unidirectional signals are directly output through the player (playback module).
[0079] Based on the analysis of the interaction protocol, the current handshake logic includes: (1) instantaneous condition: the virtual actuator only needs the latest data to determine whether to perform a state machine transition; (2) timing condition: the state machine transition condition depends not only on the latest data, but also on the timing changes of the signal over a period of time.
[0080] This application embodiment constructs virtual vehicles in a modular fashion, which can quickly configure specific actuators according to different test objectives (such as braking system failure, steering delay, etc.) without having to repeatedly build a complete vehicle model, greatly improving the adaptability efficiency of test scenarios.
[0081] It should be added that during data playback, when transmitting data to the ADCU, data generated by different sensors may require different transmission modules. For example, image data needs to be transmitted through a decoding module (such as an FPGA (Field Programmable Gate Array) + serializer), vehicle-level CAN signals need to be transmitted through the CAN bus, and other data need to be transmitted through a network module, etc.
[0082] S140: Record the playback process and verify the recorded ADCU results.
[0083] The verification content includes: functional correctness verification, data integrity verification, anomaly handling capability verification, and performance indicator verification. Functional correctness verification involves comparing the recorded ADCU output with the expected output. For example, after injecting a "LiDAR signal loss" fault, the system should switch to Radar-driven perception mode and trigger a degradation strategy. If the recorded ADCU results adopt this approach, the function is correct. Functional correctness verification may also include checking whether the response delay is within the tolerance range (e.g., whether the braking command takes effect within 100ms). If it is within the tolerance range, the response function is correct. Data integrity verification verifies whether the recorded ADCU results are complete and free from loss or tampering (e.g., hash value comparison). Anomaly handling capability verification checks whether the system properly triggers fault diagnosis mechanisms (e.g., generating DTC (Diagnostic Trouble Code) codes and reporting fault status), and confirms whether safety mechanisms are effective (e.g., emergency stop, driver takeover prompts). Performance metrics verification is used to check whether resource utilization exceeds the standard (e.g., CPU (Central Processing Unit) load exceeding 80% may cause real-time risks), and whether communication bandwidth meets the requirements (e.g., whether CAN bus utilization is reasonable), etc.
[0084] The testing method for autonomous driving domain controllers provided in this application only requires, after collecting the original real-vehicle driving data, to directly inject the static fault data to be verified into the original real-vehicle driving data using an external electronic device independent of the vehicle. Then, the data is played back, and dynamic fault data is injected during the playback process. For unidirectional data transmission, it can be directly transmitted to the ADCU for data playback. For data requiring bidirectional interactive transmission, it can be played back through virtual vehicle simulation of communication with the ADCU. Finally, the playback process is recorded for verification. This application not only eliminates the reliance on real vehicles for testing, reducing testing costs, but also allows for the injection of any required static or dynamic faults according to testing needs, improving the controllability of fault generation and thus enhancing the reliability of autonomous driving domain controller testing.
[0085] Based on the above method embodiments, another embodiment of this application provides a testing device for an autonomous driving domain controller, such as... Figure 2 As shown, the device includes:
[0086] The fault injection unit 210 is used to inject static fault data into the collected original real vehicle driving data, replay the real vehicle driving data with injected static fault data, and inject dynamic fault data during the data replay process.
[0087] The data playback unit 220 is used to transmit the real vehicle driving data of the first data type to the Advanced Driver Controller Unit (ADCU) for playback when the data type to be tested includes a first data type, wherein the first data type is a data type that only needs to be transmitted unidirectionally to the ADCU; and to transmit the real vehicle driving data of the second data type as initial data to the ADCU when the data type to be tested includes a second data type, and to interact with the ADCU through a virtual vehicle to realize the playback of the real vehicle driving data of the second data type, wherein the second data type is a data type that requires bidirectional communication with the ADCU.
[0088] Recording unit 230 is used to record the playback process;
[0089] The verification unit 240 is used to verify the recorded ADCU results.
[0090] In one possible implementation, the device further includes:
[0091] A creation unit is used to create an initial virtual vehicle before interacting with the ADCU via the virtual vehicle, and to create at least one virtual actuator in the initial virtual vehicle according to test requirements, thereby generating the final virtual vehicle.
[0092] In one possible implementation, the method for acquiring the original vehicle driving data includes: inserting a CAN card into the vehicle, connecting the electronic device to the vehicle via the high-speed serial computer expansion bus standard PCIE, converting the data into rostopic for recording, and obtaining the CAN data in the original vehicle driving data; and / or, based on the data relay function of the switch of the ADCU in the vehicle, receiving other vehicle driving data besides the CAN data via Ethernet.
[0093] In one possible implementation, the fault injection unit 210 includes:
[0094] The acquisition module is used to acquire target data information of the ADCU in real time during data playback, wherein the target data information includes input and output data and / or system status information;
[0095] The prediction module is used to input the target data information into a pre-trained fault prediction model to obtain a fault prediction result, wherein the fault prediction model is trained based on historical real vehicle driving data including fault data.
[0096] The fault injection module is used to inject dynamic fault data into the real vehicle driving data into which static fault data is injected, based on the fault prediction results and test requirements.
[0097] In one possible implementation, the fault prediction model includes a fault classification model and / or a fault intensity prediction model;
[0098] When the fault prediction model includes the fault classification model, the fault prediction result includes the fault prediction type;
[0099] When the fault prediction model includes the fault intensity prediction model, the fault prediction result includes the fault prediction intensity.
[0100] The testing device for the autonomous driving domain controller provided in this application only requires, after collecting the original real-vehicle driving data, to directly inject the static fault data to be verified into the original real-vehicle driving data using an external electronic device independent of the vehicle. Then, the data is played back, and dynamic fault data is injected during the playback process. For unidirectional data transmission, it can be directly transmitted to the ADCU for data playback. For data requiring bidirectional interactive transmission, it can be played back through virtual vehicle simulation of communication with the ADCU. Finally, verification is performed by recording the playback process. This application not only eliminates the reliance on real vehicles for testing, reducing testing costs, but also allows for the injection of any required static or dynamic faults according to testing needs, improving the controllability of fault generation and thus enhancing the reliability of autonomous driving domain controller testing.
[0101] Based on the above method embodiments, another embodiment of this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method as described in any of the above embodiments.
[0102] Based on the above method embodiments, another embodiment of this application provides an electronic device or computer device, such as... Figure 3 As shown, the electronic device includes:
[0103] One or more processors 310;
[0104] The processor 310 is coupled to a storage device 320, the storage device 320 being used to store one or more programs;
[0105] When the one or more programs are executed by the one or more processors 310, the electronic device performs the method as described in any of the possible implementations above.
[0106] Based on the above embodiments, another embodiment of this application provides a computer program product, which includes instructions that, when executed on a computer or processor, cause the computer or processor to perform the method described in any of the above embodiments.
[0107] The above-described device and system embodiments correspond to the method embodiments and have the same technical effects. For detailed descriptions, please refer to the method embodiments. The device embodiments are derived from the method embodiments; detailed descriptions can be found in the method embodiments section, and will not be repeated here. Those skilled in the art will understand that the accompanying drawings are merely schematic diagrams of one embodiment, and the modules or processes shown in the drawings are not necessarily essential for implementing this application.
[0108] Those skilled in the art will understand that the modules in the apparatus of the embodiments can be distributed in the apparatus of the embodiments as described in the embodiments, or they can be located in one or more devices different from this embodiment with corresponding changes. The modules of the above embodiments can be combined into one module, or they can be further divided into multiple sub-modules.
[0109] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.
Claims
1. A testing method for an autonomous driving domain controller, characterized in that, The method includes: Static fault data is injected into the collected raw vehicle driving data, the vehicle driving data with injected static fault data is replayed, and dynamic fault data is injected during the data replay process. When the data type to be tested includes the first data type, the real vehicle driving data of the first data type is transmitted to the autonomous driving domain controller ADCU for playback, wherein the first data type is a data type that only needs to be transmitted unidirectionally to the ADCU; When the data type to be tested includes the second data type, the real vehicle driving data of the second data type is transmitted to the ADCU as the initial data, and the virtual vehicle interacts with the ADCU to realize the playback of the real vehicle driving data of the second data type. The second data type is a data type that requires bidirectional communication with the ADCU. Record and replay the process, and verify the recorded ADCU results.
2. The method according to claim 1, characterized in that, Before interacting with the ADCU via a virtual vehicle, the method further includes: Create an initial virtual vehicle, and based on the testing requirements, create at least one virtual actuator within the initial virtual vehicle to generate the final virtual vehicle.
3. The method according to claim 1, characterized in that, The method for collecting the original real vehicle driving data includes: After inserting a CAN card into the actual vehicle and connecting the electronic device to the actual vehicle via the high-speed serial computer expansion bus standard PCIE, the data is converted into rostopic for recording, thereby obtaining the CAN data in the original actual vehicle driving data; And / or, based on the data relay function of the switch of the ADCU in the actual vehicle, receive other actual vehicle driving data other than the CAN data via Ethernet.
4. The method according to any one of claims 1-3, characterized in that, During data playback, dynamic fault data is injected, including: During the data playback process, the target data information of the ADCU is collected in real time and input into the pre-trained fault prediction model to obtain the fault prediction result. The target data information includes input and output data and / or system status information. The fault prediction model is trained based on historical real vehicle driving data including fault data. Based on the fault prediction results and testing requirements, dynamic fault data is injected into the actual vehicle driving data into which static fault data is injected.
5. The method according to claim 4, characterized in that, The fault prediction model includes a fault classification model and / or a fault intensity prediction model; When the fault prediction model includes the fault classification model, the fault prediction result includes the fault prediction type; When the fault prediction model includes the fault intensity prediction model, the fault prediction result includes the fault prediction intensity.
6. A testing apparatus for an autonomous driving domain controller, characterized in that, The device includes: The fault injection unit is used to inject static fault data into the collected raw real vehicle driving data, replay the real vehicle driving data with injected static fault data, and inject dynamic fault data during the data replay process. The data playback unit is used to transmit real-vehicle driving data of the first data type to the Advanced Driver Controller Unit (ADCU) for playback when the data type to be tested includes a first data type, wherein the first data type is a data type that only needs to be transmitted unidirectionally to the ADCU; and to transmit real-vehicle driving data of the second data type as initial data to the ADCU when the data type to be tested includes a second data type, and to interact with the ADCU through a virtual vehicle to realize the playback of real-vehicle driving data of the second data type, wherein the second data type is a data type that requires bidirectional communication with the ADCU. The recording unit is used to record the playback process; The verification unit is used to verify the recorded ADCU results.
7. The apparatus according to claim 6, characterized in that, The device further includes: A creation unit is used to create an initial virtual vehicle before interacting with the ADCU via the virtual vehicle, and to create at least one virtual actuator in the initial virtual vehicle according to test requirements, thereby generating the final virtual vehicle.
8. The apparatus according to claim 6 or 7, characterized in that, The fault injection unit includes: The acquisition module is used to acquire target data information of the ADCU in real time during data playback, wherein the target data information includes input and output data and / or system status information; The prediction module is used to input the target data information into a pre-trained fault prediction model to obtain a fault prediction result, wherein the fault prediction model is trained based on historical real vehicle driving data including fault data. The fault injection module is used to inject dynamic fault data into the real vehicle driving data into which static fault data is injected, based on the fault prediction results and test requirements.
9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1-5.
10. An electronic device, characterized in that, The electronic device includes: One or more processors; The processor is coupled to a storage device for storing one or more programs; When the one or more programs are executed by the one or more processors, the electronic device performs the method as described in any one of claims 1-5.