CN117827555A - Hardware-in-loop test method and device, electronic equipment and storage medium - Google Patents
Hardware-in-loop test method and device, electronic equipment and storage medium Download PDFInfo
- Publication number
- CN117827555A CN117827555A CN202311570789.XA CN202311570789A CN117827555A CN 117827555 A CN117827555 A CN 117827555A CN 202311570789 A CN202311570789 A CN 202311570789A CN 117827555 A CN117827555 A CN 117827555A
- Authority
- CN
- China
- Prior art keywords
- test
- target
- data
- target test
- task
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000010998 test method Methods 0.000 title claims abstract description 23
- 238000012360 testing method Methods 0.000 claims abstract description 809
- 238000004088 simulation Methods 0.000 claims abstract description 164
- 238000000034 method Methods 0.000 claims abstract description 54
- 238000012545 processing Methods 0.000 claims description 78
- 238000004891 communication Methods 0.000 claims description 24
- 230000008569 process Effects 0.000 claims description 24
- 230000004044 response Effects 0.000 claims description 7
- 230000001360 synchronised effect Effects 0.000 claims description 7
- 238000007726 management method Methods 0.000 description 19
- 230000006870 function Effects 0.000 description 18
- 238000010586 diagram Methods 0.000 description 10
- 238000011161 development Methods 0.000 description 9
- 238000002347 injection Methods 0.000 description 8
- 239000007924 injection Substances 0.000 description 8
- 230000005540 biological transmission Effects 0.000 description 5
- 239000000243 solution Substances 0.000 description 5
- 230000008447 perception Effects 0.000 description 4
- 230000007547 defect Effects 0.000 description 3
- 230000004927 fusion Effects 0.000 description 3
- 230000003993 interaction Effects 0.000 description 3
- 230000001276 controlling effect Effects 0.000 description 2
- 230000001419 dependent effect Effects 0.000 description 2
- 238000011990 functional testing Methods 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 101100480851 Saccharomyces cerevisiae (strain ATCC 204508 / S288c) TDA4 gene Proteins 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 230000008878 coupling Effects 0.000 description 1
- 238000010168 coupling process Methods 0.000 description 1
- 238000005859 coupling reaction Methods 0.000 description 1
- 238000013523 data management Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- -1 etc. Proteins 0.000 description 1
- 239000011159 matrix material Substances 0.000 description 1
- 238000000691 measurement method Methods 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 230000001105 regulatory effect Effects 0.000 description 1
- 238000009877 rendering Methods 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 230000009897 systematic effect Effects 0.000 description 1
Abstract
The application discloses a hardware-in-the-loop test method, a hardware-in-the-loop test device, electronic equipment and a storage medium. According to the method, a task type mark corresponding to a target test task is determined by responding to a target test instruction corresponding to the target test task, target test data corresponding to the target test task is generated based on the task type mark, and the target test data comprises simulation data corresponding to a target hardware functional module required by a vehicle to execute the target test task; transmitting target test data to a domain controller under test used in a vehicle, the target test data being used for the domain controller under test to perform a target test task; and determining a test result corresponding to the target test task based on the control data fed back by the tested domain controller after the target test task is executed. Therefore, when the hardware-in-loop test is performed on the tested domain controller, the test equipment adaptively generates corresponding simulation data according to different test tasks, so that the flexibility and the test efficiency of the hardware-in-loop test can be improved, and the resource utilization rate can be improved.
Description
Technical Field
The present application relates to the field of vehicle control technologies, and in particular, to a hardware-in-the-loop test method, apparatus, electronic device, and storage medium.
Background
With the vigorous development of the intelligent driving automobile industry, the development of intelligent driving functions is in progress. Whereas the release of the intelligent driving function's landing and mass production software is strongly dependent on the functional test. The main functional test method at present depends on the real vehicle test, although the hardware in the loop test and the software test also gradually start to play a certain auxiliary role in the test. However, the current mainstream hardware-in-loop test method has low simulation test efficiency.
Disclosure of Invention
In view of the above problems, the present application provides a method, an apparatus, an electronic device, and a storage medium for testing hardware in a ring, which can adaptively generate corresponding simulation data according to different hardware in-ring testing tasks, thereby improving flexibility of hardware in-ring testing, and improving resource utilization and testing efficiency.
In a first aspect, an embodiment of the present application provides a hardware-in-loop testing method, applied to a testing device, where the method includes: responding to a target test instruction corresponding to a target test task, determining a task type mark corresponding to the target test task, and generating target test data corresponding to the target test task based on the task type mark, wherein the target test data comprises simulation data corresponding to a target hardware functional module required by a vehicle to execute the target test task; transmitting the target test data to a domain controller under test used in a vehicle, wherein the target test data is used for the domain controller under test to execute the target test task; and determining a test result corresponding to the target test task based on the control data fed back by the tested domain controller after the target test task is executed.
In a second aspect, an embodiment of the present application provides a hardware-in-the-loop test method applied to a domain controller under test used in a vehicle, the method including: receiving target test data corresponding to a target test task sent by test equipment, wherein the target test data comprises simulation data corresponding to a target hardware functional module required by a vehicle to execute the target test task; and executing the target test task based on the target test data, obtaining control data and feeding the control data back to the test equipment, wherein the control data is used for determining a test result corresponding to the target test task by the test equipment.
In a third aspect, an embodiment of the present application provides a hardware-in-loop testing apparatus, applied to a testing device, where the apparatus includes: the device comprises a data generation module, a data transmission module and a result determination module. The data generation module is used for responding to a target test instruction corresponding to a target test task, determining a task type mark corresponding to the target test task, and generating target test data corresponding to the target test task based on the task type mark, wherein the target test data comprises simulation data corresponding to a target hardware functional module required by a vehicle to execute the target test task; the data transmission module is used for transmitting the target test data to a tested domain controller used in a vehicle, wherein the target test data is used for the tested domain controller to execute the target test task; the result determining module is used for determining a test result corresponding to the target test task based on the control data fed back by the tested domain controller after the target test task is executed.
In a fourth aspect, embodiments of the present application provide a hardware-in-the-loop testing apparatus for a domain controller under test for use in a vehicle, the apparatus comprising: the system comprises a data receiving module and a task executing module, wherein the data receiving module is used for receiving target test data corresponding to a target test task sent by test equipment, and the target test data comprises simulation data corresponding to a target hardware functional module required by a vehicle for executing the target test task; the task execution module is used for executing the target test task based on the target test data, obtaining control data and feeding the control data back to the test equipment, wherein the control data is used for determining a test result corresponding to the target test task by the test equipment.
In a fifth aspect, embodiments of the present application provide an electronic device, including: 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, the one or more applications configured to perform the hardware-in-loop test method provided in the first aspect described above or the hardware-in-loop test method provided in the second aspect described above.
In a sixth aspect, embodiments of the present application provide a computer readable storage medium having stored therein program code that is capable of being invoked by a processor to perform the hardware-in-loop test method provided in the first aspect or the hardware-in-loop test method provided in the second aspect.
According to the scheme, a task type mark corresponding to a target test task is determined in response to a target test instruction corresponding to the target test task, target test data corresponding to the target test task is generated based on the task type mark, and the target test data comprises simulation data corresponding to a target hardware functional module required by a vehicle to execute the target test task; transmitting target test data to a domain controller under test used in a vehicle, the target test data being used for the domain controller under test to perform a target test task; and determining a test result corresponding to the target test task based on the control data fed back by the tested domain controller after the target test task is executed. Therefore, when the hardware-in-loop test is carried out on the tested domain controller used for the vehicle, the testing equipment adaptively generates corresponding simulation data according to different testing tasks, so that the flexibility of the hardware-in-loop test is improved, and the resource utilization rate and the testing efficiency are improved.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are needed in the description of the embodiments will be briefly introduced below, it being obvious that the drawings in the following description are only some embodiments of the present application, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.
Fig. 1 is a schematic flow chart of a hardware-in-loop test method according to an embodiment of the present application.
Fig. 2 is a schematic flow chart of a hardware-in-loop testing method according to another embodiment of the present application.
Fig. 3 is a schematic flowchart of step S240 in another embodiment of the present application.
FIG. 4 shows a schematic diagram of the interaction of hardware between the ring simulation platform and the domain controller under test in an embodiment of the present application.
Fig. 5 is a schematic flow chart of a hardware-in-loop testing method according to another embodiment of the present application.
Fig. 6 shows a specific flowchart of step S320 in yet another embodiment of the present application.
Fig. 7 is an overall flow diagram of a hardware-in-loop test method according to an embodiment of the present application.
Fig. 8 shows a block diagram of a hardware-in-the-loop test device according to an embodiment of the present application.
Fig. 9 shows a schematic structural diagram of another hardware-in-the-loop testing device according to an embodiment of the present application.
Fig. 10 shows a block diagram of an electronic device according to an embodiment of the present application.
Fig. 11 shows a block diagram of a computer-readable storage medium according to an embodiment of the present application.
Detailed Description
In order to enable those skilled in the art to better understand the present application, the following description will make clear and complete descriptions of the technical solutions in the embodiments of the present application with reference to the accompanying drawings in the embodiments of the present application.
In general, the function test on which the intelligent driving function of the vehicle depends on the floor generally comprehensively determines the effectiveness and safety of the intelligent driving function through various modes such as a software test, a hardware-in-the-loop test, a real vehicle test and the like. The hardware-in-loop test is to simulate the running state of a controlled object by running a simulation model through test equipment, and connect with a tested domain controller through an I/O interface to perform full-scale and systematic test on the tested domain controller. From the aspects of safety, feasibility and reasonable cost, hardware is an important ring in the development process of the domain controller for realizing the intelligent driving function of the vehicle in ring test, so that the number of times of real vehicle road tests can be reduced, the development time can be shortened, the development cost can be reduced, the software quality of the domain controller can be improved, and the risk of a vehicle enterprise can be reduced.
However, currently, the main hardware-in-the-loop test methods mainly comprise three methods: the method comprises the steps of data recharging open-loop test, full stack closed-loop test and regular control closed-loop test. The data recharging open-loop test method is strongly dependent on real vehicle data and mainly aims at sensing tests, full stack software cannot be covered, distortion phenomenon can occur in input of a sensing module once the vehicle position changes, and closed-loop tests cannot be well achieved; the full stack closed loop test method can cover all functional modules of the vehicle and can realize closed loop test, but the data volume of the perception simulation is large, the resource requirement is higher and the performance of the perception module is limited; the regular closed loop test method can bypass the sensing module to directly simulate the fusion target, has low resource requirements, but the test method cannot cover the testing of the sensing module and other modules, cannot support the testing of integrated version software, and is difficult to meet various test requirements. Therefore, the existing method for realizing the hardware-in-the-loop simulation test cannot always consider a plurality of different test tasks at the same time, and the test efficiency is low.
Therefore, the application provides a hardware-in-loop test method, a device, electronic equipment and a storage medium, and when the hardware-in-loop test is carried out on a tested domain controller used in a vehicle, the test equipment adaptively generates corresponding simulation data according to different test tasks, so that the flexibility of the hardware-in-loop test can be improved, and the resource utilization rate and the test efficiency can be improved. The specific hardware in the ring test method is described in detail in the following embodiments.
Referring to fig. 1, fig. 1 shows a flow chart of a hardware-in-loop testing method according to an embodiment of the present application, and the flow chart shown in fig. 1 will be described in detail, where the hardware-in-loop testing method is applied to a testing device, and may specifically include the following steps:
step S110: and determining a task type mark corresponding to the target test task in response to a target test instruction corresponding to the target test task, and generating target test data corresponding to the target test task based on the task type mark, wherein the target test data comprises simulation data corresponding to a target hardware functional module required by the vehicle for executing the target test task.
In the embodiment of the application, different test tasks can correspond to different test instructions, a technician can input a corresponding target test instruction to test equipment according to actual requirements, and the test equipment can firstly determine a task type mark corresponding to the target test task after receiving the target test instruction, wherein the task type mark can uniquely identify the test task. After determining the task type mark corresponding to the target test task, the test equipment can determine the target hardware functional module required by the vehicle to execute the target test task based on the task type mark, and further generate target test data corresponding to the target test task based on the simulation module used for simulating the target hardware functional module in the test equipment.
It will be appreciated that the test apparatus may support the execution of a plurality of different test tasks, and thus the test apparatus may include a simulation module of the hardware functional modules required to execute the plurality of different test tasks, respectively. In order to facilitate the rapid generation of target test data required for executing a target test task after receiving a target test instruction, the test device may determine all simulation modules required for executing the target test task according to task type marks corresponding to the target test task and correspondence between prestored different task type marks and simulation modules corresponding to hardware function modules, and further rapidly generate the target test data based on the simulation modules.
In some embodiments, the test equipment may be simulation software such as DSPACE, IPG/CarMaker. The simulation software is provided with simulation modules corresponding to hardware functional modules existing in the real vehicles such as a vehicle power unit, a sensor, a camera or a laser radar. The technician can build a simulation vehicle of the target configuration based on the simulation modules in the test equipment and connect the test equipment with the domain controller under test. The test equipment can generate corresponding simulation data through the simulation module and send the corresponding simulation data to the tested domain controller, and the tested domain controller regards the simulation data as real vehicle data to judge the corresponding running state of the vehicle simulated by the test equipment and feeds back control data to the test equipment so as to control the simulated vehicle to realize the target test task. In the process, the test equipment can find possible defects in the control program of the tested domain controller, and realize the hardware-in-loop simulation test of the tested domain controller.
In some implementations, the test tasks that the test device may receive may include full stack test tasks, regulatory test tasks, and state management test tasks. The full stack test task mainly aims at full stack test including a perception module; the rule control test task mainly aims at rule control test; the state management test task is mainly aimed at rapidly testing state interaction logic between a state management module in a micro control unit (Microcontroller Unit, MCU) in a tested domain controller and an application module process in a System On Chip (SOC).
Specifically, the test data required by the tested domain controller to execute different test tasks are different, so that the test data generated by the test equipment according to the different test tasks are also different, that is, the test equipment can control different simulation modules to generate corresponding test data according to the different test tasks. Thus, in order to facilitate the test device to generate target test data related to a target test task, the test device may previously aggregate all simulation modules corresponding to all test data required for the same test task into one simulation module group. If the test equipment receives a specific target test indicating execution of a target test task, a task type mark corresponding to the target test task can be directly used for determining a simulation module group corresponding to the target test task, and target test data required by the target test task is generated according to all simulation modules included in the simulation module group. It can be appreciated that the test device generates corresponding different groups of simulation modules for different test tasks, whereby the test device can also generate different test data adaptively for different test tasks. Therefore, the test equipment can support to realize various different test tasks through a plurality of different pre-configured simulation module groups, and can adaptively match corresponding simulation resources according to the different test tasks, meanwhile, the generated test data does not need to depend on real vehicle data, and hardware-in-loop test based on the local simulation data is realized.
In some embodiments, the target test instruction may be received by the test device from an externally connected task management platform, where the task management platform may be a cloud server or a local jira system. Specifically, the task management platform may send a corresponding target test instruction to the test device according to preset timing, or may issue the target test instruction in real time according to the operation of the technician.
In some embodiments, the task type mark corresponding to the target test task may be a task type mark corresponding to the target test task, where the task type mark is sent by the task management platform to the test device along with the target test instruction, and the test device may parse the target test instruction to obtain the task type mark corresponding to the target test task; the test device may generate a corresponding task type flag capable of uniquely identifying 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, in the process of generating the corresponding target test data and sending the target test data to the domain controller to be tested, the test device may also send the task type flag corresponding to the target test task to the domain controller to be tested synchronously, so that the domain controller to be tested may also determine the target test task to be executed directly based on the task type flag.
Step S120: and sending target test data to a tested domain controller used in the vehicle, wherein the target test data is used for the tested domain controller to execute target test tasks.
In the embodiment of the application, after generating the target test data corresponding to the target test task, the test equipment may send the target test data to the domain controller to be tested, where the domain controller to be tested is a controller used in the vehicle to control the vehicle to implement various intelligent driving functions, and after receiving the target test data, the domain controller to be tested may execute the target test task based on the target test data.
Obviously, the vehicle can realize various intelligent driving functions, namely, the domain controller is written with a control program in advance by a technician, and the domain controller can acquire real-time data of the vehicle from each sensor by running the control program, judge the current running state of the vehicle according to the real-time data and further control the vehicle to realize the intelligent driving function. Therefore, before the domain controller is actually used in the vehicle, a technician can use the domain controller as a detected domain controller, and judge whether a control program in the detected domain controller can normally run or not and whether the vehicle can be controlled to stably realize the intelligent driving function or not through the test equipment.
Specifically, after receiving the target test instruction, the test device may generate target test data corresponding to the target test task, and send the target test data to the tested domain controller, where the tested domain controller may determine the current running state of the vehicle simulated by the test device according to the target test data, and control the test device to execute the target test task.
In some embodiments, the domain controller under test may be a data center platform (Mobile Data Center, MDC) for autopilot, a texas instruments generated chip TDA4, etc., and an MDC integrated development environment may be included in the domain controller under test, so that a technician may add a special executable program to the domain controller under test through the integrated development environment.
In other embodiments, the domain under test controller may further include a communication management module, configured to receive the target test data sent in the test device and a task type flag corresponding to the target test task.
In some embodiments, a plurality of different sets of processing modules may be included in the domain under test controller, each set of processing modules being operable to process execution of a different test task. After receiving the task type mark sent by the test equipment, the tested domain controller can determine a target test task to be executed based on the task type mark, and determine a target processing module group corresponding to the target test task. In particular, a plurality of different processing modules may be included in each processing module group, each processing module being capable of performing a portion of the operations of the test task. Wherein the same processing module may be present in different groups of processing modules. For example, the fault-monitoring module may process test data in a state-management test task, or may process test data in a regular test task.
Step S130: and determining a test result corresponding to the target test task based on the control data fed back by the tested domain controller after the target test task is executed.
In the embodiment of the application, the domain under test controller can execute the target test task based on the target test data sent by the test equipment, and the domain under test controller can realize the function of executing the target test task by feeding back the control data to the test equipment. Specifically, the tested domain controller can determine the running state of the vehicle simulated by the current test equipment according to the target test data, and further determine the operation to be executed next by each simulation module on the test equipment according to the target test task, and the operation is realized by feeding back control data to the test equipment. The control data fed back to the test equipment by the tested domain controller not only comprises an execution instruction for controlling each simulation module in the test equipment to perform the next step, but also comprises observation data of the execution condition of the current tested domain controller on the target test task. That is, the test device may not only control the simulation module to execute a corresponding operation based on execution data in the control data fed back by the domain controller to be tested, but also determine whether the current target test task is completed based on observation data in the control data, and determine a test result corresponding to the target test task.
According to the hardware-in-loop test method, the task type mark corresponding to the target test task is determined by responding to the target test instruction corresponding to the target test task, and target test data corresponding to the target test task is generated based on the task type mark, wherein the target test data comprises simulation data corresponding to a target hardware functional module required by a vehicle to execute the target test task; transmitting target test data to a domain controller under test used in a vehicle, the target test data being used for the domain controller under test to perform a target test task; and determining a test result corresponding to the target test task based on the control data fed back by the tested domain controller after the target test task is executed. Therefore, when the hardware-in-loop test is carried out on the tested domain controller used for the vehicle, the test equipment can adaptively generate corresponding simulation data according to different test tasks, so that the flexibility of the hardware-in-loop test can be improved, and the resource utilization rate and the test efficiency can be improved.
Referring to fig. 2, fig. 2 is a schematic flow chart of a hardware-in-loop testing method according to another embodiment of the present application, and the detailed description will be given below with respect to the flow chart shown in fig. 2, where the hardware-in-loop testing method is applied to a testing device, and may specifically include the following steps:
Step S210: and responding to the target test instruction, determining a task type mark corresponding to the target test task, and determining a target simulation module group corresponding to the target test task based on the task type mark, wherein the target simulation module group comprises simulation modules for simulating simulation data corresponding to the target hardware functional modules.
In an embodiment of the present application, a plurality of different simulation module groups may be included in the test apparatus, each simulation module group corresponds to simulation data required for generating a different test task, and each simulation module group is correspondingly associated with a different task type flag. Therefore, after receiving the target test instruction corresponding to the target test task, the test equipment can firstly determine the task type mark corresponding to the target test task, and then directly determine the target simulation module group based on the task type mark, so that target test data required for executing the target test task can be generated directly based on the target simulation module group.
It can be understood that the test device can support a plurality of different test tasks, the test data required by the tested domain controller to be used for reference is different in the execution process of the different test tasks, and meanwhile, even if the real vehicle executes the target test task, a plurality of different hardware functional modules are usually required to be matched with each other to realize the target test task. Therefore, in order to be able to adapt to different test tasks, the test device can quickly generate test data corresponding to the test tasks, and all simulation modules for generating the test data required by the test tasks can be assembled into a simulation module group in advance for each test task, wherein each simulation module in the test device is a simulation model for a certain hardware functional module of the vehicle.
Step S220: based on the target simulation module group, simulation data corresponding to the target hardware functional module is simulated to serve as target test data.
In the embodiment of the present application, after determining the corresponding target simulation module group based on the target test task, the test device may 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 test data required by the target test task, and the combination of the test data respectively simulated by each simulation module in the target simulation module group can obtain the target test data corresponding to the target test task.
In some embodiments, since the test device and the tested domain controller cannot complete the target test task at one time, the test device needs to update the test data continuously in a loop manner, that is, the test device updates the test data continuously through the simulation module and sends the test data to the tested domain controller, and the tested domain controller determines the control data of each simulation module included in the test device based on the test data updated in real time and the target test task and feeds back the control data to the test device, and 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 tested domain controller again, thereby realizing the effect of the hardware-in-loop simulation test. Therefore, in the process of executing the target test task, the target simulation module group in the test equipment can respond to the initial target test instruction and also can respond to the execution data in the control data fed back by the tested domain controller to generate simulation data corresponding to the target hardware functional module as target test data.
Step S230: and acquiring positioning data synchronous with the target test data, wherein the positioning data is simulation data generated by a positioning simulation module of the vehicle.
In the embodiment of the application, after the test equipment obtains the target test data corresponding to the target test task based on the simulation of the target simulation module group, the positioning simulation module can also respond to the target test instruction to generate the positioning data corresponding to the target test task. The positioning data and the target test data generated by the target simulation module group are synchronous, namely the positioning data and the target test data can represent data of vehicles simulated by the test equipment in different aspects at the same time. The positioning data can represent the position and posture data of the vehicle simulated by the test equipment in a 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 equipment.
In some embodiments, 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 in response to execution data in the control data fed back by the domain controller under test.
Step S240: and sending the target test data and the positioning data to the tested domain controller.
In the embodiment of the application, after the test equipment 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 the synchronous positioning data thereof can be sent to the tested domain controller, so that the tested domain controller can determine the current state of the vehicle simulated by the test equipment based on the data generated by the simulation modules, and further execute the target test task.
In some embodiments, as shown in fig. 3, the test equipment may send the target test data to the domain under test controller by:
step S241: and acquiring a communication mode corresponding to the target test data.
In this embodiment of the present application, each simulation module included in the target simulation module group is configured to generate test data to obtain target test data, where data types corresponding to the simulation data generated by different simulation modules may be different, and a transmission manner in which the test data of different data types is transmitted between the test device and the domain controller to be tested is not necessarily the same. Therefore, the test equipment can pre-configure the corresponding simulation module group aiming at different test tasks and pre-configure the communication modes respectively corresponding to the simulation modules included in the simulation module group.
Specifically, as shown in fig. 4, if the task management platform issues the test tasks to the test device, the test tasks include three types: if the test device can configure the corresponding simulation module group 1 for the full stack test task, the corresponding simulation module group 2 for the regular test task and the corresponding simulation module group 3 for the state management test task in advance. The simulation module group 1 may include simulation modules such as a video injection module, a laser point cloud injection module, a millimeter wave target injection module, and an ultrasonic target injection module. The video injection module is used for generating video data corresponding to a simulation scene where the vehicle simulated by the test equipment is located, and the test equipment can pre-configure a communication mode corresponding to the simulation module to be converted into a gigabit multimedia serial link (Gigabit Multimedia Serial Links, GMSL) through a high-definition multimedia interface (High Definition Multimedia, HDMI) and send the gigabit multimedia serial link to the tested domain controller; the laser point cloud injection module is used for generating simulation point cloud data, and the testing equipment can pre-configure a communication mode corresponding to the simulation module to send the simulation point cloud data to the tested domain controller in a user datagram protocol (User Datagram Protocol, UDP) mode; the millimeter wave target injection module and the ultrasonic target injection module are respectively used for generating millimeter wave target information and ultrasonic target information, and the testing equipment CAN pre-configure the communication modes corresponding to the two simulation modules into target data defined according to a transmission matrix through controller area network bus (Controller Area Network, CAN) communication to a tested domain controller.
The simulation module group 2 may include a lane line fusion module, a target fusion module, and other simulation modules, and both of the two simulation modules may generate test data according to a format of an interface description language (Interface Description Language, IDL) predefined by the domain controller under test when generating the test data. The test equipment can configure the communication mode corresponding to the simulation module in advance to send the communication mode to the tested domain controller in a UDP mode.
The simulation module group 3 may include a state simulation module, configured to fill state information according to an IDL format predefined by the domain controller to be tested, so as to obtain test data. The test equipment can pre-configure the corresponding communication mode to send to the tested domain controller in a UDP mode.
In some embodiments, the test device may further include a data management module, configured to adaptively switch, according to the target test instruction, a target simulation module group that is matched with the target test task, and control a domain controller to be tested that sends the target test data generated by the target simulation module group and a task type flag corresponding to the target test task.
Step S242: and sending the target test data to the tested domain controller in a communication mode.
In this embodiment of the present application, after the test device generates test data based on each simulation module included in the target simulation module group, the test device may send the test data generated by each simulation module to the domain controller to be tested based on the communication mode corresponding to each simulation module configured in advance, so that the domain controller to be tested may execute the target test task based on the target test data.
In some embodiments, the test device may further send the positioning data generated synchronously by the positioning simulation module to the tested domain controller along with the target test data, where the test device may also pre-configure a communication mode corresponding to the positioning simulation module. Specifically, the positioning simulation module is used for generating position and posture data corresponding to the vehicle simulated by the device and WGS84 longitude and latitude data of the simulated vehicle relative to the Open Drive map. The testing device may configure its corresponding communication mode in advance to send to the domain controller under test in a mode of someip.
Step S250: based on the observation data, it is determined whether to perform the completion target test task.
In the embodiment of the application, the control data includes execution data and observation data. The observed data are data which are fed back to the test equipment by the tested domain controller and are used for representing the execution condition or execution progress of the current target test task. The test equipment can judge whether the target test task is executed and completed or not based on the observation data fed back by the tested domain controller, namely, whether the test data output by the simulation module is required to be further updated or not is determined and sent to the tested domain controller.
Step S260: if the target test task is not executed, updating the target test data based on the execution data, and returning to the step of sending the target test data to the tested domain controller used in the vehicle until the execution of the target test task is determined to be completed based on the observation data fed back by the tested domain controller.
In this embodiment of the present application, if the test device determines, based on the observation data, that the domain controller to be tested has not currently performed to complete the target test task, then the test device may control, based on the execution data fed back by the domain controller to be tested, the target simulation module group corresponding to the target test task to generate updated target test data, and send the updated target test data to the domain controller to be tested again, so as to implement closed loops of the test data and the perceived scene.
The execution data is an operation instruction which is determined to be executed by each simulation module in the test equipment next according to the execution condition of the target test task after the tested domain controller determines the current running state of the simulated vehicle based on the target test data acquired from the test equipment.
In some embodiments, if the test device determines that the target test task is not performed, the target test data may be updated not only by the target simulation module group corresponding to the target test task, but also by the positioning simulation module. The test equipment may then send the updated target test data and the positioning data synchronized therewith to the domain under test controller.
Step S270: and if the target test task is executed, determining a test result corresponding to the target test task based on the observation data.
In this embodiment of the present application, if the test device determines that the target test task has been executed based on the observation data, the test device may determine, based on the observation data, an execution condition of the target test task, that is, determine whether the domain controller to be tested executes the target test task according to the expected requirement.
In some embodiments, if the test device determines that the target test task is executed, but there is a defect in the execution process, the test device may output a defect prompt message to inform a technician to make a corresponding modification to the running program in the domain controller under test.
According to the hardware-in-loop test method, task type marks corresponding to target test tasks are determined by responding to target test instructions, and target simulation module groups corresponding to the target test tasks are determined based on the task type marks; based on the target simulation module group, simulating simulation data corresponding to the target hardware functional module to serve as target test data; positioning data synchronous with the target test data are obtained, and the target test data and the positioning data are sent to a tested domain controller; and determining whether to execute the target test task based on the observation data, updating the target test data based on the execution data if the target test task is not executed, and returning to the step of sending the target test data to the tested domain controller used in the vehicle until the execution completion target test task is determined based on the observation data fed back by the tested domain controller, and determining a test result corresponding to the target test task based on the observation data if the target test task is executed. By configuring corresponding simulation module groups aiming at different test tasks, the self-adaptive closed-loop test of the different test tasks is realized on the basis of the existing simulation modules, the expandability of the test tasks is enhanced, and the test efficiency and the utilization rate of simulation module resources are improved.
Referring to fig. 5, fig. 5 is a schematic flow chart of a hardware-in-loop testing method according to another embodiment of the present application, and the flow chart shown in fig. 5 will be described in detail, where the hardware-in-loop testing method is applied to a domain controller under test in a vehicle, and may specifically include the following steps:
step S310: and receiving target test data corresponding to a target test task sent by the test equipment, wherein the target test data comprises simulation data corresponding to a target hardware functional module required by the vehicle to execute the target test task.
In the embodiment of the application, after receiving the target test data sent by the test equipment, the tested domain controller can determine the running state of the vehicle simulated by the test equipment in the simulation scene according to the target test data. And determining whether each simulation module on the test equipment needs to be controlled to execute new processing operation according to the execution progress corresponding to the target test task.
In some embodiments, a communication management (Communication Management, CM) module may be preconfigured in the domain controller under test to receive the target test data and the positioning data sent by the test device through different communication modes.
In some implementations, a technician may write an executable program in the domain under test controller through the MDC integrated development environment (Development Studio). The domain under test controller performs the target test task by running an executable program.
Step S320: and executing the target test task based on the target test data, obtaining control data and feeding the control data back to the test equipment, wherein the control data is used for determining a test result corresponding to the target test task by the test equipment.
In the embodiment of the application, after receiving the target test data, the domain under test controller may execute the target test task based on the target test data. In general, the tested domain controller executes the target test task by controlling the target hardware functional module simulated by each simulation module in the test equipment to execute corresponding operation according to the task requirement, so that the vehicle simulated by the test equipment realizes corresponding intelligent driving function. Therefore, in the process of executing the target test task by the tested domain controller, the control data needs to be fed back to the test equipment continuously to instruct the test equipment to control the corresponding simulation module to execute the corresponding operation, and the output simulation data is updated to serve as updated target test data. The test equipment can send the updated target test data to the tested domain controller again, so that the closed loop of the test data is realized.
In some embodiments, the test device may further send a task type flag corresponding to the target test task to the domain-to-be-tested controller along with the target test data, and the domain-to-be-tested controller may determine the target test task to be executed based on the received task type flag.
In some embodiments, as shown in fig. 6, the domain under test controller may perform the target test tasks by:
step S321: and running a bypass shielding program corresponding to the target test task, wherein the bypass shielding program is used for shielding the processing modules except the target processing module group.
In the embodiment of the application, since the test equipment can adaptively generate different test data for a plurality of different test tasks, the tested domain controller can determine the target test tasks to be executed only after receiving the target test data, and a plurality of different processing modules capable of supporting all the test tasks are actually deployed in the tested domain controller. Therefore, in order to better perform the target test task independently, the domain controller to be tested may run a bypass shielding program corresponding to the target test task after receiving the target test data, so as to shield other processing modules except for the target processing module group, where the target processing module group includes processing modules required for performing the target test task. Therefore, the tested domain controller can ensure that the tested domain controller is not interfered by other execution modules in the process of executing the target test task later through the bypass shielding module. Meanwhile, aiming at different target test tasks, the tested domain controller can shield other processing modules through corresponding different bypass shielding programs, so that the flexibility and the resource utilization rate of each processing module in the tested domain controller are improved.
In some embodiments, the domain controller under test may further include a data conversion program for converting the target test data received directly from the test device into data recognizable by the processing module. Specifically, the target test data directly sent in the test equipment is simulation data generated by a simulation module, and the target test data obtained after being converted by a data conversion program is abstract data which can be identified by a target processing module corresponding to the execution target test task.
In some embodiments, if the target test task is a full stack test task, then the domain controller under test may not run the bypass mask program at this time, or the bypass mask module corresponding to the full stack test task may not actually mask any processing module. Because performing a full stack test task requires running each of the processing modules, including the sensing module, included in the domain controller under test. If the target test task is a regular test task or a state management test task, the tasks are executed without operating a sensing module in the tested domain controller, so that a processing module which is not required to be used in the process of executing the target test task can be shielded by operating a bypass shielding program before executing the tasks.
Step S322: and running a target processing module group corresponding to the target test task based on the target test data, wherein the target processing module group is used for processing the target test data.
In this embodiment of the present application, after obtaining target test data corresponding to a target test task, a domain under test controller may run a target processing module group corresponding to the target test task based on the target test data, where the target processing module group includes at least one processing module, and each processing module may process part of data in the target test data to obtain processing data, so that the domain under test controller may determine an operation state of a vehicle simulated by the test device based on the processing data obtained by each processing module in the target processing module group, and generate corresponding control data based on the target test task.
In particular, the domain under test controller may run unshielded processing modules in the domain under test controller based on the target test data. That is, after the tested domain controller passes through the bypass shielding program corresponding to the target test task, all the processing modules irrelevant to the execution of the target test task are already shielded, so that the tested domain controller can directly run all the processing modules which are not shielded at the moment, namely, the target processing module group corresponding to the execution of the target test task.
In some embodiments, referring again to fig. 4, where the test tasks include a full stack test task, a regular test task, and a state management test task, three different sets of processing modules, namely set 1, set 2, and set 3, may be included in the domain controller under test. Wherein, the processing module group 1 corresponds to a full stack test task, so that all processing modules including the perception module are included; the processing module group 2 corresponds to the rule control test task and is mainly aimed at rule control test, so that the sensing module is shielded; the processing module group 3 corresponds to a state management test task, and is mainly used for rapidly testing state interaction logic between a state management module in the MCU and an application module process in the SOC, so that a sensing module, a decision module, a regulation module and the like can be shielded.
Step S323: and generating control data based on the processing data obtained after the target processing module group processes the target test data, and feeding back the control data to the test equipment.
In the embodiment of the application, the tested domain controller runs the target processing module group corresponding to the target test task to generate control data and feed the control data back to the test equipment, further receives the target test data updated by the test equipment through the target simulation module group, realizes the closed loop of the test data, further continuously executes the target test task until the test equipment determines that the execution of the target test task is completed through the control data fed back by the tested domain controller, and determines an execution result.
In some embodiments, the domain under test controller may feed back control data to the test device through communication with the CAN bus. The control data fed back by the tested domain controller may include observation data and execution data, where the execution data is a request for instructing a simulation module in a target simulation module group in the test apparatus to perform a corresponding operation and update the test data, and may include, for example, a steering wheel angle request, an accelerator pedal request, a brake pedal request, a motor torque request, and the like. The execution data is also used for indicating a vehicle dynamics module in the test equipment to update and send pose data of the simulated vehicle.
According to the hardware-in-loop test method, target test data corresponding to a target test task sent by test equipment are received; operating a bypass shielding program corresponding to the target test task; operating a target processing module group corresponding to the target test task based on the target test data; and generating control data based on the processing data obtained after the target processing module group processes the target test data, and feeding back the control data to the test equipment. Therefore, the tested domain controller can adaptively operate the corresponding processing module based on different target test tasks, and the tested domain controller can support a plurality of different test tasks by shielding the processing module irrelevant to the target test tasks, so that the expansibility of the test tasks is enhanced, and the test efficiency and the resource utilization rate are improved.
In general, referring to fig. 7, an overall flow chart of a hardware-in-loop color measurement method provided in an embodiment of the present application is shown. Firstly, the test equipment receives a target test task sent by a task management platform, and under the condition that the test tasks capable of being supported comprise a full stack test task, a rule test task and a state management test task, the test equipment can sequentially judge which test task the target test task belongs to and determine a target simulation module group corresponding to the target test task based on a task type mark corresponding to the target test task. And then the test equipment can obtain target test data through simulation of the target simulation module group and send the target test data to the tested domain controller. After receiving the target test data, the domain controller to be tested can also judge the target processing module group corresponding to the target test task to be executed. And then, running all the processing modules in the target processing module group to obtain control data and feeding the control data back to the test equipment, wherein the control data comprises observation data and execution data which are used for indicating the test equipment to update the position and posture data corresponding to the simulated vehicle. Therefore, closed loop testing is realized until the testing equipment finally determines that the tested domain controller executes the target testing task.
Referring to fig. 8, a block diagram of a hardware-in-loop testing apparatus 200 according to an embodiment of the present application is shown, where the hardware-in-loop testing apparatus 200 is applied to a testing device, and includes: a data generation module 210, a data transmission module 220, and a result determination module 230. The data generating module 210 is configured to determine a task type flag corresponding to a target test task in response to a target test instruction corresponding to the target test task, and generate target test data corresponding to the target test task based on the task type flag, where the target test data includes simulation data corresponding to a target hardware functional module required by the vehicle to execute the target test task; the data transmitting module 220 is configured to transmit target test data to a domain controller under test used in a vehicle, where the target test data is used for the domain controller under test to perform a target test task; the result determining module 230 is configured to determine a test result corresponding to the target test task based on the control data fed back by the tested domain controller after the target test task is executed.
As one possible implementation, the result determining module 230 is further configured to determine whether to perform the completion target test task based on the observation data; if the target test task is not executed, updating target test data based on the execution data, and returning to the step of sending the target test data to a tested domain controller used in the vehicle until the execution of the target test task is determined to be completed based on the observation data fed back by the tested domain controller; and if the target test task is executed, determining a test result corresponding to the target test task based on the observation data.
As a possible implementation manner, the target test instruction corresponding to the target test task is responded. The data generating module 210 is further configured to determine a task type flag corresponding to the target test task in response to the target test instruction, and determine a target simulation module group corresponding to the target test task based on the task type flag, where the target simulation module group includes a simulation module for simulating simulation data corresponding to the target hardware functional module; based on the target simulation module group, simulation data corresponding to the target hardware functional module is simulated to serve as target test data.
As a possible implementation manner, the data sending module 220 is further configured to obtain a communication manner corresponding to the target test data; and sending the target test data to the tested domain controller in a communication mode.
As a possible implementation manner, the data sending module 220 is further configured to obtain positioning data synchronized with the target test data, where the positioning data is simulation data generated by the positioning simulation module of the vehicle; and sending the target test data and the positioning data to the tested domain controller.
Referring to fig. 9, a block diagram of a hardware-in-loop testing apparatus 300 according to an embodiment of the present application is shown, and the hardware-in-loop testing apparatus 300 is applied to a domain controller under test used in a vehicle, and includes: the data receiving module 310 and the task executing module 320. The data receiving module 310 is configured to receive target test data corresponding to a target test task sent by a test device, where the target test data includes simulation data corresponding to a target hardware functional module required by a vehicle to execute the target test task; the task execution module 320 is configured to execute a target test task based on the target test data, obtain control data, and feed back the control data to the test device, where the control data is used by the test device to determine a test result corresponding to the target test task.
As a possible implementation manner, the task execution module 320 is further configured to run a target processing module group corresponding to the target test task based on the target test data, where the target processing module group is configured to process the target test data; and generating control data based on the processing data obtained after the target processing module group processes the target test data, and feeding back the control data to the test equipment.
As a possible implementation manner, the task execution module 320 is further configured to run a bypass mask program corresponding to the target test task, where the bypass mask program is configured to mask processing modules other than the target processing module group; based on the target test data, unmasked processing modules in the domain under test controller are run.
It will be clearly understood by those skilled in the art that, for convenience and brevity of description, the specific working process of the apparatus and modules described above may refer to the corresponding process in the foregoing method embodiment, which is not repeated herein.
In several embodiments provided herein, the coupling of the modules to each other may be electrical, mechanical, or other.
In addition, each functional module in each embodiment of the present application may be integrated into one processing module, or each module may exist alone physically, or two or more modules may be integrated into one module. The integrated modules may be implemented in hardware or in software functional modules.
In summary, according to the scheme provided by the application, the task type mark corresponding to the target test task is determined by responding to the target test instruction corresponding to the target test task, and the target test data corresponding to the target test task is generated based on the task type mark, wherein the target test data comprises simulation data corresponding to a target hardware functional module required by the vehicle to execute the target test task; transmitting target test data to a domain controller under test used in a vehicle, the target test data being used for the domain controller under test to perform a target test task; and determining a test result corresponding to the target test task based on the control data fed back by the tested domain controller after the target test task is executed. Therefore, when the hardware-in-loop test is carried out on the tested domain controller used for the vehicle, the testing equipment adaptively generates corresponding simulation data according to different testing tasks, so that the flexibility of the hardware-in-loop test is improved, and the resource utilization rate and the testing efficiency are improved.
Referring to fig. 10, a block diagram of an electronic device 400 according to an embodiment of the present application is shown. 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 application programs, wherein the one or more application programs may be stored in the memory 420 and configured to be executed by the one or more processors 410, the one or more program(s) configured to perform the method as described in the foregoing method embodiments.
Processor 410 may include one or more processing cores. The processor 410 utilizes various interfaces and lines to connect various portions of the overall computer device, perform various functions of the computer device, and process data by executing or executing instructions, programs, code sets, or instruction sets stored in the memory 420, and invoking data stored in the memory 420. Alternatively, the processor 410 may be implemented in hardware in at least one of digital signal processing (Digital Signal Processing, DSP), field programmable gate array (Field-Programmable Gate Array, FPGA), programmable logic array (Programmable Logic Array, PLA). The processor 410 may integrate one or a combination of several of a central processing unit (Central Processing Unit, CPU), a graphics processor (Graphics Processing Unit, GPU), and a modem, etc. The CPU mainly processes an operating system, a user interface, an application program and the like; the GPU is used for being responsible for rendering and drawing of display content; the modem is used to handle wireless communications. It will be appreciated that the modem may not be integrated into the processor 410 and may be implemented solely by a single communication chip.
The Memory 420 may include a random access Memory (Random Access Memory, RAM) or a Read-Only Memory (Read-Only Memory). Memory 420 may be used to store instructions, programs, code sets, or instruction sets. The memory 420 may include a stored program area and a stored data area, wherein the stored program area may store instructions for implementing an operating system, instructions for implementing at least one function (e.g., a touch function, a sound playing function, an image playing function, etc.), instructions for implementing the various method embodiments described below, etc. The storage data area may also store data created by the computer device in use (e.g., phonebook, audio-video data, chat-record data), etc.
Referring to fig. 11, a block diagram of a computer readable storage medium according to an embodiment of the present application is shown. The computer readable medium 800 has stored therein program code which can be invoked by a processor to perform the methods described in the method embodiments described above.
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 comprises a non-volatile computer readable medium (non-transitory computer-readable storage medium). The computer readable storage medium 800 has storage space for program code 810 that performs any of the method steps described above. The program code can be read from or written to one or more computer program products. Program code 810 may be compressed, for example, in a suitable form.
Finally, it should be noted that: the above embodiments are only for illustrating the technical solution of the present application, and are not limiting thereof; although the present application has been described in detail with reference to the foregoing embodiments, one of ordinary skill in the art will appreciate that: the technical scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; such modifications and substitutions do not drive the essence of the corresponding technical solutions to depart from the spirit and scope of the technical solutions of the embodiments of the present application.
Claims (11)
1. A method of hardware-in-the-loop testing, characterized by being applied to a test device, the method comprising:
responding to a target test instruction corresponding to a target test task, determining a task type mark corresponding to the target test task, and generating target test data corresponding to the target test task based on the task type mark, wherein the target test data comprises simulation data corresponding to a target hardware functional module required by a vehicle to execute the target test task;
transmitting the target test data to a domain controller under test used in a vehicle, wherein the target test data is used for the domain controller under test to execute the target test task;
And determining a test result corresponding to the target test task based on the control data fed back by the tested domain controller after the target test task is executed.
2. The method according to claim 1, wherein the control data includes execution data and observation data, and the determining, based on the control data fed back by the domain under test controller after executing the target test task, a test result corresponding to the target test task includes:
determining whether to perform the target test task based on the observed data;
if the target test task is not executed, updating the target test data based on the execution data, and returning to the step of sending the target test data to a tested domain controller used in a vehicle until the execution of the target test task is determined to be completed based on the observation data fed back by the tested domain controller;
and if the target test task is executed, determining a test result corresponding to the target test task based on the observation data.
3. The method of claim 1, wherein the determining, in response to the target test instruction corresponding to the target test task, 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, comprises:
Responding to the target test instruction, determining a task type mark corresponding to the target test task, and determining a target simulation module group corresponding to the target test task based on the task type mark, wherein the target simulation module group comprises simulation modules for simulating simulation data corresponding to the target hardware functional modules;
and simulating simulation data corresponding to the target hardware functional module based on the target simulation module group to serve as the target test data.
4. The method of claim 1, wherein the transmitting the target test data to a domain under test controller for a vehicle comprises:
acquiring a communication mode corresponding to the target test data;
and sending the target test data to the tested domain controller in the communication mode.
5. The method of any of claims 1-4, wherein the transmitting the target test data to a domain under test controller for a vehicle comprises:
positioning data synchronous with the target test data are obtained, wherein the positioning data are simulation data generated by a positioning simulation module of a vehicle;
and sending the target test data and the positioning data to the tested domain controller.
6. A hardware-in-the-loop test method for a domain controller under test for use in a vehicle, the method comprising:
receiving target test data corresponding to a target test task sent by test equipment, wherein the target test data comprises simulation data corresponding to a target hardware functional module required by a vehicle to execute the target test task;
and executing the target test task based on the target test data, obtaining control data and feeding the control data back to the test equipment, wherein the control data is used for determining a test result corresponding to the target test task by the test equipment.
7. The method of claim 6, wherein performing the target test task based on the target test data, deriving the control data and feeding the control data back to the test equipment, comprises:
operating a target processing module group corresponding to the target test task based on the target test data, wherein the target processing module group is used for processing the target test data;
and generating the control data based on the processing data obtained after the target processing module group processes the target test data, and feeding back the control data to the test equipment.
8. The method of claim 7, wherein prior to the running the set of target processing modules corresponding to the target test task based on the target test data, the method further comprises:
operating a bypass shielding program corresponding to the target test task, wherein the bypass shielding program is used for shielding the processing modules except the target processing module group;
the running the target processing module group corresponding to the target test task based on the target test data comprises the following steps:
and operating the unmasked processing module in the tested domain controller based on the target test data.
9. A hardware-in-the-loop testing apparatus comprising functional modules for implementing the method of any of claims 1-5, or claims 6-8.
10. An electronic device, the 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, the one or more applications configured to perform the method of any of claims 1-5 or the method of any of claims 6-8.
11. A computer readable storage medium having stored therein program code which is callable by a processor to perform the method according to any one of claims 1-5 or to perform the method according to any one of claims 6-8.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311570789.XA CN117827555A (en) | 2023-11-22 | 2023-11-22 | Hardware-in-loop test method and device, electronic equipment and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311570789.XA CN117827555A (en) | 2023-11-22 | 2023-11-22 | Hardware-in-loop test method and device, electronic equipment and storage medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN117827555A true CN117827555A (en) | 2024-04-05 |
Family
ID=90516179
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202311570789.XA Pending CN117827555A (en) | 2023-11-22 | 2023-11-22 | Hardware-in-loop test method and device, electronic equipment and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN117827555A (en) |
-
2023
- 2023-11-22 CN CN202311570789.XA patent/CN117827555A/en active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN108983633B (en) | System, method and device for simulating multiple objects in virtual environment | |
| CN211236045U (en) | ADAS HIL test system based on multisensor | |
| US20130124703A1 (en) | Method and apparatus for setting up gateway for autosar-based vehicle network | |
| CN103543999A (en) | Method and device for creating and testing a control unit program | |
| WO2022120717A1 (en) | Simulation task scheduling method, execution method, simulation implementation method and device | |
| CN113468070A (en) | Consistency test method for vehicle-mounted Ethernet | |
| US20220164166A1 (en) | Simulation method and recording medium | |
| CN109683491B (en) | Vehicle-mounted camera simulation system | |
| CN115277882A (en) | CAN message database establishing method and device, vehicle-mounted electronic equipment and storage medium | |
| KR20200062594A (en) | Operating method in debugging system for vehicle | |
| CN117827555A (en) | Hardware-in-loop test method and device, electronic equipment and storage medium | |
| JP2021533437A (en) | Information presentation methods and devices, electronic devices, storage media and computer programs | |
| CN115795845A (en) | Construction method, device, equipment and storage medium of integrated test simulation platform | |
| CN115384526A (en) | Debugging system and debugging method | |
| CN115309085A (en) | Unmanned dual-communication redundancy control method, system, electronic equipment and medium | |
| JP2005181113A (en) | Testing system and testing method for onboard electrical components | |
| CN112685082A (en) | Task execution method and device, computer readable storage medium and vehicle-mounted terminal | |
| JP6548708B2 (en) | Low Latency Testing Machine for Image Processing Systems | |
| CN111077798A (en) | Simulation scene real-time control method and device | |
| WO2018198770A1 (en) | Calculation device, log recording method, log recording system | |
| US20230281354A1 (en) | System and method for providing autonomous driving simulation architecture with switchable models | |
| CN111103869A (en) | Scene simulation system and method | |
| CN116627053B (en) | Semi-physical simulation system of unmanned platform cluster communication network | |
| CN112702247B (en) | Hybrid control method and device for FF field bus system and storage medium | |
| CN116520753B (en) | Vehicle remote control method, device, electronic equipment and computer readable medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |