Test method and device and readable storage medium

Abstract

The invention provides a test method and device and a readable storage medium, and is applied to the technical field of vehicles. The method comprises the following steps: determining a target message needing to be processed by a to-be-tested electronic control unit; under the condition that N simulation nodes are created in advance, determining a first simulation node used for processing a target message from the N simulation nodes; controlling the first simulation node and the to-be-tested electronic control unit to interact the target message; and executing the test item of the to-be-tested electronic control unit to obtain a test result. According to the test method provided by the invention, when different electronic control units are tested, a large amount of modification operation does not need to be performed on an existing simulation environment, and only the simulation node for processing the target message needs to be determined on the basis of the existing simulation environment according to the target message, needing to be processed, of the to-be-tested electronic control unit; and the simulation node is started to process the target message, so that the test work of the electronic control unit to be tested can be adapted, and the efficiency of the test work is improved.

Description

Technical Field

[0001] This application relates to the field of vehicle technology, and more specifically to a test method, apparatus, and readable storage medium. Background Technology

[0002] With the rapid development of automotive intelligence, the functions of Electronic Control Units (ECUs) are becoming increasingly complex, and functional testing of various ECUs has become a key link in ensuring the reliable operation of each ECU.

[0003] When testing multiple ECUs on a single device, the simulation environment required for testing different ECUs is different. Therefore, when testing a new ECU, a large number of tedious modifications must be made to the existing simulation environment, which reduces the efficiency of the testing work. Summary of the Invention

[0004] In view of the above problems, this application provides a testing method, apparatus and readable storage medium, which can improve the testing efficiency in the ECU testing process.

[0005] In a first aspect, a testing method is provided, which includes: determining the target message that the electronic control unit under test needs to process; determining a first simulation node for processing the target message from the N simulation nodes in the case of pre-created N simulation nodes; controlling the first simulation node to interact with the electronic control unit under test to process the target message; and executing the test items of the electronic control unit under test to obtain the test results.

[0006] Using the above method, when testing different ECUs, there is no need to make extensive modifications to the existing simulation environment. Simply determine the simulation node used to receive or send the target message based on the target message that the ECU under test needs to process, and start the simulation node to receive or send the target message. This adapts the testing work of the ECU under test and improves the efficiency of the testing work.

[0007] In conjunction with the above method, in some possible implementations, before the control first simulation node interacts with the electronic control unit under test to exchange target messages, the above method further includes: creating the first simulation node if the first simulation node is not included among the N simulation nodes; or creating the first simulation node if N simulation nodes have not been created in advance.

[0008] Using the above method, the first simulation node is created when it is not included in the N simulation nodes, or when N simulation nodes have not been pre-created. When faced with new target messages, such as communication requirements added after an ECU upgrade, new ECU testing without corresponding preset nodes, or an initial test environment without pre-created simulation nodes, simulation nodes can be created directly on demand, quickly building the simulation environment. This "on-demand creation" mechanism shortens the test environment setup cycle, enabling the testing method to flexibly respond to diverse ECU communication test scenarios, and improving the agility and practicality of the testing work.

[0009] In some possible implementations, the above method may further include: when the N simulation nodes include a second simulation node, shutting down the second simulation node, where the second simulation node is any simulation node other than the first simulation node among the N simulation nodes.

[0010] By employing the above method, when there are nodes among the N simulation nodes that are irrelevant to the test, these nodes are shut down. Shutting down irrelevant nodes simplifies the bus communication scenario of the test environment, prevents irrelevant messages or node behavior from interfering with the interaction process of target messages, and reduces test noise. Simultaneously, it reduces bus bandwidth usage and host computer resource consumption, improving test stability and the reliability of test results.

[0011] In some possible implementations, combining the above methods, shutting down the second simulation node includes: determining the proportion of the second simulation node among the N simulation nodes when N is greater than a preset number; and shutting down the second simulation node when the proportion is greater than a preset proportion.

[0012] By using the above method, when there are many simulation nodes and the load is high, shutting down unnecessary second simulation nodes can reduce the load during the testing process and ensure that the testing process can proceed smoothly.

[0013] In conjunction with the above methods, in some possible implementations, the test items of the electronic control unit under test are executed to obtain test results, including: when there are multiple test items, the Mth test item is executed to obtain a test result corresponding to the Mth test item; if the state of the first simulation node is changed after the execution of the Mth test item, the state of the first simulation node is restored; after restoring the state of the first simulation node, the (M+1)th test item is executed to obtain a test result corresponding to the (M+1)th test item.

[0014] By employing the above method, multiple test items are executed sequentially. If the Mth test item changes the state of the first simulation node, the state is restored before executing the (M+1)th test item. This ensures the independence between multiple test items, avoids residual states from previous tests affecting subsequent test results (e.g., unresolved fault states causing abnormalities in subsequent normal tests), and ensures that each test item is executed in the same initial environment. This improves test consistency and repeatability, reduces misjudgments caused by environmental interference, and guarantees the accuracy of test results in multi-test scenario scenarios.

[0015] In conjunction with the above method, in some possible implementations, before executing the Mth test item to obtain a test result corresponding to the Mth test item, the above method further includes: for the Mth test item, determining whether the first simulation node needs to interact with the target message in the case of simulating a message transmission failure corresponding to the test item when executing the test item; if so, modifying the fault flag bit of the first simulation node so that the first simulation node sends the target message in the case of simulating a message transmission failure.

[0016] Using the above method, for the Mth test item, if a message transmission failure needs to be simulated, the fault flag bit of the first simulation node is modified to send an abnormal message. This achieves accurate simulation of fault scenarios and allows for targeted testing of the ECU's handling capabilities under abnormal operating conditions (such as fault response to message loss or verification errors). Standardized control of the fault flag bit makes the fault injection process configurable, avoiding the randomness of manually simulating faults and improving the standardization and coverage of fault testing.

[0017] In conjunction with the above method, in some possible implementations, executing the Mth test item to obtain a test result corresponding to the Mth test item includes: determining the execution number corresponding to the fault flag bit; executing the Mth test item for the above execution number to obtain a test result corresponding to each execution of the Mth test item.

[0018] The above method determines the number of times each test item is executed for different fault flags, repeats the test item according to the number of executions, and determines whether the test item passes or fails based on multiple sets of results. This solves the problem of randomness in single-execution judgment, avoids misjudgments caused by occasional situations encountered in a single test, and improves the accuracy of test results.

[0019] In conjunction with the above methods, in some possible implementations, the test items of the electronic control unit under test are executed to obtain test results, including: when there are multiple test items of the electronic control unit under test, the multiple test items are sorted according to their execution time to obtain a sorting result, the shorter the execution time of the test item, the higher its position in the sorting result; according to the sorting result, the multiple test items are executed sequentially to obtain a test result corresponding to each test item.

