Hardware-in-the-loop test method and device based on data infinite loop playback

Abstract

This application provides a hardware-in-the-loop (HIL) testing method and apparatus based on infinite data loop playback, comprising: acquiring a data sequence group for hardware-in-the-loop testing; determining the warm-up window, data offset time, and loop start time of the loop playback sequence to be constructed based on the data sequence group and the hardware-in-the-loop testing system, wherein the loop start time is the timestamp of the last frame data of the last data sequence in the data sequence group that has been replayed; constructing a loop playback sequence based at least on the data sequence group, the warm-up window of the loop playback sequence, the data offset time, and the loop start time; inputting the loop playback sequence into the hardware-in-the-loop testing system for data loop testing processing of the domain controller under test, and obtaining test results. This solves the problem that existing HIL testing data backfeeding schemes have limited backfeeding data volume, which cannot meet the requirements of long-term continuous testing.

Description

Technical Field

[0001] This application relates to the field of hardware-in-the-loop testing technology, and more specifically, to a hardware-in-the-loop testing method, apparatus, computer-readable storage medium, and electronic device based on infinite data loop playback. Background Technology

[0002] Advances in modern transportation have set numerous milestones in the fields of software and technology. Vehicles are a safety-critical system, and their importance will only increase as system complexity continues to grow. This is achieved through methods such as Hardware-in-the-Loop (HIL) testing.

[0003] HIL stands for Hardware-in-the-Loop, a simulation technology used to test and verify hardware or software systems. Its core principle is to connect real hardware to a simulation environment, allowing them to interact in real time to simulate system performance under real-world conditions. This technology enables engineers to test component functionality and resolve any issues discovered within a simulated environment.

[0004] For example, in the automotive industry, where system complexity is constantly increasing, HIL testing helps to safely and efficiently test various scenarios, including dangerous or rare events, before actual components are in place. Engineers ensure that vehicle performance meets safety requirements by verifying control algorithms in real time, without causing any damage to the vehicle or occupants.

[0005] The prerequisite for performing HIL testing is having backfeed data. In summary, the HIL testing technology currently used in the automotive industry includes the following essential steps:

[0006] 1. Simulated Environment: Establish a high-fidelity model of the vehicle environment. By utilizing a large amount of raw data collected from the actual vehicle, the model is equipped with the ability to simulate (or re-feed back) various sensor data from the actual vehicle and can interact with the hardware platform under test in real time.

[0007] 2. Connecting the hardware: The actual ECU (the "hardware" in HIL) is connected to the analog environment through its actual input and output (I / O) interfaces.

[0008] 3. Real-time testing: The system runs in real time, enabling the real ECU to receive sensor data input from the simulated environment and send commands to the connected hardware platform under test, just like in a real car.

[0009] 4. Verification and Refinement: Engineers can test the system to verify whether the hardware and software under test can correctly respond to analog inputs. For example, ensuring that the communication network (such as CAN, LIN, or Ethernet) is working properly and testing the system under various conditions.

[0010] However, existing HIL test data backfeeding schemes have the problem of limited backfeeding data volume, which cannot meet the needs of long-term continuous testing. Summary of the Invention

[0011] The main objective of this application is to provide a hardware-in-the-loop testing method, apparatus, computer-readable storage medium, and electronic device based on infinite data loop playback, so as to at least solve the problem that the existing HIL test data backflow scheme has a limited amount of backflow data and cannot meet the requirements of long-term continuous testing.

[0012] To achieve the above objectives, according to one aspect of this application, a hardware-in-the-loop testing method based on infinite data loop playback is provided, comprising: acquiring a data sequence group for hardware-in-the-loop testing, wherein the data sequence group includes: multiple time-aligned data sequences, each data sequence being acquired by various sensors of a vehicle; determining a warm-up window, a data offset time, and a loop start time for constructing a loop playback sequence based on the data sequence group and a hardware-in-the-loop testing system, wherein the warm-up window includes a warm-up start time and a warm-up end time, and the warm-up start time is the timestamp of the last frame data of the data sequence that first completes playback in the data sequence group, wherein... The preheating end time is the time when the hardware-in-the-loop test system completes its reset. The data offset time is the difference between the timestamp of the last frame of the last data sequence that was replayed in the data sequence group and the timestamp of the first frame of the first data sequence that was replayed. The loop start time is the timestamp of the last frame of the last data sequence that was replayed in the data sequence group. The loop playback sequence is constructed based at least on the data sequence group, the preheating window of the loop playback sequence, the data offset time, and the loop start time. The loop playback sequence is then input into the hardware-in-the-loop test system to perform data loop test processing on the domain controller under test to obtain the test results.

[0013] Optionally, the loop playback sequence is composed of multiple rounds of the data sequence group spliced ​​together. The data frame time of each data sequence in the Nth round of the data sequence group is equal to the sum of the data frame time of each data sequence in the (N-1)th round of the data sequence group and the corresponding data offset time of each data sequence, where N is greater than or equal to 2.

[0014] Optionally, during the process of inputting the loop playback sequence into the hardware-in-the-loop test system to perform data loop testing on the domain controller under test, the hardware-in-the-loop test method further includes: resetting the hardware-in-the-loop test system when the preheating start time is reached; and determining the current time point as the preheating end time and continuing to perform data loop testing on the domain controller under test when the reset of the hardware-in-the-loop test system is detected to be complete.

[0015] Optionally, constructing the loop playback sequence based at least on the data sequence group, the warm-up window of the loop playback sequence, the data offset time, and the loop start time includes: obtaining a preset data preload time when it is determined that the hardware-in-the-loop test system needs to set a data preload time; constructing the loop playback sequence based on the data preload time, the data sequence group, the warm-up window of the loop playback sequence, the data offset time, and the loop start time, wherein the data offset time is the sum of the difference between the last frame timestamp and the first frame timestamp of each data sequence in the data sequence group and the data preload time, and the loop start time is the sum of the last frame timestamp of the last data sequence in the data sequence group that has been replayed and the data preload time.

[0016] Optionally, when the hardware-in-the-loop test system is detected to have completed a reset, determining the current time point as the preheating end time includes: when the hardware-in-the-loop test system is detected to have completed a reset, determining that no alarm has occurred in the hardware-in-the-loop test system within a preset time period, and determining the current time point as the preheating end time.

[0017] Optionally, before inputting the loop replay sequence into the hardware-in-the-loop test system for data loop testing of the domain controller under test, the hardware-in-the-loop test method further includes: performing lock-free processing on the test controller in the hardware-in-the-loop test system based on the CAS lock-free strategy to supervise the hardware-in-the-loop test.

