Automatic test verification method for communication loss DTC, electronic equipment and storage medium

Abstract

The invention relates to the technical field of whole vehicle test and diagnosis, in particular to an automatic test verification method for communication loss DTC, electronic equipment and a storage medium. By creating a CANoe automatic test project, the running condition of the diagnosis monitoring function of the controller is met, the time condition of sending and losing of related communication messages is simulated, the DTC report condition and the curing condition are verified, automatic test verification of communication DTC of each controller is achieved, and the problems that communication loss DTC verification is difficult, the verification time is long, and the verification precision is not enough are solved. And automatic test verification of communication loss DTC of each controller in an automobile is realized.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of whole vehicle testing and diagnosis, in particular to an automatic test verification method for communication loss DTC, an electronic device and a storage medium. BACKGROUND

[0002] With the development of electricization, intelligentization and networking of automobiles, the number of controllers of newly developed vehicle models has increased several times compared with the past. After the number of automobile controllers increases, the communication between different controllers becomes more complex. In addition, with the widespread application of UDS protocol in the current automobile industry, the number of communication loss DTCs, which monitor the communication messages between different controllers, increases exponentially, so the workload of testing and verifying related communication loss DTCs also increases by several times.

[0003] In the past, when the number of communication loss diagnostic trouble codes (DTCs) was small, technicians in the field could generally verify the reporting and healing conditions of the DTCs on the vehicle sufficiently and accurately. However, with the increase in the number of communication loss diagnostic trouble codes (DTCs) of new vehicle models and the general shortening of the development cycle, it has become inevitable to realize the automatic test verification of communication loss diagnostic trouble codes (DTCs). Therefore, it is urgent to improve the prior art to solve the above technical defects. SUMMARY

[0004] The present application aims to provide an automatic test verification method for communication loss DTC, an electronic device and a storage medium to solve the problems raised in the background.

[0005] To achieve the above-mentioned purpose, the present application provides the following technical solutions: An automatic test verification method for communication loss DTC, comprising the following steps: S101, constructing a test environment, connecting the to-be-tested controller to the host computer through a communication board card, and controlling the power supply of the to-be-tested controller through the host computer; S201, building an environment for CANoe software, which is used to control the communication board card; S301, constructing an Excel table file containing a parameter configuration table, and filling in the parameter configuration table in the Excel table file; the parameter configuration table in the Excel table file is parsed through an Excel table parsing library function of the CANoe software; S401, realizing automatic test verification of communication loss DTC in the working process of the to-be-tested controller through the CANoe software, simulating the time conditions of related communication message sending and loss to verify the DTC reporting conditions and healing conditions, and generating a report after the test is completed.

[0006] The technical scheme has the following technical effects: The communication loss DTC automatic test verification method of the application significantly improves the efficiency and accuracy of test verification by constructing a test environment, building a CANoe software environment, constructing an Excel table file, and using CANoe software for automatic test verification. Specifically, the power supply of the controller under test is controlled by the host computer, and the communication board is controlled by the CANoe software, realizing accurate simulation and test of the communication loss DTC. At the same time, by constructing an Excel table file containing a parameter configuration table and filling and analyzing it, the test verification process is more flexible and configurable. In addition, the application also provides technical solutions of electronic devices and storage media, further expanding the application range and use convenience of the application.

[0007] As a further improvement of the application, the communication board is a 1611 / 1640 model.

[0008] As a further improvement of the application, the controller under test is powered by a program-controlled power supply, and the opening and closing and voltage adjustment of the program-controlled power supply are controlled by the host computer.

[0009] As a further improvement of the application, the method for building the environment of the CANoe software includes the following steps: S21, new TestModule; S22, add.vxt file for displaying test cases; S23, add.Can file, which contains the main CAPL script for realizing test; S24, associate the test cases written in the.CAN file with the test cases in the.vxt file; S25, add OSEK_TP interface library function to realize the transmission and reception of diagnostic messages in the form of CAN TP, and the function functions related to CAN TP in the CAPL language are used through the OSEK_TP interface library function; S26, add Excel table parsing library function to parse the Excel parameter table and obtain the parameters needed for test.

[0010] As a further improvement of the application, the Excel table parsing library function encapsulates the function function with the table parsing function, which is directly called in the CAPL script.

