Hardware-in-the-loop testing method, device, electronic device, and storage medium

Abstract

The present application discloses a hardware-in-the-loop test method, device, electronic device and storage medium. The method determines the task type flag corresponding to the target test task by responding to the target test instruction corresponding to the target test task, and generates the target test data corresponding to the target test task based on the task type flag, the target test data including the simulation data corresponding to the target hardware function module required for the vehicle to perform the target test task; the target test data is sent to the tested domain controller used in the vehicle, and the target test data is used for the tested domain controller to perform the target test task; based on the control data fed back after the tested domain controller performs the target test task, the test result corresponding to the target test task is determined. Thus, when the tested domain controller is subjected to hardware-in-the-loop testing, the test equipment adaptively generates corresponding simulation data according to different test tasks, which can improve the flexibility and test efficiency of hardware-in-the-loop testing and improve resource utilization.

Description

Technical Field

[0001] The present application relates to the field of vehicle control technology, and more specifically, to a hardware-in-the-loop testing method, device, electronic device, and storage medium. Background Art

[0002] With the vigorous development of the intelligent driving car industry, the research and development of intelligent driving functions is in the ascendant. The implementation of intelligent driving functions and the release of mass production software strongly rely on functional testing. At present, the main functional testing method still relies on real vehicle testing, although hardware-in-the-loop testing and software testing are gradually beginning to play a certain auxiliary role in testing. However, the efficiency of simulation testing by the current mainstream hardware-in-the-loop testing method is still relatively low. Summary of the invention

[0003] In view of the above problems, the present application proposes a hardware-in-the-loop testing method, device, electronic device and storage medium, which can adaptively generate corresponding simulation data according to different hardware-in-the-loop testing tasks, enhance the flexibility of hardware-in-the-loop testing, and improve resource utilization and testing efficiency.

[0004] In a first aspect, an embodiment of the present application provides a hardware-in-the-loop testing method, which is applied to a testing device, and the method includes: in response to a target test instruction corresponding to a target test task, determining a task type flag corresponding to the target test task, and generating target test data corresponding to the target test task based on the task type flag, wherein the target test data includes simulation data corresponding to a target hardware functional module required for the vehicle to perform the target test task; sending the target test data to a domain controller under test used in the vehicle, and the target test data is used by the domain controller under test to perform the target test task; and determining a test result corresponding to the target test task based on control data fed back after the domain controller under test performs the target test task.

[0005] In the second aspect, an embodiment of the present application provides a hardware-in-the-loop testing method, which is applied to a domain controller under test used in a vehicle, and the method includes: receiving target test data corresponding to a target test task sent by a test device, and the target test data includes simulation data corresponding to a target hardware functional module required for the vehicle to perform the target test task; based on the target test data, executing the target test task, obtaining control data and feeding back the control data to the test device, and the control data is used by the test device to determine the test result corresponding to the target test task.

[0006] In the third aspect, an embodiment of the present application provides a hardware-in-the-loop test device, which is applied to a test device, and the device includes: a data generation module, a data sending module, and a result determination module. Among them, the data generation module is used to respond to the target test instruction corresponding to the target test task, determine the task type flag corresponding to the target test task, and generate the target test data corresponding to the target test task based on the task type flag, and the target test data includes the simulation data corresponding to the target hardware function module required for the vehicle to perform the target test task; the data sending module is used to send the target test data to the tested domain controller used in the vehicle, and the target test data is used for the tested domain controller to perform the target test task; the result determination module is used to determine the test result corresponding to the target test task based on the control data fed back after the tested domain controller performs the target test task.

[0007] In a fourth aspect, an embodiment of the present application provides a hardware-in-the-loop testing device, which is applied to a domain controller under test used in a vehicle, and the device includes: a data receiving module and a task execution module, wherein the data receiving module is used to receive target test data corresponding to a target test task sent by a test device, and the target test data includes simulation data corresponding to a target hardware functional module required for the vehicle to perform the target test task; the task execution module is used to execute the target test task based on the target test data, obtain control data and feed the control data back to the test device, and the control data is used by the test device to determine the test result corresponding to the target test task.

[0008] In a fifth aspect, an embodiment of the present application provides an electronic device, comprising: one or more processors; a memory; one or more applications, wherein the one or more applications are stored in the memory and configured to be executed by the one or more processors, and the one or more programs are configured to execute the hardware-in-the-loop testing method provided in the first aspect above, or to execute the hardware-in-the-loop testing method provided in the second aspect above.

[0009] In a sixth aspect, an embodiment of the present application provides a computer-readable storage medium, in which a program code is stored. The program code can be called by a processor to execute the hardware-in-the-loop testing method provided in the first aspect, or to execute the hardware-in-the-loop testing method provided in the second aspect.

[0010] The solution provided by the present application determines the task type flag corresponding to the target test task in response to the target test instruction corresponding to the target test task, and generates the target test data corresponding to the target test task based on the task type flag, the target test data including the simulation data corresponding to the target hardware function module required for the vehicle to perform the target test task; the target test data is sent to the tested domain controller used in the vehicle, and the target test data is used for the tested domain controller to perform the target test task; based on the control data fed back after the tested domain controller performs the target test task, the test result corresponding to the target test task is determined. Thus, when performing hardware-in-the-loop testing on the tested domain controller used in the vehicle, the test equipment improves the flexibility of hardware-in-the-loop testing by adaptively generating corresponding simulation data according to different test tasks, and improves resource utilization and test efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For those skilled in the art, other drawings can be obtained based on these drawings without creative work.

[0012] Figure 1 A flowchart of a hardware-in-the-loop testing method provided by an embodiment of the present application is shown.

[0013] Figure 2 A flowchart of a hardware-in-the-loop testing method provided by another embodiment of the present application is shown.

[0014] Figure 3 A specific flow chart of step S240 in another embodiment of the present application is shown.

