Vehicle-mounted TBox test system and method

Abstract

The invention relates to the technical field of vehicle testing, and discloses a vehicle-mounted TBox testing system and method, and the system comprises an upper computer and a vehicle-mounted TBox. A remote instruction simulation module and a feedback signal simulation module are deployed in the upper computer, the upper computer is in communication connection with the vehicle-mounted TBox, and the remote instruction simulation module is used for simulating a cloud platform to send a remote control instruction to the vehicle-mounted TBox, receiving an instruction execution result returned by the vehicle-mounted TBox and then judging whether the vehicle-mounted TBox is qualified or not according to the instruction execution result; the feedback signal simulation module is used for simulating a vehicle controller to receive a control signal output by the vehicle-mounted TBox and sending a feedback signal to the vehicle-mounted TBox in response to the control signal, the control signal is a signal obtained by analyzing a remote control instruction by the vehicle-mounted TBox, and the feedback signal is a signal used for being analyzed by the vehicle-mounted TBox and obtaining an instruction execution result. According to the invention, the vehicle-mounted TBox test efficiency and accuracy are improved.

Description

Technical Field

[0001] This invention relates to the field of vehicle testing technology, and specifically to a testing system and method for an on-board TBox. Background Technology

[0002] With the development of intelligent connected vehicles, remote control has become a crucial aspect of vehicle intelligence. Users send remote control commands (such as turning the air conditioning on / off, unlocking doors, and opening / closing windows) via a mobile application. These commands are forwarded to the vehicle's Telematics Box (TBox, remote communication module) via a cloud platform. The TBox receives and parses the commands, generates corresponding control signals, and forwards them to the vehicle's CAN bus. The vehicle controller receives these signals via the CAN bus and executes the corresponding control actions, thus enabling remote control of vehicle functions. The development and verification of the TBox's remote control function heavily relies on the collaborative work of multiple external systems, including the upper-level cloud platform and the lower-level vehicle controller. Therefore, in the early stages of development, verification testing of the TBox requires waiting for the cloud platform and vehicle controller to be in production and configuration ready, significantly reducing development efficiency. Furthermore, configuring the communication connection between the TBox, cloud platform, and vehicle controller involves complex program logic, leading to a complex testing environment setup and hindering rapid verification in the early stages of development. Summary of the Invention

[0003] This invention provides a testing system and method for vehicle-mounted TBoxes to solve the problem of long testing cycles for vehicle-mounted TBoxes.

[0004] In a first aspect, the present invention provides a testing system for an in-vehicle TBox, comprising: a host computer and an in-vehicle TBox; the host computer is equipped with a remote command simulation module and a feedback signal simulation module, the host computer and the in-vehicle TBox are communicatively connected, the remote command simulation module is used to simulate a cloud platform sending remote control commands to the in-vehicle TBox and receiving the command execution results returned by the in-vehicle TBox, and then judging whether the in-vehicle TBox is qualified based on the command execution results; the feedback signal simulation module is used to simulate a vehicle controller receiving control signals output by the in-vehicle TBox and sending feedback signals to the in-vehicle TBox in response to the control signals, the control signals being obtained by the in-vehicle TBox from parsing the remote control commands, and the feedback signals being used by the in-vehicle TBox to analyze and obtain the command execution results.

[0005] Based on the aforementioned technical methods, a core testing system architecture for the host computer and the vehicle-mounted TBox was constructed. By deploying a remote command simulation module and a feedback signal simulation module, functional simulations of the cloud platform and vehicle controller were achieved, respectively. This eliminates the need to rely on real cloud platform and vehicle controller hardware, enabling the establishment of a complete testing loop. This solves the problem of waiting for external systems to become ready in traditional testing, significantly shortening the testing cycle. Simultaneously, the remote command simulation module can directly receive the execution results from the vehicle-mounted TBox and determine its pass / fail status, while the feedback signal simulation module can accurately respond to control signals, ensuring the integrity of the test closed loop and avoiding test interruptions caused by external system coordination issues. This improves the efficiency of functional verification in the early stages of vehicle-mounted TBox development and reduces the complexity of test environment setup.

[0006] In some optional implementations, a test case management module is also deployed in the host computer. The test case management module is used to configure and save test cases, which include remote control commands, control signals expected to be output by the vehicle TBox, feedback signals, and command execution results expected to be output by the vehicle TBox.

[0007] Based on the aforementioned technical methods, a new test case management module has been added. This module can uniformly configure and save complete test cases containing remote control commands, expected control signals, feedback signals, and expected execution results. It eliminates the need for manual parameter input for each test, reducing repetitive operations and improving testing efficiency. Simultaneously, the standardized test case format ensures the reproducibility of the testing process, avoiding deviations in test results caused by human input errors. Furthermore, this module supports flexible adjustment of test case parameters, allowing for quick switching between normal, boundary, and abnormal test scenarios, comprehensively covering the verification requirements of the vehicle-mounted TBox remote control function, and helping developers accurately locate functional defects in different scenarios.

[0008] In some optional implementations, a log recording and analysis module is also deployed in the host computer. The log recording and analysis module is used to record the interaction data during the test process and generate a visual test report based on the interaction data.

[0009] Based on the aforementioned technical methods, the logging and analysis module records interactive data during the testing process and generates visual reports, solving the problems of fragmented and difficult-to-trace data in traditional testing. Complete recording of interactive data facilitates subsequent review of test details and quick identification of the root cause of problems; the visual reports present test results in an intuitive format, eliminating the need for developers to manually organize and analyze data, thus reducing the difficulty of data interpretation. Simultaneously, this module facilitates the archiving and sharing of test results, supports team collaboration and debriefing, helps optimize testing strategies, and further improves the standardization and efficiency of testing the vehicle-mounted TBox remote control function.

[0010] In some alternative implementations, the host computer establishes a local communication connection with the vehicle-mounted TBox.

[0011] In some optional implementations, the steps of configuring the host computer to establish a local communication connection with the vehicle-mounted TBox include: starting local TCP / IP services for the remote command simulation module and the feedback signal simulation module on the host computer, and listening on the first port of the host computer; mapping the first port to the second port of the vehicle-mounted TBox using Android debug bridge commands, where the second port is the port corresponding to the local loopback address of the vehicle-mounted TBox; modifying the configuration file of the vehicle-mounted TBox to replace the communication address in the configuration file with the local loopback address; controlling the vehicle-mounted TBox to initiate a connection request to the first port based on the local loopback address; and controlling the remote command simulation module and the feedback signal simulation module to receive the connection request through the first port, and establishing a bidirectional communication link with the vehicle-mounted TBox in response to the connection request.

[0012] Based on the aforementioned technical methods, a local communication connection is explicitly adopted between the host computer and the vehicle-mounted TBox. Compared to remote network communication, this avoids the impact of external factors such as network latency and signal interference on test results, ensuring the stability and real-time performance of test data transmission and improving the accuracy of test results. Local communication does not rely on an external network environment, simplifying the test environment setup process. It is particularly suitable for bench testing scenarios in the early stages of development, allowing developers to quickly conduct tests locally, reducing environment preparation time and accelerating the iterative verification of the vehicle-mounted TBox's remote control function. Furthermore, specific configuration steps for the local communication connection are provided. Stable communication between the host computer and the vehicle-mounted TBox is achieved through operations such as starting a local TCP / IP service, port reverse mapping, and modifying configuration files. This configuration method does not require large-scale modifications to the core control logic of the vehicle-mounted TBox; only communication-related parameters and port settings are adjusted, reducing development costs and risks. Port reverse mapping technology solves the potential network isolation problem between the vehicle-mounted TBox and the host computer, ensuring efficient interaction between the two. The standardized configuration process ensures reproducible operation, allowing different developers to quickly build a communication link step by step, improving the consistency and efficiency of test environment setup.

[0013] Secondly, the present invention provides a testing method for an in-vehicle TBox, applied to a host computer provided by any system of the first aspect. The method includes: generating a remote control command through a remote command simulation module and sending the remote control command to the in-vehicle TBox, so that the in-vehicle TBox can parse the remote control command to obtain a control signal; receiving the control signal sent by the in-vehicle TBox through a feedback signal simulation module; responding to the control signal through the feedback signal simulation module, generating a feedback signal after the control is completed, and sending the feedback signal to the in-vehicle TBox, so that the in-vehicle TBox can determine the command execution result based on the feedback signal; receiving the command execution result sent by the in-vehicle TBox through the remote command simulation module and comparing the command execution result with the expected execution result; and determining whether the in-vehicle TBox is qualified based on the comparison result.

[0014] In some optional implementations, the method further includes configuring and saving test cases through a test case management module. The test cases include remote control commands, control signals expected to be output by the vehicle TBox, feedback signals, and command execution results expected to be output by the vehicle TBox.

[0015] In some alternative implementations, the method further includes: recording interaction data during the testing process through a logging and analysis module, and generating a visual test report based on the interaction data.

[0016] In some optional implementations, the remote control command or feedback signal is used as the target signal. The step of the host computer sending the target signal to the vehicle TBox includes: sending the target signal to the first port through the remote command simulation module or the feedback signal simulation module, so that the target signal is transmitted to the local loopback address of the vehicle TBox through the first port; the step of the host computer receiving the target signal includes: listening to the target signal received by the first port through the remote command simulation module or the feedback signal simulation module.

[0017] Thirdly, the present invention provides a testing method for an in-vehicle TBox, applicable to an in-vehicle TBox provided by any system of the first aspect. The method includes: receiving a remote control command, wherein the remote control command is a command generated by a host computer through a remote command simulation module; parsing the remote control command to obtain a control signal; sending the control signal to the host computer, so that the host computer receives the control signal through a feedback signal simulation module and, in response to the control signal, generates a feedback signal after control is completed; receiving the feedback signal sent by the host computer; determining the command execution result based on the feedback signal; sending the command execution result to the host computer, so that the host computer receives the command execution result through the remote command simulation module, compares the command execution result with the expected execution result, and then determines whether the in-vehicle TBox is qualified based on the comparison result.

[0018] Fourthly, the present invention provides a computer-readable storage medium storing computer instructions for causing a computer to perform the method described in the first aspect or any corresponding embodiment thereof.

[0019] Fifthly, the present invention provides a computer program product, including computer instructions for causing a computer to perform the method described in the first aspect or any corresponding embodiment thereof.

[0020] The technical solution provided by this invention has the following advantages: (1) Based on the above technical means, a core test system architecture for the host computer and the vehicle TBox was constructed. By deploying a remote command simulation module and a feedback signal simulation module, the functions of the cloud platform and the vehicle controller were simulated respectively. A complete test link can be built without relying on the actual cloud platform and vehicle controller hardware, which solves the problem of waiting for the external system to be ready in traditional testing and greatly shortens the test cycle. At the same time, the remote command simulation module can directly receive the execution results of the vehicle TBox and judge its pass / fail status, and the feedback signal simulation module can accurately respond to the control signals, ensuring the integrity of the test closed loop, avoiding test interruption caused by external system coordination problems, improving the efficiency of functional verification in the early stage of vehicle TBox development, and reducing the complexity of test environment construction.

[0021] (2) Based on the above technical means, a new test case management module is added, which can uniformly configure and save complete test cases containing remote control commands, expected control signals, feedback signals, and expected execution results. This eliminates the need for manual parameter input for each test, reducing repetitive operations and improving testing efficiency. Simultaneously, the standardized test case format ensures the reproducibility of the testing process, avoiding test result deviations caused by human input errors. Furthermore, this module supports flexible adjustment of test case parameters, allowing for quick switching between normal, boundary, and abnormal test scenarios, comprehensively covering the verification requirements of the vehicle-mounted TBox remote control function, and helping developers accurately locate functional defects in different scenarios.

[0022] (3) Based on the above technical means, the log recording and analysis module records the interactive data of the test process and generates a visual report, which solves the problem of scattered and difficult-to-trace data in traditional testing. The complete recording of interactive data facilitates the subsequent review of test details and quickly locates the root cause of the problem; the visual report presents the test results in an intuitive form, eliminating the need for developers to manually organize and analyze the data, thus reducing the difficulty of data interpretation. At the same time, this module provides convenience for archiving and sharing test results, supports team collaboration and review, helps optimize test strategies, and further improves the standardization and efficiency of the vehicle TBox remote control function test.

[0023] (4) Based on the above technical means, it is clear that the host computer and the vehicle TBox adopt a local communication connection. Compared with remote network communication, this can avoid the impact of external factors such as network delay and signal interference on the test results, ensure the stability and real-time performance of test data transmission, and improve the accuracy of test results. Local communication does not rely on an external network environment, simplifying the test environment setup process. It is especially suitable for bench testing scenarios in the early stages of development. Developers can quickly conduct tests locally, reduce environment preparation time, and accelerate the iterative verification of the remote control function of the vehicle TBox. In addition, specific configuration steps for local communication connection are provided. Stable communication between the host computer and the vehicle TBox can be achieved by starting the local TCP / IP service, port reverse mapping, and modifying the configuration file. This configuration method does not require large-scale modification of the core control logic of the vehicle TBox. Only communication-related parameters and port settings are adjusted, reducing development costs and risks. The port reverse mapping technology solves the network isolation problem that may exist between the vehicle TBox and the host computer, ensuring efficient interaction between the two. The standardized configuration process ensures that the operation is reproducible. Different developers can quickly build the communication link step by step, improving the consistency and efficiency of test environment setup. Attached Figure Description

[0024] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0025] Figure 1 This is a schematic diagram of the structure of a vehicle-mounted TBox testing system according to an embodiment of the present invention; Figure 2 This is a schematic diagram of the configuration process of the vehicle-mounted TBox testing system according to an embodiment of the present invention; Figure 3 This is a schematic diagram of the first step in a testing method for an in-vehicle TBox according to an embodiment of the present invention; Figure 4 This is a schematic diagram of a second process for testing an in-vehicle TBox according to an embodiment of the present invention; Detailed Implementation To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0026] It is understood that before using the technical solutions disclosed in the various embodiments of the present invention, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in the present invention and their authorization should be obtained in accordance with relevant laws and regulations through appropriate means.

[0027] With the development of intelligent connected vehicles, remote control has become a crucial aspect of vehicle intelligence. Users send remote control commands (such as turning the air conditioning on / off, unlocking doors, and opening / closing windows) via a mobile application, which are then forwarded to the in-vehicle TBox via a cloud platform. The in-vehicle TBox receives and parses the commands, generates corresponding control signals, and forwards these signals to the vehicle's CAN bus. The vehicle controller receives the control signals via the CAN bus and executes the corresponding control actions, thus enabling remote control of vehicle functions. The development and verification of the in-vehicle TBox's remote control function heavily relies on the collaborative work of multiple external systems, including the upper-level cloud platform and the lower-level vehicle controller. Therefore, in the early stages of development, verification testing of the in-vehicle TBox requires waiting for the cloud platform and vehicle controller to be in a production-complete and configuration-ready state. In some related technologies, the in-vehicle TBox acts as a relay station, forwarding data to the vehicle target controller, which then feeds back action signals. However, during the R&D process, when testing the in-vehicle TBox, the vehicle target controller may not be fully developed. Using the vehicle target controller's testing scheme to test the in-vehicle TBox may lead to inaccurate testing or the absence of test feedback signals, severely reducing the development efficiency and accuracy of the in-vehicle TBox. In addition, configuring the communication connection between the in-vehicle TBox, cloud platform and vehicle controller involves complex program logic, which makes it difficult to set up the test environment and hinders rapid intervention and verification in the early stages of development.

[0028] According to an embodiment of the present invention, a test system embodiment for an in-vehicle TBox is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0029] This embodiment provides a testing system for an in-vehicle TBox, such as Figure 1As shown, it includes: a host computer and an in-vehicle TBox; the host computer is equipped with a remote command simulation module and a feedback signal simulation module. The host computer is communicatively connected to the in-vehicle TBox. The remote command simulation module is used to simulate the cloud platform sending remote control commands to the in-vehicle TBox and receiving the command execution results returned by the in-vehicle TBox. Then, it determines whether the in-vehicle TBox is qualified based on the command execution results. The feedback signal simulation module is used to simulate the vehicle controller receiving the control signals output by the in-vehicle TBox and sending feedback signals to the in-vehicle TBox in response to the control signals. The control signals are obtained by the in-vehicle TBox from parsing the remote control commands, and the feedback signals are used by the in-vehicle TBox to analyze and obtain the command execution results.

[0030] Specifically, in this embodiment, a testing system for an in-vehicle TBox is provided as follows: Figure 1 As shown, the core components of the system are the host computer and the vehicle-mounted TBox. The two are connected through a specific communication method to achieve efficient testing of the remote control function of the vehicle-mounted TBox. The vehicle-mounted TBox is a key module in intelligent connected vehicles responsible for data interaction with external networks (such as the cloud), receiving and executing remote control commands. Its normal functioning directly affects the stability and reliability of the vehicle's remote control function.

[0031] The host computer, serving as the control and simulation core of the testing system, internally deploys two key functional modules: a remote command simulation module and a feedback signal simulation module. The core function of the remote command simulation module is to simulate a cloud platform in a real-world scenario, sending remote control commands to the vehicle-mounted TBox under test. These commands cover common remote control needs of intelligent connected vehicles, such as remotely unlocking doors, turning on the air conditioning, and controlling window operation. The command format and protocol specifications are completely consistent with those issued by a real cloud platform, ensuring that the commands received by the vehicle-mounted TBox during testing are identical to those in actual application scenarios. Simultaneously, the remote command simulation module also has the function of receiving the command execution results returned by the vehicle-mounted TBox. After receiving the execution results, it compares them with preset reasonable results to determine whether the vehicle-mounted TBox's reception, parsing, and execution feedback process of remote control commands is normal, thus initially determining whether the vehicle-mounted TBox is qualified in the remote command interaction phase.

