Automatic test method, device and equipment for network diagnosis fault code and storage medium

Abstract

The invention discloses an automatic test method, device and equipment for a network diagnosis fault code and a storage medium, and relates to the technical field of vehicle fault diagnosis, and the automatic test method for the network diagnosis fault code comprises the steps: obtaining a vehicle type diagnosis table; obtaining a clustered network type fault code and a controller local area network access programming language module function according to the vehicle type diagnosis table and a preset network type fault type; constructing an automatic test script according to the vehicle type diagnosis table, the clustered network type fault codes and the controller local area network access programming language module function; and performing automatic testing according to the automatic testing script, and generating a testing report. According to the method, the automation degree and efficiency of DTC network fault code testing are improved, long-time manual intervention and manual operation are not needed, the testing period is greatly shortened, the generated testing report provides clear and accurate testing information for related personnel, and problems in a system can be found and solved in time.

Description

Technical Field

[0001] The present application relates to the technical field of vehicle fault diagnosis, and in particular to an automated testing method, device, equipment and storage medium for network diagnostic fault codes. Background Art

[0002] As the degree of automobile electronics and intelligence continues to improve, the vehicle's network communication system has become more complex, and the difficulty of diagnosing network communication failures has also increased. Diagnostic trouble code (DTC) is an important part of the automobile fault diagnosis system, which can help technicians quickly locate vehicle faults. Testing of DTC network fault codes is an important part of ensuring the reliability and stability of the automobile network communication system, and is of great significance to improving the quality and safety of automobile products. Therefore, accurate and efficient testing of DTC network fault codes is an important requirement in the automobile research and development and production process.

[0003] At present, the industry's testing of DTC network fault codes mainly relies on manual operation and manual programming. The specific approach is to first adapt the parameters according to the vehicle model, and then perform CAN Access Programming Language (CAPL) programming based on the Controller Area Network Open Engineering Tool (CAN Open Engineering, CANOE) device, and connect the Controller Area Network (CAN) hardware channel corresponding to the controller under test. Then, send the DTC-associated CAN message and create the corresponding network fault, and manually build the relevant fault. In this process, it is necessary to manually set the number of fault frames or the time when the fault occurs in the message, and read the corresponding DTC code in the fault diagnosis table through the Unified Diagnostic Services (UDS) to see if it is reported, so as to realize the test of DTC network fault codes.

[0004] There are many problems with the existing practices. First, the fault construction process is complicated and cumbersome, requiring repeated adaptation of parameters according to vehicle models and a large amount of manual programming and settings, which is not only time-consuming and labor-intensive, but also prone to errors. Secondly, the lack of a clear automation solution makes it impossible to automate the test process, resulting in low testing efficiency. In addition, different models require re-adaptation of the test engineering, which cannot quickly adapt to the needs of different models. Regression testing also requires manual retesting, which further increases the test cycle and labor costs. Therefore, how to improve the automation and efficiency of DTC network fault code testing has become an urgent problem to be solved.

[0005] The above contents are only used to assist in understanding the technical solution of the present application and do not constitute an admission that the above contents are prior art. Summary of the invention

[0006] The purpose of this application is to provide an automated testing method, device, equipment and storage medium for network diagnostic fault codes, aiming to solve the technical problem of how to improve the automation level and efficiency of DTC network fault code testing.

[0007] To achieve the above objectives, the present application proposes an automated testing method for network diagnostic fault codes, the method comprising:

[0008] Get the vehicle model diagnostic table;

[0009] Obtaining clustered network fault codes and controller area network access programming language module functions according to the vehicle type diagnosis table and preset network fault types;

[0010] Constructing an automated test script according to the vehicle type diagnostic table, the clustered network fault codes and the controller area network access programming language module function;

[0011] Perform automated testing according to the automated testing script and generate a test report.

[0012] In one embodiment, the vehicle type diagnostic table includes reporting conditions of all fault codes included in the current vehicle type;

[0013] The step of obtaining clustered network fault codes and controller area network access programming language module functions according to the vehicle type diagnosis table and preset network fault types includes:

[0014] Clustering the fault codes according to the reporting conditions and the preset network fault types to obtain clustered network fault codes;

[0015] A controller area network access programming language module function is constructed according to the preset network class fault type.

[0016] In one embodiment, the step of clustering the fault codes according to the reporting conditions and the preset network fault types to obtain clustered network fault codes includes:

[0017] Performing text analysis on the reporting conditions to extract fault feature keywords;

[0018] The corresponding fault code is matched with a preset network class fault type according to the fault feature keyword to obtain a clustered network class fault code.

[0019] In one embodiment, the preset network fault types include signal value error fault and message loss fault;

[0020] The controller area network access programming language module function includes a signal value error fault module function and a message loss fault module function;

[0021] The step of constructing a controller area network access programming language module function according to the preset network fault type comprises:

[0022] Taking the message identifier, byte position and byte assignment as parameters, and constructing the signal value error fault module function with the construction logic and clearing logic of the signal value error fault;

[0023] The message loss fault module function is constructed using the message identifier and loss time as parameters and the construction logic and clearing logic of the message loss fault.

[0024] In one embodiment, the preset network fault type includes a counting bit error fault and a check bit error fault;

[0025] The controller area network access programming language module function includes a counting bit error fault module function and a check bit error fault module function;

[0026] The step of constructing a controller area network access programming language module function according to the preset network fault type comprises:

[0027] Taking the message identifier and the number of frames as parameters, and using the construction logic and clearing logic of the counting bit error fault, construct the counting bit error fault module function;

[0028] The message identifier and the frame number are used as parameters, and the check bit error fault construction logic and clearing logic are used to construct the check bit error fault module function.

[0029] In one embodiment, the step of constructing an automated test script according to the vehicle type diagnostic table, the clustered network fault codes and the controller area network access programming language module function comprises:

[0030] Generate a first code, wherein the first code is used to read fault code information of the network fault code in the vehicle type diagnostic table, and monitor the fault code status of the network fault code through a unified diagnostic service protocol;

[0031] Generate a second code, wherein the second code is used to call the controller area network access programming language module function according to the fault code information and the fault type corresponding to the clustered network fault code;

[0032] Generate a third code, the third code is used to confirm whether the fault code state meets the expected state, and perform a boundary value test to verify whether the fault code state is always fault-free before and after the triggering when the triggered fault is less than a preset fault triggering time threshold or a preset fault triggering frame number threshold, and output the test result;

[0033] The first code, the second code and the third code are integrated to form an automated test script.

[0034] In one embodiment, the step of performing automated testing according to the automated testing script and generating a test report includes:

[0035] Performing automated testing according to the automated testing script to obtain test results of whether the fault code status before, during, after, and after the fault is cleared meets the expected status;

[0036] A test report is generated according to the test results.

[0037] In addition, to achieve the above purpose, the present application also proposes an automated testing device for network diagnostic fault codes, the device comprising:

[0038] Data acquisition module, used to obtain vehicle model diagnostic table;

[0039] A clustering and function building module, used to obtain clustered network fault codes and controller area network access programming language module functions according to the vehicle type diagnosis table and preset network fault types;

[0040] A script construction module, used for constructing an automated test script according to the vehicle type diagnosis table, the clustered network fault codes and the controller area network access programming language module function;

[0041] The test module is used to perform automated testing according to the automated testing script and generate a test report.

[0042] In addition, to achieve the above-mentioned purpose, the present application also proposes an automated testing device for network diagnostic fault codes, the device comprising: 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 automated testing method for network diagnostic fault codes as described above.

[0043] In addition, to achieve the above-mentioned purpose, the present application also proposes a storage medium, which 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 automated testing method of the network diagnostic fault code as described above are implemented.

[0044] In addition, to achieve the above-mentioned purpose, the present application also provides a computer program product, which includes a computer program, and when the computer program is executed by a processor, it implements the steps of the automated testing method for network diagnostic fault codes as described above.

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

[0046] Obtain a vehicle model diagnostic table; obtain clustered network class fault codes and controller area network access programming language module functions according to the vehicle model diagnostic table and preset network class fault types; construct an automated test script according to the vehicle model diagnostic table, the clustered network class fault codes and the controller area network access programming language module functions; perform automated testing according to the automated test script and generate a test report. First, the automated test system obtains the vehicle model diagnostic table, which is the basis for realizing automated testing because it provides detailed information on all vehicle fault codes, including reporting conditions and related CAN message data. Then, the system clusters the fault codes according to the vehicle model diagnostic table and preset network class fault types (such as signal value errors, message loss, etc.), classifies fault codes with similar trigger conditions, and constructs corresponding CAPL module functions for each type of fault code, which can simulate specific network class faults. Then, using the vehicle model diagnostic table, clustered fault codes and CAPL module functions, an automated test script is constructed, which can automatically perform a series of test operations, including reading fault code status, creating and clearing faults, and recording test results. Finally, the test is performed according to the automated test script, and a detailed test report is generated. The report summarizes the test status of all fault codes, including the number of fault codes that passed and failed, the specific reason analysis of the failed fault codes, etc., to provide data support for vehicle fault diagnosis and system improvement. Through automated testing, this application can efficiently and accurately complete the testing of DTC network fault codes without long-term human intervention and manual operation, greatly shortening the test cycle and reducing labor costs. The generated test report provides clear and accurate test information for relevant personnel, which helps to promptly discover and solve problems in the system and improve the quality and reliability of the vehicle network communication system. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0048] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0049] Figure 1 A flowchart diagram of the first embodiment of the automated testing method for network diagnostic fault codes of the present application is provided;

[0050] Figure 2 A flowchart diagram of the second embodiment of the automated testing method for network diagnostic fault codes of the present application is provided;

[0051] Figure 3 A schematic diagram of the module structure of an automated testing device for network diagnostic fault codes according to an embodiment of the present application;

[0052] Figure 4 Schematic diagram of the device structure of the hardware operating environment involved in the automated testing method for network diagnostic fault codes in the embodiment of the present application.

