An automatic testing device for a remote vehicle control system and a method for building the same

Abstract

The present application relates to the technical field of remote vehicle control system, and specifically provides an automatic testing device for remote vehicle control system and a building method thereof, which comprises the following steps: HIL load box system design; bench building and debugging; automatic testing framework design; system initialization design; code design; system debugging. The present application is based on python software engineering and HIL load box testing system, simulates remote instructions, achieves the purpose of controlling target output, supports precondition presetting, can set precondition before each use case execution, supports cyclic endurance testing, realizes continuous and uninterrupted automatic testing, and generates complete testing report, thereby realizing the stability and endurance testing of remote control service.

Description

Technical Field

[0001] This invention belongs to the field of remote vehicle control system technology, specifically relating to an automated testing device for a remote vehicle control system and its construction method. Background Technology

[0002] With the development of automotive intelligence, vehicle networking services, as an indispensable part of intelligent vehicles, are becoming increasingly widespread. Remote vehicle control, as its core component, requires car owners or testers to send relevant control commands (such as opening / closing windows, locking / unlocking, etc.) via a mobile app. This allows car owners to control and interact with their vehicles from their mobile phones, greatly enhancing the user experience and sense of technology.

[0003] Since the advent of software-defined vehicles, vehicle architecture has gradually transformed from the traditional distributed EE architecture to a service-oriented distributed architecture. For the vehicle body, this represents a shift from traditional CAN control to service control, and the current support for numerous remote control functions, such as remote window control and remote locking / unlocking, presents challenges for testers. Traditional system testing involves manually operating a mobile app to perform tests and check if the actuators on the vehicle respond successfully. This requires functional testing on multiple test phones, resulting in a large workload, long processing time, and low efficiency, necessitating significant investment of manpower and resources for remote testing. Furthermore, the new software architecture no longer supports the traditional CAN tool for simulating remote signals to test the body controller, presenting new challenges for testers and equipment. Summary of the Invention

[0004] The purpose of this invention is to provide an automated testing device and its construction method for a remote vehicle control system, in order to solve the problems of large workload, long testing time, low testing efficiency, and the need to invest a lot of manpower and resources in remote testing of existing vehicle systems.

[0005] To achieve the above-mentioned technical objectives, the technical solution adopted by the present invention is as follows:

[0006] In a first aspect, this application provides a method for constructing an automated testing device for a remote vehicle control system, comprising the following steps:

[0007] S110, a hardware platform for designing HIL load cell system based on host computer, controlled object HIL load cell and controller;

[0008] S120, connect the host computer, the controlled object HIL load cell and the controller hardware platform and perform debugging;

[0009] S130, Test engineering script design, the test engineering script is used to simulate the target controller of the vehicle sending communication messages or service instructions to the body controller under test, and to detect the communication messages fed back by the body controller under test.

[0010] S140, Initialize the controlled object HIL load cell based on the function;

[0011] S150, Design text test cases based on programming software, wherein the text test cases include at least the service instructions;

[0012] S160, Perform system debugging on the text test cases.

[0013] In conjunction with the first aspect, in some optional implementations, the host computer has embedded test management software and a real-time software test model, and the controller hardware platform is connected to the controlled object HIL load cell via a wiring harness. The object HIL load cell is pre-loaded with a wiring harness connected to the controller hardware platform.

[0014] In conjunction with the first aspect, in some optional implementations, the method includes: connecting the host computer to the controlled object HIL load cell; connecting the controlled object HIL load cell to the controller hardware platform; and the debugging includes verifying whether the wiring harness is connected, whether the basic communication settings of the host computer software and the bus communication are correct, and whether the data volume of the wiring harness channel is normal.

[0015] In conjunction with the first aspect, in some alternative implementations, the service instructions are programmed into a format and content that matches the target controller and / or the body controller.

[0016] In conjunction with the first aspect, in some optional implementations, the initialization includes: initializing the underlying code of the controlled object HIL load cell.

