Test method of vehicle end controller and related equipment

Abstract

The invention provides a test method of a vehicle end controller and related equipment, and is applied to a server, the method comprises the following steps: responding to a received data item reading request sent by a to-be-tested controller to at least one simulated test virtual node, and controlling a target test virtual node in the at least one test virtual node to execute a preset fault operation. Feedback operation information generated when the controller to be tested executes feedback operation for the fault operation is collected. And analyzing the feedback operation information, and determining whether the feedback operation is a fault removal operation corresponding to the fault operation. Different fault operations have corresponding fault removal operations, and the controller to be tested needs to execute the corresponding fault removal operations for the fault operations of a specific type. And determining that the to-be-tested controller passes the test if the feedback operation is a fault removal operation corresponding to the fault operation, the execution operation of the to-be-tested controller is correct, and the to-be-tested controller does not have a performance fault.

Description

Technical Field

[0001] The present application relates to the field of vehicle testing technology, and in particular to a testing method and related equipment for a vehicle-side controller. Background Art

[0002] When the vehicle is upgrading via Over-the-Air Technology (OTA), the vehicle body controller needs to read the software and hardware configuration information of the electronic control unit that needs to be upgraded. If the body controller encounters a reading anomaly when reading the software and hardware configuration information of the electronic control unit, the cause of the anomaly cannot be located, resulting in the failure of the OTA upgrade. Therefore, when the vehicle is offline, the body controller needs to be tested for performance to avoid the phenomenon of being unable to locate the cause of the anomaly.

[0003] However, since the interaction process between the body controller and each electronic control unit is in a black box state and is invisible to testers, it brings certain difficulties to the performance detection of the body controller. Summary of the invention

[0004] In view of this, the purpose of this application is to propose a vehicle-side controller testing method and related equipment to solve the problem of difficulty in vehicle body controller performance testing.

[0005] Based on the above purpose, the first aspect of the present application provides a testing method of a vehicle-side controller, which is applied to a server, comprising:

[0006] In response to receiving a data item read request sent by the controller under test to at least one simulated test virtual node, controlling a target test virtual node in the at least one test virtual node to perform a preset fault operation;

[0007] collecting feedback operation information generated when the controller under test performs a feedback operation on the fault operation;

[0008] Parsing the feedback operation information to determine whether the feedback operation is a troubleshooting operation corresponding to the fault operation;

[0009] In response to the feedback operation being a troubleshooting operation corresponding to the fault operation, it is determined that the controller under test passes the test.

[0010] The second aspect of the present application further provides a test device for a vehicle-side controller, which is applied to a server, and includes:

[0011] an execution module, configured to control a target test virtual node in the at least one test virtual node to execute a preset fault operation in response to receiving a data item read request sent by the controller to be tested to the at least one test virtual node to be simulated;

[0012] A collection module, configured to collect feedback operation information generated when the controller to be tested performs a feedback operation on the fault operation;

[0013] A parsing module, configured to parse the feedback operation information to determine whether the feedback operation is a troubleshooting operation corresponding to the fault operation;

[0014] The determination module is configured to determine that the controller under test passes the test in response to the feedback operation being a troubleshooting operation corresponding to the fault operation.

[0015] The third aspect of the present application also provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable by the processor, wherein the processor implements the method described in the first aspect when executing the computer program.

[0016] The fourth aspect of the present application also provides a non-transitory computer-readable storage medium, which stores computer instructions, and the computer instructions are used to enable a computer to execute the method described in the first aspect.

[0017] As can be seen from the above, the vehicle-side controller test method and related equipment provided by the present application are applied to the server, and the method includes: in response to receiving a data item read request sent by the controller to be tested to at least one simulated test virtual node, controlling the target test virtual node in at least one test virtual node to perform a preset fault operation. A fault test environment can be provided for the controller to be tested to test the operation behavior of the controller to be tested when the virtual node feedbacks a fault. The fault operation can be flexibly set according to the performance of the controller to be tested to be tested. The feedback operation information generated when the controller to be tested performs a feedback operation on the fault operation is collected. When the controller to be tested performs a feedback operation on the fault operation, feedback operation information will be generated synchronously, and the feedback operation information records the feedback operation process of the controller to be tested. The feedback operation information generated by the feedback operation can be collected to understand whether the controller to be tested can make a correct operation in the case of fault feedback through the feedback operation information. The feedback operation information is parsed to determine whether the feedback operation is a troubleshooting operation corresponding to the fault operation. Different fault operations have corresponding troubleshooting operations, and the controller to be tested needs to perform corresponding troubleshooting operations for specific types of fault operations. In response to the feedback operation being a troubleshooting operation corresponding to the fault operation, indicating that the controller under test performs the operation correctly and there is no performance fault in the controller under test, it is determined that the controller under test passes the test. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] In order to more clearly illustrate the technical solutions in the present application or related technologies, the drawings required for use in the embodiments or related technical descriptions are briefly introduced below. Obviously, the drawings described below are only embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0019] Figure 1 A flowchart for reading software and hardware configuration information of an electronic control unit according to an embodiment of the present application;