[0020] Using the above method, multiple test items are sorted by execution duration from shortest to longest and executed sequentially to obtain test results. This "shortest-duration-first" strategy allows for the rapid exposure of fundamental functional issues in the early stages of testing (short-duration test items typically cover core functionalities), preventing basic defects from being introduced into complex test items and shortening the problem localization cycle. Simultaneously, it reduces the consumption of ineffective testing resources and improves overall testing efficiency.

[0021] Secondly, a testing apparatus is provided, the apparatus comprising: The determination module is used to determine the target message that the electronic control unit under test (ECU) needs to process; given that N simulation nodes have been pre-created, it determines the first simulation node from the N simulation nodes to process the target message, and each first simulation node is used to process a target message in the network where the ECU under test is located; it controls the first simulation node to interact with the ECU under test to process the target message; The execution module is used to execute the test items of the electronic control unit under test to obtain test results. The test items are used to test whether the electronic control unit under test can correctly process the target message.

[0022] Thirdly, a readable storage medium is provided that stores program code, which, when run on a computer, causes the computer to perform the method in any possible implementation of the first aspect described above.

[0023] Fourthly, an electronic device is provided, comprising a processor and a memory; the memory stores computer-executable instructions; the processor executes the computer-executable instructions stored in the memory to implement the method in any possible implementation of the first aspect above. Attached Figure Description

[0024] Figure 1 This is a schematic diagram of a test scenario provided in an embodiment of this application; Figure 2 This is an architecture diagram of a testing method provided in an embodiment of this application; Figure 3 This is a flowchart of the steps of a testing method provided in an embodiment of this application; Figure 4 This is a message transmission logic diagram provided in an embodiment of this application; Figure 5 This is a flowchart of an example of an automated testing method provided in an embodiment of this application; Figure 6 This is a schematic diagram of the structure of a testing device provided in an embodiment of this application; Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0025] The technical solutions in this application will be clearly and thoroughly described below with reference to the accompanying drawings. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B. "And / or" in the text is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, in the description of the embodiments of this application, "multiple" refers to two or more than two.

[0026] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature.

[0027] With the development of automotive intelligence, the functions of various electronic control units (ECUs) are becoming increasingly complex. The reliable operation of these ECUs is directly related to the safety, comfort, and intelligent experience of the vehicle. Therefore, the testing of various ECUs is very important.

[0028] Currently, when testing ECUs, in order to simulate the complex communication network in a real vehicle and avoid the high costs and risks that may result from testing directly in the real vehicle environment, it is necessary to build a simulation environment that can simulate the communication network of a real vehicle and test the ECU in the simulation environment.

[0029] See Figure 1 , Figure 1 This is a schematic diagram of a test scenario provided in an embodiment of this application, which describes a test scenario for testing the ECU under test.

[0030] like Figure 1As shown, the test scenario includes a host computer 101, hardware device 102, ECU under test 103, and a programmable power supply 104. The host computer 101 is connected to the hardware device 102 via a Universal Serial Bus (USB) interface to realize the transmission of simulation control commands and data. The hardware device 102 is connected to the bus interface of the ECU under test 103 via a Controller Area Network (CAN) bus to realize the transmission of messages on the bus. The programmable power supply 104 is connected to the power interface of the ECU under test 103 via a power cable to provide it with operating voltage. The programmable power supply 104 is connected to the host computer 101 via a Remote Synchronous Serial Communication (RS485) adapter cable.

[0031] When testing the ECU, technicians use the host computer 101 to build a simulation environment to simulate the communication network in a real vehicle. Specifically, they create simulation nodes in a bus testing tool (such as CANoe) and write corresponding script files (such as CAPL scripts) to control the simulation nodes to send and receive messages, thereby building the simulation environment required for testing. As described above, a simulation node is a unit module that implements message sending and receiving.

[0032] When testing multiple ECUs consecutively within a single device, the node configurations, signal definitions, and interaction logic in the simulation environments for each ECU differ. Therefore, different simulation environments are required for testing different ECUs. Figure 1 A simulation environment is a virtual environment built using a host computer bus testing tool in a test scenario to simulate the communication scenarios of a real vehicle ECU. It provides the ECU under test with a bus communication network consistent with the real operating scenario. The operation of the simulation environment depends on a large amount of code. Only through the execution of the code can the simulation environment simulate the bus communication network of a real vehicle.

[0033] When testing a new ECU after completing the test of one, technicians typically need to locate the target code segment requiring modification within a large amount of code in the simulation environment. They then need to specifically adjust the parameter configurations and logic instructions of the target code segment, and consider the side effects of the modification process on other code segments. For example, when code coupling exists, modifying the target code segment may cause logical conflicts or abnormal signal interactions in other code segments. These problems need to be considered during modification to avoid their occurrence. Therefore, modifying the simulation environment often consumes a significant amount of time and effort, reducing the overall efficiency of the testing work.

[0034] To address the aforementioned issues, this application provides a testing method that eliminates the need for extensive modifications to the existing simulation environment when testing different ECUs. Instead, it simplifies the testing process by identifying a first simulation node for receiving or sending the target message based on the existing simulation environment, and then activating this first simulation node to receive or send the target message. This adapts the method to the testing of the ECU under test, eliminating the need for numerous and cumbersome modifications to the existing simulation environment and improving the efficiency of the testing process.

[0035] For example, during the continuous testing of multiple ECUs, when testing one of the ECUs, such as the second ECU in a group of ECUs, it is first necessary to determine the target message that the ECU under test needs to process. Since a simulation environment corresponding to the first ECU has been created when testing the first ECU, and this simulation environment includes multiple simulation nodes for sending and receiving messages, the first simulation node for receiving or sending the target message is determined from these simulation nodes. By controlling the first simulation node to receive or send the target message, the simulation environment for testing the second ECU can be realized. Based on this simulation environment, it is possible to test whether the ECU under test can correctly process the target message, and finally obtain the test result.

[0036] Figure 2 This is an architecture diagram of a testing method provided in an embodiment of this application. For example... Figure 2 The architecture diagram includes an ECU under test 201, an execution module 202, a network module 203, a determination module 204, a message set 205, and a test case set 206.

[0037] The ECU under test 201 is the object under test and is connected to the network module 203. The determination module 204 consists of n simulation nodes, and the network module 203 receives one message sent by each simulation node in the determination module 204. The execution module 202 is connected to the network module 203 and can exchange multiple messages in the message set 205. The multiple messages in the message set 205 are generated by the test case set 206, which includes tests such as signal reception monitoring, message loss monitoring, E2E verification monitoring, SecOC security RxPDU verification, SecOC security TxPDU authentication, SecOC synchronization message verification, SecOC request synchronization verification, SecOC default code verification, communication fault DTC testing, and vehicle configuration word testing.

[0038] Figure 3 This is a flowchart of a testing method provided in an embodiment of this application. Figure 3 The method shown can be applied to the testing process of any ECU, and the embodiments of this application do not limit it.