[0015] Figure 4 A schematic diagram of the interaction between the hardware-in-the-loop simulation platform and the domain controller under test in an embodiment of the present application is shown.

[0016] Figure 5 A flowchart of a hardware-in-the-loop testing method provided by yet another embodiment of the present application is shown.

[0017] Figure 6 A specific flow chart of step S320 in another embodiment of the present application is shown.

[0018] Figure 7 The overall flow chart of the hardware-in-the-loop testing method provided in the embodiment of the present application is shown.

[0019] Figure 8 A structural block diagram of a hardware-in-the-loop testing device provided in an embodiment of the present application is shown.

[0020] Fig. 9 A schematic structural diagram of another hardware-in-the-loop testing device provided in an embodiment of the present application is shown.

[0021] Fig.10 A structural block diagram of an electronic device provided in an embodiment of the present application is shown.

[0022] Fig.11 A structural block diagram of a computer-readable storage medium provided in an embodiment of the present application is shown. DETAILED DESCRIPTION

[0023] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application.

[0024] Normally, the functional tests that the implementation of the vehicle's intelligent driving function relies on generally use a variety of methods such as software testing, hardware-in-the-loop testing, and actual vehicle testing to comprehensively determine the effectiveness and safety of the intelligent driving function. Among them, hardware-in-the-loop testing refers to simulating the operating state of the controlled object by running a simulation model through the test equipment, connecting to the domain controller under test through the I / O interface, and conducting a comprehensive and systematic test of the domain controller under test. Considering safety, feasibility and reasonable cost, hardware-in-the-loop testing has become a very important part of the development process of the domain controller for realizing the vehicle's intelligent driving function. It can reduce the number of actual vehicle road tests, shorten development time and reduce R&D costs, while improving the software quality of the domain controller and reducing the risks of car companies.

[0025] However, there are three main methods for implementing hardware-in-the-loop testing: data re-injection open-loop testing, full-stack closed-loop testing, and regulatory closed-loop testing. Among them, the data re-injection open-loop testing method relies heavily on real vehicle data and is mainly aimed at perception testing. It cannot cover the full-stack software, and once the vehicle position changes, the input of the perception module will be distorted, and closed-loop testing cannot be done well; although the full-stack closed-loop testing method can cover all functional modules of the vehicle and can implement closed-loop testing, the amount of perception simulation data is large, the resource requirements are high, and the performance of the perception module is limited; the regulatory closed-loop testing method can bypass the perception module and directly simulate the fusion target, with low resource requirements, but this test method cannot cover the testing of the perception module and other modules, cannot support the testing of the integrated version of the software, and is difficult to meet various testing requirements. It can be seen from this that the existing methods for implementing hardware-in-the-loop simulation testing often cannot take into account multiple different test tasks at the same time, and the test efficiency is not high.

[0026] Therefore, the present application provides a hardware-in-the-loop test method, device, electronic device, and storage medium. When performing hardware-in-the-loop testing on a domain controller under test used in a vehicle, the test device adaptively generates corresponding simulation data according to different test tasks, thereby improving the flexibility of hardware-in-the-loop testing, and improving resource utilization and test efficiency. The specific hardware-in-the-loop test method is described in detail in the subsequent embodiments.

[0027] See also Figure 1 , Figure 1 A schematic diagram of a hardware-in-the-loop testing method according to an embodiment of the present application is shown below. Figure 1 The process shown is described in detail, and the hardware-in-the-loop test method is applied to the test equipment, which may specifically include the following steps:

[0028] Step S110: In response to a target test instruction corresponding to the target test task, determine a task type flag corresponding to the target test task, and generate target test data corresponding to the target test task based on the task type flag, wherein the target test data includes simulation data corresponding to a target hardware functional module required for the vehicle to perform the target test task.

[0029] In an embodiment of the present application, different test tasks may correspond to different test instructions. A technician may input corresponding target test instructions into the test device according to actual needs. After receiving the target test instruction, the test device may first determine the task type flag corresponding to the target test task, wherein the task type flag may uniquely identify the test task. After determining the task type flag corresponding to the target test task, the test device may determine the target hardware functional module required for the vehicle to perform the target test task based on the task type flag, and then generate the target test data corresponding to the target test task based on the simulation module in the test device used to simulate these target hardware functional modules.

[0030] It is understandable that the test device can support the execution of multiple different test tasks, so the test device can simultaneously include simulation modules of the hardware function modules required to execute multiple different test tasks respectively. In order to facilitate the rapid generation of target test data required to execute the target test task after receiving the target test instruction, the test device can determine all simulation modules required to execute the target test task based on the task type flag corresponding to the target test task, and the pre-stored correspondence between the simulation modules corresponding to the different task type flags and the hardware function modules, and then quickly generate the target test data based on these simulation modules.

[0031] In some embodiments, the test equipment may be simulation software such as DSPACE, IPG / CarMaker, etc. These simulation softwares contain simulation modules corresponding to the hardware functional modules present in real vehicles such as vehicle power groups, sensors, cameras, or lidars. Technicians can build a simulated vehicle of the target configuration based on these simulation modules in the test equipment, and connect the test equipment to the domain controller under test. Thus, the test equipment can generate corresponding simulation data through the simulation module and send it to the domain controller under test, and the domain controller under test regards these simulation data as real vehicle data to determine the corresponding operating status of the vehicle simulated by the test equipment, and feedback control data to the test equipment to control the simulated vehicle to achieve the target test task. In this process, the test equipment can find possible defects in the control program in the domain controller under test, and realize hardware-in-the-loop simulation test of the domain controller under test.

[0032] In some implementations, the test tasks that the test device may receive may include full-stack test tasks, regulatory control test tasks, and state management test tasks. The full-stack test tasks are mainly for full-stack tests including the perception module; the regulatory control test tasks are mainly for regulatory control tests; and the state management test tasks are mainly for rapid testing of the state interaction logic between the state management module in the microcontroller unit (MCU) in the tested domain controller and the application module process in the system on chip (SOC).

