Equipment testing method, device and system

Abstract

The invention provides an equipment testing method, device and system, and relates to the field of testing. And the test equipment communicates with the tested equipment in a first communication mode, and the tested equipment communicates with the CAN transceiver in a second communication mode, so that the test of the edge node is realized. During specific testing, the testing device sends a testing instruction corresponding to the testing type to the tested device, the testing instruction comprises testing data, and in the process that the tested device processes the testing data, a generated response message is obtained, verification operation is executed on the response message, and therefore the device testing result of the tested device is determined. In the invention, the response message comprises data transmitted by the tested equipment and the test equipment, and / or data transmitted by the tested equipment and the CAN transceiver, and whether communication between the tested equipment and the test equipment and communication between the tested equipment and the CAN transceiver are normal is analyzed by checking the response message. Therefore, whether the edge node has the capability of correctly converting the message between the DoIP and the DoCAN can be verified.

Description

Technical Field

[0001] The present application relates to the field of testing, and more specifically, to a device testing method, apparatus and system. Background Art

[0002] As the complexity of modern automotive electronic systems increases, the internal communication networks of vehicles have become more diverse. DoIP (Diagnostic over IP, an on-board diagnostic communication protocol based on IP network) and DoCAN (Diagnostic over CAN, an on-board diagnostic communication protocol based on CAN bus) are two commonly used on-board diagnostic communication protocols. DoIP uses IP network as the transport layer, while DoCAN uses CAN bus for data transmission. As a bridge connecting DoIP and DoCAN, the edge node needs to have the ability to correctly convert messages between DoIP and DoCAN.

[0003] In order to ensure that the edge nodes have the above capabilities, the edge nodes need to be tested. How to implement the test is a technical problem that technical personnel in this field need to solve urgently. Summary of the invention

[0004] In view of this, the present application provides a device testing method, apparatus and system to solve the problem of needing to test whether the edge node has the ability to correctly convert messages between DoIP and DoCAN.

[0005] In order to solve the above technical problems, this application adopts the following technical solutions:

[0006] A device testing method is applied to a test device, wherein the test device communicates with the device under test through a first communication mode, and the device under test communicates with a controller area network (CAN) transceiver through a second communication mode; the CAN transceiver is used to simulate multiple CAN nodes;

[0007] The device testing method comprises:

[0008] After establishing a communication connection with the device under test, sending a test instruction corresponding to the test type to the device under test; the test instruction includes test data;

[0009] Acquire a response message generated by the device under test in the process of processing the test data, and perform a verification operation on the response message to determine a device test result of the device under test;

[0010] The response message includes: data transmitted between the device under test and the test device, and / or data transmitted between the device under test and the CAN transceiver.

[0011] Optionally, the test types include: data length diagnostic test;

[0012] Acquiring a response message generated by the device under test in the process of processing the test data, and performing a verification operation on the response message to determine a device test result of the device under test, including:

[0013] When the message length in the test data is greater than the maximum length supported by the CAN transceiver, obtaining a first message output by the device under test to the test device;

[0014] Detecting whether the first message is a negative confirmation message including a too long fault code;

[0015] If so, determine that the test result of the data length diagnostic test of the device under test is a preset test result; the preset test result is an indicator indicating normality.

[0016] Optionally, the test type includes: a physical addressing test or a functional addressing test;

[0017] Obtaining a response message generated by the device under test in the process of processing the test data, including:

[0018] Acquire a second message sent by the device under test to the CAN transceiver in response to the test instruction;

[0019] Acquire a third message sent by the CAN transceiver to the device under test in response to the second message;

[0020] A fourth message is obtained, which is sent by the device under test to the testing device and is obtained by performing address conversion on the third message.

[0021] Optionally, performing a verification operation on the response message to determine a device test result of the device under test includes:

[0022] Verifying whether the target domain in the second message matches the target domain in the test data;

[0023] If they match, verify whether the CAN bus diagnostic request identifier in the second message is the CAN bus diagnostic request identifier corresponding to the CAN node logical address in the test data;

[0024] If so, after determining that the third message is successfully sent to the device under test, verifying the address in the fourth message;

[0025] If the verification is passed, it is determined that the test result of the physical addressing test or the functional addressing test of the device under test is a preset test result; the preset test result is an identification indicating normality.

[0026] Optionally, the test type includes: cache test;

[0027] Obtaining a response message generated by the device under test in the process of processing the test data, including:

[0028] When the message length in the test data is equal to the maximum length of the register of the device under test, a fifth message sent by the device under test to the CAN transceiver is obtained.

[0029] Optionally, performing a verification operation on the response message to determine a device test result of the device under test includes:

[0030] By analyzing the fifth message, determining whether the device under test uses a CAN bus multi-frame transmission mode for data transmission;

[0031] If the CAN bus multi-frame transmission mode is adopted for transmission, verify whether the target domain and the CAN bus diagnostic request identifier in the fifth message are correct;

[0032] If all are correct, it is determined that the test result of the buffer test of the device under test is a preset test result; the preset test result is an indicator indicating that it is normal.

[0033] Optionally, the test type includes: an error forwarding test;

[0034] Obtaining a response message generated by the device under test in the process of processing the test data, including:

[0035] Acquire a sixth message sent by the device under test to the CAN transceiver;

[0036] Acquire a seventh message sent by the CAN transceiver to the device under test in response to the sixth message;

[0037] A first response result sent by the device under test to the CAN transceiver and a second response result sent by the device under test to the test device are obtained.

[0038] Optionally, performing a verification operation on the response message to determine a device test result of the device under test includes:

[0039] Verifying whether the target domain in the sixth message matches the target domain in the test data;

[0040] If they match, verify whether the CAN bus diagnostic request identifier in the sixth message is the CAN bus diagnostic request identifier corresponding to the CAN node logical address in the test data;

[0041] If it is a CAN bus diagnostic request identifier corresponding to the CAN node logical address in the test data, when the message length in the seventh message is equal to the maximum length of the register of the device under test, determine whether the first response result is a flow control frame including an overflow identifier;

[0042] If it is a flow control frame including an overflow flag, determining whether the second response result is a negative confirmation message including a preset error fault code, and whether the second response result does not include the message data in the seventh message;

[0043] If the second response result is a negative confirmation message including a preset error fault code, and the second response result does not include the message data in the seventh message, it is determined that the test result of the error forwarding of the device under test is a preset test result; the preset test result is an identification indicating normality.

[0044] A device testing apparatus is applied to a testing device, wherein the testing device communicates with a device under test through a first communication mode, and the device under test communicates with a controller area network (CAN) transceiver through a second communication mode; the CAN transceiver is used to simulate multiple CAN nodes;

[0045] The equipment testing device comprises:

[0046] An instruction sending module, used for sending a test instruction corresponding to the test type to the device under test after establishing a communication connection with the device under test; the test instruction includes test data;

[0047] A test module, used to obtain a response message generated by the device under test in the process of processing the test data, and perform a verification operation on the response message to determine a device test result of the device under test;

[0048] The response message includes: data transmitted between the device under test and the test device, and / or data transmitted between the device under test and the CAN transceiver.

[0049] A device testing system includes a device for performing the above-mentioned test, and also includes: a device under test and a CAN transceiver;

[0050] The device under test is used to perform an operation corresponding to the test data in the test instruction;

[0051] The CAN transceiver is used to perform interactive operations with the device under test during the process of the device under test performing the operation.