[0053] The purpose, features and advantages of this application will be further described in conjunction with the embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0054] 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.

[0055] In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

[0056] With the development of automotive electronics and intelligence, the complexity of vehicle network communication systems has increased, making fault diagnosis more difficult. Diagnostic fault codes are crucial for quickly locating problems, especially the testing of network fault codes, which is of great significance to ensuring system stability and improving automobile quality and safety. At present, the industry mainly relies on manual operation and manual programming to test DTC network fault codes, by using CANOE devices for CAPL programming, connecting CAN hardware channels, sending specific CAN messages to simulate faults, and using UDS to read DTC results. However, this method is not only time-consuming and error-prone, but also lacks automation, making it difficult to efficiently adapt to the needs of different models, resulting in low test efficiency and increasing the cycle and cost of regression testing. Therefore, achieving accurate and efficient automated testing of DTC network fault codes has become an urgent need in automotive R&D and production.

[0057] The main solution of the embodiment of the present application is: by communicating with the automobile manufacturer database interface, automatically downloading and parsing the diagnostic table file of a specific model, extracting key DTC information (such as code, description, trigger conditions, etc.) and CAN message data, and providing accurate basis for subsequent testing. Then, the system classifies DTC according to the fault type, and uses CAPL programming to generate module functions that simulate faults, simplifying the creation process of test scripts, and improving test efficiency and accuracy. Then, use high-level programming languages ​​such as Python to build automated test scripts that integrate fault code reading, simulation, verification and other functions, to achieve continuous test operations without human intervention, and ensure the consistency and reliability of test results. Finally, the system runs these scripts, automatically executes the test process and records the results, and automatically generates a detailed test report after completion, summarizing the test conditions and overall conclusions of all fault codes. This process significantly improves the efficiency of the test preparation and execution stages, reduces the risk of manual errors, and supports the needs of rapid adaptation to different models.

[0058] It should be noted that the execution subject of the embodiment 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 capable of realizing the above functions, an automated testing system, etc. The following takes the automated testing system as an example to illustrate this embodiment and the following embodiments.

[0059] Based on this, the embodiment of the present application provides an automated testing method for network diagnostic fault codes, referring to Figure 1 , Figure 1 This is a flow chart of the first embodiment of the automated testing method for network diagnostic fault codes of the present application.

[0060] In this embodiment, the automated testing method for network diagnostic fault codes includes steps S10 to S40:

[0061] Step S10, obtaining a vehicle type diagnosis table;

[0062] It should be noted that the vehicle model diagnostic table refers to a detailed fault diagnosis information table specially compiled by the automobile manufacturer for each vehicle model. It defines in detail all the diagnostic trouble codes (DTCs) contained in the vehicle model, as well as the conditions for reporting and clearing each fault code. Specifically, the vehicle model diagnostic table includes the following contents: (1) Fault code list: Lists all possible diagnostic trouble codes (DTCs) reported by the vehicle model. Each fault code has a unique code identifier, usually composed of letters and numbers, such as P0300, C1234, etc. (2) Fault code description: Provides a detailed text description of each fault code, indicating the specific fault type or problem represented by the fault code. For example, P0300 may indicate engine misfire, C1234 may indicate abnormal sensor signal, etc. (3) Reporting conditions: Clearly define the conditions for reporting each fault code, that is, under what circumstances will the fault code be triggered and reported. This may involve a variety of situations such as specific sensor signal values, message loss, signal errors in the message, message count bit errors, message check bit errors, etc. For example, a fault code may be reported after a CAN message has been lost for a period of time, or when a signal value exceeds the normal range. (4) Release conditions: Specifies the conditions for releasing each fault code, that is, under what circumstances the fault code will be cleared. Usually, the release conditions of the fault code correspond to the reporting conditions. For example, when the lost message resumes normal transmission, or the abnormal signal value returns to the normal range, the fault code will be released. (5) Related message information: For network fault codes, the vehicle model diagnostic table will also contain CAN message information related to the fault code, such as message ID, message cycle, byte position of the signal in the message and normal value range, etc. This information is crucial for testing and diagnosing network fault codes.

[0063] It can be understood that, first, the automated test system communicates with the database interface of the automobile manufacturer, and uses pre-set query parameters, such as vehicle model, year, etc., to retrieve and download the diagnostic table file of the vehicle model from the database (or directly obtain the pre-stored vehicle model diagnostic table from the vehicle system). Secondly, the system parses the downloaded diagnostic table file and extracts the key information, including the codes, descriptions, reporting and release conditions of all DTCs, as well as the CAN message ID, cycle, signal byte bit and normal value range related to the network fault code. Finally, the system stores the extracted information in an internal data structure so that the subsequent automated test script can directly read and use this data, thereby realizing the automated testing of DTC network fault codes and improving the efficiency and accuracy of the test.

[0064] Step S20, obtaining clustered network fault codes and controller area network access programming language module functions according to the vehicle type diagnosis table and preset network fault types;

[0065] It should be noted that the preset network fault types refer to several typical fault modes that may occur in the automotive network communication system. These fault types are summarized based on the characteristics of the CAN (Controller Area Network) communication protocol and common problems in actual applications. They specifically include the following four categories: (1) Error in a signal value in a CAN message: This fault type refers to the fact that the value of a signal in a message transmitted over the CAN network does not match the normal value. The signal value error may be caused by sensor failure, interference during transmission, or other reasons. For example, the temperature signal value in a message suddenly jumps to an abnormally high value, which may trigger the relevant fault code. (2) CAN message loss: This fault type refers to the fact that a CAN message has not been sent or received normally for a period of time. The message loss may be caused by network node failure, communication line problem, or network congestion. For example, a control unit does not send the status message that it should send regularly within a certain period of time, which may cause other nodes to be unable to obtain the status information of the control unit, thereby triggering a fault code. (3) The value of the Rolling counter of the CAN message is wrong: The Rolling counter is a mechanism used to detect repeated message transmission. Its count bit increases each time a message is sent. When the value of the Rolling counter is wrong, such as repeated values ​​or value jumps, this may indicate that there is a problem with the order or frequency of message transmission, thereby triggering a fault code. (4) The value of the checksum of the CAN message is wrong: The checksum is used to detect whether there is an error in the message transmission process. When the value of the checksum of the message is wrong, it indicates that the message may have been interfered with or damaged during the transmission process, which will cause the message to be unable to be correctly parsed, thereby triggering a fault code.

[0066] Network fault codes refer to diagnostic trouble codes (DTCs) related to the vehicle network communication system. These fault codes are specifically used to indicate various fault conditions in the network communication system, such as the above-mentioned CAN message signal value error, message loss, Rolling counter count bit error, and checksum check bit error. The setting and triggering of network fault codes are to help technicians quickly locate and diagnose problems in the vehicle network communication system and ensure the reliability and stability of the network system. Network fault codes are the focus of testing. By simulating various network fault types, it is verified whether the reporting and release of these fault codes are in line with expectations.

[0067] The controller area network access programming language module function refers to a series of functional modules defined in the CAPL programming language, which is used to implement access and control of the CAN network. CAPL is a programming language specifically used for CAN network development and testing. It provides a rich function library and syntax structure, allowing developers to easily generate programs to simulate various communication behaviors and fault conditions in the CAN network. In this embodiment, the CAPL module function is constructed according to the preset network class fault type, and each fault type corresponds to one or more CAPL module functions, which can simulate the corresponding fault conditions. For example, for the fault type of a certain signal value error in the CAN message, the CAPL module function can set the assignment of a certain byte in the message, thereby realizing the construction and recovery of the fault; for the fault type of CAN message loss, the CAPL module function can set a certain message to stop sending for a period of time, thereby simulating the fault condition of message loss. By calling these CAPL module functions, the automated test system can simulate various network class faults in the CAN network, and then trigger the corresponding network class fault code, and realize the automated testing and verification of the fault code logic.

[0068] It can be understood that, first, the automated test system reads and parses the vehicle diagnostic table, extracts all DTCs and their reporting conditions, and then classifies these DTCs according to the preset network fault types (error in a certain signal value in the CAN message, loss of the CAN message, error in the value of the CAN message Rolling counter, error in the value of the CAN message checksum), and classifies DTCs with the same or similar trigger conditions into one category to form a clustered network fault code set. Then, for each type of network fault code, the system uses the CAPL programming language to generate the corresponding module function according to its trigger conditions and the characteristics of the CAN communication protocol. For example, for the fault type of a certain signal value error in the CAN message, a CAPL module function is generated, which can set the value of the signal byte bit of the specified message ID to an error value, thereby simulating the fault condition of the signal value error; for the fault type of the CAN message loss, a CAPL module function is generated, which can control the message of the specified message ID to stop sending within a certain period of time, simulating the fault condition of the message loss. In this way, the system generates corresponding CAPL module functions for each type of network fault code. These functions can be called by subsequent automated test scripts to achieve automated simulation and testing of network fault codes.

[0069] Step S30, constructing an automated test script according to the vehicle type diagnosis table, the clustered network fault codes and the controller area network access programming language module function;

[0070] It should be noted that the automated test script refers to the program code generated based on high-level programming languages ​​such as Python and used to implement automated testing of DTC network fault codes.

[0071] It can be understood that, first of all, the automated test system extracts all DTCs and their corresponding reporting conditions, relevant CAN message IDs, signal byte bits and other key information by reading and parsing the vehicle diagnostic table. This is to obtain the basic data required for the test and ensure the accuracy and completeness of subsequent tests. Secondly, the system determines the fault type corresponding to each fault code based on the extracted information and the pre-clustered network fault codes. This is done to match the fault code with the corresponding fault simulation logic and provide a basis for subsequent fault simulation. Then, according to the fault type of each fault code, the system calls the corresponding CAPL module function to simulate the fault condition. For example, for the fault type of a certain signal value error in the CAN message, the CAPL module function that sets the signal byte bit error value is called; for the fault type of the CAN message loss, the CAPL module function that controls the message to stop sending is called. In this way, the system can accurately simulate various network faults in the CAN network and provide the necessary conditions for the reporting and release of the test fault code. Finally, in the process of simulating faults, the system controls the execution order and time of the test process, including steps such as reading the DTC status before and after the fault occurs, simulating faults, and recovering from faults. It also records the test results of each DTC and generates a detailed test report. This can fully verify whether the logic of the fault code meets expectations, ensure the reliability of the vehicle network communication system and the accuracy of fault diagnosis, while improving test efficiency and reducing the possibility of human intervention and errors.