[0033] Specifically, the domain controller under test needs different test data to perform different test tasks, so the test data generated by the test device according to different test tasks is also different, that is, the test device can control different simulation modules to generate corresponding test data according to different test tasks. Therefore, in order to facilitate the test device to generate target test data related to the target test task, the test device can pre-collect all simulation modules corresponding to all test data required for the same test task into a simulation module group. If the test device receives a specific instruction to perform a target test of the target test task, the task type flag corresponding to the target test task can be directly used to determine the simulation module group corresponding to the target test task, and the target test data required for the target test task can be generated according to all simulation modules included in the simulation module group. It can be understood that the test device generates different simulation module groups corresponding to different test tasks, so that the test device can also adaptively generate different test data for different test tasks. Thus, the test device can support the implementation of a variety of different test tasks through a plurality of different simulation module groups pre-configured, and can adaptively match the corresponding simulation resources according to the different test tasks, and the generated test data does not have to rely on the real vehicle data, so as to realize the hardware-in-the-loop test based on the local simulation data.

[0034] In some implementations, the target test instruction may be received by the test device from an externally connected task management platform, wherein the task management platform may be a cloud server or a local jira system. Specifically, the task management platform may send the corresponding target test instruction to the test device according to a preset timing, or may send the target test instruction in real time according to the operation of the technician.

[0035] In some embodiments, the task type flag corresponding to the target test task can be sent to the test device together with the target test instruction by the task management platform, and the test device can obtain the task type flag corresponding to the target test task by parsing the target test instruction; or the test device can generate a corresponding task type flag that can uniquely identify the target test task based on the target test task indicated to be executed in the target test instruction after receiving the target test instruction. In other embodiments, the test device can also synchronously send the task type flag corresponding to the target test task to the domain controller under test during the process of generating the corresponding target test data and sending the target test data to the domain controller under test, so that the domain controller under test can also directly determine the target test task to be executed based on the task type flag.

[0036] Step S120: Send the target test data to the domain controller under test used in the vehicle, and the target test data is used by the domain controller under test to perform the target test task.

[0037] In an embodiment of the present application, after generating target test data corresponding to the target test task, the test device can send the target test data to the domain controller under test, wherein the domain controller under test is a controller used in a vehicle to control the vehicle to implement various intelligent driving functions. After receiving the target test data, the domain controller under test can execute the target test task based on the target test data.

[0038] Obviously, the reason why the vehicle can realize various intelligent driving functions is that the domain controller included in it has been pre-written with the control program by the technicians. The domain controller can obtain the real-time data of the vehicle from various sensors when running the control program, and judge the current operating status of the vehicle based on these real-time data, and then control the vehicle to realize the intelligent driving function. Therefore, before the domain controller is actually used in the vehicle, the technicians can use it as the tested domain controller and use the test equipment to determine whether the control program in the tested domain controller can run normally and whether it can control the vehicle to stably realize the intelligent driving function.

[0039] Specifically, after receiving the target test instruction, the test equipment can generate target test data corresponding to the target test task and send the target test data to the domain controller under test. The domain controller under test can determine the current operating status of the vehicle simulated by the test equipment based on the target test data and control the test equipment to perform the target test task.

[0040] In some implementations, the domain controller under test may be Huawei's autonomous driving mobile data center platform (MDC), the chip TDA4 generated by Texas Instruments, etc. The domain controller under test may also include an MDC integrated development environment to facilitate technicians to add special executable programs to the domain controller under test through the integrated development environment.

[0041] In other implementations, the domain controller under test may further include a communication management module for receiving target test data sent from the test device and a task type flag corresponding to the target test task.

[0042] In some embodiments, the domain controller under test may include a plurality of different processing module groups, and each processing module group may be used to process and execute different test tasks. After receiving the task type flag sent by the test device, the domain controller under test may determine the target test task to be executed based on the task type flag, and determine the target processing module group corresponding to the target test task. Specifically, each processing module group may include a plurality of different processing modules, and each processing module may perform a portion of the operations in the test task. Among them, the same processing module may appear in different processing module groups. For example, the fault monitoring module may process test data in the state management test task, and may also process test data in the regulation and control test task.

[0043] Step S130: Determine the test result corresponding to the target test task based on the control data fed back by the domain controller under test after executing the target test task.

[0044] In an embodiment of the present application, the tested domain controller can execute the target test task based on the target test data sent by the test device, and the tested domain controller can realize the function of executing the target test task by feeding back the control data to the test device. Specifically, the tested domain controller can determine the operating state of the vehicle simulated by the current test device according to the target test data, and then determine the operation that each simulation module on the test device needs to perform next according to the target test task, which is realized by feeding back the control data to the test device. Among them, the control data fed back by the tested domain controller to the test device includes not only the execution instructions for controlling the next step of each simulation module in the test device, but also the observation data of the execution of the target test task by the current tested domain controller. In other words, the test device can not only control the simulation module to perform the corresponding operation based on the execution data in the control data fed back by the tested domain controller, but also judge whether the current target test task is completed based on the observation data in the control data, and determine the test result corresponding to the target test task.

[0045] The hardware-in-the-loop test method provided in the embodiment of the present application determines the task type flag corresponding to the target test task by responding to the target test instruction corresponding to the target test task, and generates the target test data corresponding to the target test task based on the task type flag, the target test data including the simulation data corresponding to the target hardware functional module required for the vehicle to perform the target test task; the target test data is sent to the tested domain controller used in the vehicle, and the target test data is used for the tested domain controller to perform the target test task; based on the control data fed back after the tested domain controller performs the target test task, the test result corresponding to the target test task is determined. Thus, when performing hardware-in-the-loop testing on the tested domain controller used in the vehicle, the test equipment can adaptively generate corresponding simulation data according to different test tasks, thereby improving the flexibility of hardware-in-the-loop testing, as well as improving resource utilization and testing efficiency.