[0052] The present application provides a device testing method, apparatus and system, wherein the test device communicates with the device under test through a first communication mode, and the device under test communicates with a CAN transceiver through a second communication mode to implement the testing of edge nodes. During a specific test, the test device sends a test instruction corresponding to the test type to the device under test, and the test instruction includes test data. During the process of the device under test processing the test data, the generated response message is obtained, and a verification operation is performed on the response message to determine the device test result of the device under test. In the present invention, the response message includes the data transmitted between the device under test and the test device, and / or the data transmitted between the device under test and the CAN transceiver. By verifying the response message, it is analyzed whether the communication between the device under test, the test device and the CAN transceiver is normal, so as to verify whether the edge node has the ability to correctly convert the messages between DoIP and DoCAN. BRIEF DESCRIPTION OF THE DRAWINGS

[0053] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the related technologies, the drawings required for use in the embodiments or the related technical descriptions are briefly introduced below. Obviously, the drawings described below are merely embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying any creative work.

[0054] Figure 1 A schematic diagram of the structure of a device testing system provided by an embodiment of the present invention;

[0055] Figure 2 A flow chart of a device testing method provided by an embodiment of the present invention;

[0056] Figure 3 A flow chart of a device testing process provided by an embodiment of the present invention;

[0057] Figure 4 Another device testing process flow chart provided by an embodiment of the present invention;

[0058] Figure 5 A schematic diagram of the structure of a device testing apparatus provided by an embodiment of the present invention;

[0059] Figure 6 A schematic diagram of the structure of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0060] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0061] In order to enable those skilled in the art to more clearly understand the present invention, the professional terms in the present invention are now explained.

[0062] DoIP (Diagnostic over IP, an on-board diagnostic communication protocol based on IP network) is mainly used for remote diagnosis and maintenance.

[0063] DoCAN (Diagnostic over CAN, an on-board diagnostic communication protocol based on the CAN (Controller Area Network, a field bus standard for real-time applications) bus): mainly used for internal vehicle diagnosis.

[0064] DUT (Device Under Test): Test object, here refers to the edge node.

[0065] NACK: Negative Acknowledgement, used to indicate that the received data packet has errors or cannot be processed.

[0066] ACK: Positive Acknowledgement, used to confirm that the data packet has been received correctly.

[0067] TCP (Transmission Control Protocol): Transmission Control Protocol is a connection-oriented, reliable, byte stream-based transport layer communication protocol.

[0068] FF_DL (First Frame Data Length): First frame data length, used to indicate the total length of single-frame or multi-frame transmission.

[0069] FS (Flow Status): Flow status, used to control the rate of multi-frame transmission.

[0070] NRC (Negative Response Code): Negative response code, used to report problems during multi-frame transmission.

[0071] As the complexity of modern automotive electronic systems increases, the internal communication networks of vehicles have become more diverse. DoIP and DoCAN are two commonly used on-board diagnostic communication protocols. DoIP uses the IP network as the transport layer, while DoCAN uses the CAN bus for data transmission. As a bridge connecting DoIP and DoCAN, the edge node needs to have the ability to correctly convert messages between DoIP and DoCAN.

[0072] In order to ensure that the edge nodes have the above capabilities, the edge nodes need to be tested. How to implement the test is a technical problem that technical personnel in this field need to solve urgently.

[0073] In order to verify the performance of various functions of edge nodes in the DoIP-DoCAN environment, a device testing system was built, which mainly includes test equipment (including PC (Personal Computer) configured with test software and test terminal Tester), device under test (generally edge node), and in-vehicle CAN node simulated by CAN transceiver. The test content covers DoIP message processing, conversion function from logical address to CAN diagnostic ID (Identity document), response mechanism of diagnostic request, etc. Through these tests, it can be ensured that the device under test can work correctly in accordance with the DoIP-065 part of the ISO 13400 standard. Ensuring that the device under test can meet the DoIP-DoCAN communication requirements includes but is not limited to routing activation, diagnostic request processing, logical address resolution and other functions.

[0074] Based on the above content, an embodiment of the present invention provides a device testing method, which is applied to a testing device, wherein the testing device is a testing device in a device testing system, and Figure 1 , the equipment test system includes:

[0075] Test equipment, device under test, and CAN transceiver.

[0076] Test equipment includes Figure 1 In the actual application, the PC and the Tester communicate through a USB (Universal Serial Bus) line. The PC is used to execute the test process and output the output data to the device under test through the Tester for testing.

[0077] The device under test refers to the test object DUT mentioned above, which generally refers to the edge node. In general, in actual testing, each edge node is tested separately. After one edge node is tested, the next edge node is tested. The edge node is powered by a programmable power supply (Power supply), which can also provide activation voltage for the edge node. The programmable power supply is connected to the edge node through KL30, KL15 and Active line.

[0078] In the present invention, since there are a large number of CAN nodes, in order to save a plurality of resources, the CAN transceiver is used to simulate a plurality of CAN nodes, instead of directly using the CAN nodes for testing.

[0079] It should be noted that Figure 1 Only one CAN transceiver is drawn for schematic illustration. In actual scenarios, multiple CAN transceivers can be configured according to the capabilities of the CAN transceivers.

[0080] Tester communicates with edge nodes through DoIP (including TD+, TD-, RD+, and RD-). Before communication, a TCP connection between Tester and edge nodes needs to be established. The edge node is then connected to the CAN transceiver through the CAN bus using the DOCAN communication method (including CAN_H and CAN_L).

[0081] During the test, the diagnostic request and response process of the embodiment of the present invention is as follows:

[0082] The test device sends a diagnostic request to the edge node through DoIP. The edge node converts the request into DoCAN format and forwards it to the CAN transceiver. After the CAN transceiver processes the request, it returns a DoIP response to the test device through the edge node.

[0083] In addition, the embodiment of the present invention is also configured with an error handling mechanism. Specifically, when the length of the diagnostic data exceeds the CAN network limit, the edge node should send a NACK and prevent abnormal data transmission.

[0084] Reference Figure 2 , the device testing method in the embodiment of the present invention may include:

[0085] S11. After establishing a communication connection with the device under test, sending a test instruction corresponding to the test type to the device under test.

[0086] Wherein, the test instruction includes test data.

[0087] Specifically, in order to implement the test of the device under test, the present invention needs to pre-establish a communication connection between the testing device and the device under test.

[0088] The process of establishing a communication connection is:

[0089] (1) The device under test is powered on by a programmable power supply, and the activation line voltage is 5V. The device under test works normally after powering on.

[0090] (2) The test device establishes a TCP connection with the device under test (such as an edge node), and the device under test replies with a response message for establishing a TCP connection. It should be noted that in this embodiment, the Tester in the test device establishes a TCP connection with the device under test.

[0091] (3) The test device sends a routing activation request to verify whether the device under test replies with a routing activation response and the response code is 0x10 (activation successful).

[0092] Specifically, the routing activation request sent by the test device is:

[0093] 0x02 0xFD 0x00 0x05 0x00 0x00 0x00 0x07 SA 0x00 0x00 0x00 0x00 0x00

[0094] Among them, SA is a 2-byte diagnostic device logical address, specifically refers to the logical address of the Tester.

[0095] The route activation response from the device under test is:

[0096] 0x02 0xFD 0x00 0x06 0x00 0x00 0x00 0x09 TL DL 0x10 0x00 0x00 0x000x00

[0097] Among them, TL is the 2-byte logical address of the diagnostic device; DL is the 2-byte logical address of the device under test.

[0098] When the route activation response returned by the device under test is correct, the test operation starts.

[0099] The tests in the embodiments of the present invention are divided into multiple test types, and the test types can be as follows:

[0100] Data length diagnostic test, physical addressing test, functional addressing test, buffer test, error forwarding test.

[0101] The data length diagnostic test is used to diagnose whether the data length exceeds the network limit. When the diagnostic data length exceeds the maximum supported length (4095 bytes) of the CAN network transmission protocol, the edge node should be able to identify and correctly handle this situation to prevent communication failures caused by data overflow.

[0102] The physical addressing test and functional addressing test are mainly used to test the conversion function between the DoIP logical address and the CAN diagnostic ID of the edge node. In practical applications, the edge node needs to be able to realize the conversion between the DoIP logical address and the CAN node diagnostic ID to ensure that the diagnostic request can be correctly routed to the target CAN node and the response can be routed back to the test equipment.

[0103] Buffer testing is used to test the buffer management of edge nodes. Edge nodes need to have appropriate buffer management strategies so that they can correctly store and forward data during multi-frame transmission.

[0104] The error forwarding test is used to test the error forwarding processing of the edge node. When the length of the response sent by the CAN node exceeds the maximum capacity of the edge node buffer, the edge node should be able to send a specific flow control frame (FS is overflow) and stop receiving subsequent response data to avoid failures caused by data overflow.

[0105] For each of the above test types, when performing the corresponding test operation, it is necessary to send a test instruction corresponding to the test type to the device under test, wherein the test instruction includes test data.

[0106] For example, in order to implement a data length diagnostic test, the test device sends a diagnostic request to the CAN node in the vehicle, and the message length is set to zz bytes (where zz is greater than the maximum length supported by the target CAN network transmission protocol, which is 4095 bytes), and verifies whether the device under test replies to the diagnostic request NACK, where the response code is 0x04 (diagnostic data too long), and the message will not be forwarded to the CAN node in the vehicle.

[0107] At this time, the test data in the test instruction sent by the test equipment is:

[0108] 0x02 0xFD 0x80 0x01 PL SA TA UD

[0109] Among them, PL is the 4-byte load length; SA is the 2-byte diagnostic device logical address; TA is the 2-byte in-vehicle CAN node logical address; UD is the carried diagnostic message.

[0110] The device under test should respond with:

[0111] 0x02 0xFD 0x80 0x03 0x00 0x00 0x00 0x07 DL TL 0x04 0x3E 0x00

[0112] Among them, DL is the 2-byte logical address of the in-vehicle CAN node; TL is the 2-byte logical address of the diagnostic device.

[0113] S12, obtaining a response message generated by the device under test in the process of processing the test data, and performing a verification operation on the response message to determine a device test result of the device under test;

[0114] The response message includes: data transmitted between the device under test and the test device, and / or data transmitted between the device under test and the CAN transceiver.

[0115] Specifically, when executing a test, the device under test may interact only with the test device, or may interact with both the test device and the CAN transceiver.

[0116] For example, in the data length diagnostic test, since the message length sent by the test device is greater than the maximum length supported by the target CAN network transmission protocol, the device under test should theoretically reply with a diagnostic request NACK to the test device, where the response code is 0x04 (diagnostic data too long), and the message will not be forwarded to the in-vehicle CAN node. In this case, the device under test only needs to reply to the test device, that is, in the data length diagnostic test, there is only interaction with the test device. At this time, the response message includes: the data transmitted between the device under test and the test device,

[0117] In the remaining four tests, since the device under test needs to forward data to the CAN transceiver for processing and feed back the results to the test device, the device under test needs to interact with both the test device and the CAN transceiver. At this time, the response message includes: the data transmitted between the device under test and the test device, and the data transmitted between the device under test and the CAN transceiver.

[0118] After the response message is determined, a verification operation is performed on the response message according to a verification method corresponding to each test to determine a device test result of the device under test.

[0119] In this embodiment, the test device communicates with the device under test through a first communication method, and the device under test communicates with the CAN transceiver through a second communication method to implement the test of the edge node. During the specific test, the test device sends a test instruction corresponding to the test type to the device under test, and the test instruction includes test data. During the process of the device under test processing the test data, the generated response message is obtained, and a verification operation is performed on the response message to determine the device test result of the device under test. In the present invention, the response message includes the data transmitted between the device under test and the test device, and / or the data transmitted between the device under test and the CAN transceiver. By verifying the response message, it is analyzed whether the communication between the device under test, the test device and the CAN transceiver is normal, so as to verify whether the edge node has the ability to correctly convert the messages between DoIP and DoCAN.

[0120] The above embodiment introduces five test types. Now the test process of each test type is explained respectively.

[0121] 1. The test types include: data length diagnostic test.

[0122] The data length diagnostic test refers to the diagnostic NACK (diagnostic data too long) test. The purpose of the test is to verify whether the device under test can give the corresponding diagnostic message NACK according to the process described in ISO13400[DoIP-065].

[0123] In the data length diagnostic test, the device under test is powered on by a programmable power supply, the activation line voltage is 5V, and the device under test works normally after powering on.

[0124] The test device establishes a TCP connection with the device under test (such as an edge node), and the device under test replies with a response message for establishing a TCP connection. It should be noted that in this embodiment, the Tester in the test device establishes a TCP connection with the device under test.

[0125] The test device sends a route activation request to verify whether the device under test replies with a route activation response and the response code is 0x10 (activation successful).

[0126] Specifically, the routing activation request sent by the test device is:

[0127] 0x02 0xFD 0x00 0x05 0x00 0x00 0x00 0x07 SA 0x00 0x00 0x00 0x00 0x00

[0128] Among them, SA is a 2-byte diagnostic device logical address, specifically refers to the logical address of the Tester.

[0129] The route activation response from the device under test is:

[0130] 0x02 0xFD 0x00 0x06 0x00 0x00 0x00 0x09 TL DL 0x10 0x00 0x00 0x000x00

[0131] Among them, TL is the 2-byte logical address of the diagnostic device; DL is the 2-byte logical address of the device under test.

[0132] In order to implement the data length diagnostic test, the test equipment sends a diagnostic request (i.e., a test instruction) to the CAN node in the vehicle, and the message length is set to zz bytes (where zz is greater than the maximum length supported by the target CAN network transmission protocol, which is 4095 bytes), and verifies whether the device under test replies to the diagnostic request NACK, where the response code is 0x04 (diagnostic data too long), and the message will not be forwarded to the CAN node in the vehicle.

[0133] At this time, the test data in the test instruction sent by the test equipment is:

[0134] 0x02 0xFD 0x80 0x01 PL SA TA UD

[0135] Among them, PL is the 4-byte load length; SA is the 2-byte diagnostic device logical address; TA is the 2-byte in-vehicle CAN node logical address; UD is the carried diagnostic message.

[0136] The device under test should respond with:

[0137] 0x02 0xFD 0x80 0x03 0x00 0x00 0x00 0x07 DL TL 0x04 0x3E 0x00

[0138] Among them, DL is the 2-byte logical address of the in-vehicle CAN node; TL is the 2-byte logical address of the diagnostic device.

[0139] After the test device sends a diagnostic request and the device under test responds, the device under test can process the test data in the diagnostic request and determine whether the message length in the test data is greater than the maximum length supported by the CAN transceiver (i.e., the above-mentioned 4095 bytes). If so, the device under test will output the first message to the test device. The first message is as above:

[0140] 0x02 0xFD 0x80 0x03 0x00 0x00 0x00 0x07 DL TL 0x04 0x3E 0x00

[0141] Therefore, during the test process, when obtaining a response message, the first message output by the device under test to the testing device should be obtained.