[0017] In conjunction with the first aspect, in some optional implementations, the steps further include: interface call encapsulation and use case design, wherein the use case design includes preconditions, test steps, expected results, actual results, and condition recovery.

[0018] In conjunction with the first aspect, in some optional implementations, the system debugging includes: outputting test results based on the comparison between the output value of the signal and the preset expected value.

[0019] Secondly, this application provides an automated testing device for the remote vehicle control system described above, comprising a host computer, a controlled object HIL load cell, and a controller hardware platform that are connected in sequence via communication.

[0020] The invention employing the above technical solution has the following advantages:

[0021] This invention, based on Python software engineering and the HIL load cell testing system, simulates remote commands to control target output. It supports precondition setting, allowing preconditions to be set before each test case execution. It also supports cyclic endurance testing, enabling continuous and uninterrupted automated testing and generating complete test reports, thus achieving stability and endurance testing of remote control services. Attached Figure Description

[0022] The present invention can be further illustrated by the non-limiting embodiments given in the accompanying drawings;

[0023] Figure 1 This is a block diagram of the automated testing device in the embodiments of this application;

[0024] Figure 2 This document outlines the process for setting up the test apparatus in the embodiments of this application.

[0025] Figure 3 This is a use case management design diagram in the embodiments of this application;

[0026] Figure 4 Screenshots showing Python use case designs in the embodiments of this application;

[0027] Figure 5 This is a test execution report for an embodiment of this application.

[0028] The symbols for the main components are explained below:

[0029] 1: Host computer; 2: Controller hardware platform; 3: Controlled object HIL load cell; 4: CAN / LIN device; 5: ETH; 6: CAN / LIN device; 7: I / O harness. Detailed Implementation

[0030] The present invention will be described in detail below with reference to the accompanying drawings and specific embodiments. It should be noted that similar or identical parts are referred to by the same reference numerals in the drawings or description. Implementations not shown or described in the drawings are forms known to those skilled in the art. In addition, directional terms mentioned in the embodiments, such as "up," "down," "top," "bottom," "left," "right," "front," and "back," are only for reference to the directions in the drawings and are not intended to limit the scope of protection of the present invention.

[0031] Combined with appendix Figure 1 This application provides a method for building an automated testing device for a remote vehicle control system, the method including the following steps:

[0032] S110, a HIL load cell system is designed based on host computer 1, controlled object HIL load cell 2 and controller hardware platform 3;

[0033] S120, connect the host computer 1, the controlled object HIL load box 2 and the controller hardware platform 3 and perform debugging;

[0034] S130, Test engineering script design, the test engineering script is used to simulate the target controller of the vehicle sending communication messages or service instructions to the body controller under test, and to detect the communication messages fed back by the body controller under test.

[0035] S140, Initialize the controlled object HIL load cell 2 based on its function;

[0036] S150, Design text test cases based on programming software, wherein the text test cases include at least the service instructions;

[0037] S160, Perform system debugging on the text test cases.

[0038] In step S110, a HIL load cell system is designed based on the host computer 1, the controlled object HIL load cell 2, and the controller hardware platform 3. The HIL (Hardware-in-the-Loop) test system can simulate switch or bus signal inputs according to the interface between the actual controlled object and the controller, and can also respond correctly to control commands and issue correct status values. It mainly consists of the host computer 1, the controller hardware platform 3, and the controlled object HIL load cell 2. The host computer 1 contains test management software and a real-time software test model. The controller hardware platform 3 is connected to the controlled object HIL load cell 2 via a customized wiring harness. The controlled object HIL load cell 2 can control the corresponding actuators according to the output frequency of the controller hardware platform 3. A CAN communication wiring harness connected to the controller hardware platform 3 is designed in the controlled object HIL load cell 2. Therefore, the host computer 1 (PC) is connected to the load cell via a CAN / LIN device 4 to simulate the signal transmission of an external controller and monitor and acquire the signal output of the controller under test.