[0039] like Figure 3As shown, the method may include the following steps: Step 301: Determine the target message that the ECU under test needs to process.

[0040] The target message refers to the message received and sent by the ECU under test in the vehicle's CAN bus network.

[0041] In one implementation, during the process of determining the target message that the ECU under test needs to process, the host computer first obtains the communication matrix of the ECU under test. The communication matrix defines which messages the ECU under test needs to receive and send in the vehicle communication network. Based on the communication matrix, the target message that the ECU under test needs to process can be determined. If the receiving node of a certain message is the ECU under test, then the message is determined to be the target message that the ECU under test needs to receive; if the sending node of a certain message is the ECU under test, then the message is determined to be the target message that the ECU under test needs to send.

[0042] Step 302: If N simulation nodes have been created in advance, determine the first simulation node from the N simulation nodes to process the target message.

[0043] Where N is a positive integer, each first simulation node is used to process a target message in the network where the electronic control unit under test (ECU) is located. The N pre-created simulation nodes refer to the simulation nodes created when creating the simulation environment for the previous ECU before testing the ECU under test. When creating the simulation environment for the previous ECU, the messages that the ECU needs to process are first determined, and a simulation node is created for each message. Each simulation node is used to process one message. If there are N messages, then N simulation nodes are created. These N simulation nodes are the N pre-created simulation nodes before testing the current ECU under test. The first simulation node is the simulation node that receives or sends the target message that the current ECU under test needs to process.

[0044] In one implementation, during the creation of a simulation node, technicians can add the simulation node in the CANoe software interface settings, and then add script files to the simulation node to implement the message sending / receiving logic.

[0045] Figure 4This is a message transmission logic diagram provided in an embodiment of this application. The script file of the simulation node includes code for implementing the message transmission logic, specifically code segment 401, code segment 402, and code segment 403. Code segment 401 defines variables such as message ID, transmission period, signal initial value, and fault flag bit; code segment 402 is used to initialize timers, signal values, and system variables; code segment 403 generates message frames periodically, including rolling counter increment, checksum calculation, signal value update, and fault injection judgment logic. In addition, the script file also reserves parameter configuration interfaces corresponding to the communication matrix fields, such as message ID, signal start bit, and length, which can be directly modified through variables; then, a corresponding Database Description File (DBC) is associated with each simulation node, enabling the simulation node to automatically parse the signal definitions in the message; finally, the communication parameters of each simulation node, such as baud rate and sampling points, are made consistent with the vehicle network through CANoe's node configuration tool, thereby completing the creation of the simulation node.

[0046] In one implementation, the process of determining the first simulation node for receiving or sending a target message from N simulation nodes first involves extracting the message name and ID of the target message from the communication matrix. Then, all pre-created simulation nodes are traversed, and the message information recorded in the configuration file of each node is examined. If the message name and ID of a node are completely consistent with the target message, and the sending / receiving attributes of that node match the interaction requirements of the target message, then that node is determined as the first simulation node.

[0047] Optionally, if the first simulation node is not included among the N simulation nodes, a first simulation node is created. In one implementation, an existing simulation node is copied, the message ID is updated to the target message ID, the transmission period is adjusted to match the definition in the communication matrix, the signal list in the Variables section is replaced with the signals in the target message (including signal name, start bit, length, etc.), and the assignment logic and verification calculation logic related to the signals in the ontimer section are modified synchronously (such as the initial value of the rolling counter and the calculation range of the checksum). Then, the signal mapping table is updated, the system variables are re-associated with the new signals (such as pointing "SysVar_SignalValue" to the signal value of the target message), and the fault injection type in the fault rule table is adjusted according to whether the target message requires security verification, such as adding or deleting fault flags related to Secure On-Board Communication (SecOC). Finally, the new node is imported into the CANoe environment, the corresponding DBC file is associated to ensure correct signal parsing, and the creation of the first simulation node is completed. The entire process requires no coding from scratch. By reusing the framework of existing simulation nodes and modifying parameters, it can quickly adapt to new target message testing requirements.

[0048] Optionally, if the N simulation nodes have not been created in advance, the first simulation node is created in the same way as the process of creating simulation nodes described above, and will not be elaborated here.

[0049] In this embodiment, a first simulation node is created when the first simulation node is not included in the N simulation nodes, or when N simulation nodes have not been pre-created. When faced with new target messages (such as communication requirements added after an ECU software upgrade), new ECU testing (without a corresponding preset node), or an initial test environment (without a pre-created simulation node), simulation nodes can be created directly on demand, quickly building the test link. This "on-demand creation" mechanism shortens the test environment setup cycle, enabling the test method to flexibly respond to diverse ECU communication test scenarios, and improving the agility and practicality of the test process.

[0050] Optionally, if the N simulation nodes include a second simulation node, the second simulation node is turned off. The second simulation node is any of the N pre-created simulation nodes other than the first simulation node; that is, the second simulation node neither receives nor sends the target messages that the ECU under test needs to process, and is unrelated to the testing process of the ECU under test.

[0051] In one implementation, when determining whether the N simulation nodes include a second simulation node, the N pre-created simulation nodes are first traversed. All message information (including message name, ID, and corresponding node send / receive attributes) recorded in the node configuration file of each simulation node is extracted and compared with all target messages that the ECU under test needs to process, as determined in step 201. If none of the messages corresponding to a certain simulation node are within the target message range, and the send / receive attributes of that simulation node do not match the interaction requirements of any message (i.e., it neither sends messages that the ECU under test needs to receive nor receives messages that the ECU under test needs to send out), then that node is determined to be the second simulation node. In this way, all nodes unrelated to the current ECU under test can be filtered out, ensuring that only the first simulation node, which is meaningful for the test, is retained.

[0052] In one implementation, when the second simulation node is shut down, the CANoe software on the host computer calls the system variable control interface to set the global enable variable corresponding to each second simulation node to the "disabled" state. This operation triggers the node's internal disable logic, causing it to stop all message sending and receiving and no longer participate in bus communication. This ensures that the bus environment during testing only contains interactions related to the target message, avoiding interference from irrelevant nodes with the test results.

[0053] In this embodiment, when there are nodes irrelevant to the test among the N simulation nodes, these nodes are shut down. By shutting down irrelevant nodes, the bus communication scenario of the test environment is simplified, and interference from irrelevant messages or node behavior with the interaction process of the target message is avoided, thus reducing test noise. At the same time, bus bandwidth usage and host computer resource consumption are reduced, improving test stability and the reliability of test results.

[0054] Optionally, the second simulation node can be turned off, including: When N is greater than the preset number, determine the proportion of the second simulation node in the N simulation nodes; If the percentage is greater than the preset percentage, shut down the second simulation node.