[0046] See also Figure 2 , Figure 2 A flowchart of a hardware-in-the-loop testing method provided by another embodiment of the present application is shown below. Figure 2 The process shown is described in detail, and the hardware-in-the-loop test method is applied to the test equipment, which may specifically include the following steps:

[0047] Step S210: In response to a target test instruction, determine a task type flag corresponding to the target test task, and determine a target simulation module group corresponding to the target test task based on the task type flag, wherein the target simulation module group includes a simulation module for simulating simulation data corresponding to a target hardware functional module.

[0048] In an embodiment of the present application, the test device may include a plurality of different simulation module groups, each simulation module group corresponds to the simulation data required to generate different test tasks, and each simulation module group is associated with a different task type flag. Therefore, after receiving the target test instruction corresponding to the target test task, the test device may first determine the task type flag corresponding to the target test task, and then directly determine the target simulation module group based on the task type flag, so that the target test data required to execute the target test task can be directly generated based on the target simulation module group.

[0049] It is understandable that the test equipment can support multiple different test tasks. Different test tasks require different test data for reference by the tested domain controller during execution. At the same time, even if the actual vehicle executes the target test task, it usually requires multiple different hardware functional modules to cooperate with each other to achieve it. Therefore, in order to be able to adapt to different test tasks and quickly generate test data corresponding to the test tasks, the test equipment can pre-group all simulation modules used to generate the test data required for each test task into a simulation module group, where each simulation module in the test equipment is a simulation model of a certain hardware functional module of the vehicle.

[0050] Step S220: Based on the target simulation module group, simulate the simulation data corresponding to the target hardware functional module as the target test data.

[0051] In an embodiment of the present application, after the test device determines the corresponding target simulation module group based on the target test task, it can simulate the target test data corresponding to the target test task based on all the simulation modules included in the target simulation module group. Specifically, each simulation module included in the target simulation module group can simulate part of the test data required for the target test task, and the test data simulated by each simulation module in the target simulation module group can be combined to obtain the target test data corresponding to the target test task.

[0052] In some implementations, since the test device and the domain controller under test are usually unable to complete the target test task in one go, they need to be done in a loop manner, that is, the test device continuously updates the test data through the simulation module and sends it to the domain controller under test, and the domain controller under test determines the next step of the control data for each simulation module included in the test device based on the real-time updated test data and the target test task, and feeds it back to the test device. The test device further updates the test data in the simulation module based on the execution data in the control data, and sends the updated test data to the domain controller under test again, thereby achieving the effect of hardware-in-the-loop simulation testing. Therefore, in the process of executing the target test task, the target simulation module group in the test device can not only respond to the initial target test instruction, but also respond to the execution data in the control data fed back by the domain controller under test, and generate simulation data corresponding to the target hardware function module as the target test data.

[0053] Step S230: Acquire positioning data synchronized with the target test data, where the positioning data is simulation data generated by a positioning simulation module of the vehicle.

[0054] In an embodiment of the present application, after the test device obtains the target test data corresponding to the target test task based on the target simulation module group simulation, it can also generate the positioning data corresponding to the target test task in response to the target test instruction through the positioning simulation module. Among them, the positioning data is synchronized with the target test data generated by the target simulation module group, that is, the two can represent the data of different aspects of the vehicle simulated by the test device at the same time. Among them, the positioning data can represent the position and posture data of the vehicle simulated by the test device in the simulation scene, and the target test data represents the sensor data monitored in real time by each functional module configured in the vehicle simulated by the test device.

[0055] In some implementations, the positioning data generated by the positioning simulation module may be generated not only by the test device in response to the target test instruction, but also by the execution data in response to the control data fed back by the domain controller under test.

[0056] Step S240: Send the target test data and positioning data to the domain controller under test.

[0057] In an embodiment of the present application, after the test device obtains the target test data through the target simulation module group and obtains the positioning data through the positioning simulation module, the target test data and its synchronized positioning data can be sent to the domain controller under test, so that the domain controller under test can determine the current state of the vehicle simulated by the test device based on the data generated by these simulation modules, and then perform the target test task.

[0058] In some embodiments, Figure 3As shown, the test device can send the target test data to the tested domain controller in the following ways:

[0059] Step S241: Obtain the communication method corresponding to the target test data.

[0060] In an embodiment of the present application, each simulation module included in the target simulation module group is used to generate test data to obtain target test data, wherein the data types corresponding to the simulation data generated by different simulation modules may be different, and the transmission methods of test data of different data types between the test device and the tested domain controller may not be the same. Therefore, the test device can pre-configure the corresponding simulation module group for different test tasks, and pre-configure the communication methods corresponding to each simulation module included in the simulation module group.

[0061] Specifically, if Figure 4 As shown, if the test tasks sent by the task management platform to the test equipment include three types: full-stack test tasks, regulatory control test tasks, and state management test tasks, then the test equipment can pre-configure the corresponding simulation module group 1 for the full-stack test tasks, the corresponding simulation module group 2 for the regulatory control test tasks, and the corresponding simulation module group 3 for the state management test tasks. Among them, the simulation module group 1 can include simulation modules such as video injection module, laser point cloud injection module, millimeter wave target injection module, and ultrasonic target injection module. Among them, the video injection module is used to generate video data corresponding to the simulation scene in which the vehicle simulated by the test equipment is located. The test equipment can pre-configure the communication method corresponding to the simulation module to convert it into a gigabit multimedia serial link (GMSL) through the High Definition Multimedia Interface (HDMI) and send it to the domain controller under test; the laser point cloud injection module is used to generate simulation point cloud data. The test equipment can pre-configure the communication method corresponding to the simulation module to send it to the domain controller under test through the User Datagram Protocol (UDP); the millimeter wave target injection module and the ultrasonic target injection module are used to generate millimeter wave target information and ultrasonic target information respectively. The test equipment can pre-configure the communication methods corresponding to these two simulation modules to communicate through the controller area network bus (CAN) and define the target data according to the transmission matrix to the domain controller under test.

