Method and device for testing diagnosis fault code of controller area network

Abstract

The invention discloses a method and a device for testing a diagnosis fault code of a controller area network, and relates to the technical field of automobile electronic diagnosis, and the method for testing the diagnosis fault code of the controller area network comprises the steps: obtaining a database file and test configuration information of the controller area network; generating message records of all verification messages according to the test configuration information and the controller local area network database file; sorting the message records according to time, and generating a message record file according to a preset file format; playing back the message recording file through a controller local area network tool, and sending a diagnosis request message to the tested controller through the controller local area network tool while playing back the data to obtain a diagnosis fault code; and comparing the diagnosis fault code with a preset expected diagnosis fault code to obtain a test result. According to the method, the automation degree and the real-time performance of the test are improved, the dependence on physical hardware and environmental resources is reduced, and the test cost and the technical threshold are reduced.

Description

Technical Field

[0001] The present application relates to the field of automotive electronic diagnostic technology, and in particular to a method and device for testing controller area network diagnostic fault codes. Background Art

[0002] With the rise of software-defined cars and the rapid development of intelligent driving technology, the number of interactive signals between automotive controllers is increasing. To ensure the high reliability of these interactive signals, the sending controller adds a rolling signal (Rolling Counter) and a checksum signal (Checksum) to the key signal frame. The receiving controller needs to check whether the rolling signal increases by 1 for each frame received, and whether the checksum conforms to the preset checksum algorithm. Therefore, testing the Diagnostic Trouble Code (DTC) of the Controller Area Network (CAN) to ensure the accuracy and reliability of the signal has become an important requirement in the field of automotive electronics.

[0003] Currently, common methods for testing CAN message checksum DTCs include: implementing a checksum algorithm in a hardware-in-the-loop (HIL) controlled object model and deploying it to a slave computer for execution; writing CAN message RollingCounter and Checksum scripts, compiling them to generate machine code, and deploying them to a slave computer for call; or using bus simulation tools such as CANOE to develop a Communication Access Programming Language (CAPL) script to send checksum messages. These methods require using diagnostic tools to determine whether the controller under test reports communication fault codes as expected when sending, not sending, or sending errors with checksum messages over a period of time.

[0004] Existing approaches present several major problems: First, they rely on HIL environment resources or programmable bus tools with bus simulation capabilities, which are often expensive and limit the popularity and flexibility of testing. Second, these methods lack real-time performance and struggle to meet rapidly changing testing needs, especially when real-time response and processing of large amounts of data are required. Finally, these methods place high technical demands on test developers, increasing the difficulty and complexity of implementation. Therefore, the poor real-time performance, high dependence on environmental resources, and high technical barriers to entry of existing Controller Area Network Diagnostic Trouble Code testing methods have become urgent issues that need to be addressed.

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

[0006] The purpose of this application is to provide a method and device for testing controller local area network diagnostic fault codes, aiming to solve the technical problems of existing controller local area network diagnostic fault code testing methods, such as poor real-time performance, high dependence on environmental resources, and high technical barriers.

[0007] To achieve the above objectives, the present application proposes a method for testing controller area network diagnostic trouble codes, the method comprising:

[0008] Get the Controller Area Network database file and test configuration information;

[0009] Generate message records of all verification messages according to the test configuration information and the controller area network database file;

[0010] Sorting the message records by time and generating a message record file according to a preset file format;

[0011] Playing back the message record file through a controller area network tool, and sending a diagnostic request message to the controller under test through the controller area network tool while playing back the data, to obtain a diagnostic fault code;

[0012] The diagnostic trouble code is compared with a preset expected diagnostic trouble code to obtain a test result.

[0013] In one embodiment, the step of generating message records of all verification messages according to the test configuration information and the controller area network database file includes:

[0014] Parsing the controller area network database file to obtain a controller area network communication matrix;

[0015] querying and obtaining all verification messages from the controller area network communication matrix according to the rolling signal keyword and the verification signal keyword in the test configuration information;

[0016] All the verification messages are processed cyclically to obtain message records of all the verification messages.

[0017] In one embodiment, the step of cyclically processing all the verification messages to obtain message records of all the verification messages includes:

[0018] Set the time offset and message record generation time;

[0019] Determining a current message to be processed from all the verification messages;

[0020] Set the initial value of the rolling signal and the initial value of the check signal;

[0021] Querying and obtaining the period, rolling signal keyword, check signal keyword, check function, total message record generation time, and rolling discontinuous change value of the current message to be processed from the test configuration information;

[0022] Generate a message record of the current message to be processed according to the rolling signal keyword, the controller area network communication matrix, the test configuration information, the rolling signal initial value, the rolling discontinuous change value, a preset rolling signal threshold, the check signal keyword, the check signal initial value, the current message to be processed, the check function, and a preset check error value;

[0023] Return to the step of determining the current message to be processed from all the verification messages until the message records of all the verification messages are obtained.

[0024] In one embodiment, after the step of generating a message record of the current message to be processed based on the rolling signal keyword, the controller area network communication matrix, the test configuration information, the rolling signal initial value, the rolling discontinuous change value, the preset rolling signal threshold, the check signal keyword, the check signal initial value, the current message to be processed, the check function, and the preset check error value, the further step includes:

[0025] Updating the message record generation time according to the period;

[0026] When the message record generation time is less than the total message record generation time, returning to the step of generating the message record of the current message to be processed according to the rolling signal keyword, the controller local area network communication matrix, the test configuration information, the rolling signal initial value, the rolling discontinuous change value, the preset rolling signal threshold, the check signal keyword, the check signal initial value, the current message to be processed, the check function and the preset check error value;

[0027] When the message record generation time is greater than or equal to the total message record generation time, the time offset is incremented to update the time offset, and the message record generation time is updated according to the time offset.

[0028] In one embodiment, the step of generating a message record of the current message to be processed based on the rolling signal keyword, the controller area network communication matrix, the test configuration information, the rolling signal initial value, the rolling discontinuous change value, a preset rolling signal threshold, the check signal keyword, the check signal initial value, the current message to be processed, the check function, and a preset check error value includes:

[0029] Obtaining a rolling signal target value according to the rolling signal keyword, the controller area network communication matrix, the test configuration information, the rolling signal initial value, the rolling discontinuous change value, and a preset rolling signal threshold;

[0030] Obtaining a target value for a calibration signal according to the calibration signal keyword, the controller area network communication matrix, the test configuration information, the initial value for the calibration signal, the current message to be processed, the calibration function, and a preset calibration error value;

[0031] A message record of the current message to be processed is generated according to the rolling signal target value, the verification signal target value, and the controller area network communication matrix.

[0032] In one embodiment, the step of generating a message record of the current message to be processed based on the rolling signal target value, the verification signal target value, and the controller area network communication matrix includes:

[0033] Obtaining, from the controller area network communication matrix according to the current message to be processed, the parallel signal initial value, scale factor, offset, bit length, byte order, and value type of the parallel signals excluding the rolling signal and the check signal in the current message to be processed;

[0034] Obtaining a conversion relationship between the original value of the message and the signal value according to the scale factor, the offset, the bit length, the byte order, and the value type;

[0035] A message record of the current message to be processed is generated according to the rolling signal target value, the verification signal target value, the parallel signal initial value and the conversion relationship.

[0036] In one embodiment, the step of obtaining the rolling signal target value according to the rolling signal keyword, the controller area network communication matrix, the test configuration information, the rolling signal initial value, the rolling discontinuous change value, and a preset rolling signal threshold comprises:

[0037] According to the rolling signal keyword, a rolling signal name is obtained by querying the message signal of the controller local area network communication matrix;

[0038] querying the test configuration information according to the rolling signal name to obtain a rolling error result, a rolling error initial frame number, a rolling error continuous frame number, and a rolling error type;

[0039] Obtaining a rolling error end frame number according to the rolling error initial frame number and the number of rolling error continuous frames;

[0040] When the scroll error result is yes and the scroll error type is unchanged, taking the scroll signal initial value as the scroll signal target value;

[0041] When the scroll error result is yes and the scroll error type is discontinuous, obtaining the scroll signal target value according to the scroll discontinuous change value and the scroll signal initial value;

[0042] When the scroll error result is no, the scroll signal initial value is incremented to obtain the scroll signal target value;

[0043] When the scroll signal target value is greater than a preset scroll signal threshold, the scroll signal initial value is used as the scroll signal target value.

[0044] In one embodiment, the step of obtaining a target value of the check signal according to the check signal keyword, the CAN communication matrix, the test configuration information, the initial value of the check signal, the current message to be processed, the check function, and a preset check error value includes:

[0045] According to the verification signal keyword, a verification signal name is obtained by querying the verification signal of the controller local area network communication matrix;

[0046] querying the test configuration information according to the check signal name to obtain a check error result, a check error initial frame number, a check error continuous frame number, and a check error type;

[0047] Obtaining a check error end frame sequence number according to the check error initial frame sequence number and the number of check error consecutive frames;

[0048] When the check error result is yes, obtaining a check signal target value according to the current message to be processed, the check signal initial value, the check function and a preset check error value;

[0049] When the check error result is no, a check signal target value is obtained according to the current message to be processed, the check signal initial value and the check function.

[0050] In one embodiment, the step of replaying the message record file through a controller area network tool and sending a diagnostic request message to the controller under test through the controller area network tool while replaying the data to obtain a diagnostic fault code includes:

[0051] Playing back the message record file through a controller area network tool;