[0055] In one implementation, if it is determined that a second simulation node exists among N simulation nodes, it can be determined whether the total number of N simulation nodes (i.e., N) is greater than a preset number. If it is greater than the preset number, it is determined that there are currently too many simulation nodes and the load on the host computer is too high. At this time, the total number of second simulation nodes can be further counted, and the ratio of the total number of second simulation nodes to N can be calculated to obtain the proportion of the second simulation node among the N simulation nodes.

[0056] If the proportion of the second simulation node among the N simulation nodes is greater than the preset proportion, it is determined that there are too many unnecessary simulation nodes (i.e., the second simulation node) during the testing of the ECU under test. In this case, the second simulation node can be turned off.

[0057] Conversely, if N is less than or equal to the preset number, it can be determined that there are relatively few simulation nodes and the load on the host computer is low. In this case, there is no need to shut down the second simulation node. Furthermore, if the proportion of the second simulation node among the N simulation nodes is less than or equal to the preset proportion, it can be determined that there are relatively few unnecessary simulation nodes during the test, and in this case, there is no need to shut down the second simulation node.

[0058] In this embodiment of the application, when there are many simulation nodes and the load is large, shutting down unnecessary second simulation nodes can reduce the load during the testing process and ensure that the testing process can proceed smoothly.

[0059] Optionally, during the process of shutting down the second simulation nodes, only some of the second simulation nodes can be shut down, so that the total number of currently running simulation nodes is less than or equal to a preset number, thereby reducing the load on the host computer.

[0060] It's understandable that second simulation nodes not needed in this test might be needed in the next test. Disabling only some second simulation nodes can avoid having to re-enable them in the next test.

[0061] Step 303: Control the first simulation node to interact with the ECU under test to send target messages.

[0062] In one implementation, controlling the first simulation node to interact with the ECU under test to send target messages includes controlling the first simulation node to send target messages or controlling the first simulation node to receive target messages.

[0063] Specifically, in controlling the first simulation node to send the target message, the host computer's test software first calls the corresponding send enable system variable of the first simulation node and sets it to an active state, enabling the node to have the basic conditions for sending the target message. Next, according to the test case requirements, values ​​are assigned to each signal in the target message through the signal value system variable, such as setting a specific value for the vehicle speed signal. If it is necessary to simulate fault scenarios, such as message verification errors or signal over-range, the corresponding fault flag system variable is called and set to valid. After completing the parameter configuration, the send timer of the first simulation node is started. The node will generate a complete target message frame according to the preset send cycle, based on the configured signal values ​​and fault states. After being converted into an electrical signal conforming to the bus specification by the hardware device, it is sent to the ECU under test.

[0064] Specifically, in controlling the first simulation node to receive target messages, the message listening function of the first simulation node is first enabled. The target message ID that the node listens to is configured through the host computer test software to ensure that the node only captures specific target messages. Subsequently, the reception timeout threshold and signal parsing rules are set. The signal parsing rules must be consistent with the signal definition of the target message in the communication matrix, including parameters such as signal start bit, length, and factor. When the ECU under test sends a target message to the bus, the first simulation node monitors the bus data in real time. Once a message with a matching ID is identified, it immediately parses the signal value in the message according to the preset rules and stores the parsing result in the corresponding reception result system variable. At the same time, it records information such as message reception time and period, providing data support for subsequent verification of the external message sending function of the ECU under test.

[0065] Step 304: Perform the test items for the ECU under test to obtain the test results.

[0066] Among them, the test item is a test script used to test whether the ECU under test can correctly process the target message.

[0067] Optionally, testing whether the ECU under test can correctly process the target message includes testing whether the ECU under test can correctly receive the target message sent by the simulation node, and testing whether the ECU under test can correctly send the target message.