[0072] As an example, the step of constructing an automated test script based on the vehicle type diagnostic table, the clustered network fault codes and the controller local area network access programming language module function includes: generating a first code, the first code is used to read the fault code information of the network fault code in the vehicle type diagnostic table, and monitor the fault code status of the network fault code through a unified diagnostic service protocol; generating a second code, the second code is used to call the controller local area network access programming language module function according to the fault code information and the fault type corresponding to the clustered network fault code; generating a third code, the third code is used to confirm whether the fault code status meets the expected status, and perform a boundary value test to verify whether the fault code status is always fault-free before and after the triggering when the triggered fault is less than a preset fault trigger time threshold or a preset fault trigger frame number threshold, and output the test result; integrating the first code, the second code and the third code to form an automated test script.

[0073] The first code refers to the code segment in the automated test script that is responsible for reading the fault code information of the network fault code in the vehicle model diagnostic table and monitoring the status of these fault codes through the unified diagnostic service protocol. Its specific function is to obtain detailed information on the fault code, such as the fault code ID, reporting conditions, related CAN message ID, etc., and at the same time monitor the status changes of the fault code during the test in real time, providing basic data for subsequent fault manufacturing and status verification.

[0074] Fault code information refers to the detailed description and related data of each diagnostic trouble code (DTC) in the vehicle model diagnostic table, including the unique identifier of the fault code (such as P0300, C1234, etc.), the text description of the fault code (such as "engine misfire", "sensor signal abnormality", etc.), the reporting conditions (such as a signal value exceeds the normal range, a message is lost for a period of time, etc.), and the associated CAN message ID, signal byte position and other information. This information is the key basis for the automated test script to perform fault simulation and status verification.

[0075] The Unified Diagnostic Service (UDS) is an internationally standardized automotive diagnostic communication protocol that defines the communication method and diagnostic services between automotive electronic control units (ECUs) and diagnostic tools. It provides a set of unified diagnostic services and sub-functions, such as reading fault codes, clearing fault codes, reading data parameters, etc., so that diagnostic tools from different manufacturers can effectively communicate with ECUs of various models. In automated test scripts, the UDS protocol can be used to read and monitor the status of fault codes.

[0076] The fault code status refers to the reporting of the diagnostic fault code at different test stages. It includes three specific states: no fault state (fault code is not reported), current fault state (fault code is triggered and reported during the test), and historical fault state (fault code was triggered and reported, but it was cleared at the end of the test). By monitoring the fault code status, it can be verified whether the fault code reporting and clearing logic are in line with expectations.

[0077] The second code refers to the code segment in the automated test script that calls the controller area network access programming language (CAPL) module function to implement fault creation and fault clearing according to the fault code information and the fault type corresponding to the clustered network fault code. Its function is to simulate the corresponding network fault through the CAPL module function according to the triggering conditions and fault type of the fault code, such as setting signal value errors, control message loss, etc., and restore the normal communication state after the test is completed, so as to verify the reporting and release logic of the fault code.

[0078] Fault type refers to the fault mode classified according to the triggering conditions and characteristics of network fault codes. In this embodiment, network faults are mainly divided into four categories: error in a certain signal value in the CAN message, loss of the CAN message, error in the value of the CAN message rolling counter, and error in the value of the CAN message checksum. Each fault type corresponds to different fault simulation logic and CAPL module functions, which are used to accurately simulate fault conditions in automated testing.

[0079] The third code refers to the code segment in the automated test script that is used to confirm whether the fault code status is consistent with the expected status and to perform boundary value testing to verify the fault code logic. Its function is to check whether the fault code status is consistent with expectations after the fault is created and cleared, such as whether the fault code changes from a no-fault state to a current fault state when the fault is created, and whether it changes to a historical fault state or a no-fault state after the fault is cleared. At the same time, through boundary value testing, it is verified whether the fault code status is always no-fault when the triggered fault is less than the preset fault trigger time threshold or frame number threshold, so as to ensure the accuracy and robustness of the fault code logic.

[0080] The expected state refers to the state that the fault code should reach under specific test conditions. For example, in the fault manufacturing stage, the expected state is that the fault code changes from the no-fault state to the current fault state; in the fault clearing stage, the expected state is that the fault code changes to the historical fault state or the no-fault state. By comparing the actual fault code state with the expected state, it can be determined whether the fault code logic is correct.

[0081] Boundary value testing is a software testing method used to verify whether the system behaves correctly when the input or condition reaches the boundary value. In the automated test script, boundary value testing is used to verify whether the fault code status is always fault-free when the triggered fault time or number of frames is close to but less than the preset fault trigger threshold. For example, if the trigger time threshold of a fault code is 5 seconds, the boundary value test will verify whether the fault code is still not reported when the fault duration is 4 seconds.

[0082] The preset fault trigger time threshold refers to the time limit that specifies the duration of a fault before it is triggered in the fault code reporting conditions. For example, a fault code may require that the CAN message loss lasts for 5 seconds before it is reported, so 5 seconds is the preset fault trigger time threshold. In the test, the boundary value test verifies whether the fault code is not reported when the fault duration is less than 5 seconds (such as 4 seconds).

[0083] The preset fault trigger frame number threshold refers to the frame number limit that specifies the number of frames that a fault needs to occur before it is triggered in the fault code reporting conditions. For example, a fault code may require that a certain signal value in the CAN message is wrong for 10 frames before it is reported, so 10 frames is the preset fault trigger frame number threshold. In the test, the boundary value test verifies whether the fault code is not reported when the wrong signal value lasts for 9 frames.

[0084] No fault means that the fault code is not triggered or reported. In this state, the vehicle's network communication system works normally and no network faults are detected. In the test, the no fault state is the state that the fault code should maintain under normal circumstances, and it is also one of the target states verified by the boundary value test.

[0085] The test result refers to the conclusion and data on the fault code logic verification output by the automated test script after executing a series of test operations. The test result includes information such as whether the test status of each fault code meets expectations and whether the boundary value test passes. By analyzing the test results, the correctness of the fault code logic and the reliability of the system can be evaluated, providing a basis for subsequent system optimization and fault diagnosis.

[0086] First, the automated test system generates the first code based on high-level programming languages ​​such as Python. The code extracts relevant information of the network fault code from the vehicle model diagnostic table by file reading or database query, such as fault code ID, reporting conditions, related CAN message ID, etc., and stores it in the data structure inside the script, such as a dictionary or list, for subsequent use. At the same time, the first code uses the diagnostic services provided by the UDS protocol, such as the service of reading the fault code status, to communicate with the communication interface of the vehicle ECU (such as the OBD interface) to obtain the current status of the fault code in real time, such as no fault, current fault or historical fault, etc., to provide real-time data support for subsequent fault simulation and status verification. Secondly, the system generates the second code based on the fault code information obtained by the first code and the fault type corresponding to the pre-clustered network fault code. The second code passes the fault code information and fault type as parameters to the corresponding CAPL function by calling the CAPL module function, thereby simulating a specific fault condition in the CAN network. For example, for a fault type in which a signal value in a CAN message is incorrect, the second code will call the CAPL module function that sets the signal byte bit error value, and pass in parameters such as the message ID and the signal byte bit, so that the CAPL function can accurately modify the signal value in the message and simulate the fault of the signal value error. In this way, the system can accurately create various network faults during the test process, providing the necessary conditions for verifying the reporting logic of the fault code. Then, the system generates a third code, which is responsible for confirming whether the fault code state meets the expected state and performing a boundary value test. The third code first reads the state of the fault code before the fault is created, and then reads the state of the fault code again after the fault is created. By comparing the states read twice, it is determined whether the fault code is correctly reported when the fault is created and correctly released after the fault is cleared. At the same time, the third code will also perform a boundary value test, that is, when the time or frame number of the fault trigger is close to but less than the preset fault trigger threshold, the state of the fault code is read again to verify whether it is always fault-free. For example, if the trigger time threshold of a fault code is 5 seconds, the third code will read the fault code state when the fault duration is 4 seconds to ensure that it is not reported. Finally, the first code, the second code, and the third code are integrated to form a complete automated test script, so that the entire test process can be automatically and continuously executed. The integrated script can perform operations such as fault code information reading, fault simulation, state verification, and boundary value testing in sequence according to the preset test process, and output the test results, such as generating a test report or outputting log information. Doing so can greatly improve test efficiency, reduce the possibility of manual intervention and errors, ensure the accuracy and consistency of test results, and provide reliable data support for subsequent system optimization and fault diagnosis.

[0087] Step S40: Perform automated testing according to the automated testing script and generate a test report.

