An automotive bus testing system, method, electronic device, and storage medium.

Abstract

This application provides an automotive bus testing system, method, electronic device, and storage medium, relating to the field of vehicle technology, and solves the problem in existing technologies that cannot diagnose whether a device under test (DUT) is functioning correctly based on its original messages. The system includes: a bus emulation device configured to: acquire N bus messages generated by the DUT within a first preset time period and send the N bus messages to a test device; the test device configured to: divide the N bus messages into K bus message sets sequentially and sort them according to a preset method; send the sorted K bus message sets to the bus emulation device; the bus emulation device configured to: send the sorted K bus message sets sent by the test device to the DUT; send the acquired diagnostic fault codes (DTCs) and response information of the DUT to the test device; and the test device further configured to: receive the DTCs and response information; and determine whether the DUT is functioning correctly based on the DTCs and response information.

Description

Technical Field

[0001] This invention relates to the field of vehicle technology, and more specifically to an automotive bus testing system, method, electronic device, and storage medium. Background Technology

[0002] Vehicles typically have two diagnostic interfaces before leaving the factory: a diagnostic interface and a data interface. The data interface can read data from each CAN bus; the diagnostic interface connects to the diagnostic CAN. Commercial vehicles usually have the data port removed, leaving only the diagnostic port. The data port allows for bus fuzzy testing of the entire vehicle, revealing design flaws. For electronic control units (ECUs), connecting to the CAN bus also enables bus fuzzy testing. However, current technology does not address methods for acquiring and processing the original messages from the ECUs to observe whether their functions are operating normally. Summary of the Invention

[0003] This application provides an automotive bus testing system, method, electronic device, and storage medium to solve the problem in the prior art that it is impossible to diagnose whether the device under test is normal based on the original messages of the device under test.

[0004] In a first aspect, this application provides an automotive bus testing system, comprising: a bus simulation device, a device under test (DUT), and a testing device; the bus simulation device is electrically connected to both the DUT and the testing device; the bus simulation device is configured to: acquire N bus messages generated by the DUT within a first preset time period, and send the N bus messages to the testing device; wherein the first preset time period is divided into K second preset time periods, N is a positive integer, and K is a positive integer less than N; the testing device is configured to: receive the N bus messages sent by the bus simulation device; divide the N bus messages into K bus message sets sequentially according to the K second preset time periods within the first preset time period; and process the K bus message sets according to a preset method. The system performs sorting; it sequentially sends the sorted K bus message sets to the bus emulation device; the preset sorting method includes one of sequential sorting, reverse sorting, and random sorting; the bus emulation device is also configured to: send the sorted K bus message sets sent by the test device to the device under test; obtain the diagnostic fault codes (DTCs) and response information of the device under test; send the DTCs and response information to the test device; the response information includes one or more of the following: message sending period, Unified Diagnostic Service (UDS) message response time, and UDS message content; the test device is also configured to: receive the DTCs and response information sent by the bus emulation device; and determine whether the device under test is normal based on the DTCs and response information.

[0005] Based on the aforementioned technical means, this application periodically sends a pre-sorted set of K bus messages to the device under test (DUT) to obtain the DTC and response information of the DUT; the DTC and response information of the DUT can be used to determine whether the DUT is functioning properly. This application also replays a set of K bus messages generated from the original messages of the DUT to the DUT, and determines whether the DUT is malfunctioning by obtaining the response information of the DUT, thus solving the problem in the prior art that it is impossible to detect whether the DUT is operating normally based on the original messages of the DUT.

[0006] In some embodiments, the test device is further configured to: obtain M bus messages whose CAN ID of the test device's local area network is less than a first preset value from N bus messages; process the message length and message content of the M bus messages according to the Unified Diagnostic Service (UDS) specification; and sequentially send the processed M bus messages to the bus emulation device; where M is a positive integer less than N; the bus emulation device is further configured to: send the processed M bus messages sent by the test device to the device under test.

[0007] As described above, this application obtains M processed bus messages for diagnosing the device under test (DUT) based on M bus messages with CAN IDs less than a first preset value from among the N bus messages of the DUT, i.e., the M messages with higher priority. If the DUT continuously receives high-priority messages, it will cause the bus load of the DUT to be too high. At this time, the DUT's DTC and response information are used to determine whether the DUT is normal, thus solving the problem in the prior art that it is impossible to diagnose the extreme state of the DUT based on the original messages of the DUT.