[0020] Figure 2 A flow chart of a method for testing a vehicle-side controller according to an embodiment of the present application;

[0021] Figure 3 A schematic diagram of the structure of the test environment of an embodiment of the present application;

[0022] Figure 4 A schematic diagram of the structure of a test device for a vehicle-side controller according to an embodiment of the present application;

[0023] Figure 5 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0024] In order to make the objectives, technical solutions and advantages of the present application more clearly understood, the present application is further described in detail below in combination with specific embodiments and with reference to the accompanying drawings.

[0025] It should be noted that, unless otherwise defined, the technical terms or scientific terms used in the embodiments of the present application should be the usual meanings understood by people with ordinary skills in the field to which the present application belongs. The "first", "second" and similar words used in the embodiments of the present application do not represent any order, quantity or importance, but are only used to distinguish different components. "Including" or "comprising" and similar words mean that the elements or objects appearing in front of the word cover the elements or objects listed after the word and their equivalents, without excluding other elements or objects. "Connect" or "connected" and similar words are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. "Up", "down", "left", "right" and the like are only used to indicate relative positional relationships. When the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0026] As vehicle functions become more and more abundant, the number of electronic control units inside the vehicle is also increasing. When performing OTA upgrades on vehicles, if a single electronic control unit is flashed, it will consume a lot of time and energy, and also cause idle waste of bus resources. Therefore, in the OTA upgrade process, a parallel flashing method is adopted to save a lot of flashing time. The purpose of parallel flashing is to make the best use of bandwidth resources. After sending a diagnostic request to an electronic control unit, you can directly send a diagnostic request to the electronic control unit of another network segment without waiting for its response, so as to achieve the purpose of flashing multiple electronic control units at the same time, improve bandwidth utilization, and greatly shorten the flashing time.

[0027] The parallel flashing process specifically includes: when the vehicle is performing an OTA upgrade, the remote server will send the configuration file used for the upgrade to the head unit (HUT), and the head unit will determine the multiple electronic control units (ECUs) that need to be upgraded based on the configuration file. Before the upgrade, the vehicle will read the software and hardware configuration information of the multiple electronic control units that need to be upgraded through the central electronic module (CEM). Figure 1 The flowchart of reading the software and hardware configuration information of the electronic control unit is shown in FIG. Figure 1 As shown, the vehicle computer sends a read instruction of the software and hardware configuration information to the body controller, and the body controller sends a read request to multiple electronic control units that need to be upgraded at the same time according to the read instruction. The software and hardware configuration information of each electronic control unit includes a variety of information. For example, the hardware configuration information includes the part number, node number, and serial number, etc., which are correspondingly recorded as hardware configuration information 1, hardware configuration information 2, hardware configuration information 3, etc. in the figure. Similarly, the software configuration information also includes a variety of information, such as the software version number, release date, and developer information, etc., which are correspondingly recorded as software configuration information 1, software configuration information 2, and software configuration information 3, etc. in the figure.

[0028] When the body controller collects the software and hardware version information of each electronic control unit in the vehicle, it will periodically feedback the online information to the vehicle computer so that the vehicle computer knows that the body controller is always in the process of collecting information. When the body controller has collected the hardware version information or software version information, it will uniformly feedback all the acquired information to the vehicle computer. If the software and hardware version information of one of the electronic control units is not fully read, the body controller will not feedback the software and hardware version information of the electronic control unit to the vehicle computer. After the information of all electronic control units is read, if the vehicle computer does not receive the software and hardware version information of any electronic control unit, it means that the electronic control unit is a faulty electronic control unit, and the faulty electronic control unit is located.

[0029] However, if one of the electronic control units returns abnormal data (such as response timeout, error, or continuous busy state), and the body controller does not perform corresponding feedback operations for the abnormal situation, but continues to wait for the electronic control unit to return one of the software and hardware configuration information, and no longer continues to read other software and hardware configuration information of the electronic control unit, the entire OTA upgrade process cannot proceed. Since the interaction process between the body controller and the electronic control unit is in a black box state, the inspector cannot view the internal interaction process, and the problem of being unable to locate the faulty electronic control unit arises. Therefore, whether the body controller can perform corresponding feedback operations for abnormal situations will directly affect the location of the faulty electronic control unit, and thus affect the vehicle's OTA upgrade process.

