UDS diagnosis automatic test system and method

Abstract

The invention relates to an automatic test system and method for UDS diagnosis, based on a CAN bus technology, Kvaser is used for communicating with a TCU, Labview is used for developing Kvaser-based UDS test software, ECU TEST calls the test software to perform automatic test of the UDS, and meanwhile, joint test of other functions of the TCU is also supported. A test case is written through the EUC TEST, and test software is called to automatically execute the test case, so that automatic testing of an application layer and a network layer of the UDS is realized. The test software can also directly test the application layer and the network layer, and supports the request and data analysis of the application layer service. Through testing and result judgment of continuous frames, flow control frames, time parameters and unknown messages of a network layer, it can be guaranteed that network layer test cases are executed within one minute, and data analysis, report generation and the like are carried out.

Description

Technical Field

[0001] The present application relates to the field of UDS diagnostic testing, and in particular, to a UDS diagnostic automated testing system and method. Background Art

[0002] The UDS (Unified Diagnostic Services) test is a diagnostic communication protocol test performed in the automotive electronic ECU (Electronic Control Unit) environment. It is a key link to ensure efficient and safe operation of the vehicle and is essential in the transmission TCU test.

[0003] Currently, the UDS diagnostic test of TCU is mainly based on the Vector platform, which is mainly based on CANoe's CANdelaStudio and CANoe.Diva plug-ins. CANdelaStudio is used to edit the diagnostic database CDD (CANdela Diagnostic Descriptions) file, and import the diagnostic database file into CANoe.Diva to convert it into a UDS test case file, and then use CANoe to run the test case file generated by CANdiva to perform UDS diagnostic service testing. This solution requires the use of 3 software and related hardware boards from Vector. To obtain software updates and technical support, additional licenses or subscriptions are required, which is costly. In addition, these tools are highly professional, complex to use, and have a long software learning cycle. At the same time, for some specific needs, Vector cannot meet the specific needs of users. Summary of the invention

[0004] In order to overcome at least one deficiency in the prior art, the present application provides a UDS diagnostic automated testing system and method.

[0005] In a first aspect, a UDS diagnostic automation test system is provided, comprising: a host computer, a CAN bus and a TCU; the host computer is provided with a test software based on Labview; the host computer and the TCU communicate via the CAN bus;

[0006] The test software executes the test case. The host computer sends a diagnostic request to the TCU through the CAN bus communication device Kvaser. After receiving the diagnostic request, the TCU gives a diagnostic response. The diagnostic response is sent to the host computer through the CAN bus communication device Kvaser. The test software analyzes the diagnostic response and generates a diagnostic report.

[0007] In one embodiment, the test cases include network layer test cases.

[0008] In one embodiment, the system further includes ECU TEST, ECU TEST writes test cases, ECU TEST calls the test software in the host computer to test other functions of the TCU, and the test software executes the test cases.

[0009] In one embodiment, the host computer sends the diagnostic response to ECU TEST, and ECU TEST analyzes the diagnostic response and generates a diagnostic report.

[0010] In one embodiment, the test cases include application layer test cases.

[0011] In one embodiment, the application layer test case scenario is designed as follows:

[0012] The test item is: the request message length is wrong, and the expected result is: negative response, the NRC code is correct;

[0013] The test item is: prohibit positive response bit test, expected result: no positive response;

[0014] The test items are: requests in different session modes, and the expected results are: different sessions support different services;

[0015] The test item is: invalid sub-function, and the expected result is: correctly identify the invalid sub-function and return the NRC code;

[0016] The test item is: safe mode access, expected result: services that can only be accessed in safe mode need to be unlocked before access;

[0017] Test item: invalid request data, expected result: verify that the DUT makes a corresponding negative response when receiving invalid or undefined data;

[0018] The test item is: invalid DID, expected result: verify that the DUT can identify invalid DID and send a negative response with a negative code of 0x31.

[0019] In a second aspect, a UDS diagnostic automation test method is provided, which is applied to a host computer and includes:

[0020] The test software executes the test cases and sends a diagnostic request to the TCU;

[0021] Receive the diagnostic response returned by the TCU;

[0022] The diagnostic response is analyzed and a diagnostic report is generated.

[0023] In one embodiment, the method further comprises:

[0024] The test software is called by ECU TEST, ECU TEST writes test cases, and the test software executes the test cases.

[0025] In one embodiment, the diagnostic response is sent to ECU TEST, and ECU TEST analyzes the diagnostic response and generates a diagnostic report.

[0026] In one embodiment, the test cases include application layer test cases.