[0052] Inputting the replayed message into the controller under test, and sending a diagnostic request to the controller under test through a unified diagnostic service protocol, so that the controller under test feeds back response data;

[0053] The diagnostic trouble code is read from the response data through the controller area network tool.

[0054] In addition, to achieve the above-mentioned purpose, the present application also proposes a test device for Controller Area Network Diagnostic Fault Codes, the device comprising:

[0055] Data acquisition module, used to obtain controller local area network database files and test configuration information;

[0056] A message recording module, configured to generate message records of all verification messages according to the test configuration information and the controller area network database file;

[0057] A message record file generating module, used to sort the message records by time and generate a message record file according to a preset file format;

[0058] a diagnostic module, configured to replay the message record file through a controller area network tool, and simultaneously send a diagnostic request message to the controller under test through the controller area network tool to obtain a diagnostic fault code;

[0059] The test module is used to compare the diagnostic trouble code with a preset expected diagnostic trouble code to obtain a test result.

[0060] In addition, to achieve the above-mentioned purpose, the present application also proposes a test device for a controller area network diagnostic fault code, 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 test method for a controller area network diagnostic fault code as described above.

[0061] 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 test method of the controller local area network diagnostic fault code are implemented as described above.

[0062] 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 test method of the controller local area network diagnostic fault code as described above.

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

[0064] Obtain the controller area network database file and test configuration information; generate message records of all verification messages based on the test configuration information and the controller area network database file; sort the message records by time and generate a message record file according to a preset file format; replay the message record file through the controller area network tool, and send a diagnostic request message to the controller under test through the controller area network tool while replaying the data to obtain a diagnostic fault code; compare the diagnostic fault code with the preset expected diagnostic fault code to obtain the test result. The diagnostic test system first extracts the necessary communication parameters from the controller area network database file and generates a specific CAN message record based on the built-in test configuration information. This step ensures that the test can be performed based on accurate network parameters and predefined test requirements. Subsequently, the system sorts these message records in chronological order and generates a message record file that conforms to the preset file format, ensuring that the order in which the messages are sent is consistent with the actual communication and that the file can be correctly read and replayed by the CAN tool. Next, the diagnostic test system uses the controller area network tool to replay the generated message log files, simulating an actual communication environment. The replayed messages are then used to diagnose the controller under test to obtain diagnostic trouble codes. This step enables the system to test the controller's response to specific messages without interfering with the normal operation of the vehicle, improving the safety and flexibility of the test. Finally, the system compares the actual diagnostic trouble codes obtained with the preset expected diagnostic trouble codes to determine the test results. This verification step is key to ensuring that the controller's diagnostic functions operate as expected. It provides clear test results, helps quickly identify potential problems in the controller, and accelerates the fault diagnosis and repair process. The entire process improves the automation, accuracy, and real-time performance of the test, reduces dependence on physical hardware and environmental resources, lowers testing costs and technical barriers, and enables testing to be conducted in a more controlled environment, ensuring the reliability and safety of the vehicle's electronic systems. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

[0067] Figure 1 A flowchart of the first embodiment of the method for testing a controller area network diagnostic fault code is provided in this application;

[0068] Figure 2 A flowchart diagram of the second embodiment of the method for testing a controller area network diagnostic fault code of the present application is provided;

[0069] Figure 3 A schematic diagram of a simplified flow chart of a method for testing a controller area network diagnostic fault code provided in the second embodiment of the present application;

[0070] Figure 4 This is a schematic diagram of the module structure of a test device for diagnosing fault codes in a controller area network according to an embodiment of the present application;

[0071] Figure 5 This is a schematic diagram of the device structure of the hardware operating environment involved in the test method for the controller local area network diagnostic fault code in the embodiment of the present application.

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

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

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

[0075] With the development of software-defined vehicles and intelligent driving technologies, the number of interactive signals between automotive controllers has increased. To ensure high reliability, the sending controller has added rolling signals and check signals to key signal frames, and the receiving controller needs to verify the correctness of these signals. Therefore, it is crucial to test the checksum DTC in CAN messages to ensure signal accuracy. Currently, common testing methods include implementing verification algorithms in a HIL environment, writing and deploying CAN message verification scripts, or using tools such as CANOE to develop CAPL scripts to send messages with checksums and use diagnostic tools to read whether the controller reports fault codes as expected under different circumstances. However, existing methods have problems such as reliance on expensive resources, lack of real-time performance, and high requirements for technical personnel. These problems limit the popularity and flexibility of testing and make it difficult to meet rapidly changing testing needs.

[0076] The main solution of the embodiment of the present application is: the diagnostic test system extracts communication parameters from the controller local area network database and generates specific CAN message records to ensure that the test is based on precise network parameters and predefined requirements. The system sorts these message records in chronological order and generates files that conform to the preset format to ensure that the message sending order is consistent with the actual communication and is compatible with the CAN tool. Then, these message records are replayed through the CAN tool to simulate the real communication environment and diagnose the controller under test to obtain fault codes. This process does not interfere with the normal operation of the vehicle and improves the safety and flexibility of the test. Finally, the system compares the actual fault codes obtained with the expected results to verify whether the controller diagnostic function works as expected, thereby quickly identifying and accelerating the resolution of potential problems.

[0077] It should be noted that the execution subject of the embodiments of the present application may be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, mobile phone, etc. that runs a CANOE script that implements the above functions, or an electronic device, diagnostic test system, etc. that can implement the above functions. The following uses the diagnostic test system as an example to illustrate this embodiment and the following embodiments.

[0078] Based on this, the embodiment of the present application provides a method for testing a controller area network diagnostic fault code, referring to Figure 1 , Figure 1 This is a flow chart of the first embodiment of the method for testing controller area network diagnostic trouble codes of the present application.

[0079] In this embodiment, the method for testing the CAN diagnostic trouble code includes steps S10 to S50:

[0080] Step S10, obtaining a controller area network database file and test configuration information;

[0081] It should be noted that the Controller Area Network Database File (DBC) is a file format used to describe the CAN network protocol. It is a database file. The DBC file contains message information, not message records. The message records are generated according to the flowchart of the block diagram. The generation process requires the use of test configuration information and the Controller Area Network Database File. The DBC file contains all the necessary communication parameters and configuration information in the CAN network. This information is crucial for understanding and generating CAN messages. Specifically, the information contained in the DBC file includes: (1) Node information: describes each node in the CAN network, that is, each controller or device. (2) Send message and receive message names: lists the names of the messages that each node can send and receive. (3) Message period: specifies the sending period of each message. (4) Signal name: lists the signal name contained in each message. (5) Signal initial value and signal length: provides the initial value of each signal and the number of bits occupied by the signal. (6) Factor (scaling factor) and Offset (offset): used to convert from raw value to signal value (physical value). (7) Maximum and minimum values: define the range of signal values. The DBC file is the basis of CAN network communication. It provides the necessary parameters and rules for the generation and analysis of messages.

[0082] Test configuration information refers to a series of parameters and settings provided by the user in order to perform a specific CAN verification DTC test. This information is used to guide the test process and ensure that the generated messages meet the test requirements. The test configuration information includes: (1) Total time for generating message records: specifies the total time length for generating messages during the test. (2) Name of the controller under test: identifies the controller to be tested. (3) Names of all verification messages: lists the names of all messages that need to be verified. (4) Rolling signal keywords and verification signal keywords: used to search and identify rolling signals and verification signals in message signals. (5) Verification algorithm name: specifies the algorithm used for verification. (6) Whether to create verification errors: determines whether to intentionally introduce verification errors in the test. (7) Number of consecutive verification error frames and frame sequence number at which verification errors begin to be created: If verification errors are created, specify the frame sequence number where the error occurs and the number of consecutive error frames. (8) Whether to create rolling errors: determines whether to intentionally introduce rolling signal errors in the test. (9) Rolling error type: specifies the type of rolling error, such as whether the rolling signal remains unchanged or the rolling signal is discontinuous. (10) Frame number and number of consecutive frames at which rolling errors begin: If rolling errors are to be generated, specify the frame number where the error occurs and the number of consecutive frames at which the error occurs. Test configuration information is a key input to the test process. It allows testers to customize test scenarios based on specific test requirements to verify whether the controller's response to different CAN message verification conditions meets expectations. With this configuration information, messages that meet specific test requirements can be generated and corresponding DTC tests can be performed.

[0083] As you can understand, the diagnostic test system first retrieves and loads a DBC file from a storage medium or network server. This file contains the communication parameters for all nodes in the CAN network, such as message period, signal names, and attributes. This ensures that the system can accurately understand and generate messages that comply with the CAN protocol. Secondly, the system loads test configuration information from a storage medium or network server, or parses test configuration information entered by the user through a graphical interface or command line. This information specifies the specific test requirements, such as test duration, controller name, message name, and whether to simulate errors. This step is used to customize test scenarios to verify the controller's behavior under different conditions. Finally, the system uses the parameters in the DBC file and the test configuration information to generate test cases. These test cases include both normal and abnormal CAN messages to simulate various conditions in actual operation. This allows for detailed testing of the controller without requiring actual hardware intervention, thereby evaluating its response to receiving correct or incorrect checksum messages and ensuring that its diagnostic trouble code (DTC) generation and processing meet expectations, improving test efficiency and accuracy.

[0084] Step S20, generating message records of all verification messages according to the test configuration information and the controller area network database file;