[0088] It should be noted that automated testing refers to the use of previously constructed automated test scripts to automatically execute a series of preset test operations to verify whether the functions and logic of the DTC network fault code meet expectations. Specifically, the automated testing process includes the following key steps: (1) Script execution: The automated test system loads and executes the automated test script. The script will call the first code, the second code, and the third code in sequence according to the established logical order, and the entire test process can be completed without human intervention. (1) Fault code information reading and status monitoring: The automated test system reads the network fault code information in the vehicle model diagnostic table through the first code in the script, and monitors the status of the fault code in real time through the UDS protocol. This step ensures that the test script can obtain accurate fault code data and real-time status, laying the foundation for subsequent fault simulation and status verification. (2) Fault simulation: The automated test system uses the script to call the CAPL module function to simulate various network faults according to the fault code information and fault type. For example, by setting signal value errors, control message loss, etc., the fault scenario can be reproduced in the CAN network. This step is a key link in verifying the fault code reporting logic. By simulating the real fault situation, the fault code can be accurately triggered. (3) Status verification and boundary value testing: The automated test system uses the third code in the script to confirm whether the fault code status meets the expected status and performs boundary value testing. It will read the status of the fault code before and after the fault is created, and determine whether the fault code is correctly reported when the fault is created and correctly released after the fault is cleared. At the same time, the boundary value test will verify whether the fault code status is always fault-free when the time or number of frames triggered by the fault is close to but less than the preset threshold, so as to ensure the accuracy and robustness of the fault code logic. (4) Result recording and analysis: During the entire test process, the automated test system uses the script to record the test results of each fault code, including changes in the fault code status, whether the test passed, and other information. After the test is completed, the script will summarize and analyze all test results to provide data support for generating a test report.

[0089] A test report is a document generated by the test system after the completion of the automated test, which records the test process, test results, and related analysis in detail. It mainly includes the following contents: (1) Test overview: Introduces the purpose of the test, the test environment, the test object (such as vehicle model, ECU, etc.), and the diagnostic table and fault code information based on the test, etc., to provide readers with basic background information of the test. (2) Test result summary: Lists the test results of each network fault code in detail, including the fault code ID, whether the test passed, and the change of the fault code status. For fault codes that failed the test, it is also necessary to record the specific failure reasons or abnormal conditions, such as the fault code was not reported correctly, the status did not meet expectations, etc. (3) Boundary value test results: Lists the results of the boundary value test separately, showing whether the fault code status is always fault-free when the fault trigger time or frame number is close to but less than the preset threshold, so as to verify the performance of the fault code logic under boundary conditions. (4) Problem analysis and suggestions: Conducts in-depth analysis of the problems found during the test, finds out the possible causes, such as fault code logic design defects, CAPL module function implementation problems, etc., and puts forward corresponding improvement suggestions or optimization plans to provide reference for subsequent system improvement and fault diagnosis. (5) Test conclusion: Summarize the conclusion of the entire test and clearly indicate whether the function and logic of the DTC network fault code meet the expected requirements, as well as the overall reliability level of the system. The test conclusion can provide important basis for project decision-making, such as whether to enter the next stage of development or mass production.

[0090] It is understandable that, first, the automated test system loads the constructed automated test script and executes the script in the test environment. During the script execution, the network fault code information in the vehicle model diagnostic table is automatically read, and the status of these fault codes is monitored in real time using the UDS protocol. Then, the script calls the CAPL module function to simulate network faults based on the fault code information and fault type, such as setting signal value errors, control message loss, etc., to trigger the reporting of fault codes. While simulating the fault, the script continuously monitors the state changes of the fault code to confirm whether it meets the expected state, such as whether the fault code is correctly reported when the fault is manufactured, whether it is correctly released after the fault is cleared, and performs boundary value tests to verify whether the fault code state is always fault-free when the fault trigger time or frame number is less than the preset threshold. The script will record the test results of each fault code in detail, including state changes, whether the test passes, and any abnormal information. Finally, after the test is completed, the system automatically generates a comprehensive test report based on the recorded result data. The test report shows the test results of each fault code in detail, summarizes the number of fault codes that passed and failed, analyzes the specific reasons for the failed fault codes, and provides relevant data for boundary value testing. The report also summarizes the overall conclusion of the test, points out whether the functions of the DTC network fault codes meet the expected requirements, and provides a reference for subsequent system improvements and fault diagnosis. Through automated testing and generating test reports, the testing of DTC network fault codes can be completed efficiently and accurately, improving test efficiency, reducing manual intervention, and ensuring the reliability and consistency of test results.

[0091] As an example, the step of performing automated testing according to the automated testing script and generating a test report includes: performing automated testing according to the automated testing script to obtain test results of whether the fault code status before, during, after and after the fault is cleared is consistent with the expected status; and generating a test report based on the test results.

[0092] Before the fault is triggered, it refers to the time point before the automated test script performs the fault simulation operation. At this stage, the vehicle's network communication system is in normal working condition, and no fault is artificially simulated or triggered. At this time, the fault code status should be no fault state, that is, the fault code is not reported, the vehicle's CAN network communication is normal, and all related electronic control units (ECUs) and sensors are working as expected, and no abnormalities are detected. In the test script, the fault code status before the fault is triggered will be read and recorded first as a benchmark for subsequent status change comparisons.

[0093] Fault triggering refers to the moment when the automated test script performs fault simulation operations and artificially introduces a preset network fault in the CAN network. For example, the signal value in a CAN message is set to an error value through the CAPL module function, or a message is controlled to stop sending for a period of time. At this point in time, the fault code should be triggered and reported according to its reporting conditions, that is, it changes from a no-fault state to the current fault state. At this point, the change in the fault code state is the focus of the test. It is necessary to confirm whether the fault code can accurately identify and report the fault to verify the correctness of its logic.

[0094] After the fault is triggered, it means the stage after the fault is triggered and reported, but before the fault clearing operation is performed. At this stage, the fault code is still in the current fault state, the vehicle's network communication system is still affected by the fault, and the relevant ECU and sensors may take some emergency measures or limit certain functions according to the instructions of the fault code. At this time, the test script will continue to monitor the state of the fault code to ensure that it remains in the current fault state, and record the duration and performance of the fault code in this stage to provide a reference for subsequent fault clearing and state recovery.

[0095] After fault clearing refers to the stage where after the fault is triggered and reported, the fault clearing operation is performed through the automated test script to change the fault code from the current fault state to the historical fault state or the non-fault state. The fault clearing operation usually includes restoring normal CAN network communication, such as restoring the signal value to the normal value, resending the message that was previously stopped, etc. After the fault is cleared, the fault code status should conform to the expected clearing logic, that is, it will no longer be displayed as a current fault, but will become a historical fault state (indicating that the fault has occurred, but has now been resolved), or completely cleared and restored to a non-fault state. At this time, the test script will read and record the status of the fault code again to verify the effectiveness of the fault clearing operation.

[0096] The fault code status refers to the reporting and manifestation of the diagnostic trouble code (DTC) in different test stages. According to the definition of the UDS protocol and the vehicle diagnostic system, the fault code status mainly includes the following types: (1) No fault status: The fault code is not reported, the vehicle's network communication system works normally, and no fault is detected. (2) Current fault status: The fault code is triggered and reported, indicating that there is currently a fault in the vehicle's network communication system. The relevant ECU and sensors will take corresponding measures based on the fault code. (3) Historical fault status: The fault code has been triggered and reported, but has been cleared during the test process, indicating that the fault has occurred but has now been resolved. (4) Pending confirmation fault status: After some fault codes are reported for the first time, it takes a period of time to confirm them as current faults or historical faults, and they are in a pending confirmation state.

[0097] The expected state refers to the state that the fault code should reach in each test stage according to the reporting and clearing conditions of the fault code and the design logic of the test script during the automated testing process. For example: (1) Before the fault is triggered, the expected state is the no-fault state, because the fault simulation has not been performed at this time. (2) When the fault is triggered, the expected state is the current fault state, because the fault code should be able to accurately identify and report the fault. (3) After the fault is triggered, the expected state remains the current fault state until the fault is cleared. (4) After the fault is cleared, the expected state is the historical fault state or the no-fault state, depending on the fault code clearing logic and the design of the test script. By comparing the actual fault code state with the expected state, it can be determined whether the fault code logic is correct and whether the test has passed.

[0098] The test result refers to the conclusion and data obtained by the automated test script after executing a series of test operations on whether the fault code status meets the expected status. The test results usually include the following: (1) Fault code status change record: Detailed record of the status change of each fault code before the fault is triggered, when the fault is triggered, after the fault is triggered, and after the fault is cleared, such as from no fault state to current fault state, and then to historical fault state or no fault state. (2) Test pass or fail judgment: Determine whether the test of each fault code passes or not based on whether the fault code status meets the expected status. If the fault code status is consistent with the expected status, the test passes; otherwise, the test fails. (3) Abnormal information and error cause: For fault codes that fail the test, record the specific abnormal information and possible error causes, such as the fault code is not reported correctly, the status change does not meet expectations, etc., for subsequent analysis and improvement. (4) Boundary value test results: If a boundary value test is performed, the results of the boundary value test must also be recorded to show whether the fault code status is always no fault when the fault trigger time or frame number is less than the preset threshold, so as to verify the performance of the fault code logic under boundary conditions. The test results are an important basis for evaluating the logical correctness of fault codes and system reliability. By analyzing the test results, problems in the system can be discovered and subsequent system optimization and fault diagnosis work can be guided.

[0099] First, the automated test system runs the automated test script, which automatically executes a series of preset test operations. At the beginning of the test, the script reads the network fault code information in the vehicle model diagnostic table, and monitors the initial state of the fault code through the UDS protocol to confirm that it is in a non-fault state, that is, the fault code is not reported, and the vehicle's network communication system is working normally. Then, according to the fault code information and fault type, the script calls the CAPL module function to simulate network faults, such as setting signal value errors or control message loss, etc. At this time, the fault code should be triggered and reported, and it will change from a non-fault state to the current fault state. The script will record the fault code state when the fault is triggered to verify whether it meets the expected current fault state. After the fault is triggered, the script continues to monitor the state of the fault code to ensure that it remains in the current fault state, and records the duration and performance of the fault code at this stage. Subsequently, the script executes the fault clearing operation to restore normal CAN network communication. The fault code should change from the current fault state to the historical fault state or the non-fault state. The script reads and records the fault code state after the fault is cleared again to verify whether it meets the expected clearing logic. During the entire test process, the script records in detail the status changes of each fault code and whether the test passes, and obtains test results of whether the fault code status before, during, after, and after the fault is cleared meets the expected status. Finally, based on these test results, the system automatically generates a detailed test report, which summarizes the test status of all fault codes, including the number of fault codes that passed and failed, the specific cause analysis of the failed fault codes, the boundary value test results, etc., and summarizes the overall conclusion of the test, indicating whether the function of the DTC network fault code meets the expected requirements, and provides a reference for subsequent system improvements and fault diagnosis. Through such an automated test and test report generation process, the test work of DTC network fault codes can be completed efficiently and accurately, the test efficiency can be improved, manual intervention can be reduced, and the reliability and consistency of the test results can be ensured.