[0142] Then, it is detected whether the first message is a negative confirmation message including a too-long fault code. If so, it is determined that the test result of the data length diagnostic test of the device under test is a preset test result; the preset test result is an indicator indicating normality.

[0143] Specifically, if the fault code in the first message is a fault code of too long length, such as 0x04 (diagnostic data too long), and it is a negative confirmation message including 0x80 and 0x03, it means that the device under test can normally identify the communication data that is too long, and the preset test result is an indicator representing normality. In actual applications, if 1 is used to indicate normality and 0 is used to indicate abnormality, the preset test result is 1.

[0144] After the test is completed, the test device disconnects the TCP connection with the device under test; the device under test replies with a response message for disconnecting the TCP connection.

[0145] In this embodiment, when the device under test receives a diagnostic request message whose length is greater than the maximum supported by the CAN network transmission protocol, it replies with a NACK response message whose NACK code is 0x04, thereby verifying that the function of the device under test is normal.

[0146] 2. The test types include: physical addressing test or functional addressing test.

[0147] In the embodiment of the present invention, the difference between the physical addressing test and the functional addressing test is that the selected CAN nodes are different. The physical addressing test selects a CAN node of a target domain, and the functional addressing test selects CAN nodes of all target domains. The remaining steps are similar. In this embodiment, the test process is introduced by taking the physical addressing test as an example. The purpose of the physical addressing test is to detect whether the device under test can realize the diagnostic routing (physical addressing) between DoIP-DoCAN.

[0148] Before testing, the communication connection operation also needs to be performed. Specifically, the device under test is powered on, the activation line voltage is 5V, and the device under test works normally. The test device establishes a TCP connection with the device under test, and the device under test replies with a response message to establish a TCP connection. The test device sends a route activation request to verify whether the device under test replies with a route activation response, and the response code is 0x10 (activation successful).

[0149] Specifically, the content of the routing activation request sent by the test device is:

[0150] 0x02 0xFD 0x00 0x05 0x00 0x00 0x00 0x07 SA 0x00 0x00 0x00 0x00 0x00

[0151] Among them, SA is a 2-byte diagnostic device logical address.

[0152] The content of the route activation response replied by the device under test is:

[0153] 0x02 0xFD 0x00 0x06 0x00 0x00 0x00 0x09 TL DL 0x10 0x00 0x00 0x000x00

[0154] Among them, TL is the 2-byte logical address of the diagnostic device; DL is the 2-byte logical address of the device under test.

[0155] In order to implement the physical addressing test, the test equipment uses physical addressing to send a diagnostic request (such as 0x3E service) to the specified in-vehicle CAN node (the CAN bus diagnostic ID of the known node) to verify whether the device under test replies to the diagnostic request ACK.

[0156] Specifically, the test data of the test message sent by the test device is:

[0157] 0x02 0xFD 0x80 0x01 0x00 0x00 0x00 0x06 SA TA 0x3E 0x00

[0158] Among them, SA is a 2-byte logical address of the diagnostic device; TA is a 2-byte logical address of the in-vehicle CAN node.

[0159] Verify that the content of the diagnostic request ACK replied by the device under test is:

[0160] 0x02 0xFD 0x80 0x02 0x00 0x00 0x00 0x07 DL TL 0x00 0x3E 0x00

[0161] Among them, DL is the 2-byte logical address of the in-vehicle CAN node; TL is the 2-byte logical address of the diagnostic device.

[0162] If the device under test responds normally, the subsequent test process will continue.

[0163] First, detect the message received by the device under test to determine whether the source address in the message is the logical address of the test device, whether the target address is the logical address of the CAN node in the vehicle, whether the source IP address is the IP address of the test device, and whether the target IP address is the external IP address of the device under test.

[0164] If yes, continue to execute the subsequent test steps.

[0165] The device under test will convert the DoIP logical address into a CAN diagnostic ID through internal logic processing to obtain a CAN bus diagnostic request ID. Then the message (in this embodiment, for the sake of distinction, the message is referred to as the second message) is sent to the CAN transceiver, and the PC can obtain the second message received by the CAN transceiver through the connection relationship with the CAN transceiver.

[0166] The CAN transceiver receives the second message, performs internal logic processing, and returns a diagnostic response to the device under test (such as 0x3E service). The diagnostic response in this embodiment can be implemented by a third message. The content of the third message can be as follows:

[0167] 0x02 0x7E 0x00

[0168] CAN diagnostic response message payload field.

[0169] The third message sent by the CAN transceiver will also be monitored by the PC, so that the PC can obtain the third message.

[0170] After receiving the third message, the device under test will perform a CAN diagnostic ID and DoIP logical address conversion operation to obtain a fourth message, and send the fourth message to the Tester. The PC can obtain the fourth message through a communication connection with the Tester.

[0171] In summary, obtaining a response message generated by the device under test in processing the test data includes:

[0172] Acquire a second message sent by the device under test to the CAN transceiver in response to the test instruction, acquire a third message sent by the CAN transceiver to the device under test in response to the second message, and acquire a fourth message sent by the device under test to the test device after performing address conversion on the third message.

[0173] On this basis, refer to Figure 3 , performing a verification operation on the response message to determine a device test result of the device under test, including:

[0174] S21. Verify whether the target domain in the second message matches the target domain in the test data; if so, execute step S22.

[0175] Specifically, in actual scenarios, there are multiple domains in the car, such as the power domain, the body domain, etc., and each domain is configured with a corresponding CAN node. The device under test, such as an edge node, has a physical addressing function, that is, after receiving the message, it should be able to correctly route the message to the corresponding domain. Therefore, in this embodiment, verifying whether the target domain in the second message matches the target domain in the test data is to verify whether the device under test correctly routes the message to the target domain where the in-vehicle CAN node where the message should arrive is located.

[0176] If it is verified that the target domain in the second message matches the target domain in the test data, it means that the target domain routed to the device under test is correct. At this time, it is further determined whether it is routed to the corresponding CAN node. This step is implemented by S22.

[0177] S22. Verify whether the CAN bus diagnostic request identifier in the second message is the CAN bus diagnostic request identifier corresponding to the CAN node logical address in the test data; if so, execute step S23.

[0178] Specifically, there will be multiple CAN nodes in a target domain. The test equipment specifies the CAN node in the vehicle through the TA field in the test data, but the address of the CAN node uses a logical address. Inside the device under test, the logical address needs to be converted into a CAN diagnostic ID. At this time, the CAN bus diagnostic request identifier in the second message, that is, the CAN bus diagnostic request ID, is used to verify whether the conversion process inside the device under test is correct.

[0179] If the CAN bus diagnostic request identifier in the second message is the CAN bus diagnostic request identifier corresponding to the CAN node logical address in the test data (the content in TA in the test data), it means that the message ID in the second message is the CAN bus diagnostic request ID of the target CAN node to be sent, that is, the physical addressing of the device under test is correct.

[0180] S23: After determining that the third message is successfully sent to the device under test, verify the address in the fourth message.

[0181] After the device under test forwards the message to the target CAN node in the CAN transceiver, it is necessary to further verify whether the device under test can normally feed back the message to the test device.

[0182] Since the message fed back by the device under test to the test device is sent by the target CAN node, it is necessary to first determine whether the CAN node has fed back the message to the device under test. The PC can be used to monitor whether the third message is successfully sent by the CAN transceiver. If it is successfully sent, it means that the third message is successfully sent to the device under test. In addition to verifying that the third message is successfully sent, it is also necessary to verify that the message ID in the message received by the device under test is the CAN bus diagnostic response ID of the CAN node in the vehicle. If correct, continue with the subsequent process.

