Test method of data message in vehicle-mounted network system, vehicle and storage medium

Abstract

The embodiment of the invention provides a method for testing a data message in a vehicle-mounted network system, a vehicle and a storage medium, the vehicle-mounted network system comprises a plurality of vehicle-mounted network communication nodes and at least one transmission channel, the method comprises the following steps: in response to a test instruction, determining a target communication node from the plurality of vehicle-mounted network communication nodes, the test instruction is at least used for representing a to-be-tested message demand and a test demand; determining at least one to-be-tested data message meeting the requirement of the to-be-tested message from at least one to-be-transmitted data message in the target communication node; determining at least one target data field meeting the test requirement from the to-be-tested data message; calling a test strategy corresponding to the target data field, and testing the target data field to obtain a test sub-result; and determining a test result of the to-be-tested data message based on the at least one test sub-result corresponding to the at least one target data field. According to the invention, the technical problem of low test efficiency of the data message in the vehicle-mounted network system is solved.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of vehicle network communication security technology, and more specifically, to a method for testing data messages in a vehicle network system, a vehicle, and a storage medium. Background Art

[0002] As vehicles become increasingly intelligent and connected, their in-vehicle network systems are becoming increasingly complex, leading to a dramatic increase in communication demands. The reliability and stability of in-vehicle network systems directly impact the overall performance of the vehicle and the safety of its drivers and passengers. To address this, an end-to-end (E2E) communication protection mechanism has been proposed to ensure that data messages are not interfered with or tampered with during transmission from one in-vehicle network communication node to another.

[0003] In related technologies, for the E2E mechanism testing process, test engineers need to manually input each message data of each in-vehicle network communication node into a dedicated Cyclic Redundancy Check (CRC) calculator, and calculate and compare the CRC value for each data message.

[0004] However, the above method is not only time-consuming but also multiplies the workload due to the manual CRC calculation of each data message, seriously affecting the progress of data message testing. Therefore, the technical problem of low test efficiency of data messages in the vehicle network system still exists.

[0005] There is currently no good solution to the above problems. Summary of the Invention

[0006] Embodiments of the present application provide a method, a vehicle, and a storage medium for testing data messages in an in-vehicle network system, so as to at least solve the technical problem of low testing efficiency of data messages in the in-vehicle network system.

[0007] According to one aspect of an embodiment of the present application, a method for testing data messages in an in-vehicle network system is provided, wherein the in-vehicle network system includes multiple in-vehicle network communication nodes and at least one transmission channel, and the in-vehicle network communication nodes are used to transmit data messages to each other through the transmission channel. The method may include: responding to a test instruction, determining a target communication node from the multiple in-vehicle network communication nodes, wherein the test instruction is used to at least indicate the message requirements and the test requirements to be tested; determining at least one data message to be tested that meets the message requirements to be tested from at least one data message to be transmitted from the target communication node; determining at least one target data field that meets the test requirements from the data message to be tested; calling a test strategy corresponding to the target data field, testing the target data field, and obtaining a test sub-result, wherein the test strategy is used to test the completeness of the target data field; and determining a test result of the data message to be tested based on at least one test sub-result corresponding to the at least one target data field, wherein the test result is used to indicate whether the data message to be tested meets the transmission requirements of the target transmission channel, and the target transmission channel is a transmission channel connected to the target communication node in the at least one transmission channel.

[0008] Furthermore, the test requirement includes a position identifier, which is used to indicate at least one position of at least one target data field in the data message to be tested. Determining at least one target data field that meets the test requirement from the data message to be tested includes: determining at least one target byte that meets the position identifier from at least one byte of the data message to be tested; determining at least one target bit that meets the position identifier from at least one bit of the target byte, wherein the byte includes at least one bit; and determining the data field at the target bit under the target byte in the data message to be tested as the target data field.

[0009] Furthermore, the target data field includes a function data field, which is used to trigger the execution of a corresponding function on a vehicle associated with the in-vehicle network system. The field area of ​​the data message to be tested includes a first field area and a second field area. The first field area at least includes the function data field, and the second field area is a field area other than the first field area in the field area. From at least one byte of the data message to be tested, at least one target byte that meets the position identifier is determined. The method includes at least one of the following: in response to the position identifier including the position of the function data field in the first field area, determining the target byte of the function data field from the first field area; in response to the position identifier including the position of the target data field other than the function data field in the first field area, determining the target byte of the target data field other than the function data field from the first field area; in response to the position identifier including the position of the target data field in the second field area, determining the target byte of the target data field from the second field area.

[0010] Furthermore, the message requirement to be tested includes a target channel identifier and a target message identifier, and determining at least one data message to be tested that meets the message requirement to be tested from at least one data message to be transmitted in the vehicle network communication node includes: based on the target channel identifier, determining at least one initial data message from at least one data message to be transmitted in the vehicle network communication node, wherein the initial data message is a data message that needs to be transmitted through a target transmission channel whose channel identifier is the target channel identifier; based on the target message identifier, determining at least one data message to be tested from at least one initial data message, wherein the message identifier of the data message to be tested is the target message identifier; the message requirement to be tested also includes a target node identifier, and determining the vehicle network communication node from multiple vehicle network communication nodes in response to the test instruction includes: based on the vehicle network communication node identifier, determining the target communication node from multiple vehicle network communication nodes, wherein the node identifier of the target communication node is the target node identifier.

[0011] Furthermore, the method also includes: determining a test strategy from at least one candidate test strategy based on the bit attribute of the data message to be tested, wherein the bit attribute is used to represent the number of bits included in the byte in the data message to be tested; calling the test strategy corresponding to the target data field, testing the target data field, and obtaining a test sub-result, including: calling the test strategy, traversing the byte value of the target bit under the target byte where the target data field is located; in the process of traversing the byte value, performing an XOR operation on the traversed byte value and a preset byte value to obtain an operation result; in response to the operation result being that the byte value and the preset byte value are the same, determining that the test sub-result is that the integrity of the target data field is greater than or equal to the integrity threshold.

[0012] Furthermore, based on the bit attributes of the data message to be tested, a test strategy is determined from the candidate test strategies, including: determining the candidate test strategy whose bit identifier is greater than or equal to the bit attribute from at least one candidate test strategy as the test strategy, wherein the bit identifier is used to indicate the number of bits that the candidate test strategy can process; calling the test strategy to traverse the byte value of the target bit under the target byte where the target data field is located, including: in response to the bit attribute being less than the bit identifier of the test strategy, adjusting the target bit to obtain the adjusted target bit, wherein the number of adjusted target bits is the same as the bit identifier; calling the test strategy to traverse the byte value of the adjusted target bit.

[0013] Furthermore, the test strategy is called to traverse the byte values ​​of the target bits under the target byte where the target data field is located, including: in response to the number of target bits of the target data field being greater than the bit attribute, splitting the target bits to obtain at least two target bit groups; traversing the byte values ​​of the target bit groups respectively; the method also includes: in response to the test result that the data message to be tested meets the transmission requirements, using the target transmission channel to send the data message to be tested to the corresponding vehicle network communication node, wherein the vehicle network communication node that receives the data message to be tested is used to trigger the execution of corresponding functions on the vehicle associated with the vehicle network system.

[0014] According to another aspect of an embodiment of the present application, another method for testing data messages in a vehicle network system is provided, including: in response to an input operation on a test interface, displaying on the test interface the message requirements and test requirements for testing the data message to be tested in the vehicle network system, wherein the vehicle network system includes multiple vehicle network communication nodes and at least one transmission channel, and the vehicle network communication nodes are used to transmit data messages to each other through the transmission channel; in response to a test operation on the test interface, displaying the test result of the data message to be tested on the test interface, wherein the test result is obtained by calling a preset test script according to any of the above methods; the method also includes: in response to a reset operation on the test interface, displaying the reset result on the test interface, wherein the reset result is used to indicate that the test of the data message to be tested executed by calling the preset test script under the current test process is successfully cleared, and the next test process of the current test process is started.

[0015] According to another aspect of an embodiment of the present application, a vehicle is further provided, comprising: a memory storing an executable program; and a processor for running the program, wherein the method of each embodiment of the present application is executed when the program is running.

[0016] According to another aspect of an embodiment of the present application, a computer-readable storage medium is also provided, which includes a stored executable program, wherein when the executable program is running, the device where the computer-readable storage medium is located is controlled to execute the methods in various embodiments of the present application.

[0017] According to another aspect of the embodiments of the present application, a computer program product is further provided, including a computer program, which implements the methods in various embodiments of the present application when executed by a processor.

[0018] According to another aspect of an embodiment of the present application, a computer program product is further provided, including a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the method in each embodiment of the present application is implemented.

[0019] According to another aspect of the embodiments of the present application, a computer program is further provided, which implements the methods in various embodiments of the present application when executed by a processor.