[0030] In view of this, the present application proposes a vehicle-side controller testing method, which performs performance testing on the body controller when the vehicle is offline, and converts the black box state of the interaction between the body controller and the electronic control unit into a gray box state or even a white box state. The tester can intuitively understand the interaction process between the body controller and the electronic control unit to test whether the body controller can perform corresponding feedback operations when the electronic control unit returns abnormal data. If the body controller can perform the corresponding correct feedback operation, it means that the body controller does not have the above-mentioned performance problems, and can assist in determining the faulty electronic control unit during the OTA upgrade process.

[0031] The embodiments of the present application are described in detail below with reference to the accompanying drawings.

[0032] This application proposes a test method for a vehicle-side controller, which is applied to the server side. Figure 2 , including the following steps:

[0033] Step 102 : In response to receiving a data item read request sent by the controller under test to at least one simulated test virtual node, controlling a target test virtual node in the at least one test virtual node to execute a preset fault operation.

[0034] Specifically, the server in this embodiment can be a host computer or test platform for testing the controller to be tested. The server integrates the test script to perform performance testing on the controller to be tested. At the same time, the server can also configure a configuration file for testing the controller to be tested, collect test data during the test, and analyze and generate a test report.

[0035] The test virtual node in this embodiment is constructed according to the simulation software and is used to simulate the vehicle network node in the vehicle that is connected to the controller under test. Each test virtual node contains multiple data item information, and the controller under test can read the data item information of the test virtual node. When there is a need to read the data item information, the controller under test will send a data item read request to at least one test virtual node.

[0036] Exemplarily, the controller to be tested is a body controller in a vehicle, and the test virtual node is an electronic control unit in a simulated vehicle. The data item may be a plurality of software and hardware configuration information included in the ECU. During the OTA upgrade process, when the CEM needs to read the software and hardware configuration information of multiple ECUs, it is necessary to send a data item read request to each ECU. If the data item is read normally, the ECU will feed back its own software and hardware configuration information to the CEM one by one. In order to test the feedback operation of the CEM under abnormal reading conditions, in this embodiment, the target test virtual node is controlled by the server to send a preset fault operation to the CEM. The target test virtual node is a test virtual node that sends a preset fault operation specified by the server.

[0037] In addition, the server can also control multiple target test virtual nodes to perform fault operations at the same time, and the fault operations performed by each target test virtual node can be different. For example, the first target test virtual node performs a response timeout fault operation, and the second target test virtual node performs an error fault operation. Through different fault operations, it can be detected whether the controller under test can perform the troubleshooting operation corresponding to each fault operation under different fault operations. In this way, the performance of the controller under test can be comprehensively evaluated.

[0038] Step 104: Collect feedback operation information generated when the controller under test performs a feedback operation for the fault operation.

[0039] Specifically, when the controller under test performs a feedback operation, corresponding feedback operation information will be generated, and the server collects the feedback operation information to evaluate the feedback operation of the controller under test. Determine whether the feedback operation is a correct operation corresponding to the fault operation. By collecting feedback operation information on the server, the purpose of visualizing the operation behavior of the controller under test can be achieved. The test personnel can intuitively see the interaction between the controller under test and the test virtual node on the server, which provides convenience for the detection of the controller under test.

[0040] Step 106: parse the feedback operation information to determine whether the feedback operation is a troubleshooting operation corresponding to the fault operation.

[0041] Specifically, the troubleshooting operation is an operation that the controller under test needs to perform correctly when it receives abnormal feedback, so as to avoid the controller under test continuously waiting for the test virtual node to feedback normal data and being unable to continue the subsequent data item reading process. If it is determined from the feedback operation information that the controller under test has not performed the corresponding troubleshooting operation, it is determined that there is a fault problem in the controller under test, and the inspection personnel need to maintain or debug the controller under test.

[0042] Step 108: In response to the feedback operation being a troubleshooting operation corresponding to the fault operation, determining that the controller to be tested passes the test.

[0043] Specifically, if it is determined from the feedback operation information that the controller under test has executed the correct troubleshooting operation corresponding to the fault operation, it means that the performance of the controller under test is good and there is no fault problem, and the controller under test passes the test.

[0044] At the same time, since the server can automatically analyze the feedback operation information, it reduces the time and cost of manual analysis and improves the test efficiency and accuracy of the controller under test. If it is determined that there is a problem with the controller under test, the time and cause of the problem will be marked in the test report and fed back to the tester, so that the tester can repair the faulty controller under test.