[0018] Optionally, acquiring a data sequence set for hardware-in-the-loop testing includes: acquiring sensor data collected by each sensor of the vehicle, preprocessing the sensor data of each sensor to obtain multiple data sequences, and constructing the data sequence set for hardware-in-the-loop testing based on the data sequences, wherein the preprocessing includes time synchronization processing between the sensor data and real-world time alignment processing of the sensor data.

[0019] According to another aspect of this application, a hardware-in-the-loop testing device based on infinite data loop playback is provided, comprising: an acquisition unit for acquiring a data sequence group for hardware-in-the-loop testing, wherein the data sequence group includes: multiple time-aligned data sequences, each data sequence being acquired by a vehicle's sensors; and a construction unit for determining a warm-up window, a data offset time, and a loop start time for constructing a loop playback sequence based on the data sequence group and the hardware-in-the-loop testing system, wherein the warm-up window includes a warm-up start time and a warm-up end time, the warm-up start time being the timestamp of the last frame data of the data sequence that first completes playback in the data sequence group, and the warm-up window being... The warm-up end time is the time when the hardware-in-the-loop test system completes its reset; the data offset time is the difference between the last frame timestamp of the last data sequence that was replayed in the data sequence group and the first frame timestamp of the first data sequence that was replayed; the loop start time is the timestamp of the last frame of the last data sequence that was replayed in the data sequence group; the processing unit is used to construct the loop playback sequence based at least on the data sequence group, the warm-up window of the loop playback sequence, the data offset time, and the loop start time, and input the loop playback sequence to the hardware-in-the-loop test system to perform data loop test processing on the domain controller under test to obtain test results.

[0020] According to another aspect of this application, a computer-readable storage medium is provided, the computer-readable storage medium including a stored program, wherein, when the program is executed, it controls the device where the computer-readable storage medium is located to perform any of the described hardware-in-the-loop testing methods based on infinite data loop playback.

[0021] According to another aspect of this application, an electronic device is provided, comprising: one or more processors, a memory, and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, the one or more programs including methods for performing any of the described hardware-in-the-loop testing methods based on infinite data loop playback.

[0022] By applying the technical solution of this application, an infinite data loop replay mechanism based on a preheating window is introduced into hardware-in-the-loop testing, effectively solving the problem of incomplete test scenario coverage caused by limited data volume in existing testing technologies. Specifically, this solution acquires a set of data sequences for testing, which includes multiple time-aligned data sequences originating from various vehicle sensors. By determining the preheating window, data offset time, and loop start time, the preheating window defines the start and end time intervals during data loop replay. The start time is based on the timestamp of the last frame of the data sequence that finishes replaying first, while the end time is the moment when the domain controller under test completes its reset. The data offset time is derived from the difference between the timestamp of the last frame of the last replaying data sequence and the timestamp of the first frame of the first replaying data sequence, ensuring the continuity of data frames and timestamps during loop replay and avoiding abrupt time changes or data interruptions. The loop start time corresponds to the timestamp of the last frame of the data sequence that finishes replaying last, thereby enabling infinite loop replay of data. The constructed loop replay sequence is input into the hardware-in-the-loop testing system to perform continuous data loop testing on the domain controller under test, obtaining more comprehensive test results. This solution improves data reusability, reduces the need for data re-acquisition, significantly lowers testing costs, and ensures high-precision time synchronization of data during testing. This results in more accurate and reliable test results, comprehensively verifying the performance stability of the domain controller under test (DUT) under various operating conditions. Therefore, this solution addresses the problem of limited data re-feedback in existing HIL testing data re-feedback schemes, which cannot meet the needs of long-term continuous testing. Attached Figure Description

[0023] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments and descriptions of this application are used to explain this application and do not constitute an undue limitation of this application. In the drawings:

[0024] Figure 1 A hardware structure block diagram of a mobile terminal for performing a hardware-in-the-loop testing method based on infinite data loop playback, according to an embodiment of this application, is shown.

[0025] Figure 2 A schematic flowchart of a hardware-in-the-loop testing method based on infinite data loop replay provided in an embodiment of this application is shown.

[0026] Figure 3 A schematic diagram illustrating data time synchronization provided according to an embodiment of this application is shown;

[0027] Figure 4 A schematic diagram of a loop playback sequence provided according to an embodiment of this application is shown;

[0028] Figure 5A schematic diagram of the data collection and reinjection process according to an embodiment of this application is shown;

[0029] Figure 6 A flowchart illustrating the HIL replay status monitoring provided according to an embodiment of this application is shown.

[0030] Figure 7 A schematic diagram of the global control process for the cyclic playback of a preheating window provided according to an embodiment of this application is shown.

[0031] Figure 8 A structural block diagram of a hardware-in-the-loop test apparatus based on infinite data loop playback provided according to an embodiment of this application is shown. Detailed Implementation

[0032] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0033] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0034] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate for the embodiments of this application described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0035] As described in the background section, existing HIL testing data backfeeding schemes have limited backfeeding data volume, which cannot meet the requirements of long-term continuous testing. To solve the problem that existing HIL testing data backfeeding schemes have limited backfeeding data volume and cannot meet the requirements of long-term continuous testing, embodiments of this application provide a hardware-in-the-loop testing method, apparatus, computer-readable storage medium, and electronic device based on infinite data loop playback.

[0036] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention.

[0037] The methods and embodiments provided in this application can be executed on a mobile terminal, a computer terminal, or a similar computing device. Taking running on a mobile terminal as an example, Figure 1 This is a hardware structure block diagram of a mobile terminal based on a hardware-in-the-loop testing method for infinite data loop playback, according to an embodiment of the present invention. Figure 1 As shown, a mobile terminal may include one or more ( Figure 1 Only one is shown in the diagram. A processor 102 (which may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.) and a memory 104 for storing data are also shown. The mobile terminal may further include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the mobile terminal described above. For example, the mobile terminal may also include components that are more... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0038] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the hardware-in-the-loop testing method based on infinite data loop replay in this embodiment of the invention. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, thereby implementing the above-described method. The memory 104 may include high-speed random access memory and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the mobile terminal via a network. Examples of the aforementioned networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof. The transmission device 106 is used to receive or send data via a network. Specific examples of the aforementioned networks may include wireless networks provided by the mobile terminal's communication provider. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can be connected to other network devices via a base station to communicate with the Internet. In one example, the transmission device 106 may be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0039] This embodiment provides a hardware-in-the-loop testing method based on infinite data loop playback that runs on a mobile terminal, computer terminal, or similar computing device. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Also, although the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a different order than that shown here.