[0183] The address in the fourth message is subsequently verified to verify whether the conversion function of the device under test is correct.

[0184] The specific verification contents are:

[0185] The source address in the fourth message is the logical address of the CAN node in the vehicle, the target address is the logical address of the test device, the source IP address is the external IP address of the device under test, and the target IP address is the IP address of the test device.

[0186] S24: If the verification is successful, determine that the test result of the physical addressing test or the functional addressing test of the device under test is a preset test result.

[0187] The preset test result is an indicator of normality.

[0188] Specifically, if the verification of step S23 is passed, it means that the device under test can normally implement the DoIP logical address-CAN node diagnostic ID conversion, and the test result is the preset test result. The content of the preset test result refers to the above corresponding description. If the verification fails, the test result is not the preset test result.

[0189] Subsequently, other in-vehicle CAN nodes are set up and the above steps are repeated until the test of all in-vehicle CAN nodes is completed.

[0190] After the test is completed, the test device disconnects the TCP connection with the device under test, and the device under test replies with a response message to disconnect the TCP connection.

[0191] In this embodiment, whether the physical addressing function of the device under test is normal is tested by diagnosing whether the device under test can normally implement the DoIP logical address-CAN node diagnostic ID conversion function.

[0192] The process of functional addressing test is similar to that of physical addressing test. The process of functional addressing test is briefly described below.

[0193] During the DoIP logical address-CAN diagnostic ID conversion test, that is, the functional addressing test, the test purpose is to detect whether the device under test can realize the diagnostic routing (functional addressing) between DoIP and DoCAN.

[0194] The test steps are as follows:

[0195] The device under test is powered on, the activation line voltage is 5V, and the device under test works normally. The test device establishes a TCP connection with the device under test, and the device under test replies with a response message to establish a TCP connection. The test device sends a route activation request to verify whether the device under test replies with a route activation response, and the response code is 0x10 (activation successful).

[0196] Specifically, the content of the routing activation request sent by the test device is:

[0197] 0x02 0xFD 0x00 0x05 0x00 0x00 0x00 0x07 SA 0x00 0x00 0x00 0x00 0x00

[0198] Among them, SA is a 2-byte diagnostic device logical address.

[0199] The content of the route activation response replied by the device under test is:

[0200] 0x02 0xFD 0x00 0x06 0x00 0x00 0x00 0x09 TL DL 0x10 0x00 0x00 0x000x00

[0201] Among them, TL is the 2-byte logical address of the diagnostic device; DL is the 2-byte logical address of the device under test.

[0202] The test equipment uses functional addressing to send a diagnostic request (such as 0x3E service) to a specified in-vehicle CAN node (the CAN bus diagnostic ID of the known node) to verify that the device under test replies to the diagnostic request ACK.

[0203] Specifically, the diagnostic data in the diagnostic message sent by the test device is:

[0204] 0x02 0xFD 0x80 0x01 0x00 0x00 0x00 0x06 SA TA 0x3E 0x00

[0205] Among them, SA is a 2-byte diagnostic device logical address; TA is a 2-byte in-vehicle CAN node function addressing logical address.

[0206] Response from the device under test:

[0207] 0x02 0xFD 0x80 0x02 0x00 0x00 0x00 0x07 DL TL 0x00 0x3E 0x00

[0208] DL is the 2-byte logical address of the in-vehicle CAN node function addressing; TL is the 2-byte logical address of the diagnostic device.

[0209] If the device under test responds normally, it is detected that the device under test has received the message, and the source address in the message is the logical address of the test device, the target address is the functional addressing logical address of the CAN node in the vehicle, the source IP address is the IP address of the test device, and the target IP address is the external IP address of the device under test.

[0210] Verify that the device under test routes the second message to the target domain where the in-vehicle CAN node is located, and the message ID is the CAN bus diagnostic function addressing ID of the target node.

[0211] The CAN node in the vehicle returns a diagnostic response to the test equipment (such as 0x3E service). The content of the third message sent is:

[0212] 0x02 0x7E 0x00

[0213] CAN diagnostic response message payload field.

[0214] Verify that the device under test receives the message and that the message ID is the CAN bus diagnostic response ID of the CAN node in the vehicle.

[0215] Verify that the device under test routes the fourth message to the test device, and the source address in the message is the logical address of the CAN node in the vehicle, the target address is the logical address of the test device, the source IP address is the external IP address of the device under test, and the target IP address is the IP address of the test device.

[0216] If the verification is successful, it means that the device under test has successfully implemented the DoIP function addressing logical address - CAN node diagnostic ID conversion, and set up other in-vehicle CAN nodes, repeat the above steps, and complete the test of all in-vehicle CAN nodes.

[0217] After the test is completed, the test device disconnects the TCP connection with the device under test, and the device under test replies with a response message to disconnect the TCP connection.

[0218] In this embodiment, it is diagnosed whether the device under test can implement the DoIP logical address-CAN node diagnostic ID conversion function to determine whether the functional addressing function of the device under test is normal.

[0219] 3. The test types include: cache test.

[0220] Specifically, the purpose of the DoIP-DoCAN buffer test is to verify whether the DoIP-DoCAN receiving buffer is consistent with the definition in Ref.1.

[0221] Before testing, it is still necessary to perform communication connection operations. Specifically, the device under test is powered on, the activation line voltage is 5V, and the device under test works normally. The test device establishes a TCP connection with the device under test, and the device under test replies with a response message to establish a TCP connection. The test device sends a route activation request to verify whether the device under test replies with a route activation response, and the response code is 0x10 (activation successful).

[0222] Specifically, the routing activation request sent by the test device is:

[0223] 0x02 0xFD 0x00 0x05 0x00 0x00 0x00 0x07 SA 0x00 0x00 0x00 0x00 0x00

[0224] Among them, SA is a 2-byte diagnostic device logical address.

[0225] The route activation response from the device under test is:

[0226] 0x02 0xFD 0x00 0x06 0x00 0x00 0x00 0x09 TL DL 0x10 0x00 0x00 0x000x00

[0227] Among them, TL is the 2-byte logical address of the diagnostic device; DL is the 2-byte logical address of the device under test.

[0228] On this basis, the buffer test is started. During the test, the test equipment sends a diagnostic request to the CAN node in the vehicle, and the message length is set to xx bytes (where xx is the byte length of the buffer of the device under test, such as the edge node that receives the DoIP message and forwards it to the CAN network. The value is 4095 bytes).

[0229] Specifically, the test data in the test message sent by the test device is:

[0230] 0x02 0xFD 0x80 0x01 0x00 0x00 0x0F 0xFB SA TA UD

[0231] Among them, SA is a 2-byte logical address of the diagnostic device; TA is a 2-byte logical address of the in-vehicle CAN node; and UD is the carried diagnostic message.

[0232] The response from the device under test is:

[0233] 0x02 0xFD 0x80 0x02 0x00 0x00 0x0F 0xFC DL TL 0x00 UD

[0234] Among them, DL is the 2-byte logical address of the in-vehicle CAN node; TL is the 2-byte logical address of the diagnostic device.

[0235] Since the message length in the test content sent by the test device is equal to the maximum register length XX of the device under test, the buffer management strategy of the device under test will adopt multi-frame transmission so that data can be correctly stored and forwarded during the multi-frame transmission process. Therefore, it is possible to determine whether the buffer strategy of the device under test is normal by analyzing whether the device under test forwards the message to the CAN transceiver in a multi-frame manner.

