Network pressure test method, device and equipment of vehicle-mounted controller and storage medium

Abstract

The invention discloses a network pressure testing method, device and equipment of a vehicle-mounted controller and a storage medium, and relates to the technical field of vehicle electric control testing, and the network pressure testing method of the vehicle-mounted controller comprises the steps: obtaining a network pressure testing demand of the vehicle-mounted controller; determining a target test case according to the network pressure test requirement; performing a network pressure test on the to-be-tested controller through the target test case to obtain a test result; and generating a test report according to the test process record and the test result. According to the application, the performance and stability of the vehicle-mounted controller under different network load conditions can be accurately tested and evaluated, so that the quality and performance of an automobile electronic control system are improved.

Description

Technical Field

[0001] This application relates to the technical field of vehicle electronic control testing, and particularly to a network stress testing method, device, equipment and storage medium for in-vehicle controllers. Background Art

[0002] With the development of automotive intelligence and networking, in-vehicle controllers, as key components for control and management in vehicles, their performance and stability directly affect the running safety of vehicles and the user experience. During the automotive design and manufacturing process, it becomes particularly important to conduct strict network stress testing on in-vehicle controllers to ensure their reliable operation in various complex network environments.

[0003] Currently, the network stress testing of in-vehicle controllers mainly relies on simulating the software and hardware environments in actual applications and the user usage process. These tests simulate different network load conditions by sending a large number of Controller Area Network (CAN) messages to evaluate the performance, reliability and stability of the controllers. During the testing process, professional testing equipment and software are usually used and connected to the controller under test through the CAN bus to achieve the network stress testing of the controller's CAN network.

[0004] Although the existing testing methods can provide a certain degree of evaluation, they have some obvious deficiencies. First, the existing testing methods may not be able to comprehensively cover all possible network load conditions, resulting in limitations in the test results. Second, the testing process may lack flexibility and scalability and is difficult to adapt to the changing test requirements. In addition, the testing efficiency and automation level are not high, resulting in a long test cycle and high labor costs. These problems limit the accuracy and efficiency of the testing and affect the quality assurance of in-vehicle controllers. Therefore, how to accurately test and evaluate the performance and stability of in-vehicle controllers under different network load conditions has become an urgent problem to be solved.

[0005] The above content is only used to assist in understanding the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0006] The purpose of this application is to provide a network stress testing method, device, equipment and storage medium for in-vehicle controllers, aiming to solve the technical problem of how to accurately test and evaluate the performance and stability of in-vehicle controllers under different network load conditions.

[0007] To achieve the above object, the present application proposes a network pressure test method for an in-vehicle controller. The method is applied to a host computer, and the host computer is connected to a controller area network data conversion device through a universal serial bus. The controller area network data conversion device is connected to a to-be-tested controller through a controller area network bus. The method includes:

[0008] Obtain the network pressure test requirements of the in-vehicle controller;

[0009] Determine a target test case according to the network pressure test requirements;

[0010] Perform a network pressure test on the to-be-tested controller through the target test case to obtain a test result;

[0011] Generate a test report according to the test process record and the test result.

[0012] In one embodiment, the step of performing a network pressure test on the to-be-tested controller through the target test case to obtain a test result includes:

[0013] Obtain the configuration requirements of the target test case;

[0014] Configure the parameters of the controller area network data conversion device according to the configuration requirements;

[0015] When the parameter configuration is completed, perform a network pressure test on the to-be-tested controller through the target test case;

[0016] During the test process, capture all controller area network messages, and record all network segment states of the to-be-tested controller and the bus load rate of each network segment of the to-be-tested controller;

[0017] Obtain a test result according to the controller area network messages, the network segment states, and the bus load rate.

[0018] In one embodiment, the step of performing a network pressure test on the to-be-tested controller through the target test case when the parameter configuration is completed includes:

[0019] When the parameter configuration is completed and the target test case is a high-priority - small-cycle message impact test case, simulate and send a first preset message to the to-be-tested network segment port of the to-be-tested controller through the controller area network data conversion device, and continue for a first preset duration;

[0020] When there is a conflict between the identifier of the currently sent first preset message and the in-vehicle message, skip the currently sent first preset message;

[0021] When the bus load rate is less than the preset average load rate threshold, continue to simulate sending the first preset message until the DUT (Device Under Test) controller resets or an error frame appears.

[0022] When the bus load rate is greater than or equal to the preset average load rate threshold or the number of transmissions of the first preset message is greater than the preset message quantity, stop simulating the transmission of the first preset message, and monitor the status of all network segments of the DUT controller for a second preset duration to complete the network stress test.

[0023] In one embodiment, the step of performing a network stress test on the DUT controller using the target test case when the parameter configuration is completed includes:

[0024] When the parameter configuration is completed and the target test case is a standard frame identifier traversal test case, compare the second preset message with the message data in the controller area network database file to obtain a comparison result.

[0025] When the comparison result indicates the existence of the same message or the second preset message is a network management message, skip the currently transmitted second preset message.

[0026] When the comparison result indicates the non - existence of the same message, simulate sending the second preset message to the DUT network segment port of the DUT controller through the controller area network data conversion device every third preset duration, and monitor the status of all network segments of the DUT controller for a fourth preset duration to complete the network stress test.

[0027] In one embodiment, the step of performing a network stress test on the DUT controller using the target test case when the parameter configuration is completed includes:

[0028] When the parameter configuration is completed and the target test case is an error frame impact test case, simulate sending a first preset number of error frames to the DUT network segment port of the DUT controller through the controller area network data conversion device every fifth preset duration and / or sixth preset duration and / or seventh preset duration, where the fifth preset duration is greater than the sixth preset duration, and the sixth preset duration is greater than the seventh preset duration.

[0029] Repeat sending the error frames a second preset number of times to complete the network stress test.

[0030] In one embodiment, the step of performing a network stress test on the DUT controller using the target test case when the parameter configuration is completed includes:

[0031] When the parameter configuration is completed and the target test case is an identifier conflict test case, a third preset message is simulated and sent to the tested network segment port of the tested controller through the controller local area network data conversion device for an eighth preset time, and the message attributes of the third preset message are the same, and the message attributes include a message period and a data field length;

[0032] Adjust the message period and / or the data field length, repeat the step of simulating sending the third preset message to the tested network segment port of the tested controller through the controller LAN data conversion device, and continue for an eighth preset time to complete the network stress test.

[0033] In one embodiment, the step of determining a target test case according to the network stress test requirement includes:

[0034] When the network stress test requirement is to test the performance of the controller to be tested under the design limit of the network load rate, the high priority-small cycle message impact test case, the low priority-large cycle message impact test case, the high priority-large cycle message impact test case, the low priority-small cycle message impact test case and the full network segment load impact test case are used as target test cases;

[0035] When the network stress test requirement is to test the performance of the controller to be tested without being affected by an abnormal network environment, a message compatibility test case with a data field length of a first preset length, a message compatibility test case with a data field length greater than a second preset length, an extended frame message compatibility test case, an error frame impact test case, an identifier conflict test case, a standard frame identifier traversal test case, a diagnostic identifier traversal test case, and an on-board diagnostic function addressing impact test case are used as target test cases, and the first preset length is less than or equal to the second preset length;

[0036] When the network stress test requirement is to simulate the performance of the controller to be tested in a real vehicle network environment, the whole vehicle message playback stress test case is used as the target test case.

[0037] In addition, to achieve the above purpose, the present application also proposes a network stress testing device for a vehicle-mounted controller, the device comprising:

[0038] The requirement acquisition module is used to obtain the network stress test requirements of the vehicle controller;

[0039] A test case determination module, used to determine a target test case according to the network stress test requirements;

[0040] A network stress test module, used to perform a network stress test on the controller to be tested through the target test case to obtain a test result;

[0041] A report generation module, configured to generate a test report according to the test process record and the test result.

[0042] In addition, to achieve the above object, the present application further provides a network pressure test device for a vehicle-mounted controller, the device including: a memory, a processor, and a computer program stored on the memory and executable on the processor, the computer program being configured to implement the steps of the network pressure test method for a vehicle-mounted controller as described above.

[0043] In addition, to achieve the above object, the present application further provides a storage medium, the storage medium being a computer-readable storage medium, and a computer program being stored on the storage medium, the computer program, when executed by a processor, implementing the steps of the network pressure test method for a vehicle-mounted controller as described above.

[0044] In addition, to achieve the above object, the present application further provides a computer program product, the computer program product including a computer program, the computer program, when executed by a processor, implementing the steps of the network pressure test method for a vehicle-mounted controller as described above.

[0045] One or more technical solutions proposed by the present application have at least the following technical effects:

[0046] Obtain the network pressure test requirements of the vehicle-mounted controller; determine the target test cases according to the network pressure test requirements; perform a network pressure test on the to-be-tested controller through the target test cases to obtain test results; generate a test report according to the test process record and the test results. The host computer first obtains the network pressure test requirements by analyzing the design specifications of the vehicle-mounted controller and the expected network communication conditions, or receiving the specific expectations and concerns of the user regarding the performance of the vehicle-mounted controller. This step ensures that the test requirements match the design objectives of the controller and provides a clear direction for the design of test cases. Next, the host computer determines the target test cases according to these test requirements, selects or designs a series of test scenarios that can simulate different network conditions, such as high load rates, abnormal network environments, in-vehicle network environments, etc. This helps to evaluate the performance and stability of the controller under various network pressures. Then, the host computer performs a network pressure test on the to-be-tested controller by executing these target test cases, and real-time monitors and records the responses and performance data of the controller, such as processing time, error rate, bus load rate, etc. These data are crucial for evaluating the reliability and stability of the controller. Finally, the host computer generates a detailed test report according to the records of the test process and the test results, including test results, abnormal events, performance metrics, etc. This report provides a clear overview of the test for engineers, helps them understand the performance of the controller, and provides a basis for the further development and optimization of the product. Through this series of steps, the host computer can accurately test and evaluate the performance and stability of the vehicle-mounted controller under different network load conditions, thereby improving the quality and performance of the automotive electronic control system. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] The accompanying drawings herein are incorporated into the specification and constitute a part of this specification, showing embodiments consistent with the present application, and are used together with the specification to explain the principles of the present application.