[0040] Figure 2 This is a flowchart of a hardware-in-the-loop testing method based on infinite data loop playback according to an embodiment of this application. Figure 2 As shown, the method includes the following steps:

[0041] Step S201: Obtain a data sequence group for hardware-in-the-loop testing, wherein the data sequence group includes: multiple time-aligned data sequences, each of which is acquired by a sensor of the vehicle;

[0042] Step S202: Determine the warm-up window, data offset time, and loop start time of the loop playback sequence to be constructed based on the data sequence group and the hardware-in-the-loop test system. The warm-up window includes a warm-up start time and a warm-up end time. The warm-up start time is the timestamp of the last frame of the data sequence that is the first to be played back in the data sequence group. The warm-up end time is the time when the hardware-in-the-loop test system is reset. The data offset time is the difference between the timestamp of the last frame of the last data sequence that is played back in the data sequence group and the timestamp of the first frame of the first data sequence that is played back. The loop start time is the timestamp of the last frame of the last data sequence that is played back in the data sequence group.

[0043] Step S203: Construct the loop playback sequence based at least on the data sequence group, the warm-up window of the loop playback sequence, the data offset time, and the loop start time, and input the loop playback sequence into the hardware-in-the-loop test system to perform data loop test processing on the domain controller under test and obtain the test results.

[0044] This embodiment, by applying steps S201, S202, and S203, introduces an infinite data loop playback mechanism based on a preheating window in hardware-in-the-loop testing, effectively solving the problem of incomplete test scenario coverage caused by limited data volume in existing testing technologies. Specifically, this embodiment acquires a data sequence group for testing, which includes multiple time-aligned data sequences originating from various vehicle sensors. By determining the preheating window, data offset time, and loop start time, the preheating window defines the start and end time intervals during data loop playback. The start time is based on the timestamp of the last frame of the first data sequence to be replayed in the data sequence group, while the end time is the moment the domain controller under test completes its reset. The data offset time is derived from the difference between the timestamp of the last frame of the last replayed data sequence and the timestamp of the first frame of the first replayed data sequence, ensuring the continuity of data frames and timestamps during loop playback and avoiding abrupt time changes or data interruptions. The loop start time corresponds to the timestamp of the last frame of the latest replayed data sequence, enabling infinite loop playback of data. The constructed loop replay sequence is input into the hardware-in-the-loop (HIL) test system to perform continuous data loop testing on the domain controller under test, resulting in more comprehensive test results. This embodiment improves data reusability, reduces the need for re-acquiring data, significantly lowers testing costs, and ensures high-precision time synchronization of data during the testing process, thereby making the test results more accurate and reliable and comprehensively verifying the performance stability of the domain controller under test under various operating conditions. Therefore, this embodiment solves the problem that existing HIL testing data backfeedback schemes have limited backfeed data volume, which cannot meet the needs of long-term continuous testing.

[0045] In the specific implementation process, the above-mentioned loop playback sequence is composed of multiple rounds of the above-mentioned data sequence groups spliced ​​together. The data frame time of each data sequence in the Nth round of the above-mentioned data sequence group is equal to the sum of the data frame time of each data sequence in the (N-1)th round of the above-mentioned data sequence group and the corresponding data offset time of each data sequence, where N is greater than or equal to 2.

[0046] In this embodiment, the loop playback sequence is composed of multiple rounds of data sequence groups, each originating from the same set of collected original datasets. Taking the Nth round of data sequence group as an example, the data frame time of each data sequence is equal to the sum of the data frame time of each data sequence in the (N-1)th round of data sequence group and the corresponding data offset time of each data sequence. This operation ensures the consistency and coherence of time between each loop, avoiding time abrupt changes caused by simply repeating data. Through this loop offset strategy, the system can maintain the continuity of data frame timestamps while continuously replaying the original data, thereby avoiding the impact of time jumps on test results and improving the accuracy and reliability of HIL testing. As the value of N increases, the system can simulate vehicle operating conditions over a longer time span, achieving test coverage of complex and rare events, thus improving the comprehensiveness and effectiveness of the test. This technology is not only applicable to loop playback of single sensor data, but can also be extended to multi-sensor collaborative playback scenarios, significantly enhancing data reusability and test efficiency, and reducing the implementation cost of HIL testing.

[0047] Specifically, during the process of inputting the above-mentioned loop playback sequence into the hardware-in-the-loop test system to perform data loop testing on the domain controller under test, the hardware-in-the-loop test method further includes: resetting the hardware-in-the-loop test system when the above-mentioned warm-up start time is reached; and determining the current time point as the above-mentioned warm-up end time and continuing to perform data loop testing on the domain controller under test when the reset of the hardware-in-the-loop test system is detected to be complete.

[0048] In this embodiment, when the warm-up start time is triggered, the hardware-in-the-loop (HIL) test system immediately performs a reset to prepare for a new round of data loop testing. This process ensures the consistency of the initial state of the test environment, providing a clean starting point for subsequent tests. After detecting the signal that the HIL test system has completed its reset, the current time point is marked as the warm-up end time, and data loop testing resumes. This design achieves seamless connection between data replay and system state through the warm-up window mechanism, avoiding potential time abrupt changes or data interruptions during loop switching, ensuring the authenticity and continuity of the test. The use of the warm-up window allows HIL testing to loop infinitely on a finite dataset, not only improving data reuse and reducing testing costs, but also solving the problems of data connection and timing synchronization at the beginning and end of the loop, thereby improving test coverage and accuracy.

[0049] More specifically, constructing the loop playback sequence based at least on the aforementioned data sequence group, the aforementioned warm-up window of the aforementioned loop playback sequence, the aforementioned data offset time, and the aforementioned loop start time includes: obtaining a preset data preload time when it is determined that the aforementioned hardware-in-the-loop test system needs to set a data preload time; constructing the loop playback sequence based on the aforementioned data preload time, the aforementioned data sequence group, the aforementioned warm-up window of the aforementioned loop playback sequence, the aforementioned data offset time, and the aforementioned loop start time, wherein the aforementioned data offset time is the sum of the difference between the last frame timestamp and the first frame timestamp of each of the aforementioned data sequences in the aforementioned data sequence group and the aforementioned data preload time, and the aforementioned loop start time is the sum of the timestamp of the last frame data of the last data sequence in the aforementioned data sequence group that has been replayed and the aforementioned data preload time.