[0236] Therefore, when acquiring the message, the fifth message sent by the device under test to the CAN transceiver should be acquired when the message length in the test data is equal to the maximum length of the register of the device under test.

[0237] After obtaining the fifth message, refer to Figure 4 , performing a verification operation on the response message to determine a device test result of the device under test may include:

[0238] S31. Determine, by analyzing the fifth message, whether the device under test adopts the CAN bus multi-frame transmission mode for data transmission.

[0239] Specifically, the content of the fifth message is analyzed to verify whether the device under test routes the message to the in-vehicle CAN node in a CAN bus multi-frame transmission mode.

[0240] If yes, it means that the buffer management strategy of the device under test is normal.

[0241] S32: If the CAN bus multi-frame transmission mode is adopted for transmission, verify whether the target domain and the CAN bus diagnostic request identifier in the fifth message are correct.

[0242] Specifically, the process of verifying the target domain and the CAN bus diagnostic request identifier is the same as the above corresponding content, that is, whether the fifth message routed by the device under test in the CAN bus multi-frame transmission mode is correctly routed to the target domain where the CAN node in the vehicle is located, and the message ID is the CAN bus diagnostic request ID of the target node.

[0243] In the process of the device under test sending the fifth message, the in-vehicle CAN node simulated by the CAN transceiver may reply with several negative response messages with NRC=0x78.

[0244] S33. If all are correct, determine that the test result of the buffer test of the device under test is a preset test result; the preset test result is an indicator indicating that it is normal.

[0245] If the target domain and the CAN bus diagnostic request identifier are verified to be correct, it can be determined that the buffer management strategy of the device under test is normal. At this time, the test result of the buffer test of the device under test is determined to be the preset test result; the preset test result is an identifier that indicates normality. The content of the preset test result refers to the corresponding description above.

[0246] After the fifth message is transmitted, the CAN node in the vehicle replies with a corresponding diagnostic response, and the device under test forwards the diagnostic response to the test device. Subsequently, it can be detected whether the test device can receive the message normally and the address of the message is correct.

[0247] Subsequently, in the test data of the test message, set TA to any node in other CAN segments in the vehicle, repeat the above steps, and complete the test of all CAN segments in the vehicle.

[0248] After the test is completed, the test device disconnects the TCP connection with the device under test, and the device under test replies with a response message to disconnect the TCP connection.

[0249] In this embodiment, the message length in the test content sent by the test device is set to the maximum register length of the device under test to verify whether the device under test can implement the forwarding function of the DoIP message - CAN message buffer (4095 bytes).

[0250] 4. The test types include: error forwarding test.

[0251] In this embodiment, the purpose of the DoCAN-DoIP error forwarding test is to verify whether the device under test can send a flow control frame with FS as overflow to the CAN node after the in-vehicle CAN node sends a first frame diagnostic response whose length is greater than the maximum register length of the device under test (such as 4095 bytes), and does not forward the message to the test device.

[0252] Specifically, a communication connection needs to be established before testing. The specific process is as follows:

[0253] The device under test is powered on, the activation line voltage is 5V, and the device under test works normally. The test device establishes a TCP connection with the device under test, and the device under test replies with a response message to establish a TCP connection. The test device sends a route activation request to verify whether the device under test replies with a route activation response, and the response code is 0x10 (activation successful).

[0254] Specifically, the content of the routing activation request sent by the test device is:

[0255] 0x02 0xFD 0x00 0x05 0x00 0x00 0x00 0x07 SA 0x00 0x00 0x00 0x00 0x00

[0256] Among them, SA is a 2-byte diagnostic device logical address.

[0257] The content of the route activation response replied by the device under test is:

[0258] 0x02 0xFD 0x00 0x06 0x00 0x00 0x00 0x09 TL DL 0x10 0x00 0x00 0x000x00

[0259] Among them, TL is the 2-byte logical address of the diagnostic device; DL is the 2-byte logical address of the device under test.

[0260] If the device under test responds normally, the subsequent test will continue. The test device sends a diagnostic request (such as 0x3E service) to the specified in-vehicle CAN node (the CAN bus diagnostic ID of the known node) to verify whether the device under test responds to the diagnostic request ACK.

[0261] The test data in the test message sent by the test device is:

[0262] 0x02 0xFD 0x80 0x01 0x00 0x00 0x00 0x06 SA TA 0x3E 0x00

[0263] Among them, SA is a 2-byte logical address of the diagnostic device; TA is a 2-byte logical address of the in-vehicle CAN node.

[0264] The device under test responds:

[0265] 0x02 0xFD 0x80 0x02 0x00 0x00 0x0F 0xFC DL TL 0x00 UD

[0266] Among them, DL is the 2-byte logical address of the in-vehicle CAN node; TL is the 2-byte logical address of the diagnostic device.

[0267] Subsequently, it is detected whether the device under test has received the message, and the source address in the message is the logical address of the test device, the target address is the logical address of the CAN node in the vehicle, the source IP address is the IP address of the test device, and the target IP address is the external IP address of the device under test.

[0268] If all are correct, the device under test will perform physical addressing and route the message to the corresponding CAN node in the CAN transceiver. At this time, the sixth message sent by the device under test to the CAN transceiver is obtained.

[0269] After the corresponding CAN node in the CAN transceiver receives the sixth message, if the message length sent by the in-vehicle CAN node is greater than the maximum register length of the device under test, the in-vehicle CAN node returns a diagnostic response to the test device and sets the response message length to uu bytes (where uu is a value greater than 4095 bytes, that is, the FF_DL contained in the first frame returned is greater than 4095 bytes). The diagnostic response returned by the in-vehicle CAN node can be implemented through the seventh message, and the content of the seventh message can be:

[0270] 0x10 0x00 DL

[0271] Among them, DL is a 4-byte CAN message length indicator, which is greater than 4095 bytes.

[0272] At this time, the seventh message sent by the CAN transceiver to the device under test in response to the sixth message can be obtained through the communication relationship between the PC and the CAN transceiver.

[0273] Theoretically, after receiving the seventh message, the device under test should send a flow control frame with FS as overflow to the CAN node in the vehicle and stop receiving the continuous frames of the subsequent response messages. Therefore, it is possible to obtain the first response result sent by the device under test to the CAN transceiver to verify whether the flow control frame with FS as overflow is sent.

[0274] In addition, the device under test may reply a second response result to the testing device, and the second response result sent by the device under test to the testing device may be obtained.

[0275] If the second response result is:

[0276] 0x02 0xFD 0x80 0x03 0x00 0x00 0x00 0x07 DL TL 0x05 0x3E 0x00

[0277] Among them, DL is the 2-byte logical address of the in-vehicle CAN node; TL is the 2-byte logical address of the diagnostic device.

[0278] After obtaining the sixth message, the seventh message, the first response result and the second response result, these data may be verified to determine the device test result of the device under test.

[0279] Specifically, verify whether the target domain in the sixth message matches the target domain in the test data; if they match, verify whether the CAN bus diagnostic request identifier in the sixth message is the CAN bus diagnostic request identifier corresponding to the CAN node logical address in the test data.

[0280] Specifically, it is verified whether the domain where the tested device routes the sixth message to the in-vehicle CAN node is the target domain, and whether the message ID is the CAN bus diagnostic request ID of the target node.