[0062] Among them, the simulation module group 2 may include simulation modules such as a fusion lane line module and a fusion target module. When generating test data, these two simulation modules can generate test data in accordance with the format of the interface description language (IDL) predefined by the tested domain controller. The test equipment can pre-configure the communication method corresponding to the simulation module to send it to the tested domain controller via UDP.

[0063] The simulation module group 3 may include a state simulation module for filling the state information according to the IDL format predefined by the tested domain controller to obtain test data. The test device may pre-configure the corresponding communication mode to send to the tested domain controller via UDP.

[0064] In some embodiments, the test device may also include a data management module for adaptively switching a target simulation module group that matches the target test task according to the target test instructions, and controlling the sending of the target test data generated by the target simulation module group and the task type flag corresponding to the target test task to the domain controller under test.

[0065] Step S242: Send the target test data to the domain controller under test via communication.

[0066] In an embodiment of the present application, after the test device generates test data respectively based on each simulation module included in the target simulation module group, it can send the test data generated by each simulation module to the domain controller under test based on the pre-configured communication method corresponding to each simulation module, so that the domain controller under test can perform the target test task based on the target test data.

[0067] In some embodiments, the test device can also send the positioning data generated synchronously by the positioning simulation module to the domain controller under test together with the target test data, wherein the test device can also pre-configure the communication method corresponding to the positioning simulation module. Specifically, the positioning simulation module is used to generate the position and posture data corresponding to the vehicle simulated by the device and the WGS84 longitude and latitude data of the simulated vehicle relative to the Open Drive map. The test device can pre-configure its corresponding communication method to send it to the domain controller under test via someip.

[0068] Step S250: Based on the observed data, determine whether the target test task is executed and completed.

[0069] In an embodiment of the present application, the control data includes execution data and observation data. Among them, the observation data is the data fed back by the tested domain controller to the test device to characterize the execution status or execution progress of the current target test task. The test device can determine whether the target test task has been executed based on the observation data fed back by the tested domain controller, that is, determine whether it is necessary to further update the test data output by the simulation module and send it to the tested domain controller.

[0070] Step S260: If the target test task is not completed, the target test data is updated based on the execution data, and the step of sending the target test data to the domain controller under test used in the vehicle is returned until it is determined that the target test task is completed based on the observation data fed back by the domain controller under test.

[0071] In an embodiment of the present application, if the test device determines based on the observation data that the domain controller under test has not yet completed the target test task, then the test device can control the target simulation module group corresponding to the target test task to generate updated target test data based on the execution data fed back by the domain controller under test, and send the updated target test data to the domain controller under test again to achieve a closed loop of test data and perception scenarios.

[0072] Among them, the execution data is the operation instructions that each simulation module in the test equipment should execute next after the domain controller under test determines the current operating status of the simulated vehicle based on the target test data obtained from the test equipment, and then determines the execution status of the target test task.

[0073] In some implementations, if the test device determines that the target test task has not been completed, the target test data can be updated not only through the target simulation module group corresponding to the target test task, but also through the positioning simulation module to update the positioning data. Thereafter, the test device can send the updated target test data and the positioning data synchronized therewith to the domain controller under test.

[0074] Step S270: If the target test task is executed and completed, the test result corresponding to the target test task is determined based on the observed data.

[0075] In an embodiment of the present application, if the test device determines based on the observation data that the target test task has been executed, then the test device can determine the execution status of the target test task based on the observation data, that is, determine whether the domain controller under test executes the target test task according to the expected requirements.

[0076] In some implementations, if the test device determines that the target test task is executed but there are defects in the execution process, the test device can output defect prompt information to inform the technician to make corresponding modifications to the running program in the tested domain controller.

[0077] The hardware-in-the-loop test method provided by the embodiment of the present application determines the task type flag corresponding to the target test task by responding to the target test instruction, and determines the target simulation module group corresponding to the target test task based on the task type flag; based on the target simulation module group, simulates the simulation data corresponding to the target hardware function module as the target test data; obtains the positioning data synchronized with the target test data, and sends the target test data and the positioning data to the domain controller under test; based on the observation data, determines whether the target test task is executed and completed, if the target test task is not executed and completed, then updates the target test data based on the execution data, and returns to the step of sending the target test data to the domain controller under test used in the vehicle, until it is determined based on the observation data fed back by the domain controller under test that the target test task is executed and completed, if the target test task is executed and completed, then determines the test result corresponding to the target test task based on the observation data. Thus, by configuring the corresponding simulation module group for different test tasks, the adaptive closed-loop test of different test tasks is realized on the basis of the existing simulation module, the scalability of the test task is enhanced, and the test efficiency and the utilization rate of the simulation module resources are improved.

[0078] See also Figure 5 , Figure 5 A flowchart of a hardware-in-the-loop testing method provided by another embodiment of the present application is shown below. Figure 5 The process shown is described in detail, and the hardware-in-the-loop test method is applied to a domain controller under test used in a vehicle, and specifically may include the following steps:

[0079] Step S310: receiving target test data corresponding to the target test task sent by the test equipment, where the target test data includes simulation data corresponding to the target hardware function module required for the vehicle to execute the target test task.

[0080] In the embodiment of the present application, after receiving the target test data sent by the test device, the tested domain controller can determine the running state of the vehicle simulated by the test device in the simulation scenario according to the target test data. And according to the execution progress corresponding to the target test task, it is determined whether it is necessary to control each simulation module on the test device to perform a new processing operation.

[0081] In some implementations, a communication management (CM) module may be pre-configured in the domain controller under test to receive target test data and positioning data sent by the test equipment through different communication methods.

[0082] In some implementations, a technician can write an executable program in the tested domain controller through the MDC integrated development environment (Development Studio). The tested domain controller executes the target test task by running the executable program.