[0068] In one implementation, when testing whether the ECU under test can correctly respond to the target message sent by the simulation node, in step 303, the first simulation node is first controlled to send the target message according to preset parameters, including normal signal values ​​or signals containing specific faults (such as verification errors, signal over-range, etc.). Then, a preset processing time is waited (this time is set according to the ECU's message processing delay requirements, usually several message sending cycles) to ensure that the ECU under test has sufficient time to receive and process the target message. Afterwards, the internal variables of the ECU under test are read through CANoe's Universal Measurement and Calibration Protocol (XCP). These variables correspond to the signals in the target message (e.g., the vehicle speed variable inside the ECU corresponds to the VehicleSpeed ​​signal in the target message). The read internal variable values ​​are compared with the preset expected results of the test case (e.g., in a normal scenario, the expected internal variable value matches the sent signal value; in a fault scenario, the fault flag corresponding to the internal variable is set). If they match, the current test item is considered passed; otherwise, it is considered failed. During the test, the ECU under test receives multiple target messages. Following the above process, multiple test items related to the multiple target messages (such as reception of different signal values, response to different types of faults, etc.) are executed in sequence. The judgment results of all test items are summarized to form the final test result of the ECU under test receiving messages.

[0069] Optionally, testing whether the ECU under test can correctly respond to the target message sent by the simulation node can include signal reception testing. Specifically, the simulation node sends target messages containing different signal values ​​(such as normal range values, boundary values, and over-range values). The corresponding signal variables after being parsed internally by the ECU are read through XCP, and the error between the variable value and the sent value is compared to see if it is within the allowable range (such as ≤5%). At the same time, it is checked whether the ECU triggers a preset protection mechanism (such as signal clamping) when the over-range occurs, thereby verifying the accuracy of the ECU's parsing of the received signal.

[0070] Optionally, testing whether the ECU under test can correctly respond to the target message sent by the simulation node can include a message loss fault test. Specifically, the target message sending state is controlled by system variables (e.g., intermittently stopping sending) to simulate a message loss scenario. The message loss fault flag bit inside the ECU is monitored by XCP to verify whether the flag bit is set within a preset time (e.g., 3 message cycles) and meets the debounce time requirement. At the same time, it is checked whether the flag bit is reset in time after the fault is cleared.

[0071] Optionally, testing whether the ECU under test can correctly respond to the target message sent by the simulation node can include end-to-end (E2E) verification fault testing. Specifically, E2E-related faults (such as incorrect checksums or rolling counter jumps) are injected into system variables. The E2E verification failure counter and fault flag inside the ECU are read using XCP to verify whether the counter increments as expected and whether the fault flag is set correctly, thereby confirming the validity of the ECU's E2E verification logic.

[0072] Optionally, testing whether the ECU under test can correctly respond to the target message sent by the simulation node can include a SecOC Protocol Data Unit (PDU) reception verification test. Specifically, the simulation node is controlled to send a target message with SecOC attributes to the ECU, and faults such as MAC errors and message counter anomalies are generated through system variables. The SecOC verification failure counter and safety status flag inside the ECU are observed through XCP to check whether the counter accurately records the number of failures and whether the ECU triggers the preset safety policy (such as entering degrade mode).

[0073] Optionally, testing whether the ECU under test can correctly respond to the target message sent by the simulation node can include a SecOC synchronization message verification test. Specifically, when the control simulation node sends a SecOC synchronization message, faults such as synchronization counter errors and abnormal MAC values ​​are injected into the system variables. The synchronization counter, reset counter, and verification failure counter inside the ECU are read by XCP to confirm whether the ECU can correctly identify synchronization message faults and update its internal state.

[0074] Optionally, testing whether the ECU under test can correctly respond to the target message sent by the simulation node can include a SecOC default code verification test. Specifically, when the control simulation node sends a safety PDU message or a synchronization message message to the ECU, parameters such as the message counter and MAC value are set to default codes. The default code count (such as the safety PDU default code count and the synchronization message default code count) and default code information inside the ECU are read by XCP to verify whether the ECU can correctly recognize the default code and update the relevant statistical values.

[0075] In one implementation, when testing whether the ECU under test can correctly send messages, firstly, ensure that the first simulation node has entered the receiving state according to the configuration in step 203, and is able to listen for target messages that the ECU under test may send. Then, trigger the sending conditions of the ECU under test (such as sending a wake-up signal or control command through the simulation node to prompt the ECU to generate and send the target message). After the first simulation node captures the target message sent by the ECU under test on the bus, it parses the key information in the message, including signal values, sending period, and checksums (such as checksum, MAC value, etc.). These parsing results are compared with the preset requirements in the communication matrix and test cases (such as signal values ​​should be within a reasonable range, sending period error should not exceed 10%, and checksums should conform to calculation rules). If all requirements are met, the current sending test item passes; if any discrepancy exists, it is determined to fail. In the test, the ECU under test sends multiple target messages. The above process is repeated for different test scenarios (such as normal sending, sending under extreme conditions, sending under safety verification scenarios, etc.) for multiple target messages. After executing multiple test items, all results are integrated to obtain the final test result of the ECU under test's outgoing messages.

[0076] Optionally, the test verifies whether the ECU under test can correctly send messages, including SecOC request synchronization messages. Specifically, the simulation node is controlled to stop sending SecOC synchronization messages, and the ECU is powered on and off to wake up via a programmable power supply. The first simulation node listens to the bus, captures the request synchronization messages sent by the ECU, verifies whether the message format (ID, signal definition) conforms to the specifications, and checks the triggering mechanism of the ECU sending requests (such as whether it sends a request immediately after waking up if no synchronization message is received).

[0077] Optionally, testing whether the ECU under test can correctly send messages includes a SecOC security PDU outbound authentication test. Specifically, the simulation node is controlled to send synchronization messages normally, triggering the ECU to send a target message with SecOC attributes. After the simulation node captures the message, it parses the MAC value, message counter, and low-order bits of the reset counter, and compares them with the expected values ​​calculated according to the SecOC specification to verify whether the three match, thereby confirming the authentication validity of the ECU's outbound security message.

[0078] Optionally, testing whether the ECU under test can correctly send messages includes a SecOC default code verification test. Specifically, a diagnostic tool writes a specific configuration word to the ECU, controlling its external security message transmission to set parameters such as the MAC value and message counter to default codes. The simulation node captures the external message, parses whether the relevant parameters conform to the default code format, and simultaneously reads the default code configuration status inside the ECU through XCP to verify whether the default code setting is effective.

[0079] Optionally, testing whether the ECU under test can correctly send messages includes Diagnostic Trouble Code (DTC) testing. Specifically, an abnormal message (such as a checksum error or periodic anomaly) is sent to the ECU through a simulation node, triggering the relevant DTCs on the ECU. The simulation node listens to the DTC messages sent by the ECU, parses the fault codes in the messages to see if they match expectations, and simultaneously reads the ECU's internal DTC storage through the diagnostic service to verify whether the reporting and storage of fault codes meet the requirements.

[0080] Optionally, testing whether the ECU under test can correctly send messages includes testing the vehicle configuration word function. Specifically, the vehicle configuration word of the ECU is modified by a diagnostic tool, the first simulation node sends the corresponding fault message to the ECU, listens to the DTC messages sent by the ECU, and verifies whether the DTC reporting logic under different configuration words meets the configuration requirements.

[0081] The above tests all use a combination of "simulation node interaction + internal variable reading + message parsing" to cover the full scenarios of ECU receiving and sending messages. All test items can be platformized by adapting system variables and XCP variables, and can be quickly adapted to the test requirements of different ECUs without modifying the underlying scripts.

[0082] Optionally, when executing multiple test items consecutively, if the state of the first simulation node is changed after executing the Mth test item, the state of the first simulation node is restored. After restoring the state of the first simulation node, it is determined whether the ECU under test can correctly process the target message when performing the (M+1)th test item, so as to obtain a test result corresponding to the (M+1)th test item. The change of the state of the simulation node refers to the change of the simulation node from a normal state to a fault state. In the normal state, the simulation node receives / sends target messages normally. In the fault state, the simulation node sends abnormal target messages or does not send target messages according to the fault state.

[0083] In one implementation, when restoring the state of the first simulation node, for transmitting parameters, fault flag variables (such as check error flags and message loss flags) are reset to 0, signal values ​​are restored to the baseline values ​​preset in the test cases, and the transmitting period is adjusted to the standard period defined by the communication matrix. For receiving parameters, historical data in the message buffer is cleared, the receiving timeout counter is reset, and the signal parsing rules are restored to the default configuration. Simultaneously, the node diagnostic function of CANoe is used to detect whether the node has restored normal communication capabilities (e.g., sending a standard test frame and confirming the bus response). If the detection passes, the state restoration is considered complete, providing the (M+1)th test item with the same initial environment as before the execution of the Mth test item, ensuring no state interference between adjacent test items.

[0084] In this embodiment, multiple test items are executed sequentially. If the Mth test item changes the state of the first simulation node, the state is restored before executing the (M+1)th test item. This ensures the independence between multiple test items, avoids residual states from previous tests affecting subsequent test results (e.g., unresolved fault states causing abnormalities in subsequent normal tests), and ensures that each test item is executed in the same initial environment, improving test consistency and repeatability, reducing misjudgments caused by environmental interference, and guaranteeing the accuracy of test results in multi-test-item scenarios.

[0085] Optionally, when executing each test item, it is determined whether the first simulation node needs to send the target message in the case of simulating a message transmission failure corresponding to the test item; if so, the fault flag bit of the first simulation node is modified so that the first simulation node can send the target message in the case of simulating a message transmission failure.

[0086] Among them, message transmission failure refers to the message transmission failures that may occur during actual vehicle communication, including but not limited to message period abnormalities, message length errors, message loss, etc. The fault flag is defined in the script file of the simulation node and is a system variable used to control whether the simulation node triggers a specific fault. Each fault type corresponds to an independent flag. When the flag is set to 1, the simulation node automatically injects the corresponding fault when sending the target message. When it is set to 0, it returns to the normal transmission state.

[0087] For example, the current test item tests whether the ECU under test can correctly trigger the fault handling mechanism when it receives a target message with an E2E check error. Therefore, when executing the current test item, the simulation node needs to send the target message under the condition of simulating an E2E check error fault. Modify the fault flag bit related to E2E check in the simulation node so that when the simulation node generates the target message, it intentionally calculates an incorrect checksum value and sends it with the message. This can test whether the ECU under test can recognize the fault and execute the preset processing logic.

[0088] In this embodiment, for the Mth test item, if a message transmission failure needs to be simulated, the fault flag bit of the first simulation node is modified to send an abnormal message. This achieves accurate simulation of the fault scenario and allows for targeted testing of the ECU's processing capabilities under abnormal operating conditions (such as fault response to message loss or verification errors). Standardized control of the fault flag bit makes the fault injection process configurable, avoiding the randomness of manually simulating faults and improving the standardization and coverage of fault testing.

[0089] Optionally, when executing multiple test items, the execution number corresponding to the fault flag bit is determined; the Mth test item is executed for that number of executions to obtain a test result corresponding to each execution of the Mth test item.

[0090] The execution count corresponding to the fault flag bit refers to the number of times the corresponding test item needs to be executed repeatedly for a specific fault flag bit, i.e., a specific fault, to verify the stability of the ECU under test in handling the fault. This number is determined based on the fault characteristics. For example, for the "message verification error flag bit" (corresponding to verification error fault): referring to the fact that this fault occurs an average of 3 times per day in real vehicles, and the ECU needs to respond 100% correctly, the execution count of its corresponding test item "verification error fault response test" is set to 5 times, which is more than the frequency in real vehicles, to avoid occasional anomalies affecting the test.

[0091] For example, when testing whether the ECU under test can correctly handle the fault condition corresponding to a certain fault flag bit, firstly, the number of executions corresponding to the fault flag bit is determined, then the test item is executed according to the number of executions and the results are recorded, and finally, the test item is judged to pass based on multiple sets of results.

[0092] In one implementation, the process of determining the execution count corresponding to the fault flag bit first involves acquiring historical data on the fault type of the ECU under test, including the average daily frequency of the fault, the impact level of a single fault on the ECU's function, and the fault response compliance requirements specified in the ECU design document (e.g., 100% correct response for high-impact faults, and ≥80% compliance rate for medium-impact faults). Next, the execution count is calculated based on the acquired historical data. Using the average daily fault frequency of the actual vehicle as a base, the execution count is amplified by an "impact level coefficient." A coefficient of 1.7 corresponds to high-impact faults (ensuring coverage of extreme and occasional scenarios), and a coefficient of 2.0 corresponds to medium-impact faults (balancing coverage and testing efficiency). For example, the "message verification error fault" has an average daily frequency of 3, classifying it as a high-impact fault, so its execution count = 3 × 1.7 ≈ 5 times. The high-impact fault coefficient and low-impact fault coefficient can be customized according to the testing requirements of the ECU under test.

[0093] In this embodiment, the number of times a corresponding test item is executed is determined for different fault flag bits, the test item is repeatedly executed according to the number of times, and the pass or fail of the test item is determined based on multiple sets of results. This solves the problem of the randomness of single-execution judgment, avoids misjudgment caused by a single test encountering an accidental situation, and improves the accuracy of test results.

[0094] Optionally, if there are multiple test items for the ECU under test, the test items are sorted according to their execution time to obtain a sorting result; based on the sorting result, the test items are executed sequentially to obtain a test result corresponding to each test item.

[0095] The shorter the execution time of a test item, the higher its position in the sorting results.

[0096] In one implementation, the execution time of multiple test items is first determined. For each test item, all operation steps included in the test item are traversed to identify core links such as simulation node configuration (e.g., system variable assignment, fault flag initialization), message interaction (e.g., sending rounds, period setting), ECU response monitoring (e.g., XCP variable reading frequency, status judgment count), and result processing (e.g., data comparison, log writing). Then, based on preset link time benchmarks (e.g., 20ms for configuring one system variable, message sending time equal to the message period, 30ms for reading one XCP variable, and an additional 100ms for complex verification logic), the actual number of operations required by the test item is accumulated. Calculations are performed; for example, for the basic signal reception test, the calculation shows "1 node configuration (20ms × 5 variables = 100ms) + 3 rounds of message sending (100ms / round × 3 = 300ms) + 3 XCP reads (30ms × 3 = 90ms) + 1 result recording (50ms)", with a total duration of 540ms. For the SecOC security test, the calculation shows "1 node configuration (20ms × 8 variables = 160ms) + 5 rounds of encrypted message sending (100ms / round × 5 + 100ms verification time = 600ms) + 5 XCP reads (30ms × 5 = 150ms) + 1 result recording (50ms)", with a total duration of 960ms. Through this step-by-step quantitative calculation, the execution time of each test item can be determined, providing a quantitative basis for subsequent sorting according to the "shortest duration priority" principle.

[0097] In another implementation, for each test item, the execution time is calculated by analyzing the time complexity of the test script: First, the CAPL script corresponding to the test item is parsed to identify the core logical structures in the script that affect the execution efficiency, including loop statements (such as for loops to send multiple rounds of messages), condition judgments (such as nested if statements to handle fault responses), interactive operations (such as the number of times XCP variables are read), etc.; then, the time complexity type is determined according to the number of times these structures are executed. For example, a script containing only a single send and read operation is O(1) (constant level), a script containing a fixed number of loops (such as sending 5 rounds of messages) is O(n) (linear level), and a script containing nested loops (such as performing 3 checks after each round of sending) is O(n²) (quadratic level). Based on this, the total execution time is calculated by combining the preset basic time units (such as O(1) corresponding to a baseline time of 50ms, and each loop unit n corresponding to a time of 100ms): For O(1) level scripts (such as basic signal reception test, only 1 transmission + 1 reading), the execution time is 50ms × 2 = 100ms; for O(n) level scripts (such as 5 rounds of fault message transmission, n = 5), the execution time is 50ms (basic) + 100ms × 5 = 550ms; for O(n²) level scripts (such as 3 rounds of transmission and each round includes 2 checks, n = 3), the execution time is 50ms (basic) + 100ms × 3² = 950ms.

[0098] In one implementation, after determining the execution duration of multiple test items, the test items are sorted according to their execution durations to obtain a sorting result. Based on the sorting result, the test items are executed sequentially. Specifically, the execution duration data of all test items is stored in a temporary array. A built-in sorting algorithm (such as quicksort) is called to sort the duration values ​​in the array in ascending order. Simultaneously, each duration value is associated with a corresponding test item identifier (such as TestID), forming a "duration-test item" mapping table. That is, the shortest execution duration test item is placed first, and the longest duration test item is placed last. After sorting, the test items are executed sequentially according to the order of the mapping table. Specifically, the first test item is started first, the initial state of the first simulation node is configured through system variables, and the message sending or receiving process is triggered. After this test item is completed, the state of the first simulation node is restored, and then the next test item is executed.

[0099] In this embodiment, multiple test items are sorted by execution duration from shortest to longest and executed sequentially to obtain test results. This "shortest-duration-first" strategy allows for the rapid exposure of fundamental functional issues in the early stages of testing (short-duration test items typically cover core functionalities), preventing basic defects from being introduced into complex test items and shortening the problem localization cycle. Simultaneously, it reduces the consumption of ineffective testing resources and improves overall testing efficiency.

[0100] Optionally, when testing a new ECU, test cases can be reused by modifying system variables and XCP variables.

[0101] In one implementation, when reusing test cases for a new ECU, only system variables and XCP variables adapted to the new ECU need to be modified. Specifically, for system variables, the configuration parameters related to the target message in the simulation node are modified, such as updating the message ID from 0x123 in the old ECU to 0x456 in the new ECU, adjusting the sending period to the 200ms required by the new ECU, and synchronously updating the signal mapping relationship. If the new ECU involves secure communication, only security parameter variables such as SysVar_SecOC_Key need to be modified, without reconstructing the entire security verification logic. For XCP variables, the addresses of internal ECU variables related to the test results are remapped, such as replacing the vehicle speed parsing value at address 0x00A0 in the old ECU with the corresponding variable at address 0x00B8 in the new ECU, and updating the variable parsing rules (such as factors and offsets) to match the signal processing logic of the new ECU.

[0102] In this embodiment of the application, when testing a new ECU, the script framework of the original test cases does not need to be modified. Only by adapting the communication matrix and internal variable definitions of the new ECU through variable configuration can the test cases be quickly reused, reducing the amount of repetitive development work and improving the universality and maintenance efficiency of the test scripts.

[0103] Optionally, the host computer has a Jenkins platform installed, which has a preset automated testing process in which the above testing methods are integrated. When a developer pushes code to a specific branch (such as the develop branch) of the GitLab remote repository, this event is notified to the Jenkins server via GitLab's webhook function. Upon receiving the notification, the Jenkins server immediately starts the preset automated testing process.

[0104] Figure 5 This is a flowchart illustrating an example of an automated testing method provided in an embodiment of this application. Figure 5 As shown in the diagram, the process architecture includes a main process 501, a repository 502, a flashing project 503, and an automated testing project 504. The repository is, for example, GitLab. Flashing project 503 is a CANoe-based flashing project, and automated testing project 504 is a CANoe-based automated testing project. The main process 501 includes the following six steps: Step 5011: Clean up the workspace. The Jenkins platform performs cleanup operations through a preset shell script or pipeline plugin (such as WorkspaceCleanupPlugin): If the workspace is newly created, an empty directory is directly generated in the specified path on the server, and read / write permissions are set to be accessible by the current Jenkins process; if the workspace already exists, all files and subfolders in the directory (including hidden files, build cache, historical test reports, etc.) are recursively deleted, and a disk cleanup tool is called to release the occupied inode resources. After cleanup, the directory space usage is output through a script (such as the du-sh command) to confirm that the workspace size is 0 or only the basic configuration files are retained, ensuring that subsequent steps are not affected by historical data.

[0105] Step 5012: Download Code. Jenkins uses pre-configured credentials (such as SSH keys or username / password) to access the GitLab repository 502 and download the complete source code project of the specific branch to the workspace prepared in Step 1. After the download is complete, the latest commit ID is output via gitlog-1 to verify that the code version is consistent with the GitLab remote repository, avoiding incomplete code pulls or version errors.

[0106] Step 5013: Compile the code. Jenkins calls the preset compilation script in the workspace, selects the corresponding compiler based on the chip model of the ECU under test, and compiles the code downloaded in step 202 to generate an object file (.o). This is then linked into an executable binary file for the ECU (such as .elf or .s19 format). Logs are output in real time during the compilation process. If syntax errors, undefined variables, or other issues occur, the pipeline automatically terminates and marks it as "compilation failed," while simultaneously uploading the error log to the Jenkins console. If compilation is successful, a binary file is generated in the output directory of the workspace, and the file hash value is calculated using the md5sum command for subsequent flashing verification.

[0107] Step 5014: Flashing the code. Jenkins calls the CANoe COM interface via a Python script to start the preset CANoe flashing project 503. The script first checks if the compiled .elf / .s19 files exist and verifies that their hash values ​​are consistent with those in the compilation stage. Then, it establishes a diagnostic session with the ECU under test through diagnostic services (such as $34 (request download), $36 (transfer data), and $37 (request end) of the UDS protocol), sequentially executing the operations of "unlocking ECU," "erasing the Flash partition," "transferring binary files," and "verifying data integrity." During the flashing process, the script obtains the progress information returned by CANoe in real time (e.g., "30% transferred"). If timeouts or verification failures occur, the flashing is immediately terminated and an error code is recorded (e.g., 0x10 indicates verification failure). If the flashing is successful, the ECU is switched to normal mode via $10 (diagnostic session control), and a "flashing successful" log is output upon completion.

[0108] Step 5015: Perform communication tests. Jenkins calls a Python script to start the CANoe automated test project 504. The script loads multiple pre-set test cases (such as signal reception tests, SecOC security tests, etc.) through the TestModule interface. After the test starts, CANoe executes each test item in sequence: For reception tests, the first simulation node sends the target message (including normal signals or fault injection), and the script reads the ECU's internal variables through XCP and compares them with the expected values; for outgoing tests, the first simulation node listens to the ECU's outgoing messages, parses signal values, checksums, and other parameters, and verifies compliance. After each test item is completed, the script records the "pass" or "fail" status and detailed logs (such as the reason for failure: "MAC value verification error"). The CANoe automated test project 504 implements the test method provided in this application, which will not be elaborated further here.

[0109] Step 5016: Upload Test Report. After testing, CANoe automatically generates an HTML test report in the workspace's `report` directory, including the total number of test cases, pass count, failure count, details of failures, and key screenshots (such as signal waveform diagrams). Jenkins uploads the report to the designated test management platform via FTP or API. The report also includes metadata such as the pipeline number, commit ID, and compilation time. After upload, the platform automatically sends an email notification to developers (including a report link). If failures exist, the email highlights the failed test items and possible reasons (e.g., "E2E verification failed, suspected ECU verification algorithm error"), facilitating quick problem identification.

[0110] The above text combined Figures 1 to 5 The test methods provided in the embodiments of this application are described in detail below; the following will be combined with Figure 6 and Figure 7 This application describes an embodiment of the apparatus. It should be understood that the apparatus in the embodiments of this application can perform the various methods described in the foregoing embodiments of this application. That is, the specific working processes of the various products described below can be referred to the corresponding processes in the foregoing method embodiments.

[0111] See Figure 6 , Figure 6 This is a schematic diagram of the structure of a testing device provided in an embodiment of this application. Figure 6 As shown, the testing apparatus 600 may include: The determination module 601 is used to determine the target message that the electronic control unit under test needs to process; given that N simulation nodes have been created in advance, the first simulation node for processing the target message is determined from the N simulation nodes, and each first simulation node is used to process a target message in the network where the electronic control unit under test is located; the first simulation node is controlled to interact with the electronic control unit under test to process the target message; The execution module 602 is used to execute the test items of the electronic control unit under test to obtain the test results. The test items are used to test whether the electronic control unit under test can correctly process the target message.

[0112] Optionally, the determining module 601 is further configured to create a first simulation node if the first simulation node is not included in the N simulation nodes; or, to create a first simulation node if N simulation nodes have not been created in advance.

[0113] Optionally, the determining module 601 is further configured to shut down the second simulation node if the N simulation nodes include the second simulation node, wherein the second simulation node is any simulation node other than the first simulation node among the N simulation nodes.

[0114] Optionally, the determining module 601 is further configured to determine the proportion of the second simulation node among the N simulation nodes when N is greater than a preset number; and to shut down the second simulation node when the proportion is greater than a preset proportion.

[0115] Optionally, the execution module 602 is specifically used to execute the Mth test item when there are multiple test items, so as to obtain a test result corresponding to the Mth test item; if the state of the first simulation node is changed after the execution of the Mth test item, the state of the first simulation node is restored; after restoring the state of the first simulation node, the (M+1)th test item is executed to obtain a test result corresponding to the (M+1)th test item.

[0116] Optionally, the execution module 602 is specifically used to determine, for the Mth test item, whether the first simulation node needs to interact with the target message in the case of simulating a message transmission failure corresponding to the test item when executing the test item; if so, modify the fault flag bit of the first simulation node so that the first simulation node can send the target message in the case of simulating a message transmission failure.

[0117] Optionally, the execution module 602 is specifically used to sort the multiple test items according to their execution time when there are multiple test items for the electronic control unit under test, and obtain a sorting result. The shorter the execution time of a test item, the higher its position in the sorting result. According to the sorting result, the multiple test items are executed sequentially to obtain a test result corresponding to each test item.

[0118] See Figure 7 , Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. For example... Figure 7 As shown, the electronic device 700 includes a memory 701 and a processor 702, wherein the memory 701 stores program code 7011, and the processor 702 is used to call and execute the program code 7011 to perform the method in any of the foregoing embodiments.

[0119] This application also provides a computer-readable storage medium storing program code thereon, which, when executed by a processor, implements the steps of any of the foregoing embodiments. The computer-readable storage medium may include, but is not limited to, any type of disk, including floppy disks, optical disks, Digital Video Discs (DVDs), and Compact Disc Read-Only Memory (CD-ROMs). Only Memory, CD ROM, microdrives, magneto-optical disks, and read-only memory (ROM) Only Memory (ROM), Random Access Memory (RAM), Erasable Programmable Read-Only Memory (EPROM) Only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), dynamic random access memory (DRAM), video random access memory (VRAM), flash memory devices, magnetic or optical cards, nanosystems (including molecular memory ICs), or any type of media or device suitable for storing instructions and / or data.