[0281] If it is a CAN bus diagnostic request identifier corresponding to the CAN node logical address in the test data, and when the message length in the seventh message is equal to the maximum length of the register of the device under test, determine whether the first response result is a flow control frame including an overflow identifier, that is, whether it is the above-mentioned flow control frame with FS as overflow. If so, it means that the device under test correctly recognizes that the message length sent by the CAN node in the vehicle is greater than the maximum length of the register of the device under test. Subsequently, determine whether the second response result sent by the device under test to the test device is a negative confirmation message including a preset error fault code (such as 0x05), and whether the second response result does not include the message data in the seventh message.

[0282] If the second response result is:

[0283] 0x02 0xFD 0x80 0x03 0x00 0x00 0x00 0x07 DL TL 0x05 0x3E 0x00

[0284] Including the preset error fault code 0x05, indicating that the response sent by the device under test to the test device is correct. In addition, it is necessary to determine whether the device under test did not forward the message sent by the CAN node to the test device, that is, whether the second response result does not include the message data in the seventh message. If not, it means that the device under test did not forward the diagnostic message replied by the CAN node in the vehicle to the external test device, and the test result of the erroneous forwarding of the device under test is determined to be the preset test result; the preset test result is an identification that represents normality.

[0285] Afterwards, set up other in-vehicle CAN nodes and repeat the above steps to complete the test of all in-vehicle CAN nodes.

[0286] After the test is completed, the test device disconnects the TCP connection with the device under test, and the device under test replies with a response message to disconnect the TCP connection.

[0287] In this embodiment, after the device under test sends a first frame response with a length greater than 4095 bytes at the target CAN node, it is verified whether the device under test has an error forwarding function by determining whether to send a flow control frame with FS as overflow to the target node and not forwarding the message to the test device.

[0288] The above embodiment uses five types of tests, and the test scheme covers a variety of diagnostic scenarios, including diagnostic data that is too long, logical address and CAN diagnostic ID conversion, etc. The test scenarios are comprehensive. In addition, clear test steps and evaluation criteria ensure the accuracy of the test. In addition, the performance of the device under test is verified by simulating actual operating conditions, which ensures the reliability of the scheme.

[0289] Based on the above-mentioned embodiment of the device testing method, another embodiment of the present invention provides a device testing apparatus, referring to Figure 5 , applied to a test device, the test device communicates with the device under test through a first communication mode, and the device under test communicates with a controller area network (CAN) transceiver through a second communication mode; the CAN transceiver is used to simulate multiple CAN nodes;

[0290] The equipment testing device comprises:

[0291] The instruction sending module 11 is used to send a test instruction corresponding to the test type to the device under test after establishing a communication connection with the device under test; the test instruction includes test data;

[0292] The test module 12 is used to obtain a response message generated by the device under test in the process of processing the test data, and perform a verification operation on the response message to determine a device test result of the device under test;

[0293] The response message includes: data transmitted between the device under test and the test device, and / or data transmitted between the device under test and the CAN transceiver.

[0294] In one implementation, the test types include: data length diagnostic test;

[0295] The test module 12 includes:

[0296] A first acquisition submodule, configured to acquire, when a message length in the test data is greater than a maximum length supported by the CAN transceiver, a first message output by the device under test to the test device;

[0297] The detection submodule is used to detect whether the first message is a negative confirmation message including a too-long fault code; if so, determine that the test result of the data length diagnostic test of the device under test is a preset test result; the preset test result is an indicator of normality.

[0298] In one implementation, the test type includes: a physical addressing test or a functional addressing test;

[0299] The test module 12 includes:

[0300] A second acquisition submodule, used for acquiring a second message sent by the device under test to the CAN transceiver in response to the test instruction;

[0301] A third acquisition submodule, used for acquiring a third message sent by the CAN transceiver to the device under test in response to the second message;

[0302] The fourth acquisition submodule is used to acquire a fourth message sent by the device under test to the testing device after performing address conversion on the third message.

[0303] In one implementation, the test module 12 includes:

[0304] A first verification submodule, used to verify whether the target domain in the second message matches the target domain in the test data;

[0305] A second verification submodule is used to verify whether the CAN bus diagnostic request identifier in the second message is the CAN bus diagnostic request identifier corresponding to the CAN node logical address in the test data if there is a match;

[0306] The third verification submodule is used to verify the address in the fourth message after determining that the third message is successfully sent to the device under test; if the verification passes, determine that the test result of the physical addressing test or the functional addressing test of the device under test is a preset test result; the preset test result is an identification that represents normality.

[0307] In one implementation, the test types include: cache testing;

[0308] The test module 12 includes:

[0309] The fifth acquisition submodule is used to acquire a fifth message sent by the device under test to the CAN transceiver when the message length in the test data is equal to the maximum length of the register of the device under test.

[0310] In one implementation, the test module 12 includes:

[0311] A mode determination submodule, used to determine whether the device under test adopts a CAN bus multi-frame transmission mode for data transmission by analyzing the fifth message;

[0312] The fourth verification submodule is used to verify whether the target domain and the CAN bus diagnostic request identifier in the fifth message are correct if the CAN bus multi-frame transmission method is adopted; if both are correct, it is determined that the test result of the cache test of the device under test is a preset test result; the preset test result is an identifier that represents normality.

[0313] In one implementation, the test types include: an error forwarding test;

[0314] The test module 12 includes:

[0315] A sixth acquisition submodule, used to acquire a sixth message sent by the device under test to the CAN transceiver;

[0316] a seventh acquisition submodule, configured to acquire a seventh message sent by the CAN transceiver to the device under test in response to the sixth message;

[0317] An eighth acquisition submodule is used to acquire a first response result sent by the device under test to the CAN transceiver, and a second response result sent by the device under test to the test device.

[0318] In one implementation, the test module 12 includes:

[0319] a fifth verification submodule, configured to verify whether the target domain in the sixth message matches the target domain in the test data;

[0320] a sixth verification submodule, configured to verify, if a match occurs, whether the CAN bus diagnostic request identifier in the sixth message is the CAN bus diagnostic request identifier corresponding to the CAN node logical address in the test data;

[0321] A first judgment submodule is used to judge whether the first response result is a flow control frame including an overflow flag if the CAN bus diagnostic request flag corresponding to the CAN node logical address in the test data and the message length in the seventh message is equal to the maximum length of the register of the device under test;

[0322] The second judgment submodule is used to judge whether the second response result is a negative confirmation message including a preset error fault code and whether the second response result does not include the message data in the seventh message if it is a flow control frame including an overflow identifier; if the second response result is a negative confirmation message including a preset error fault code and the second response result does not include the message data in the seventh message, it is determined that the test result of the error forwarding of the device under test is a preset test result; the preset test result is an identifier that indicates normality.

[0323] In this embodiment, the test device communicates with the device under test through a first communication method, and the device under test communicates with the CAN transceiver through a second communication method to implement the test of the edge node. During the specific test, the test device sends a test instruction corresponding to the test type to the device under test, and the test instruction includes test data. During the process of the device under test processing the test data, the generated response message is obtained, and a verification operation is performed on the response message to determine the device test result of the device under test. In the present invention, the response message includes the data transmitted between the device under test and the test device, and / or the data transmitted between the device under test and the CAN transceiver. By verifying the response message, it is analyzed whether the communication between the device under test, the test device and the CAN transceiver is normal, so as to verify whether the edge node has the ability to correctly convert the messages between DoIP and DoCAN.

[0324] It should be noted that, for the working process of each module and sub-module in this embodiment, please refer to the corresponding description in the above embodiment, which will not be repeated here.