[0050] In this embodiment, a loop playback sequence is constructed based at least on the data sequence group, the warm-up window of the loop playback sequence, the data offset time, and the loop start time. Specifically, firstly, given that the hardware-in-the-loop test system needs to set a data preload time, a preset data preload time gap is obtained. Subsequently, the loop playback sequence is constructed based on the gap, the data sequence group, the warm-up window of the loop playback sequence, the data offset time offset, and the loop start time. The data offset time offset is calculated as the sum of the difference between the last frame timestamp and the first frame timestamp of each data sequence in the data sequence group and the data preload time gap. The loop start time is the timestamp of the last frame data of the last data sequence in the data sequence group that has been replayed, plus the gap. This design ensures seamless connection of all sensor data on the timeline during data loop playback, avoiding time abrupt changes and data interruptions during loop switching, effectively improving the realism and accuracy of HIL testing. Simultaneously, the introduction of the warm-up window allows the system to perform state initialization and time synchronization calibration before loop playback, further enhancing the stability of the test system and the reliability of the test results. Through the aforementioned precise time control and data processing mechanism, this embodiment achieves efficient and unlimited recycling of limited data resources, significantly reduces the cost of HIL testing, improves testing efficiency and data reusability, and solves the problems of limited data volume, high reuse cost, and test errors during cycle switching in traditional HIL testing.

[0051] Furthermore, when it is detected that the hardware-in-the-loop test system has been reset, the current time point is determined as the preheating end time, including: when it is detected that the hardware-in-the-loop test system has been reset, determining that no alarm has occurred in the hardware-in-the-loop test system within a preset time period, and determining the current time point as the preheating end time.

[0052] In this embodiment, once the Hardware-in-the-Loop (HIL) test system has been reset, and it is further confirmed that no alarms have occurred within a preset time period, the current time point is marked as the warm-up end time. This mechanism aims to ensure the adequacy and safety of the warm-up phase by monitoring the system status. During the warm-up window, the system undergoes initialization and preparation phases, the key of which is to avoid any abnormal situations that may affect the accuracy of the test. By setting an alarm monitoring period, the system can smoothly transition to the formal testing phase in the absence of serious errors, thereby enhancing the reliability and effectiveness of HIL testing. The existence of the warm-up window ensures the consistency of the initial test conditions, and even during data loop playback, it avoids instability in the test environment caused by sudden time changes or data interruptions, thereby reducing the risk of test misjudgment and improving the authenticity and accuracy of the test results.

[0053] Furthermore, before inputting the aforementioned loop replay sequence into the hardware-in-the-loop test system for data loop testing of the domain controller under test, the hardware-in-the-loop test method further includes: performing lock-free processing on the test controller in the hardware-in-the-loop test system based on the CAS lock-free strategy to supervise the hardware-in-the-loop test.

[0054] In this embodiment, the test controller in the hardware-in-the-loop (HIL) test system is lock-free based on a CAS lock-free strategy, aiming to improve the efficiency and security of test control. By adopting a lock-free mechanism, the test controller can effectively monitor the loop playback process, especially during the warm-up window. It can ensure real-time monitoring of the system status and avoid misjudgments caused by data interruptions or time abrupt changes during loop transitions. This strategy eliminates the performance bottlenecks and deadlock risks of traditional locking mechanisms through atomic operations on key state variables, enabling the data loading and sending modules in the loop playback process to work efficiently together. Under the management of the warm-up window, the test controller can intelligently determine when to start and stop the warm-up phase and when to update the loop timestamp offset, ensuring the continuity and accuracy of the loop test while maintaining the feedback loop of the hardware under test and its system status. This provides a consistent and reliable test environment throughout the entire test cycle, significantly improving the coverage and efficiency of HIL testing.

[0055] Specifically, acquiring a data sequence set for hardware-in-the-loop testing includes: acquiring sensor data collected by each sensor of the vehicle, preprocessing the sensor data of each of the aforementioned sensors to obtain multiple data sequences, and constructing the data sequence set for hardware-in-the-loop testing based on the aforementioned data sequences. The preprocessing includes time synchronization processing between the aforementioned sensor data and real-world time alignment processing of the aforementioned sensor data.

[0056] In this embodiment, acquiring a data sequence set for hardware-in-the-loop (HIL) testing includes acquiring sensor data collected by various vehicle sensors, preprocessing the sensor data to obtain multiple data sequences, and constructing a data sequence set for HIL testing based on these data sequences. The preprocessing encompasses time synchronization and real-world time alignment of the sensor data, aiming to eliminate timing differences between multiple sensor data during loop playback, ensuring seamless data integration and test authenticity. By accurately calculating the time offset of each data sequence, the timestamps of all data frames are aligned with real-world time, thus maintaining the temporal continuity and consistency of the data during looping. This solution overcomes the problems of limited data volume and poor time synchronization in traditional HIL testing, enabling unlimited continuous playback of limited data, greatly expanding the test scenario, improving test efficiency and accuracy, reducing unnecessary data acquisition costs, and also avoiding the risk of misjudgment caused by signal abrupt changes during loop switching.

[0057] To enable those skilled in the art to better understand the technical solution of this application, the implementation process of the hardware-in-the-loop testing method based on infinite data loop playback of this application will be described in detail below with reference to specific embodiments.

[0058] The existing HIL test data backfeedback scheme has the following problems:

[0059] 1. The amount of data re-feeding is limited and cannot meet the needs of long-term continuous testing;

[0060] 2. Poor data reusability leads to low testing efficiency and high costs;

[0061] 3. Sudden time changes and data interruptions during loop switching can compromise the realism of the test and lead to misjudgments.

[0062] This embodiment relates to a specific hardware-in-the-loop testing method based on infinite data loop playback, which specifically includes the following:

[0063] 1. Data time synchronization processing:

[0064] like Figure 3 As shown, in the HIL system, all time quantities are aligned to real-world time. Therefore, HIL will initialize when replay starts. During the initialization process, it will calculate the offset (denoted as record_offset) that needs to be uniformly added to the timestamp of each frame of the acquired data (hereinafter referred to as record):

[0065] record_offset = HIL startup initialization timestamp - first frame GNSS timestamp in record;

[0066] Therefore, during the HIL replay process, the actual sending timestamp (denoted as time_to_send) of each frame of data re-fed by all sensors can be expressed as: time_to_send = original timestamp of record data frame + record_offset;

[0067] Since the original timestamp of the record data frame is time-synchronized, HIL replay needs to ensure sufficient sending accuracy. Sending according to time_to_send can achieve sensor data synchronization during replay.

[0068] 2. Warm-up window during the cycle phase:

[0069] like Figure 4 As shown, this embodiment uses a preheating window to solve the problem of data frame and timestamp concatenation during the simple analysis loop of data replay from two sensors, LiDAR and camera. Firstly, according to... Figure 4 As shown, the camera is the first sensor to complete data playback, and the LiDAR is the last sensor to complete data playback.