[0083] Step S320: Based on the target test data, the target test task is executed to obtain control data and feed the control data back to the test equipment. The control data is used by the test equipment to determine the test result corresponding to the target test task.

[0084] In an embodiment of the present application, after receiving the target test data, the domain controller under test can perform the target test task based on the target test data. Normally, the domain controller under test performs the target test task by controlling the target hardware function modules simulated by each simulation module in the test equipment to perform corresponding operations according to the task requirements, thereby enabling the vehicle simulated by the test equipment to realize the corresponding intelligent driving function. Therefore, in the process of the domain controller under test performing the target test task, it is necessary to continuously feedback control data to the test equipment to instruct the test equipment to control the corresponding simulation module to perform the corresponding operation and update the output simulation data as the updated target test data. The test equipment can send the updated target test data to the domain controller under test again, thereby realizing a closed loop of the test data.

[0085] In some implementations, the test device may also send the task type flag corresponding to the target test task along with the target test data to the domain controller under test, and the domain controller under test may determine the target test task to be executed based on the received task type flag.

[0086] In some embodiments, Figure 6 As shown in the figure, the domain controller under test can perform the target test task through the following steps:

[0087] Step S321: running a bypass shielding program corresponding to the target test task, the bypass shielding program is used to shield processing modules other than the target processing module group.

[0088] In an embodiment of the present application, since the test equipment can adaptively generate different test data for a variety of different test tasks, the tested domain controller can determine the target test task to be executed only after receiving the target test data, and the tested domain controller actually deploys multiple different processing modules that can support all test tasks. Therefore, in order to better perform the target test task alone, the tested domain controller can run the bypass shielding program corresponding to the target test task after receiving the target test data, so as to shield other processing modules outside the target processing module group, wherein the target processing module group includes the processing module required to perform the target test task. Thus, through the bypass shielding module, the tested domain controller can ensure that it will not be interfered with by other execution modules during the subsequent execution of the target test task. At the same time, for different target test tasks, the tested domain controller can shield other processing modules through corresponding different bypass shielding programs, thereby improving the flexibility and resource utilization of each processing module in the tested domain controller.

[0089] In some implementations, the domain controller under test may also include a data conversion program for converting the target test data directly received from the test device into data that can be recognized by the processing module. Specifically, the target test data directly sent from the test device is the simulation data generated by the simulation module, and the target test data obtained after conversion by the data conversion program is the abstract data that can be recognized by the target processing module corresponding to the target test task.

[0090] In some implementations, if the target test task is a full-stack test task, then the domain controller under test may not run the bypass shielding program at this time, or the bypass shielding module corresponding to the full-stack test task will not actually shield any processing module. Because executing the full-stack test task requires running each processing module included in the domain controller under test, including the perception module. If the target test task is a regulatory control test task or a status management test task, executing these tasks does not require running the perception module in the domain controller under test. Therefore, before executing the task, the bypass shielding program can be run to shield the processing modules that are not needed in the process of executing the target test task.

[0091] Step S322: Based on the target test data, run the target processing module group corresponding to the target test task, and the target processing module group is used to process the target test data.

[0092] In an embodiment of the present application, after obtaining the target test data corresponding to the target test task, the domain controller under test can run the target processing module group corresponding to the target test task based on the target test data, wherein the target processing module group includes at least one processing module, and each processing module can process part of the target test data to obtain processed data, so that the domain controller under test can determine the operating status of the vehicle simulated by the test equipment based on the processed data obtained by each processing module in the target processing module group, and generate corresponding control data based on the target test task.

[0093] Specifically, the tested domain controller can run the unshielded processing modules in the tested domain controller based on the target test data. That is to say, after the tested domain controller runs the bypass shielding program corresponding to the target test task, all processing modules that are not related to the execution of the target test task have been shielded. At this time, the tested domain controller can directly run all unshielded processing modules, that is, the target processing module group corresponding to the target test task.

[0094] In some embodiments, please refer again to Figure 4 , when the test tasks include full-stack test tasks, regulatory control test tasks, and state management test tasks, the tested domain controller may include three different processing module groups, namely, processing module group 1, processing module group 2, and processing module group 3. Among them, since processing module group 1 corresponds to the full-stack test task, it includes all processing modules including the perception module; while processing module group 2 corresponds to the regulatory control test task, mainly for regulatory control testing, so the perception module will be shielded; and processing module group 3 corresponds to the state management test task, mainly for the state interaction logic between the state management module in the MCU and the application module process in the SOC to perform a quick test, so the perception module, decision module, and regulatory control module will be shielded.

[0095] Step S323: Generate control data based on the processed data obtained after the target processing module group processes the target test data, and feed the control data back to the test equipment.

[0096] In an embodiment of the present application, the domain controller under test runs the target processing module group corresponding to the target test task to generate control data to feed back to the test device, and then receives the target test data updated by the test device through the target simulation module group, thereby realizing a closed loop of the test data, and then continuously executing the target test task until the test device determines that the target test task is completed through the control data fed back by the domain controller under test, and determines the execution result.

[0097] In some embodiments, the domain controller under test can feed back control data to the test equipment through the communication mode of CAN bus. The control data fed back by the domain controller under test may include observation data and execution data, wherein the execution data is a request for instructing the simulation module in the target simulation module group in the test equipment to perform corresponding operations and update the test data, for example, it may include a steering wheel angle request, an accelerator pedal request, a brake pedal request, a motor torque request, etc. The execution data is also used to instruct the vehicle dynamics module in the test equipment to update and send the posture data of the simulated vehicle.

[0098] The hardware-in-the-loop test method provided in the embodiment of the present application receives the target test data corresponding to the target test task sent by the test equipment; runs the bypass shielding program corresponding to the target test task; based on the target test data, runs the target processing module group corresponding to the target test task; generates control data based on the processing data obtained after the target processing module group processes the target test data, and feeds the control data back to the test equipment. Thus, the domain controller under test can also adaptively run the corresponding processing module based on different target test tasks, and by shielding the processing modules unrelated to the target test tasks, the domain controller under test can support a variety of different test tasks, thereby enhancing the scalability of the test tasks and improving the test efficiency and resource utilization.