[0008] In some embodiments, the test device is further configured to: obtain P bus messages with CAN IDs within a first preset range from N bus messages; process the message length and message content of the P bus messages according to the UDS specification; and sequentially send the processed P bus messages to the bus emulation device; wherein P is a positive integer less than N, and the first preset range represents the range of diagnostic message IDs of the device under test; the bus emulation device is further configured to: send the processed P bus messages sent by the test device to the device under test.

[0009] As can be seen from the above, this application obtains P processed bus messages for diagnosing the device under test based on the CAN ID of P bus messages within the first preset range of the N bus messages of the device under test, that is, based on the diagnostic messages of the device under test. This solves the problem in the prior art that it is impossible to detect whether the device under test is operating normally based on the original messages of the device under test.

[0010] In some embodiments, the test device is further configured to: randomly generate W bus messages with CAN IDs within a second preset range according to the UDS specification; and sequentially send the W bus messages to the bus emulation device; wherein W is a positive integer and the length of any bus message is within the second preset range; the bus emulation device is further configured to: send the W bus messages sent by the test device to the device under test.

[0011] As described above, this application uses W randomly generated bus messages to perform diagnostic tests on the device under test (DUT). The functionality of the DUT can be determined based on the W randomly generated bus messages and the response information from the DUT. Using a random generation method to generate the messages for diagnosing the DUT reduces testing costs.

[0012] In some embodiments, the test equipment is specifically configured to determine, based on DTC and response information, whether one or more of the following are normal: message transmission period, UDS message response time, communication system function, dashboard function, and vehicle terminal function of the device under test.

[0013] As can be seen from the above, this application determines whether at least one function of the device under test is normal based on the DTC and response information of the device under test, thus solving the problem in the prior art that it is impossible to determine whether the device under test is normal based on the response information of the device under test.

[0014] Secondly, this application provides an automotive bus testing method, comprising: acquiring N bus messages generated by a device under test (DUT) within a first preset time period; wherein the first preset time period is divided into K second preset time periods, N is a positive integer, and K is a positive integer less than N; dividing the N bus messages into K bus message sets according to the K second preset time periods within the first preset time period; sorting the K bus message sets according to a preset method; the preset method includes one of sequential sorting, reverse sorting, and random sorting; sequentially sending the processed K bus message sets to the DUT; acquiring the diagnostic fault code (DTC) of the DUT and the response information of the DUT; the response information includes one or more of the following: message sending period, Unified Diagnostic Service (UDS) message response time, and UDS message content; and determining whether the DUT is normal based on the DTC and the response information.

[0015] In some embodiments, the method further includes: obtaining M bus messages from N bus messages whose CAN ID of the test device's local area network is less than a first preset value; M is a positive integer less than N; processing the message length and message content of the M bus messages according to the UDS specification; and sequentially sending the processed M bus messages to the device under test.

[0016] In some embodiments, the method further includes: obtaining P bus messages with CAN IDs within a first preset range from N bus messages; wherein P is a positive integer less than N, and the first preset range represents the range of diagnostic message IDs of the device under test; processing the message length and message content of the P bus messages according to the UDS specification; and sequentially sending the processed P bus messages to the device under test.

[0017] In some embodiments, the method further includes: randomly generating W bus messages with CAN IDs within a second preset range according to the UDS specification; wherein W is a positive integer and the length of any bus message is within the second preset range; and sending the W bus messages to the device under test.

[0018] In some embodiments, the above-mentioned determination of whether the device under test is normal based on the DTC and response information includes: determining whether one or more of the following functions of the device under test are normal: message transmission period, UDS message response time, communication system function, instrument panel function, and vehicle terminal function, based on the DTC and response information.

[0019] Thirdly, this application provides an electronic device, including: a memory and a processor; the memory is used to store computer execution instructions; when the electronic device is running, the processor executes the computer execution instructions stored in the memory to cause the electronic device to perform the method as described in the second aspect and any of the embodiments.