[0070] After the time synchronization processing of the data used in this embodiment, the time synchronization between each frame of the loaded different sensor data is satisfied and aligned to real-world time. Therefore, it is only necessary to ensure that the timestamps of all data frames can maintain a consistent offset (denoted as Offset) in each loop replay, so that all sensor data in the loop can still maintain time synchronization.

[0071] Therefore, at the junction of each loop replay, within each loop replay, the offset size that should be added to the raw data timestamps of each sensor is calculated. According to... Figure 4 The timeline diagram shown illustrates the calculation sources for the following key moments:

[0072] 1) Data preloading duration (denoted as gap): Since the initialization process and data loading require a time buffer after the program starts, an optional manual setting of a data preloading duration (in milliseconds, which can be set to 0) is provided.

[0073] 2) The start time of each preheating window = the timestamp of the last frame of sensor data that was the first to be replayed in the previous replay;

[0074] 3) The end time of each warm-up window = the real-world time of receiving the notification that the hardware environment under test and the system reset are complete, that is, the system under test has entered the normal operation test state;

[0075] 4) The start time of each round in the loop replay = timestamp of the last frame of the previous round + gap;

[0076] 5) Offset = (Timestamp of the last frame of the data sequence that was last played in the entire round - Timestamp of the first frame of the data sequence that started playing in the entire round) + gap, for example Figure 4 In the first round of replay, the timestamp of the first frame of the entire round is the timestamp of the first frame of the camera, while the timestamp of the last frame of the entire round is the timestamp of the last frame of the lidar, because the camera is the first to start sending data, and the lidar is the last to finish sending all data.

[0077] 6) The timestamp of each sensor data = the original timestamp in the record + Offset.

[0078] 3. Basic data reinjection process after data collection:

[0079] In HIL testing, the data replay recorded by the vehicle needs to meet high-precision time synchronization, which is a fundamental prerequisite for accurate testing of the hardware environment and system under test. In this embodiment, the data timestamp processing mentioned above is strictly aligned to real-world time. This ensures real-time performance for subsequent loop replays and the output of the entire HIL test results, and is also more user-friendly for subsequent problem analysis.

[0080] Figure 5 This is a schematic diagram of the data recharge process after data collection, such as... Figure 5 As shown, the process first reads and loads offline data (raw data), then calculates the offset between the raw data timestamp and real-world time. Based on this time offset, all raw data frames are aligned to future real-world time, thus calculating the expected transmission time in the replay. This data is then stored in a priority queue, sorted by timestamp. The next frame is retrieved from the priority queue sequentially and sent to the link to the domain controller under test, enabling testing of the domain controller. In a complete HIL replay cycle, each sensor data transmission follows this process. This process primarily uses a three-component encapsulation design to simulate the real sensor device at three different levels, summarized as follows:

[0081] Data loading module: This module reads raw data frames and stores them in a priority queue. Data is sorted according to the `time_to_send` timestamp of each frame, with the first-in, first-out order, simulating the data generation process on the sensor. Within the loop logic, this module resets the data playback pointer and preloads the buffer to ensure continuity between data frames and time synchronization.

[0082] Data transmission module: Internally, this corresponds to a data loading module, responsible for reloading each frame of data generated during preloading according to its timestamp. This module also incorporates TX and RX thread capabilities to simulate the data transmission link on the sensor.

[0083] Sensor simulation module: Device encapsulation layer, internally corresponding to the data transmission module of the current sensor (multiple modules are allowed), used to simulate a complete sensor device (such as Lidar Device, GNSS Device, Camera Device, etc.).

[0084] 4. Status feedback process for the preheating window:

[0085] To monitor the status of the hardware and system under test (HIL), such as the autonomous driving domain controller and system in a vehicle as the HIL environment, during the warm-up window, it is necessary to monitor in real time the critical alarms (CA) generated within the autonomous driving system, as well as whether the autonomous driving system has completed localization initialization, entered automatic mode, or triggered system degradation. For this purpose, a monitoring module for the environment under test was specifically designed and implemented. This module is responsible for feeding back necessary key status information to the replay program. With the support of the warm-up window, continuous data loop playback requires monitoring capabilities, especially determining the current warm-up window status of the system under test to avoid interfering with the determination of the vehicle system's operating status during the replay process. The change logic of the warm-up window can be summarized as follows:

[0086] a) Replay starts, immediately triggering the start of the warm-up window;

[0087] b) When the first sensor data is completely sent during a replay, the warm-up phase begins immediately.

[0088] c) The system under test remains in a preheating state until it is fully reset or ready.

[0089] d) When the system location reset is complete and no abnormal alarms are triggered within a preset time threshold (default 10s), the system is considered to have been completely reset and entered the ready state, at which point the warm-up window ends;

[0090] The complete logic flow of the HIL warm-up window status monitoring module is as follows: Figure 6As shown, the replay test process is first initiated to warm up the test system. Data frames of each data sequence are sent in timestamp order to determine if the system is in the warm-up phase. If the system is in the warm-up phase and the test system reset is confirmed to be complete, the warm-up is complete. Data frames of each data sequence are then sent to the domain controller under test in timestamp order to test the domain controller. At the same time, it is determined whether the replay data sequence appears for the first time in the current replay data sequence group. If it does not appear and all data sequences have been replayed, the replay test is exited.

[0091] 5. Implementation of a global controller for loop playback based on a preheating window:

[0092] In this innovative warm-up window mode, the data loading module and data sending module are managed by a global controller, which controls the closed-loop logic of data loading and sending. Because this controller is coupled with a large number of sensor simulation threads, a lock-free design based on CAS is implemented to improve program efficiency. The following is a flowchart of the global controller currently controlling the loop logic, detailing how the data loading loop, data sending loop, and warm-up state transition loop are controlled, etc. Figure 7 As shown:

[0093] The small loop for loading data: After one round of loading is completed, it blocks and waits for all sensors to finish sending data. Then, the global controller wakes it up and notifies it to enter the next round.

[0094] The small loop for sending data: simply retrieve data from the priority data queue and send the data. When a simulated sensor finishes sending the last frame, if it is the first to finish sending, the global controller will start the warm-up phase. If it is the last to finish sending, it means that the data replay of the current round is completely completed, and the global controller will wake up and notify the start of the next round.

[0095] The entire data loading / sending process is based on a large loop of wake-up notifications: In each loop, after the data is loaded, wait for all sensors to finish sending (i.e., the entire replay is completely completed) before waking up the next round of data loading and sending. The new round of data will be superimposed with the timestamp offset of the previous round (referred to as the loop offset) to avoid time jump problems caused by the connection between the previous and subsequent rounds.