[0032] The feedback signal simulation module acts as a simulator of the vehicle controller. The vehicle controller is the component inside the vehicle that receives control signals from the onboard TBox and executes specific vehicle control actions. In a real-world scenario, the onboard TBox parses remote control commands, generates control signals, and sends them to the vehicle controller. After executing the action, the vehicle controller returns a feedback signal to the onboard TBox. In this test system, the feedback signal simulation module receives the control signals output by the onboard TBox. These control signals are generated by the onboard TBox after parsing the remote control commands sent by the remote command simulation module, conforming to the vehicle's internal communication protocol standards. Subsequently, based on the content of the received control signals, the feedback signal simulation module simulates the response behavior of the vehicle controller under different execution states, generates corresponding feedback signals, and sends them to the onboard TBox. These feedback signals are crucial for the onboard TBox to determine whether its command execution was successful and whether it needs to return a correct execution result to the remote command simulation module, ensuring the onboard TBox functions correctly in the complete chain of "receiving commands - parsing and generating control signals - receiving feedback signals - providing execution results."

[0033] In practical testing scenarios, the vehicle-mounted TBox testing system provided in this embodiment of the invention can effectively overcome the high dependence on real cloud platforms, mobile apps, and vehicle controllers in existing vehicle-mounted TBox remote control function testing processes. Traditional testing requires waiting for the real cloud platform to be deployed, the mobile app to be debugged, and the vehicle controller hardware to be in place before it can be carried out. This not only lacks flexibility but also suffers from problems such as missing feedback signals (inability to simulate multiple response states of the vehicle controller), limited scenario coverage (difficulty in quickly switching between different test scenarios), and low testing efficiency. In contrast, this system, through the software simulation functions of two modules within the host computer, constructs a complete remote control test link without relying on real external systems, achieving closed-loop testing of the TBox remote control logic.

[0034] On the one hand, without waiting for the external real system to be ready, developers can set up a test environment to conduct tests at any time, significantly shortening test preparation time and lowering the testing threshold and cost. On the other hand, by flexibly adjusting the types of commands sent by the remote command simulation module (such as normal commands, abnormal format commands, and repetitive commands) and the feedback signals generated by the feedback signal simulation module (such as execution success feedback, execution failure feedback, and abnormal error code feedback), it is possible to easily cover normal operation scenarios, boundary condition scenarios, and abnormal input scenarios, comprehensively evaluating the vehicle-mounted TBox's processing capabilities and fault tolerance mechanisms in complex environments, and improving test flexibility and coverage. Simultaneously, the testing process can be repeated, and the initial conditions and simulation environment can be kept consistent for each test, ensuring the accuracy and comparability of test results. This provides an efficient, flexible, and reliable solution for the development and verification of vehicle-mounted TBox remote control functions, with good engineering application prospects and promotional value.

[0035] In some optional implementations, a test case management module is also deployed in the host computer. The test case management module is used to configure and save test cases, which include remote control commands, control signals expected to be output by the vehicle TBox, feedback signals, and command execution results expected to be output by the vehicle TBox.

[0036] Specifically, in the vehicle-mounted TBox testing system of this embodiment, in addition to deploying a remote command simulation module and a feedback signal simulation module, the host computer further deploys a test case management module. This module, as the core support for the standardization and efficiency of the testing process, is specifically used to configure and save test cases, providing clear and reusable test basis for the entire vehicle-mounted TBox remote control function testing. A test case is a complete definition of a single test task, covering the key data and expected results involved in the test process. Specifically, it includes remote control commands, the expected control signals output by the vehicle-mounted TBox, feedback signals, and the expected command execution results output by the vehicle-mounted TBox. Each item matches the actual business logic and communication protocol of the TBox remote control, ensuring a high degree of consistency between the test scenario and the real application scenario.

[0037] In the test case configuration phase, such as Figure 2As shown, testers can set each test element one by one through the operation interface (such as a graphical interactive interface or a standardized parameter input interface) provided by the host computer for the test case management module. For remote control commands, common remote control commands for intelligent connected vehicles can be configured according to test requirements, such as remote door unlocking commands (which must include fields such as command identifier, target vehicle ID, and unlocking permission verification information), remote air conditioning activation commands (which must specify control parameters such as air conditioning temperature, fan speed, and mode), and remote window raising and lowering commands (which must specify parameters such as window position and raising / lowering speed). The command format must strictly follow the communication protocol specifications between the real cloud platform and the vehicle TBox to ensure that the vehicle TBox can parse it correctly.

[0038] For the control signals expected to be output by the vehicle TBox, the configuration needs to be based on the TBox's parsing logic for remote control commands. For example, if the remote control command is "Turn on the air conditioner (temperature 24℃, fan speed 2)," the expected control signal should include fields such as "air conditioner start indicator, temperature code 24℃, fan speed code 2, and signal check bit" based on the communication protocol between the TBox and the vehicle controller. The values ​​of these fields must be completely consistent with the control signals that should be generated after the vehicle TBox normally parses the command, so that the remote command simulation module can subsequently compare and verify the control signals actually output by the vehicle TBox.

[0039] The configuration of feedback signals needs to simulate the response of the vehicle controller under different execution states. For example, when the TBox outputs the control signal "turn on the air conditioner", if the simulated vehicle controller executes the action normally, the feedback signal can be configured as "the air conditioner has been started (temperature 24℃, fan speed 2), execution status code 'success'"; if the simulated vehicle controller fails to execute (such as air conditioner hardware failure), the feedback signal can be configured as "the air conditioner failed to start, fault code 'E01', fault description 'compressor abnormal'", so as to cover the feedback requirements under different execution scenarios.