[0048] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings required for use in the description of the embodiments or the prior art. Obviously, for those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0049] Figure 1 It is a schematic flowchart provided for the first embodiment of the network pressure test method for the vehicle-mounted controller of the present application;

[0050] Figure 2 It is a schematic diagram of the software interface of the host computer provided for the first embodiment of the network pressure test method for the vehicle-mounted controller of the present application;

[0051] Figure 3 It is a schematic flowchart provided for the second embodiment of the network pressure test method for the vehicle-mounted controller of the present application;

[0052] Figure 4 Schematic diagram of the module structure of the network pressure test device for the vehicle-mounted controller according to the embodiment of the present application;

[0053] Figure 5 Schematic diagram of the device structure of the hardware operating environment involved in the network pressure test method for the vehicle-mounted controller according to the embodiment of the present application.

[0054] The realization of the purpose, functional features and advantages of the present application will be further described in conjunction with the embodiments with reference to the accompanying drawings. Detailed implementation manners

[0055] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of the present application and are not used to limit the present application.

[0056] In order to better understand the technical solutions of the present application, the following will be described in detail in conjunction with the accompanying drawings of the specification and specific implementation manners.

[0057] With the development of automotive intelligence and networking, the performance and stability of vehicle-mounted controllers are crucial for driving safety and user experience. Therefore, in the design and manufacturing process, strict network pressure testing is essential to ensure that the controller can work reliably in complex network environments. Currently, such tests mainly evaluate the controller's performance by simulating the actual application environment and the user's usage process and using professional equipment to send a large number of CAN messages. However, the existing methods have limitations: they cannot comprehensively cover all network load conditions, the test flexibility and scalability are insufficient, and the automation level and efficiency are relatively low, resulting in a long test cycle and high costs, which affect the test accuracy and the quality assurance of vehicle-mounted controllers.

[0058] The main solutions of the embodiments of the present application are as follows: First, the host computer analyzes the design specifications and user expectations of the vehicle-mounted controller to determine the network pressure test requirements and ensure that the test matches the design goals. Next, select or design test scenarios that simulate different network conditions according to the requirements to evaluate the performance and stability of the controller under various pressures. Then, execute the test cases and monitor and record the response data of the controller in real time, such as processing time, error rate, etc., to evaluate its reliability and stability. Finally, generate a detailed report containing test results, abnormal events, and performance metrics to provide a clear test overview for engineers and support the development and optimization of the product.

[0059] It should be noted that the execution subject of the embodiments of the present application can be a computing service device with data processing, network communication, and program running functions, such as a tablet computer, a personal computer, a mobile phone, etc., or an electronic device, a host computer, etc. that can implement the above functions. Hereinafter, the host computer will be taken as an example to describe this embodiment and the following embodiments.

[0060] Based on this, an embodiment of the present application provides a network pressure test method for an in-vehicle controller. Refer to Figure 1 , Figure 1 which is a schematic flowchart of the first embodiment of the network pressure test method for the in-vehicle controller of the present application.

[0061] In this embodiment, the network pressure test method for the in-vehicle controller is applied to a host computer. The host computer is connected to a controller area network (CAN) data conversion device through a universal serial bus (USB). The CAN data conversion device is connected to a to-be-tested controller through a CAN bus. The method includes steps S10 to S40:

[0062] Step S10: Obtain the network pressure test requirements of the in-vehicle controller;

[0063] It should be noted that the in-vehicle controller refers to the to-be-tested CAN network controller, abbreviated as the to-be-tested controller or the equipment under test (EUT). This is the object that needs to perform the network pressure test, that is, the device to be tested. The to-be-tested controller is connected to the CAN data conversion device through the CAN bus and communicates with the host computer through the CAN data conversion device to perform the network pressure test. In an automobile, the in-vehicle controller is responsible for managing and controlling various electronic systems of the automobile, such as engine control, body electronics, safety systems, etc. The host computer refers to the computer or test terminal that executes the test operation. It can be a PC or a test terminal of other operating systems. The host computer communicates with the CAN data conversion device through the installed software, controls the test process, collects and sends CAN messages, and analyzes the test results. The host computer software is programmed in Python + Qt language to implement functions such as human-computer interaction, test input, and test process monitoring.

[0064] Please refer to Figure 2 , Figure 2This is a schematic diagram of the software interface of the host computer provided by Embodiment 1 of the network pressure test method for the vehicle-mounted controller of this application. This figure shows four main functional areas of the host computer software interface, including the message display area, the test process display area, the manual test control area, and the automatic test control area. These areas together constitute the human-computer interaction platform of the test system. In the "message display area", the CAN signals sent by the EUT under test and the CAN signals sent by the test system are displayed in real time, providing users with an intuitive understanding of the communication status. The "test process display area" is used to record and display the detailed information of the test process, helping users to track the progress and status of the test. The "manual test control area" provides a human-computer interaction interface for manual testing, allowing users to input vehicle network data, shield message data sent by the EUT, and other operations. The "automatic test control area" is used for human-computer interaction during automatic testing. Users can select test cases and start the automatic test process here. The overall interface design aims to improve the efficiency and convenience of testing, while ensuring the monitoring and control of the test process.

[0065] Universal Serial Bus (USB) is a widely used interface technology for connecting a computer to external devices. In this embodiment, the host computer is connected to the CAN data conversion device through the USB interface to achieve data transmission and communication. The controller area network data conversion device is an intermediate device connecting the host computer and the controller under test. It converts the instructions sent by the host computer through USB into CAN bus signals for communication with the controller under test. This device usually has CAN_H and CAN_L interfaces for connecting to the CAN bus network. Controller Area Network bus (CAN bus) is a communication network inside a vehicle used to connect and communicate various electronic control units (ECUs). In this embodiment, the CAN bus is used to connect the CAN data conversion device and the controller under test to achieve data transmission and communication.

[0066] It can be understood that, first, the host computer determines its expected network communication behaviors and performance parameters in different working modes by analyzing the design documents and specifications of the vehicle-mounted controller, so as to ensure that the test requirements match the design objectives of the controller. Second, the host computer collects actual vehicle operation data, including network traffic, message types, transmission frequencies, etc., and uses these data to simulate the network environment in the real world, ensuring the representativeness and practicality of the test scenario. Then, the host computer receives the specific expectations and concerns of the user regarding the performance of the vehicle-mounted controller, which helps to customize test cases to meet specific performance and reliability requirements. Finally, based on the information collected, the host computer uses professional test requirement analysis tools, such as Python scripts or Qt interface design tools, to define and optimize the test cases, which can ensure the systematicness and comprehensiveness of the test process, while improving the automation level and efficiency of the test. Through these steps, the host computer can accurately obtain the network stress test requirements of the vehicle-mounted controller, laying a solid foundation for the subsequent test process.

[0067] Step S20, determine the target test cases according to the network stress test requirements;

[0068] It should be noted that the target test cases refer to the specific test scenarios and test steps designed according to the network stress test requirements of the vehicle-mounted controller, and the purpose of these test cases is to verify and evaluate the performance and stability of the vehicle-mounted controller under specific network stress conditions.

[0069] It can be understood that, first, the host computer identifies the test points that need special attention according to the network stress test requirements of the vehicle-mounted controller, such as the performance under high-load conditions or the processing ability of specific error frames. Then, the host computer selects the test cases that match these test points from the pre-developed test case library, such as selecting the "High-priority, small-cycle message impact test case" to evaluate the performance of the controller under high load, or selecting the "Error frame impact test case" to simulate the impact of an abnormal network environment on the controller. Next, the host computer configures the selected test cases, sets specific test parameters, such as the sending frequency, duration, and expected system response of the message, to ensure that the test can accurately simulate the actual network stress conditions. Finally, the host computer integrates the configured test cases into the test process and displays them to the user through the interface of the host computer software, and also allows the user to select and change the corresponding test cases according to the actual test requirements, which can ensure the pertinence and effectiveness of the test, while improving the automation level and efficiency of the test. Through this series of steps, the host computer can ensure that the selection and application of the test cases can accurately meet the network stress test requirements of the vehicle-mounted controller.

[0070] As an example, the step of determining the target test cases according to the network stress test requirements includes: when the network stress test requirement is to test the performance of the to-be-tested controller under the design limit of the network load rate, taking the high-priority - small-cycle message impact test case, the low-priority - large-cycle message impact test case, the high-priority - large-cycle message impact test case, the low-priority - small-cycle message impact test case, and the whole-network segment load impact test case as the target test cases; when the network stress test requirement is to test the performance of the to-be-tested controller without being affected by an abnormal network environment, taking the message compatibility test case with the data field length being the first preset length, the message compatibility test case with the data field length being greater than the second preset length, the extended frame message compatibility test case, the error frame impact test case, the identifier conflict test case, the standard frame identifier traversal test case, the diagnostic identifier traversal test case, and the in-vehicle diagnostic function addressing impact test case as the target test cases, where the first preset length is less than or equal to the second preset length; when the network stress test requirement is to simulate and test the performance of the to-be-tested controller in the real vehicle network environment, taking the vehicle-wide message playback stress test case as the target test case.

[0071] Testing the performance of the to-be-tested controller under the design limit of the network load rate: This test requirement refers to evaluating the performance of the EUT when it reaches or approaches its designed maximum network load capacity to ensure that it can still work properly under extreme conditions.

[0072] High-priority - small-cycle message impact test case: This test case simulates the sending of high-priority short-cycle messages to test the performance of the EUT when handling frequent and important network communications. Please refer to Table 1.