[0045] Based on the above steps 102 to 108, this embodiment provides a test method and related equipment for a vehicle-side controller, including: in response to receiving a data item read request sent by the controller to be tested to at least one simulated test virtual node, controlling the target test virtual node in at least one test virtual node to perform a preset fault operation. A fault test environment can be provided for the controller to be tested to test the operation behavior of the controller to be tested when the virtual node feedbacks a fault. The fault operation can be flexibly set according to the performance of the controller to be tested to be tested. The feedback operation information generated when the controller to be tested performs a feedback operation on the fault operation is collected. When the controller to be tested performs a feedback operation on the fault operation, feedback operation information will be generated synchronously, and the feedback operation information records the feedback operation process of the controller to be tested. The feedback operation information generated by the feedback operation can be collected to understand whether the controller to be tested can perform correct operations in the case of fault feedback through the feedback operation information. The feedback operation information is parsed to determine whether the feedback operation is a troubleshooting operation corresponding to the fault operation. Different fault operations have corresponding troubleshooting operations, and the controller to be tested needs to perform corresponding troubleshooting operations for specific types of fault operations. In response to the feedback operation being a troubleshooting operation corresponding to the fault operation, indicating that the controller under test performs the operation correctly and there is no performance fault in the controller under test, it is determined that the controller under test passes the test.

[0046] The above embodiments describe that fault operations include multiple types, which are described in detail below through multiple embodiments.

[0047] In some embodiments, the fault operation includes that the target test virtual node does not respond to the data item read request within a first preset time period; and determining whether the feedback operation is a troubleshooting operation corresponding to the fault operation includes:

[0048] In response to the feedback operation being a first operation, determining that the feedback operation is a troubleshooting operation corresponding to the fault operation;

[0049] Among them, the first operation includes: the controller under test sends a data item read request to the target test virtual node again a predetermined number of times, and when the controller under test does not receive data returned by the target test virtual node for the data item read request, the controller under test skips reading the current data item of the target test virtual node and starts reading the next data item of the target test virtual node.

[0050] Specifically, if the target test virtual node does not respond to the data item read request within the first preset time period, it means that the target test virtual node response has timed out. If the feedback operation performed by the controller to be tested is the first operation, it is determined that the feedback operation is a troubleshooting operation corresponding to the fault operation.

[0051] The specific process of the first operation includes: resending a data item read request to the target test virtual node. If the target test virtual node successfully returns the data of the current data item to the controller under test, the controller under test receives the returned data and continues to read the next data item. If the controller under test does not receive the data returned by the target test virtual node after sending the data item read request a predetermined number of times, it is determined that a failure has occurred in the current data item reading process of the target test virtual node. The controller under test does not need to continue waiting for the target test virtual node to return data, but directly skips the current data item and reads the next data item of the target test virtual node. Exemplarily, the first preset time length can be 50ms, and the predetermined number of times can be three times.

[0052] Through the method of this embodiment, when the target test virtual node responds to a timeout, it is possible to detect whether the controller under test can automatically execute the action of repeatedly sending a data item read request to the target test virtual node. If it can be automatically executed, it means that the feedback operation of the controller under test in response to the response timeout is correct. Repeatedly sending a data item read request can also eliminate communication interference and other problems to determine that the target test virtual node does have a data return failure, thereby avoiding missing data item reading.

[0053] In yet another embodiment, the fault operation includes the target test virtual node sending read error information to the controller under test; and determining whether the feedback operation is a troubleshooting operation corresponding to the fault operation includes:

[0054] In response to the feedback operation being a second operation, determining that the feedback operation is a troubleshooting operation corresponding to the fault operation; wherein the second operation includes: the controller under test skips reading a current data item of the target test virtual node and starts reading a next data item of the target test virtual node.

[0055] Specifically, if the target test virtual node sends a read error message to the controller under test, it means that the target test virtual node reports an error for the current data item, and the current data item has an error or does not exist. At this time, if the feedback operation performed by the controller under test is the second operation, it is determined that the feedback operation is a troubleshooting operation corresponding to the fault operation.

[0056] The specific process of the second operation includes: the controller under test does not need to continue to wait for the target test virtual node to return data, directly skips the current data item, and reads the next data item of the target test virtual node. The target test virtual node includes multiple data items. When reading, there is a reading order between the multiple data items. If the current data item is skipped, the next data item will be read according to the reading order.

[0057] By using the method of this embodiment, when an error occurs in the target test virtual node, the controller under test can learn that there is a read error in the current data item, and there is no need to repeatedly send a data item read request, and the next data item can be directly read. In this way, it is possible to avoid continuing to send a data item read request when a read error has been determined, reduce unnecessary information exchanges, and save data reading time.