[0020] Fourthly, this application provides a computer-readable storage medium including computer instructions that, when executed on an electronic device, cause the electronic device to perform the methods described in the second aspect and any of its embodiments.

[0021] Fifthly, embodiments of the present invention provide a computer program product that can be directly loaded into a memory and contains software code. After being loaded and executed by a computer, the computer program product can implement the methods described in the second aspect and any of its embodiments.

[0022] Therefore, the above-mentioned technical features of this application have the following beneficial effects:

[0023] (1) By periodically sending K pre-processed bus message sets to the device under test (DUT), the DTC and response information of the DUT can be obtained; the DTC and response information of the DUT can be used to determine whether the DUT is normal. This application replays the K bus message sets generated based on the original messages of the DUT to the DUT, and determines whether the DUT is abnormal by obtaining the response information of the DUT, thus solving the problem in the prior art that it is impossible to detect whether the DUT is operating normally based on the original messages of the DUT.

[0024] (2) Based on the M bus messages with CAN IDs less than a first preset value from the N bus messages of the device under test (DUT), i.e., the M messages with high priority, M processed bus messages are obtained for diagnosing the DUT. If the DUT continuously receives high-priority messages, it will cause the bus load of the DUT to be too high. At this time, the DUT's DTC and response information are used to determine whether the DUT is normal, which solves the problem in the prior art that the extreme state of the DUT cannot be diagnosed based on the original messages of the DUT.

[0025] (3) Based on the P bus messages with CAN ID in the first preset range among the N bus messages of the device under test, that is, based on the diagnostic messages of the device under test, P processed bus messages are obtained for diagnosing the device under test, which solves the problem in the prior art that it is impossible to detect whether the device under test is operating normally based on the original messages of the device under test.

[0026] (4) Using W randomly generated bus messages to perform diagnostic tests on the device under test (DUT), the functionality of the DUT can be determined based on the W randomly generated bus messages and the response information of the DUT. Using a random generation method to generate messages for diagnosing the DUT reduces testing costs.

[0027] (5) Determine whether at least one function of the device under test is normal based on the DTC and response information of the device under test, which solves the problem in the prior art that it is impossible to determine whether the device under test is normal based on the response information of the device under test.

[0028] It should be noted that the aforementioned computer instructions may be stored, in whole or in part, on a computer-readable storage medium. This computer-readable storage medium may be packaged together with the controller's processor, or it may be packaged separately from the controller's processor; this application does not impose any limitations on this.

[0029] The beneficial effects described in aspects two through five of this application can be referred to the analysis of the beneficial effects of aspect one, and will not be repeated here. Attached Figure Description

[0030] Figure 1 A schematic diagram of the structure of an automotive bus testing system provided in this application embodiment. Figure 1 ;

[0031] Figure 2 A schematic diagram of the structure of an automotive bus testing system provided in this application embodiment. Figure 2 ;

[0032] Figure 3 A flowchart illustrating an automotive bus testing method provided in this application embodiment. Figure 1 ;

[0033] Figure 4 A flowchart illustrating an automotive bus testing method provided in this application embodiment. Figure 2 ;

[0034] Figure 5 A flowchart illustrating an automotive bus testing method provided in this application embodiment. Figure 3 ;

[0035] Figure 6 A flowchart illustrating an automotive bus testing method provided in this application embodiment. Figure 4 ;

[0036] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0037] The embodiments of the present invention will be described below with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be understood that the preferred embodiments are only for illustrating the present invention and not for limiting the scope of protection of the present invention.

[0038] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0039] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0040] Vehicles typically have two diagnostic interfaces before leaving the factory: a diagnostic interface and a data interface. The data interface can read data from each CAN bus; the diagnostic interface connects to the diagnostic CAN. Commercial vehicles usually have the data port removed, leaving only the diagnostic port. The data port allows for bus fuzzy testing of the entire vehicle, revealing design flaws. For electronic control units (ECUs), connecting to the CAN bus also enables bus fuzzy testing. However, current technology does not address methods for acquiring and processing the original messages from the ECUs to observe whether their functions are operating normally.

[0041] See Figure 1 As shown, the automotive bus testing system provided in this application embodiment may include: a device under test 101, a testing device 102, and a bus simulation device 103; the bus simulation device 103 is electrically connected to the device under test 101 and the testing device 102 respectively.