[0011] As a further improvement of the application, the related parameters for filling in the parameter configuration table in step S301 are as follows: DTC Code: Select the communication loss DTC in the DTC List table, 16 hexadecimal; Failure Type: DTC type, 16 hexadecimal; Monitor Message ID: Message ID monitored by the communication loss DTC; Monitor Message Channel: The CAN bus name where the message monitored by the communication loss DTC is located, which is consistent with the definition of the CANoe network name; Monitor Message DLC: The DLC attribute of the message monitored by the communication loss DTC; Monitor Message Period: The message period of the communication loss DTC monitored, unit: ms; Lost Time: The message loss time corresponding to the communication loss DTC, unit: ms; Pass Time: The message recovery time corresponding to the communication loss DTC, unit: ms.

[0012] As a further improvement of the application, the DTC Code is the first 2 bytes of the DTC code, and the Failure Type is the 3rd byte of the DTC code.

[0013] As a further improvement of the application, the communication loss DTC automatic test verification process in step S401 includes the following steps: S41, after clicking the Start button of the CANoe software, realize the DTC monitoring enabling condition through script control, adjust the program-controlled power supply voltage to the working voltage, and send the Power mode=RUN message; S42, simulate the message that does not meet the DTC reporting condition; S43, send the diagnostic message to clear the current controller DTC; D44, after receiving the positive response, send the diagnostic message to read the current and historical DTCs, at this time, the DTC corresponding to the message that does not meet the DTC reporting condition should not be read; S45, stop simulating the sending of the DTC monitoring message; S46, after 2000ms of LostTime time, send the diagnostic message to read the current and historical DTCs, S47, the test case is tested, a report is generated, and if the DTC corresponding to the message that the simulation does not meet the DTC reporting condition is read in step S46, the report shows fail; if not, the report shows Pass.

[0014] An electronic device comprising: at least one processor; and a memory communicatively connected with the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the method of any of the preceding claims.

[0015] A non-transitory computer readable storage medium storing computer instructions, wherein the computer instructions are used to make a computer execute the method of any of the preceding claims. BRIEF DESCRIPTION OF DRAWINGS

[0016] Figure 1 A structural schematic diagram of the overall test environment of the present application; Figure 2 A program schematic diagram of the newly created TestModule in the automated test verification method of the present application; Figure 3 A program schematic diagram of adding a.vxt file in the automated test verification method of the present application; Figure 4 A program schematic diagram of adding a.Can file in the automated test verification method of the present application; Figure 5 A program schematic diagram of adding a test case in the automated test verification method of the present application; Figure 6 A program schematic diagram of adding an OSEK_TP interface library function in the automated test verification method of the present application; Figure 7 A program schematic diagram of adding an Excel table parsing library function in the automated test verification method of the present application; Figure 8 A structural schematic diagram of the parameter configuration table in the automated test verification method of the present application; Figure 9 A test strategy flowchart of the automated test verification method of the present application; Figure 10 A test report display diagram in embodiment 1 of the automated test verification method of the present application. DETAILED DESCRIPTION

[0017] The present application will be described in detail below with reference to the accompanying drawings and in conjunction with embodiments. It should be noted that the embodiments in the present application and the features in the embodiments can be combined with each other without conflict.

[0018] The following detailed description is exemplary in nature and is intended to provide further description of the application. All technical terms employed herein are intended to have the same meaning as commonly understood by one of ordinary skill in the art to which the application pertains. The terminology used in the present application is for the purpose of describing only the exemplary embodiments of the present application and is not intended to limit the scope of the exemplary embodiments of the present application.

[0019] To facilitate the understanding of the schemes provided by the following embodiments of the present application, before describing the technical schemes provided by the present application, the terms related to the present application are explained as follows: Communication Loss DTC (Diagnostic Trouble Code): A fault code used in automotive electronic systems to diagnose communication faults. When communication between controllers is interrupted or abnormal, the system generates a specific DTC to record fault information.

[0020] CANoe (CAN Open Environment): A tool software for automotive electronic system development, testing and simulation, supporting CAN, LIN and other bus protocols, capable of realizing automatic testing, simulation and diagnosis functions.

[0021] CAPL (CAN Access Programming Language): A programming language designed for CANoe, used to write scripts to control and simulate the communication behavior of automotive electronic systems UDS (Unified Diagnostic Services): Unified Diagnostic Services protocol, a widely used standardized diagnostic protocol in the automotive industry, defines the format and content of diagnostic requests and responses, used to monitor and maintain vehicle electronic systems.