[0058] In another embodiment, the fault operation includes that the target test virtual node still does not return data within a second preset time after sending busy information to the controller under test; and determining whether the feedback operation is a troubleshooting operation corresponding to the fault operation includes:

[0059] In response to the feedback operation being a third operation, determining that the feedback operation is a troubleshooting operation corresponding to the fault operation; wherein the third operation includes: the controller under test skips reading a current data item of the target test virtual node and starts reading a next data item of the target test virtual node.

[0060] Specifically, if the target test virtual node sends a busy message to the controller to be tested, it means that the target test virtual node is in a busy state, and the controller to be tested needs to wait for a period of time, and the target test virtual node delays returning data. However, if the target test virtual node still does not return data within the second preset time length after sending the busy message, it means that the current data item of the target test virtual node may have a read error problem. If the controller to be tested continues to wait at this time, it may not be able to receive the data returned by the target test virtual node. Therefore, the controller to be tested needs to perform the third operation immediately. If the feedback operation performed by the controller to be tested is the third operation, it is determined that the feedback operation is a troubleshooting operation corresponding to the fault operation. The specific process of the third operation includes: the controller to be tested does not need to continue to wait for the target test virtual node to return data, directly skips the current data item, and reads the next data item of the target test virtual node. That is to say, in the above case, the controller to be tested can immediately skip the current data item reading, avoid wasting waiting time, and continue to read the next data item. Exemplarily, the second preset time length can be 11s.

[0061] Through the method of this embodiment, when the target test virtual node returns a busy state but does not return data, in order to avoid infinite waiting of the controller under test, the controller under test needs to immediately jump to read the next data item to avoid causing a significant delay in the entire data reading process.

[0062] It should be noted that the above three embodiments are only exemplary descriptions of fault operations and troubleshooting operations and have no limiting effect. Similarly, if the target test virtual node has other fault operations, the controller to be tested can be determined to perform corresponding troubleshooting operations based on the fault operations. Then, by controlling the target test virtual node to perform the fault operation, it is tested whether the controller to be tested can correctly perform the troubleshooting operation.

[0063] Figure 3 The schematic diagram of the structure of the test environment of this application is shown. Figure 3As shown, the server is connected to the controller under test through an external tester, and the controller under test is connected to the vehicle computer. The server can simulate the vehicle CAN network, including various CAN nodes and ECUs, by performing network simulation and simulation through the automatic test software installed. By collaborating with the external tester, the server can collect communication data on the CAN bus through the interface between the external tester and the controller under test. Afterwards, the automatic test software installed inside the server can capture, analyze and record the communication data on the CAN bus in order to detect errors, optimize performance and solve communication problems. The automatic test software also provides powerful diagnostic functions for identifying and solving faults and monitoring the health of the test environment. In addition, the automatic test software can create automated test scripts and test cases for large-scale testing and verification. The test personnel can simulate fault conditions such as signal loss, noise injection, etc. through the automatic test software. A test environment for detecting the controller under test is built through the server, external tester and automatic test software, which provides the possibility for the detection of the controller under test and solves the problem of technicians' difficulty in detecting the performance of the controller under test.

[0064] In this embodiment, multiple virtual nodes are obtained by simulating the automatic test software, and each virtual node is connected to the controller to be tested. By simulating the virtual nodes, a simulation test environment is provided for the controller to be tested, which facilitates the testing of various performances of the controller to be tested and simplifies the testing process. The test script can be configured through the server, and the controller to be tested is tested through the test script. The server can also control each virtual node to perform predetermined operations, and control the information interaction between each virtual node and the controller to be tested. The interactive information generated during the information interaction process is collected to visualize the interactive process of the controller to be tested, which is convenient for the detection personnel to view through the server. The interactive information can also be used to determine whether the controller to be tested has a performance failure, and whether the correct feedback operation can be made when the virtual node returns a data failure. The following describes how to test the performance of the controller to be tested under the above-mentioned test environment through a specific embodiment.

[0065] In some embodiments, in response to receiving a data item read request sent by the controller under test to at least one simulated test virtual node, before controlling a target test virtual node in at least one test virtual node to perform a preset fault operation, the method includes:

[0066] Generate a configuration file, and send the configuration file to the vehicle computer, so that the vehicle computer determines at least one test virtual node from multiple simulated virtual nodes according to the configuration file, and sends a data item read request for at least one test virtual node to the controller under test, so that the controller under test sends the data item read request to at least one test virtual node.