[0100] This embodiment provides an automated testing method for network diagnostic fault codes, which includes obtaining a vehicle type diagnostic table; obtaining clustered network fault codes and controller area network access programming language module functions according to the vehicle type diagnostic table and preset network fault types; constructing an automated test script according to the vehicle type diagnostic table, the clustered network fault codes and the controller area network access programming language module functions; and performing automated testing according to the automated test script to generate a test report. First, the automated test system obtains the vehicle type diagnostic table, which is the basis for realizing automated testing because it provides detailed information on all fault codes of the vehicle, including reporting conditions and related CAN message data. Then, the system clusters the fault codes according to the vehicle type diagnostic table and preset network fault types (such as signal value errors, message loss, etc.), classifies fault codes with similar triggering conditions, and constructs corresponding CAPL module functions for each type of fault code, which can simulate specific network faults. Then, the vehicle type diagnostic table, the clustered fault codes and the CAPL module functions are used to construct an automated test script, which can automatically perform a series of test operations, including reading the fault code status, creating and clearing the fault, and recording the test results. Finally, the test is performed according to the automated test script, and a detailed test report is generated. The report summarizes the test status of all fault codes, including the number of fault codes that passed and failed, the specific reason analysis of the fault codes that failed, etc., to provide data support for vehicle fault diagnosis and system improvement. This embodiment can efficiently and accurately complete the test of DTC network fault codes through automated testing, without the need for long-term human intervention and manual operation, greatly shortening the test cycle and reducing labor costs. The generated test report provides clear and accurate test information for relevant personnel, which helps to promptly discover and solve problems in the system and improve the quality and reliability of the vehicle network communication system.

[0101] Based on the first embodiment of the present application, in the second embodiment of the present application, the same or similar contents as those in the above-mentioned embodiment 1 can refer to the above introduction, and will not be repeated later. Figure 2 , Figure 2 This is a flow chart of the second embodiment of the automated testing method for network diagnostic fault codes of the present application. The vehicle type diagnostic table includes the reporting conditions of all fault codes included in the current vehicle type. Step S20 of the automated testing method for network diagnostic fault codes includes steps S21 to S22:

[0102] Step S21, clustering the fault codes according to the reporting conditions and the preset network fault types to obtain clustered network fault codes;

[0103] It should be noted that the current vehicle model refers to the specific car model undergoing automated testing. Each vehicle model has its own unique design, configuration and functions. Therefore, there will be specific fault codes and diagnostic requirements in the vehicle's electronic system and network communications. In the automated testing solution in this embodiment, the diagnostic table of the current vehicle model contains all possible fault codes and related information of the vehicle model, and is the basic data source for automated testing. By analyzing and processing the diagnostic table of the current vehicle model, it can be ensured that the writing and execution of the test script can accurately test the fault codes of the vehicle model, thereby improving the pertinence and effectiveness of the test.

[0104] The reporting condition refers to the specific conditions or standards under which the fault code is triggered and reported. In the vehicle's diagnostic system, each fault code has its corresponding reporting condition, which is usually related to the vehicle's sensor signal, CAN message data, system status, etc. For example, the reporting condition of a fault code may be that the signal value of a sensor exceeds the normal range, a CAN message is lost for a period of time, or the checksum value of a message is wrong. The reporting condition is the core of the fault code logic. It determines under what circumstances the fault code will be reported, thereby helping technicians quickly locate and diagnose vehicle faults. In automated testing, the fault scenario can be accurately simulated according to the reporting condition to verify whether the fault code reporting logic is correct.

[0105] The preset network fault types refer to several typical network communication fault modes that are preset according to the characteristics of the CAN communication protocol and common problems in actual applications. In this embodiment, the preset network fault types mainly include the following four categories: (1) Error in a signal value in a CAN message: refers to a signal value in a message that does not match the normal value, which may be caused by sensor failure, transmission interference, etc. (2) CAN message loss: refers to a CAN message that has not been sent or received normally for a period of time, which may be caused by network node failure, communication line problem or network congestion. (3) CAN message Rolling counter count bit value error: Rolling counter is used to detect repeated message transmission. When the count bit value is wrong, such as repeated value or value jump, it indicates that there is a problem with the message transmission order or frequency. (4) CAN message checksum check bit value error: Checksum check bit is used to detect whether there is an error in the message during transmission. When its value is wrong, it indicates that the message may be interfered or damaged. These preset network fault types provide a classification basis for clustering fault codes, allowing the test script to perform targeted simulation and testing on different types of network faults.

[0106] Clustering refers to the process of classifying and organizing fault codes according to their reporting conditions and preset network fault types. In automated testing, by clustering fault codes, fault codes with similar reporting conditions and fault types can be grouped into one category to form a clustered set of network fault codes. For example, all fault codes triggered by signal value errors in CAN messages are grouped into one category, all fault codes triggered by CAN message loss are grouped into another category, and so on. Clustering is to simplify the writing of test scripts and the complexity of fault simulation, making the test process more efficient and orderly. Through clustered fault codes, unified test logic and CAPL module functions can be written for each type of fault code to improve the reusability and maintainability of test scripts.

[0107] Network fault codes refer to diagnostic trouble codes (DTCs) related to the vehicle network communication system. These fault codes are specifically used to indicate various fault conditions in the network communication system, such as CAN message signal value errors, message loss, Rollingcounter count bit errors, checksum check bit errors, etc. The setting and triggering of network fault codes are to help technicians quickly locate and diagnose problems in the vehicle network communication system and ensure the reliability and stability of the network system. In the automated testing solution, network fault codes are the focus of the test. By simulating various network fault types, it is verified whether the reporting and release of these fault codes are in line with expectations, thereby evaluating the fault diagnosis capabilities of the vehicle network communication system.

[0108] It can be understood that, first, the automated test system extracts the reporting conditions of each fault code from the vehicle model diagnostic table, which describe in detail the specific circumstances in which the fault code is triggered, such as signal value out of range, message loss, etc. Then, the system matches these reporting conditions with preset network fault types, which include signal value error in CAN message, CAN message loss, CAN message Rolling counter value error, and CAN message checksum value error. By comparing the reporting conditions of the fault code with these preset types, the system classifies the fault codes with the same or similar triggering conditions into one category, for example, all fault codes triggered by signal value errors in CAN messages are classified into the "signal value error" category, and all fault codes triggered by CAN message loss are classified into the "message loss" category. In this way, the system completes the clustering of the fault codes and obtains a set of fault codes classified by network fault types, that is, the clustered network fault codes. This step is to simplify the writing of subsequent test scripts and the complexity of fault simulation, so that targeted tests can be carried out for different types of network faults, improving the efficiency and accuracy of the test. Through clustering processing, we can more clearly understand the associations and differences between fault codes, providing strong support for subsequent automated testing and fault diagnosis.

[0109] As an example, the steps of clustering the fault codes according to the reporting conditions and preset network class fault types to obtain clustered network class fault codes include: performing text analysis on the reporting conditions to extract fault feature keywords; matching the corresponding fault codes with preset network class fault types according to the fault feature keywords to obtain clustered network class fault codes.

[0110] Text analysis refers to the process of natural language processing of the reporting conditions of the fault codes in the vehicle model diagnostic table. Specifically, the purpose of text analysis is to extract useful information and key features from the text description of the reporting conditions so that the fault codes can be accurately matched with the preset network fault types in the future. Text analysis usually involves the following steps: (1) Preprocessing: Clean and format the text of the reporting conditions, including removing irrelevant punctuation, spaces, special characters, etc., and converting the text into a unified format for subsequent processing. For example, convert all letters in the text to lowercase to eliminate the impact of uppercase and lowercase differences on the analysis. (2) Word segmentation: Split the text of the reporting conditions into separate words or vocabulary units. In English text, word segmentation usually splits sentences into words; in Chinese text, it is necessary to split sentences into individual Chinese characters or phrases. Word segmentation is to extract the basic semantic units in the text, laying the foundation for subsequent feature extraction and analysis. (3) Feature extraction: Extract feature information related to the fault code from the text after word segmentation. These characteristic information may include specific keywords, terms, value ranges, logical relationships, etc., which can reflect the core content and characteristics of the fault code reporting conditions. For example, extracting keywords such as "signal value", "out of range", "message loss", "a period of time", etc., these keywords can reveal the specific reasons and conditions for the fault code reporting.

[0111] Fault feature keywords refer to key words or terms extracted from the fault code reporting condition text that can represent fault features and trigger conditions. These keywords are important bases for matching fault codes with network fault types. They can link the reporting conditions of fault codes with preset fault types. In the automated test scheme of this embodiment, fault feature keywords mainly include the following aspects: (1) Fault cause keywords: keywords that describe the root cause or trigger factor of the fault code reporting, such as "sensor failure", "communication line problem", "network node failure", etc. These keywords can help identify the source and type of the fault code and provide clues for subsequent fault diagnosis and processing. (2) Fault condition keywords: keywords that describe the specific conditions or standards for the fault code reporting, such as "signal value out of range", "message loss for a period of time", "checksum check bit error", etc. These keywords clarify the quantitative indicators and time requirements for the fault code reporting, making the trigger conditions of the fault code more clear and operational. (3) Fault type keywords: keywords directly related to the preset network fault type, such as "signal value error", "message loss", "Rolling counter error", "checksum error", etc. These keywords are the key to matching fault codes with network fault types. They can correspond the reporting conditions of fault codes to preset types, thereby realizing clustering processing of fault codes.