[0085] It should be noted that message records refer to a series of specific message data generated based on the CAN network communication parameters and test configuration information defined in the DBC file. These data are used to simulate actual CAN network communication conditions for DTC testing. Specifically, message records include the following aspects: (1) Message identifier (ID): A unique identifier for each CAN message, used to distinguish different messages. (2) Message direction (Dir): Indicates whether the message is sent (TX) or received (RX). (3) Data length (DLC): The length of the data field in the message, that is, the number of data bytes contained in the message. (4) Data field (data0~data7): The actual data in the message. These data are calculated based on the signal attributes and test configuration information defined in the DBC file. Each byte in the data field corresponds to a signal in the message and contains the value of the signal. (5) Timestamp (Time): The time point when the message is sent or received, used to simulate the timing in actual communication. (6) Channel: The physical channel through which the message is sent or received, such as the channel number of the CAN bus.

[0086] As you can understand, the diagnostic test system first reads the test configuration information, which includes parameters such as the name of the CAN message to be tested, the test duration, whether errors need to be simulated, and the error type. The system then accesses the controller area network database file (DBC file) to extract detailed communication parameters related to the messages specified in the test configuration information, including the signal name, initial value, signal length, scale factor, and offset for each message. Next, the system calculates the specific value of each signal based on these parameters and configuration information and assembles these values into a complete CAN message according to the format defined in the DBC file. Finally, the system generates message records containing timestamps, channel information, message ID, direction, data length, and data fields. These records simulate the communication conditions in an actual CAN network and are used for subsequent DTC testing to ensure the accuracy and effectiveness of the test. This process allows the system to simulate a CAN communication environment that meets specific test requirements without actual hardware interaction.

[0087] Step S30, sorting the message records by time and generating a message record file according to a preset file format;

[0088] It should be noted that the preset file format refers to the standard file format used to store and exchange CAN message data. These formats can be recognized and processed by CAN analysis tools and simulation software. Common preset file formats include: (1) ASC format (ASCII format): This is a text format. Message records are stored in plain text, which is easy to read and edit. Each message record contains a timestamp, channel, ID, direction, DLC (data length), and data bytes (data0 to data7). (2) BLF format (Binary Log Format): This is a binary format. Compared with the ASC format, it is more compact and suitable for storing and processing large amounts of data. BLF files contain binary-encoded message information and require specialized software to parse.

[0089] A message log file contains a chronological series of CAN message records, which can be used for subsequent testing and analysis. For example, during CAN network simulation testing, this file can be read by CAN tools to simulate the actual CAN communication environment or used to diagnose and analyze data transmission issues within the CAN network. Message log files enable diagnostic test systems to simulate and verify network communications without the need for actual CAN hardware, making them a valuable tool for CAN network testing and analysis.

[0090] As you can understand, the diagnostic test system first sorts all generated message records based on the timestamp information in each message record, ensuring they are arranged in absolute chronological order of transmission or reception. This is done to simulate the timing and event sequence in actual CAN network communications. The system then converts the sorted message records into a file format based on a preset file format, such as ASC or BLF. For example, in ASC format, the system converts each message record into a text line containing information such as time, channel, ID, direction, data length, and data field, and writes these lines to a text file in chronological order. Finally, the generated ASC file contains the file header information and all chronologically sorted message records. This file can be read and processed by CAN analysis tools and simulation software for further testing and analysis, ensuring the correct format and data integrity of the message record file, and can be used for subsequent DTC testing and network simulation.

[0091] Step S40, replaying the message record file through a controller area network tool, and sending a diagnostic request message to the controller under test through the controller area network tool while replaying the data, to obtain a diagnostic fault code;

[0092] It should be noted that Controller Area Network (CAN) tools refer to tools used to manipulate and analyze CAN network communications. These tools can send, receive, record, and replay CAN messages. Common CAN tools include CAN analyzers, CAN emulators, and CAN test software. These can be hardware devices or software applications used to support the development, testing, and troubleshooting of CAN networks. Replay refers to the process of using CAN tools to resend messages from previously recorded or generated message log files to the CAN network. This process simulates the transmission of the original messages, allowing diagnostic test systems to recreate communication scenarios in actual hardware or simulated environments to verify network behavior and controller responses. The controller under test refers to one or more electronic control units (ECUs) on the CAN network whose functionality and performance need to be verified during testing. These controllers are responsible for processing messages on the CAN network and performing actions based on the message content, such as controlling the vehicle's lighting or engine management system. Diagnostic trouble codes are codes generated when an electronic control unit (ECU) detects a potential problem or fault. DTCs provide detailed information about the nature, location, and cause of a fault and are typically used for fault diagnosis and repair. In CAN network testing, by sending specific messages and observing the DTCs that the controller responds to, it is possible to verify whether the controller can correctly identify and respond to different network conditions and potential communication errors.

[0093] As you can understand, the diagnostic test system first loads a pre-generated message log file containing time-ordered CAN message data. Then, using a controller area network (CAN) tool, the system replays these message data back to the CAN network via the CAN interface. This process, called replay, simulates a real-world communication environment, allowing network communication behavior to be reproduced and observed in a controlled test environment. Next, the system monitors the response of the controller under test (the target ECU) on the network to these replayed messages. This step verifies whether the controller correctly processes the received messages. Finally, the system retrieves diagnostic trouble codes (DTCs) from the controller under test by sending diagnostic request messages. This step is accomplished through diagnostic communication on the CAN network to verify whether the controller correctly generates the expected DTCs based on the received messages. In this way, the diagnostic test system can evaluate whether the controller's response meets expectations, thereby verifying the accuracy of its diagnostic logic and network communication, ensuring that the controller can accurately detect and report faults in actual vehicle operation.

[0094] As an example, the message recording file is replayed through the controller LAN tool, and a diagnostic request message is sent to the controller under test through the controller LAN tool while playing back the data. The step of obtaining a diagnostic fault code includes: replaying the message recording file through the controller LAN tool; inputting the replayed message into the controller under test, and sending a diagnostic request to the controller under test through a unified diagnostic service protocol, so that the controller under test feeds back response data; and reading the diagnostic fault code from the response data through the controller LAN tool.

[0095] Uniform Diagnostic Services (UDS) is a standardized diagnostic communication protocol for communication between a vehicle's electronic control unit (ECU) and external diagnostic tools. Based on the ISO 14229 standard, UDS defines a series of services and requests that allow diagnostic tools to read and clear fault codes (DTCs), as well as read and modify ECU parameters and settings. The UDS protocol supports services such as reading fault codes (DTCs), clearing DTCs, reading data parameters, and writing data parameters. A diagnostic request is a specific request message sent by a diagnostic tool to the controller under test (UUT) using the UDS protocol. These requests are intended to query or manipulate ECU data. For example, a diagnostic request might be a "Read DTC" service request, which requests the ECU to return the DTC information stored within it. Response data is the data returned by the UUT in response to a diagnostic request. In the UDS protocol, when an ECU receives a request from a diagnostic tool, it generates a response message containing the results of the requested operation. For example, if the diagnostic request is to read DTCs, the response data will contain a list of all DTCs detected by the ECU.

[0096] First, the diagnostic test system uses a Controller Area Network (CAN) tool to replay a series of CAN messages stored in a message log file onto the CAN network in chronological order, simulating a real-world vehicle communication environment. Second, as these messages are replayed on the CAN network, they are input into the controller under test (ECU). The diagnostic test system then uses the Unified Diagnostic Service (UDS) protocol, a standardized diagnostic communication protocol, to send a diagnostic request to the ECU. This request is a specific service request, such as a request to read a fault code. This triggers the controller to execute the diagnostic service and return relevant information. Finally, after receiving the diagnostic request, the ECU processes it and generates response data containing the results of the diagnostic request. The diagnostic test system, again using the CAN tool, extracts the diagnostic trouble codes from this response data. These trouble codes provide important information about the controller's status and potential faults, which can be used to analyze and verify that the controller's diagnostic functions are functioning as expected. This process ensures accurate controller diagnostic testing without physically intervening in the vehicle's operation.

[0097] Step S50: Compare the diagnostic trouble code with a preset expected diagnostic trouble code to obtain a test result.

[0098] It should be noted that the preset expected diagnostic trouble codes refer to a set of trouble codes set before the diagnostic test is performed based on the test scenario and expected system behavior. They represent the trouble codes that the system should return under specific test conditions. If the controller under test (ECU) works as expected, it will return these preset trouble codes. For example, if the test scenario is to simulate a sensor fault, the preset expected diagnostic trouble code may be "P0123", which represents the specific fault type of the sensor. The test result is the conclusion drawn after comparing the diagnostic trouble codes actually obtained from the controller under test with the preset expected diagnostic trouble codes. The test results can be the following: (1) Pass: If the diagnostic trouble codes actually obtained completely match the preset expected diagnostic trouble codes, then the test result is "passed", indicating that the controller under test correctly identified the test conditions and returned the expected trouble codes, indicating that the diagnostic function of the controller is working properly. For example, if a checksum error input is made, the expected result is DTC: U0456, and the actual result is DTC U0456, then the test result is considered to be passed. (2) Failure: If the actual diagnostic trouble code obtained is inconsistent with the expected one, or if no trouble code is returned when a trouble code is expected, the test result is "Failure", indicating that the controller under test is not working as expected and there may be a problem that requires further diagnosis. (3) Warning: In some cases, if the returned trouble code indicates a non-critical problem or further information is needed to determine the status, the test result may be marked as "Warning".