[0099] In general, see Figure 7 , which shows the overall flow diagram of the hardware-in-the-loop color measurement method provided in the embodiment of the present application. First, the test device receives the target test task sent by the task management platform. When the test tasks that can be supported include full-stack test tasks, regulatory control test tasks, and state management test tasks, the test device can determine which test task the target test task belongs to in turn, and determine the target simulation module group corresponding to the target test task based on the task type flag corresponding to the target test task. Thereafter, the test device can obtain the target test data through the target simulation module group simulation and send it to the tested domain controller. After the tested domain controller receives the target test data, it can also first determine the target processing module group corresponding to the target test task to be executed. Thereafter, all processing modules in the target processing module group are run to obtain control data and feed the control data back to the test device, wherein the control data includes observation data and execution data, which are used to instruct the test device to update the position and posture data corresponding to the simulated vehicle. Thus, a closed-loop test is achieved until the test device finally determines that the tested domain controller has completed the execution of the target test task.

[0100] See also Figure 8, which shows a structural block diagram of a hardware-in-the-loop test device 200 provided in an embodiment of the present application, which is applied to a test device, and the hardware-in-the-loop test device 200 includes: a data generation module 210, a data sending module 220, and a result determination module 230. Among them, the data generation module 210 is used to respond to the target test instruction corresponding to the target test task, determine the task type flag corresponding to the target test task, and generate the target test data corresponding to the target test task based on the task type flag, and the target test data includes the simulation data corresponding to the target hardware function module required for the vehicle to perform the target test task; the data sending module 220 is used to send the target test data to the tested domain controller used in the vehicle, and the target test data is used for the tested domain controller to perform the target test task; the result determination module 230 is used to determine the test result corresponding to the target test task based on the control data fed back after the tested domain controller performs the target test task.

[0101] As a possible implementation, the result determination module 230 is also used to determine whether the target test task is executed based on the observation data; if the target test task is not executed, the target test data is updated based on the execution data, and the step of sending the target test data to the domain controller under test used in the vehicle is returned until it is determined based on the observation data fed back by the domain controller under test that the target test task is executed; if the target test task is executed, the test result corresponding to the target test task is determined based on the observation data.

[0102] As a possible implementation, in response to the target test instruction corresponding to the target test task. The data generation module 210 is also used to determine the task type flag corresponding to the target test task in response to the target test instruction, and determine the target simulation module group corresponding to the target test task based on the task type flag, the target simulation module group includes a simulation module for simulating the simulation data corresponding to the target hardware function module; based on the target simulation module group, the simulation data corresponding to the target hardware function module is simulated as the target test data.

[0103] As a possible implementation manner, the data sending module 220 is further used to obtain a communication method corresponding to the target test data; and send the target test data to the domain controller under test through the communication method.

[0104] As a possible implementation, the data sending module 220 is also used to obtain positioning data synchronized with the target test data, where the positioning data is simulation data generated by the vehicle's positioning simulation module; and the target test data and the positioning data are sent to the domain controller under test.

[0105] See also Fig. 9, which shows a structural block diagram of a hardware-in-the-loop test device 300 provided in an embodiment of the present application, which is applied to a domain controller under test used in a vehicle, and the hardware-in-the-loop test device 300 includes: a data receiving module 310 and a task execution module 320. Among them, the data receiving module 310 is used to receive target test data corresponding to the target test task sent by the test equipment, and the target test data includes simulation data corresponding to the target hardware function module required for the vehicle to perform the target test task; the task execution module 320 is used to execute the target test task based on the target test data, obtain control data and feed the control data back to the test equipment, and the control data is used for the test equipment to determine the test result corresponding to the target test task.

[0106] As a possible implementation, the task execution module 320 is also used to run the target processing module group corresponding to the target test task based on the target test data, and the target processing module group is used to process the target test data; based on the processed data obtained after the target processing module group processes the target test data, control data is generated, and the control data is fed back to the test equipment.

[0107] As a possible implementation, the task execution module 320 is also used to run a bypass shielding program corresponding to the target test task, and the bypass shielding program is used to shield processing modules other than the target processing module group; based on the target test data, run the unshielded processing modules in the tested domain controller.

[0108] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the above-described devices and modules can refer to the corresponding processes in the aforementioned method embodiments, and will not be repeated here.

[0109] In several embodiments provided in the present application, the coupling between modules may be electrical, mechanical or other forms of coupling.

[0110] In addition, each functional module in each embodiment of the present application can be integrated into a processing module, or each module can exist physically separately, or two or more modules can be integrated into one module. The above integrated modules can be implemented in the form of hardware or software functional modules.

[0111] In summary, the solution provided by the present application determines the task type flag corresponding to the target test task by responding to the target test instruction corresponding to the target test task, and generates the target test data corresponding to the target test task based on the task type flag, the target test data including the simulation data corresponding to the target hardware function module required for the vehicle to perform the target test task; the target test data is sent to the tested domain controller used in the vehicle, and the target test data is used for the tested domain controller to perform the target test task; based on the control data fed back after the tested domain controller performs the target test task, the test result corresponding to the target test task is determined. Thus, when performing hardware-in-the-loop testing on the tested domain controller used in the vehicle, the test equipment improves the flexibility of hardware-in-the-loop testing by adaptively generating corresponding simulation data according to different test tasks, and improves resource utilization and test efficiency.

[0112] Please refer to Fig.10 , which shows a structural block diagram of an electronic device 400 provided in an embodiment of the present application. The electronic device 400 in the present application may include one or more of the following components: a processor 410, a memory 420, and one or more applications, wherein the one or more applications may be stored in the memory 420 and configured to be executed by one or more processors 410, and the one or more programs are configured to execute the method described in the foregoing method embodiment.