[0022] OSEK_TP: OSEK standard-based transport protocol function library, used to realize segmented transmission and recombination of diagnostic messages, ensuring the reliability of data transmission on CAN bus.

[0023] Excel table analysis library function: encapsulates the function module of reading and analyzing Excel files, which can extract key information such as DTC code, message ID, etc. in the parameter configuration table in automated testing.

[0024] DTC Code (Diagnostic Trouble Code): A fault code represented by 16 hexadecimal digits, used to uniquely identify a class of faults. The first two bytes represent the fault category, and the third byte represents the fault type.

[0025] ECU is the abbreviation of "Electronic Control Unit", which is commonly known as "Electronic Control Unit" or "Controller" in Chinese. It is one of the core components in the automotive electronic system, responsible for receiving, processing and executing signals from sensors and other input devices, and controlling corresponding actuators or output devices according to preset logic and algorithms. ECU is widely used in different functional modules of modern cars, such as engine control, transmission control, body control, etc.

[0026] Embodiment 1 As shown in Figure 1 , the present application builds a test environment as shown in Figure 1, in which the ECU to be tested is connected to the host computer through the communication board card 1611 / 1640; the host computer controls the program-controlled power supply to realize opening and closing and voltage adjustment, thereby indirectly controlling the power supply of the ECU to be tested.

[0027] Further, the communication board card 1611 / 1640 realizes control through CANoe software. The environment building of CANoe software includes: S21, new TestModule, as shown in Figure 2; S22, add.vxt file, as shown in Figure 3, only after adding.vxt file can the test case be displayed; S23, add.Can file, the.Can file contains the main CAPL script for realizing the test, as shown in Figure 4; S24, associate the test case written in.CAN file with the test case in.vxt file, as shown in Figure 5; S25, add OSEK_TP interface library function, as shown in Figure 6. It is used to realize the sending and receiving of diagnostic messages in the form of CAN TP, only after adding the library function, the function functions related to CAN TP in CAPL language can be used; S26, add Excel table parsing library function. As shown in Figure 7. It is used to parse the Excel parameter table to obtain the parameters needed for the test. This function library encapsulates the function functions with table parsing function, which can be directly called in CAPL script.

[0028] Further, the filling of parameter configuration table is shown in Figure 8, and the specific related parameter meanings are as follows: DTC Code: Select the communication loss DTC in the DTC List table, 16 hexadecimal; (the first 2 bytes of DTC code) Failure Type: DTC type, 16 hexadecimal; (the 3rd byte of DTC code) Monitor Message ID: Message ID monitored by the communication loss DTC; Monitor Message Channel: The name of the CAN bus where the communication loss DTC monitoring message is located. It must be consistent with the definition of the CANoe network name. Monitor Message DLC: The DLC attribute of the message monitored by the Communication Loss Control Center (DTC). Monitor Message Period: The message period monitored by the Communication Loss Control (DTC) in milliseconds. Lost Time: The time the message was lost corresponding to the Communication Loss TC (DTC), in milliseconds (ms). Pass Time: The time required to recover the message corresponding to the communication loss DTC, in milliseconds.

[0029] Furthermore, the DTC (Distributed Communication Troubleshooting) automated testing and verification process, such as... Figure 9 As shown, it includes the following steps: S41. After clicking the Start button in the CANoe software, use scripts to control the DTC monitoring enable conditions, such as adjusting the programmable power supply voltage to 12.5V and sending a Power mode = RUN message; start the CANoe software and set the DTC monitoring enable conditions: The operation begins with clicking the "Start" button in the CANoe software. This button is the starting point for the entire process, triggering a series of subsequent automated operations. The DTC (Diagnostic Trouble Code) monitoring enable conditions are implemented through script control. Specific operations include adjusting the programmable power supply voltage to 12.5V. This step simulates a specific hardware power supply environment, ensuring the controller operates at a specific voltage, as the power supply voltage can affect the controller's operating status and the generation and detection of DTCs. Simultaneously, a "Power mode = RUN" message is sent. This message sets the controller's operating mode to "RUN," putting the controller in normal operating condition for subsequent DTC-related operations.

[0030] S42. Simulate messages that do not meet the DTC reporting conditions, such as 0xC2A in Figure 8. The purpose of simulating this message is to simulate a scenario that does not meet the DTC reporting conditions, in preparation for subsequent checks on DTC clearing and reading operations. By setting up this special scenario, we can verify whether the system's DTC processing mechanism is correct under different message conditions.