[0120] This application also provides a program code product that, when run on a computer, causes the computer to perform the aforementioned related steps to implement the testing method in any of the above embodiments.

[0121] The computer-readable storage medium and program code products provided in this application are used to run the corresponding methods provided above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods provided above, and will not be repeated here.

[0122] Through the above description of the embodiments, those skilled in the art will understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0123] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0124] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A testing method, characterized in that, The method includes: Determine the target message that the electronic control unit under test needs to process; With N simulation nodes pre-created, a first simulation node is determined from the N simulation nodes to process the target message, and each of the first simulation nodes is used to process one of the target messages in the network where the electronic control unit under test is located; Control the first simulation node to interact with the electronic control unit under test (ECU) to receive the target message; The test items of the electronic control unit under test are executed to obtain test results. The test items are used to test whether the electronic control unit under test can correctly process the target message.

2. The method according to claim 1, characterized in that, Before controlling the first simulation node to interact with the electronic control unit under test (ECU) regarding the target message, the method further includes: If the first simulation node is not included among the N simulation nodes, the first simulation node is created; Alternatively, if the N simulation nodes have not been created in advance, the first simulation node may be created.

3. The method according to claim 1, characterized in that, The method further includes: If the N simulation nodes include a second simulation node, then the second simulation node is shut down. The second simulation node is any simulation node other than the first simulation node among the N simulation nodes.