[0099] It can be understood that first, the diagnostic test system collects actual diagnostic trouble codes (DTCs) from the controller under test. These codes are generated by the controller after receiving the replayed CAN message and executing the diagnostic request. The system then compares these actual DTCs one by one with the pre-defined preset expected diagnostic trouble codes. These preset codes are set based on an understanding of the test scenario and the system's expected behavior, and are used to identify the type of fault expected to occur under specific test conditions. Finally, the system determines whether the test is successful based on the comparison results. If the actual DTC is exactly the same as the expected DTC, the test result is "passed", indicating that the controller can correctly identify the fault and return the correct fault code; if there is a difference or the expected DTC is not returned, the test result is "failed", indicating that the controller may not have processed the message correctly or there is another problem. This process is a key step in verifying the accuracy of the controller's diagnostic function and ensures the reliability and safety of the vehicle's electronic system.

[0100] This embodiment provides a method for testing controller area network (CAN) diagnostic trouble codes. The method comprises obtaining a CAN database file and test configuration information; generating a message record of all verification messages based on the test configuration information and the CAN database file; sorting the message records by time and generating a message record file according to a preset file format; replaying the message record file through a CAN tool and, while replaying the data, sending a diagnostic request message to the controller under test through the CAN tool to obtain a diagnostic trouble code; and comparing the diagnostic trouble code with a preset expected diagnostic trouble code to obtain a test result. The diagnostic test system first extracts the necessary communication parameters from the CAN database file and generates a specific CAN message record based on the built-in test configuration information. This step ensures that the test can be performed based on accurate network parameters and predefined test requirements. The system then sorts the message records by time and generates a message record file that conforms to the preset file format, ensuring that the order of message transmission is consistent with actual communication and that the file can be correctly read and replayed by the CAN tool. Next, the diagnostic test system uses the controller area network tool to replay the generated message log files, simulating an actual communication environment. The replayed messages are then used to diagnose the controller under test to obtain diagnostic trouble codes. This step enables the system to test the controller's response to specific messages without interfering with the normal operation of the vehicle, improving the safety and flexibility of the test. Finally, the system compares the actual diagnostic trouble codes obtained with the preset expected diagnostic trouble codes to determine the test results. This verification step is key to ensuring that the controller's diagnostic functions operate as expected. It provides clear test results, helps quickly identify potential problems in the controller, and accelerates the fault diagnosis and repair process. The entire process improves the automation, accuracy, and real-time performance of the test, reduces dependence on physical hardware and environmental resources, lowers testing costs and technical barriers, and enables testing to be conducted in a more controlled environment, ensuring the reliability and safety of the vehicle's electronic systems.