[0040] The expected execution results of the commands output by the vehicle-mounted TBox must correspond one-to-one with the TBox's analysis logic for feedback signals. For example, if the vehicle-mounted TBox receives a "successful execution" feedback signal, the expected command execution result should include "command execution status 'successful', current air conditioning status (temperature 24℃, fan speed 2)"; if it receives a "failed execution" feedback signal, the expected command execution result should include "command execution status 'failed', fault code 'E01', fault cause 'compressor malfunction'", ensuring consistency with the format and content of the results that the TBox should report.

[0041] Once test cases are configured, the test case management module saves them in a structured format (including but not limited to XML, JSON, CSV, etc.). Each test case has a unique identifier, facilitating quick retrieval, access, and modification by testers. During subsequent testing, the remote command simulation module can directly retrieve the configured remote control commands from the test case management module and send them to the in-vehicle TBox. The feedback signal simulation module can generate responses based on the feedback signals configured in the test cases. Furthermore, each module can automatically compare the actual output of the in-vehicle TBox with the "expected results" in the test cases.

[0042] The test case management module supports single execution and batch execution, and allows users to set the execution interval. Furthermore, this module has the capability to construct exception instructions, generating non-standard input scenarios such as missing fields, format errors, and duplicate instructions to verify the stability and fault tolerance of the tested TBox under abnormal input conditions.

[0043] The addition of the test case management module effectively solves the problems of low efficiency, large errors, and difficulty in scenario reuse caused by the need to manually input commands and expected results for each test in traditional testing. Through standardized test case configuration and saving, it not only reduces test preparation time and ensures the repeatability and consistency of the testing process, but also allows for the flexible configuration of different combinations of commands, control signals, and feedback signals to quickly cover various test scenarios, including normal, boundary (such as command parameter thresholds), and abnormal scenarios. This provides strong support for comprehensively verifying the stability and fault tolerance of the vehicle-mounted TBox remote control function, further improving the testing efficiency of the entire testing system.

[0044] In some optional implementations, a log recording and analysis module is also deployed in the host computer. The log recording and analysis module is used to record the interaction data during the test process and generate a visual test report based on the interaction data.

[0045] Specifically, in the vehicle-mounted TBox testing system of this embodiment, to further improve the traceability of the testing process, the efficiency of problem localization, and the intuitiveness of test result presentation, in addition to the remote command simulation module, feedback signal simulation module, and optional test case management module, a log recording and analysis module is also deployed in the host computer. This module, as the core component for test data management and result analysis, mainly undertakes two key functions: first, to completely record all interactive data during the testing process; and second, to automatically generate a visual test report based on the recorded data, providing testers with a comprehensive and clear basis for reviewing the testing process and troubleshooting TBox functional defects.

[0046] The interactive data during the test covers all key information transmitted between each module in the test link and the vehicle-mounted TBox. Specifically, this includes, but is not limited to, details of the remote control commands sent by the remote command simulation module to the vehicle-mounted TBox (such as command type, sending timestamp, command parameters, command protocol version, etc.); the content of the control signals output by the vehicle-mounted TBox to the feedback signal simulation module after parsing the remote control commands (such as control signal encoding, signal transmission time, corresponding vehicle controller identifier, signal verification result, etc.); details of the feedback signals sent by the feedback signal simulation module to the vehicle-mounted TBox after responding to the control signals (such as feedback signal type (execution success / failure), fault code, feedback timestamp, vehicle status data, etc.); and the command execution results returned by the vehicle-mounted TBox to the remote command simulation module (such as execution status, result generation time, associated remote control command ID, etc.).

[0047] The log recording and analysis module will store these interactive data in a structured manner according to the rules of timestamp, data source, and data type. It supports saving in the form of text log files or database forms, ensuring that each piece of data can be accurately traced to the specific stage of the test process, avoiding the obstruction of problem investigation due to scattered or lost data.

[0048] After the test execution is complete, the log recording and analysis module automatically generates a visual test report based on the stored interaction data. The test results are presented intuitively to the testers through various formats such as charts, tables, and text descriptions. This invention effectively solves the pain points of incomplete test data recording and reliance on manual result analysis in traditional TBox testing, providing data support for subsequent development, further improving the practicality of the entire testing system and the standardization of testing work, and facilitating the efficient verification and quality improvement of the vehicle-mounted TBox remote control function.

[0049] In some alternative implementations, the host computer establishes a local communication connection with the vehicle-mounted TBox.

[0050] Specifically, in the vehicle-mounted TBox testing system of this embodiment, the host computer and the vehicle-mounted TBox achieve data interaction through a local communication connection (including but not limited to wired connections, Bluetooth, etc.). This eliminates the need to rely on external mobile networks or public networks, completing communication solely through a local link, thus meeting the needs of bench testing in the early stages of vehicle-mounted TBox development. The local communication connection avoids the impact of external network latency and signal interference on test data transmission, ensuring real-time and stable transmission of key data such as remote control commands, control signals, feedback signals, and execution results, thereby guaranteeing the accuracy of test results. Simultaneously, it eliminates the need for complex network configurations, simplifying the test environment setup process. Developers can quickly deploy the system and start testing on a local bench, lowering the testing threshold.

[0051] In some optional implementations, the steps of configuring the host computer to establish a local communication connection with the vehicle-mounted TBox include: Step a1: Start local TCP / IP services on the host computer for the remote command simulation module and the feedback signal simulation module respectively, and listen to the first port of the host computer. Step a2: Use the Android debug bridge command to reverse map the first port to the second port of the vehicle TBox. The second port is the port corresponding to the local loopback address of the vehicle TBox. Step a3: Modify the configuration file of the vehicle TBox, and replace the communication address in the configuration file with the local loopback address; Step a4: Control the vehicle-mounted TBox to initiate a connection request to the first port based on the local loopback address; Step a5: The remote command simulation module and the feedback signal simulation module receive connection requests through the first port respectively, and establish a two-way communication link with the vehicle TBox in response to the connection request.

[0052] Specifically, in the vehicle-mounted TBox testing system of this embodiment, when the host computer and the vehicle-mounted TBox deployed on the test bench achieve data interaction through local communication connection, the following steps need to be followed to complete the configuration in order to solve the problem that the test bench with the vehicle-mounted TBox installed and the host computer are usually not in the same network environment and cannot directly access the host computer service through IP address, and finally establish a stable bidirectional communication link.