[0031] S43, send diagnostic message 0x14 FF FF FF to clear DTC of current controller; the function of this diagnostic message is to clear the DTC stored in the current controller. "0x14" is diagnostic service identifier, which is used to indicate the operation of clearing DTC, while "FF FFFF" can be parameters related to specific controller or operation, the specific meaning needs to be determined according to the relevant diagnostic protocol. This step is to ensure that when reading DTC later, it can be verified whether the system successfully clears the relevant DTC that may exist before.

[0032] S44, after receiving the positive response, send diagnostic message 0x19 02 09 to read current and historical DTC, at this time the DTC 0xD8C8-87 corresponding to the 0xC2A message should not be read; the expected result is that at this time the DTC 0xD8C8-87 corresponding to the 0xC2A message should not be read. This is because the DTC clearing operation has just been performed, and the 0xC2A message itself is set to not meet the reporting condition, so under normal circumstances the DTC should not be read, so as to verify the effectiveness of the DTC clearing operation.

[0033] S45, stop simulating sending the message of DTC monitoring, such as 0xC2A in FIG. 8; stop simulating sending the message of DTC monitoring, here refers to the 0xC2A message in Figure 8 Stop simulating the message is to change the system state, in order to prepare for the re-occurrence of DTC for subsequent checking.

[0034] After the "LostTime" time 2000ms, set this time delay is to simulate the time-related DTC detection mechanism that may exist in the actual system. After this period of time, the system state may change, and the DTC may reappear because some conditions are met.

[0035] S46, after the LostTime time 2000ms, send diagnostic message 0x19 02 09 to read current and historical DTC, at this time the DTC 0xD8C8-87 corresponding to the 0xC2A message should be read; because after a period of time, the system state changes, the previously set conditions may make the DTC meet the reporting condition, so it can be read, so as to verify the detection mechanism of the system for DTC under different time and state.

[0036] S47, the test case of this test is ended, and the report is generated as shown in FIG. 10, if the DTC 0xC2A corresponding to the 0xC2A message is read in the first If DTC 0xC8-87 is read in the step, the report shows fail; if not, the report shows Pass. If the DTC is read, the report shows "fail", indicating that the test is failed, which means that the system may have problems in DTC clearing or detection mechanism; if the DTC is not read, the report shows "Pass", indicating that the system behaves normally in the whole DTC related operation process.

[0037] In summary, the application develops an automatic test engineering for communication loss DTC test through the CANoe tool, greatly reduces the workload of communication loss DTC test, improves the test accuracy, improves the work efficiency, and shortens the product development cycle.

[0038] Those skilled in the art will appreciate that embodiments of the application can be provided as methods, systems, or computer program products. Accordingly, the application can be embodied in the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the application can be embodied in the form of a computer program product on one or more computer-usable storage media (including, but not limited to, disk memory, CD-ROM, optical memory, etc.) having computer usable program code embodied therein.

[0039] The application is described with reference to flowcharts and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the application. It should be understood that each flow and / or block in the flowcharts and / or block diagrams can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing apparatus to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing apparatus produce a device that implements the functions specified in the flowcharts and / or block diagrams. Figure 1 The functions specified in a flow or multiple flows and / or blocks Figure 1 The functions specified in a flow or multiple flows and / or blocks

[0040] These computer program instructions can also be stored in a computer-readable memory that can direct the computer or other programmable data processing apparatus to work in a specific manner, so that the instructions stored in the computer-readable memory produce a manufactured product including instruction devices that implement the functions specified in the flowcharts and / or block diagrams. Figure 1 The functions specified in a flow or multiple flows and / or blocks Figure 1 The functions specified in a flow or multiple flows and / or blocks

[0041] These computer program instructions can also be loaded into a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks. Figure 1 one or more flowcharts and / or blocks Figure 1 one or more flowcharts and / or blocks

[0042] Finally, it should be noted that the above-mentioned embodiments are merely used to illustrate the technical solutions of the present application, rather than limit the technical solutions of the present application. Although the present application has been described in detail with reference to the above-mentioned embodiments, those skilled in the art should understand that the specific embodiments of the present application can be modified or replaced equivalently without departing from the spirit and scope of the present application, and any modification or equivalent replacement without departing from the spirit and scope of the present application should be covered in the protection scope of the claims of the present application.

Claims