[0112] First, the automated test system preprocesses the reporting condition text of each fault code in the vehicle model diagnostic table. The specific operation is to remove punctuation marks, special characters and extra spaces in the text, and convert the text to lowercase to eliminate the impact of uppercase and lowercase differences on subsequent analysis. This is done to ensure the accuracy and consistency of text analysis. Then, the system performs word segmentation on the preprocessed text, splitting the continuous text into separate words or vocabulary units, such as splitting "signal value out of range" into "signal value", "out of range", "range" and other words. Word segmentation is to extract the basic semantic units in the text, laying the foundation for subsequent feature extraction and analysis. Next, the system extracts fault feature keywords from the word segmented vocabulary. This step is achieved by analyzing the semantics and contextual relationship of the vocabulary. For example, "signal value" and "out of range" in "signal value out of range" are identified as fault feature keywords because they can represent the core reasons and conditions for the fault code to be reported. The purpose of extracting fault feature keywords is to accurately identify the characteristics and triggering factors of the fault code, providing a basis for subsequent fault code matching and clustering. Finally, the system matches the extracted fault feature keywords with the preset network class fault types. The specific operation is to compare the keywords with the keywords in the preset types, such as matching the "signal value out of range" keyword with the "signal value" keyword in the "signal value error" type. If the match is successful, the fault code is classified as the "signal value error" category. In this way, the system can classify fault codes with the same or similar trigger conditions into one category to obtain clustered network class fault codes. This simplifies the writing of subsequent test scripts and the complexity of fault simulation, making it possible to perform targeted tests on different types of network faults, improving the efficiency and accuracy of the test, and also allowing testers to more clearly understand the association and differences between fault codes, providing strong support for subsequent automated testing and fault diagnosis.

[0113] Step S22: constructing a controller area network access programming language module function according to the preset network fault type.

[0114] It can be understood that, first, the automated test system analyzes the characteristics and triggering conditions of each fault type according to the preset network fault type. For example, for the fault type of signal value error in the CAN message, the system will clarify that the triggering condition of this type of fault is that a certain signal value deviates from the normal range. Then, the system uses the controller area network access programming language (CAPL) to write corresponding module functions, which can simulate the specific behavior of the preset fault type. Taking the signal value error as an example, the CAPL module function will contain the code for setting the specific signal byte bit value in the CAN message to the error value. The function parameters include the message ID, signal byte bit and error value, etc. By calling the function, the fault condition of the signal value error can be accurately simulated in the CAN network. Then, the system tests and verifies the written CAPL module function to ensure that it can correctly simulate the fault type and is compatible with other system components such as UDS diagnostic services. Finally, these verified CAPL module functions are integrated into the automated test script so that the script can call the corresponding module function according to the fault code information when executing, realizing the automated simulation and testing of the fault. By constructing CAPL module functions, the system can efficiently and accurately simulate various network failures, providing strong technical support for automated testing while also improving the reusability and maintainability of test scripts.

[0115] As an example, the preset network class fault types include signal value error faults and message loss faults; the controller local area network access programming language module function includes a signal value error fault module function and a message loss fault module function; the step of constructing a controller local area network access programming language module function according to the preset network class fault type includes: taking a message identifier, a byte position and a byte assignment as parameters, and constructing the signal value error fault module function with the construction logic and clearing logic of the signal value error fault; taking the message identifier and loss time as parameters, and constructing the message loss fault module function with the construction logic and clearing logic of the message loss fault.

[0116] Signal value error fault refers to the situation in which the signal value contained in a CAN message in the CAN network communication of the car does not match the normal value. This fault may be caused by sensor failure, interference during transmission or other reasons. For example, the temperature signal value in a message suddenly jumps to an abnormally high value, which may trigger the relevant fault code. Signal value error fault will affect the normal function of the vehicle and the diagnostic system's accurate judgment of the fault.

[0117] Message loss failure refers to the situation in which a CAN message is not sent or received normally for a period of time in the CAN network. This failure may be caused by network node failure, communication line problem or network congestion. For example, a control unit does not send the status message that it should send regularly within a certain period of time, which may cause other nodes to be unable to obtain the status information of the control unit, thereby triggering a fault code. Message loss failure will affect the communication stability and real-time performance of the vehicle.

[0118] The signal value error fault module function is a function module written in the CAPL programming language, which is specifically used to simulate signal value error faults. This module function takes the message identifier, byte position, and byte assignment as parameters, and constructs a signal value error fault by setting the assignment of a byte in the CAN message. For example, you can specify the value of the byte of a message ID as an error value to simulate the situation of a signal value error. This module function also includes the clearing logic of the signal value error fault, that is, after the test is completed, the signal value in the message is restored to the normal value to clear the fault.

[0119] The message loss fault module function is a functional module written in the CAPL programming language, which is specifically used to simulate message loss faults. This module function takes the message identifier and loss time as parameters, and constructs a message loss fault by setting a message to stop sending for a period of time. For example, you can specify that a message ID is not sent within a certain period of time to simulate the situation of message loss. This module function also includes the clearing logic of the message loss fault, that is, after the test is completed, the normal sending of the message is restored to clear the fault.

[0120] The message identifier is an ID number used to uniquely identify each CAN message in the CAN network. Each message has a specific identifier to distinguish different message types and sources. In the CAPL module function, the message identifier is used as a parameter to specify the specific message that needs to be simulated for fault.

[0121] Byte position refers to the byte position in the CAN message, which is usually represented by byte number and bit number. In the signal value error fault module function, the byte position is used as a parameter to specify the byte position of the signal value to be modified. For example, a signal value may be located in the second position of the third byte of the message.

[0122] Byte assignment means assigning a specific value to a byte in the CAN message. In the signal value error fault module function, byte assignment is used as a parameter to set the specific value of the signal value error. For example, the value of a byte can be set to an error value that is out of the normal range to simulate a signal value error fault.

[0123] Parameters are variables used in CAPL module functions to pass specific information and control function behavior. In the signal value error fault module function, the parameters include message identifier, byte position, and byte assignment; in the message loss fault module function, the parameters include message identifier and loss time. These parameters enable module functions to flexibly simulate different types of fault conditions.

[0124] The construction logic of the signal value error fault refers to a method of constructing a signal value error fault by setting the value of a byte in the CAN message. Specifically, in the CAPL module function, the corresponding message is found according to the message identifier, and then the byte position of the signal value that needs to be modified is located according to the byte position, and finally the value of the byte is set to an error value, thereby simulating the situation of a signal value error.

[0125] The signal value error fault clearing logic refers to the method of restoring the signal value in the CAN message to the normal value after the test is completed. Specifically, in the CAPL module function, the byte previously set to the error value is reassigned to the normal signal value, thereby clearing the signal value error fault and restoring the message to the normal communication state.

[0126] The loss time is used to specify the specific length of time that a message is not sent for a period of time in the message loss fault module function. For example, the loss time can be set to 5 seconds, indicating that a message is not sent within 5 seconds, thereby simulating a message loss fault.

[0127] The construction logic of the message loss fault refers to the method of constructing a message loss fault by setting a message to stop sending for a period of time. Specifically, in the CAPL module function, the corresponding message is found according to the message identifier, and then according to the loss time parameter, the message is controlled not to be sent within the specified time, thereby simulating the message loss situation.

[0128] The message loss fault clearing logic refers to the method of restoring the normal message sending after the test is completed. Specifically, in the CAPL module function, the control of message suspension is cancelled so that the message can be resent at the normal cycle and frequency, thereby clearing the message loss fault and restoring the network communication to normal.

[0129] First, in order to construct the signal value error fault module function, the automated test system uses the CAPL programming language to define a function that accepts three parameters: message identifier, byte position, and byte assignment. The message identifier is used to specify the CAN message that needs to be modified, the byte position is used to locate the specific byte position in the message where the signal value needs to be changed, and the byte assignment is to set the value of the byte to an error value, thereby simulating the signal value error fault. For example, if you want to simulate the signal value error of the third byte in a message with a message ID of 0x100, you can set the value of the byte to a value outside the normal range. At the same time, the module function also includes the clearing logic of the signal value error fault, that is, after the test is completed, the signal value in the message is restored to the normal expected value to clear the fault and restore the message to normal communication status. Next, in order to construct the message loss fault module function, the system defines another CAPL function that accepts two parameters: message identifier and loss time. The message identifier is used to specify the CAN message that needs to be simulated to be lost, and the loss time defines the specific duration of the message stop sending. By setting a certain message not to be sent within a specified time, a message loss fault can be simulated. For example, a message with a message ID of 0x200 can be set not to be sent within 5 seconds. This module function also includes the logic for clearing the message loss fault, that is, after the test is completed, the normal sending cycle and frequency of the message are restored to restore the network communication to normal, ensuring the integrity and accuracy of the test. Through such parameterization and logic construction, the CAPL module function can flexibly simulate different types of network faults, providing strong technical support for automated testing.

[0130] As an example, the preset network class fault types include counting bit error faults and check bit error faults; the controller local area network access programming language module function includes a counting bit error fault module function and a check bit error fault module function; the step of constructing a controller local area network access programming language module function according to the preset network class fault types includes: taking a message identifier and a frame number as parameters, and constructing the counting bit error fault module function with the construction logic and clearing logic of the counting bit error fault; taking the message identifier and the frame number as parameters, and constructing the check bit error fault module function with the construction logic and clearing logic of the check bit error fault.

[0131] A count bit error fault refers to a situation in which an error occurs in the Rolling counter count bit of a CAN message in CAN network communication. The Rolling counter is a mechanism used to detect repeated message transmissions, and its count bit increments each time a message is sent. When the value of the Rolling counter count bit is incorrect, such as repeated values ​​or value jumps, this may indicate a problem with the order or frequency of message transmission, thereby triggering the relevant fault code. The count bit error fault affects the stability and reliability of vehicle network communications and may cause data loss or errors.