[0053] First, local TCP / IP services are started for the remote command simulation module and the feedback signal simulation module within the host computer. The remote command simulation module, built on the TCP / IP protocol, needs to listen to the first port of the host computer (the first port can be one or include multiple sub-ports; this embodiment is not limited to this, for example, the remote command simulation module listens to the first sub-port tcp:8883 within the first port). This module will subsequently send remote control commands from the simulated cloud platform to the vehicle-mounted TBox through this port and receive the command execution results returned by the TBox. The specific format of the remote control commands and command execution results adopts a communication protocol consistent with the native support of the TBox (such as MQTT, HTTP, or a manufacturer's proprietary protocol) to ensure that the command data is compatible with the real environment. The feedback signal simulation module is also built on the TCP / IP protocol and needs to listen to the first port of the host computer (e.g., the second sub-port tcp:41122 within the first port). It will subsequently receive control signals output by the TBox through this port and send feedback signals simulating the vehicle controller. The communication protocol is also consistent with the native support of the TBox (such as CAN bus protocol or a manufacturer's proprietary protocol) to ensure the validity of the feedback signals.

[0054] Because the test bench equipment is isolated from the host computer's network environment, this embodiment of the invention utilizes the `adbreverse` command provided by the Android Debug Bridge (ADB) to reverse map the first port (first sub-port and second sub-port) of the host computer to the second port of the vehicle-mounted TBox. The second port corresponds to the local loopback address (127.0.0.1) of the vehicle-mounted TBox. Specifically, the `adbreverse` commands are `adbreversetcp:8883tcp:8883` and `adbreversetcp:41122tcp:41122`. Through this operation, when the vehicle-mounted TBox accesses the port corresponding to its local loopback address, data can be automatically transmitted to the corresponding first port of the host computer, breaking the network isolation barrier between the two.

[0055] Additionally, the communication logic of the vehicle-mounted TBox needs to be modified for compatibility. Only the configuration file parameters need to be adjusted; the core communication logic code remains unchanged. In the remote command interaction path, the vehicle-mounted TBox originally connected to the public IP address of the real cloud platform (e.g., cloud.tbox.com:8883) via a 4G / 5G network. This public IP address in the configuration file needs to be replaced with the local loopback address 127.0.0.1:8883. In the vehicle controller signal interaction path, the vehicle-mounted TBox originally communicated with the vehicle controller hardware via a CAN bus or SPI interface. This has now been refactored to a TCPSocket-based network communication method. The hardware communication address in the configuration file needs to be replaced with the local loopback address 127.0.0.1:41122 to ensure that the vehicle-mounted TBox can subsequently communicate with the host computer module via the local loopback address.

[0056] After the configuration file is modified, the vehicle TBox acts as a communication client. Based on the set local loopback address, it initiates connection requests to the first sub-port (127.0.0.1:8883) listened to by the remote command simulation module of the host computer and the second sub-port (127.0.0.1:41122) listened to by the feedback signal simulation module. At this time, the connection request of the vehicle TBox will be accurately transmitted to the corresponding module of the host computer through the second port mapping.

[0057] The host computer's remote command simulation module receives connection requests initiated by the TBox through its first sub-port (8883), while the feedback signal simulation module receives another connection request through its second sub-port (41122). After responding to the requests, both modules establish a bidirectional communication link with the vehicle-mounted TBox. This link can then be used to issue remote control commands, output control signals, receive feedback signals, and report execution results. This closed-loop testing of the TBox's remote control logic can be completed without relying on a mobile network, a real cloud platform, or a vehicle controller.

[0058] It is important to note that, based on the aforementioned communication mechanism, the remote command simulation module is built upon the TCP / IP protocol and employs the same communication protocols natively supported by the TBox under test, including but not limited to MQTT, HTTP, and vendor-defined proprietary protocols. This ensures that the TBox under test receives command data consistent with the real environment during testing. Similarly, the feedback signal simulation module is also built upon the TCP / IP protocol and employs the same communication protocols natively supported by the TBox under test, including but not limited to CAN bus and vendor-defined proprietary protocols. This ensures that the TBox under test receives feedback signal data consistent with the real environment during testing.

[0059] This invention achieves stable communication between the host computer and the vehicle-mounted TBox by starting a local TCP / IP service, performing port reverse mapping, and modifying configuration files. The ADB-based configuration method eliminates the need for large-scale modifications to the core control logic of the vehicle-mounted TBox, requiring only adjustments to communication-related parameters and port settings, thus reducing development costs and risks. The port reverse mapping technology resolves potential network isolation issues between the vehicle-mounted TBox and the host computer, ensuring efficient interaction between the two. The standardized configuration process ensures reproducible operation, allowing different developers to quickly build a communication link step-by-step, improving the consistency and efficiency of test environment setup.

[0060] This invention also provides a testing method for an in-vehicle TBox, such as... Figure 3 As shown, the method, applied to the host computer provided by the aforementioned test system, includes: Step S301: Generate remote control commands through the remote command simulation module and send the remote control commands to the vehicle TBox so that the vehicle TBox can parse the remote control commands and obtain control signals; Step S302: Receive control signals sent by the vehicle-mounted TBox through the feedback signal simulation module; Step S303: The feedback signal simulation module responds to the control signal, generates a feedback signal after the control is completed, and sends the feedback signal to the vehicle TBox so that the vehicle TBox can determine the command execution result based on the feedback signal. Step S304: Receive the command execution result sent by the vehicle-mounted TBox through the remote command simulation module, and compare the command execution result with the expected execution result; Step S305: Determine whether the vehicle-mounted TBox is qualified based on the comparison results.

[0061] Specifically, in this embodiment, a testing method for an in-vehicle TBox is provided. This method is applied to the host computer of the aforementioned in-vehicle TBox testing system. Through the collaborative interaction between the various functional modules in the host computer and the in-vehicle TBox, the remote control function of the TBox is verified.