[0027] In one embodiment, the application layer test case scenario is designed as follows:

[0028] The test item is: the request message length is wrong, and the expected result is: negative response, the NRC code is correct;

[0029] The test item is: prohibit positive response bit test, expected result: no positive response;

[0030] The test items are: requests in different session modes, and the expected results are: different sessions support different services;

[0031] The test item is: invalid sub-function, and the expected result is: correctly identify the invalid sub-function and return the NRC code;

[0032] The test item is: safe mode access, expected result: services that can only be accessed in safe mode need to be unlocked before access;

[0033] Test item: invalid request data, expected result: verify that the DUT makes a corresponding negative response when receiving invalid or undefined data;

[0034] The test item is: invalid DID, expected result: verify that the DUT can identify invalid DID and send a negative response with a negative code of 0x31.

[0035] Compared with the prior art, this application has the following beneficial effects:

[0036] 1. This application uses Kvaser to communicate with TCU based on CAN bus technology, and uses Labview to develop UDS test software based on Kvaser. ECU TEST calls the test software to perform automatic testing of UDS, and also supports joint testing of other functions of TCU. Test cases are written through EUC TEST, and the test software is called to automatically execute the test cases, thereby realizing automatic testing of the application layer and network layer of UDS. The test software can also directly perform application layer and network layer tests. The test software supports application layer service requests and data parsing. The test and result judgment of network layer continuous frames, flow control frames, time parameters, and unknown messages can ensure that the network layer test cases are executed within one minute, and data analysis and report generation can be performed.

[0037] 2. The test software supports functions such as message sending and receiving, message parsing, data processing, data storage, message monitoring, and automatic report generation. The test software can complete all currently supported diagnostic service request tests and network layer services. It is applicable to all products that support CAN communication, can monitor original messages, support manual and automatic UDS diagnostic service requests, fault diagnosis, network layer testing, etc.

[0038] 3. This application has been promoted and used in fault diagnosis tests and UDS tests of TCUs such as AT, AMT, and new energy, effectively improving the efficiency of UDS testing, reducing costs, and saving company resources.

[0039] 4. Kvaser has low cost, small size, simple drive, rich resources, self-developed test software, strong scalability and easy maintenance; the test system has a simple structure, convenient operation, low cost, can effectively improve test efficiency, and has strong scalability to support subsequent integration of specific needs. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] The present application may be better understood by referring to the following description given in conjunction with the accompanying drawings, which together with the following detailed description are included in this specification and form a part of this specification. In the drawings:

[0041] Figure 1 Shows the structural block diagram of the UDS diagnostic automation test system;

[0042] Figure 2 A test software flow chart is shown;

[0043] Figure 3 It shows the flow chart of ECU TEST calling the test software. DETAILED DESCRIPTION

[0044] The exemplary embodiments of the present application will be described below in conjunction with the accompanying drawings. For the sake of clarity and conciseness, not all features of the actual embodiments are described in the specification. However, it should be understood that many implementation-specific decisions can be made in the process of developing any such actual embodiments in order to achieve the specific goals of the developer, and these decisions may vary from embodiment to embodiment.

[0045] It is also necessary to explain here that, in order to avoid obscuring the present application due to unnecessary details, only the device structure closely related to the scheme according to the present application is shown in the drawings, while other details that are not closely related to the present application are omitted.

[0046] It should be understood that the present application is not limited to the described implementation forms due to the following description with reference to the accompanying drawings. In this article, where feasible, the embodiments can be combined with each other, features between different embodiments can be replaced or borrowed, and one or more features can be omitted in one embodiment.

[0047] The present application embodiment provides a UDS diagnostic automation test system. Figure 1 The structural block diagram of the UDS diagnostic automated test system is shown. The system includes: a host computer, a CAN bus and a TCU; the host computer is provided with a test software based on Labview; and the host computer and the TCU communicate through the CAN bus.

[0048] Here, the TCU is connected to a power supply, and the power supply supplies power to the TCU, so that the TCU is in working state. Before performing the UDS diagnostic automation test, it is necessary to first establish communication with the TCU. This embodiment communicates based on the CAN bus, and Kvaser is selected as the communication module of the CAN bus. Kvaser provides API functions to facilitate secondary development. Kvaser is a communication device of the CAN bus, which is used to monitor and control the data flow on the CAN bus in real time.