[0042] In some embodiments, the device under test 101 may be a complete vehicle or an electronic control unit of a vehicle, and this application embodiment does not impose specific limitations on this.

[0043] In some embodiments, the testing device 102 may be a handheld car testing instrument or a testing computer, etc., and this application embodiment does not impose any limitations on this.

[0044] In some embodiments, the test device 102 is equipped with a programmable test tool, which is used to process bus messages generated by the device under test.

[0045] In some embodiments, the test device 102 is also used to store bus messages of the device under test 101.

[0046] In some embodiments, the bus emulation device 103 is used to acquire the bus messages and fault diagnosis codes (DTCs) of the device under test 101.

[0047] Specifically, the bus emulation device 103 is electrically connected to at least one CAN bus of the device under test 101 to acquire bus messages of at least one CAN bus of the device under test 101.

[0048] In some embodiments, the test device 102 is configured to: receive N bus messages sent by the bus emulation device; divide the N bus messages into K bus message sets according to K second preset durations within a first preset duration; sort the K bus message sets according to a preset method; and send the sorted K bus message sets to the bus emulation device in sequence.

[0049] The first preset duration is divided into K second preset durations, where N is a positive integer and K is a positive integer less than N; the preset method includes one of sequential sorting, reverse sorting, and random sorting.

[0050] In some embodiments, the test device 102 is further configured to: receive DTC and response information sent by the bus emulation device; and determine whether the device under test is normal based on the DTC and response information.

[0051] The response information includes one or more of the following: message sending cycle, Unified Diagnostic Services (UDS) message response time, and UDS message content.

[0052] As described above, this application periodically sends K pre-processed bus message sets to the device under test (DUT) to obtain the DTC and response information of the DUT. Based on the DTC and response information, it can determine whether the DUT is functioning correctly. This application replays K bus message sets generated from the original messages of the DUT to the DUT, and determines whether the DUT is malfunctioning by obtaining the response information of the DUT. This solves the problem in existing technologies where it is impossible to detect whether the DUT is operating normally based on the original messages of the DUT.

[0053] In some embodiments, the test device 102 is further configured to: obtain M bus messages whose test device LAN CAN ID is less than a first preset value from N bus messages; process the message length and message content of the M bus messages according to the UDS specification; and send the processed M bus messages to the bus simulation device in sequence.

[0054] Where M is a positive integer less than N.

[0055] As described above, this application obtains M processed bus messages for diagnosing the device under test (DUT) based on M bus messages with CAN IDs less than a first preset value from among the N bus messages of the DUT, i.e., the M messages with higher priority. If the DUT continuously receives high-priority messages, it will cause the bus load of the DUT to be too high. At this time, the DUT's DTC and response information are used to determine whether the DUT is normal, thus solving the problem in the prior art that it is impossible to diagnose the extreme state of the DUT based on the original messages of the DUT.

[0056] In some embodiments, the test device 102 is further configured to: obtain P bus messages with CAN IDs within a first preset range from N bus messages; process the message length and message content of the P bus messages according to the UDS specification; and send the processed P bus messages sequentially to the bus simulation device.

[0057] Where P is a positive integer less than N; the first preset range represents the range of diagnostic message IDs of the device under test.

[0058] As can be seen from the above, this application obtains P processed bus messages for diagnosing the device under test based on the CAN ID of P bus messages within the first preset range of the N bus messages of the device under test, that is, based on the diagnostic messages of the device under test. This solves the problem in the prior art that it is impossible to detect whether the device under test is operating normally based on the original messages of the device under test.

[0059] In some embodiments, the test device 102 is further configured to: randomly generate W bus messages with CAN IDs within a second preset range according to the UDS specification; and sequentially send the W bus messages to the bus emulation device; wherein W is a positive integer and the length of any bus message is within the second preset range.

[0060] As described above, this application uses W randomly generated bus messages to perform diagnostic tests on the device under test (DUT). The functionality of the DUT can be determined based on the W randomly generated bus messages and the response information from the DUT. Using a random generation method to generate the messages for diagnosing the DUT reduces testing costs.