[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 embodiment 1 can be referred to the above introduction and will not be described in detail later. Figure 2 , Figure 2 This is a flow chart of a second embodiment of the method for testing a Controller Area Network Diagnostic Trouble Code (CATN) of the present application. Step S20 of the method for testing a Controller Area Network Diagnostic Trouble Code (CATN) includes steps S21 to S23:

[0102] Step S21, parsing the CAN database file to obtain a CAN communication matrix;

[0103] It should be noted that the CAN communication matrix refers to the data structure parsed from the DBC file. It contains detailed information related to all communications in the CAN. This communication matrix specifically includes: (1) Node information: describes the identification and attributes of each node in the CAN network, that is, each controller or electronic control unit. (2) Message information: contains the name, ID, and period and attributes of the messages sent and received by each node. (3) Signal information: contains the signal name, initial value, length (number of bits), and position of the signal in the message contained in each message. (4) Signal attributes: includes the physical attributes of each signal, such as scale factor, offset, maximum value, and minimum value. These attributes are used to convert the original value of the signal into a physical value. (5) Network topology: describes the connection relationship between nodes in the network, that is, which nodes communicate with each other.

[0104] It is understandable that the diagnostic test system first parses the controller area network database file (DBC file), reading and analyzing each part of the file, including node information, message name and ID, signal name and its attributes, and the position and length of the signal in the message. The system then constructs a data structure containing these detailed information, namely the controller area network communication matrix, which summarizes the relationships and attributes between all nodes, messages and signals. This matrix is the basis for subsequent test case generation, communication scenario simulation and diagnostic testing, because it provides the necessary parameters and rules, enabling the system to accurately simulate the communication behavior in the CAN network and verify whether the controller's response is as expected.

[0105] Step S22, querying and obtaining all verification messages from the controller area network communication matrix according to the rolling signal keyword and the verification signal keyword in the test configuration information;

[0106] It should be noted that check messages refer to CAN messages that contain data used for verification. These data can be rolling counters / rolling signals (Rolling Counter) and checksums / checksums, etc. These verification data are used to ensure the integrity and correctness of the message during transmission. The receiver will verify these verification data according to the preset algorithm to determine whether the message has been tampered with or an error has occurred during transmission.

[0107] It can be understood that first, the diagnostic test system will access the data structure or file that stores the test configuration information. This configuration information is set in advance by the user according to the test requirements and contains specific parameters of the CAN messages that need to be verified; then, the system parses this configuration information and uses keywords or identifiers to retrieve all specified messages that need to be verified.

[0108] Step S23: cyclically process all the verification messages to obtain message records of all the verification messages.

[0109] It should be noted that cyclic processing refers to the process of performing the same operation on a series of objects or data one by one. In this embodiment, it involves executing a series of predetermined processing steps on each verification message, including the calculation of message signal values, the processing of rolling signals and verification signals, message generation, and the creation of message records.

[0110] It can be understood that first, the diagnostic test system will traverse all specified checksum messages. For each message, the system will calculate the initial value and required checksum data of each signal based on the signal attributes defined in the DBC file and the parameters provided in the test configuration information. This is done to simulate the correct format and content of the messages in actual CAN network communication. Then, the system will adjust the rolling counter and checksum of each message according to the test requirements specified in the configuration, such as increasing the counter value in a specific sequence or introducing checksum errors to simulate different communication scenarios and potential communication problems. Finally, the system converts these processed message data into message records in formats such as ASC or BLF, and adds timestamps and other necessary information to each message record. This is done to generate standardized files that can be recognized and played back by CAN tools. Through this cyclic processing, the system can generate a series of detailed message records. These records can not only be used to simulate the actual CAN communication environment, but also for subsequent testing and analysis to ensure the accuracy and reliability of the test results, thereby comprehensively evaluating the controller's response and processing capabilities to different checksum messages.

[0111] As an example, the step of performing cyclic processing on all the verification messages to obtain message records of all the verification messages includes: setting a time offset and a message record generation time; determining the current message to be processed from all the verification messages; setting a rolling signal initial value and a verification signal initial value; querying from the test configuration information to obtain the period, rolling signal keyword, verification signal keyword, verification function, total message record generation time and rolling discontinuous change value of the current message to be processed; generating a message record of the current message to be processed according to the rolling signal keyword, the controller LAN communication matrix, the test configuration information, the rolling signal initial value, the rolling discontinuous change value, the preset rolling signal threshold, the verification signal keyword, the verification signal initial value, the current message to be processed, the verification function and the preset verification error value; returning to the step of determining the current message to be processed from all the verification messages until the message records of all the verification messages are obtained.

[0112] The time offset (Δtime) is a time interval set by the system when generating each message record. This ensures that the timestamps of consecutively generated message records are unique, simulating the continuous transmission of messages in real-world communications. For example, if Δtime is initially set to 0 seconds, it will increase by 0.0001 seconds with each iteration. This prevents all messages from starting at the same time. If this happens, many messages will be initially sent simultaneously, causing bus congestion. The message record generation time (Time) is the absolute time at which the system generates each message record. Time is typically initialized to 0 and increments with each message record, based on the message cycle and the time offset. The currently pending message is the message currently being processed by the system during the cyclic processing process. In each iteration, the system selects a currently pending message from all checksums (typically selected in chronological order) and processes it. The rolling signal initial value (Counter) is the starting value of the rolling signal set for the current pending message. At the beginning of message generation, the Counter is set to 0 and is subsequently updated based on the configuration information and rules. The checksum initial value (Checksum) is the starting value of the checksum set for the current pending message. At the beginning of message generation, the Checksum is set to 0 and is subsequently calculated based on the checksum function and data. The period refers to the time interval between the transmission of the current pending message, that is, the interval at which the message is sent. The rolling signal keyword is a specific keyword in the configuration information that identifies the rolling signal in the message. The system uses this keyword to find the corresponding rolling signal in the message. The check signal keyword is a specific keyword in the configuration information that identifies the checksum in the message. The system uses this keyword to find the corresponding checksum in the message. The checksum function is an algorithm or function used to calculate the checksum value based on the data in the message. The total message record generation duration refers to the total time window for generating the message record, that is, the length of time from the start to the end of message record generation. The rolling discontinuous change value refers to the discontinuous change value of the rolling signal when simulating a rolling signal error. For example, if the rolling signal normally increases by 1 each time, then when simulating a discontinuous error, it can be set to increase by 3, 4, or 5, etc. The preset rolling signal threshold is the maximum value of the rolling signal. When the rolling signal value reaches this threshold, it is reset to 0 or specific processing is performed according to the configuration.A preset checksum error value means that during the generation of a checksum message, the system intentionally adds or modifies a specific value to the correct checksum calculation result to simulate a checksum error. For example, in the flowchart, [Checksum = f(dataX, dataY…, dataZ) + 1] indicates adding 1 to the correct checksum calculation result, resulting in an incorrect checksum value. This allows the system to verify whether the controller under test can correctly identify and respond to checksum error messages, ensuring that the controller's diagnostic functions are functioning as expected. By introducing this preset error value, the test can cover the controller's processing logic for incorrect checksum signals, enhancing the comprehensiveness and effectiveness of the test.

[0113] First, the diagnostic test system initializes the time offset to 0 seconds. With each iteration, Δtime increases by 0.0001 seconds. This is used to add a small time interval between each message record generation to prevent all message records from having the same timestamp, simulating the continuous transmission of messages in actual communication and preventing bus congestion. The system also sets the message record generation time to 0, indicating that message record generation begins at this point in time. Second, the system identifies a message from all pending verification messages as the current message to be processed and sets the initial rolling signal value and the initial check signal value to 0 for this message. The system then queries the test configuration information to obtain the relevant parameters of the current pending message, including the message period, rolling signal keyword, check signal keyword, check function, total message record generation time, and rolling discontinuous change value. The system then uses these parameters, along with the Controller Area Network (CAN) communication matrix, to generate a message record for the current pending message, combining the rolling signal initial value, rolling discontinuous change value, preset rolling signal threshold, check signal keyword, check signal initial value, the current pending message, the check function, and the preset check error value. This process is repeated until all the messages to be verified have been processed and the corresponding message records have been generated. Through this cyclic processing, the system can generate detailed message records for each verification message, providing the necessary data for subsequent test playback and diagnostic analysis.

[0114] As an example, after the step of generating a message record of the current message to be processed based on the rolling signal keyword, the controller local area network communication matrix, the test configuration information, the rolling signal initial value, the rolling discontinuous change value, the preset rolling signal threshold, the check signal keyword, the check signal initial value, the current message to be processed, the check function and the preset check error value, it also includes: updating the message record generation time according to the period; when the message record generation time is less than the total message record generation time, returning to the step of generating a message record of the current message to be processed based on the rolling signal keyword, the controller local area network communication matrix, the test configuration information, the rolling signal initial value, the rolling discontinuous change value, the preset rolling signal threshold, the check signal keyword, the check signal initial value, the current message to be processed, the check function and the preset check error value; when the message record generation time is greater than or equal to the total message record generation time, incrementing the time offset to update the time offset, and updating the message record generation time according to the time offset.

[0115] Incremental processing refers to the gradual increase of certain key variables in the process of generating message records to ensure the correct order of message records and the accuracy of timestamps. Specifically, it is the incremental processing of the time offset (Δtime): after each new message record is generated, the time offset Δtime will be incremented by a fixed small value (for example, 0.0001 seconds). This is done to avoid that continuously generated message records have the same timestamp, thereby simulating the continuous transmission of messages in actual communication and preventing bus congestion.

[0116] First, the diagnostic test system adds the transmission cycle (T) of the current pending message to the message record generation time (Time). This is done to simulate the actual transmission interval of messages on the CAN network and ensure that the timestamp of the message record reflects the actual time when the message should be sent. Second, the system checks whether the updated message record generation time (Time) is less than the preset total message record generation time. If so, the system will re-execute the message record generation step and continue to generate the next message record for the same message. This is done to generate a continuous sequence of message records, simulating the continuous message transmission process in actual communication. Finally, if the message record generation time (Time) reaches or exceeds the preset total time, the system increments the time offset (Δtime) and adds the time offset (Δtime) to the message record generation time (Time), where Δtime is increased by 0.0001 seconds. This is done to prepare for the generation of the next message record and ensure that each message record has a unique timestamp, avoiding timestamp conflicts and simulating the transmission time interval of different messages in actual communication. The effect of this process is to generate a series of message records with correct time stamps, which provides accurate time information for subsequent message playback and diagnostic testing, ensuring the accuracy and effectiveness of the test.

[0117] As an example, the step of generating a message record of the current message to be processed based on the rolling signal keyword, the controller local area network communication matrix, the test configuration information, the rolling signal initial value, the rolling discontinuous change value, the preset rolling signal threshold, the check signal keyword, the check signal initial value, the current message to be processed, the check function and the preset check error value includes: obtaining a rolling signal target value based on the rolling signal keyword, the controller local area network communication matrix, the test configuration information, the rolling signal initial value, the rolling discontinuous change value and the preset rolling signal threshold; obtaining a check signal target value based on the check signal keyword, the controller local area network communication matrix, the test configuration information, the check signal initial value, the current message to be processed, the check function and the preset check error value; and generating a message record of the current message to be processed based on the rolling signal target value, the check signal target value and the controller local area network communication matrix.

[0118] The rolling signal target value is calculated based on the rolling signal keyword, the CAN communication matrix, the test configuration, the rolling signal initial value, the rolling discontinuous change value, and the preset rolling signal threshold (the final counter value at the end of each loop). It represents the target value that the rolling signal (RollingCounter) should have for the current message to be processed in each loop. This value simulates the expected increment of the rolling counter when a message is sent in actual CAN communication and is used to ensure the correct order and timing of the messages. For example, if the rolling signal keyword specifies a specific signal in a message, the system will find the signal based on this keyword and calculate the target value of this signal for the current loop according to the rules defined in the test configuration (such as incrementing by 1 each time or generating an error under specific conditions). If the calculated result exceeds the preset rolling signal threshold, the counter value may be reset or adjusted according to specific rules.

[0119] The target value of the check signal is calculated based on the check signal keyword, the controller LAN communication matrix, the test configuration information, the initial value of the check signal, the current message to be processed, the check function, and the preset check error value (the checksum value obtained at the end of each cycle). It represents the target value that the check signal (checksum) should have for the current message to be processed in each cycle (corresponding to each message). This value is used to verify the integrity and correctness of the message and ensure that the message has not been tampered with during transmission. The system will use the check function (which may be CRC, checksum algorithm, etc.) combined with the message content and test configuration information to calculate the target value of the check signal. If the test needs to simulate a check error, the system may add a preset error value (such as +1) to the calculated checksum to generate an incorrect check signal target value.

[0120] First, the diagnostic test system uses the rolling signal keyword to locate the rolling signal of the current pending message in the CAN communication matrix. It then calculates the target rolling signal value for this cycle based on the test configuration, the rolling signal initial value, the rolling discontinuous change value, and the preset rolling signal threshold. This value may be normally increasing or intentionally set to discontinuous based on test requirements to simulate the rolling count during message transmission. Then, the system performs a similar operation using the check signal keyword, combining the CAN communication matrix, the test configuration, the check signal initial value, the content of the current pending message, and the check function to calculate the check signal target value. This value may be correct or may intentionally include a preset checksum error to simulate a checksum failure. Finally, the system generates a message record for the current pending message based on the calculated rolling signal target value and check signal target value, as well as other relevant information in the CAN communication matrix. This record includes all necessary message information, such as timestamps and signal values, for subsequent message playback and diagnostic testing to ensure that actual CAN network communication conditions can be simulated and the controller behavior can be verified.

[0121] As an example, the step of generating a message record of the current message to be processed based on the scrolling signal target value, the check signal target value and the controller local area network communication matrix includes: querying from the controller local area network communication matrix according to the current message to be processed to obtain the parallel signal initial value, scale factor, offset, bit length, byte order and numerical type of the parallel signal in the current message to be processed except the scrolling signal and the check signal; obtaining the conversion relationship between the message original value and the signal value according to the scale factor, the offset, the bit length, the byte order and the numerical type; and generating the message record of the current message to be processed according to the scrolling signal target value, the check signal target value, the parallel signal initial value and the conversion relationship.

[0122] Parallel signals other than rolling and checksum signals refer to signals in CAN messages other than the rolling counter and checksum. These signals typically represent various vehicle status or control information, such as accelerator pedal position and engine speed, such as "VECU_ACCFunctionInhibition_H" and "VECU_AxleTorqueStatus_H." Parallel signal initial values are defined in the DBC file for each parallel signal. These values represent the default state of the signal before receiving actual sensor data or control commands. A scaling factor is a coefficient used to convert the raw value of a signal to a physical value. To save bandwidth on a CAN network, signal values are often transmitted in a scaled form. The scaling factor is used to convert these scaled values to actual physical quantities. For example, multiplying the raw value by the scaling factor yields the actual torque value. An offset is a constant used to adjust the signal value during the conversion process. After applying the scaling factor, the offset is added to the actual physical value of the signal. The offset is used to correct the signal value to ensure that the converted value is physically accurate. The bit length refers to the number of bits a parallel signal occupies within a CAN message. Each signal has a specific position and length within a message. The bit length refers to the number of bits that the signal occupies. For example, a signal might occupy 8, 16, or 32 bits. The byte order refers to the order in which signal values are stored within a message. This is typically related to the system's endianness. The byte order can be big-endian or little-endian. In big-endian, the most significant byte is stored at the lowest memory address, while in little-endian, the most significant byte is stored at the highest memory address. In CAN messages, the byte order determines how signal values are correctly interpreted. The value type refers to the data type of a parallel signal within a message, such as integer, floating-point number, or Boolean. The value type determines how signal values are represented and how mathematical operations can be performed. For example, an integer might represent a sensor's raw count, while a floating-point number might represent a scaled temperature value. The original message value refers to the signal value transmitted in a CAN message. These values are typically scaled and encoded to facilitate transmission within limited bandwidth. The signal value is the physical value obtained by converting the original message value, representing the actual vehicle status or control parameters. The conversion relationship is the mathematical relationship that converts the original message value to the signal value. This usually involves multiplying by a scaling factor and adding an offset. This conversion relationship ensures that the original message value accurately reflects the actual vehicle status or control parameters.

[0123] First, the diagnostic test system will retrieve the detailed properties of all parallel signals (i.e., other signals other than rolling signals and verification signals) from the controller area network communication matrix for the current message to be processed, including the initial value, scale factor, offset, bit length, byte order, and value type of the parallel signal. These properties are pre-defined in the DBC file and are used to describe the storage and representation of each signal. Next, the system will determine the conversion relationship between the original value of the message and the signal value based on these properties. This involves how to extract the original bit stream of the signal from the message and convert it into the actual physical value based on the scale factor and offset, while taking into account the bit length and byte order to correctly parse the signal value. Finally, the system will combine the rolling signal target value, the verification signal target value, and the parallel signal value calculated through the conversion relationship to generate a complete message record for the current message to be processed. This record includes all signal values of the message and is used to simulate actual CAN network communication or for testing and diagnostic purposes. This series of steps ensures that the test system can accurately simulate the behavior of calibration signals and parallel signals in different test scenarios, thereby comprehensively testing the controller's response and processing capabilities to these signals, improving test coverage and effectiveness.

[0124] As an example, the step of obtaining a rolling signal target value according to the rolling signal keyword, the controller local area network communication matrix, the test configuration information, the rolling signal initial value, the rolling discontinuous change value, and the preset rolling signal threshold value includes: obtaining a rolling signal name from the message signal of the controller local area network communication matrix according to the rolling signal keyword; obtaining a rolling error result, a rolling error initial frame sequence number, a rolling error continuous frame number, and a rolling error type from the test configuration information according to the rolling signal name; obtaining a rolling error result, a rolling error initial frame sequence number, a rolling error continuous frame number, and a rolling error type according to the rolling error initial frame sequence number and the rolling error continuous frame number; obtaining a rolling error result, a rolling error result, a rolling error result, a rolling error result, a rolling error result, a rolling error result, and a rolling error type according to the rolling error result, a rolling error result, a rolling error result, and a rolling error result The scroll error end frame number; when the scroll error result is yes and the scroll error type is unchanged, the scroll signal initial value is used as the scroll signal target value; when the scroll error result is yes and the scroll error type is discontinuous, the scroll signal target value is obtained according to the scroll discontinuous change value and the scroll signal initial value; when the scroll error result is no, the scroll signal initial value is incremented to obtain the scroll signal target value; when the scroll signal target value is greater than the preset scroll signal threshold, the scroll signal initial value is used as the scroll signal target value.

[0125] The rolling signal name refers to the name of the specific signal found in the controller LAN communication matrix based on the rolling signal keyword. This name is used to identify the rolling counter signal in the message. The rolling error result is a Boolean value that indicates whether the rolling signal error needs to be simulated in the test. If the rolling error result is "yes", it means that the rolling signal error needs to be simulated. The rolling error initial frame number refers to the message frame number specified in the test configuration information at which the simulation of the rolling signal error begins. The rolling error continuous frame number refers to the number of frames specified in the test configuration information at which the rolling signal error needs to be simulated continuously. The rolling error type refers to the rolling signal error type specified in the test configuration information, which can be "unchanged" (the rolling signal remains constant during the error period) or "discontinuous" (the rolling signal does not increase as expected during the error period). The rolling error end frame number refers to the frame number obtained by adding the rolling error start frame number to the rolling error continuous frame number, indicating the end position of the rolling signal error simulation.

[0126] First, the diagnostic test system uses the rolling signal keyword to retrieve the specific name of the rolling signal in the CAN communication matrix. This step is to accurately find and identify the rolling counter signal in the message. Second, based on the rolling signal name, the system queries the test configuration information for relevant parameters for the rolling error, including whether to simulate an error, the starting frame number of the error, the number of consecutive frames, and the error type. These parameters guide the system in simulating the error behavior of the rolling signal. The system then calculates the ending frame number of the rolling error, which helps determine which message segment should contain the rolling signal error during the test. If the rolling error result is "yes", the system sets the rolling signal target value based on the rolling error type. For the "unchanged" type, the initial value remains unchanged; for the "discontinuous" type, the initial value is combined with a preset discontinuous change value to simulate the error. If the rolling error result is "no", the system simply increments the initial rolling signal value to simulate normal rolling signal increment behavior. Finally, in either case, if the calculated rolling signal target value exceeds the preset rolling signal threshold, the system resets the rolling signal target value to the initial value to ensure that the rolling signal is within the valid range. The effect of this series of steps is to ensure that the test system can accurately simulate the behavior of the rolling signal in different test scenarios, including normal and error conditions, thereby comprehensively testing the controller's response and processing capabilities to the rolling signal, improving the coverage and effectiveness of the test.

[0127] As an example, the step of obtaining a check signal target value based on the check signal keyword, the controller local area network communication matrix, the test configuration information, the check signal initial value, the current message to be processed, the check function, and a preset check error value includes: obtaining a check signal name from the check signal of the controller local area network communication matrix according to the check signal keyword; obtaining a check error result, a check error initial frame number, a check error continuous frame number, and a check error type from the test configuration information according to the check signal name; obtaining a check error end frame number based on the check error initial frame number and the check error continuous frame number; when the check error result is yes, obtaining a check signal target value based on the current message to be processed, the check signal initial value, the check function, and the preset check error value; when the check error result is no, obtaining a check signal target value based on the current message to be processed, the check signal initial value, and the check function.

[0128] The check signal name refers to the name of the specific signal found in the Controller Area Network (CAN) communication matrix using the check signal keyword. This name is used to identify the check signal in the message, such as the checksum or cyclic redundancy check (CRC). The check error result is a Boolean value that indicates whether a check signal error needs to be simulated during the test. If the check error result is "yes," it indicates that a check error simulation is required. The check error initial frame number refers to the message frame number specified in the test configuration information at which the check signal error simulation begins. The check error consecutive frame number refers to the number of frames specified in the test configuration information at which the check signal error simulation needs to be continuously simulated. The check error type refers to the check signal error type specified in the test configuration information. This typically includes the type of error value or the method by which the error was introduced. The check error end frame number refers to the frame number obtained by adding the check error initial frame number to the check error consecutive frame number, indicating the end position of the check signal error simulation.

[0129] First, the diagnostic test system retrieves the specific name of the check signal in the controller LAN communication matrix through the check signal keyword, such as "EMS_CheckSum_EMS_P3_H", in order to accurately identify the position of the check signal in the message; secondly, based on this check signal name, the system queries the test configuration information to determine whether it is necessary to simulate a check error, the starting frame number of the check error, the number of consecutive frames, and the error type. This information guides the system on how to simulate the error behavior of the check signal, such as whether it is necessary to introduce a check error in a specific frame; then, the system calculates the end frame number of the check error, which is obtained by adding the initial frame number of the check error to the number of consecutive frames, and is used to determine the end frame of the check error simulation; if the check error result is "yes", the system will The system calculates the target value of the check signal based on the content of the processed message, the initial value of the check signal, the check function, and the preset check error value. This usually involves adding a preset error value, such as +1, +2, etc., to the correct checksum to simulate a check error. If the check error result is "no", the system calculates the target value of the check signal based on the current message to be processed, the initial value of the check signal, and the check function to generate a correct checksum. Finally, this series of steps ensures that the test system can accurately simulate the behavior of the check signal in different test scenarios, including normal and error conditions, thereby comprehensively testing the controller's response and processing capabilities to the check signal, improving the test coverage and effectiveness, ensuring that the controller can accurately detect and report faults in actual vehicle operation, and improving the reliability and safety of the system.

[0130] This embodiment parses the CAN database file to obtain a CAN communication matrix; retrieves all verification messages from the CAN communication matrix based on the rolling signal keyword and verification signal keyword in the test configuration information; and loops through all verification messages to obtain message records for all verification messages. The diagnostic test system first parses the CAN database file to extract the CAN communication matrix. This matrix contains detailed information about all nodes, messages, and signals in the CAN network, providing the test system with a comprehensive view of network communications, enabling it to accurately understand and generate messages compliant with the CAN protocol. Next, the system retrieves the message names to be verified based on the user-defined test configuration information. This allows the test system to verify specific messages, ensuring targeted and effective testing. The system then uses the message names as indexes to retrieve all relevant verification messages from the CAN communication matrix, providing the test system with specific message objects, which are used to generate test cases and simulate communication scenarios. Finally, the system loops through each verification message, generating a message record for each message based on the test configuration. This includes setting timestamps, calculating target values for the rolling and verification signals, and generating the message's original value. This generates a series of detailed message records that can be used for subsequent test playback and diagnostic analysis. Overall, these steps ensure the test system can accurately simulate and generate CAN message records that meet test requirements, improving test automation and accuracy, reducing costs, and ensuring the reliability and safety of vehicle electronic systems.

[0131] For example, in order to help understand the implementation process of the test method for the controller area network diagnostic fault code obtained by combining this embodiment with the above embodiment 1, please refer to Figure 3 , Figure 3 A brief flowchart of a method for testing Controller Area Network (CAN) diagnostic trouble codes is provided. Specifically:

[0132] The figure shows the detailed process for generating and processing CAN message records. The process begins with initialization, setting the time (Time = 0), and then querying the configuration file for all checksum messages. For each message, the system determines whether to process the DBC file or configuration file to obtain detailed message information and test configuration. Next, the system processes the rolling signal and checksum signal, determining whether to generate an error, the error type, and the number of frames it lasts based on the test configuration. If a rolling error is required, the system adjusts the rolling signal value based on the error type. For the checksum signal, the system calculates the target value for the checksum signal using a checksum function and a preset error value. The system then generates a message record for the current message to be processed based on the rolling signal target value, the checksum target value, and the initial values, scaling factors, and offsets of other signals. After the message record is generated, the system updates the time (Time = Time + T) and determines whether the total message record generation time has been reached. If the time limit is not reached, the system proceeds to the next message. If it is, the system updates the time offset (Δtime = Δtime + 0.0001) and continues generating message records until all messages have been processed. Finally, the system sorts the generated message records by time and generates an ASC-formatted file, completing the entire test process. This process ensures that the test system can accurately simulate and generate CAN message records that meet test requirements, providing the necessary data for subsequent test execution and results analysis, thereby improving test automation and accuracy, reducing costs, and ensuring the reliability and safety of vehicle electronic systems.

[0133] It should be noted that the above examples are only used to understand this application and do not constitute a limitation on the test method of the controller local area network diagnostic fault code of this application. More forms of simple transformations based on this technical concept are all within the scope of protection of this application.

[0134] This application also provides a test device for Controller Area Network Diagnostic Fault Codes, please refer to Figure 4 , the test device for the controller area network diagnostic trouble code comprises:

[0135] Data acquisition module 10, used to obtain controller area network database files and test configuration information;

[0136] A message recording module 20, configured to generate message records of all verification messages according to the test configuration information and the CAN database file;

[0137] A message record file generating module 30 is used to sort the message records by time and generate a message record file according to a preset file format;

[0138] The diagnostic module 40 is configured to replay the message record file through a controller area network tool and, while replaying the data, send a diagnostic request message to the controller under test through the controller area network tool to obtain a diagnostic fault code;

[0139] The testing module 50 is configured to compare the diagnostic trouble code with a preset expected diagnostic trouble code to obtain a test result.

[0140] In one embodiment, the message recording module 20 is further configured to parse the CAN database file to obtain a CAN communication matrix; query the CAN communication matrix to obtain all verification messages based on the rolling signal keyword and the verification signal keyword in the test configuration information; and perform cyclic processing on all the verification messages to obtain message records of all the verification messages.

[0141] In one embodiment, the message recording module 20 is further used to set a time offset and a message record generation time; determine the current message to be processed from all the verification messages; set a rolling signal initial value and a verification signal initial value; query and obtain the period, rolling signal keyword, verification signal keyword, verification function, total message record generation time and rolling discontinuous change value of the current message to be processed from the test configuration information; generate a message record of the current message to be processed based on the rolling signal keyword, the controller LAN communication matrix, the test configuration information, the rolling signal initial value, the rolling discontinuous change value, the preset rolling signal threshold, the verification signal keyword, the verification signal initial value, the current message to be processed, the verification function and the preset verification error value; return to the step of determining the current message to be processed from all the verification messages until the message records of all the verification messages are obtained.

[0142] In one embodiment, the message recording module 20 is further used to update the message record generation time according to the period; when the message record generation time is less than the total message record generation time, return to the step of generating the message record of the current message to be processed according to the rolling signal keyword, the controller local area network communication matrix, the test configuration information, the rolling signal initial value, the rolling discontinuous change value, the preset rolling signal threshold, the check signal keyword, the check signal initial value, the current message to be processed, the check function and the preset check error value; when the message record generation time is greater than or equal to the total message record generation time, increment the time offset to update the time offset, and update the message record generation time according to the time offset.

[0143] In one embodiment, the message recording module 20 is further used to obtain a rolling signal target value based on the rolling signal keyword, the controller local area network communication matrix, the test configuration information, the rolling signal initial value, the rolling discontinuous change value, and a preset rolling signal threshold; obtain a check signal target value based on the check signal keyword, the controller local area network communication matrix, the test configuration information, the check signal initial value, the current message to be processed, the check function, and a preset check error value; and generate a message record of the current message to be processed based on the rolling signal target value, the check signal target value, and the controller local area network communication matrix.

[0144] In one embodiment, the message recording module 20 is further used to query the controller local area network communication matrix based on the current message to be processed to obtain the parallel signal initial value, scale factor, offset, bit length, byte order and numerical type of the parallel signal in the current message to be processed except the rolling signal and the check signal; obtain the conversion relationship between the message original value and the signal value based on the scale factor, the offset, the bit length, the byte order and the numerical type; and generate a message record for the current message to be processed based on the rolling signal target value, the check signal target value, the parallel signal initial value and the conversion relationship.

[0145] In one embodiment, the message recording module 20 is further used to query the message signal of the controller local area network communication matrix based on the rolling signal keyword to obtain the rolling signal name; query the test configuration information based on the rolling signal name to obtain the rolling error result, the rolling error initial frame number, the rolling error continuous frame number and the rolling error type; obtain the rolling error end frame number based on the rolling error initial frame number and the rolling error continuous frame number; when the rolling error result is yes and the rolling error type is unchanged, use the rolling signal initial value as the rolling signal target value; when the rolling error result is yes and the rolling error type is discontinuous, obtain the rolling signal target value based on the rolling discontinuous change value and the rolling signal initial value; when the rolling error result is no, increment the rolling signal initial value to obtain the rolling signal target value; when the rolling signal target value is greater than a preset rolling signal threshold, use the rolling signal initial value as the rolling signal target value.

[0146] In one embodiment, the message recording module 20 is further used to query the check signal of the controller local area network communication matrix according to the check signal keyword to obtain a check signal name; query the test configuration information according to the check signal name to obtain a check error result, a check error initial frame number, a check error continuous frame number, and a check error type; obtain a check error end frame number according to the check error initial frame number and the check error continuous frame number; when the check error result is yes, obtain a check signal target value according to the current message to be processed, the check signal initial value, the check function, and a preset check error value; when the check error result is no, obtain a check signal target value according to the current message to be processed, the check signal initial value, and the check function.

[0147] In one embodiment, the diagnostic module 40 is further used to replay the message record file through a controller local area network tool; input the replayed message into the controller under test, and send a diagnostic request to the controller under test through a unified diagnostic service protocol, so that the controller under test feeds back response data; and read the diagnostic fault code from the response data through the controller local area network tool.

[0148] The Controller Area Network (CAN) Diagnostic Trouble Code (CTTC) testing device provided in this application utilizes the Controller Area Network (CAN) Diagnostic Trouble Code (CTTC) testing method described in the aforementioned embodiments, resolving the technical issues of existing Controller Area Network (CAN) Diagnostic Trouble Code (CTTC) testing methods, such as poor real-time performance, high reliance on environmental resources, and high technical barriers to entry. Compared to existing technologies, the beneficial effects of the Controller Area Network (CAN) Diagnostic Trouble Code (CTTC) testing device provided in this application are the same as those of the Controller Area Network (CAN) Diagnostic Trouble Code (CTTC) testing method described in the aforementioned embodiments. Other technical features of the Controller Area Network (CAN) Diagnostic Trouble Code (CTTC) testing device are the same as those disclosed in the aforementioned embodiments and are not further elaborated upon here.

[0149] The present application provides a test device for a controller area network diagnostic trouble code, and the test device for a controller area network diagnostic trouble code includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions that can be executed 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 test method for the controller area network diagnostic trouble code in the above-mentioned embodiment one.

[0150] Reference below Figure 5, which shows a schematic diagram of the structure of a test device suitable for implementing the Controller Area Network Diagnostic Trouble Code (CADN) according to an embodiment of the present application. The test device for the Controller Area Network Diagnostic Trouble Code (CADN) according to 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), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 5 The test equipment for the controller area network diagnostic trouble code shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0151] like Figure 5 As shown, the Controller Area Network Diagnostic Trouble Code (CAN) test device 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 based on programs stored in a read-only memory (ROM) 1002 or programs loaded from a storage device 1003 into a random access memory (RAM) 1004. RAM 1004 also stores various programs and data required for the operation of the Controller Area Network Diagnostic Trouble Code (CAN) test device. Processing device 1001, ROM 1002, and RAM 1004 are interconnected 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 I / O interface 1006: input devices 1007 including, for example, a touch screen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, a magnetic tape, hard disk, etc.; and communication devices 1009. Communication devices 1009 can allow the Controller Area Network Diagnostic Trouble Code test device to communicate wirelessly or wired with other devices to exchange data. Although the figure shows a Controller Area Network Diagnostic Trouble Code test device with various systems, it should be understood that it is not required to implement or have all of the systems shown. More or fewer systems may be implemented or have instead.