[0073] Table 1

[0074]

[0075] Table 2

[0076] Serial Number Message Name Message ID Period DLC Data0 Data1 Data2 Data3 Data4 Data5 Data6 Data7 1 Msg1 0x001 5ms 8 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 2 Msg2 0x002 5ms 8 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 3 Msg3 0x003 5ms 8 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 4 Msg4 0x004 5ms 8 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA 5 Msg5 0x005 5ms 8 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 6 Msg6 0x006 5ms 8 0xF0 0xF0 0xF0 0xF0 0xF0 0xF0 0xF0 0xF0 7 Msg7 0x007 5ms 8 0xCC 0xCC 0xCC 0xCC 0xCC 0xCC 0xCC 0xCC 8 Msg8 0x008 5ms 8 0xF0 0x0F 0xF0 0x0F 0xF0 0x0F 0xF0 0x0F x Msgx 0xX 5ms 8 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA n MsgN 0xN 5ms 8 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA

[0077] Low-priority - large-cycle message impact test case: This test case simulates the sending of low-priority long-cycle messages to evaluate the performance of the EUT when handling less frequent but larger data volume network communications. Please refer to Table 3.

[0078] Table 3

[0079]

[0080] Table 4

[0081] Serial Number Message Name Message ID Period DLC Data0 Data1 Data2 Data3 Data4 Data5 Data6 Data7 1 Msg1 0x6FF 1000ms 8 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 2 Msg2 0x6FE 1000ms 8 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 3 Msg3 0x6FD 1000ms 8 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 4 Msg4 0x6FC 1000ms 8 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA 5 Msg5 0x6FB 1000ms 8 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 6 Msg6 0x6FA 1000ms 8 0xF0 0xF0 0xF0 0xF0 0xF0 0xF0 0xF0 0xF0 7 Msg7 0x6F9 1000ms 8 0xCC 0xCC 0xCC 0xCC 0xCC 0xCC 0xCC 0xCC 8 Msg8 0x6F8 1000ms 8 0xF0 0x0F 0xF0 0x0F 0xF0 0x0F 0xF0 0x0F x Msgx 0xX 1000ms 8 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA n MsqN 0xN 1000ms 8 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA

[0082] High - Priority - Long - Period Message Impact Test Case: This test case combines the characteristics of high priority and long period, simulating the sending of important but infrequent messages to test the performance of the EUT under such mixed conditions. Please refer to Table 5.

[0083] Table 5

[0084]

[0085]

[0086] Table 6

[0087] Serial Number Message Name Message ID Period DLC Data0 Data1 Data2 Data3 Data4 Data5 Data6 Data7 1 Msg1 0x001 1000ms 8 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 2 Msg2 0x002 1000ms 8 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 3 Msg3 0x003 1000ms 8 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 4 Msg4 0x004 1000ms 8 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA 5 Msg5 0x005 1000ms 8 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 6 Msg6 0x006 1000ms 8 0xF0 0xF0 0xF0 0xF0 0xF0 0xF0 0xF0 0xF0 7 Msg7 0x007 1000ms 8 0xCC 0xCC 0xCC 0xCC 0xCC 0xCC 0xCC 0xCC 8 Msg8 0x008 1000ms 8 0xF0 0x0F 0xF0 0x0F 0xF0 0x0F 0xF0 0x0F x Msgx 0xX 1000ms 8 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA n MsgN 0xN 1000ms 8 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA

[0088] Low - Priority - Short - Period Message Impact Test Case: This test case simulates the sending of low - priority short - period messages to evaluate the performance of the EUT when processing frequent but unimportant information. Please refer to Table 7.

[0089] Table 7

[0090]

[0091] Table 8

[0092] Sequence number Message name Message ID Period DLC Data0 Data1 Data2 Data3 Data4 Data5 Data6 Data7 1 Msg1 0x6FF 5ms 8 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 2 Msg2 0x6FE 5ms 8 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 3 Msg3 0x6FD 5ms 8 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 4 Msg4 0x6FC 5ms 8 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA 5 Msg5 0x6FB 5ms 8 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 6 Msg6 0x6FA 5ms 8 0xF0 0xF0 0xF0 0xF0 0xF0 0xF0 0xF0 0xF0 7 Msg7 0x6F9 5ms 8 0xCC 0xCC 0xCC 0xCC 0xCC 0xCC 0xCC 0xCC 8 Msg8 0x6F8 5ms 8 0xF0 0x0F 0xF0 0x0F 0xF0 0x0F 0xF0 0x0F x Msgx 0xX 5ms 8 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA n MsgN 0xN 5ms 8 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA

[0093] Full - Network - Segment Load Impact Test Case: This test case simulates that all network segments of the entire network are in a high - load state to test the performance of the EUT under the condition of high full - network - segment load. Please refer to Table 9.

[0094] Table 9

[0095]

[0096] Table 10

