Hardware-in-the-loop full-link automatic testing method for remote vehicle control function
Through the method of combining control attributes and image recognition, a full-link automated test link is built, which solves the problem of lack of automation in existing remote control vehicle function test methods and achieves efficient functional testing and system optimization.
Patent Information
- Application Number
- CN202211713361.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2022-12-28
- Publication Date
- 2025-01-21
- Estimated Expiration
- 2042-12-28
AI Technical Summary
The existing remote vehicle-controlled functional testing methods lack automation, making it difficult to effectively monitor functional failure nodes and response time, resulting in poor user experience and high test and development costs.
Using a combination of control attributes and image recognition, a full-cycle automated test link is built through terminal APP simulated clicks, pop-up element status recognition, bus signal full-process monitoring, and high-precision response time monitoring.
It realizes full-scale automated testing of remote control vehicle functions, improves testing efficiency and accuracy, discovers software and hardware defects, guides system optimization, and improves the robustness of functions.
Smart Images

Figure CN115933613B_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of cigarette manufacturing, and in particular to a hardware-in-the-loop full-link automatic testing method for a remote vehicle control function. Background Art
[0002] With the development of intelligent network technology, remote vehicle control has gradually become a standard feature of automobiles. Remote vehicle control usually includes functions such as remote engine / air conditioning, remote door unlocking / locking, remote vehicle search, and remote vehicle location viewing, which greatly improves the comfort and convenience of users. However, due to the increasing complexity of remote vehicle control functions, in actual usage scenarios, remote vehicle control functions have defects such as frequent control failures and long command response time, resulting in a high number of user complaints. It can be seen that the stability of this function is highly related to the passenger's car experience, and it is a key test object in the automotive component testing link, and it needs to be fully tested and verified.
[0003] The remote vehicle control function mainly involves terminal APP, server, TBOX and target actuator. It allows users to remotely issue instructions through mobile phone APP. The server forwards the received instructions to the vehicle-mounted TBOX through the network. Finally, TBOX forwards the CAN signal corresponding to the current instruction to the corresponding target actuators, thereby realizing remote control of the vehicle. At present, the test method for this function mainly adopts the real vehicle manual test method, which not only greatly prolongs the debugging nodes of each link unit of the remote vehicle control function, but also lacks effective monitoring of failure nodes, function response time, etc. In addition, the insufficient degree of automation and high test development costs are problems that need to be solved urgently.
[0004] There are specific and concrete technical problems in the existing solutions for remote vehicle control function testing:
[0005] For example, the Monkey software is used to detect the latest vehicle status on the mobile APP and record the corresponding data through screenshots. However, since the execution results of some remote vehicle control functions are usually displayed briefly through a pop-up window of 1 to 2 seconds, it is difficult to capture the pop-up window, resulting in the inability to obtain the execution results in time;
[0006] For example, the terminal execution status is first read, and then the execution result returned to the server by the vehicle's target actuator is compared. However, this method only considers the dimension of whether the vehicle's execution function is normal, and ignores the user experience defects caused by the long response time of the remote vehicle control function. Summary of the invention
[0007] In view of the above, the present invention aims to provide a hardware-in-the-loop full-link automatic testing method for remote vehicle control functions to solve the above-mentioned technical problems.
[0008] The technical solution adopted by the present invention is as follows:
[0009] The present invention provides a hardware-in-the-loop full-link automatic testing method for a remote vehicle control function, which includes:
[0010] Step S1, the control terminal remote control vehicle APP sends a control instruction, and when the control instruction sending operation is completed, a first timestamp is synchronously recorded;
[0011] Step S2, the control instruction is forwarded to the TBOX integrated on the hardware-in-the-loop test bench via the server, and the TBOX sends a first bus signal to the target actuator based on the control instruction, and synchronously records a second timestamp of sending the first bus signal;
[0012] Step S3: The target actuator executes the remote vehicle control action based on the first bus signal, and after the execution is completed, it feeds back a second bus signal indicating the completion of the execution to the TBOX, and simultaneously records a third timestamp of sending the second bus signal;
[0013] Step S4: After receiving the second bus signal, the TBOX forwards the corresponding execution status to the terminal remote vehicle control APP through the server, obtains a screenshot of the pop-up window on the terminal in real time, and simultaneously records a fourth timestamp of the pop-up window;
[0014] Step S5, identifying the pop-up window information in the pop-up window screenshot, if the pop-up window information indicates that the execution is successful, then proceeding to step S6; if the pop-up window information indicates that the execution fails, then jumping to step S7;
[0015] Step S6, calculate the difference between the fourth timestamp and the first timestamp to obtain a total time difference, and compare it with the preset total response time threshold: if the total time difference < the total response time threshold, generate a test report indicating that the execution is successful and the response is not timed out and jump to step S8; if the total time difference > the total response time threshold, respectively calculate the response time differences of different stages corresponding to adjacent timestamps, and respectively compare them with the preset target stage response time thresholds of the corresponding stages, and when the response time difference of any stage > the target stage response time threshold, generate a test report indicating that the execution is successful but the target stage response is timed out and jump to step S8;
[0016] Step S7, respectively judging the matching of the execution results of step S2 and step S3, and if there is a mismatch, generating a test report indicating that a certain execution result does not match and causes the execution failure;
[0017] Step S8, determine whether the number of cycles issued by the remote vehicle control command reaches the set value. If it reaches the set value, end the test; if it does not reach the set value, jump to step S1 for a new round of testing.
[0018] In at least one possible implementation manner, the test method further includes: in step S2, monitoring whether the first bus signal value sent by the TBOX matches the control instruction.
[0019] In at least one possible implementation manner, the testing method further includes: in step S3, monitoring whether the second bus signal value sent by the target executor matches a preset expected execution result.
[0020] In at least one possible implementation manner, obtaining a pop-up window screenshot on the terminal includes: obtaining a pop-up window screenshot on the terminal in real time by a pop-up window capture script preset by a host computer.
[0021] In at least one possible implementation manner, the control terminal remote vehicle control APP sends the control instruction including: the host computer randomly sends the control instruction individually through a preset operation terminal remote vehicle control APP.
[0022] In at least one possible implementation manner, the first bus signal and the second bus signal are both CAN signals.
[0023] In at least one possible implementation manner, the first timestamp, the second timestamp, the third timestamp, and the fourth timestamp are all millisecond-level time data.
[0024] In at least one possible implementation method, the control instructions include at least one of the following: remote start and stop of the engine, remote start and stop of the air conditioner, remote unlocking of doors and windows, remote locking of doors and windows, remote vehicle search, remote checking of vehicle location, remote query of vehicle usage data, and remote acquisition of vehicle information.
[0025] The main design concept of the present invention is to capture the pop-up window information on the APP side by combining control attributes with image recognition, and to monitor the command response time with high precision while realizing the monitoring of the failure of all node functions, so as to effectively discover the defects of software and hardware, and thus reliably guide the optimization of the system to improve the robustness of the remote control function. Specifically, by building a key test mechanism with terminal APP element simulation clicks, pop-up element status recognition, bus signal full process monitoring, response time high-precision monitoring, and visual test report generation, the automated test link of all links in the remote control function is opened up, effectively optimizing the test process and improving the test efficiency. BRIEF DESCRIPTION OF THE DRAWINGS
[0026] In order to make the purpose, technical solutions and advantages of the present invention more clear, the present invention will be further described below with reference to the accompanying drawings, in which:
[0027] Figure 1A flowchart of a hardware-in-the-loop full-link automatic testing method for a remote vehicle control function provided in an embodiment of the present invention. DETAILED DESCRIPTION
[0028] Embodiments of the present invention are described in detail below, and examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and cannot be interpreted as limiting the present invention.
[0029] The present invention proposes an embodiment of a hardware-in-the-loop full-link automatic testing method for remote vehicle control functions. Specifically, Figure 1 shown, including:
[0030] Step S1, the control terminal remote control vehicle APP sends a random single control instruction, and when the instruction sending operation is completed, the first timestamp T is synchronously recorded. Among them, the control instructions may include remote start and stop of the engine / air conditioner, remote unlocking / locking of doors and windows, remote search for the vehicle, remote viewing of the vehicle location and other functions.
[0031] Step S2: The control instruction is forwarded to the TBOX integrated on the hardware-in-the-loop test bench via the server, and the TBOX sends a first bus signal (such as a CAN signal) to the target actuator based on the control instruction, and synchronously records the second timestamp T of sending the first bus signal. 2 Furthermore, the NI board can be used to monitor whether the first bus signal value sent by the TBOX matches the control instruction.
[0032] Step S3: The target actuator executes the remote vehicle control action based on the first bus signal, and feeds back a second bus signal indicating the completion of the execution to TBOX after the execution is completed, and synchronously records a third timestamp T3 of sending the second bus signal; further, the NI board can also be used to monitor whether the second bus signal value sent by the target actuator matches the preset expected execution result.
[0033] Step S4: After receiving the second bus signal, TBOX forwards the corresponding execution status to the terminal remote vehicle control APP through the server, and the pop-up window capture script preset by the host computer obtains the pop-up window screenshot on the terminal in real time, and synchronously records the fourth timestamp T when the pop-up window appears. 4 .
[0034] Step S5, using image recognition technology to determine the pop-up window information in the pop-up window screenshot, if the pop-up window information representation is executed successfully, then go to step S6, if the pop-up window information representation is executed unsuccessfully, then jump to step S7.
[0035] Step S6: Calculate T 4 -T1 Get the total time difference and compare it with the preset total response time threshold A T For comparison: If T 4 -T 1 T Then generate a test report indicating successful execution and no response timeout and jump to step S8; if T 4 -T 1 >A T Then calculate the response time difference of adjacent timestamps (i.e., T 2 -T 1 , T 3 -T 2 , T 4 -T 3 Characterizes the response time difference of the three stages), and is respectively compared with the preset response time threshold A of each stage T1 , A T2 , A T3 The purpose of this step is to locate the target phase that causes the response timeout, generate a test report indicating that the execution is successful but the target phase response timeout occurs, and jump to step S8.
[0036] Step S7: respectively determine the matching status of the execution results of step S2 and step S3, and generate a test report indicating that a certain execution result does not match and leads to execution failure.
[0037] Step S8, determine whether the number of cycles issued by the remote vehicle control command reaches the set value. If it reaches the set value, end the test; if it does not reach the set value, jump to step S1 for a new round of testing.
[0038] The above-mentioned embodiments can be implemented in actual operation by using the following system architecture example: using a test bench that integrates TBOX and target actuators, the communication between the terminal APP and the TBOX end is realized with the help of a server, and the bus (CAN) signal is simulated through the NI board to collect the full-link CAN signal data changes in real time, and the terminal APP is automatically operated and the pop-up information is captured, identified and judged through a script program written by the host computer software, and the timestamps of each key node of the remote control vehicle command issuance, transmission, execution, and completion are synchronously recorded to achieve millisecond-level monitoring of the response time of the remote control vehicle function.
[0039] In summary, the main design concept of the present invention is to capture the pop-up window information on the APP side by combining control attributes with image recognition, and to monitor the command response time with high precision while realizing the monitoring of the failure of all node functions, so as to effectively discover software and hardware defects, thereby reliably guiding system optimization to improve the robustness of the remote control function. Specifically, by building a key test mechanism with terminal APP element simulation clicks, pop-up element status recognition, bus signal full-process monitoring, response time high-precision monitoring, and visual test report generation, the automated test link of all links in the remote control function is opened up, effectively optimizing the test process and improving the test efficiency.
[0040] In the embodiments of the present invention, "at least one" refers to one or more, and "more than one" refers to two or more. "And / or" describes the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B may represent the existence of A alone, the existence of A and B at the same time, and the existence of B alone. A and B may be singular or plural. The character " / " generally indicates that the associated objects before and after are in an "or" relationship. "At least one of the following" and similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b and c may represent: a, b, c, a and b, a and c, b and c, or a and b and c, where a, b, c may be single or multiple.
[0041] The above describes in detail the structure, features and effects of the present invention based on the embodiments shown in the drawings, but the above is only a preferred embodiment of the present invention. It should be noted that the technical features involved in the above embodiments and their preferred methods can be reasonably combined and matched into a variety of equivalent schemes by those skilled in the art without departing from or changing the design ideas and technical effects of the present invention; therefore, the present invention is not limited to the scope of implementation shown in the drawings, and all changes made in accordance with the concept of the present invention, or modifications to equivalent embodiments with equivalent changes, which still do not exceed the spirit covered by the specification and drawings, should be within the protection scope of the present invention.
Claims
1. A hardware-in-the-loop full-link automatic testing method for remote vehicle control function, characterized in that: include: Step S1, the control terminal remote control vehicle APP sends a control instruction, and when the control instruction sending operation is completed, a first timestamp is synchronously recorded; Step S2, the control instruction is forwarded to the TBOX integrated on the hardware-in-the-loop test bench via the server, and the TBOX sends a first bus signal to the target actuator based on the control instruction, and synchronously records a second timestamp of sending the first bus signal; Step S3: The target actuator executes the remote vehicle control action based on the first bus signal, and after the execution is completed, it feeds back a second bus signal indicating the completion of the execution to the TBOX, and simultaneously records a third timestamp of sending the second bus signal; Step S4: After receiving the second bus signal, the TBOX forwards the corresponding execution status to the terminal remote vehicle control APP through the server, obtains a screenshot of the pop-up window on the terminal in real time, and simultaneously records a fourth timestamp of the pop-up window; Step S5, identifying the pop-up window information in the pop-up window screenshot, if the pop-up window information indicates that the execution is successful, then proceeding to step S6; if the pop-up window information indicates that the execution fails, then jumping to step S7; Step S6, calculate the difference between the fourth timestamp and the first timestamp to obtain a total time difference, and compare it with the preset total response time threshold: if the total time difference < the total response time threshold, generate a test report indicating that the execution is successful and the response is not timed out and jump to step S8; if the total time difference > the total response time threshold, respectively calculate the response time differences of different stages corresponding to adjacent timestamps, and respectively compare them with the preset target stage response time thresholds of the corresponding stages, and when the response time difference of any stage > the target stage response time threshold, generate a test report indicating that the execution is successful but the target stage response is timed out and jump to step S8; Step S7, respectively judging the matching of the execution results of step S2 and step S3, and if there is a mismatch, generating a test report indicating that a certain execution result does not match and causes the execution failure; Step S8, determine whether the number of cycles issued by the remote vehicle control command reaches the set value. If it reaches the set value, end the test; if it does not reach the set value, jump to step S1 for a new round of testing.
2. The hardware-in-the-loop full-link automatic testing method for remote vehicle control function according to claim 1 is characterized in that: The test method further comprises: in step S2, monitoring whether the first bus signal value sent by TBOX matches the control instruction.
3. The hardware-in-the-loop full-link automatic testing method for remote vehicle control function according to claim 1 is characterized in that: The testing method further comprises: in step S3, monitoring whether the second bus signal value sent by the target executor matches a preset expected execution result.
4. The hardware-in-the-loop full-link automatic testing method for remote vehicle control function according to claim 1 is characterized in that: The obtaining of the pop-up window screenshot on the terminal includes: obtaining the pop-up window screenshot on the terminal in real time by a pop-up window capture script preset by the host computer.
5. The hardware-in-the-loop full-link automatic testing method for remote vehicle control function according to claim 1 is characterized in that: The control terminal remote vehicle control APP sends the control instruction including: the host computer sends the control instruction randomly and individually through the preset operation terminal remote vehicle control APP.
6. The hardware-in-the-loop full-link automatic testing method for remote vehicle control function according to any one of claims 1 to 5, characterized in that: The first timestamp, the second timestamp, the third timestamp, and the fourth timestamp are all millisecond-level time data.
7. The hardware-in-the-loop full-link automatic testing method for remote vehicle control function according to any one of claims 1 to 5, characterized in that: The first bus signal and the second bus signal are both CAN signals.
8. The hardware-in-the-loop full-link automatic testing method for remote vehicle control function according to any one of claims 1 to 5, characterized in that: The control instructions include at least one of the following: remote engine start and stop, remote air conditioning start and stop, remote unlocking of doors and windows, remote locking of doors and windows, remote vehicle search, remote vehicle location check, remote vehicle usage data query, and remote acquisition of vehicle information.
Citation Information
Patent Citations
Automobile bus communication method and system, remote terminal and automobile diagnosis device
CN109873733A
Internet of vehicles remote control end-cloud integrated automatic test system and method
CN113341917A