[0020] In an embodiment of the present application, if a test instruction is detected to test data messages in an onboard network system, the onboard network communication node to be tested can be identified as the target communication node from multiple onboard network communication nodes. Based on the test message requirements in the test instruction, the data message to be tested can be identified from the data messages to be transmitted in the target communication node. Based on the test requirements during the test execution, the target data field can be identified from multiple data fields in the test data message. A test strategy corresponding to the target data field is invoked to test the corresponding target data field, resulting in a test sub-result. The test sub-result can be used to determine a test result that can assess whether the data message to be tested meets the transmission requirements of the target transmission channel. In other words, in response to the test instruction from the tester, the embodiment of the present application automatically selects the target communication node and the data message to be tested, and accurately locates the target data field to be verified in the data message to be tested. Using a pre-set test strategy, the target data field is efficiently batch-tested, quickly obtaining test sub-results, and then generating a comprehensive test result to determine whether the data message meets the transmission requirements of the target transmission channel. Aside from the need to manually trigger test commands, the entire test process requires no human intervention, reducing test time and human resource consumption. This improves the efficiency of testing data packets in the vehicle network system and resolves the problem of low testing efficiency in the vehicle network system. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0022] Figure 1 is a flow chart of a method for testing data packets in a vehicle network system according to an embodiment of the present application;

[0023] Figure 2 is a flowchart of another method for testing data packets in an in-vehicle network system according to an embodiment of the present application;

[0024] Figure 3 is a schematic diagram of an example layout of a data field of an E2E communication message according to an embodiment of the present application;

[0025] Figure 4 is a schematic diagram of a process for determining an E2E check value according to an embodiment of the present application;

[0026] Figure 5 is a schematic diagram of an in-vehicle network E2E automated testing environment according to an embodiment of the present application;

[0027] Figure 6 is a schematic diagram of a test panel according to an embodiment of the present application;

[0028] Figure 7 is a schematic diagram of another test panel according to an embodiment of the present application;

[0029] Figure 8 is a schematic diagram of a test result according to an embodiment of the present application;

[0030] Figure 9 is a schematic diagram of a device for testing data packets in a vehicle network system according to an embodiment of the present invention;

[0031] Figure 10 2 is a schematic diagram of another device for testing data messages in a vehicle network system according to an embodiment of the present invention. DETAILED DESCRIPTION

[0032] In order to enable those skilled in the art to better understand the present invention, the following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments in the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of this application.

[0033] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequential order. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in a sequence other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0034] According to an embodiment of the present application, an embodiment of a method for testing data messages in an in-vehicle network system is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0035] In this embodiment, a method for testing data packets in a vehicle network system is provided. Figure 1 Flowchart of a method for testing data packets in a vehicle network system according to an embodiment of the present application. Figure 1 As shown, it may include terminal device A, network B and server C. Terminal device A may be a mobile phone, a laptop computer or a desktop computer. If a test instruction sent by terminal device A is detected, the test instruction may be transmitted to server C via network B. In server C, the method includes the following steps:

[0036] Step S102 : responding to the test instruction, determining a target communication node from a plurality of vehicle network communication nodes.

[0037] In the technical solution provided in the above step S102 of the embodiment of the present application, if a test instruction for testing a data message in the vehicle network system is detected, a target communication node can be determined from multiple vehicle network communication nodes in the vehicle network system.

[0038] In this embodiment, the vehicle network system includes multiple vehicle network communication nodes and at least one transmission channel. The vehicle network communication nodes are used to transmit data messages to each other through the transmission channel. The vehicle network system is a network architecture in the vehicle for realizing communication between the various electronic control units (Electronic Control Unit, referred to as ECU) in the vehicle. The vehicle network system can be a vehicle heterogeneous network, that is, a transmission channel containing multiple different network technologies. Among them, the network technology can include Controller Area Network (CAN), Local Interconnect Network (LIN), Media Oriented Systems Transport (MOST), Ethernet, etc.

[0039] Optionally, the in-vehicle network communication node can be an ECU, used to trigger the execution of corresponding vehicle functions based on message data. A transmission channel is a physical or logical channel for data message transmission between ECUs. Different channels can use different network technologies. For example, the CAN transmission channel is used for real-time, high-security data message transmission, while the LIN transmission channel is used for low-speed, low-power data message transmission.

[0040] Optionally, the test instruction is at least used to indicate the message requirements to be tested and the test requirements. The test instruction can be a command or signal for triggering automatic testing of data messages, which can be initiated by a test engineer or an automated testing tool. The message requirements to be tested can be used to indicate the tester's specific requirements for the data message to be tested, such as the identification of the vehicle network communication node that initiates the data message, the type of the data message, the identifier (ID), the cycle, the data field, the transmission channel for the required transmission of the data message, etc., which are used to accurately filter out the data messages that need to be tested from the data messages that need to be transmitted by a large number of target communication nodes. The test requirements can be used to indicate the tester's specific requirements for the data fields in the data message to be tested, such as the test requirements for data fields that can evaluate whether the data message is complete or erroneous. The target communication node can be the device under test (DUT).

[0041] In this embodiment, if a test command is triggered, the test command can be parsed to extract the test message requirements and test requirements, thereby understanding the test intent of the tester or automated test tool. Based on the test message requirements and test requirements, the target communication node that sends the data message to be tested is determined from the large number of vehicle network communication nodes in the vehicle network system.

[0042] For example, if the tester has the function of testing the data message transmitted by the body control module in the vehicle network system via the CAN transmission channel, he can enter or select the body control module as the target communication node on the test interface of the terminal device, and enter the CAN transmission channel as the message requirement to be tested. He can then click the control to start the test to trigger the corresponding test instruction. This will test the data message transmitted by the body control module via the CAN transmission channel. It should be noted that the above method and process of triggering the test instruction are for illustrative purposes only and are not specifically limited here.

[0043] For another example, if the vehicle network communication node ID of the data message to be transmitted for testing is parsed from the test instruction, multiple vehicle network communication nodes can be traversed to find the vehicle network communication node that meets the above vehicle network communication node ID as the target communication node.

[0044] It should be noted that the above information parsed from the test instructions and used to determine the target communication node is for illustration only and is not specifically limited here. As long as the target communication node to be tested and the data message therein can be automatically located according to the test instructions, they are within the protection scope of the embodiments of this application.

[0045] Step S104 : determining at least one data message to be tested that meets the requirement of the message to be tested from the at least one data message to be transmitted in the target communication node.

[0046] In the technical solution provided in step S104 of the embodiment of the present application, after determining the target communication node from the plurality of in-vehicle network communication nodes, at least one data message to be transmitted from the target communication node that meets the test message requirements can be determined. The above method is intended to automatically and accurately select data messages that meet the test requirements to facilitate subsequent detailed testing and analysis.

[0047] In this embodiment, the data message to be tested can be a data message in the target communication node that meets the test message requirements in the test instruction. The data message to be tested can include at least one data field, which can include a counter field, a CRC checksum field, a data identification field, a timeout monitoring field, and a function data field. The function data field can be a specific information unit transmitted between vehicle network communication nodes, such as vehicle sensor data, control commands, status information, etc., and can be used for interaction between vehicle ECUs to implement various vehicle function controls.

[0048] Optionally, after determining the target communication node, data packets to be transmitted can be captured and analyzed from the target communication node. During the analysis of the data packets to be transmitted, each data field contained in the data packets can be parsed. Based on the aforementioned test message requirements and the results of parsing each data packet, data packets that meet the test message requirements are selected as the test data packets.

[0049] For example, if the test message requirement is the Data ID of the data message to be tested, and the transmission channel of the data message to be tested is a CAN channel, the data messages transmitted according to the CAN channel can be filtered out from the data messages to be transmitted. Then, from the data messages transmitted according to the above CAN channel, the data messages that meet the above Data ID are filtered out as the data messages to be tested.

[0050] For another example, if the test message requirement specifies that the transmission channel of the data message to be tested is a CAN channel, and the function data field corresponds to the function to be triggered, then the data messages to be transmitted in the target communication node can be filtered to select data messages transmitted according to the CAN channel. Furthermore, from the data messages transmitted according to the CAN channel, data messages with the function data field can be filtered to serve as the data messages to be tested.

[0051] It should be noted that the contents included in the above-mentioned message requirements to be tested, as well as the process and method for determining the data message to be tested according to the message requirements to be tested are only for illustration and no specific restrictions are imposed here. As long as the process and method can automatically select the data message to be tested according to the message requirements to be tested, they are within the scope of protection of the embodiments of this application.

[0052] In the embodiments of the present application, automatic and accurate selection of test data packets based on test message requirements allows for centralized verification of the transmission quality and communication protocol compliance of the data packets required by the tester, thereby improving the overall reliability of the in-vehicle network system. Furthermore, this automatic screening method avoids the time-consuming and costly process of manually identifying the data packets to be tested one by one.