1. An automated testing and verification method for Communication Loss Tolerance (DTC), characterized in that, Includes the following steps: S101. Construct a test environment by connecting the controller under test to the host computer via a communication board. The host computer controls the power supply of the controller under test via a control power supply. S201. Set up the environment for CANoe software, which is used to control the communication board. S301. Construct an Excel spreadsheet file containing a parameter configuration table, and fill in the parameter configuration table in the Excel spreadsheet file; the parameter configuration table in the Excel spreadsheet file is parsed using the Excel spreadsheet parsing library function of the CANoe software; S401. The CANoe software is used to perform automated testing and verification of communication loss DTC during the operation of the controller under test. The timing conditions of sending and losing relevant communication messages are simulated to verify the DTC reporting conditions and cure conditions. A report is generated after the test is completed.

2. The automated testing and verification method for Communication Loss Diagnosis (DTC) according to claim 1, characterized in that, The communication board is model 1611 / 1640.

3. The automated testing and verification method for Communication Loss Diagnosis (DTC) according to claim 1, characterized in that, The controller under test is powered by a programmable power supply, and the switching on and off and voltage regulation of the programmable power supply are controlled by the host computer.

4. The automated testing and verification method for Communication Loss Diagnosis (DTC) according to claim 1, characterized in that, The method for setting up the CANoe software environment includes the following steps: S21. Create a new TestModule; S22. Add a .vxt file to display test cases; S23. Add a .Can file, which contains the main CAPL scripts used for testing; S24. Connect the test cases written in the .CAN file with the test cases in the .vxt file; S25. Add OSEK_TP interface library functions to implement the sending and receiving of diagnostic messages in CANTP mode. Through the OSEK_TP interface library functions, the CANTP-related function functions in the CAPL language are used. S26. Add an Excel table parsing library function to parse the Excel parameter table and obtain the parameters to be used in the test.

5. The automated testing and verification method for Communication Loss Diagnosis (DTC) according to claim 4, characterized in that, The Excel table parsing library function encapsulates functionalities that include table parsing capabilities, which can be directly called within the CAPL script.

6. The automated testing and verification method for Communication Loss Diagnosis (DTC) according to claim 1, characterized in that, The relevant parameters to be filled in the parameter configuration table in step S301 are: DTC Code: Select the communication loss DTC from the DTC List, in hexadecimal; Failure Type: DTC type, hexadecimal; Monitor Message ID: The message ID monitored by the Communication Loss Control Center (DTC). Monitor Message Channel: The name of the CAN bus where the communication loss DTC monitored the message, and it should be consistent with the definition of the CANoe network name; Monitor Message DLC: The DLC attribute of the message monitored by the Communication Loss Control Center (DTC). Monitor Message Period: The message period monitored by the Communication Loss Control (DTC) in milliseconds. Lost Time: The time the message was lost corresponding to the Communication Loss TC (DTC), in milliseconds (ms). Pass Time: The time required to recover the message corresponding to the communication loss DTC, in milliseconds.

7. The automated testing and verification method for Communication Loss Diagnosis (DTC) according to claim 6, characterized in that, DTCCode is the first two bytes of the DTC code, and Failure Type is the third byte of the DTC code.

8. The automated testing and verification method for Communication Loss Diagnosis (DTC) according to claim 1, characterized in that, The automated DTC (Distributed Communication Loss) test and verification process in step S401 includes the following steps: S41. After clicking the Start button in the CANoe software, the DTC monitoring enable condition is realized through script control, the programmable power supply voltage is adjusted to the working voltage, and the Power mode=RUN message is sent. S42. Simulate messages that do not meet the DTC reporting conditions; S43. Send a diagnostic message to clear the DTC of the current controller; D44. After receiving a positive response, send a diagnostic message and read the current and historical DTCs. At this time, you should not be able to read the DTCs corresponding to messages that do not meet the DTC reporting conditions in the simulation. S45. Stop simulating the sending of DTC monitoring messages; S46. After a LostTime period of 2000ms, a diagnostic message is sent to read the current and historical DTCs. S47. This test case is completed and a report is generated. If a DTC corresponding to a message that does not meet the DTC reporting conditions is read in step S46, the report will display "fail"; if no DTC is read, the report will display "pass".

9. An electronic device, characterized in that, include: At least one processor; And a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform an automated test and verification method for communication loss DTC according to any one of claims 1 to 8.

10. A non-transitory computer-readable storage medium storing computer instructions, characterized in that, in, The computer instructions are used to cause the computer to execute the automated testing and verification method for communication loss DTC according to any one of claims 1 to 8.

Images