[0132] A checksum error fault refers to a situation in which the checksum of a CAN message is incorrect during CAN network communication. The checksum is used to detect whether an error occurs during the transmission of a message. It is calculated by a specific algorithm on the message data. When the checksum value of a message is incorrect, it indicates that the message may have been interfered with or damaged during transmission and cannot be correctly parsed, thereby triggering the relevant fault code. A checksum error fault will affect the accuracy and integrity of the vehicle network communication and may cause incorrect data to be received and processed.

[0133] The counting bit error fault module function is a functional module written in the CAPL programming language, which is specifically used to simulate the counting bit error fault. This module function takes the message identifier and the number of frames as parameters, and constructs the counting bit error fault by setting the Rolling counter count bit of the CAN message. For example, the Rollingcounter count bit of a certain message ID can be specified to maintain the same value or jump in several consecutive frames of messages, thereby simulating the situation of counting bit error. This module function also includes the clearing logic of the counting bit error fault, that is, after the test, the Rolling counter count bit is restored to the normal incrementing state to clear the fault.

[0134] The checksum error fault module function is a function module written in the CAPL programming language, which is specifically used to simulate the checksum error fault. This module function takes the message identifier and the number of frames as parameters, and constructs the checksum error fault by setting the checksum of the CAN message. For example, the checksum of a message ID can be set to an incorrect value in several consecutive frames of messages, thereby simulating the checksum error. This module function also includes the clearing logic of the checksum error fault, that is, after the test is completed, the checksum is restored to the correct calculated value to clear the fault.

[0135] The number of frames refers to the number of CAN messages sent continuously in CAN network communication. When simulating count bit error faults and check bit error faults, the number of frames is used as a parameter to specify the number of messages that need to simulate the fault. For example, you can set the count bit error or check bit error to be simulated in 10 frames of messages sent continuously, so as to simulate the actual fault situation more accurately.

[0136] The construction logic of the count bit error fault refers to the method of simulating the count bit error fault by setting the Rolling counter count bit of the CAN message. Specifically, in the CAPL module function, the corresponding message is found according to the message identifier, and then according to the frame number parameter, the value of the Rolling counter count bit is set to an error value in several consecutive frames of the message, such as maintaining the same value or jumping, so as to simulate the count bit error situation.

[0137] The clearing logic of the count bit error fault refers to the method of restoring the Rolling counter count bit of the CAN message to the normal increasing state after the test is completed. Specifically, in the CAPL module function, the incorrect setting of the Rollingcounter count bit is canceled so that it can continue to count according to the normal increasing rule, thereby clearing the count bit error fault and restoring the message to the normal communication state.

[0138] The construction logic of the checksum error fault refers to the method of simulating the checksum error fault by setting the checksum of the CAN message. Specifically, in the CAPL module function, the corresponding message is found according to the message identifier, and then according to the frame number parameter, the checksum value is set to an incorrect value in several consecutive frames of the message, thereby simulating the checksum error.

[0139] The logic for clearing the checksum error fault refers to the method of restoring the checksum of the CAN message to the correct calculated value after the test is completed. Specifically, in the CAPL module function, the incorrect setting of the checksum checksum is canceled, the correct checksum value is recalculated, and applied to the message, thereby clearing the checksum error fault and restoring the message to normal communication status.

[0140] First, in order to build the counting bit error fault module function, the automated test system uses the CAPL programming language to define a function that accepts two parameters: the message identifier and the number of frames. The message identifier is used to specify the CAN message that needs to simulate the counting bit error, and the number of frames defines how many frames of the message the fault is to be simulated. Inside the function, according to the construction logic of the counting bit error fault, the system will find the specified message and set the Rollingcounter count bit to an error value within a continuous specified number of frames, such as repeating or jumping the counting bit value, thereby simulating the counting bit error fault. At the same time, the module function also includes the clearing logic of the counting bit error fault, that is, after the test is completed, the Rollingcounter count bit is restored to the normal incrementing state to clear the fault and restore the message to the normal communication state. Next, in order to build the check bit error fault module function, the system also defines a CAPL function that also accepts the message identifier and the number of frames as parameters. In this function, according to the construction logic of the checksum error fault, the system will find the specified message and set the checksum check bit to an incorrect value within a specified number of consecutive frames, such as calculating an incorrect checksum value and applying it to the message, thereby simulating a checksum error fault. This module function also includes the clearing logic of the checksum error fault, that is, after the test is completed, the correct checksum value is recalculated and applied to the message to clear the fault and restore the message to normal communication status. Through such parameterization and logic construction, the CAPL module function can accurately simulate two types of network faults, counting bit errors and check bit errors, providing strong technical support for automated testing and ensuring the accuracy and completeness of the test.

[0141] This embodiment clusters the fault codes according to the reporting conditions and the preset network fault types to obtain clustered network fault codes; and constructs the controller area network access programming language module function according to the preset network fault types. First, the automated test system extracts the reporting conditions of each fault code from the vehicle type diagnosis table, and these conditions describe in detail the specific circumstances in which the fault code is triggered, such as signal value out of range, message loss, etc. Then, the system matches these reporting conditions with the preset network fault types, and the preset types include signal value error in CAN message, CAN message loss, CAN message Rolling counter count bit value error, and CAN message checksum check bit value error. By comparing the reporting conditions of the fault code with these preset types, the system classifies the fault codes with the same or similar triggering conditions into one category, for example, all fault codes triggered by signal value errors in CAN messages are classified into one category, and all fault codes triggered by CAN message loss are classified into another category, and so on, thereby completing the clustering of the fault codes and obtaining a set of fault codes classified by network fault types, that is, clustered network fault codes. This step simplifies the writing of test scripts, because a unified test logic and CAPL module function can be written for each type of fault code, reducing the complexity and redundant code of the script, and improving the readability and maintainability of the script; at the same time, it improves the test efficiency, because the clustered fault codes make the test process more orderly and efficient, and can batch process fault codes with the same or similar fault types, avoiding complex test settings and operations for each fault code separately, saving test time and resources; in addition, it enhances the targetedness of the test, so that the test can be more targeted for different types of network faults, ensuring that each fault type can be fully verified, improving the comprehensiveness and accuracy of the test, and helping to more accurately evaluate the fault diagnosis capabilities of the vehicle network communication system. Then, the system uses the controller area network access programming language to write the corresponding module functions to simulate the preset network class fault types. For example, for the fault type of signal value error in CAN message, write a CAPL module function, which takes message identifier, byte position and byte assignment as parameters, and constructs signal value error fault by setting the assignment of a byte in the message; for the fault type of CAN message loss, write a CAPL module function, which takes message identifier and loss time as parameters, and constructs message loss fault by setting a message to stop sending for a period of time. Each CAPL module function contains fault construction logic and clearing logic to ensure that faults can be accurately simulated and recovered during the test process.This step can accurately simulate faults, because the CAPL module function can reproduce real fault scenarios in the CAN network by setting specific parameter values, such as message identifiers, byte positions, byte assignments, loss time, etc., providing a reliable fault simulation basis for testing; at the same time, it improves the flexibility of the test, because the CAPL module function is highly flexible and can simulate faults in different situations by adjusting parameter values ​​to adapt to different test requirements and scenarios, making the test more flexible and diversified; in addition, it enhances the reusability of the test, because the constructed CAPL module function can be reused in different vehicle models or different test projects, without the need to rewrite the code for each test, saving development time and cost, and improving the utilization efficiency of test resources.

[0142] It should be noted that the above examples are only used to understand the present application and do not constitute a limitation on the automated testing method for network diagnostic fault codes of the present application. More simple transformations based on this technical concept are all within the scope of protection of the present application.

[0143] This application also provides an automated testing device for network diagnostic fault codes. Figure 3 , the automated testing device for network diagnostic fault codes comprises:

[0144] The data acquisition module 10 is used to obtain the vehicle type diagnosis table;

[0145] A clustering and function building module 20, used to obtain clustered network fault codes and controller area network access programming language module functions according to the vehicle type diagnosis table and preset network fault types;

[0146] A script construction module 30, for constructing an automated test script according to the vehicle type diagnosis table, the clustered network fault codes and the controller area network access programming language module function;

[0147] The testing module 40 is used to perform automated testing according to the automated testing script and generate a test report.

[0148] In one embodiment, the clustering and function construction module 20 is also used to cluster the fault codes according to the reporting conditions and preset network fault types to obtain clustered network fault codes; and to construct a controller local area network access programming language module function according to the preset network fault types.

[0149] In one embodiment, the clustering and function construction module 20 is also used to perform text analysis on the reporting conditions to extract fault feature keywords; match the corresponding fault code with a preset network class fault type according to the fault feature keywords to obtain a clustered network class fault code.

[0150] In one embodiment, the clustering and function construction module 20 is also used to take the message identifier, byte position and byte assignment as parameters, and use the construction logic and clearing logic of the signal value error fault to construct the signal value error fault module function; take the message identifier and loss time as parameters, and use the construction logic and clearing logic of the message loss fault to construct the message loss fault module function.

[0151] In one embodiment, the clustering and function construction module 20 is also used to use the message identifier and the frame number as parameters, and to construct the counting bit error fault module function with the construction logic and clearing logic of the counting bit error fault; and to use the message identifier and the frame number as parameters, and to construct the check bit error fault module function with the construction logic and clearing logic of the check bit error fault.

[0152] In one embodiment, the script construction module 30 is also used to generate a first code, the first code is used to read the fault code information of the network fault code in the vehicle type diagnostic table, and monitor the fault code status of the network fault code through a unified diagnostic service protocol; generate a second code, the second code is used to call the controller local area network access programming language module function according to the fault code information and the fault type corresponding to the clustered network fault code; generate a third code, the third code is used to confirm whether the fault code status meets the expected status, and perform a boundary value test to verify whether the fault code status is always fault-free before and after the triggering when the triggered fault is less than a preset fault trigger time threshold or a preset fault trigger frame number threshold, and output the test result; integrate the first code, the second code and the third code to form an automated test script.