[0053] Step S106: Determine at least one target data field that meets the test requirements from the data message to be tested.

[0054] In the technical solution provided in the above step S106 of the embodiment of the present application, after determining the data message to be tested from the data message to be transmitted from the target communication node, the target data field that meets the test requirements can be determined from the data field in the data message to be tested.

[0055] In this embodiment, the target data field can be a data field that can be used to verify the integrity of the data message to be tested, thereby ensuring the communication security of the vehicle network system. For example, it can include a Counter field, a Checksum field, a DataID field, and a Function Data field. The Counter field can be used to identify whether the data message is sent in the correct order. The Checksum field can be used to identify whether an error (such as tampering or damage) occurred during the data message transmission process, thereby ensuring the integrity of the data message.

[0056] Optionally, the data message under test undergoes in-depth analysis, for example, understanding the message structure, including identifying components such as the header and data fields. While parsing the data message, the test system can clarify the test requirements. Based on the test requirements, the test system identifies and selects at least one data field from the data message as the target field. For example, this may include data fields that have a direct impact on the functionality, safety, or performance of the in-vehicle network system, or data fields whose characteristics and functions are relevant to the test requirements.

[0057] In the embodiments of the present application, by determining the target digital fields that meet the test requirements, data packet testing can be focused directly on the target data fields that affect the integrity and security of data packet transmission, avoiding redundant testing of irrelevant data fields and significantly shortening testing time. In other words, the above method can achieve precise testing at the data field level, rather than crude testing at the data packet level.

[0058] Step S108: calling the test strategy corresponding to the target data field, testing the target data field, and obtaining a test sub-result.

[0059] In the technical solution provided in the above step S108 of the embodiment of the present application, after determining the target data field that meets the test requirements from the data message to be tested, the test strategy corresponding to the target data field can be called to test the target data field to obtain the test sub-result.

[0060] In this embodiment, the test strategy is used to test the integrity of the target data field, and then to evaluate the accuracy of the corresponding function in the vehicle triggered this time, and can be a CRC algorithm polynomial. The test strategy can be determined based on the number of bits of the target data field. For example, if the number of bits of the target field is 7 or 8, the test strategy can be a CRC-8 algorithm polynomial. If the number of bits of the target field is 15 or 16, the test strategy can be a CRC-16 algorithm polynomial. Optionally, the test sub-result can be a calculation sequence corresponding to the target data field that needs to be subsequently involved in calculating the test result. It should be noted that the above-mentioned test strategy determination process and method are only for illustration and are not specifically limited here.

[0061] Optionally, after determining the test strategy, a corresponding test is performed on the target data field to verify the integrity of the target data field. The target data field is extracted from the data message to be tested and the corresponding CRC algorithm polynomial is applied to perform an integrity check on the target data field. For example, the CRC algorithm polynomial is used to calculate the data in each byte and bit in the target data field to obtain a test sub-result.

[0062] In an embodiment of the present application, integrity verification of the data field bit level is achieved by calling a specific CRC polynomial operation. The above-mentioned bit-accurate verification method can detect and locate subtle errors in the lowest-level data message transmission, significantly improving the reliability of vehicle network communications. By executing the CRC algorithm in an automated manner, not only the time and human resources required for manual testing are greatly reduced, but also the consistency and accuracy of the test are ensured because the interference of human factors is avoided. In addition, the flexible calling of the test strategy means that it can adapt to the test requirements of target data fields with different bit numbers, thereby ensuring the coverage and efficiency of the test strategy.

[0063] Step S110 : determining a test result of the data message to be tested based on at least one test sub-result corresponding to at least one target data field.

[0064] In the technical solution provided in the above step S110 of the embodiment of the present application, after the target data field is tested and a test sub-result is obtained, the test result of the data message to be tested can be determined based on the test sub-result.

[0065] Optionally, the test result indicates whether the data packet under test meets the transmission requirements of a target transmission channel, where the target transmission channel is the transmission channel connected to the target communication node in the at least one transmission channel. The test result may be a CRC checksum, such as a CRC checksum, which may be calculated using the aforementioned test sub-results.

[0066] Optionally, after determining the CRC Checksum based on the test sub-result, it can be compared with the Checksum field in the data message to be tested. If the two are the same, it can be said that the data message to be tested meets the transmission requirements ("OK"), that is, the data message to be tested is complete, has no errors, and can be transmitted through the target transmission channel. Conversely, if the two are different, it can be said that the data message to be tested does not meet the transmission requirements ("Not OK"), that is, the data message to be tested has errors and cannot be transmitted through the target transmission channel.

[0067] In an embodiment of the present application, when testing a test message using the above method, not only CRC verification can be implemented, but also counter value verification can be implemented simultaneously. The CRC verification can be used to ensure the integrity of the data message during transmission, and the counter value verification can be used to prevent data message replay. The above method can evaluate the integrity of the data message during transmission, effectively improving the overall reliability and functional safety of the in-vehicle network system. By automatically triggering a comprehensive test process, the test efficiency of the test data message can be improved.

[0068] In the above-mentioned steps S102 to S110 of the embodiment of the present application, if a test instruction for testing a data message in the vehicle network system is detected, the vehicle network communication node that needs to be tested this time can be determined as the target communication node from multiple vehicle network communication nodes. According to the test message requirements in the test instruction, the data message to be tested this time that needs to be tested is determined from the data message to be transmitted in the target communication node. According to the test requirements during the test execution, the target data field can be determined from multiple data fields in the test data message. The test strategy corresponding to the target data field is called to test the corresponding target data field to obtain a test sub-result. The test sub-result can be used to determine a test result that can evaluate whether the data message to be tested meets the transmission requirements of the target transmission channel. That is, the embodiment of the present application automatically filters out the target communication node and the data message to be tested by responding to the test instruction of the tester, and accurately locates the target data field to be tested in the data message to be tested. Using pre-defined test strategies, efficient batch testing of target data fields is performed, quickly generating sub-test results and ultimately generating comprehensive test results to determine whether the data message meets the transmission requirements of the target transmission channel. Aside from the need to manually trigger test commands, the entire testing process requires no human intervention, reducing testing time and human resources. This improves the testing efficiency of data messages in in-vehicle network systems and addresses the inherently low testing efficiency.

[0069] The embodiments of the present application are described in detail below in combination with the above steps.

[0070] As an optional embodiment, the test requirement includes a position identifier, which is used to indicate at least one position of at least one target data field in the data message to be tested. Step S106 determines at least one target data field that meets the test requirement from the data message to be tested, including: determining at least one target byte that meets the position identifier from at least one byte of the data message to be tested; determining at least one target bit that meets the position identifier from at least one bit of the target byte, wherein the byte includes at least one bit; and determining the data field at the target bit under the target byte in the data message to be tested as the target data field.

[0071] In this embodiment, according to the position identifier in the test requirement, the target byte can be determined from at least one byte of the data message to be tested. Further, according to the position identifier, the target bit position can be determined from at least one bit position in the target byte. Thus, the data field at the target bit position under the target byte can be determined as the target data field. Among them, the test requirement may include a position identifier. The position identifier can be used to indicate the position of the target data field in the data message to be tested, for example, it can be a CRC number (CRC Number), which can be used to identify the area in the data message to be tested that needs to be CRC checked, that is, it can be used to indicate which data fields in the data message to be tested need to participate in the CRC check calculation, and the position of the above-mentioned data fields in the data message to be tested.

[0072] Optionally, the CRC Number is a form of location identifier used to identify areas in a data message that require CRC verification. For example, in a data message, there may be multiple CRC verification fields, and each target data field may be located at different bytes and bits. The CRC Number can be used to quickly locate the target data field. It should be noted that the above location identifier is only for illustration and is not specifically limited here. As long as the information can locate the target data field, it is within the scope of protection of the embodiments of the present application.

[0073] Optionally, this embodiment describes the process of accurately screening target data fields that meet test requirements from the data message to be tested, and the process is based on a position identifier. The position identifier is used to indicate the specific position of the target data field in the data message, and may include a target byte and a target bit.

[0074] Optionally, based on the position identifier provided by the test requirements, determine which bytes in the data message are the target bytes. Bytes refer to the basic units that make up a data message, and each byte can be composed of 8 bits. For example, if the CRC Number is 3, it can be said that the third byte in the data message to be tested is the target byte. For example, in Byte0 to Byte7, Byte2 is the target byte and needs to be further analyzed. Once the target byte is determined, the target bit in the target byte is locked. The bit is the smallest unit in data message transmission, and the combination of 0 and 1 can carry and transmit data. Through the position identifier, you can know which bits are involved in a specific CRC check calculation. It should be noted that only some bits in a byte can be valid data, and the remaining bits can be padding bits or part of other data fields.