[0061] In some embodiments, the test device 102 is further configured to: specifically, determine whether one or more of the following functions of the device under test (DTC): message transmission period, UDS message response time, communication system function, dashboard function, and vehicle terminal function, based on the DTC and response information:

[0062] As can be seen from the above, this application determines whether at least one function of the device under test is normal based on the DTC and response information of the device under test, thus solving the problem in the prior art that it is impossible to determine whether the device under test is normal based on the response information of the device under test.

[0063] See Figure 2 As shown, the above-mentioned automotive bus test system also includes a power supply 104.

[0064] In some embodiments, the power supply 104 is electrically connected to the device under test 101, the test device 102, and the bus emulation device 103, respectively. The power supply 104 is used to supply power to the device under test 101, the test device 102, and the bus emulation device 103.

[0065] Based on the aforementioned automotive bus testing system, such as Figure 3 As shown in the figure, this application provides a method for testing an automotive bus, which includes the following steps:

[0066] S101. Obtain N bus messages generated by the device under test within a first preset time period.

[0067] Where N is a positive integer, the first preset duration is divided into K second preset durations, and K is a positive integer less than N.

[0068] S102. Based on the K second preset durations within the first preset duration, divide the N bus messages into K bus message sets in sequence.

[0069] S103. Sort the K bus message sets according to a preset method.

[0070] The preset sorting methods include one of sequential sorting, reverse sorting, and random sorting.

[0071] S104. Send the sorted K bus message sets to the bus emulation device in sequence.

[0072] In some embodiments, the sorted K bus message sets are sent sequentially to the device under test.

[0073] S105. Obtain the diagnostic fault code (DTC) of the device under test and the response information of the device under test to the processed K bus message sets.

[0074] The response information includes one or more of the message sending period and UDS message response time.

[0075] S106. Determine whether the device under test is normal based on the device under test's DTC and the device under test's response information to the processed K bus message sets.

[0076] In some embodiments, the DTC code of the device under test is used to determine whether the engine and transmission of the device under test are normal; the response information of the device under test to K bus message sets is determined, that is, whether the message sending period and UDS message response time of the device under test are normal, so as to determine whether there is an abnormality in the device under test.

[0077] It should be noted that when the device under test (DUT) is malfunctioning, the DTC code of the DUT will provide information such as the fault area, fault code type, specific problem, fault system, fault category, and fault subtype.

[0078] It should be noted that if the device under test is malfunctioning, there may be a mismatch between the message sending period of the device under test and the preset message sending period.

[0079] It should be noted that if the device under test is malfunctioning, there may be a mismatch between the UDS message response time of the device under test and the preset UDS message response time.

[0080] For example, there are 5 bus message sets, A, B, C, D, and E. A, B, C, D, and E are processed sequentially to obtain the ordered sequence A, B, C, D, and E. This ordered sequence A, B, C, D, and E is then sent sequentially to the device under test (DUT). The DUT's DTC code and its response information to the processed K bus message sets are obtained. Based on the DUT's DTC code and its response information to the processed K bus message sets, it is determined whether one or more of the following functions of the DUT—message transmission period, UDS message response time, communication system function, instrument panel function, and vehicle terminal function—are functioning correctly.

[0081] As can be seen from the above, in the method provided in this application embodiment, K pre-processed bus message sets are periodically sent to the device under test (DUT) to obtain the DTC and response information of the DUT. Based on the DTC and response information of the DUT, it can be determined whether one or more of the following functions of the DUT—message transmission period, UDS message response time, communication system function, instrument panel function, and vehicle terminal function—are normal:

[0082] See Figure 4 As shown in the embodiment of this application, an automotive bus testing method further includes the following steps:

[0083] S201. Obtain M bus messages from N bus messages whose CAN ID of the test device's local area network is less than a first preset value.

[0084] S202. According to the UDS specification, process the message length and message content of M bus messages.

[0085] For example, the message length and content of M bus messages are processed using a programmable testing tool, including: according to the UDS specification, the first byte of the message is the message length, and the message length has a random value range of 0x00 to 0x63, with a length ranging from 1 byte to 64 bytes. For any of the M bus messages: Step 1, flip the second byte in 8-bit units; Step 2, increment the counter by 1 after flipping; Step 3, flip the third byte and restore the original values ​​of other bytes in the bus message; Step 4, flip each byte in the bus message sequentially in the manner of Steps 2-3 until the Xth byte of the bus message.