[0049] The test software in the host computer is developed based on Labview, and uses the API function of Kvaser's CANlib to interact with the TCU. The design mode of JKI state machine + queue state machine is used, with a clear framework structure, strong readability, maintainability, and easy extensibility. The event structure in the program is only responsible for generating the state of event occurrence, and the processing of these states is executed by the conditional structure. Each event branch represents a method step, with a clear process, easy expansion and maintenance, and a clear and neat interface. Figure 2 The test software flow chart is shown. As an independent application, the test software can realize automatic testing of the application layer and network layer of the UDS diagnostic service, data analysis, report generation, CAN bus monitoring, etc. It supports custom baud rate, request / response ID, configuration of network layer time parameters, etc. At the same time, the software sets the log window and result export settings, and the tester can view the historical operation records and data records.

[0050] The test software executes the test case. The host computer sends a diagnostic request to the TCU through the CAN bus communication device Kvaser. After receiving the diagnostic request, the TCU gives a diagnostic response. The diagnostic response is sent to the host computer through the CAN bus communication device Kvaser. The test software analyzes the diagnostic response and generates a diagnostic report.

[0051] In this embodiment, the UDS diagnostic automated test system supports the test software to run independently, for example, it is suitable for network layer testing. Table 1 shows the network layer test case scenario design.

[0052] The CAN data link layer supports a maximum of 8 bytes per frame, and there are multi-frame data transmissions in UDS diagnosis. In order to ensure that multi-byte data is effectively and orderly transmitted through the CAN bus, network layer testing is also very necessary. The test system of this embodiment can be used to test the network layer, based on the ISO 15765-2 protocol, to test the validity of network layer time parameters and data when the TCU replies to the diagnostic instrument with multi-frame messages. At the same time, the TCU can effectively parse and respond to multi-frame messages sent from the diagnostic instrument to ensure that the TCU can correctly and effectively receive or send diagnostic information when diagnosing vehicle faults. The test system can perform all 38 network layer test items, support manual single-item testing, and one-click trigger automatic testing, and automatically generate a test report after the test is completed.

[0053] Table 1

[0054]

[0055] In one embodiment, the system further includes ECU TEST, ECU TEST writes test cases, ECU TEST calls the test software in the host computer to test other functions of the TCU, and the test software executes the test cases.

[0056] Here, ECU TEST is used as an automated test tool for Hil simulation. In the prior art, UDS testing using ECU TEST is implemented by calling CANoe. This embodiment develops test software based on Labview, and can call the test software through ECU TEST, combine UDS testing with fault injection, write test cases, and automatically execute them, so as to perform efficient and comprehensive automated testing on the gearbox control software. Figure 3 It shows the flow chart of ECU TEST calling the test software.

[0057] Specifically, the test cases in the above embodiments may be application layer test cases. The test software may verify the TCU application layer services one by one, ensure the availability and correctness of the UDS diagnostic function, and effectively improve the efficiency and accuracy of vehicle fault diagnosis. Table 2 shows the application layer test case scenario design.

[0058] Table 2

[0059]

[0060] Note: DID (Data Identifier) ​​is the data identifier, DUT is the device under test, and NRC (Negative Response Code) is the code used in the Unified Diagnostic Services (UDS) protocol to indicate errors or abnormal conditions, that is, the negative code.

[0061] Further, the host computer sends the diagnostic response to ECU TEST, and ECU TEST analyzes the diagnostic response and generates a diagnostic report. Here, the test software can analyze the diagnostic response and generate a diagnostic report, or send the diagnostic response to ECU TEST, and ECU TEST generates a diagnostic report.

[0062] The present application also provides a UDS diagnostic automation test method, which is applied to a host computer and includes:

[0063] The test software executes the test cases and sends a diagnostic request to the TCU;

[0064] Receive the diagnostic response returned by the TCU;

[0065] The diagnostic response is analyzed and a diagnostic report is generated.

[0066] Furthermore, the method also includes:

[0067] The test software is called by ECU TEST, ECU TEST writes test cases, and the test software executes the test cases.

[0068] Furthermore, the method further includes: sending the diagnostic response to ECU TEST, and ECU TEST analyzing the diagnostic response to generate a diagnostic report.

[0069] The UDS diagnostic automation test method of this embodiment has the same inventive concept as the UDS diagnostic automation test system described above, so the specific implementation of this method can be seen in the embodiment section of the UDS diagnostic automation test system in the previous text, and its technical effects correspond to the technical effects of the above-mentioned method, which will not be repeated here.

[0070] In summary, this application has the following beneficial effects:

[0071] 1. This application uses Kvaser to communicate with TCU based on CAN bus technology, and uses Labview to develop UDS test software based on Kvaser. ECU TEST calls the test software to perform automatic testing of UDS, and also supports joint testing of other functions of TCU. Test cases are written through EUC TEST, and the test software is called to automatically execute the test cases, thereby realizing automatic testing of the application layer and network layer of UDS. The test software can also directly perform application layer and network layer tests. The test software supports application layer service requests and data parsing. The test and result judgment of network layer continuous frames, flow control frames, time parameters, and unknown messages can ensure that the network layer test cases are executed within one minute, and data analysis and report generation can be performed.

[0072] 2. The test software supports functions such as message sending and receiving, message parsing, data processing, data storage, message monitoring, and automatic report generation. This test software can complete all currently supported diagnostic service request tests and network layer services. It is applicable to all products that support CAN communication, can monitor original messages, support manual and automatic UDS diagnostic service requests, fault diagnosis, network layer testing, etc.

[0073] 3. This application has been promoted and used in fault diagnosis tests and UDS tests of TCUs such as AT, AMT, and new energy, effectively improving the efficiency of UDS testing, reducing costs, and saving company resources.

[0074] 4. Kvaser has low cost, small size, simple drive, rich resources, self-developed test software, strong scalability and easy maintenance; the test system has a simple structure, convenient operation, low cost, can effectively improve test efficiency, and has strong scalability to support subsequent integration of specific needs.

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

Claims

1. A UDS diagnostic automated test system, characterized in that: include: A host computer, a CAN bus and a TCU; the host computer is provided with a test software based on Labview; the host computer communicates with the TCU via the CAN bus; The test software executes the test case, the host computer sends a diagnostic request to the TCU through the communication device Kvaser of the CAN bus, the TCU gives a diagnostic response after receiving the diagnostic request, and the diagnostic response is sent to the host computer through the communication device Kvaser of the CAN bus; the test software analyzes the diagnostic response and generates a diagnostic report.

2. The system according to claim 1, characterized in that The test cases include network layer test cases.

3. The system according to claim 1, characterized in that The system further comprises an ECU TEST, wherein the ECU TEST writes test cases, the ECU TEST calls the test software in the host computer to test other functions of the TCU, and the test software executes the test cases.

4. The system according to claim 3, characterized in that The host computer sends the diagnostic response to the ECU TEST, and the ECU TEST analyzes the diagnostic response and generates a diagnostic report.

5. The system according to claim 3, characterized in that The test cases include application layer test cases.

6. The system according to claim 5, characterized in that The application layer test case scenario is designed as follows: The test item is: the request message length is wrong, and the expected result is: negative response, the NRC code is correct; The test item is: prohibit positive response bit test, expected result: no positive response; The test items are: requests in different session modes, and the expected results are: different sessions support different services; The test item is: invalid sub-function, and the expected result is: correctly identify the invalid sub-function and return the NRC code; The test item is: safe mode access, expected result: services that can only be accessed in safe mode need to be unlocked before access; Test item: invalid request data, expected result: verify that the DUT makes a corresponding negative response when receiving invalid or undefined data; The test item is: invalid DID, expected result: verify that the DUT can identify invalid DID and send a negative response with a negative code of 0x31.

7. A UDS diagnostic automation test method, applied to a host computer, characterized in that: include: The test software executes the test cases and sends a diagnostic request to the TCU; Receive the diagnostic response returned by the TCU; The diagnostic response is analyzed to generate a diagnostic report.

8. The method according to claim 1, characterized in that The method further comprises: The test software is called by the ECU TEST, the ECU TEST writes test cases, and the test software executes the test cases.

9. The method according to claim 8, characterized in that The diagnostic response is sent to the ECU TEST, and the ECU TEST analyzes the diagnostic response and generates a diagnostic report.

10. The method according to claim 8, characterized in that The test cases include application layer test cases.

11. The method according to claim 10, characterized in that The application layer test case scenario is designed as follows: The test item is: the request message length is wrong, and the expected result is: negative response, the NRC code is correct; The test item is: prohibit positive response bit test, expected result: no positive response; The test items are: requests in different session modes, and the expected results are: different sessions support different services; The test item is: invalid sub-function, and the expected result is: correctly identify the invalid sub-function and return the NRC code; The test item is: safe mode access, expected result: services that can only be accessed in safe mode need to be unlocked before access; Test item: invalid request data, expected result: verify that the DUT makes a corresponding negative response when receiving invalid or undefined data; The test item is: invalid DID, expected result: verify that the DUT can identify invalid DID and send a negative response with a negative code of 0x31.

Images