[0067] Specifically, build it like Figure 3 After the test environment is established, the server generates a configuration file according to the test content. The configuration file specifies the virtual nodes participating in the test. The configuration file is sent to the vehicle computer, and the vehicle computer determines at least one test virtual node from the multiple simulated virtual nodes according to the instructions of the configuration file. The test virtual node simulates the electronic control unit that currently needs to be upgraded during the OTA upgrade process. The controller to be tested can be the body controller CEM. The vehicle computer sends a data item read request for at least one test virtual node to the controller to be tested based on the at least one test virtual node that has been determined. After receiving the data item read request, the controller to be tested forwards the data item read request to each test virtual node to read the information of each data item of each test virtual node. After that, the server selects a target test virtual node from at least one test virtual node, and controls the target test virtual node to perform a predetermined fault operation to perform a performance test on the controller to be tested.

[0068] It should be noted that the data volume of the target test virtual node is at least one. When the number of target test virtual nodes is multiple, the fault operations performed by each target test virtual node can be the same or different. When they are the same, multiple tests can be performed on the controller to be tested for one fault operation to ensure the performance stability of the controller to be tested. If they are different, the feedback operation of the controller to be tested can be tested for different fault operations to improve the comprehensiveness of the test.

[0069] Through the method of this embodiment, a test environment for testing the performance of the controller to be tested is built, and some preliminary preparation conditions for testing the performance of the controller to be tested are given to ensure that the subsequent test process proceeds smoothly. By flexibly setting test cases and generating configuration files on the server side, various performances of the controller to be tested are tested, which provides convenience for testers to test the controller to be tested.

[0070] It should be noted that the method of the embodiment of the present application can be performed by a single device, such as a computer or server. The method of this embodiment can also be applied to a distributed scenario and completed by multiple devices cooperating with each other. In the case of such a distributed scenario, one of the multiple devices can only perform one or more steps in the method of the embodiment of the present application, and the multiple devices will interact with each other to complete the described method.

[0071] It should be noted that the above describes some embodiments of the present application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in an order different from that in the above embodiments and still achieve the desired results. In addition, the processes depicted in the accompanying drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0072] Based on the same inventive concept, corresponding to any of the above-mentioned embodiment methods, the present application also provides a testing device for a vehicle-side controller.

[0073] refer to Figure 4 , the test device of the vehicle-side controller comprises:

[0074] An execution module 402 is configured to control a target test virtual node in the at least one test virtual node to execute a preset fault operation in response to receiving a data item read request sent by the controller under test to the at least one test virtual node under simulation;

[0075] The collection module 404 is configured to collect feedback operation information generated when the controller under test performs a feedback operation for the fault operation;

[0076] The parsing module 406 is configured to parse the feedback operation information to determine whether the feedback operation is a troubleshooting operation corresponding to the fault operation;

[0077] The determination module 408 is configured to determine whether the controller under test passes the test in response to the feedback operation being a troubleshooting operation corresponding to the fault operation.

[0078] In some embodiments, the fault operation includes that the target test virtual node does not respond to the data item read request within a first preset time period; the parsing module 406 is configured to, in response to the feedback operation being a first operation, determine that the feedback operation is a troubleshooting operation corresponding to the fault operation;

[0079] Among them, the first operation includes: the controller under test sends a data item read request to the target test virtual node again a predetermined number of times, and when the controller under test does not receive data returned by the target test virtual node for the data item read request, the controller under test skips reading the current data item of the target test virtual node and starts reading the next data item of the target test virtual node.

[0080] In some embodiments, the fault operation includes the target test virtual node sending a read error message to the controller under test; the parsing module 406 is configured to determine that the feedback operation is a troubleshooting operation corresponding to the fault operation in response to the feedback operation being a second operation; wherein the second operation includes: the controller under test skips reading the current data item of the target test virtual node and starts reading the next data item of the target test virtual node.

[0081] In some embodiments, the fault operation includes that the target test virtual node still does not return data within a second preset time period after sending a busy message to the controller under test; the parsing module 406 is configured to determine that the feedback operation is a troubleshooting operation corresponding to the fault operation in response to the feedback operation being a third operation; wherein the third operation includes: the controller under test skips reading the current data item of the target test virtual node and starts reading the next data item of the target test virtual node.

[0082] In some embodiments, in response to receiving a data item read request sent by the controller under test to at least one simulated test virtual node, before controlling a target test virtual node in at least one test virtual node to perform a preset fault operation, it also includes a configuration module, which is configured to generate a configuration file and send the configuration file to the vehicle computer so that the vehicle computer determines at least one test virtual node among multiple simulated virtual nodes according to the configuration file, and sends a data item read request for at least one test virtual node to the controller under test, so that the controller under test sends the data item read request to at least one test virtual node.