[0086] Wherein, the effective length is the length of the first byte marker of the bus message; X is the last byte of the bus message.

[0087] S203. Send the processed M bus messages sequentially to the device under test.

[0088] S204. Obtain the DTC of the device under test and the response information of the device under test to the processed M bus messages.

[0089] S205. Determine whether the device under test is normal based on the device's DTC and the device's response information to the processed M bus messages.

[0090] In some embodiments, the response information may be the message transmission period of the device under test (DUT) and the UDS message response time, etc. Based on the DTC and response information of the DUT, it can be determined whether one or more of the following are normal: message transmission period, UDS message response time, communication system function, instrument panel function, and vehicle terminal function.

[0091] As can be seen from the above, in the method provided in this application embodiment, the device under test (DUT) is diagnosed based on the M bus messages with CAN IDs less than a first preset value out of the N bus messages, i.e., the M messages with high priority. If the DUT continuously receives high-priority messages, it will cause the bus load of the DUT to be too high. At this time, the DUT's DTC and response information are used to determine whether the DUT is normal, thus solving the problem in the prior art that it is impossible to diagnose the extreme state of the DUT.

[0092] See Figure 5 As shown in the embodiment of this application, an automotive bus testing method further includes the following steps:

[0093] S301. Obtain P bus messages with CAN ID from N bus messages within a first preset range.

[0094] In some embodiments, the first preset range may be 0x700 to 0x7FF.

[0095] Among them, 0x700 to 0x7FF represent the diagnostic message IDs of the device under test. The bus messages with CAN IDs of 0x700 to 0x7FF store the diagnostic information of the CAN bus of the device under test.

[0096] S302. According to the UDS specification, process the message length and message content of P bus messages.

[0097] For example, a programmable testing tool is used to process the message length and content of N bus messages, including: according to the UDS specification, the first byte of the message is the message length, the message length has a random value range of 0x700 to 0x7FF, and the length varies from 1 byte to 64 bytes. For any of the N bus messages: Step 1, flip the second byte in 8-bit units; Step 2, increment the counter after flipping; Step 3, flip the third byte and restore the original values ​​of other bytes in the bus message; Step 4, flip each byte in the bus message sequentially in the manner of Steps 2-3 until the Xth byte of the bus message.

[0098] S303. Send the processed P bus messages sequentially to the device under test.

[0099] S304. Obtain the DTC of the device under test and the response information of the device under test to the processed P bus messages.

[0100] S305. Determine whether the device under test is normal based on the device's DTC and the device's response information to the processed P bus messages.

[0101] In some embodiments, based on the DTC of the device under test and the corresponding information of the device under test for the processed P bus messages, it is possible to determine whether the device under test uses a secure access algorithm for access control and other issues.

[0102] As can be seen from the above, in the method provided by the embodiments of this application, the device under test is diagnosed based on the CAN ID of P bus messages within the first preset range of the N bus messages of the device under test, that is, based on the diagnostic messages of the device under test. This solves the problem in the prior art that it is impossible to detect whether the device under test is operating normally based on the original messages of the device under test.

[0103] See Figure 6 As shown in the embodiment of this application, an automotive bus testing method further includes the following steps:

[0104] S401. According to the UDS specification, randomly generate W bus messages with CAN IDs within the second preset range.

[0105] In some embodiments, the second preset range may be from 0x01 to 0x7FF.

[0106] Among them, 0x01 to 0x7FF is the range of possible values ​​for the CANID of a CAN data frame using an 11-bit identifier as defined in the CAN2.0B specification.

[0107] In some embodiments, according to the UDS specification, and in combination with the N bus messages obtained, W bus messages with CAN IDs from 0x01 to 0x7FF and message lengths from 1 byte to 64 bytes are randomly generated.

[0108] S402. Send the W randomly generated bus messages to the device under test in sequence.

[0109] S403. Obtain the DTC of the device under test and the response information of the device under test to W randomly generated bus messages.

[0110] S404. Determine whether the device under test (DUT) is functioning properly based on the DTC of the DUT and the response information of the DUT to W randomly generated bus messages.