[0096] The large loop of preheating status changes: According to the status feedback process for the preheating window described above, the time period during which the system has not completed its reset after the replay begins should be within the preheating phase window. The preheating will only end after the conditions for the system to complete its reset are met.

[0097] This embodiment achieves the following technical effects through the above technical solution:

[0098] 1) By preprocessing the collected data on time and aligning the entire HIL system with real-world time, high-precision time synchronization of data from different sensors is ensured. During the reflow period, the time accuracy is less than 50µs. This high-precision time synchronization ensures the normal operation of the loop playback technology.

[0099] 2) By designing a warmup window in the loop phase, the problem of data frame and timestamp connection is solved, thereby realizing infinite continuous replay of limited data. This allows for the coverage of many extreme stress test scenarios without the need to recollect a large amount of data, greatly improving data reusability and reducing testing costs.

[0100] 3) For the warm-up window scheme, a status feedback mechanism for the hardware and system under test is designed and implemented to ensure that the HIL test program adjusts the problem reporting logic in a timely manner according to the feedback during the loop connection process, thereby avoiding misjudgment problems during the loop connection process.

[0101] 4) Based on the CAS lockless design, a lockless controller is realized that integrates Warmup preheating window monitoring, tested hardware and system status feedback, loop timestamp offset, and loop cycle control, ensuring the efficient and safe operation of the entire loop scheme.

[0102] This application also provides a hardware-in-the-loop testing apparatus based on infinite data loop playback. It should be noted that this hardware-in-the-loop testing apparatus can be used to execute the hardware-in-the-loop testing method based on infinite data loop playback provided in this application. This apparatus is used to implement the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can refer to a combination of software and / or hardware that performs a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0103] The following describes the hardware-in-the-loop testing device based on infinite data loop playback provided in the embodiments of this application.

[0104] Figure 8 This is a schematic diagram of a hardware-in-the-loop testing apparatus based on infinite data loop playback according to an embodiment of this application. Figure 8 As shown, the device includes:

[0105] Acquisition unit 81 is used to acquire a data sequence group for hardware-in-the-loop testing, wherein the data sequence group includes: multiple time-aligned data sequences, each of which is acquired by a sensor of the vehicle;

[0106] The construction unit 82 is used to determine the warm-up window, data offset time, and loop start time of the loop playback sequence to be constructed based on the data sequence group and the hardware-in-the-loop test system. The warm-up window includes a warm-up start time and a warm-up end time. The warm-up start time is the timestamp of the last frame data of the data sequence that is the first to be replayed in the data sequence group. The warm-up end time is the time point when the hardware-in-the-loop test system is reset. The data offset time is the difference between the timestamp of the last frame that is the last to be replayed in the data sequence group and the timestamp of the first frame that is the first to be replayed. The loop start time is the timestamp of the last frame data of the data sequence that is the last to be replayed in the data sequence group.

[0107] The processing unit 83 is configured to construct the loop playback sequence based at least on the data sequence group, the warm-up window of the loop playback sequence, the data offset time, and the loop start time, and input the loop playback sequence to the hardware-in-the-loop test system to perform data loop test processing on the domain controller under test and obtain test results.

[0108] In this embodiment, the acquisition unit is used to acquire a data sequence group for hardware-in-the-loop testing, wherein the data sequence group includes multiple time-aligned data sequences, each data sequence being acquired by various sensors of the vehicle; the construction unit is used to determine the warm-up window, data offset time, and loop start time of the loop playback sequence to be constructed based on the data sequence group and the hardware-in-the-loop testing system, wherein the warm-up window includes a warm-up start time and a warm-up end time, the warm-up start time is the timestamp of the last frame data of the data sequence that first completes playback in the data sequence group, the warm-up end time is the time point when the hardware-in-the-loop testing system completes reset, the data offset time is the difference between the timestamp of the last frame that last completes playback and the timestamp of the first frame that first starts playback in the aforementioned data sequence group, and the loop start time is the timestamp of the last frame data of the data sequence that last completes playback in the data sequence group; the processing unit is used to construct the loop playback sequence based at least on the data sequence group, the warm-up window of the loop playback sequence, the data offset time, and the loop start time, and input the loop playback sequence into the hardware-in-the-loop testing system to perform data loop testing processing on the domain controller under test to obtain test results. By introducing a preheating window-based infinite data loop replay mechanism in hardware-in-the-loop testing, this embodiment effectively solves the problem of incomplete test scenario coverage caused by limited data volume in existing testing technologies. Specifically, this embodiment acquires a data sequence group for testing, which includes multiple time-aligned data sequences from various vehicle sensors. By determining the preheating window, data offset time, and loop start time, the preheating window defines the start and end time intervals during data loop replay. The start time is based on the last frame timestamp of the first data sequence to be replayed in the data sequence group, while the end time is the moment when the domain controller under test completes its reset. The data offset time is derived from the difference between the last frame timestamp of the last data sequence to be replayed and the first frame timestamp of the first data sequence to be replayed, ensuring the continuity of data frames and timestamps during loop replay and avoiding abrupt time changes or data interruptions. The loop start time corresponds to the last frame timestamp of the last data sequence to be replayed, thereby enabling infinite loop replay of the data. The constructed loop replay sequence is input into the hardware-in-the-loop testing system to perform continuous data loop testing on the domain controller under test, obtaining more comprehensive test results. This embodiment improves data reusability, reduces the need for re-acquiring data, significantly lowers testing costs, and ensures high-precision time synchronization of data during testing, thereby making test results more accurate and reliable and comprehensively verifying the performance stability of the domain controller under test under various operating conditions. Therefore, this embodiment solves the problem that existing HIL testing data backfeedback schemes have limited backfeedback data volume, which cannot meet the needs of long-term continuous testing.

[0109] As an optional approach, the above-mentioned loop replay sequence is composed of multiple rounds of the above-mentioned data sequence groups spliced ​​together. The data frame time of each data sequence in the Nth round of the above-mentioned data sequence group is equal to the sum of the data frame time of each data sequence in the (N-1)th round of the above-mentioned data sequence group and the corresponding data offset time of each data sequence, where N is greater than or equal to 2.

[0110] In one optional embodiment, the apparatus further includes a reset processing unit and a loop test processing unit; the reset processing unit is used to reset the hardware-in-the-loop test system when the warm-up start time is reached during the process of inputting the loop playback sequence into the hardware-in-the-loop test system for data loop test processing of the domain controller under test; the loop test processing unit is used to determine the current time point as the warm-up end time when the reset of the hardware-in-the-loop test system is detected to be complete, and continue to perform data loop test processing on the domain controller under test.