[0083] In some embodiments, the multiple virtual nodes are simulated by the server using automatic testing software.

[0084] In some embodiments, the feedback operation information is collected by an external tester, and the external tester is respectively connected to the server and the controller to be tested for communication.

[0085] For the convenience of description, the above device is described in terms of functions divided into various modules. Of course, when implementing the present application, the functions of each module can be implemented in the same or multiple software and / or hardware.

[0086] The device of the above embodiment is used to implement the testing method of the corresponding vehicle-side controller in any of the above embodiments, and has the beneficial effects of the corresponding method embodiment, which will not be repeated here.

[0087] Based on the same inventive concept, corresponding to any of the above-mentioned embodiments, the present application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, the test method of the vehicle-side controller described in any of the above embodiments is implemented.

[0088] Figure 5 A more specific schematic diagram of the hardware structure of an electronic device provided in this embodiment is shown, and the device may include: a processor 1010, a memory 1020, an input / output interface 1030, a communication interface 1040, and a bus 1050. The processor 1010, the memory 1020, the input / output interface 1030, and the communication interface 1040 are connected to each other through the bus 1050 in the device.

[0089] The processor 1010 can be implemented by a general-purpose CPU (Central Processing Unit), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this specification.

[0090] The memory 1020 may be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory), static storage device, dynamic storage device, etc. The memory 1020 may store an operating system and other application programs. When the technical solutions provided in the embodiments of this specification are implemented by software or firmware, the relevant program codes are stored in the memory 1020 and are called and executed by the processor 1010.

[0091] The input / output interface 1030 is used to connect the input / output module to realize information input and output. The input / output module can be configured in the device as a component (not shown in the figure), or it can be externally connected to the device to provide corresponding functions. The input device may include a keyboard, a mouse, a touch screen, a microphone, various sensors, etc., and the output device may include a display, a speaker, a vibrator, an indicator light, etc.

[0092] The communication interface 1040 is used to connect a communication module (not shown) to realize communication interaction between the device and other devices. The communication module can realize communication through a wired mode (such as USB, network cable, etc.) or a wireless mode (such as mobile network, WIFI, Bluetooth, etc.).

[0093] The bus 1050 includes a path that transmits information between the various components of the device (eg, the processor 1010, the memory 1020, the input / output interface 1030, and the communication interface 1040).

[0094] It should be noted that, although the above device only shows the processor 1010, the memory 1020, the input / output interface 1030, the communication interface 1040 and the bus 1050, in the specific implementation process, the device may also include other components necessary for normal operation. In addition, it can be understood by those skilled in the art that the above device may also only include the components necessary for implementing the embodiments of the present specification, and does not necessarily include all the components shown in the figure.

[0095] The electronic device of the above-mentioned embodiment is used to implement the testing method of the corresponding vehicle-side controller in any of the above-mentioned embodiments, and has the beneficial effects of the corresponding method embodiment, which will not be repeated here.

[0096] Based on the same inventive concept, corresponding to any of the above-mentioned embodiment methods, the present application also provides a non-transitory computer-readable storage medium, wherein the non-transitory computer-readable storage medium stores computer instructions, and the computer instructions are used to enable the computer to execute the testing method of the vehicle-side controller as described in any of the above embodiments.

[0097] The computer-readable medium of this embodiment includes permanent and non-permanent, removable and non-removable media, and information storage can be implemented by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, read-only compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device.

[0098] The computer instructions stored in the storage medium of the above embodiment are used to enable the computer to execute the testing method of the vehicle-side controller as described in any of the above embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0099] Based on the same concept, corresponding to any of the above-mentioned embodiment methods, the present application also provides a computer program product, including computer program instructions. When the computer program instructions are run on a computer, the computer executes the method described in any of the above embodiments, which has the beneficial effects of the corresponding method embodiments and will not be repeated here.

[0100] A person skilled in the art should understand that the discussion of any of the above embodiments is merely illustrative and is not intended to imply that the scope of the present application is limited to these examples. In line with the concept of the present application, the technical features in the above embodiments or different embodiments may be combined, the steps may be implemented in any order, and there are many other variations of the different aspects of the embodiments of the present application as described above, which are not provided in detail for the sake of simplicity.