[0039] In step S120, the host computer, the controlled object HIL load cell 2, and the controller hardware platform 3 are connected and debugged. The setup mainly involves connecting the host computer 1 to the controlled object HIL load cell 2, and the controlled object HIL load cell 2 to the controller hardware platform 3. The host computer 1 and the controlled object HIL load cell 2 are connected via a CAN / LIN device 4. The number of channels on the controller hardware platform 3 must correspond one-to-one with the communication devices for simulating input bus signals and acquiring output signals from the monitoring controller. See also the appendix... Figure 2When the controller has multiple communication nodes, the CAN channels set by the host computer 1 need to correspond to the communication nodes on the controller according to the network topology. For example, if the body controller has left and right modules, and a certain CAN module is connected to the right node, then when the host computer 1 simulates that CAN communication, the CAN harness needs to be connected to the right node, not the left node. Secondly, an ETH (Ethernet cable) 5 connection is used to simulate DDS service commands from the cloud. These commands are converted into the format required by the controller using Python code, thus meeting the service simulation input requirements. Connectivity debugging includes checking whether the harness is connected, whether the basic communication settings of the host computer software and bus communication are correct, and whether the data flow of each CAN channel is normal. The connection between the controlled object HIL load box 2 and the controller hardware platform 3 is achieved through CAN / LIN device 6 and I / O harness 7.

[0040] In step S130, a test engineering script is designed. This script simulates the target controller of the vehicle sending communication messages or service commands to the body controller under test, and detects the communication messages returned by the body controller under test. The test engineering script is written in PyCharm software. It simulates other controllers of the real vehicle sending communication messages or service commands to the body controller under test, and detects the communication messages returned by the body controller under test. Service commands need to be converted into the format and content required by the controller using Python programming to achieve the purpose of simulating service input. The conversion code needs to be encapsulated into a specific format of CMD call commands, such as: client execution file name service name_method name (parameters) method period value (MS) execution count. This type of service command can also be directly used in test cases during automated testing. Because the CAN device in this test system uses USBCAN, the device interface needs to be established in the code environment, and functions corresponding to the simulated and acquired messages or signals need to be encapsulated for easy calling by automated test cases.

[0041] In step S140, the controlled object HIL load cell 2 is initialized based on its functions. Each function or system must meet a series of preconditions before it can be effective, requiring the setting of relevant initialization conditions in the software environment. Simultaneously, the load cell and underlying code environment also need to be initialized. The load cell mainly consists of two categories: input and output for switch operations. These must be set to their default states; otherwise, it will affect the testing of other functional systems, leading to inaccurate input preconditions or abnormal output environments, resulting in incorrect output results. The underlying code environment includes the initialization of basic software settings and device interface calls. Power state switching, anti-theft functions, and locking / unlocking functions all require certain preconditions to be met before they can be operated. For example, the remote locking function requires prior judgment of the power state and the states of the four doors and trunk. Once the conditions are met, the function is effective after the mobile client operates the corresponding button; otherwise, various error codes will be returned. Different functions have different logic and preconditions, so each function needs to be set individually.

[0042] In step S150, text test cases are designed based on programming software. These text test cases include at least the service instructions. The USBCAN tool supports interface calls of various scripting languages. Based on the principles of convenience and ease of use, Python is chosen for test case script development. Python provides a very comprehensive basic code library and can also call a large number of third-party libraries. Before writing the test case code, the input based on the functional definition or requirements is designed into highly readable text test cases, including service instructions. Test case design should follow methods such as boundary value analysis, valid / invalid classification, state diagrams, and error guessing. Test case management adopts a hierarchical tree diagram method (see [link]). In addition to test cases, code design and integration are also required for device invocation, basic device communication settings, bus simulation, and data acquisition. A test case demo is available (see [link]). Figure 4 Specifically, Python development mainly includes two aspects: first, the calling and encapsulation of tool interfaces, enabling automatic API calls to send control commands and retrieve returned data within test cases. Regarding device settings, initial configurations are made based on actual conditions, such as device model, communication baud rate, channel, and communication type. Second, test case design, such as... Figure 4 Test case design should include preconditions, test steps, expected results, actual results, and condition recovery. Each step can optionally determine whether its output is correct. For example... Figure 3 To facilitate test case management, different functional systems are managed in layers. For example, the remote control system is a general folder, the second layer contains different remote control functions, such as remote unlocking, remote locking, and remote vehicle locator, and the third layer contains multiple test cases for each function, with each test case designed as a .py file.