[0325] The present application also provides an electronic device in an embodiment. Figure 6 As shown, it shows a schematic diagram of the structure of an electronic device suitable for implementing the embodiment of the present application. The electronic device in the embodiment of the present application may include but is not limited to fixed terminals such as mobile phones, laptops, PDAs (personal digital assistants), PADs (tablet computers), desktop computers, etc. Figure 6 The electronic device shown is merely an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0326] like Figure 6 As shown, the electronic device may include a processing device (such as a central processing unit, a graphics processing unit, etc.) 601, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 602 or a program loaded from a storage device 608 to a random access memory (RAM) 603 to implement the above-mentioned device testing method. When the electronic device is powered on, various programs and data required for the operation of the electronic device are also stored in the RAM 603. The processing device 601, the ROM 602, and the RAM 603 are connected to each other via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0327] Typically, the following devices may be connected to the I / O interface 605: an input device 606 including, for example, a touch screen, a touch pad, a keyboard, a mouse, a camera, a microphone, an accelerometer, a gyroscope, etc.; an output device 607 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; a storage device 608 including, for example, a memory card, a hard disk, etc.; and a communication device 609. The communication device 609 may allow the electronic device to communicate with other devices wirelessly or by wire to exchange data. Although Figure 6 An electronic device having various devices is shown, but it should be understood that it is not required to implement or possess all the devices shown. More or fewer devices may be implemented or possessed instead.

[0328] An embodiment of the present application also provides a computer program product including computer-readable instructions. When the computer-readable instructions are executed on an electronic device, the electronic device implements any device testing method provided in the embodiment of the present application.

[0329] A computer-readable storage medium is also provided in an embodiment of the present application. The storage medium carries one or more computer programs. When the one or more computer programs are executed by an electronic device, the electronic device can implement any device testing method provided in the embodiment of the present application.

[0330] Another embodiment of the present application provides a device testing system, including the test device used for the above, and further including: a device under test and a CAN transceiver;

[0331] The device under test is used to perform an operation corresponding to the test data in the test instruction;

[0332] The CAN transceiver is used to perform interactive operations with the device under test during the process of the device under test performing the operation.

[0333] It should be noted that, for the specific working process of the test device, the device under test and the CAN transceiver in this embodiment, please refer to the corresponding description in the above embodiment.

[0334] The above description of the disclosed embodiments enables those skilled in the art to implement or use the present application. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application will not be limited to the embodiments shown herein, but will conform to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A device testing method, characterized in that: Applied to a test device, the test device communicates with a device under test through a first communication mode, and the device under test communicates with a controller area network (CAN) transceiver through a second communication mode; the CAN transceiver is used to simulate multiple CAN nodes; The device testing method comprises: After establishing a communication connection with the device under test, sending a test instruction corresponding to the test type to the device under test; the test instruction includes test data; Acquire a response message generated by the device under test in the process of processing the test data, and perform a verification operation on the response message to determine a device test result of the device under test; The response message includes: data transmitted between the device under test and the test device, and / or data transmitted between the device under test and the CAN transceiver.

2. The device testing method according to claim 1, characterized in that: The test types include: data length diagnostic test; Acquiring a response message generated by the device under test in the process of processing the test data, and performing a verification operation on the response message to determine a device test result of the device under test, including: When the message length in the test data is greater than the maximum length supported by the CAN transceiver, obtaining a first message output by the device under test to the test device; Detecting whether the first message is a negative confirmation message including a too long fault code; If so, determine that the test result of the data length diagnostic test of the device under test is a preset test result; the preset test result is an indicator indicating normality.

3. The device testing method according to claim 1, characterized in that: The test types include: physical addressing test or functional addressing test; Obtaining a response message generated by the device under test in the process of processing the test data, including: Acquire a second message sent by the device under test to the CAN transceiver in response to the test instruction; Acquire a third message sent by the CAN transceiver to the device under test in response to the second message; A fourth message is obtained, which is sent by the device under test to the testing device and is obtained by performing address conversion on the third message.

4. The device testing method according to claim 3, characterized in that: Performing a verification operation on the response message to determine a device test result of the device under test includes: Verifying whether the target domain in the second message matches the target domain in the test data; If they match, verify whether the CAN bus diagnostic request identifier in the second message is the CAN bus diagnostic request identifier corresponding to the CAN node logical address in the test data; If so, after determining that the third message is successfully sent to the device under test, verifying the address in the fourth message; If the verification is passed, it is determined that the test result of the physical addressing test or the functional addressing test of the device under test is a preset test result; the preset test result is an identification indicating normality.

5. The device testing method according to claim 1, characterized in that: The test types include: cache test; Obtaining a response message generated by the device under test in the process of processing the test data, including: When the message length in the test data is equal to the maximum length of the register of the device under test, a fifth message sent by the device under test to the CAN transceiver is obtained.

6. The device testing method according to claim 5, characterized in that: Performing a verification operation on the response message to determine a device test result of the device under test includes: By analyzing the fifth message, determining whether the device under test uses a CAN bus multi-frame transmission mode for data transmission; If the CAN bus multi-frame transmission mode is adopted for transmission, verify whether the target domain and the CAN bus diagnostic request identifier in the fifth message are correct; If all are correct, it is determined that the test result of the buffer test of the device under test is a preset test result; the preset test result is an indicator indicating that it is normal.

7. The device testing method according to claim 1, characterized in that: The test types include: error forwarding test; Obtaining a response message generated by the device under test in the process of processing the test data, including: Acquire a sixth message sent by the device under test to the CAN transceiver; Acquire a seventh message sent by the CAN transceiver to the device under test in response to the sixth message; A first response result sent by the device under test to the CAN transceiver and a second response result sent by the device under test to the test device are obtained.

8. The device testing method according to claim 7, characterized in that: Performing a verification operation on the response message to determine a device test result of the device under test includes: Verifying whether the target domain in the sixth message matches the target domain in the test data; If they match, verify whether the CAN bus diagnostic request identifier in the sixth message is the CAN bus diagnostic request identifier corresponding to the CAN node logical address in the test data; If it is a CAN bus diagnostic request identifier corresponding to the CAN node logical address in the test data, when the message length in the seventh message is equal to the maximum length of the register of the device under test, determine whether the first response result is a flow control frame including an overflow identifier; If it is a flow control frame including an overflow flag, determining whether the second response result is a negative confirmation message including a preset error fault code, and whether the second response result does not include the message data in the seventh message; If the second response result is a negative confirmation message including a preset error fault code, and the second response result does not include the message data in the seventh message, it is determined that the test result of the error forwarding of the device under test is a preset test result; the preset test result is an identification indicating normality.

9. A device testing apparatus, characterized in that: Applied to a test device, the test device communicates with a device under test through a first communication mode, and the device under test communicates with a controller area network (CAN) transceiver through a second communication mode; the CAN transceiver is used to simulate multiple CAN nodes; The equipment testing device comprises: An instruction sending module, used for sending a test instruction corresponding to the test type to the device under test after establishing a communication connection with the device under test; the test instruction includes test data; A test module, used to obtain a response message generated by the device under test in the process of processing the test data, and perform a verification operation on the response message to determine a device test result of the device under test; The response message includes: data transmitted between the device under test and the test device, and / or data transmitted between the device under test and the CAN transceiver.

10. A device testing system, characterized in that: The device comprises a test device for executing the test as claimed in any one of claims 1 to 8, and further comprises: a device under test and a CAN transceiver; The device under test is used to perform an operation corresponding to the test data in the test instruction; The CAN transceiver is used to perform interactive operations with the device under test during the process of the device under test performing the operation.

Images