[0075] Optionally, combining the target byte and target bit position, the data field at the target bit position below the target byte is extracted from the data message to be tested and determined as the target data field. The target data field is the main input for the subsequent CRC check calculation and directly determines the accuracy and effectiveness of the check.

[0076] Optional, hierarchical positioning from bytes to bits ensures test accuracy and flexibility. In some communication protocols, data fields may span multiple bytes, or only a portion of the bits in a byte may be used. This hierarchical positioning capability enables test strategies to adapt to various complex data structures, improving test coverage and accuracy.

[0077] In the embodiment of the present application, the target data field to be tested can be quickly located by the guidance of the location identifier, avoiding unnecessary analysis of the entire data message to be tested, and greatly improving the test efficiency. The hierarchical positioning strategy ensures the accurate identification of the target data field, helps to accurately execute the CRC check, reduces the false detection rate and missed detection rate, and improves the reliability and accuracy of the test. The above method takes into account the diversity of data structures in data messages. By adjusting the location identifier, it can easily adapt to different test requirements. Whether it is an existing communication protocol or a new communication protocol that may appear in the future, the flexible application of the test strategy can be achieved by fine-tuning the location identifier.

[0078] As an optional embodiment, the target data field includes a function data field, and the function data field is used to trigger the execution of a corresponding function on a vehicle associated with the in-vehicle network system. The field area of ​​the data message to be tested includes a first field area and a second field area. The first field area at least includes the function data field, and the second field area is a field area other than the first field area in the field area. From at least one byte of the data message to be tested, at least one target byte that meets the position identifier is determined. The method includes at least one of the following: in response to the position identifier including the position of the function data field in the first field area, determining the target byte of the function data field from the first field area; in response to the position identifier including the position of the target data field other than the function data field in the first field area, determining the target byte of the target data field other than the function data field from the first field area; in response to the position identifier including the position of the target data field in the second field area, determining the target byte of the target data field from the second field area.

[0079] In this embodiment, the target data field may include a function data field. The function data field may be used to trigger the execution of a corresponding function on a vehicle associated with the vehicle network system. It may be signal (Signal, abbreviated as Sig) data, such as Sig1, Sig2, etc. The field area of ​​the data message to be tested may include a first field area and a second field area. The first field area includes at least a function data field, and may also be referred to as a message data field or an E2E signal group. The target data field other than the function data field in the first field area may include a Counter field and a Checksum field. The second field area may be a field area other than the first field area in the field area, and may also be referred to as a non-message data field. The data field in the second field area may include a Data ID field, a Timeout monitoring field, etc.

[0080] Optionally, if the location identifier provides the specific location of the function data field within the first field area, the byte carrying the function data in the data message under test can be accurately located. Function data represents actual vehicle operating commands or status information, and verifying the correctness and integrity of the function data field is crucial to ensuring safe vehicle operation.

[0081] Optionally, in addition to the functional data field, the first field area may also include other target data fields. If the position identifier provides the position of the target data field of the non-functional data field in the first field area, the position of the target data field can be determined by locating the target byte to perform targeted testing.

[0082] Optionally, the target data field in the second field area, while not directly related to vehicle function execution, can be used for checksum control of the data message under test. If the location identifier provides the location of the target data field in the second field area, the corresponding target byte can be located to perform the necessary checksum testing.

[0083] In the embodiment of the present application, since the functional data field and other target data fields can be clearly distinguished according to the location identifier, it is possible to more accurately focus on those functional data fields that are directly related to the vehicle function, thereby improving the test efficiency. Even non-functional data fields and target data fields in the second field area can be tested through the location identifier to ensure the integrity of the data message to be tested during the transmission process and the effectiveness of the verification mechanism. The above method significantly enhances the control capability and security of the vehicle network system for the execution of vehicle functions by ensuring the accurate communication of the functional data field and the integrity of the E2E protection mechanism that supports its correct execution, thereby reducing the potential risk of failure of the vehicle network system.

[0084] In summary, precise location identification and field area division enable efficient testing and verification of functional data fields and other target data fields in vehicle network data packets. This approach not only improves the targetedness and efficiency of testing, but also strengthens the integrity and security of the data packets under test, driving the development of more reliable and secure vehicle network systems.

[0085] As an optional embodiment, the message requirement to be tested includes a target channel identifier and a target message identifier. Step S104 determines at least one data message to be tested that meets the message requirement to be tested from at least one data message to be transmitted in the vehicle network communication node, including: based on the target channel identifier, determining at least one initial data message from at least one data message to be transmitted in the vehicle network communication node, wherein the initial data message is a data message that needs to be transmitted through a target transmission channel whose channel identifier is the target channel identifier; based on the target message identifier, determining at least one data message to be tested from at least one initial data message, wherein the message identifier of the data message to be tested is the target message identifier; the message requirement to be tested also includes a target node identifier, and in response to the test instruction, determining the vehicle network communication node from multiple vehicle network communication nodes, including: based on the vehicle network communication node identifier, determining the target communication node from multiple vehicle network communication nodes, wherein the node identifier of the target communication node is the target node identifier.

[0086] In this embodiment, the message requirement to be tested may include a target channel identifier and a target message identifier. The target channel identifier may be the channel identifier of the transmission channel through which the data message to be tested is to be transmitted, and may also be referred to as the channel where the DUT is located, such as a CAN channel. The target message identifier may be the message identifier of the data message to be tested, such as a CRC message ID, which can be used to identify the ID of the data message to be tested. The initial data message may be a data message that needs to be transmitted via the target transmission channel whose channel identifier is the target channel identifier.

[0087] Optionally, in vehicle network communication testing, the test message requirements can include: target channel identifier, target message identifier, and target node identifier. These three identifiers together define the scope and objectives of the test, ensuring that the test can be precisely focused on the specific communication node, channel, and test data message, thereby improving test efficiency and accuracy.

[0088] Optionally, based on the target channel identifier, the initial data packets that need to be transmitted through a specific channel are filtered from the data packets to be transmitted in the vehicle network communication node. This method ensures that the test is only conducted on the transmission channel that the tester needs to test, eliminating interference from other transmission channels that do not need to be tested, and improving the targeted nature of the test.

[0089] Optionally, after the initial data message is determined, data messages that need to be CRC-checked are identified based on the target message identifier as data messages to be tested.

[0090] Optionally, after receiving a test instruction, a target communication node can be determined from among multiple in-vehicle network communication nodes based on the target node identifier in the test instruction, ensuring that the test targets the in-vehicle network communication node for which the tester needs to perform data message testing, rather than any in-vehicle network communication node in the in-vehicle network system. This method enhances the controllability and targeting of the test, avoids testing irrelevant in-vehicle network communication nodes, and conserves testing resources.

[0091] In an embodiment of the present application, through the precise screening of the target channel identifier, the target message identifier, and the target node identifier, the data message to be tested and the target communication node to be tested can be quickly located, avoiding the indiscriminate analysis of massive data messages, greatly improving the test efficiency and resource utilization. Each step of screening is based on a clear identifier, ensuring that the test can be carried out on the key parts of the E2E communication protection mechanism, reducing the possibility of false alarms and missed detections, and improving the accuracy of the test results. The response mechanism of the test instruction, combined with the use of the three identifiers, ensures that the test can be carried out according to the preset scope and target, avoiding the arbitrariness and blindness in the test process, and ensuring the controllability and pertinence of the test.

[0092] As an optional embodiment, the method also includes: determining a test strategy from at least one candidate test strategy based on the bit attribute of the data message to be tested, wherein the bit attribute is used to represent the number of bits included in the byte in the data message to be tested; step S108, calling the test strategy corresponding to the target data field, testing the target data field, and obtaining a test sub-result, including: calling the test strategy, traversing the byte value of the target bit under the target byte where the target data field is located; in the process of traversing the byte value, performing an XOR operation on the traversed byte value and the preset byte value to obtain an operation result; in response to the operation result being that the byte value and the preset byte value are the same, determining that the test sub-result is that the integrity of the target data field is greater than or equal to the integrity threshold.

[0093] In this embodiment, the bit attribute can be used to represent the number of bits included in a byte in the data message to be tested, that is, it can be the bit length of the data message to be tested. The preset byte value can be a starting value or an XOR value.

[0094] Optionally, this embodiment illustrates how to invoke and execute a specific test strategy based on the bit attributes of the target data field to verify the integrity and correctness of the data message. The key point is that this step covers byte value traversal, XOR operations, and test result evaluation.

[0095] Optionally, the bit attributes of the target data field, that is, the number of bits contained in each byte, are analyzed. Since different data packets to be tested may have different bit lengths, this directly affects the selection of the test strategy. The test strategy that best matches the bit attributes of the target data field is selected from a series of candidate test strategies. The above process ensures that the test method matches the bit structure of the data field, thereby improving the targetedness and efficiency of the test. For example, if the bit length of the data packet to be tested is 8, the CRC-8 algorithm can be called to test the target data field.