[0152] In particular, according to the embodiments disclosed in the present application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, the embodiments disclosed in the present application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program comprising 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 via 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.

[0153] The test device for the Controller Area Network Diagnostic Trouble Code provided in this application adopts the test method for the Controller Area Network Diagnostic Trouble Code in the above-mentioned embodiment, which can solve the technical problems of the existing test method for the Controller Area Network Diagnostic Trouble Code, such as poor real-time performance, high dependence on environmental resources, and high technical threshold. Compared with the existing technology, the beneficial effects of the test device for the Controller Area Network Diagnostic Trouble Code provided in this application are the same as the beneficial effects of the test method for the Controller Area Network Diagnostic Trouble Code provided in the above-mentioned embodiment, and the other technical features in the test device for the Controller Area Network Diagnostic Trouble Code are the same as the features disclosed in the method of the previous embodiment, and are not described in detail here. It should be understood that the various parts disclosed in this application can be implemented with hardware, software, firmware, or a combination thereof. In the description of the above-mentioned embodiments, specific features, structures, materials, or characteristics can be combined in an appropriate manner in any one or more embodiments or examples.

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

[0155] The computer-readable storage medium provided in this 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 thereof. 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 thereof. In this embodiment, the computer-readable storage medium may be any tangible medium that contains or stores a program that can be used by or in conjunction 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 thereof. The computer-readable storage medium may be included in a test device for CAN diagnostic trouble codes; or may exist independently without being assembled into the test device for CAN diagnostic trouble codes.