[0062] First, remote control commands are generated through a remote command simulation module within the host computer. This module runs on the host computer, is built on the TCP / IP protocol, and uses the same communication protocol natively supported by the in-vehicle TBox. This ensures that the generated remote control commands are completely consistent with the command format and protocol specifications issued by the real cloud platform, and can be correctly parsed by the in-vehicle TBox. The generated remote control commands cover common remote control needs of intelligent connected vehicles, such as remotely unlocking doors, turning on the air conditioning, and controlling window operation. If a test case management module is configured, preset remote control command parameters can also be directly retrieved from this module. For details, please refer to the description in the aforementioned system embodiment; further elaboration is omitted here.

[0063] After the remote control command is generated, the remote command simulation module sends the command to the vehicle TBox via the established local communication link between the host computer and the vehicle TBox. Upon receiving the command, the vehicle TBox parses it according to its preset parsing logic, extracts the control parameters (such as air conditioning temperature and window control settings), and generates corresponding control signals based on these parameters, preparing for subsequent interaction with the feedback signal simulation module.

[0064] After the vehicle-mounted TBox generates a control signal, it sends it to the feedback signal simulation module on the host computer via a local communication link. The feedback signal simulation module also runs on the host computer, is built on the TCP / IP protocol, and uses a communication protocol consistent with the vehicle-mounted TBox's native support (such as the CAN bus protocol or manufacturer-specific protocols). It can accurately receive and parse the control signals sent by the vehicle-mounted TBox. Upon receiving the control signal, this module first performs a preliminary check on the signal's integrity and format correctness to ensure the accuracy of subsequent feedback signal generation. The specific signal reception and preliminary check logic is described in the aforementioned system embodiment regarding the feedback signal simulation module, and will not be repeated here.

[0065] After successfully receiving and verifying the control signal from the vehicle TBox, the feedback signal simulation module simulates the response behavior of the vehicle controller based on the content of the control signal, generating a feedback signal after the control is completed. For example, if the control signal is "Turn on the air conditioner (temperature 24℃, fan speed 2)" and there is no abnormal scenario configuration, the feedback signal will include information such as "Air conditioner started, current temperature 24℃, fan speed 2, execution status code 'success'".

[0066] After the feedback signal is generated, the feedback signal simulation module sends it to the vehicle-mounted TBox via the local communication link. After receiving the feedback signal, the vehicle-mounted TBox analyzes the status code, fault information and other contents in the feedback signal according to its own result judgment logic, and then judges the execution status of the remote control command and obtains the command execution result (such as "command execution successful" or "command execution failed, reason: compressor abnormality").

[0067] After the vehicle-mounted TBox generates the command execution result, it reports it to the remote command simulation module of the host computer via the local communication link. Upon receiving the execution result, the remote command simulation module retrieves the corresponding expected execution result from the preset test criteria. If the system is configured with a test case management module, the expected execution result is obtained from the test cases saved in that module; otherwise, it uses the standard result manually set before the test.

[0068] The remote command simulation module compares the actual received command execution results with the expected execution results item by item. The comparison includes the execution status (success / failure) and the consistency of related parameters, ensuring that the TBox's execution feedback to the command meets expectations.

[0069] After the remote command simulation module completes the result comparison, it will determine whether the vehicle-mounted TBox is qualified based on the comparison results. If the actual command execution result is completely consistent with the expected execution result, and there are no anomalies such as signal loss or parsing errors during the entire interaction process, the remote control function of the vehicle-mounted TBox in this test scenario is deemed qualified; if there is a difference between the two (such as the actual execution result being "failure" while the expected result is "success", or the fault code is mismatched), it is deemed unqualified, and the difference is marked so that developers can troubleshoot the problem later.

[0070] The interactive data (including remote control commands, control signals, feedback signals, execution results, and comparison results) throughout the entire testing process will be automatically recorded and a visual test report can be generated subsequently. For details, please refer to the description in the aforementioned system embodiment; further elaboration will not be repeated here. Through the above steps, closed-loop testing of the in-vehicle TBox remote control function can be achieved without relying on a real cloud platform or vehicle controller, effectively improving testing efficiency and accuracy.

[0071] In some optional implementations, the testing method for the vehicle-mounted TBox provided in this embodiment of the invention further includes: Step b1: Configure and save test cases through the test case management module. Test cases include remote control commands, control signals expected to be output by the vehicle TBox, feedback signals, and command execution results expected to be output by the vehicle TBox.

[0072] Specifically, the execution principle of the test case management module in step b1 can be found in the relevant description of the aforementioned system embodiment, and will not be repeated here.

[0073] In some optional implementations, the testing method for the vehicle-mounted TBox provided in this embodiment of the invention further includes: Step c1 involves recording the interaction data during the testing process through the log recording and analysis module, and generating a visual test report based on the interaction data.

[0074] Specifically, the execution principle of the log recording and analysis module in step c1 can be found in the relevant description of the aforementioned system embodiment, and will not be repeated here.

[0075] In some optional implementations, defining a remote control command or feedback signal as the target signal, the step of the host computer sending the target signal to the vehicle-mounted TBox includes: Step d1: The target signal is sent to the first port through the remote command simulation module or the feedback signal simulation module, so that the target signal is transmitted to the local loopback address of the vehicle TBox through the first port.

[0076] The steps for the host computer to receive the target signal include: Step d2: Listen to the target signal received at the first port through the remote command simulation module or the feedback signal simulation module.

[0077] Specifically, the principles of local data communication based on ADB in steps d1 and d2 can be found in the relevant descriptions of the aforementioned system embodiments, and will not be repeated here.