[0096] Optionally, for the selected target data field, each possible byte value of the target bit under the target byte in which it is located will be traversed. The above traversal process is performed automatically to cover various possible data states to check the integrity of the data field and the effectiveness of the verification mechanism under various circumstances. During the traversal process, each traversed byte value is XORed with the preset byte value. After each XOR operation, the operation result can be compared with the byte value itself to determine the integrity of the data field. If the operation result is equal to the preset byte value (i.e., the two are the same), it can be said that the traversed byte value is correct in the CRC calculation, which means that the integrity of the data field has reached or exceeded a predetermined threshold.

[0097] Optionally, when the result of the XOR operation indicates that the byte value of the target data field is consistent with the preset byte value, it can be determined that the integrity of the target data field is greater than or equal to the integrity threshold. The above steps directly reflect the accuracy and integrity of the target data field during transmission and reception.

[0098] For example, the CRC-8 algorithm polynomial is 0x1D, which represents 10011101 in binary and is mathematically expressed as x^8+x^4+x^3+x^2+1. The polynomial value 0x1D means that the checksum calculation pays special attention to bits 8, 4, 3, 2, and 0 of the data. The CRC calculation process can be started with different starting values, or XORed with a specific 8-bit XOR value. By using specific starting values ​​and XOR values, the CRC algorithm can more effectively detect errors in data message transmission, enhancing communication reliability. The choice of different starting values ​​and XOR values ​​allows the CRC algorithm to adapt to and match the requirements of different communication standards and protocols, ensuring consistent communication.

[0099] In the embodiments of the present application, by traversing byte values ​​and performing XOR operations, various possible data states of the target data field can be covered, ensuring the comprehensiveness and reliability of the test. The evaluation results of the XOR operation provide a basis for verifying the integrity of the data message and help identify potential errors or anomalies in data transmission. The automated execution of the above steps significantly improves test efficiency, reduces the need for manual intervention, and reduces the error rate during the test process.

[0100] As an optional embodiment, based on the bit attributes of the data message to be tested, a test strategy is determined from candidate test strategies, including: determining a candidate test strategy with a bit identifier greater than or equal to the bit attribute from at least one candidate test strategy as the test strategy, wherein the bit identifier is used to indicate the number of bits that the candidate test strategy can process; calling the test strategy to traverse the byte value of the target bit under the target byte where the target data field is located, including: in response to the bit attribute being less than the bit identifier of the test strategy, adjusting the target bit to obtain an adjusted target bit, wherein the number of adjusted target bits is the same as the bit identifier; calling the test strategy to traverse the byte value of the adjusted target bit.

[0101] In this embodiment, the bit identifier may be used to indicate the number of bits that can be processed by the candidate test strategy. For example, the number of bits that can be processed by the CRC-8 algorithm is 8.

[0102] Optionally, a test strategy with a bit identifier greater than or equal to the bit attribute is selected from the candidate test strategies. For example, if the bit attribute is 7 bits, then a test strategy that can process 8 bits can be selected. This is because although the CRC-8 algorithm only processes 8 bits, in some cases, such as when processing 7 bits, zeros can be added to the end of the above 7 bits in the target data field to adapt to the requirements of the CRC-8 algorithm. If the bit attribute is 9 bits, then a test strategy that can process 16 bits can be selected. Therefore, 7 zeros can be added to the end of the above 9 bits in the target data field to adapt to the CRC-16 algorithm.

[0103] Optionally, if the bit attribute of the data message to be tested is less than the bit identifier of the test policy, the bits are adjusted to meet the requirements of the test policy. For example, for a 7-bit data field, the bit length of the field is expanded to 8 bits by padding the 7 bits with zeros.

[0104] Optionally, after adjusting the target bit position, the byte values ​​can be iterated. This involves testing each possible byte value to ensure the integrity and correctness of the data field in different states. During the byte value iteration, each byte value is XORed with a preset starting value or XOR value. The purpose of the XOR operation is to verify the correctness of the data field's checksum and thus assess the integrity of the data field.

[0105] In the embodiments of the present application, by precisely matching bit attributes with test strategies, the test accurately covers every valid bit in the data field, avoiding unnecessary testing and improving test efficiency and effectiveness. The ability to handle target data fields with different bit attributes makes the test strategy more flexible and adaptable to a variety of data formats and in-vehicle network communication standards. Ensuring the integrity of each data field during transmission helps enhance the security and reliability of the entire in-vehicle network communication system and prevent data tampering or corruption during transmission.

[0106] As an optional embodiment, a test strategy is called to traverse the byte values ​​of the target bits under the target byte where the target data field is located, including: in response to the number of target bits of the target data field being greater than the bit attribute, splitting the target bits to obtain at least two target bit groups; traversing the byte values ​​of the target bit groups respectively; the method also includes: in response to the test result that the data message to be tested meets the transmission requirements, using the target transmission channel to send the data message to be tested to the corresponding vehicle network communication node, wherein the vehicle network communication node that receives the data message to be tested is used to trigger the execution of a corresponding function on the vehicle associated with the vehicle network system.

[0107] In this embodiment, if the number of target bits in the target data field is greater than the bit attribute, the target bits can be split to obtain at least two target bit groups (high and low screening to obtain the low byte of the Data ID and then the high byte of the Data ID), and the byte values ​​in each of the above target bit groups can be traversed separately.

[0108] Optionally, when the number of target bits in the target byte where the target data field in the data message to be tested is located (for example, the number of bits of the Data ID) exceeds the defined bit attribute, bit splitting may be adopted.

[0109] Optionally, check whether the number of target bits in the target data field exceeds a preset bit attribute. If the number of target bits is indeed greater than the bit attribute, splitting processing can be performed to divide the target bits into two or more target bit groups. For example, a 16-bit Data ID can be split into an 8-bit low byte (Low Byte of Data ID) and an 8-bit high byte (High Byte of Data ID). The above splitting is to adapt to the test process and ensure that each bit group can be tested independently and effectively.

[0110] Optionally, after the bit splitting is completed, the byte values ​​of each target bit group are traversed to check their integrity and correctness under possible data states. For each generated target bit group, the byte values ​​are traversed. During the traversal process, each traversed byte value is XORed with a preset byte value, and other forms of verification (such as CRC calculation) are performed to verify whether the verification mechanism of the data field is effective under various data states.

[0111] Optionally, once the test results indicate that the data message under test meets the transmission requirements, the data message under test will be sent to the corresponding vehicle network communication node using a specific target transmission channel. The vehicle network communication node that receives the data message under test can trigger the vehicle associated with the vehicle network system to perform a corresponding function based on the received data message under test. For example, if the data message under test carries information to activate the vehicle's cruise control, the vehicle network communication node that receives the data message under test will activate the vehicle's cruise control system to verify the data message's execution effect in a real-world environment.

[0112] In the embodiment of the present application, when the number of bits exceeds the preset bit attribute, the target bits of the target data field are split and the byte value traversal test is performed on each of the generated target bit groups. The above method not only enhances the adaptability and flexibility of the test, but also improves the test coverage.

[0113] Figure 2 FIG. 1 is a flow chart of another method for testing data packets in an in-vehicle network system according to an embodiment of the present application. Figure 2 As shown, it may include terminal device A, network B and server C. Terminal device A may be a mobile phone, a laptop computer or a desktop computer. If a test instruction sent by terminal device A is detected, the test instruction may be transmitted to server C via network B. In terminal device A, the method includes the following steps:

[0114] Step S202 : In response to an input operation on the test interface, a message requirement and a test requirement for testing the data message to be tested in the vehicle network system are displayed on the test interface.

[0115] In this embodiment, in response to the tester's input operation on the test interface (test panel), the test message requirements of the data message to be tested and the test requirements of the test process are displayed and confirmed in real time. The above input operations may include but are not limited to: selecting the target communication node, specifying the target transmission channel, entering the target message identifier, defining the bit attributes of the data field to be tested, etc. In response to the tester's input operation, the demand information of the data message to be tested (message requirements to be tested and test requirements) is displayed in real time on the test interface. The above demand information intuitively prompts the tester on which vehicle network communication node, which transmission channel, and which specific message data the current test will be performed on, thereby ensuring the pertinence and effectiveness of the test.

[0116] Step S204: In response to the test operation on the test interface, the test result of the data message to be tested is displayed on the test interface.

[0117] In this embodiment, when the user performs a test operation on the test interface, for example, clicking a test button (CRCTest), the corresponding test result is responded and displayed.

[0118] Optionally, the response test instruction may call a related test script or program to execute an automated test process for the data message to be tested.