[0043] In step S160, the text test cases are debugged using the system. After the environment and test cases are completed, the Python project and test cases need to be debugged. Figure 5 The report can monitor the output value of a signal for a certain step that needs to be judged, and compare it with the expected value. If the two are inconsistent, the test will fail (FAIL). Conversely, if the output value is consistent with the expected value, the test will pass (PASS) and an automated test report will be generated.

[0044] This application also provides an automated testing device for a remote vehicle control system, including a host computer 1, a controlled object HIL load cell 2, and a controller hardware platform 3 connected in sequence via communication.

[0045] In the embodiments provided in this application, it should be understood that the disclosed apparatus, systems, and methods can also be implemented in other ways. The apparatus, systems, and methods embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code, which includes one or more executable instructions for implementing a specified logical function. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions. Furthermore, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0046] The above provides a detailed description of an automated testing device for a remote vehicle control system and its construction method. The specific embodiments described are merely for the purpose of helping to understand the method and core ideas of this invention. It should be noted that those skilled in the art can make various improvements and modifications to this invention without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this invention.

Claims

1. A method for building an automatic test device of a remote vehicle control system, characterized in that, The method comprises the following steps: S110, designing a HIL load box system based on a host computer (1), a controlled object HIL load box (2), and a controller hardware platform (3); S120, connecting the host computer (1), the controlled object HIL load box (2), and the controller hardware platform (3) and debugging; S130, testing an engineering script design, the testing engineering script being used for simulating a target controller of a vehicle to send a communication message or a service instruction to a measured vehicle body controller and detecting a communication message fed back by the measured vehicle body controller; S140, initializing the controlled object HIL load box (2) based on a function; S150, designing a text test case based on programming software, the text test case at least comprising the service instruction; S160, performing system debugging on the text test case; The host computer and the controlled object HIL load box are connected through a CAN / LIN device (4), the number of channels of the controller hardware platform (3) needs to correspond to the communication device one by one, which is used for simulating input bus signals and collecting output signals of the controller for monitoring; The controlled object HIL load box is connected with the controller hardware platform 2. The automated test device build method of claim 1, wherein, The host computer is embedded with a test management software and a real-time software test model, the controller hardware platform is connected with the controlled object HIL load box based on a wire harness, and the object HIL load box is pre-provided with a wire harness connected with the controller hardware platform.

3. The automated test device build method of claim 1, wherein, The method comprises connecting the host computer with the controlled object HIL load box; the debugging comprises checking whether the wire harness is passable, whether the software communication basis setting of the host computer is correct, whether the bus communication is correct, and whether the data volume of the wire harness channel is normal.

4. The automated test device build method of claim 1, wherein, The service instruction is converted into a format and content matched with the target controller and / or the vehicle body controller based on programming.

5. The automated test device build method of claim 1, wherein, The initialization comprises initializing a bottom code of the controlled object HIL load box (2).

6. The automated test device build method of claim 1, wherein, The steps further comprise interface calling encapsulation and use case design, wherein the content of the use case design comprises a precondition, a test step, an expected result, an actual result, and a condition recovery.

7. The automated test device build method of claim 1, wherein, The system debugging comprises outputting a test result based on a comparison result of an output value of a signal with a preset expected value.

8. An automated testing device for a remote vehicle control system, characterized by, The application discloses an automatic testing device building method applied to a remote vehicle control system.

Images