[0113] The processor 410 may include one or more processing cores. The processor 410 uses various interfaces and lines to connect various parts of the entire computer device, and executes various functions of the computer device and processes data by running or executing instructions, programs, code sets or instruction sets stored in the memory 420, and calling data stored in the memory 420. Optionally, the processor 410 can be implemented in at least one hardware form of digital signal processing (DSP), field-programmable gate array (FPGA), and programmable logic array (PLA). The processor 410 can integrate one or a combination of a central processing unit (CPU), a graphics processing unit (GPU), and a modem. Among them, the CPU mainly processes the operating system, user interface, and application programs; the GPU is responsible for rendering and drawing display content; and the modem is used to process wireless communications. It can be understood that the above-mentioned modem may not be integrated into the processor 410, but may be implemented separately through a communication chip.

[0114] The memory 420 may include a random access memory (RAM) or a read-only memory (ROM). The memory 420 may be used to store instructions, programs, codes, code sets or instruction sets. The memory 420 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for implementing at least one function (such as a touch function, a sound playback function, an image playback function, etc.), instructions for implementing the following various method embodiments, etc. The data storage area may also store data (such as a phone book, audio and video data, chat record data) created by the computer device during use.

[0115] Please refer to Fig.11 , which shows a structural block diagram of a computer-readable storage medium provided in an embodiment of the present application. The computer-readable medium 800 stores program codes, which can be called by a processor to execute the method described in the above method embodiment.

[0116] The computer readable storage medium 800 may be an electronic memory such as a flash memory, an EEPROM (electrically erasable programmable read-only memory), an EPROM, a hard disk, or a ROM. Optionally, the computer readable storage medium 800 includes a non-transitory computer-readable storage medium. The computer readable storage medium 800 has storage space for program code 810 that performs any method step in the above method. These program codes can be read from or written to one or more computer program products. The program code 810 can be compressed, for example, in an appropriate form.

[0117] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit it. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements 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 the present application.

Claims

1. A hardware-in-the-loop testing method, characterized in that: Applied to a test device, the test device includes a simulation module group required to perform a plurality of different test tasks respectively; the method includes: In response to a target test instruction corresponding to a target test task, a task type flag corresponding to the target test task is determined, and a target simulation module group corresponding to the target test task is determined based on the task type flag, wherein the target simulation module group includes a simulation module for simulating simulation data corresponding to a target hardware function module, and the target hardware function module is a hardware function module required for the vehicle to perform the target test task; wherein the target test task includes any one of a full-stack test task, a regulatory control test task, and a state management test task, and the task type flag is used to uniquely identify the target test task; the simulation module group corresponding to the full-stack test task includes a video injection module, a laser point cloud injection module, a millimeter wave target injection module, and an ultrasonic target injection module, the simulation module group corresponding to the regulatory control test task includes a fusion lane line module and a fusion target module, and the simulation module group corresponding to the state management test task includes a state simulation module; Simulating the simulation data corresponding to the target hardware functional module based on the target simulation module group as target test data; Sending the task type flag and the target test data to a tested domain controller used in a vehicle, wherein the task type flag is used by the tested domain controller to determine the target test task to be performed, and the target test data is used by the tested domain controller to perform the target test task; Based on the control data fed back after the tested domain controller executes the target test task, the test result corresponding to the target test task is determined.

2. The method according to claim 1, characterized in that The control data includes execution data and observation data. The control data fed back after the tested domain controller executes the target test task, and determining the test result corresponding to the target test task, includes: Based on the observed data, determining whether the target test task is completed; If the target test task is completed, a test result corresponding to the target test task is determined based on the observed data; The method further comprises: If the target test task is not completed, the target test data is updated based on the execution data, and the step of sending the task type flag and the target test data to the domain controller under test used in the vehicle is returned until it is determined that the target test task is completed based on the observation data fed back by the domain controller under test.

3. The method according to claim 1, characterized in that: Sending the target test data to a domain controller under test used in a vehicle includes: Obtaining a communication method corresponding to the target test data; The target test data is sent to the domain controller under test through the communication method.

4. The method according to any one of claims 1 to 3, characterized in that: When sending the task type flag and the target test data to a domain controller under test used in a vehicle, the method further includes: Acquire positioning data synchronized with the target test data, wherein the positioning data is simulation data generated by a positioning simulation module of the vehicle; The positioning data is sent to the measured domain controller.

5. A hardware-in-the-loop testing method, characterized in that: Applicable to a tested domain controller used in a vehicle, the tested domain controller includes a plurality of processing module groups corresponding to the test tasks respectively; the method includes: Receive a task type flag and target test data sent by a test device, and determine a target test task to be performed based on the task type flag, wherein the target test data includes simulation data corresponding to a target hardware function module required for the vehicle to perform the target test task; Run the bypass shielding program corresponding to the target test task, the bypass shielding program is used to shield the processing modules other than the target processing module group corresponding to the target test task; wherein the target test task includes any one of a full-stack test task, a regulation and control test task, and a state management test task; the bypass shielding program corresponding to the full-stack test task is not used to shield any processing module, the bypass shielding program corresponding to the regulation and control test task is used to shield the perception module, and the bypass shielding program corresponding to the state management test task is used to shield the perception module, the decision module, and the regulation and control module; Based on the target test data, running the unshielded processing modules in the tested domain controller; Control data is generated based on processed data obtained after the target test data is processed by the unshielded processing module, and the control data is fed back to the test device. The control data is used by the test device to determine the test result corresponding to the target test task.

6. An electronic device, characterized in that: The electronic device comprises: one or more processors; Memory; 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, and the one or more programs are configured to execute the method according to any one of claims 1 to 4, or to execute the method according to claim 5.

7. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores program code, and the program code can be called by a processor to execute the method according to any one of claims 1 to 4, or to execute the method according to claim 5.

Images