[0111] An optional scheme, the processing unit includes a first acquisition module and a construction module; the first acquisition module is used to acquire the preset data preload time when it is determined that the hardware-in-the-loop test system needs to set a data preload time; the construction module is used to construct the loop playback sequence based on the data preload time, the data sequence group, the warm-up window of the loop playback sequence, the data offset time, and the loop start time, wherein the data offset time is the sum of the difference between the last frame timestamp and the first frame timestamp of each data sequence in the data sequence group and the data preload time, and the loop start time is the sum of the timestamp of the last frame data of the last data sequence that has been replayed in the data sequence group and the data preload time.

[0112] In one alternative, the loop test processing unit includes a determination module, which is used to determine that, when the hardware-in-the-loop test system has been reset, no alarm has occurred in the hardware-in-the-loop test system within a preset time period, and to determine the current time point as the warm-up end time.

[0113] In an alternative embodiment, the apparatus further includes a lock-free processing unit, used to perform lock-free processing on the test controller in the hardware-in-the-loop test system based on the CAS lock-free strategy before inputting the above-mentioned loop playback sequence into the hardware-in-the-loop test system for data loop test processing of the domain controller under test, so as to supervise the hardware-in-the-loop test.

[0114] In one optional scheme, the acquisition unit includes a second acquisition module, which is used to acquire sensor data collected by each sensor of the vehicle, preprocess the sensor data of each of the aforementioned sensors to obtain multiple data sequences, and construct a data sequence group for hardware-in-the-loop testing based on the aforementioned data sequences, wherein the aforementioned preprocessing includes time synchronization processing between the aforementioned sensor data and real-world time alignment processing of the aforementioned sensor data.

[0115] The aforementioned hardware-in-the-loop testing device based on infinite data loop playback includes a processor and a memory. The acquisition unit, construction unit, and processing unit are all stored as program units in the memory, and the processor executes these program units to achieve the corresponding functions. All of the above modules reside in the same processor; alternatively, the modules may be located in different processors in any combination.

[0116] The processor contains a kernel, which retrieves the corresponding program units from memory. One or more kernels can be configured. By adjusting kernel parameters, the problem of limited data re-feedback in existing HIL testing methods, which cannot meet the requirements of long-term continuous testing, can be addressed.

[0117] The memory may include non-permanent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one memory chip.

[0118] This invention provides a computer-readable storage medium including a stored program, wherein, when the program is executed, it controls the device containing the computer-readable storage medium to perform the hardware-in-the-loop test method based on infinite data loop playback.

[0119] Specifically, hardware-in-the-loop testing methods based on infinite data replay include:

[0120] Step S201: Obtain a data sequence group for hardware-in-the-loop testing, wherein the data sequence group includes: multiple time-aligned data sequences, each of which is acquired by a sensor of the vehicle.

[0121] Step S202: Determine the warm-up window, data offset time, and loop start time of the loop playback sequence to be constructed based on the data sequence group and the hardware-in-the-loop test system. The warm-up window includes a warm-up start time and a warm-up end time. The warm-up start time is the timestamp of the last frame of the data sequence that is the first to be played back in the data sequence group. The warm-up end time is the time when the hardware-in-the-loop test system is reset. The data offset time is the difference between the timestamp of the last frame of each data sequence that is the last to be played back in the data sequence group and the timestamp of the first frame of the data sequence that is the first to be played back. The loop start time is the timestamp of the last frame of the data sequence that is the last to be played back in the data sequence group.

[0122] Step S203: Construct the loop playback sequence based at least on the data sequence group, the warm-up window of the loop playback sequence, the data offset time, and the loop start time, and input the loop playback sequence into the hardware-in-the-loop test system to perform data loop test processing on the domain controller under test and obtain the test results.

[0123] This invention provides a processor for running a program, wherein the program executes the hardware-in-the-loop testing method based on infinite data loop replay.

[0124] Specifically, hardware-in-the-loop testing methods based on infinite data replay include:

[0125] Step S201: Obtain a data sequence group for hardware-in-the-loop testing, wherein the data sequence group includes: multiple time-aligned data sequences, each of which is acquired by a sensor of the vehicle.

[0126] Step S202: Determine the warm-up window, data offset time, and loop start time of the loop playback sequence to be constructed based on the data sequence group and the hardware-in-the-loop test system. The warm-up window includes a warm-up start time and a warm-up end time. The warm-up start time is the timestamp of the last frame of the data sequence that is the first to be played back in the data sequence group. The warm-up end time is the time when the hardware-in-the-loop test system is reset. The data offset time is the difference between the timestamp of the last frame of the last data sequence that is played back in the data sequence group and the timestamp of the first frame of the first data sequence that is played back. The loop start time is the timestamp of the last frame of the last data sequence that is played back in the data sequence group.

[0127] Step S203: Construct the loop playback sequence based at least on the data sequence group, the warm-up window of the loop playback sequence, the data offset time, and the loop start time, and input the loop playback sequence into the hardware-in-the-loop test system to perform data loop test processing on the domain controller under test and obtain the test results.

[0128] This invention provides an electronic device, which includes a processor, a memory, and a program stored in the memory and executable on the processor. When the processor executes the program, it performs at least the following steps:

[0129] Step S201: Obtain a data sequence group for hardware-in-the-loop testing, wherein the data sequence group includes: multiple time-aligned data sequences, each of which is acquired by a sensor of the vehicle.

[0130] Step S202: Determine the warm-up window, data offset time, and loop start time of the loop playback sequence to be constructed based on the data sequence group and the hardware-in-the-loop test system. The warm-up window includes a warm-up start time and a warm-up end time. The warm-up start time is the timestamp of the last frame of the data sequence that is the first to be played back in the data sequence group. The warm-up end time is the time when the hardware-in-the-loop test system is reset. The data offset time is the difference between the timestamp of the last frame of the last data sequence that is played back in the data sequence group and the timestamp of the first frame of the first data sequence that is played back. The loop start time is the timestamp of the last frame of the last data sequence that is played back in the data sequence group.

[0131] Step S203: Construct the loop playback sequence based at least on the data sequence group, the warm-up window of the loop playback sequence, the data offset time, and the loop start time, and input the loop playback sequence into the hardware-in-the-loop test system to perform data loop test processing on the domain controller under test and obtain the test results.

[0132] The devices mentioned in this article can be servers, PCs, tablets, mobile phones, etc.

[0133] This application also provides a computer program product, which, when executed on a data processing device, is suitable for executing an initialization program having at least the following method steps:

[0134] Step S201: Obtain a data sequence group for hardware-in-the-loop testing, wherein the data sequence group includes: multiple time-aligned data sequences, each of which is acquired by a sensor of the vehicle.

[0135] Step S202: Determine the warm-up window, data offset time, and loop start time of the loop playback sequence to be constructed based on the data sequence group and the hardware-in-the-loop test system. The warm-up window includes a warm-up start time and a warm-up end time. The warm-up start time is the timestamp of the last frame of the data sequence that is the first to be played back in the data sequence group. The warm-up end time is the time when the hardware-in-the-loop test system is reset. The data offset time is the difference between the timestamp of the last frame of the last data sequence that is played back in the data sequence group and the timestamp of the first frame of the first data sequence that is played back. The loop start time is the timestamp of the last frame of the last data sequence that is played back in the data sequence group.

[0136] Step S203: Construct the loop playback sequence based at least on the data sequence group, the warm-up window of the loop playback sequence, the data offset time, and the loop start time, and input the loop playback sequence into the hardware-in-the-loop test system to perform data loop test processing on the domain controller under test and obtain the test results.

[0137] It is obvious to those skilled in the art that the modules or steps of the present invention described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. They can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those described herein, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, the present invention is not limited to any particular combination of hardware and software.

[0138] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0139] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0140] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0141] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0142] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0143] Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0144] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0145] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0146] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0147] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A hardware-in-the-loop testing method based on infinite data loop playback, characterized in that, include: Acquire a set of data sequences for hardware-in-the-loop testing, wherein the set of data sequences includes: multiple time-aligned data sequences, each of which is acquired by a sensor of the vehicle; The warm-up window, data offset time, and loop start time of the loop playback sequence to be constructed are determined based on the data sequence group and the hardware-in-the-loop test system. The warm-up window includes a warm-up start time and a warm-up end time. The warm-up start time is the timestamp of the last frame of the data sequence that is the first to be replayed in the data sequence group. The warm-up end time is the time point when the hardware-in-the-loop test system completes its reset. The data offset time is the difference between the timestamp of the last frame of the last data sequence that is the first to be replayed in the data sequence group and the timestamp of the first frame of the first data sequence that is the first to be replayed. The loop start time is the timestamp of the last frame of the last data sequence that is the last to be replayed in the data sequence group. The loop playback sequence is constructed based at least on the data sequence group, the warm-up window of the loop playback sequence, the data offset time, and the loop start time. The loop playback sequence is then input into the hardware-in-the-loop test system to perform data loop test processing on the domain controller under test and obtain test results.

2. The method according to claim 1, characterized in that, The loop playback sequence is composed of multiple rounds of the data sequence group spliced ​​together. The data frame time of each data sequence in the Nth round of the data sequence group is equal to the sum of the data frame time of each data sequence in the (N-1)th round of the data sequence group and the corresponding data offset time of each data sequence, where N is greater than or equal to 2.

3. The method according to claim 1, characterized in that, During the process of inputting the loopback sequence into the hardware-in-the-loop test system for data loop testing of the domain controller under test, the hardware-in-the-loop test method further includes: If the preheating start time is reached, the hardware-in-the-loop test system is reset. If the hardware-in-the-loop test system is detected to have completed its reset, the current time point is determined as the preheating end time, and the data loop test processing of the domain controller under test continues.

4. The method according to claim 1, characterized in that, The loop playback sequence is constructed based at least on the data sequence group, the warm-up window of the loop playback sequence, the data offset time, and the loop start time, including: If it is determined that the hardware-in-the-loop test system needs to set a data preload time, obtain the preset data preload time; The loop playback sequence is constructed based on the data preloading time, the data sequence group, the warm-up window of the loop playback sequence, the data offset time, and the loop start time. The data offset time is the sum of the difference between the last frame timestamp of the last data sequence that was played back and the first frame timestamp of the first data sequence that was played back, and the data preloading time. The loop start time is the sum of the timestamp of the last frame of the last data sequence that was played back and the data preloading time.

5. The method according to claim 3, characterized in that, If the hardware-in-the-loop test system is detected to have completed its reset, the current time point is determined as the preheating end time, including: If the hardware-in-the-loop test system is detected to have completed its reset, and it is determined that no alarm has occurred in the hardware-in-the-loop test system within a preset time period, then the current time point is determined as the preheating end time.

6. The method according to claim 1, characterized in that, Before inputting the loopback sequence into the hardware-in-the-loop test system for data loop testing of the domain controller under test, the hardware-in-the-loop test method further includes: The test controller in the hardware-in-the-loop test system is made lock-free based on the CAS lock-free strategy in order to supervise the hardware-in-the-loop test.

7. The method according to claim 1, characterized in that, Obtain a set of data sequences for hardware-in-the-loop testing, including: The sensor data collected by each sensor of the vehicle is acquired, and the sensor data of each sensor is preprocessed to obtain multiple data sequences. The data sequence group for hardware-in-the-loop testing is constructed based on the data sequences. The preprocessing includes time synchronization processing between the sensor data and real-world time alignment processing of the sensor data.

8. A hardware-in-the-loop testing device based on infinite data loop playback, characterized in that, include: An acquisition unit is used to acquire a data sequence group for hardware-in-the-loop testing, wherein the data sequence group includes: multiple time-aligned data sequences, each of which is acquired by a sensor of the vehicle; A construction unit is used to determine the warm-up window, data offset time, and loop start time of the loop playback sequence to be constructed based on the data sequence group and the hardware-in-the-loop test system. The warm-up window includes a warm-up start time and a warm-up end time. The warm-up start time is the timestamp of the last frame of the data sequence that is the first to be replayed in the data sequence group. The warm-up end time is the time point when the hardware-in-the-loop test system is reset. The data offset time is the difference between the timestamp of the last frame of the last data sequence that is the last to be replayed in the data sequence group and the timestamp of the first frame of the first data sequence that is the first to be replayed. The loop start time is the timestamp of the last frame of the last data sequence that is the last to be replayed in the data sequence group. The processing unit is configured to construct the loop playback sequence based at least on the data sequence group, the warm-up window of the loop playback sequence, the data offset time, and the loop start time, and input the loop playback sequence to the hardware-in-the-loop test system to perform data loop test processing on the domain controller under test and obtain test results.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored program, wherein, when the program is executed, it controls the device containing the computer-readable storage medium to perform the hardware-in-the-loop testing method based on infinite data loop playback as described in any one of claims 1 to 7.

10. An electronic device, characterized in that, include: One or more processors, a memory, and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, the one or more programs including a hardware-in-the-loop testing method based on infinite data loop playback as described in any one of claims 1 to 7.

Images