[0101] In addition, to simplify the description and discussion, and in order not to make the embodiments of the present application difficult to understand, the known power supply / ground connection with the integrated circuit (IC) chip and other components may or may not be shown in the provided drawings. In addition, the device can be shown in the form of a block diagram to avoid making the embodiments of the present application difficult to understand, and this also takes into account the fact that the details of the implementation of these block diagram devices are highly dependent on the platform to be implemented in the embodiments of the present application (that is, these details should be fully within the scope of understanding of those skilled in the art). In the case of elaborating specific details (e.g., circuits) to describe exemplary embodiments of the present application, it is obvious to those skilled in the art that the embodiments of the present application can be implemented without these specific details or when these specific details are changed. Therefore, these descriptions should be considered to be illustrative rather than restrictive.

[0102] Although the present application has been described in conjunction with specific embodiments of the present application, many replacements, modifications and variations of these embodiments will be apparent to those skilled in the art from the foregoing description. For example, other memory architectures (e.g., dynamic RAM (DRAM)) may use the embodiments discussed.

[0103] The embodiments of the present application are intended to cover all such substitutions, modifications and variations that fall within the broad scope of the present application. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the embodiments of the present application should be included in the protection scope of the present application.

Claims

1. A method for testing a vehicle-side controller, characterized in that: Applied to the server, including: In response to receiving a data item read request sent by the controller under test to at least one simulated test virtual node, controlling a target test virtual node in the at least one test virtual node to perform a preset fault operation; collecting feedback operation information generated when the controller under test performs a feedback operation on the fault operation; Parsing the feedback operation information to determine whether the feedback operation is a troubleshooting operation corresponding to the fault operation; In response to the feedback operation being a troubleshooting operation corresponding to the fault operation, it is determined that the controller under test passes the test.

2. The method according to claim 1, characterized in that: The fault operation includes that the target test virtual node does not respond to the data item read request within a first preset time period; and determining whether the feedback operation is a troubleshooting operation corresponding to the fault operation includes: In response to the feedback operation being a first operation, determining that the feedback operation is a troubleshooting operation corresponding to the fault operation; Among them, the first operation includes: the controller under test sends a data item read request to the target test virtual node again a predetermined number of times, and when the controller under test does not receive data returned by the target test virtual node for the data item read request, the controller under test skips reading the current data item of the target test virtual node and starts reading the next data item of the target test virtual node.

3. The method according to claim 1, characterized in that The fault operation includes the target test virtual node sending read error information to the controller under test; and determining whether the feedback operation is a troubleshooting operation corresponding to the fault operation includes: In response to the feedback operation being a second operation, determining that the feedback operation is a troubleshooting operation corresponding to the fault operation; The second operation includes: the controller under test skips reading a current data item of the target test virtual node and starts reading a next data item of the target test virtual node.

4. The method according to claim 1, characterized in that The fault operation includes that the target test virtual node still does not return data within a second preset time after sending busy information to the controller under test; The determining whether the feedback operation is a troubleshooting operation corresponding to the fault operation includes: In response to the feedback operation being a third operation, determining that the feedback operation is a troubleshooting operation corresponding to the fault operation; The third operation includes: the controller under test skips reading a current data item of the target test virtual node and starts reading a next data item of the target test virtual node.

5. The method according to claim 1, characterized in that: In response to receiving a data item read request sent by the controller under test to at least one simulated test virtual node, before controlling a target test virtual node in at least one test virtual node to perform a preset fault operation, the method includes: Generate a configuration file, and send the configuration file to the vehicle computer, so that the vehicle computer determines at least one test virtual node from multiple simulated virtual nodes according to the configuration file, and sends a data item read request for at least one test virtual node to the controller under test, so that the controller under test sends the data item read request to at least one test virtual node.

6. The method according to claim 5, characterized in that The multiple virtual nodes are simulated by the server using automatic testing software.

7. The method according to claim 1, characterized in that The feedback operation information is collected by an external tester, and the external tester is respectively connected to the service end and the controller to be tested for communication.

8. A vehicle-side controller testing device, characterized in that: Applied to the server, including: an execution module, configured to control a target test virtual node in the at least one test virtual node to execute a preset fault operation in response to receiving a data item read request sent by the controller to be tested to the at least one test virtual node to be simulated; A collection module, configured to collect feedback operation information generated when the controller to be tested performs a feedback operation on the fault operation; A parsing module, configured to parse the feedback operation information to determine whether the feedback operation is a troubleshooting operation corresponding to the fault operation; The determination module is configured to determine that the controller under test passes the test in response to the feedback operation being a troubleshooting operation corresponding to the fault operation.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that: When the processor executes the program, the method according to any one of claims 1 to 7 is implemented.

10. A non-transitory computer-readable storage medium storing computer instructions, characterized in that: The computer instructions are used to enable a computer to execute the method according to any one of claims 1 to 7.

Images