4. The method according to claim 3, characterized in that, The step of shutting down the second simulation node includes: When N is greater than a preset number, determine the proportion of the second simulation node among the N simulation nodes; If the percentage is greater than the preset percentage, the second simulation node is turned off.

5. The method according to claim 1, characterized in that, The execution of test items for the electronic control unit under test to obtain test results includes: When there are multiple test items, the Mth test item is executed to obtain a test result corresponding to the Mth test item; If the state of the first simulation node is changed after the Mth test item is executed, then the state of the first simulation node is restored. After restoring the state of the first simulation node, the (M+1)th test item is executed to obtain a test result corresponding to the (M+1)th test item.

6. The method according to claim 5, characterized in that, Before executing the Mth test item to obtain a test result corresponding to the Mth test item, the method further includes: For the Mth test item, determine whether the first simulation node needs to interact with the target message when simulating a message transmission failure corresponding to the test item when executing the test item; If so, the fault flag bit of the first simulation node is modified so that the first simulation node sends the target message in the event of a simulated message transmission failure.

7. The method according to claim 6, characterized in that, Executing the Mth test item to obtain a test result corresponding to the Mth test item includes: Determine the number of executions corresponding to the fault flag bit; The Mth test item is executed the specified number of times to obtain a test result corresponding to each execution of the Mth test item.

8. The method according to any one of claims 1-7, characterized in that, The execution of test items for the electronic control unit under test to obtain test results includes: When there are multiple test items for the electronic control unit under test, the multiple test items are sorted according to their execution time to obtain a sorting result. The shorter the execution time of the test item, the higher its position in the sorting result. Based on the sorting result, multiple test items are executed sequentially to obtain a test result corresponding to each test item.

9. A testing device, characterized in that, The device includes: A determination module is used to determine the target message that the electronic control unit under test needs to process; given that N simulation nodes have been pre-created, a first simulation node is determined from the N simulation nodes to process the target message, and each of the first simulation nodes is used to process one of the target messages in the network where the electronic control unit under test is located; the first simulation node is controlled to interact with the electronic control unit under test to process the target message; The execution module is used to execute the test items of the electronic control unit under test to obtain test results. The test items are used to test whether the electronic control unit under test can correctly process the target message.

10. A readable storage medium, characterized in that, The readable storage medium stores program code, which is executed by a processor to implement the method of any one of claims 1-8.

Images