[0156] The above-mentioned computer-readable storage medium carries one or more programs. When the above-mentioned one or more programs are executed by the test equipment of the controller local area network diagnostic fault code, the test equipment of the controller local area network diagnostic fault code: obtains the controller local area network database file and test configuration information; generates message records of all verification messages according to the test configuration information and the controller local area network database file; sorts the message records by time, and generates a message record file according to a preset file format; replays the message record file through the controller local area network tool, and sends a diagnostic request message to the controller under test through the controller local area network tool while replaying the data to obtain a diagnostic fault code; compares the diagnostic fault code with a preset expected diagnostic fault code to obtain a test result.

[0157] The computer program code for performing the operations of the present application can be written 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 can 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 can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computer (for example, using an Internet service provider to connect through the Internet). The modules described in the embodiments of the present application can be implemented by software or by hardware. In some cases, the name of the module does not constitute a limitation on the unit itself.

[0158] The computer-readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the aforementioned Controller Area Network (CAN) Diagnostic Trouble Code (DTC) testing method. This computer-readable storage medium can address the technical issues of existing Controller Area Network (CAN) DTC testing methods, such as poor real-time performance, high reliance on environmental resources, and high technical barriers to entry. Compared to the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the Controller Area Network (CAN) DTC testing method provided in the aforementioned embodiments, and are not further elaborated here.