[0078] This invention also provides a testing method for an in-vehicle TBox, such as... Figure 4 As shown, the method applied to the vehicle-mounted TBox provided by the aforementioned test system includes: Step S401: Receive remote control command. The remote control command is a command generated by the host computer through the remote command simulation module. Step S402: Parse the remote control command to obtain the control signal; Step S403: Send a control signal to the host computer so that the host computer receives the control signal through the feedback signal simulation module and responds to the control signal through the feedback signal simulation module to generate a feedback signal after the control is completed. Step S404: Receive feedback signals sent by the host computer; Step S405: Determine the instruction execution result based on the feedback signal; Step S406: Send the instruction execution result to the host computer so that the host computer can receive the instruction execution result through the remote instruction simulation module, compare the instruction execution result with the expected execution result, and then determine whether the vehicle TBox is qualified based on the comparison result.

[0079] Specifically, the principles of steps S401 to S403 can be found in the relevant descriptions of the aforementioned system embodiments, and will not be repeated here.

[0080] In some optional implementations, the instruction execution result or control signal is used as the target signal. The step of the vehicle TBox sending the target signal to the host computer includes: sending the target signal to the second port so that the target signal is transmitted to the first port of the host computer through the second port, and the host computer obtains the target signal by listening to the first port; The steps for the vehicle-mounted TBox to receive the target signal include: obtaining the target signal by monitoring the local loopback address.

[0081] This invention also provides a computer-readable storage medium. The methods described above according to embodiments of the invention can be implemented in hardware or firmware, or implemented as computer code that can be recorded on a storage medium, or implemented as computer code downloaded via a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code, which, when accessed and executed by the computer, processor, or hardware, implements the methods shown in the above embodiments.

[0082] A portion of this invention can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to the invention through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions, or the computer compiling the instructions and then executing the corresponding compiled program, or the computer reading and executing the instructions, or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.

[0083] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A testing system for an in-vehicle TBox, characterized in that, include: Host computer and vehicle-mounted TBox; The host computer is equipped with a remote command simulation module and a feedback signal simulation module. The host computer is communicatively connected to the vehicle-mounted TBox. The remote command simulation module is used to simulate the cloud platform sending remote control commands to the vehicle-mounted TBox and receiving the command execution results returned by the vehicle-mounted TBox. Then, it determines whether the vehicle-mounted TBox is qualified based on the command execution results. The feedback signal simulation module is used to simulate the vehicle controller receiving the control signals output by the vehicle-mounted TBox and sending feedback signals to the vehicle-mounted TBox in response to the control signals. The control signals are obtained by the vehicle-mounted TBox from parsing the remote control commands, and the feedback signals are used by the vehicle-mounted TBox to analyze and obtain the command execution results.

2. The system according to claim 1, characterized in that, The host computer also deploys a test case management module, which is used to configure and save test cases. The test cases include the remote control command, the control signal expected to be output by the vehicle TBox, the feedback signal, and the command execution result expected to be output by the vehicle TBox.

3. The system according to claim 1, characterized in that, The host computer also deploys a log recording and analysis module, which is used to record the interaction data during the test process and generate a visual test report based on the interaction data.

4. The system according to claim 1, characterized in that, The host computer establishes a local communication connection with the vehicle-mounted TBox.

5. The system according to claim 4, characterized in that, The steps for configuring the host computer to establish a local communication connection with the vehicle-mounted TBox include: The remote command simulation module and the feedback signal simulation module respectively start local TCP / IP services on the host computer and listen to the first port of the host computer; The first port is reverse-mapped to the second port of the vehicle TBox using the Android debug bridge command. The second port is the port corresponding to the local loopback address of the vehicle TBox. Modify the configuration file of the vehicle TBox, and replace the communication address in the configuration file with the local loopback address; The vehicle-mounted TBox is controlled to initiate a connection request to the first port based on the local loopback address; The remote command simulation module and the feedback signal simulation module respectively receive the connection request through the first port, and establish a bidirectional communication link with the vehicle TBox in response to the connection request.

6. A testing method for an in-vehicle TBox, characterized in that, Applied to the host computer provided by any one of claims 1-5, the method includes: The remote control command is generated by the remote command simulation module and sent to the vehicle TBox so that the vehicle TBox can parse the remote control command to obtain the control signal. The control signal sent by the vehicle-mounted TBox is received through the feedback signal simulation module; The feedback signal simulation module responds to the control signal, generates a feedback signal after the control is completed, and sends the feedback signal to the vehicle TBox so that the vehicle TBox can determine the instruction execution result based on the feedback signal. The remote command simulation module receives the command execution result sent by the vehicle-mounted TBox and compares the command execution result with the expected execution result. The vehicle-mounted TBox is deemed qualified based on the comparison results.

7. The method according to claim 6, characterized in that, The method further includes: Test cases are configured and saved through the test case management module. The test cases include the remote control commands, the control signals expected to be output by the vehicle TBox, the feedback signals, and the command execution results expected to be output by the vehicle TBox.

8. The method according to claim 6, characterized in that, The method further includes: recording interaction data during the test process through a log recording and analysis module, and generating a visual test report based on the interaction data.

9. The method according to claim 6, characterized in that, The step of the host computer sending the target signal to the vehicle TBox, using the remote control command or the feedback signal as the target signal, includes: sending the target signal to the first port through the remote command simulation module or the feedback signal simulation module, so that the target signal is transmitted to the local loopback address of the vehicle TBox through the first port; The step of the host computer receiving the target signal includes: listening to the target signal received at the first port through the remote command simulation module or the feedback signal simulation module.

10. A testing method for an in-vehicle TBox, characterized in that, The method, applied to the in-vehicle TBox provided by any one of claims 1-5, comprises: Receive remote control commands, wherein the remote control commands are generated by the host computer through the remote command simulation module; The remote control command is parsed to obtain the control signal; The control signal is sent to the host computer, so that the host computer receives the control signal through the feedback signal simulation module, and responds to the control signal through the feedback signal simulation module to generate a feedback signal after the control is completed; Receive the feedback signal sent by the host computer; The instruction execution result is determined based on the feedback signal; The instruction execution result is sent to the host computer, so that the host computer receives the instruction execution result through the remote instruction simulation module, compares the instruction execution result with the expected execution result, and then determines whether the vehicle-mounted TBox is qualified based on the comparison result.

Images