[0111] As can be seen from the above, in the method provided in this application embodiment, W randomly generated bus messages are used to perform diagnostic tests on the device under test. The system can determine whether the device under test is functioning correctly based on the W randomly generated bus messages and the response information of the device under test. Using a random generation method to generate messages for diagnosing the device under test reduces testing costs.

[0112] This application embodiment can, based on the above method, exemplarily divide an automotive bus testing system or electronic device into functional modules. For example, the automotive bus testing system or electronic device may include functional modules corresponding to each functional division, or two or more functions may be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module. It should be noted that the module division in this application embodiment is illustrative and only represents one logical functional division; in actual implementation, there may be other division methods.

[0113] Figure 7 This is a schematic diagram illustrating the structure of an electronic device according to an exemplary embodiment. For example... Figure 7 As shown, the electronic device 50 includes, but is not limited to, a processor 501 and a memory 502.

[0114] The memory 502 described above is used to store the executable instructions of the processor 501. It is understood that the processor 501 is configured to execute instructions to implement the automotive bus testing method in the above embodiments.

[0115] It should be noted that those skilled in the art will understand that Figure 7 The electronic device structure shown does not constitute a limitation on the electronic device; the electronic device may include, but is not limited to, other electronic devices. Figure 7 This may indicate more or fewer components, or a combination of certain components, or a different arrangement of components.

[0116] Processor 501 is the control center of the electronic device. It connects various parts of the electronic device via various interfaces and lines. By running or executing software programs and / or modules stored in memory 502, and by calling data stored in memory 502, it performs various functions and processes data, thereby providing overall monitoring of the electronic device. Processor 501 may include one or more processing units. Optionally, processor 501 may integrate an application processor and a modem processor. The application processor mainly handles the operating system, user interface, and applications, while the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into processor 501.

[0117] The memory 502 can be used to store software programs and various data. The memory 502 may primarily include a program storage area and a data storage area. The program storage area may store the operating system, application programs required by at least one functional module (such as a determination unit, processing unit, etc.), etc. Furthermore, the memory 502 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0118] In an exemplary embodiment, a computer-readable storage medium including instructions is also provided, such as a memory 502 including instructions, which can be executed by a processor 501 of an electronic device 50 to implement the automotive bus testing method in the above embodiments.

[0119] In actual implementation, Figure 1 The functions of the device under test, bus emulation device, and test device can all be provided by... Figure 7 The processor 501 calls the computer program stored in the memory 502 to implement the test. The specific execution process can be found in the description of the automotive bus testing method section of the previous embodiment, and will not be repeated here.

[0120] Through the above description of the embodiments, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0121] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another apparatus, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0122] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the classified units can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0123] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0124] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solution of the embodiments of this application, essentially, or the part that contributes to the prior art, or a complete or partial classification of the technical solution, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0125] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. An automotive bus testing system, characterized in that, include: Bus emulation equipment, device under test (DUT), and testing equipment; The bus emulation device is electrically connected to both the device under test and the test device. The bus simulation device is configured to: acquire N bus messages generated by the device under test within a first preset time period, and send the N bus messages to the test device; wherein, the first preset time period is divided into K second preset time periods, N is a positive integer, and K is a positive integer less than N; The test device is configured to: receive the N bus messages sent by the bus simulation device; divide the N bus messages into K bus message sets according to K second preset durations within a first preset duration; sort the K bus message sets according to a preset method; and send the sorted K bus message sets to the bus simulation device sequentially; the preset method includes one of sequential sorting, reverse sorting, and random sorting. The bus emulation device is further configured to: send a sorted set of K bus messages sent by the test device to the device under test; obtain the Diagnostic Trouble Code (DTC) of the device under test and the response information of the device under test; and send the DTC and the response information to the test device; wherein the response information includes one or more of the following: message sending period, Unified Diagnostic Service (UDS) message response time, and UDS message content. The test device is also configured to: receive the DTC and the response information sent by the bus emulation device; and determine whether the device under test is normal based on the DTC and the response information.

2. The system according to claim 1, characterized in that, The test device is also configured to: obtain M bus messages whose CAN ID of the test device's local area network is less than a first preset value from the N bus messages; and process the message length and message content of the M bus messages according to the UDS specification; The processed M bus messages are sent sequentially to the bus emulation device; M is a positive integer less than N; The bus emulation device is further configured to send the processed M bus messages sent by the test device to the device under test.