[0159] The present application also provides a computer program product, including a computer program, which, when executed by a processor, implements the steps of the test method for the controller local area network diagnostic fault code as described above. The computer program product provided by the present application can solve the technical problems of the existing test method for the controller local area network diagnostic fault code, such as poor real-time performance, high dependence on environmental resources, and high technical threshold. 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 test method for the controller local area network diagnostic fault code provided by the above embodiment, and will not be elaborated here. The above description is only part of the embodiments of the present application, and does not limit the patent scope of the present application. All equivalent structural transformations made by using the contents of the present application specification and drawings under the technical concept of the present application, or direct / indirect application in other related technical fields are included in the patent protection scope of the present application.

Claims

1. A method for testing controller area network diagnostic trouble codes, characterized in that: The method comprises: Get the Controller Area Network database file and test configuration information; Generate message records of all verification messages according to the test configuration information and the controller area network database file; Sorting the message records by time and generating a message record file according to a preset file format; Playing back the message record file through a controller area network tool, and sending a diagnostic request message to the controller under test through the controller area network tool while playing back the data, to obtain a diagnostic fault code; The diagnostic trouble code is compared with a preset expected diagnostic trouble code to obtain a test result.

2. The method according to claim 1, wherein The step of generating message records of all verification messages according to the test configuration information and the controller area network database file includes: Parsing the controller area network database file to obtain a controller area network communication matrix; querying and obtaining all verification messages from the controller area network communication matrix according to the rolling signal keyword and the verification signal keyword in the test configuration information; All the verification messages are processed cyclically to obtain message records of all the verification messages.

3. The method according to claim 2, wherein The step of cyclically processing all the verification messages to obtain message records of all the verification messages includes: Set the time offset and message record generation time; Determining a current message to be processed from all the verification messages; Set the initial value of the rolling signal and the initial value of the check signal; Querying and obtaining the period, rolling signal keyword, check signal keyword, check function, total message record generation time, and rolling discontinuous change value of the current message to be processed from the test configuration information; Generate a message record of the current message to be processed according to the rolling signal keyword, the controller area network communication matrix, the test configuration information, the rolling signal initial value, the rolling discontinuous change value, a preset rolling signal threshold, the check signal keyword, the check signal initial value, the current message to be processed, the check function, and a preset check error value; Return to the step of determining the current message to be processed from all the verification messages until the message records of all the verification messages are obtained.

4. The method according to claim 3, wherein After the step of generating a message record of the current message to be processed according to the rolling signal keyword, the controller area network communication matrix, the test configuration information, the rolling signal initial value, the rolling discontinuous change value, the preset rolling signal threshold, the check signal keyword, the check signal initial value, the current message to be processed, the check function and the preset check error value, the further step includes: Updating the message record generation time according to the period; When the message record generation time is less than the total message record generation time, returning to the step of generating the message record of the current message to be processed according to the rolling signal keyword, the controller local area network communication matrix, the test configuration information, the rolling signal initial value, the rolling discontinuous change value, the preset rolling signal threshold, the check signal keyword, the check signal initial value, the current message to be processed, the check function and the preset check error value; When the message record generation time is greater than or equal to the total message record generation time, the time offset is incremented to update the time offset, and the message record generation time is updated according to the time offset.

5. The method according to claim 3, wherein The step of generating a message record of the current message to be processed according to the rolling signal keyword, the controller area network communication matrix, the test configuration information, the rolling signal initial value, the rolling discontinuous change value, the preset rolling signal threshold, the check signal keyword, the check signal initial value, the current message to be processed, the check function, and the preset check error value comprises: Obtaining a rolling signal target value according to the rolling signal keyword, the controller area network communication matrix, the test configuration information, the rolling signal initial value, the rolling discontinuous change value, and a preset rolling signal threshold; Obtaining a target value for a calibration signal according to the calibration signal keyword, the controller area network communication matrix, the test configuration information, the initial value for the calibration signal, the current message to be processed, the calibration function, and a preset calibration error value; A message record of the current message to be processed is generated according to the rolling signal target value, the verification signal target value, and the controller area network communication matrix.

6. The method according to claim 5, wherein The step of generating a message record of the current message to be processed according to the rolling signal target value, the verification signal target value, and the controller area network communication matrix includes: Obtaining, from the controller area network communication matrix according to the current message to be processed, the parallel signal initial value, scale factor, offset, bit length, byte order, and value type of the parallel signals excluding the rolling signal and the check signal in the current message to be processed; Obtaining a conversion relationship between the original value of the message and the signal value according to the scale factor, the offset, the bit length, the byte order, and the value type; A message record of the current message to be processed is generated according to the rolling signal target value, the verification signal target value, the parallel signal initial value and the conversion relationship.

7. The method according to claim 5, wherein The step of obtaining the rolling signal target value according to the rolling signal keyword, the controller area network communication matrix, the test configuration information, the rolling signal initial value, the rolling discontinuous change value and the preset rolling signal threshold comprises: According to the rolling signal keyword, a rolling signal name is obtained by querying the message signal of the controller local area network communication matrix; querying the test configuration information according to the rolling signal name to obtain a rolling error result, a rolling error initial frame number, a rolling error continuous frame number, and a rolling error type; Obtaining a rolling error end frame number according to the rolling error initial frame number and the number of rolling error continuous frames; When the scroll error result is yes and the scroll error type is unchanged, taking the scroll signal initial value as the scroll signal target value; When the scroll error result is yes and the scroll error type is discontinuous, obtaining the scroll signal target value according to the scroll discontinuous change value and the scroll signal initial value; When the scroll error result is no, the scroll signal initial value is incremented to obtain the scroll signal target value; When the scroll signal target value is greater than a preset scroll signal threshold, the scroll signal initial value is used as the scroll signal target value.

8. The method according to claim 5, wherein The step of obtaining a target value of the verification signal according to the verification signal keyword, the controller area network communication matrix, the test configuration information, the initial value of the verification signal, the current message to be processed, the verification function, and a preset verification error value comprises: According to the verification signal keyword, a verification signal name is obtained by querying the verification signal of the controller local area network communication matrix; querying the test configuration information according to the check signal name to obtain a check error result, a check error initial frame number, a check error continuous frame number, and a check error type; Obtaining a check error end frame sequence number according to the check error initial frame sequence number and the number of check error consecutive frames; When the check error result is yes, obtaining a check signal target value according to the current message to be processed, the check signal initial value, the check function and a preset check error value; When the check error result is no, a check signal target value is obtained according to the current message to be processed, the check signal initial value and the check function.

9. The method according to any one of claims 1 to 8, characterized in that The step of replaying the message record file through the controller area network tool and sending a diagnostic request message to the controller under test through the controller area network tool while replaying the data to obtain a diagnostic fault code includes: Playing back the message record file through a controller area network tool; Inputting the replayed message into the controller under test, and sending a diagnostic request to the controller under test through a unified diagnostic service protocol, so that the controller under test feeds back response data; The diagnostic trouble code is read from the response data through the controller area network tool.

10. A test device for Controller Area Network Diagnostic Fault Codes, characterized in that: The device comprises: Data acquisition module, used to obtain controller local area network database files and test configuration information; A message recording module, configured to generate message records of all verification messages according to the test configuration information and the controller area network database file; A message record file generating module, used to sort the message records by time and generate a message record file according to a preset file format; a diagnostic module, configured to replay the message record file through a controller area network tool, and simultaneously send a diagnostic request message to the controller under test through the controller area network tool to obtain a diagnostic fault code; The test module is used to compare the diagnostic trouble code with a preset expected diagnostic trouble code to obtain a test result.

Images