[0119] Optionally, after executing the test process of each data message to be tested, the test results can be displayed on the test interface. Alternatively, after each data message to be tested is tested, the test results can be displayed on the test interface, and after the next data message to be tested is tested, the above-displayed test results can be updated. The corresponding test results can also be updated and displayed in real time during the test of the data message to be tested. The test results can include the status of the test (such as testing, test completed), the specific value of the test data (such as the calculated CRC value, transmission time), and the evaluation of the test results (such as "OK" or "not OK").

[0120] The following describes the embodiments of the present application in detail in combination with the above steps.

[0121] As an optional embodiment, in response to the reset operation on the test interface, the reset result is displayed on the test interface, wherein the reset result is used to indicate that the current test process is successfully cleared, the test of the data message to be tested executed by calling the preset test script, and the next test process of the current test process is started.

[0122] In this embodiment, if necessary, the test status and test results of the current test process need to be cleared and a new test process needs to be started, the tester can perform a reset operation on the test interface, for example, by clicking a reset button ("Reset" control). The reset operation indicates that the tester wishes to clear the current test status and test results and prepare for a new test process.

[0123] Optionally, upon receiving a reset instruction, the reset process is immediately executed. During the reset process, the test status of the executing test script can be cleared, halting the ongoing test process. Test-related variables, counters, and status flags are reset to ensure a return to the initial or preset state. The current test results displayed on the test interface are cleared to prepare for displaying new test results.

[0124] Optionally, after the reset operation is completed, the reset result can be displayed on the test interface to inform the tester whether the reset operation was successful. The reset result may include "Reset Successful", the specific operation steps or status of the reset (such as which test scripts were stopped, which states were reset), and any possible error or warning information.

[0125] The technical solutions of the embodiments of the present application are illustrated below with reference to preferred implementation methods.

[0126] Currently, with the continuous development of vehicle technology and the deepening of the four trends of vehicles (intelligence, networking, electrification, and sharing), vehicle functions are constantly enriched, and the demand for data exchange between the functional domains of the entire vehicle is also increasing. The corresponding vehicle network system (vehicle network topology) is also becoming more and more complex. In the current era of heterogeneous in-vehicle networks, end-to-end communication protection mechanisms for in-vehicle network communication nodes are particularly important. End-to-end protection mechanisms refer to the use of specific monitoring mechanisms in the in-vehicle network system to ensure the timeliness, accuracy, and integrity of data during information transmission between nodes.

[0127] In related technologies, manual testing and verification requires inputting the data message to be verified into a CRC checksum calculator byte by byte, which is inefficient and prone to errors when iterating over counter values. Therefore, the technical problem of low testing efficiency for data messages in in-vehicle network systems still exists.

[0128] However, the present application proposes an automated E2E testing method for in-vehicle networks. To achieve rapid verification of in-vehicle E2E networks, the method is based on a network communication test tool hardware and software platform and is implemented through self-compiled software code. The method automatically performs a CRC checksum algorithm test on received DUT data packets, automatically completes checksum comparison, and outputs test results. The method does not require additional hardware or tool investment and is implemented solely through code development in a commonly used tool software environment for manual testing. Furthermore, the code is portable and reusable, eliminating the need for repeated code development and making the operation convenient. The method completes the test verification of the CRC checksum algorithm for a frame of messages and ensures that each counter value is traversed within a time limit of 200ms-2000ms, significantly shortening the verification cycle and improving test efficiency. Furthermore, the method achieves good test consistency. The code automatically monitors and processes E2E data packets, automatically completes algorithm verification comparison, and automatically outputs test results, eliminating the introduction of subjective test errors due to different test engineers conducting the test. This improves the test efficiency of data packets in the in-vehicle network system and solves the technical problem of low test efficiency in the in-vehicle network system.

[0129] The method of the embodiment of the present application is further illustrated below.

[0130] In an embodiment of the present application, the algorithm used for the E2E protection mechanism of CAN network communication can be the End-to-End Profile 1A (E2E Profile 1A) algorithm. The E2E Profile 1A algorithm elements may include: Counter, DataID, CRC Checksum, and Timeout monitoring. Among them, the element Counter is a counter present in the protected data, which is used to count the sending behavior of the signal group. In E2E Profile 1A, the length of Counter is fixed to 4 bits; the element Data ID, each signal group protected by E2E has a specific ID, namely Data ID, and the Data ID length is set to 16 bits. This element is not reflected in the message data field but is included in the CRC checksum calculation. The Data ID is generally defined in the communication matrix. In the Profile 1A algorithm, both bytes of the Data ID must be included in the data stream for the CRC checksum calculation. The calculation order is: low byte of the Data ID, then the high byte of the Data ID. The element CRC Checksum is the cyclic redundancy check. The CRC algorithm of Profile 1A uses the polynomial of the CRC-8 algorithm, that is, the polynomial value is: 0x1D (x8+x4+x3+x2+1), but uses different starting values ​​and XOR values.

[0131] Figure 3 is a schematic diagram of an example layout of an E2E communication message data field according to an embodiment of the present application, such as Figure 3 The figure below shows an example of the layout of signal groups within a CAN data unit in E2E Profile 1A. This layout is critical for implementing end-to-end communication protection mechanisms. The checksum field (Checksum) is located in Byte 0 of the message and contains the CRC-8 checksum value, which ensures the integrity and correctness of data transmission. The counter field (Counter) is located in Byte 1. The Counter field is a 4-bit field (Bit 0b to Bit 4b) that tracks the transmission order of signal groups. The Counter value typically increments with each signal group transmission. This mechanism helps the receiver detect data loss or duplication. Signals 1a to 5a (Sig1a to Sig5a) are located in Bytes 2 to 6, respectively. Sig1a to Sig5a are signal data, that is, the actual payload to be transmitted. In E2E Profile 1A, this signal data, along with the Data ID and Counter, participates in the CRC calculation to generate the checksum value. Together, the Counter and Checksum fields form the core of E2E protection. The counter ensures the correct order of data, while the checksum verifies the integrity and correctness of the data. By combining these two fields, the sender and receiver can effectively detect and correct errors that may occur during transmission.

[0132] Figure 4 is a schematic diagram of an E2E check value determination process according to an embodiment of the present application, such as Figure 4 As shown, a CRC checksum calculation can be performed on the DataID, Counter, and Sig1a through Sig5a. The CRC checksum = the CRC8 calculation of the Data ID + each of the serialized signals (including unused bits and bytes, but excluding the CRC byte itself). The CRC checksum calculation result must be placed in E2E ByteIndex0. The sequence involved in the CRC checksum calculation can be arranged in the following order: Low Byte of Data ID, High Byte of Data ID, E2E ByteIndex1 (corresponding to Counter in Byte1), E2E ByteIndex2 (corresponding to Sig1a in Byte2), ..., E2E ByteIndexn.

[0133] Optionally, based on the aforementioned E2E profile 1A algorithm, algorithm verification can be performed on data sent by CAN communication nodes equipped with E2E protection mechanisms. Taking the E2E algorithm test of 8-byte CAN messages as an example, a CRC calculator can be used to fill in the Data ID, Counter, and User Data (e.g., Counter, Sig1-Sig5) in the CAN message into designated areas as required. The calculator then performs a checksum calculation on each message. Verifying the CRC checksum algorithm for a single message frame typically takes approximately one minute, starting with manually entering the calculation data, obtaining the calculation result, and comparing the checksum value. If iterating through each counter value is required, testing the E2E algorithm for a single message frame can take at least 10 minutes. Currently, driven by the trend toward automotive functional safety, E2E protection mechanisms have been widely adopted. A CAN communication node equipped with an E2E algorithm needs to send multiple 8-byte E2E data units, significantly increasing the time required to complete the CRC checksum algorithm test of the E2E data units of this CAN communication node.

[0134] Optionally, for the CRC Checksum algorithm test of the E2E data unit of the above-mentioned CAN communication node, an automated testing method is proposed to improve the test efficiency. The embodiment of the present application realizes automatic algorithm testing, automatic comparison and output of test results upon receiving the E2E data unit through independently developed test code. The expected effect is to test and verify the CRC Checksum algorithm of a frame message and ensure that the time taken to traverse each Counter value is controlled within 200ms-2000ms (generally, the message cycle with E2E communication protection mechanism is 10ms-100ms). Compared with manual testing, the time taken is significantly shortened, efficient and can avoid subjective test errors caused by human input data.

[0135] To summarize, in order to achieve rapid verification of the in-vehicle E2E network, the embodiment of the present application adopts a general, automatable, and stress-testing in-vehicle E2E automated testing method. The above method is based on the in-vehicle network communication test tool hardware and software platform, and is implemented through self-compiled software code. It automatically performs CRC Checksum algorithm testing on the received DUT message data, and automatically completes data comparison and outputs test results.