[0153] In one embodiment, the test module 40 is also used to perform automated testing according to the automated test script to obtain test results of whether the fault code status before, during, after and after the fault is cleared is consistent with the expected status; and generate a test report based on the test results.

[0154] The automated testing device for network diagnostic fault codes provided by the present application adopts the automated testing method for network diagnostic fault codes in the above-mentioned embodiment, and can solve the technical problem of how to improve the automation and efficiency of DTC network fault code testing. Compared with the prior art, the beneficial effects of the automated testing device for network diagnostic fault codes provided by the present application are the same as the beneficial effects of the automated testing method for network diagnostic fault codes provided by the above-mentioned embodiment, and other technical features in the automated testing device for network diagnostic fault codes are the same as the features disclosed in the above-mentioned embodiment method, which will not be described in detail here.

[0155] The present application provides an automated testing device for network diagnostic fault codes, the automated testing device for network diagnostic fault codes comprising: 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 so that the at least one processor can execute the automated testing method for network diagnostic fault codes in the above-mentioned embodiment one.

[0156] Reference below Figure 4 , which shows a schematic diagram of the structure of an automated test device for network diagnostic trouble codes suitable for implementing the embodiment of the present application. The automated test device for network diagnostic trouble codes in the embodiment of the present 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), 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 4 The automated testing equipment for network diagnostic trouble codes shown is merely an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0157] like Figure 4As shown, the automated test equipment for network diagnostic trouble codes may include a processing device 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM: Read Only Memory) 1002 or a program loaded from a storage device 1003 to a random access memory (RAM: Random Access Memory) 1004. Various programs and data required for the operation of the automated test equipment for network diagnostic trouble codes are also stored in RAM1004. The processing device 1001, ROM1002, and RAM1004 are connected to each other via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, a touch screen, a touchpad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; storage devices 1003 including, for example, a magnetic tape, a hard disk, etc.; and communication devices 1009. The communication device 1009 can allow the automated test equipment for network diagnostic trouble codes to communicate wirelessly or wired with other devices to exchange data. Although the figure shows an automated test equipment for network diagnostic trouble codes with various systems, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems may be implemented or have instead.

[0158] In particular, according to the embodiments disclosed in the present application, the process described above with reference to the flowchart can be implemented as a computer software program. 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 includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication device, or installed from a storage device 1003, or installed from a ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiment disclosed in the present application are executed.

[0159] The automated testing device for network diagnostic fault codes provided by the present application adopts the automated testing method for network diagnostic fault codes in the above-mentioned embodiment, which can solve the technical problem of how to improve the automation and efficiency of DTC network fault code testing. Compared with the prior art, the beneficial effects of the automated testing device for network diagnostic fault codes provided by the present application are the same as the beneficial effects of the automated testing method for network diagnostic fault codes provided by the above-mentioned embodiment, and other technical features in the automated testing device for network diagnostic fault codes are the same as the features disclosed in the method of the previous embodiment, which will not be described in detail here.

[0160] It should be understood that the various parts disclosed in this application can be implemented by hardware, software, firmware or a combination thereof. In the description of the above embodiments, specific features, structures, materials or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0161] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

[0162] The present application provides a computer-readable storage medium having computer-readable program instructions (ie, computer programs) stored thereon, the computer-readable program instructions being used to execute the automated testing method for network diagnostic fault codes in the above-mentioned embodiment.

[0163] The computer-readable storage medium provided in the present application may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, systems or devices, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, system or device. The program code contained on the computer-readable storage medium may be transmitted using any appropriate medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination of the above.

[0164] The computer-readable storage medium may be included in the automated testing device for network diagnostic trouble codes; or may exist independently without being assembled into the automated testing device for network diagnostic trouble codes.

[0165] The above-mentioned computer-readable storage medium carries one or more programs. When the above-mentioned one or more programs are executed by the automated testing equipment for network diagnostic fault codes, the automated testing equipment for network diagnostic fault codes: obtains a vehicle type diagnostic table; obtains clustered network type fault codes and controller local area network access programming language module functions according to the vehicle type diagnostic table and preset network type fault types; constructs an automated testing script according to the vehicle type diagnostic table, the clustered network type fault codes and the controller local area network access programming language module functions; performs automated testing according to the automated testing script and generates a test report.

[0166] Computer program code for performing the operations of the present application may be generated in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate 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 may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0167] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present application. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0168] The modules involved in the embodiments described in this application may be implemented by software or hardware, wherein the name of the module does not constitute a limitation on the unit itself in some cases.

[0169] The readable storage medium provided by the present application is a computer-readable storage medium, which stores computer-readable program instructions (i.e., computer programs) for executing the above-mentioned automated testing method for network diagnostic fault codes, and can solve the technical problem of how to improve the automation and efficiency of DTC network fault code testing. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided by the present application are the same as the beneficial effects of the automated testing method for network diagnostic fault codes provided by the above-mentioned embodiment, and will not be elaborated here.

[0170] The present application also provides a computer program product, including a computer program, which implements the steps of the above-mentioned automatic testing method for network diagnostic fault codes when executed by a processor.

[0171] The computer program product provided by the present application can solve the technical problem of how to improve the automation and efficiency of DTC network fault code testing. Compared with the prior art, the beneficial effects of the computer program product provided by the present application are the same as the beneficial effects of the automated testing method for network diagnostic fault codes provided by the above embodiment, which will not be elaborated here.

[0172] The above descriptions are only some embodiments of the present application, and are not intended to limit the patent scope of the present application. All equivalent structural changes made using the contents of the present application specification and drawings under the technical concept of the present application, or direct / indirect applications in other related technical fields are included in the patent protection scope of the present application.

Claims

1. An automated testing method for network diagnostic fault codes, characterized in that: The method comprises: Get the vehicle model diagnostic table; Obtaining clustered network fault codes and controller area network access programming language module functions according to the vehicle type diagnosis table and preset network fault types; Constructing an automated test script according to the vehicle type diagnostic table, the clustered network fault codes and the controller area network access programming language module function; Perform automated testing according to the automated testing script and generate a test report.

2. The method according to claim 1, characterized in that The vehicle type diagnostic table includes the reporting conditions of all fault codes included in the current vehicle type; The step of obtaining clustered network fault codes and controller area network access programming language module functions according to the vehicle type diagnosis table and preset network fault types includes: Clustering the fault codes according to the reporting conditions and the preset network fault types to obtain clustered network fault codes; A controller area network access programming language module function is constructed according to the preset network class fault type.

3. The method according to claim 2, characterized in that The step of clustering the fault codes according to the reporting conditions and the preset network fault types to obtain clustered network fault codes comprises: Performing text analysis on the reporting conditions to extract fault feature keywords; The corresponding fault code is matched with a preset network class fault type according to the fault feature keyword to obtain a clustered network class fault code.

4. The method according to claim 2, characterized in that The preset network fault types include signal value error fault and message loss fault; The controller area network access programming language module function includes a signal value error fault module function and a message loss fault module function; The step of constructing a controller area network access programming language module function according to the preset network fault type comprises: Taking the message identifier, byte position and byte assignment as parameters, and constructing the signal value error fault module function with the construction logic and clearing logic of the signal value error fault; The message loss fault module function is constructed using the message identifier and loss time as parameters and the construction logic and clearing logic of the message loss fault.

5. The method according to claim 2, characterized in that The preset network fault types include counting bit error fault and check bit error fault; The controller area network access programming language module function includes a counting bit error fault module function and a check bit error fault module function; The step of constructing a controller area network access programming language module function according to the preset network fault type comprises: Taking the message identifier and the number of frames as parameters, and using the construction logic and clearing logic of the counting bit error fault, construct the counting bit error fault module function; The message identifier and the frame number are used as parameters, and the check bit error fault construction logic and clearing logic are used to construct the check bit error fault module function.

6. The method according to claim 1, characterized in that The step of constructing an automated test script according to the vehicle type diagnostic table, the clustered network fault codes and the controller area network access programming language module function comprises: Generate a first code, wherein the first code is used to read fault code information of the network fault code in the vehicle type diagnostic table, and monitor the fault code status of the network fault code through a unified diagnostic service protocol; Generate a second code, wherein the second code is used to call the controller area network access programming language module function according to the fault code information and the fault type corresponding to the clustered network fault code; Generate a third code, the third code is used to confirm whether the fault code state meets the expected state, and perform a boundary value test to verify whether the fault code state is always fault-free before and after the triggering when the triggered fault is less than a preset fault triggering time threshold or a preset fault triggering frame number threshold, and output the test result; The first code, the second code and the third code are integrated to form an automated test script.

7. The method according to any one of claims 1 to 6, characterized in that The step of performing automated testing according to the automated testing script and generating a test report comprises: Performing automated testing according to the automated testing script to obtain test results of whether the fault code status before, during, after, and after the fault is cleared meets the expected status; A test report is generated according to the test results.

8. An automated testing device for network diagnostic fault codes, characterized in that: The device comprises: Data acquisition module, used to obtain vehicle model diagnostic table; A clustering and function building module, used to obtain clustered network fault codes and controller area network access programming language module functions according to the vehicle type diagnosis table and preset network fault types; A script construction module, used for constructing an automated test script according to the vehicle type diagnosis table, the clustered network fault codes and the controller area network access programming language module function; The test module is used to perform automated testing according to the automated testing script and generate a test report.

9. An automated testing device for network diagnostic fault codes, characterized in that: The device comprises: a memory, a processor and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the automated testing method for network diagnostic trouble codes as claimed in 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 a processor, the steps of the automated testing method for network diagnostic fault codes as described in any one of claims 1 to 7 are implemented.

Images