[0097] Sequence number [Message name Message ID Period DLC Data0 Data1 Data2 Data3 Data4 Data5 Data6 Data7 1 Msg1 0x001 5ms 8 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 2 Msg2 0x002 5ms 8 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 3 Msg3 0x003 5ms 8 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 0x0F 4 Msg4 0x004 5ms 8 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA 5 Msg5 0x005 5ms 8 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 6 Msg6 0x006 5ms 8 0xF0 0xF0 0xF0 0xF0 0xF0 0xF0 0xF0 0xF0 7 Msg7 0x007 5ms 8 0xCC 0xCC 0xCC 0xCC 0xCC 0xCC 0xCC 0xCC 8 Msg8 0x008 5ms 8 0xF0 0x0F 0xF0 0x0F 0xF0 0x0F 0xF0 0x0F x Msgx 0xX 5ms 8 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA n MsgN 0xN 5ms 8 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA

[0098] Testing the performance of the to - be - tested controller without being affected by an abnormal network environment: This test requirement refers to evaluating the performance and stability of the EUT under abnormal network conditions, such as error frames, identifier conflicts, etc.

[0099] Message Compatibility Test Case with Data Field Length of the First Preset Length: Testing the compatibility of the EUT with messages having a specific data field length (shorter). In this embodiment, the first preset length is 0. Please refer to Table 11.

[0100] Table 11

[0101]

[0102]

[0103] Table 12

[0104] Sequence number Message name Message ID Period DLC 1 Msg1 0x10 10ms 0 2 Msg2 0x20 20ms 0 3 Msg3 0x70 70ms 0 4 Msg4 0x100 100ms 0 5 Msg5 0x200 200ms 0 6 Msg6 0x300 300ms 0 7 Msg7 0x600 600ms 0

[0105] Message compatibility test cases for data field lengths greater than the second preset length: To test the compatibility of the EUT with messages having a longer data field length. In this embodiment, the second preset length is 8. Please refer to Table 13.

[0106] Table 13

[0107]

[0108] Table 14

[0109] Sequence number Message name Message ID Period DLC 1 Msg1 0x10 10ms 0x9 2 Msg2 0x20 20ms 0xA 3 Msg3 0x70 70ms 0xB 4 Msg4 0x100 100ms 0xC 5 Msg5 0x200 200ms 0xD 6 Msg6 0x300 300ms 0xE 7 Msg7 0x600 600ms 0xF

[0110] Extended frame message compatibility test cases: To test the compatibility of the EUT with extended frame messages, which are typically used for transmitting large amounts of data. Please refer to Table 15.

[0111] Table 15

[0112]

[0113]

[0114] Table 16

[0115] Sequence number Message name Message ID Period DLC Data0 Data1 Data2 Data3 Data4 Data5 Data6 Data7 Remarks 1 Msg1 0x0CF00400 10ms 8 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA EEC1 2 Msg2 0x1CFE9200 100ms 8 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF EI 3 Msg3 0x0C000003 10ms 8 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55 TSC1 4 Msg4 0x18F00000 100ms 4 0x55 0x55 0x55 0x55 - - - - ERC1 5 Msg5 0x18FD0103 100ms 0 - - - - - - - - TCD 6 Msg6 0x18FEEE00 1000ms 8 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 ET1

[0116] Error frame impact test cases: Simulate sending error frames to test the performance and error handling ability of the EUT in the presence of error frames. Please refer to Table 17.

[0117] Table 17

[0118]

[0119] Identifier conflict test cases: Simulate sending messages that conflict with the message identifiers of the EUT itself to test the performance of the EUT in case of identifier conflicts. Please refer to Table 18.

[0120] Table 18

[0121]

[0122]

[0123] Standard frame identifier traversal test cases: Test the response of the EUT to all possible standard frame identifiers to ensure that it can correctly handle various messages. Please refer to Table 19.

[0124] Table 19

[0125]

[0126] Table 20

[0127] Sequence number Message name Message ID Period DLC Data0 Data1 Data2 Data3 Data4 Data5 Data6 Data7 1 Msg1 0x001 10ms 8 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA 2 Msg2 0x002 10ms 8 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA 3 Msg3 0x003 10ms 8 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA x Msgx 0xX 10ms 8 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA 1791 Msg 6FF 0x6FF 10ms 8 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA 0xAA

[0128] Diagnostic identifier traversal test case: Test the response of the EUT to all possible diagnostic identifiers to ensure the normal operation of its diagnostic function. Refer to Table 21.

[0129] Table 21

[0130]

[0131]

[0132] Table 22

[0133] Sequence number Message name Message ID Event DLC Data0 Data1 Data2 Data3 Data4 Data5 Data6 Data7 1 Msg1 0x700 Event 8 0x02 0x10 0x01 0x00 0x00 0x00 0x00 0x00 2 Msg2 0x701 Event 8 0x02 0x10 0x01 0x00 0x00 0x00 0x00 0x00 3 Msg3 0x702 Event 8 0x02 0x10 0x01 0x00 0x00 0x00 0x00 0x00 0xX Msgx 0xX Event 8 0x02 0x10 0x01 0x00 0x00 0x00 0x00 0x00 2566 Msg 7FF 0x7FF Event 8 0x02 0x10 0x01 0x00 0x00 0x00 0x00 0x00

[0134] On-vehicle diagnostic function addressing impact test case: Test the performance of the EUT under on-vehicle diagnostic (OBD) function addressing to ensure its stability under specific addressing conditions. Refer to Table 23.

[0135] Table 23

[0136]

[0137] Table 24

[0138] Sequence number Message name Message ID Event DLC Data0 Data1 Data2 Data3 Data4 Data5 Data6 Data7 1 Msg1 0x7DF Event 8 0x02 0x01 0x00 0x00 0x00 0x00 0x00 0x00 2 Msg2 0x18DB33F1 Event 8 0x02 0x01 0x00 0x00 0x00 0x00 0x00 0x00

[0139] Simulate the performance of the controller under test in the real vehicle network environment: This test requirement means evaluating the performance of the EUT under actual vehicle operating conditions by simulating the real vehicle network environment.

[0140] Whole vehicle message replay stress test case: This case simulates the real vehicle network environment by replaying the collected whole vehicle network data to test the performance and stability of the EUT in this environment. This includes masking the message data sent by the EUT, finding the power-on and power-off moments in the whole vehicle network data for synchronizing the power-on and power-off simulation of the EUT on the test bench for stress testing. Refer to Table 25.

[0141] Table 25

[0142]

[0143]

[0144] When conducting network stress testing, first, when the test requirement is to evaluate the performance of the to-be-tested controller when the network load reaches the design limit, the upper computer will select a series of target test cases, including high-priority - small-cycle message impact test cases to examine the controller's ability to handle urgent and frequent communication requirements, low-priority - large-cycle message impact test cases to test the controller's ability to handle non-urgent but large-volume communication requirements, high-priority - large-cycle message impact test cases to evaluate the controller's performance when handling important but infrequent communications, low-priority - small-cycle message impact test cases to test the controller's ability to handle non-urgent and frequent communication requirements, and full-network segment load impact test cases to simulate the controller's performance under high-load conditions of the entire network. Second, when the test requirement is to ensure that the to-be-tested controller can still work properly in an abnormal network environment, the upper computer will select message compatibility test cases with a data field length of the first preset length to test the controller's ability to handle short data messages, message compatibility test cases with a data field length greater than the second preset length to test the controller's ability to handle long data messages, extended frame message compatibility test cases to evaluate the controller's compatibility with extended frames, error frame impact test cases to simulate the impact of error frames on the controller's performance, identifier conflict test cases to test the stability of the controller in case of identifier conflicts, standard frame identifier traversal test cases and diagnostic identifier traversal test cases to ensure that the controller can correctly respond to all possible identifiers, and in-vehicle diagnostic function addressing impact test cases to test the controller's performance under in-vehicle diagnostic function addressing. Finally, when the test requirement is to simulate the real vehicle network environment, the upper computer will select vehicle message playback stress test cases to test the performance and stability of the controller under real network conditions by playing back actual vehicle network data. The selection and application of these test cases ensure that the performance and stability of the to-be-tested controller are comprehensively evaluated under various network conditions.

[0145] Step S30: Conduct network stress testing on the to-be-tested controller through the target test cases to obtain test results;

[0146] It should be noted that the test results refer to the data and information collected and analyzed after a series of network stress test cases for the controller under test. These test results specifically include: (1) Performance data: including performance indicators such as response time, processing capacity, and stability of the EUT under different test conditions. (2) Error and exception records: record whether error frames, resets, busoff states, or other abnormal behaviors occur in the EUT during the test. (3) Bus load rate monitoring: the bus load rate (BUSLOAD) of each network segment during the test to evaluate the performance of the EUT under different load conditions. (4) Message cycle deviation: the deviation between the cycle of the messages sent by the EUT and its expected cycle, used to evaluate its time synchronization and scheduling capabilities. (5) Compatibility test results: the compatibility and processing capabilities of the EUT for different types of messages (such as DLC = 0, DLC> 8, extended frames, etc.). (6) Conflict and addressing test results: the performance of the EUT under the influence of identifier conflicts, standard frame identifier traversal, diagnostic identifier traversal, and OBD function addressing. (7) Test results of simulating the real vehicle network environment: evaluate the performance and stability of the EUT in the simulated real vehicle network environment through the vehicle message playback stress test. (8) Test conclusion: based on the test data and analysis, draw a conclusion on whether the EUT meets the design requirements and performance standards. (9) Test case information: the names, numbers of the executed test cases, and detailed descriptions of each test case. (10) Basic information of the EUT: basic information such as the model, version, and configuration of the controller under test. (11) EUT status record: the status changes of the EUT during the test, including records of key events such as resets, error frames, and warnings.

[0147] It can be understood that during the execution of the network stress test, the host computer first sends a series of designed CAN messages to the controller under test (EUT) through the CAN data conversion device according to the predetermined target test cases, such as the high-priority - small cycle message impact test case, the low-priority - large cycle message impact test case, etc., to simulate different network loads and abnormal situations. Then, the host computer software monitors the response of the EUT in real time, including its ability to process messages, system stability, and performance in high-load or abnormal network environments. At the same time, the host computer records key performance indicators such as the bus load rate, the number of error frames, the reset situation, and the accuracy of the message cycle during the test process of the EUT. In addition, the host computer will also pay special attention to the performance of the EUT under test cases such as abnormal data field length, extended frames, error frame impact, identifier conflicts, etc., and its performance in the vehicle message playback stress test simulating the real vehicle network environment. Finally, the host computer collects all test data, analyzes it, and obtains the test results, which include the performance data of the EUT, error and exception records, load rate monitoring data, message cycle deviation, compatibility test results, conflict and addressing test results, and real vehicle network environment simulation test results, so as to comprehensively evaluate the network performance and stability of the EUT. This can ensure that the EUT can operate stably under various network conditions and provide guarantee for the quality and performance of the automotive electronic control system.

[0148] Step S40, generate a test report according to the test process record and the test results.

[0149] It should be noted that the test process record refers to a series of detailed information about the test execution automatically recorded by the host computer software during the network stress test. These records include but are not limited to: (1) The execution order and parameter settings of the test cases. (2) The start and end times of each test case. (3) The detailed information of the CAN messages sent to the controller under test, including message ID, data length, cycle, etc. (4) The response of the EUT to these messages, including the received messages and any error frames. (5) The network load rate (BUSLOAD) during the test process. (6) Any abnormal events that occur, such as the reset of the EUT, the generation of error frames, identifier conflicts, etc.

[0150] The test report is an official document generated by the host computer software based on the test process records and test results after the test process ends. The test report usually includes the following contents: (1) Test results: List in detail the results of each test case, including whether the EUT has successfully processed the message and whether the expected performance criteria have been met. (2) Abnormal events: Record any abnormal situations that occurred during the test process, such as unexpected behaviors of the EUT, generation of error frames, system crashes, etc., and provide possible cause analyses. (3) Performance metrics: Display the key performance metrics of the EUT during the test process, such as response time, processing capacity, stability, etc., and compare them with the design requirements. (4) Test conclusion: Provide an overall evaluation of the EUT's performance based on the test results and analysis, pointing out its advantages and areas for improvement. (5) Suggestions and improvement measures: Based on the problems found in the test, put forward improvement suggestions and future test or design directions. The generation of the test report is to provide a comprehensive overview of the test, help engineers and decision-makers understand the performance of the EUT, and provide a basis for the further development and optimization of the product.

[0151] It can be understood that, firstly, during the execution of the network stress test by the host computer software, all network activities and responses of the controller under test are monitored and recorded in real time, including the CAN messages sent and received, the priority, period, data field length (Data Length Code, DLC) of the messages, and the bus load rate (BUSLOAD) of the EUT under different test conditions. This is done to ensure that every detail of the test is accurately captured and provide raw data for subsequent analysis. Secondly, once the test is completed, the host computer software will automatically organize and analyze the data, identify any abnormal events during the test process, such as error frames, resets, identifier conflicts, etc., and compare these events with the expected results of the test cases to determine whether the performance of the EUT meets the design requirements. Then, the host computer software integrates these analysis results into a test report, which not only includes a summary of the test results but also details the performance metrics of each test case, such as response time, processing capacity, stability, etc., and compares these metrics with the design standards. Finally, the test report will contain an overall evaluation of the EUT's performance, pointing out its advantages and areas for improvement, and putting forward specific improvement suggestions and future test or design directions based on the problems found in the test. This is to provide a comprehensive overview of the test for engineers and decision-makers, help them understand the performance of the EUT, and provide a basis for the further development and optimization of the product to ensure that the final product can meet the performance and stability requirements in actual applications.

[0152] This embodiment provides a network pressure test method for a vehicle-mounted controller, which includes obtaining the network pressure test requirements of the vehicle-mounted controller; determining target test cases according to the network pressure test requirements; performing a network pressure test on the to-be-tested controller through the target test cases to obtain test results; and generating a test report based on the test process record and the test results. The host computer first obtains the network pressure test requirements by analyzing the design specifications of the vehicle-mounted controller and the expected network communication conditions, or by receiving the specific expectations and concerns of users regarding the performance of the vehicle-mounted controller. This step ensures that the test requirements match the design objectives of the controller, providing a clear direction for the design of test cases. Next, the host computer determines the target test cases based on these test requirements, selecting or designing a series of test scenarios that can simulate different network conditions, such as high load rates, abnormal network environments, in-vehicle network environments, etc. This helps to evaluate the performance and stability of the controller under various network pressures. Then, the host computer performs a network pressure test on the to-be-tested controller by executing these target test cases, monitoring and recording the responses and performance data of the controller in real time, such as processing time, error rate, bus load rate, etc. These data are crucial for evaluating the reliability and stability of the controller. Finally, the host computer generates a detailed test report based on the records of the test process and the test results, including test results, abnormal events, performance metrics, etc. This report provides a clear overview of the test for engineers, helping them understand the performance of the controller and providing a basis for the further development and optimization of the product. Through this series of steps, the host computer can accurately test and evaluate the performance and stability of the vehicle-mounted controller under different network load conditions, thereby improving the quality and performance of the automotive electronic control system.

[0153] Based on the first embodiment of the present application, in the second embodiment of the present application, the same or similar content as that in the above-mentioned first embodiment can be referred to the above introduction and will not be repeated hereinafter. On this basis, please refer to Figure 3 , Figure 3 which is a schematic flowchart of the second embodiment of the network pressure test method for the vehicle-mounted controller of the present application. The steps S30 of the network pressure test method for the vehicle-mounted controller include steps S31 to S35:

[0154] Step S31, obtaining the configuration requirements of the target test case;

[0155] It should be noted that the configuration requirements refer to the specific parameters and conditions that the host computer needs to collect and set to ensure that the test cases can be correctly executed and achieve the expected test objectives. These configuration requirements generally include, but are not limited to, the following aspects: (1) Message parameters: including the ID of the message, data length code (DLC), priority, and message period, etc. These parameters determine the attributes of the message and its transmission behavior in the network. (2) Test environment settings: may include network topology, the number of nodes in the network, and other environmental factors that may affect the test results. (3) Test conditions: such as the duration of the test, the sending frequency of the message, and the network load rate that needs to be simulated in specific test cases. (4) Simulation of abnormal situations: the abnormal network environment that needs to be simulated in the test cases, such as the type of error frame, the handling method of identifier conflicts, etc. (5) Compatibility requirements: For compatibility tests of special message types such as data field length and extended frames, the specific requirements of the test need to be clarified. (6) Performance indicators: The performance indicators that need to be monitored during the test, such as response time, processing capacity, stability, etc. (7) Test scripts and tools: The configuration of software scripts, tools, or hardware devices required to execute the test cases.

[0156] It can be understood that, first, the host computer determines the configuration requirements of the test cases by analyzing the technical specifications of the controller under test and the expected network communication conditions. This includes setting specific CAN message parameters for each test case, such as ID, DLC, priority, and period, to simulate the actual network communication scenario. Secondly, the host computer configures the specific parameters of the test environment, such as network topology, number of nodes, and test duration. The setting of these parameters is to ensure that the test environment can simulate the real-world network conditions as much as possible. Then, the host computer details the simulation conditions of abnormal situations, including error frame types, identifier conflicts, etc., and the specific requirements of compatibility tests. These settings help to evaluate the stability and error handling ability of the controller under abnormal network conditions. Next, the host computer determines the monitoring parameters of performance indicators, such as response time and processing capacity. These parameters are crucial for evaluating the performance of the controller. Finally, the host computer prepares and configures the test scripts and tools to ensure that all hardware devices and software tools are accurately set according to the test requirements. Doing so can ensure that the test cases can comprehensively cover various network stress conditions that the controller under test may encounter, thereby providing detailed test data to help engineers accurately evaluate the performance and stability of the controller and providing solid data support for the further development and optimization of the product.

[0157] Step S32, configure the parameters of the controller area network data conversion device according to the configuration requirements;

[0158] It should be noted that the parameters refer to the specific working parameters that need to be set to ensure that the Controller Area Network (CAN) data conversion device can communicate correctly with the device under test (EUT) and perform network stress tests. These parameters typically include: (1) Baud rate setting: Configure the communication rate between the CAN data conversion device and the EUT to ensure that the data transmission speed matches the communication requirements of the EUT. (2) Filter configuration: Set the receive and transmit filters of the CAN data conversion device to correctly identify and process the CAN messages required in the test. (3) Termination resistor: Configure the termination resistor of the CAN bus to ensure signal integrity and reduce signal reflection. (4) Operating mode: Set the operating mode of the CAN data conversion device, such as normal mode, listening mode, or special test mode. (5) Synchronization parameters: Configure the parameters for synchronizing with the EUT, such as the send and receive times of the synchronization signal, to ensure the accuracy of the test. (6) Error handling: Set the handling method of the CAN data conversion device when encountering error frames, such as error counting and error reporting. (7) Power management: Configure the power settings of the device to ensure a stable power supply during the test. (8) Interface settings: Set the interface parameters for the connection between the CAN data conversion device and the host computer, such as USB connection settings.

[0159] It is understandable that, first of all, the host computer adjusts the baud rate parameter of the CAN data conversion device according to the configuration requirements of the test case to match the communication rate of the controller under test. This is done to ensure the synchronization and accuracy of data transmission and avoid data loss or errors caused by rate mismatch. Secondly, the host computer configures the filter parameter of the CAN data conversion device and sets specific message IDs so that the CAN data conversion device can identify and process CAN messages related to the test. This can ensure the pertinence of the test and avoid interference from irrelevant messages. Then, the host computer sets the terminal resistance parameter of the CAN data conversion device to adapt to the electrical characteristics of the CAN bus, reduce signal reflection, and improve communication quality. This helps to maintain the stability and reliability of the network. Next, the host computer selects the working mode parameter of the CAN data conversion device, such as the normal mode or the listening mode, to adapt to different test scenarios. This can flexibly meet various test requirements. In addition, the host computer synchronizes the parameters to ensure that the message sending and receiving during the test match the expected behavior of the EUT. This is done to simulate a real network environment and improve the practical significance of the test. The host computer also configures error handling parameters, such as error counting and error reporting, to correctly identify and record error frames during the test. This helps to evaluate the error handling ability of the EUT. At the same time, the host computer manages the power supply parameter of the CAN data conversion device to ensure the stable operation of the CAN data conversion device during the test and avoid affecting the test results due to power problems. Finally, the host computer sets the interface parameter of the CAN data conversion device, such as the USB connection, to ensure the stable and reliable data transmission between the host computer and the CAN data conversion device. This can ensure the integrity of the test data and the continuity of the test process. Through these detailed configuration steps, the host computer can ensure that the CAN data conversion device accurately simulates the network environment in the network stress test, effectively communicates with the EUT, and thus realizes the accurate evaluation of the performance of the EUT.

[0160] Step S33, when the parameter configuration is completed, perform a network stress test on the controller under test through the target test case;

[0161] It can be understood that the host computer uses these configured parameters to send designed CAN messages to the controller under test through the CAN data conversion device. These messages may include messages with different priorities, periods, and data lengths according to the requirements of the target test cases to simulate different network loads and communication conditions. The host computer simultaneously monitors the response of the EUT, records the efficiency of its message processing, the stability of the system, and its performance under high load or abnormal network environments. In addition, the host computer also pays special attention to the performance of the EUT under test conditions such as abnormal data field length, extended frame, influence of error frame, and identifier conflict. Through such network stress testing, the host computer can collect key performance data of the EUT under various network stress conditions, including response time, error rate, bus load rate, etc. These data are crucial for evaluating the reliability and stability of the EUT. Doing so can ensure that the EUT can operate stably under various network conditions and provide guarantee for the quality and performance of the automotive electronic control system.

[0162] As an example, the step of performing network stress testing on the controller under test through the target test case when the parameter configuration is completed includes: when the parameter configuration is completed and the target test case is a high-priority - small-period message impact test case, simulating and sending a first preset message to the port of the network segment under test of the controller under test through the controller area network data conversion device and lasting for a first preset duration; when there is a conflict between the identifier of the currently sent first preset message and the in-vehicle message, skipping the currently sent first preset message; when the bus load rate is less than the preset average load rate threshold, continuing to simulate and send the first preset message until the controller under test resets or an error frame appears; when the bus load rate is greater than or equal to the preset average load rate threshold or the number of sent first preset messages is greater than the preset message number, stopping the simulation of sending the first preset message and monitoring the status of all network segments of the controller under test for a second preset duration to complete the network stress testing.

[0163] The ports of the network segment to be tested refer to the CAN interfaces on the controller under test (EUT) used to connect to the CAN data conversion device, usually the CAN_H (high level) and CAN_L (low level) ports. Analog transmission refers to the process in which the host computer generates and sends CAN messages to the EUT through the CAN data conversion device, and these messages are used to test the performance of the EUT under different network conditions. The first preset message (Table 2 Msg1) refers to the CAN message predefined by the host computer with specific attributes (such as ID, DLC, period, etc.) in the test case of high-priority - small-period message impact, and is used to simulate high-priority communication requirements. The first preset duration refers to the duration for which the host computer analogously sends the first preset message, for example, 5 seconds. The identifier refers to the field in the CAN message used to uniquely identify the message, usually an 11-bit or 29-bit number, and is used to distinguish different types of messages. The in-vehicle message refers to the CAN message sent by the vehicle's ECU or other devices during actual vehicle operation. The preset average load rate threshold (BUSLOAD) refers to the maximum average load rate that the CAN network can withstand as specified in the EUT design. Exceeding this threshold may affect network performance. Reset refers to the situation in the CAN network where when the ECU detects more than a certain number of errors, it will enter a safe state, stop sending and receiving messages until the system is restarted or the errors are cleared. An error frame refers to a message with incorrect message format or data error due to various reasons (such as electrical interference, software error, etc.) during CAN communication. The transmission quantity refers to the number of messages actually sent by the host computer during the test. The preset message quantity refers to the upper limit of the number of messages to be sent preset in the test case, for example, 150 messages. The network segment status refers to the network communication status of the EUT during the test, including whether it is reset, whether error frames are generated, and whether the message sending period is normal. The second preset duration refers to the duration for which the host computer continues to monitor all network segment statuses of the EUT after stopping sending messages in the final stage of the test, for example, 1 minute.

[0164] After the parameter configuration is completed, the host computer first sends a predefined first preset message to the port of the network segment under test of the equipment under test (EUT) through a Controller Area Network (CAN) data conversion device according to the requirements of the high-priority - small-cycle message impact test case. This process lasts for a first preset duration, i.e., 5 seconds. If a conflict is found between the identifier of the current message and the identifier in the in-vehicle message during the simulated sending process, the host computer will automatically skip this message to avoid affecting the normal communication of the in-vehicle network. When the bus load rate is lower than the preset average load rate threshold (BUSLOAD), the host computer will continue to send the first preset message until the EUT resets or an error frame is detected, indicating that the performance of the EUT under high load has been affected. When the bus load rate reaches or exceeds the preset BUSLOAD, or the number of sent messages reaches the preset upper limit (150 messages), the host computer will stop sending the first preset message and start monitoring all network segment states of the EUT, including whether a reset occurs, whether an error frame is generated, and whether the message sending cycle is normal. This process lasts for a second preset duration, i.e., 1 minute. Through such a test, the host computer can evaluate the network pressure tolerance of the EUT under the influence of high-priority small-cycle messages, ensuring its stability and reliability in actual applications.

[0165] As an example, the step of performing a network pressure test on the EUT through the target test case when the parameter configuration is completed includes: when the parameter configuration is completed and the target test case is a standard frame identifier traversal test case, comparing the second preset message with the message data in the Controller Area Network database file to obtain a comparison result; when the comparison result is that there is an identical message or the second preset message is a network management message, skipping the currently sent second preset message; when the comparison result is that there is no identical message, simulating and sending the second preset message to the port of the network segment under test of the EUT through the Controller Area Network data conversion device every third preset duration and monitoring all network segment states of the EUT for a fourth preset duration to complete the network pressure test.

[0166] The second preset message (Table 20 Msg1) refers to a CAN message with specific attributes (such as ID, DLC, period, etc.) predefined by the host computer in the standard frame identifier traversal test case, which is used to test the response of the EUT to all possible standard frame identifiers. The Controller Area Network database file (.dbc file) is a database file that contains detailed descriptions of all messages in the CAN network, including information such as the ID, DLC, and data fields of the messages. In the test, this file is used to compare and verify the correctness of the message to be sent, whether it is a received / transmitted message defined by the EUT. Message data refers to the specific information contained in the CAN message, such as the content of the data field, which is used to transmit information between ECUs in the CAN network. The comparison result refers to the result of comparing the second preset message with the message data in the.dbc file, which is used to determine whether the preset message matches the message in the database or whether it is a network management message. Network management messages refer to messages used for network management in the CAN network, such as for network node synchronization, error handling, etc. These messages usually do not participate in regular data transmission. The third preset duration refers to the time interval at which the host computer simulates sending the second preset message when the comparison result shows that there is no identical message, for example, sending once every 10 milliseconds. The fourth preset duration refers to the duration for which the host computer monitors the status of all network segments of the device under test (EUT) after simulating the sending of the second preset message, for example, lasting for 1 minute.

[0167] After the parameter configuration is completed, the host computer first prepares the second preset message for the standard frame identifier traversal test case, which is a CAN message with a specific identifier and data length. Then, the host computer compares this message with the message data in the Controller Area Network database file (.dbc file) to determine whether the message already exists in the database (indicating a received / transmitted message defined by the EUT) or whether it is a network management message. If the comparison result shows that the message already exists or is a network management message, the host computer will skip sending this message to avoid unnecessary network interference or conflicts. If the comparison result indicates that the message does not exist in the database, the host computer will, according to the test requirements, simulate sending this second preset message to the port of the network segment under test of the device under test (EUT) through the CAN data conversion device every third preset duration (for example, 10 milliseconds). While sending the message, the host computer continuously monitors the status of all network segments of the EUT, including whether there are resets, error frames generated, and whether the message sending period is normal. This process lasts for the fourth preset duration (for example, 1 minute). Through such a test, the host computer can evaluate the performance of the EUT in the standard frame identifier traversal test, ensuring that the EUT can correctly respond to all possible standard frame identifiers, thereby verifying its compatibility and stability in the actual vehicle network environment.

[0168] As an example, the step of performing a network stress test on the to-be-tested controller by using the target test case after the parameter configuration is completed includes: when the parameter configuration is completed and the target test case is an error frame impact test case, at every interval of a fifth preset duration and / or a sixth preset duration and / or a seventh preset duration, the controller area network (CAN) data conversion device is used to simulate sending a first preset number of error frames to the to-be-tested network segment port of the to-be-tested controller, where the fifth preset duration is greater than the sixth preset duration, and the sixth preset duration is greater than the seventh preset duration; the error frames are sent repeatedly for a second preset number of times to complete the network stress test.

[0169] The fifth preset duration refers to the time interval for the host computer to simulate sending error frames in the error frame impact test case, such as 1000 milliseconds (1 second). The sixth preset duration refers to another time interval, which is shorter than the fifth preset duration, such as 100 milliseconds, for simulating more frequent sending of error frames. The seventh preset duration refers to the shortest time interval, such as 10 milliseconds, for simulating very frequent sending of error frames. The first preset number refers to the number of error frames that the host computer simulates sending in each time interval, such as 6 error frames. An error frame refers to a message with an incorrect message format or data error due to various reasons (such as electrical interference, software error, etc.) in CAN communication. In the test, the host computer simulates these error frames to test the error handling ability of the EUT. The second preset number refers to the total number of times the host computer repeats sending the error frames, such as 60 times, to ensure a full test of the performance of the EUT under the continuous impact of error frames.

[0170] After the parameter configuration is completed, for the error frame impact test case, the host computer will use the controller area network (CAN) data conversion device to simulate sending error frames to the to-be-tested network segment port of the to-be-tested controller (EUT) to test the response and handling ability of the EUT to error frames. The host computer will send a first preset number of error frames, such as 6 error frames, at preset time intervals, namely the fifth preset duration, the sixth preset duration, or the seventh preset duration. The selection of these time intervals is to simulate different frequencies of error frame occurrences. Among them, the fifth preset duration is the longest, used to simulate less frequent error frames, while the seventh preset duration is the shortest, used to simulate high-frequency error frames. The host computer will repeat this process a second preset number of times, such as 60 times, to ensure the comprehensiveness and sufficiency of the test. Through this repeated test, the host computer can evaluate the performance of the EUT under continuous reception of error frames, including the effectiveness of its error handling mechanism and the stability of the system. Such a test helps ensure that the EUT can operate normally when encountering communication errors in the actual vehicle network environment, thereby improving the reliability and safety of the automotive electronic control system.

[0171] As an example, the step of performing a network stress test on the to-be-tested controller by using the target test case after the parameter configuration is completed includes: when the parameter configuration is completed and the target test case is an identifier conflict test case, simulating and sending a third preset message to the to-be-tested network segment port of the to-be-tested controller through the controller area network data conversion device, and lasting for an eighth preset duration. The message attributes of the third preset message are the same, and the message attributes include a message period and a data field length; adjusting the message period and / or the data field length, and repeating the step of simulating and sending the third preset message to the to-be-tested network segment port of the to-be-tested controller through the controller area network data conversion device and lasting for the eighth preset duration to complete the network stress test.

[0172] The third preset message refers to a CAN message with specific attributes predefined by the host computer in an identifier conflict test case, which is used to simulate the situation of conflicting with the message sent by the EUT. For example, the third preset message may be a message with a specific ID, DLC, and data value. The eighth preset duration refers to the duration for which the host computer simulates and sends the third preset message, such as 1 minute. The message attributes refer to a series of characteristics in the CAN message, including but not limited to the message period, data field length, data value, etc. These attributes define the structure and transmission behavior of the message. The message period refers to the time interval at which the CAN message is repeatedly sent in the network, which determines the transmission frequency of the message. The data field length refers to the length of the data field in the CAN message, in bytes, which represents the amount of data that can be carried in the message.

[0173] After the parameter configuration is completed, for the identifier conflict test case, the host computer first simulates and sends a third preset message to the to-be-tested network segment port of the to-be-tested controller through the controller area network data conversion device. These messages have the same attributes, such as period, data field length, and data value, to simulate the situation of identifier conflict. This sending process lasts for the eighth preset duration, such as 1 minute, to evaluate the performance of the EUT under continuous conflict conditions. Then, the host computer adjusts some attributes of the third preset message, such as shortening or lengthening the message period, or changing the data field length, and then repeats sending these adjusted third preset messages and lasts for the eighth preset duration, which is used to further test the stability and error handling ability of the EUT under different identifier conflict conditions. Through this repeated test, the host computer can comprehensively evaluate the performance of the EUT when encountering identifier conflicts in the actual vehicle network environment, ensure that it can correctly handle conflicts and maintain the stability of network communication. Such a test helps to improve the reliability and safety of the automotive electronic control system.

[0174] Step S34, during the test, capture all Controller Area Network (CAN) messages, and record all the segment statuses of the DUT controller and the bus load rate of each segment of the DUT controller.

[0175] It should be noted that Controller Area Network (CAN) messages refer to the data units transmitted in the CAN network. They contain information such as identifier (ID), data length code, data field, and checksum. CAN messages are used to transfer information between the electronic control units of a vehicle, such as sensor data, control commands, etc. In the CAN network, a segment usually refers to a branch or part of the network. Each segment can contain one or more ECUs. During the test, the host computer needs to monitor all the segments connected to the DUT controller to evaluate the performance of the entire network. The bus load rate is an indicator that measures the data transmission density in the CAN network. It represents the ratio of the data volume transmitted on the network within a certain period of time to the total network capacity. A high bus load rate may mean that the network is approaching the limit of its processing capacity, which may affect the stability of the network and the reliability of data transmission.

[0176] It can be understood that, first, the host computer captures and records in real time all CAN messages transmitted through the CAN data conversion device during the test. These messages contain the communication data of the DUT controller under different test conditions, such as message ID, DLC, and data values, etc. This is done to collect the communication behavior and performance data of the EUT under network stress. Second, the host computer monitors and records the status of all segments of the EUT, including whether error frames are generated, whether abnormal situations such as resets occur, etc. These status information is crucial for evaluating the stability and error handling ability of the EUT. Then, the host computer calculates and records the bus load rate of each segment. This indicator reflects the data transmission density in the network and helps to evaluate the performance of the network under high load conditions.

[0177] Step S35, obtain the test result based on the Controller Area Network (CAN) messages, the segment status, and the bus load rate.

[0178] It is understandable that, first, the host computer conducts a detailed analysis of the captured CAN message records, checking the transmission frequency, content integrity of the messages, and whether there are error frames. These data help to evaluate the data transmission accuracy and stability of the controller under test under network stress. Secondly, the host computer evaluates the reliability of the EUT during the test based on the recorded network segment status, especially paying attention to whether there are abnormal events such as resets or error frames. This information is crucial for judging the stability of the EUT under stress conditions. Then, the host computer analyzes the bus load rate data to determine the network load during the test and whether the EUT can maintain normal network communication at different load rates. Finally, the host computer synthesizes these analysis results to obtain the test results, which include the overall performance of the EUT in the network stress test, such as stability and error handling ability under high load or abnormal network environments. Through such comprehensive analysis, the host computer can provide a comprehensive evaluation of the EUT's network performance, providing data support for further product development and optimization.

[0179] In this embodiment, the configuration requirements of the target test case are obtained; the parameters of the controller area network (CAN) data conversion device are configured according to the configuration requirements; when the parameter configuration is completed, the network stress test is performed on the to-be-tested controller through the target test case; during the test, all CAN messages are captured, and all network segment states of the to-be-tested controller and the bus load rate of each network segment of the to-be-tested controller are recorded; the test result is obtained based on the CAN messages, the network segment states, and the bus load rate. First, the host computer determines the configuration requirements of the test case by analyzing the technical specifications of the to-be-tested controller and the expected network communication conditions, which includes setting specific CAN message parameters for each test case, such as ID, DLC, priority, and period, etc., to ensure that the test case can accurately simulate the actual network environment and the expected test conditions. Next, the host computer sets the parameters of the CAN data conversion device according to these configuration requirements, such as baud rate, filter settings, termination resistors, etc., to match the requirements of the test case, so that the CAN data conversion device can correctly communicate with the EUT and provide a stable hardware environment for the test. Then, after the parameter configuration is completed, the host computer uses the configured CAN data conversion device to send specific CAN messages according to the target test case, apply network stress to the EUT, test the performance of the EUT under different network stress conditions, and evaluate its stability and reliability. During the test, the host computer monitors and records all CAN messages during the test process, as well as the network segment states and bus load rates of the EUT, collects comprehensive test data, and provides detailed information for analyzing the performance of the EUT. Finally, the host computer analyzes the captured message data, network segment states, and bus load rates, evaluates the performance of the EUT under the test conditions, and obtains the specific performance indicators of the EUT in the network stress test, such as error rate, response time, stability, etc., to provide a basis for product optimization and quality assurance. Through this series of steps, the host computer can comprehensively evaluate the performance of the EUT under various network stress conditions and ensure its reliability and stability in actual vehicle operation.

[0180] This application also provides a network stress test device for a vehicle-mounted controller. Please refer to Figure 4 , the network stress test device for the vehicle-mounted controller includes:

[0181] A requirement acquisition module 10, configured to acquire the network stress test requirements of the vehicle-mounted controller;

[0182] A test case determination module 20, configured to determine a target test case according to the network stress test requirements;

[0183] A network stress test module 30, configured to perform a network stress test on the to-be-tested controller through the target test case to obtain a test result;

[0184] The report generation module 40 is configured to generate a test report based on the test process record and the test result.

[0185] In one embodiment, the network stress test module 30 is further configured to obtain the configuration requirements of the target test case; configure the parameters of the controller area network data conversion device according to the configuration requirements; when the parameter configuration is completed, perform a network stress test on the to-be-tested controller through the target test case; during the test process, capture all controller area network messages, and record all network segment states of the to-be-tested controller and the bus load rate of each network segment of the to-be-tested controller; obtain a test result according to the controller area network messages, the network segment states, and the bus load rate.

[0186] In one embodiment, when the parameter configuration is completed and the target test case is a high-priority - small-cycle message impact test case, the network stress test module 30 is further configured to simulate and send a first preset message to the to-be-tested network segment port of the to-be-tested controller through the controller area network data conversion device, and continue for a first preset duration; when there is a conflict between the identifier of the currently sent first preset message and the in-vehicle message, skip the currently sent first preset message; when the bus load rate is less than the preset average load rate threshold, continue to simulate and send the first preset message until the to-be-tested controller resets or an error frame appears; when the bus load rate is greater than or equal to the preset average load rate threshold or the number of sent first preset messages is greater than the preset message number, stop simulating and sending the first preset message, and monitor all network segment states of the to-be-tested controller for a second preset duration to complete the network stress test.

[0187] In one embodiment, when the parameter configuration is completed and the target test case is a standard frame identifier traversal test case, the network stress test module 30 is further configured to compare a second preset message with the message data in the controller area network database file to obtain a comparison result; when the comparison result is that there is an identical message or the second preset message is a network management message, skip the currently sent second preset message; when the comparison result is that there is no identical message, simulate and send the second preset message to the to-be-tested network segment port of the to-be-tested controller through the controller area network data conversion device every third preset duration, and monitor all network segment states of the to-be-tested controller for a fourth preset duration to complete the network stress test.

[0188] In one embodiment, the network stress testing module 30 is also used to simulate sending a first preset number of error frames to the tested network segment port of the controller under test through the controller LAN data conversion device at every fifth preset time length and / or sixth preset time length when the parameter configuration is completed and the target test case is a test case affected by an error frame, the fifth preset time length is greater than the sixth preset time length, and the sixth preset time length is greater than the seventh preset time length; repeatedly sending the error frames a second preset number of times to complete the network stress test.

[0189] In one embodiment, the network stress testing module 30 is also used to simulate sending a third preset message to the network segment port to be tested of the controller to be tested through the controller local area network data conversion device when the parameter configuration is completed and the target test case is an identifier conflict test case, and the message attributes of the third preset message are the same, and the message attributes include a message period and a data field length; adjust the message period and / or the data field length, repeat the step of simulating sending the third preset message to the network segment port to be tested of the controller to be tested through the controller local area network data conversion device, and continuing the eighth preset time, to complete the network stress test.

[0190] In one embodiment, the test case determination module 20 is also used to, when the network stress test requirement is to test the performance of the controller to be tested under the design limit of the network load rate, use high priority-small period message impact test cases, low priority-large period message impact test cases, high priority-large period message impact test cases, low priority-small period message impact test cases and full network segment load impact test cases as target test cases; when the network stress test requirement is to test the performance of the controller to be tested without being affected by the abnormal network environment, use message compatibility test cases with a data field length of a first preset length, message compatibility test cases with a data field length greater than a second preset length, extended frame message compatibility test cases, error frame impact test cases, identifier conflict test cases, standard frame identifier traversal test cases, diagnostic identifier traversal test cases and on-board diagnostic function addressing impact test cases as target test cases, and the first preset length is less than or equal to the second preset length; when the network stress test requirement is to simulate the performance of the controller to be tested in a real vehicle network environment, use the whole vehicle message playback stress test case as the target test case.

[0191] The network pressure test device for a vehicle-mounted controller provided by this application adopts the network pressure test method for a vehicle-mounted controller in the above embodiment, and can solve the technical problem of how to accurately test and evaluate the performance and stability of a vehicle-mounted controller under different network load conditions. Compared with the prior art, the beneficial effects of the network pressure test device for a vehicle-mounted controller provided by this application are the same as those of the network pressure test method for a vehicle-mounted controller provided by the above embodiment, and other technical features in the network pressure test device for a vehicle-mounted controller are the same as those disclosed in the above embodiment method, which will not be elaborated here.

[0192] This application provides a network pressure test device for a vehicle-mounted controller. The network pressure test device for a vehicle-mounted controller includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein, the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the network pressure test method for a vehicle-mounted controller in the first embodiment above.

[0193] Refer to the following Figure 5 , which shows a schematic structural diagram of a network pressure test device for a vehicle-mounted controller suitable for implementing the embodiments of this application. The network pressure test device for a vehicle-mounted controller in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions: tablet computers), PMPs (Portable Media Players), vehicle-mounted terminals (such as vehicle-mounted navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 5 The network pressure test device for a vehicle-mounted controller shown is only an example and should not impose any limitation on the functions and usage scope of the embodiments of this application.

[0194] As shown in Figure 5As shown, the network pressure testing device of the vehicle-mounted controller may include a processing device 1001 (such as a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to the program stored in the read-only memory (ROM: Read Only Memory) 1002 or the program loaded from the storage device 1003 into the random access memory (RAM: Random Access Memory) 1004. In the RAM 1004, various programs and data required for the operation of the network pressure testing device of the vehicle-mounted controller are also stored. The processing device 1001, the ROM 1002, and the RAM 1004 are connected to each other through a bus 1005. The input / output (I / O) interface 1006 is also connected to the bus. Generally, the following systems may be connected to the I / O interface 1006: an input device 1007 including, for example, a touch screen, a touchpad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; an output device 1008 including, for example, a liquid crystal display (LCD: Liquid Crystal Display), a speaker, a vibrator, etc.; a storage device 1003 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 1009. The communication device 1009 can allow the network pressure testing device of the vehicle-mounted controller to communicate with other devices wirelessly or wiredly to exchange data. Although the figure shows a network pressure testing device of the vehicle-mounted controller with various systems, it should be understood that it is not required to implement or have all the shown systems. More or fewer systems may be implemented or had alternatively.

[0195] In particular, according to the embodiments disclosed in the present application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, the embodiments disclosed in the present application include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program contains program codes for executing the methods shown in the flowcharts. In such an embodiment, the computer program can be downloaded and installed from the network through the communication device, or installed from the storage device 1003, or installed from the ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the methods of the embodiments disclosed in the present application are executed.

[0196] The network pressure testing device of the vehicle-mounted controller provided by the present application adopts the network pressure testing method of the vehicle-mounted controller in the above-mentioned embodiment, and can solve the technical problem of how to accurately test and evaluate the performance and stability of the vehicle-mounted controller under different network load conditions. Compared with the prior art, the beneficial effects of the network pressure testing device of the vehicle-mounted controller provided by the present application are the same as those of the network pressure testing method of the vehicle-mounted controller provided by the above-mentioned embodiment, and other technical features in the network pressure testing device of the vehicle-mounted controller are the same as those disclosed in the method of the previous embodiment, and will not be elaborated here.

[0197] The present application provides a computer-readable storage medium having computer-readable program instructions (i.e., computer programs) stored thereon, and the computer-readable program instructions are used to execute the network pressure testing method of the vehicle-mounted controller in the above embodiments.

[0198] The computer-readable storage medium provided by the present application may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or components, or any combination of the above. More specific examples of the computer-readable storage medium may include, but are not limited to: electrical connections with one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM) or flash memory, optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the above. In this embodiment, the computer-readable storage medium may be any tangible medium that contains or stores a program, and the program can be used by or in conjunction with an instruction execution system, device, or component. The program code contained on the computer-readable storage medium can be transmitted by any appropriate medium, including but not limited to: wires, optical cables, RF (radio frequency), etc., or any suitable combination of the above. The above computer-readable storage medium may be included in the network pressure testing device of the vehicle-mounted controller; it may also exist separately and not be assembled into the network pressure testing device of the vehicle-mounted controller.

[0199] The above computer-readable storage medium carries one or more programs. When the one or more programs are executed by the network pressure testing device of the vehicle-mounted controller, the network pressure testing device of the vehicle-mounted controller is caused to: obtain the network pressure testing requirements of the vehicle-mounted controller; determine the target test case according to the network pressure testing requirements; perform network pressure testing on the to-be-tested controller through the target test case to obtain a test result; and generate a test report according to the test process record and the test result.

[0200] Computer program code for performing the operations of this application can be written in one or more programming languages or combinations thereof. The above-mentioned programming languages include object-oriented programming languages such as Java, Smalltalk, C++, and also include conventional procedural programming languages such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, executed as an independent software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer can be connected to the user's computer through any kind of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computer (for example, by using an Internet service provider to connect through the Internet).

[0201] The flowcharts and block diagrams in the accompanying drawings illustrate the possible architectures, functions, and operations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each box in the flowchart or block diagram may represent a module, a program segment, or a part of code that contains one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the boxes may occur in a different order than that marked in the accompanying drawings. For example, two consecutive boxes shown may actually be executed substantially in parallel, and they may sometimes be executed in the reverse order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flowchart, as well as the combination of boxes in the block diagram and / or flowchart, can be implemented by a dedicated hardware-based system that performs the specified function or operation, or can be implemented by a combination of dedicated hardware and computer instructions.

[0202] The readable storage medium provided by this application is a computer-readable storage medium. The computer-readable storage medium stores computer-readable program instructions (i.e., computer programs) for performing the above-mentioned network pressure test method of the vehicle-mounted controller, and can solve the technical problem of how to accurately test and evaluate the performance and stability of the vehicle-mounted controller under different network load conditions. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided by this application are the same as those of the network pressure test method of the vehicle-mounted controller provided by the above embodiments, and will not be elaborated here.

[0203] The present application also provides a computer program product, including a computer program which, when executed by a processor, implements the steps of the network stress test method for the vehicle-mounted controller as described above. The computer program product provided by the present application can solve the technical problem of how to accurately test and evaluate the performance and stability of the vehicle-mounted controller under different network load conditions. Compared with the prior art, the beneficial effects of the computer program product provided by the present application are the same as those of the network stress test method for the vehicle-mounted controller provided by the above embodiments, and will not be elaborated herein. The above are only partial embodiments of the present application, and thus do not limit the patent scope of the present application. Any equivalent structural transformation made by using the content of the specification and drawings of the present application under the technical concept of the present application, or any direct / indirect application in other related technical fields, is included in the patent protection scope of the present application.

Claims

1. A network pressure testing method for a vehicle-mounted controller, characterized in that, The method is applied to a host computer, which is connected to a Controller Area Network (CAN) data conversion device through a Universal Serial Bus (USB). The CAN data conversion device is connected to a controller under test through a CAN bus. The method includes: Obtain the network pressure test requirements of the vehicle-mounted controller; Determine the target test case according to the network pressure test requirements; Conduct a network pressure test on the controller under test through the target test case to obtain a test result; Generate a test report based on the test process record and the test result.

2. The method according to claim 1, characterized in that The step of conducting a network pressure test on the controller under test through the target test case to obtain a test result includes: Obtain the configuration requirements of the target test case; Configure the parameters of the CAN data conversion device according to the configuration requirements; When the parameter configuration is completed, conduct a network pressure test on the controller under test through the target test case; During the test process, capture all CAN messages, and record all segment states of the controller under test and the bus load rate of each segment of the controller under test; Obtain the test result according to the CAN messages, the segment states, and the bus load rate.

3. The method according to claim 2, wherein The step of conducting a network pressure test on the controller under test through the target test case when the parameter configuration is completed includes: When the parameter configuration is completed and the target test case is a high-priority - small-cycle message impact test case, simulate sending a first preset message to the port of the segment under test of the controller under test through the CAN data conversion device and continue for a first preset duration; When there is a conflict between the identifier of the currently sent first preset message and the in-vehicle message, skip the currently sent first preset message; When the bus load rate is less than the preset average load rate threshold, continue to simulate sending the first preset message until the controller under test resets or an error frame appears; When the bus load rate is greater than or equal to the preset average load rate threshold or the number of sent first preset messages is greater than the preset message number, stop simulating sending the first preset message, and monitor all segment states of the controller under test for a second preset duration to complete the network pressure test.

4. The method according to claim 2, wherein The step of conducting a network pressure test on the controller under test through the target test case when the parameter configuration is completed includes: When the parameter configuration is completed and the target test case is a standard frame identifier traversal test case, compare the second preset message with the message data in the CAN database file to obtain a comparison result; When the comparison result is that there is an identical message or the second preset message is a network management message, skip the currently sent second preset message; When the comparison result is that there is no identical message, the second preset message is simulated to be sent to the tested network segment port of the controller under test through the controller LAN data conversion device every third preset time period, and the status of all network segments of the controller under test is monitored for a fourth preset time period to complete the network stress test.

5. The method according to claim 2, characterized in that, When the parameter configuration is completed, the step of performing a network stress test on the controller to be tested through the target test case includes: When the parameter configuration is completed and the target test case is a test case affected by an error frame, at intervals of the fifth preset time length and / or the sixth preset time length and / or the seventh preset time length, a first preset number of error frames are simulated and sent to the tested network segment port of the tested controller through the controller local area network data conversion device, the fifth preset time length is greater than the sixth preset time length, and the sixth preset time length is greater than the seventh preset time length; Repeat sending the error frame a second preset number of times to complete the network stress test.

6. The method according to claim 2, wherein When the parameter configuration is completed, the step of performing a network stress test on the controller to be tested through the target test case includes: When the parameter configuration is completed and the target test case is an identifier conflict test case, a third preset message is simulated and sent to the tested network segment port of the tested controller through the controller local area network data conversion device for an eighth preset time, and the message attributes of the third preset message are the same, and the message attributes include a message period and a data field length; Adjust the message period and / or the data field length, repeat the step of simulating sending the third preset message to the tested network segment port of the tested controller through the controller LAN data conversion device, and continue for an eighth preset time to complete the network stress test.

7. The method according to any one of claims 1 to 6, characterized in that, The step of determining the target test case according to the network stress test requirement includes: When the network stress test requirement is to test the performance of the controller to be tested under the design limit of the network load rate, the high priority-small cycle message impact test case, the low priority-large cycle message impact test case, the high priority-large cycle message impact test case, the low priority-small cycle message impact test case and the full network segment load impact test case are used as target test cases; When the network stress test requirement is to test the performance of the controller to be tested without being affected by an abnormal network environment, a message compatibility test case with a data field length of a first preset length, a message compatibility test case with a data field length greater than a second preset length, an extended frame message compatibility test case, an error frame impact test case, an identifier conflict test case, a standard frame identifier traversal test case, a diagnostic identifier traversal test case, and an on-board diagnostic function addressing impact test case are used as target test cases, and the first preset length is less than or equal to the second preset length; When the network stress test requirement is to simulate the performance of the controller to be tested in a real vehicle network environment, the whole vehicle message playback stress test case is used as the target test case.

8. A network pressure test device for a vehicle-mounted controller, characterized in that, The device comprises: A requirement acquisition module, configured to acquire the network pressure test requirements of the vehicle-mounted controller; A test case determination module, configured to determine target test cases according to the network pressure test requirements; A network pressure test module, configured to perform a network pressure test on the to-be-tested controller through the target test cases to obtain test results; A report generation module, configured to generate a test report according to the test process record and the test results.

9. A network pressure test device for a vehicle-mounted controller, characterized in that, The device includes: a memory, a processor, and a computer program stored on the memory and executable on the processor, where the computer program is configured to implement the steps of the network pressure test method for the vehicle-mounted controller according to any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by the processor, the steps of the network pressure test method for the vehicle-mounted controller according to any one of claims 1 to 7 are implemented.

Images