[0136] The embodiment of the present application is suitable for CRC Checksum algorithm verification of E2E data units of vehicle CAN bus communication nodes. A standard CAN network hardware interface card can be prepared, and the hardware supports C language / C-like language for programming and development.

[0137] Optionally, to verify whether the CRC Checksum verification algorithm in the E2E communication protection strategy of the CAN bus communication node is correct, the CRC data in each message can be verified, and at the same time, it is ensured that the test execution should traverse each Counter value.

[0138] Optionally, the prerequisites may be: using a stable power supply (a power supply that meets the rated voltage and rated power of the DUT) to power the DUT; the DUT can establish a network connection with the test module normally, and the communication is stable; the test software and hardware environment meets the special wake-up conditions of the DUT, such as a wake-up line or a network management message (if necessary).

[0139] Optionally, Figure 5 Schematic diagram of an in-vehicle network E2E automated testing environment according to an embodiment of the present application, such as Figure 5 As shown, the test environment may include a device under test 501 , a power supply device (Power) 502 , a CAN bus stress test device 503 , an oscilloscope (Scope) 504 and a test module (CANoe) 505 .

[0140] Optionally, the test inputs the DUT communication matrix, the E2E communication protection strategy design specifications, and the DUT sample with the E2E function enabled. In the initial state to be tested, the DUT is powered off.

[0141] Optionally, power on and trigger a DUT wake-up condition, transitioning the DUT from a powered-down state to a powered-up state. Run the CAN network test tool to monitor the communication status of the DUT's network channel under test, ensuring that the DUT is in a normal communication state. Based on the communication matrix information, enter the CRC signal information in the test engineering panel interface and click the CRCTest button to perform automated testing.

[0142] Optionally, enter the result display window (Write window) under the test window to view the final test result to display whether the CRC value calculated corresponding to the Counter value is correct.

[0143] Optionally, the above automated test process is repeated to traverse the CRC signals of each message to be transmitted by the DUT in the communication matrix. Finally, the test data is recorded and a test report is compiled.

[0144] Figure 6 is a schematic diagram of a test panel according to an embodiment of the present application, such as Figure 6As shown in the figure, in accordance with E2E strategy design specifications, pre-test information is clearly defined: target message ID, data ID information, DUT channel, test channel reset switch, and test information refresh switch. Specifically, the environment and environment variables need to be defined, a test panel needs to be compiled, and each panel element needs to be associated with the environment variables. The contents of the above system variable configuration window show the variable definitions of an automated test script. These variable definitions are primarily used to control and monitor key parameters during the automated test process. The Channel variable in the CAN controller (CANCtrl) is an Int32 type variable used to specify the CAN bus channel. Although its initial value, minimum value, and maximum value are empty, they can be dynamically assigned to specific requirements during script execution or set through external input before testing. Located in the Configuration section, Channel is a configuration variable used to set the system state before the script runs. The Reset variable is of the Int32 data type, similarly with an empty initial value, minimum value, and maximum value, and is also located in the Configuration section.

[0145] Alternatively, as Figure 6 As shown, the CRC information (CRCInfo) includes the DataID High Byte and DataID Low Byte fields, both of type Int32, which store the high and low bytes of the Data ID in the E2E Profile. These fields play a key role in the CRC check calculation. Although their initial, minimum, and maximum values ​​are empty, they are dynamically set during testing based on test requirements. The Input field is an Int32 variable that can be used to receive external input or control the start of a test sequence. Input can trigger the execution of automated test scripts, such as starting data reading or initiating a CRC check. The Message ID field, of type Int64, stores the message ID. In CAN communication, the message ID uniquely identifies a sent or received message. Although the initial, minimum, and maximum values ​​are empty, they are set in the test environment based on the ID of the message being tested. The Number field, of type Int32, identifies the sequence or type of CRC check. Different messages can contain different CRC check numbers. The Number variable allows you to distinguish and process different types of CRC checks.

[0146] Alternatively, as Figure 6As shown in the figure, the test panel includes the OK, Cancel, Apply, and Help buttons below. Clicking the OK button saves the current variable configuration and closes the window. Clicking the Cancel button discards the changes to the current variable configuration and closes the window without saving. Clicking the Apply button applies the current configuration, but the window remains open, allowing further adjustments or review. Clicking the Help button displays help information about the current configuration or operation, guiding the user on how to correctly set and use the variables.

[0147] Figure 7 is a schematic diagram of another test panel according to an embodiment of the present application, such as Figure 7 As shown in the figure, on the CRC information input panel, you can enter information such as the CRC message ID, CRC number, DataID high byte, DataID low byte, and channel. The right side of the test panel contains Start Test and Reset buttons. Clicking the Start Test button initiates the CRC check. Clicking the Reset button ends the current test, resetting the information and waiting for the next test.

[0148] Optionally, a script file CRC8 test project file (CRC8Test.can) structure for CAN communication CRC automated testing is used using CAPL, wherein the CRC test project file may include an Includes section and a Variables section. The Includes section is used to list other files or libraries that need to be included in the script. The above libraries can provide additional functions or data types for script writing and execution. By including the above files, the script can utilize pre-defined structures and functions to avoid rewriting the same code. Variables are used to store data and status information. In automated testing, Variables can be used to store test data, test results, system status, and other test-related parameters (such as DataID High Byte, DataID Low Byte, etc.). System-on start defines the initialization behavior when the script starts. In automated test scripts, operations such as presetting system status, setting communication parameters, and initializing test tools are involved. Ensure that the script starts from a known and consistent state each time it is run. Value Objects are used to encapsulate and process data. For example, when the system variable (sysvar) CRCInfo::Input changes, the script can execute a specific code block to respond to the change, which can be to read new test data, adjust test parameters, or perform test operations. Similarly, when CANCtrl::Reset changes, the script can perform a CAN bus reset operation to reset the device before testing or recover from communication failures.

[0149] Optionally, the CAN-on message block defines an event handler for receiving CAN bus messages. When the CAN interface receives any message, the on message block can be triggered. The script can read the received message data, perform a CRC checksum calculation to verify communication correctness, and execute subsequent test logic based on the results. The Map Window provides a visual way to view and modify the contents of system variables and value objects. In automated testing, the Map Window can be used to monitor the test status of the ECE test, such as error counts and the number of messages received. Application Layer Objects can include objects and functions related to specific network application protocols. When testing E2E communication protection mechanisms, application layer objects can be used to handle higher-level network services and functions, such as data encapsulation and decapsulation. Functions are used to perform specific tasks. For example, the CRC8 calculation function CRC8(byteCRC8_TargetData[], intCRC8_DataSize):byte calculates a CRC8 checksum. It takes as input the target data and the data size, and outputs the CRC8 checksum result. Using these functions improves code readability and maintainability while reducing duplication. Test Functions are a collection of functions used to perform test operations, which can include data generation, test case execution, and test result verification. These functions are usually called by Test Cases to perform specific test steps. Test Cases define the specific scenarios and steps of the test. A test case can include a series of inputs, expected outputs, and a call sequence of test functions. In CRC testing, test cases may contain different data IDs, counter values, and data sequences to fully verify the correctness of the CRC algorithm. Test Control is responsible for managing the entire test process, including test start, stop, reset, and other operations. It can also include test result summary and reporting functions, as well as test sequence scheduling and execution control to ensure the orderly progress of the test process.

[0150] Figure 8 is a schematic diagram of a test result according to an embodiment of the present application, such as Figure 8As shown in the figure, through the independently developed software code, the accuracy of the data verification algorithm of the message with E2E verification algorithm sent by the CAN network communication node can be achieved, and the target message can be automatically obtained while automatically performing calculations according to the standard E2E algorithm. The calculation result is compared with the result value of the self-verification of the received message, and then the judgment result is automatically output. For example, for the data message CRC3, the CRC byte value preset in the data message is 0xB8, and the CRC verification value calculated by CRC verification is 0xB8. The two are the same, and the test result is OK.

[0151] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of relevant countries and regions, and provide corresponding operation entrances for users to choose to authorize or refuse.

[0152] According to another aspect of an embodiment of the present invention, corresponding to the embodiment of the method for testing data messages in the vehicle network system, this specification also provides a device for testing data messages in the vehicle network system.

[0153] Figure 9 is a schematic diagram of a test device for data packets in a vehicle network system according to an embodiment of the present invention. Figure 9 As shown, the data message testing device 90 in the in-vehicle network system may include: a first determination module 902 , a second determination module 904 , a third determination module 906 , a first testing module 908 and a second testing module 910 .

[0154] The first determining module 902 is configured to respond to a test instruction and determine a target communication node from a plurality of vehicle network communication nodes.

[0155] The second determining module 904 is configured to determine at least one data packet to be tested that meets the requirement of the packet to be tested from at least one data packet to be transmitted in the target communication node.