3. The system according to claim 1, characterized in that, The test device is also configured to: obtain P bus messages with CAN ID within a first preset range from the N bus messages; According to the UDS specification, the message length and message content of the P bus messages are processed; The processed P bus messages are sequentially sent to the bus emulation device; where P is a positive integer less than N, and the first preset range represents the range of diagnostic message IDs of the device under test; The bus emulation device is further configured to send P processed bus messages sent by the test device to the device under test.

4. The system according to claim 1, characterized in that, The test device is also configured to: randomly generate W bus messages with CAN IDs within a second preset range according to the UDS specification; and sequentially send the W bus messages to the bus simulation device; wherein W is a positive integer and the length of any bus message is within the second preset range. The bus emulation device is also configured to send W bus messages sent by the test device to the device under test.

5. The system according to claim 1, characterized in that, The test equipment is specifically configured to determine, based on the DTC and the response information, whether one or more of the following are normal: message transmission period, UDS message response time, communication system function, instrument panel function, and vehicle terminal function of the device under test.

6. A method for testing automotive bus systems, characterized in that, The method includes: The bus simulation device acquires N bus messages generated by the device under test within a first preset time period and sends the N bus messages to the test device; wherein, the first preset time period is divided into K second preset time periods, N is a positive integer, and K is a positive integer less than N; The test device receives the N bus messages sent by the bus simulation device, and divides the N bus messages into K bus message sets according to K second preset durations within a first preset duration. The test device sorts the K bus message sets according to a preset method and sends the sorted K bus message sets to the bus simulation device sequentially; the preset method includes one of sequential sorting, reverse sorting, and random sorting. The bus simulation device sequentially sends the processed K bus message sets to the device under test. The bus emulation device acquires the Diagnostic Trouble Code (DTC) of the device under test (DUT) and the response information of the DUT, and sends the DTC and the response information to the test device; the response information includes one or more of the following: message sending period, Unified Diagnostic Service (UDS) message response time, and UDS message content. The test device receives the DTC and response information sent by the bus emulation device, and determines whether the device under test is normal based on the DTC and response information.

7. The method according to claim 6, characterized in that, The method further includes: The test device obtains M bus messages from the N bus messages whose CAN ID is less than a first preset value; M is a positive integer less than N. The test device processes the message length and message content of the M bus messages according to the UDS specification, and then sends the processed M bus messages to the bus simulation device in sequence. The bus emulation device sequentially sends the processed M bus messages sent by the test device to the device under test.

8. The method according to claim 6, characterized in that, The method further includes: The test device obtains P bus messages with CAN IDs within a first preset range from the N bus messages; where P is a positive integer less than N, and the first preset range represents the range of diagnostic message IDs of the device under test; The test equipment processes the message length and message content of the P bus messages according to the UDS specification, and then sends the processed P bus messages to the bus simulation equipment in sequence. The bus emulation device sequentially sends the P processed bus messages sent by the test device to the device under test.

9. The method according to claim 6, characterized in that, The method further includes: According to the UDS specification, the test device randomly generates W bus messages with CAN IDs within a second preset range, and sends the W bus messages sequentially to the bus simulation device; where W is a positive integer, and the length of any bus message is within the second preset range. The bus emulation device sends the W bus messages sent by the test device to the device under test.

10. The method according to claim 6, characterized in that, The step of determining whether the device under test is normal based on the DTC and the response information includes: The testing equipment determines, based on the DTC and the response information, whether one or more of the following functions of the device under test are normal: message transmission period, UDS message response time, communication system function, instrument panel function, and vehicle terminal function.

11. An electronic device, characterized in that, include: Memory and processor; The memory is used to store computer execution instructions; when the electronic device is running, the processor executes the computer execution instructions stored in the memory to cause the electronic device to perform the method as described in any one of claims 6 to 10.

12. A computer-readable storage medium, characterized in that, When the computer-executable instructions stored in the computer-readable storage medium are executed by the processor of the electronic device, the electronic device is capable of performing the method as described in any one of claims 6 to 10.

Images