[0156] The third determining module 906 is configured to determine at least one target data field that meets the test requirements from the data message to be tested.

[0157] The first testing module 908 is configured to call a testing strategy corresponding to a target data field, test the target data field, and obtain a test sub-result.

[0158] The second testing module 910 is configured to determine a test result of the data message to be tested based on at least one test sub-result corresponding to at least one target data field.

[0159] The above-mentioned vehicle network system solves the technical problem of low testing efficiency of data messages in the vehicle network system, and achieves the technical effect of improving the testing efficiency of data messages in the vehicle network system.

[0160] Figure 10 FIG. 1 is a schematic diagram of another device for testing data packets in a vehicle network system according to an embodiment of the present invention. Figure 10 As shown, the testing device 100 for data messages in the in-vehicle network system may include: a first display module 1002 and a second display module 1004 .

[0161] The first display module 1002 is configured to display, on the test interface, a message requirement and a test requirement for testing a data message to be tested in the vehicle network system in response to an input operation on the test interface.

[0162] The second display module 1004 is configured to display the test result of the data message to be tested on the test interface in response to the test operation on the test interface.

[0163] The above-mentioned vehicle network system solves the technical problem of low testing efficiency of data messages in the vehicle network system, and achieves the technical effect of improving the testing efficiency of data messages in the vehicle network system.

[0164] An embodiment of the present application further provides a vehicle, comprising: a memory storing an executable program; and a processor for running the program, wherein the method of each embodiment of the present application is executed when the program is running.

[0165] An embodiment of the present application further provides a computer-readable storage medium, which includes a stored executable program, wherein when the executable program is running, the device where the computer-readable storage medium is located is controlled to execute the methods in various embodiments of the present application.

[0166] An embodiment of the present application further provides a computer program product, including a computer program, which implements the methods in various embodiments of the present application when executed by a processor.

[0167] An embodiment of the present application further provides a computer program product, including a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium is used to store a computer program, and when the computer program is executed by a processor, the method in each embodiment of the present application is implemented.

[0168] The embodiments of the present application further provide a computer program, which, when executed by a processor, implements the methods in the above-mentioned embodiments of the present application.

[0169] In the above embodiments of the present application, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, please refer to the relevant description of other embodiments.

[0170] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. Among them, the device embodiments described above are only exemplary. For example, the division of the units can be a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.

[0171] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple units. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

[0172] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0173] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for enabling a computer device (which can be a personal computer, a server or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, read-only memory (ROM), random access memory (RAM), mobile hard disk, magnetic disk or optical disk, etc., various media that can store program code.

[0174] The above is only a preferred embodiment of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A method for testing data packets in a vehicle network system, characterized in that: The vehicle network system includes a plurality of vehicle network communication nodes and at least one transmission channel, wherein the vehicle network communication nodes are used to transmit data messages to each other through the transmission channel. The method includes: In response to a test instruction, determining a target communication node from the plurality of vehicle network communication nodes, wherein the test instruction is used to at least indicate a message requirement to be tested and a test requirement; Determining at least one data message to be tested that meets the test message requirement from at least one data message to be transmitted in the target communication node; Determining at least one target data field that meets the test requirements from the data message to be tested; Invoking a test strategy corresponding to the target data field, testing the target data field, and obtaining a test sub-result, wherein the test strategy is used to test the integrity of the target data field; Based on at least one of the test sub-results corresponding to at least one of the target data fields, a test result of the data message to be tested is determined, wherein the test result is used to indicate whether the data message to be tested meets the transmission requirements of a target transmission channel, and the target transmission channel is a transmission channel in at least one of the transmission channels that is connected to the target communication node.

2. The method according to claim 1, characterized in that The test requirement includes a position identifier, where the position identifier is used to indicate at least one position of at least one target data field in the data message to be tested. Determining at least one target data field that meets the test requirement from the data message to be tested includes: Determining at least one target byte that satisfies the position identifier from at least one byte of the data message to be tested; Determining at least one target bit that satisfies the position identifier from at least one bit of the target byte, wherein the byte includes at least one bit; A data field at the target bit position under the target byte in the data message to be tested is determined as the target data field.

3. The method according to claim 2, characterized in that The target data field includes a function data field, and the function data field is used to trigger execution of a corresponding function on a vehicle associated with the in-vehicle network system. The field area of ​​the data message to be tested includes a first field area and a second field area, the first field area includes at least the function data field, and the second field area is a field area in the field area other than the first field area. At least one target byte that satisfies the position identifier is determined from at least one byte of the data message to be tested, and the method includes at least one of the following: In response to the position identifier including the position of the function data field in the first field area, determining the target byte where the function data field is located from the first field area; In response to the position identifier including the position of the target data field excluding the function data field in the first field area, determining the target byte where the target data field excluding the function data field is located from the first field area; In response to the position identifier including the position of the target data field in the second field area, the target byte where the target data field is located is determined from the second field area.

4. The method according to claim 1, wherein The message requirement to be tested includes a target channel identifier and a target message identifier, and determining at least one data message to be tested that meets the message requirement to be tested from at least one data message to be transmitted in the vehicle network communication node includes: Based on the target channel identifier, determining at least one initial data message from at least one data message to be transmitted in the in-vehicle network communication node, wherein the initial data message is a data message that needs to be transmitted through the target transmission channel whose channel identifier is the target channel identifier; Based on the target message identifier, determining at least one data message to be tested from at least one initial data message, wherein the message identifier of the data message to be tested is the target message identifier; The message requirement to be tested also includes a target node identifier, and responding to the test instruction, determining the vehicle network communication node from the plurality of vehicle network communication nodes, including: Based on the in-vehicle network communication node identifier, the target communication node is determined from a plurality of the in-vehicle network communication nodes, wherein the node identifier of the target communication node is the target node identifier.

5. The method according to claim 1, wherein The method further comprises: Determining the test strategy from at least one candidate test strategy based on a bit attribute of the data message to be tested, wherein the bit attribute is used to represent the number of bits included in a byte in the data message to be tested; Invoking a test strategy corresponding to the target data field, testing the target data field, and obtaining a test sub-result, including: Calling the test strategy to traverse the byte value of the target bit under the target byte where the target data field is located; In the process of traversing the byte value, performing an XOR operation on the traversed byte value and a preset byte value to obtain an operation result; In response to the operation result being that the byte value and the preset byte value are identical, the test sub-result is determined to be that the completeness of the target data field is greater than or equal to a completeness threshold.

6. The method according to claim 5, characterized in that Determining the test strategy from candidate test strategies based on the bit attributes of the data message to be tested includes: Determine, among at least one of the candidate test strategies, the candidate test strategy whose bit identifier is greater than or equal to the bit attribute as the test strategy, wherein the bit identifier is used to indicate the number of bits that can be processed by the candidate test strategy; The test strategy is called to traverse the byte value of the target bit under the target byte where the target data field is located, including: In response to the bit attribute being less than the bit identifier of the test strategy, adjusting the target bit positions to obtain the adjusted target bit positions, wherein the number of the adjusted target bit positions is the same as the bit identifier; The test strategy is called to traverse the adjusted byte value of the target bit.

7. The method according to claim 5, characterized in that The test strategy is called to traverse the byte value of the target bit under the target byte where the target data field is located, including: In response to the number of the target bits of the target data field being greater than the bit attribute, performing a splitting process on the target bits to obtain at least two target bit groups; Traversing the byte values ​​of the target bit group respectively; The method also includes: in response to the test result that the data message to be tested meets the transmission requirement, using the target transmission channel, sending the data message to be tested to the corresponding vehicle network communication node, wherein the vehicle network communication node that receives the data message to be tested is used to trigger the execution of a corresponding function on the vehicle associated with the vehicle network system.

8. A method for testing data messages in a vehicle network system, characterized in that: include: In response to an input operation on a test interface, displaying on the test interface a message requirement and a test requirement for testing a data message to be tested in an in-vehicle network system, wherein the in-vehicle network system includes a plurality of in-vehicle network communication nodes and at least one transmission channel, and the in-vehicle network communication nodes are used to transmit the data message to each other through the transmission channel; In response to a test operation on the test interface, a test result of the data message to be tested is displayed on the test interface, wherein the test result is obtained by calling a preset test script according to the method of any one of claims 1 to 7; The method also includes: in response to a reset operation on the test interface, displaying a reset result on the test interface, wherein the reset result is used to indicate that the current test process is successfully cleared, the data message test to be tested executed by calling the preset test script, and the next test process of the current test process is started.

9. A vehicle, characterized in that: include: a memory storing an executable program; A processor, configured to run the program, wherein the program executes the method according to any one of claims 1 to 8 when running.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium includes a stored executable program, wherein when the executable program is run, the device where the storage medium is located is controlled to execute the method according to any one of claims 1 to 8.

Images