A fault-tolerant test method and device, electronic equipment and storage medium

Abstract

This application provides a fault-tolerant testing method, apparatus, electronic device, and storage medium. The method includes: calculating a message verification code based on data to be processed and a corresponding freshness value, where the freshness value characterizes the newness of the data during network transmission; encapsulating the data to be processed, the freshness value, and the message verification code into a secure data message; sending the secure data message to the component under test (BUT) to enable the BUT to process the secure data message; and determining the fault-tolerant test result of the BUT based on the fault information corresponding to the secure data message. By sending a secure data message encapsulated with the data to be processed, the freshness value, and the message verification code to the BUT, and determining the fault-tolerant test result of the BUT based on the fault information corresponding to the secure data message, fault-tolerant testing of the BUT is effectively achieved, thereby improving the security of fault-tolerant testing of the BUT.

Description

Technical Field

[0001] This application relates to the technical fields of vehicle networking, vehicle communication and data security, and more specifically, to a fault-tolerant testing method, apparatus, electronic device and storage medium. Background Technology

[0002] Fault tolerance testing, also known as robustness testing, refers to simulating and testing various possible transmission value errors during data transmission and processing to evaluate the system's ability to handle these errors and its fault tolerance performance, as well as the system's guarantee of data timeliness and reliability.

[0003] Currently, security issues related to automotive components in Security Onboard Community (SecOC) are typically addressed by improving SecOC message security through message content verification and message timing verification. However, there is no focus on improving SecOC message security through fault tolerance testing of automotive components. Summary of the Invention

[0004] The purpose of this application is to provide a fault-tolerant testing method, apparatus, electronic device, and storage medium to improve the security of SecOC messages.

[0005] This application provides a fault-tolerant testing method, including: calculating a message verification code based on the data to be processed and its corresponding freshness value, where the freshness value characterizes the newness of the data during network transmission; encapsulating the data to be processed, the freshness value, and the message verification code into a secure data message; sending the secure data message to the component under test (BUT) to enable the BUT to process the secure data message; and determining the fault-tolerant test result of the BUT based on the fault information corresponding to the secure data message. In the implementation of the above scheme, by sending a secure data message encapsulated with the data to be processed, the freshness value, and the message verification code to the BUT, and determining the fault-tolerant test result of the BUT based on the fault information corresponding to the secure data message, fault-tolerant testing of the BUT is effectively achieved, thereby improving the security of the secure data message in terms of the fault tolerance testing of the BUT.

[0006] Optionally, in this embodiment, before calculating the message verification code based on the data to be processed and its corresponding freshness value, the method further includes: obtaining a synchronization counter value and a reset counter value, as well as a message counter value corresponding to the secure data packet; determining a reset flag value based on the reset counter value; and constructing a freshness value based on the synchronization counter value, the reset counter value, the message counter value, and the reset flag value. In the implementation of the above scheme, by constructing a freshness value based on the synchronization counter value, the reset counter value, the message counter value, and the reset flag value, the data receiver can determine whether the data has been intercepted, copied, and resent by an attacker based on the freshness value. Therefore, the probability of replay attacks can be effectively reduced based on this freshness value.

[0007] Optionally, in this embodiment, obtaining the synchronization counter value and the reset counter value includes: obtaining the locally stored reset counter value and the synchronization counter value through a simulated master node; modifying the locally stored reset counter value to obtain a modified reset counter value; constructing a synchronization message based on the synchronization counter value and the modified reset counter value; and parsing the synchronization counter value and the reset counter value from the synchronization message through a simulated slave node. In the implementation of the above scheme, by modifying the locally stored reset counter value to obtain a modified reset counter value, and simulating various fault-tolerant scenarios for secure data packets based on the modified reset counter value, the tested components can withstand more complex network environments, effectively improving the security and reliability of the tested components.

[0008] Optionally, in this embodiment, after constructing the synchronization message based on the synchronization counter value and the modified reset counter value, the method further includes: sending the synchronization message to the component under test (DUT) through the simulation master node, so that the DUT can parse out the synchronization counter value and reset counter value used to construct the freshness value. In the implementation of the above scheme, by sending the synchronization message to the DUT through the simulation master node, the DUT can parse out the synchronization counter value and reset counter value used to construct the freshness value. The DUT can perform fault tolerance testing based on the synchronization message, effectively realizing the fault tolerance testing of the DUT, thereby improving the security of secure data messages in terms of the fault tolerance testing of the DUT.

[0009] Optionally, in this embodiment, constructing a freshness value based on the synchronization counter value, reset counter value, message counter value, and reset flag value includes: constructing the freshness value based on the synchronization counter value, locally stored reset counter value, message counter value, and reset flag value; or, constructing the freshness value based on the synchronization counter value, modified reset counter value, message counter value, and reset flag value. In the implementation of the above scheme, by constructing a freshness value based on the synchronization counter value, modified reset counter value, message counter value, and reset flag value, and simulating various fault-tolerant scenarios for secure data packets based on the modified reset counter value, the tested component can withstand more complex network environments, effectively improving the security and reliability of the tested component.

[0010] Optionally, in this embodiment, the data to be processed, the freshness value, and the message verification code are encapsulated into a secure data message, including: truncating the freshness value to obtain a truncated freshness value; truncating the message verification code to obtain a truncated message verification code; and encapsulating the data to be processed, the truncated freshness value, and the truncated message verification code into a secure data message, wherein the message format of the secure data message is the message format accepted by the component under test. In the implementation of the above scheme, by encapsulating the data to be processed, the truncated freshness value, and the truncated message verification code into a secure data message, the amount of data transmitted in the network is reduced, effectively improving the transmission efficiency of the secure data message.

[0011] Optionally, in this embodiment, determining the fault tolerance test result of the component under test based on the fault information corresponding to the security data message includes: determining whether a preset fault diagnostic code exists in the fault information corresponding to the security data message; if so, determining that the fault tolerance test result of the component under test is a pass; otherwise, determining that the fault tolerance test result of the component under test is a fail. In the implementation of the above scheme, by determining the fault tolerance test result of the component under test based on whether a preset fault diagnostic code exists in the fault information corresponding to the security data message, the fault tolerance test of the component under test is effectively realized, thereby improving the security and reliability of the security data message in terms of the fault tolerance test of the component under test.

[0012] This application also provides a fault-tolerant testing device, comprising: a message verification calculation module, used to calculate a message verification code based on the data to be processed and the freshness value corresponding to the data to be processed, wherein the freshness value is used to characterize the newness of the data in network transmission; a data packet encapsulation module, used to encapsulate the data to be processed, the freshness value, and the message verification code into a secure data packet; a data packet sending module, used to send the secure data packet to the component under test so that the component under test can process the secure data packet; and a test result determination module, used to determine the fault-tolerant test result of the component under test based on the fault information corresponding to the secure data packet.

[0013] Optionally, in this embodiment of the application, the fault-tolerant testing device further includes: a counter value acquisition module, used to acquire a synchronization counter value and a reset counter value, as well as a message counter value corresponding to a security data message; and a freshness value construction module, used to determine a reset flag value based on the reset counter value, and construct a freshness value based on the synchronization counter value, the reset counter value, the message counter value, and the reset flag value.

[0014] Optionally, in this embodiment, the counter value acquisition module includes: a counter value acquisition submodule, used to acquire the locally stored reset counter value and synchronization counter value through the simulated master node; a counter value modification submodule, used to modify the locally stored reset counter value to obtain the modified reset counter value; a synchronization message construction submodule, used to construct a synchronization message based on the synchronization counter value and the modified reset counter value; and a counter value parsing submodule, used to parse the synchronization counter value and reset counter value from the synchronization message through the simulated slave node.

[0015] Optionally, in this embodiment of the application, the counter value acquisition module further includes: a synchronization message sending submodule, used to send a synchronization message to the component under test through the simulation master node, so that the component under test can parse out the synchronization counter value and the reset counter value used to construct the freshness value.

[0016] Optionally, in this embodiment of the application, the freshness value construction module includes: a first freshness value construction submodule, used to construct a freshness value based on the synchronization counter value, the locally stored reset counter value, the message counter value, and the reset flag value; or, a second freshness value construction submodule, used to construct a freshness value based on the synchronization counter value, the modified reset counter value, the message counter value, and the reset flag value.

[0017] Optionally, in this embodiment, the data packet encapsulation module includes: a freshness value truncation submodule, used to truncate the freshness value to obtain the truncated freshness value; a message verification truncation submodule, used to truncate the message verification code to obtain the truncated message verification code; and a security packet encapsulation submodule, used to encapsulate the data to be processed, the truncated freshness value, and the truncated message verification code into a security data packet, wherein the message format of the security data packet is the message format accepted by the component under test.

[0018] Optionally, in this embodiment of the application, the test result determination module includes: a fault diagnosis judgment submodule, used to determine whether there is a preset fault diagnosis code in the fault information corresponding to the security data message; and a fault tolerance test determination submodule, used to determine that the fault tolerance test result of the component under test is a pass if there is a preset fault diagnosis code in the fault information after the component under test is processed, otherwise, determine that the fault tolerance test result of the component under test is a fail.

[0019] This application also provides an electronic device, including a processor and a memory, wherein the memory stores machine-readable instructions executable by the processor, and the machine-readable instructions, when executed by the processor, perform the method described above.

[0020] This application also provides a computer-readable storage medium storing a computer program that is executed by a processor to perform the methods described above. Attached Figure Description

[0021] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1 The flowchart shown is a schematic diagram of the fault tolerance testing method provided in the embodiment of this application;

[0023] Figure 2 The illustration shows a schematic diagram of a secure data packet provided in an embodiment of this application;

[0024] Figure 3 A schematic diagram of the fault-tolerant testing environment provided in an embodiment of this application is shown;

[0025] Figure 4 The diagram shown illustrates the freshness values ​​provided in the embodiments of this application.

[0026] Figure 5The diagram shown is a structural schematic of the fault-tolerant testing device provided in an embodiment of this application.

[0027] Figure 6 The diagram shows a structural schematic of an electronic device provided in an embodiment of this application. Detailed Implementation

[0028] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the accompanying drawings in the embodiments of this application are for illustrative and descriptive purposes only and are not intended to limit the protection scope of the embodiments of this application. Furthermore, it should be understood that the schematic drawings are not drawn to scale. The flowcharts used in the embodiments of this application illustrate operations implemented according to some embodiments of this application. It should be understood that the operations in the flowcharts may not be implemented in sequence, and steps without logical contextual relationships may be reversed or implemented simultaneously. In addition, those skilled in the art, guided by the content of the embodiments of this application, may add one or more other operations to the flowcharts, or remove one or more operations from the flowcharts.

[0029] Furthermore, the described embodiments are merely a part of the embodiments of this application, and not all of them. The components of the embodiments of this application described and illustrated herein can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed embodiments of this application, but merely to illustrate selected embodiments of this application.

[0030] It is understood that the terms "first" and "second" in the embodiments of this application are used to distinguish similar objects. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and that "first" and "second" do not necessarily imply that they are different. In the description of the embodiments of this application, the term "and / or" is merely a description of the association relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this document generally indicates that the preceding and following related objects have an "or" relationship. The term "multiple" refers to two or more (including two), and similarly, "multiple groups" refers to two or more groups (including two groups).

[0031] Before introducing the fault-tolerant testing method provided in the embodiments of this application, let's first introduce some concepts involved in the embodiments of this application:

[0032] An Electronic Control Unit (ECU), also known as an electronic control unit or electronic controller, is an embedded system in an automotive electronic system used to control the electrical system, electronic system, and automotive subsystems.

[0033] Protocol Data Unit (PDU) typically refers to the unit of data transmitted between peer layers. The Protocol Data Unit Router (PDU Router, PDUR) layer, also known as the PDUR module, is a fundamental software component of the AUTOSAR system and is a module that must be instantiated in every AUTOSAR system ECU.

[0034] An Inter-Process Data Unit (I-PDU) is the basic unit used in automotive electronic systems for exchanging data between different electronic control units (ECUs). The I-PDU contains the data information and formats exchanged between ECUs to ensure that data can be correctly transmitted and interpreted within the automotive electronic system.

[0035] CANoe is a software tool widely used in the development and testing of automotive electronic systems. CANoe's main function is to simulate, test, and verify the communication and functions in automotive networks.

[0036] It should be noted that the fault-tolerant testing method provided in this application embodiment can be executed by an electronic device. Here, electronic device refers to a device terminal or server with the function of executing computer programs. Device terminals include, for example, smartphones, personal computers, tablets, personal digital assistants, or mobile internet devices. Servers refer to devices that provide computing services through a network. Servers include, for example, x86 servers and non-x86 servers. Non-x86 servers include, for example, mainframes, minicomputers, and UNIX servers.

[0037] The following describes the applicable scenarios for this fault-tolerant testing method. These scenarios include, but are not limited to: using this fault-tolerant testing method to test the fault-tolerant performance of the component under test, or using this fault-tolerant testing method to implement fault-tolerant testing of the component under test, thereby improving the security of security data messages in terms of fault tolerance testing of the component under test.

[0038] Please see Figure 1 The illustration shows a flowchart of a fault-tolerant testing method provided in an embodiment of this application; this application provides a fault-tolerant testing method, including:

[0039] Step S110: Calculate the message verification code based on the data to be processed and the freshness value corresponding to the data to be processed. The freshness value is used to characterize the newness of the data during network transmission.

[0040] Data to be processed refers to message data transmitted over a network, such as Authentic I-PDU data that needs to be transmitted on the Controller Area Network (CAN) bus of the vehicle network, or data transmitted in a local area network, etc.

[0041] It is understandable that the freshness value can characterize the degree of newness of the data to be processed in the network transmission. This means that the data receiving end can determine whether the data to be processed has been intercepted, copied and resent by the attacker based on the freshness value. Therefore, the probability of replay attacks can be effectively reduced based on this freshness value.

[0042] Step S120: Encapsulate the data to be processed, the freshness value, and the message verification code into a secure data message.

[0043] Please see Figure 2 The illustration shows a schematic diagram of a secure data packet provided in an embodiment of this application. For ease of understanding and explanation, the following description uses a SecOC bus packet as an example. A secure data packet (also known as a Secured I-PDU) may include: an optional packet header (Secured I-PDU Header), data to be processed (Authentic I-PDU), a freshness value (FV), and a message authentication code (MAC). Here, the message authentication code is also referred to as a message authentication code or authentication information (Authenticator).

[0044] Step S130: Send a security data message to the component under test so that the component under test can process the security data message.

[0045] A device under test (DUT), also known as a unit under test, is a device or component that needs to be tested during the testing process. The aforementioned DUT can be various electronic devices, electronic components, integrated circuits, sensors, actuators, electronic modules, etc.

[0046] Please see Figure 3The diagram illustrates a fault-tolerant testing environment provided in this embodiment of the application. The fault-tolerant testing environment may include an electronic device and a component under test (DUT). The electronic device can send secure data messages to the DUT, enabling the DUT to process the secure data messages. In other words, the electronic device and the DUT can communicate with each other in the fault-tolerant testing environment. During the processing of the secure data messages, the DUT may encounter fault information. For example, if the DUT can process the secure data message normally within a preset fault tolerance range, then the DUT will not encounter fault information (e.g., a diagnostic code). Conversely, if the DUT cannot process the secure data message within the preset fault tolerance range, then the DUT will encounter fault information. The electronic device can also obtain the fault information of the DUT through the CAN bus and determine the fault-tolerant testing result of the DUT based on the processed fault information.

[0047] The aforementioned electronic device may include a CANoe master and a CANoe slave. The CANoe master can generate a synchronization message based on the synchronization counter value and the reset counter value, and send the synchronization message to the component under test (DUT) via the CAN bus. The DUT can then parse the synchronization counter value and reset counter value used to generate the freshness value from the synchronization message. Furthermore, the CANoe master can also directly forward synchronization messages to the CANoe slave. Upon receiving the forwarded synchronization message, the CANoe slave parses the synchronization counter value and reset counter value from the synchronization message.

[0048] Step S140: Determine the fault tolerance test results of the component under test based on the fault information corresponding to the safety data message.

[0049] In practical applications, the Unified Diagnostic Services (UDS) tool can be used to obtain fault information of the component under test after processing. It can obtain fault information corresponding to the security data message. If the fault information corresponding to the security data message contains a preset fault diagnosis code, the fault tolerance test result of the component under test is determined to be a pass; if the fault information corresponding to the security data message does not contain a preset fault diagnosis code, the fault tolerance test result of the component under test is determined to be a fail.

[0050] In the implementation of the above scheme, by sending a secure data message encapsulated with the data to be processed, a freshness value, and a message verification code to the component under test, and determining the fault tolerance test result of the component under test based on the fault information corresponding to the secure data message, the fault tolerance test of the component under test is effectively realized, thereby improving the security and reliability of the secure data message in terms of the fault tolerance test of the component under test.

[0051] Please see Figure 4 The illustration shows a schematic diagram of the freshness value provided in the embodiments of this application; the freshness value (FV) may include: a trip counter, a reset counter, a message counter, and a reset flag; the function and explanation of each counter value are as follows.

[0052] The Trip Counter value can be a specific value of an incrementing counter. The initial value of the counter value can be 0. When the power is connected or the device is woken up, the Trip Counter value can increment automatically. The increment step can be set according to specific circumstances, such as 1 or 2, etc.

[0053] The reset counter value can be a specific value of a monotonically increasing counter. The reset counter can be set with different reset periods depending on the specific scenario, and it monotonically increases within the reset period. In essence, when the reset counter value increments, the message counter value can be reset to 0.

[0054] A message counter value can be a specific value of a monotonically increasing counter. The message counter value can include a message counter upper value and a message counter lower value. In order to reduce the transmission load of security data messages, the two can be separated. For example, the message counter upper value can be used for calculation, while the message counter lower value can be used for transmission.

[0055] The reset flag value is the specific value of the reset flag, which can be the lowest N bits of the reset counter value (e.g., the lowest 2 bits of the reset counter value).

[0056] It is understandable that the calculation length of the freshness value (SecOC Freshness Value Length) and the transmission length of the freshness value (SecOC Freshness Value TxLength) can be different. The calculation length of the freshness value can include the sum of the lengths of the four values: the Trip Counter, the Reset Counter, the Message Counter, and the Reset Flag. The transmission length of the freshness value can include only the sum of the lengths of the Message Counter Lower and the Reset Flag.

[0057] As an optional implementation of the above-mentioned fault tolerance testing method, before calculating the message verification code based on the data to be processed and the freshness value corresponding to the data to be processed in step S110, a freshness value can also be constructed. Implementation methods for constructing the freshness value may include:

[0058] Step S111: Obtain the synchronization counter value and reset counter value, as well as the message counter value corresponding to the security data message.

[0059] Step S112: Determine the reset flag value based on the reset counter value, and construct the freshness value based on the synchronization counter value, reset counter value, message counter value, and reset flag value.

[0060] As an optional implementation of step S111 above, the implementation of obtaining the synchronization counter value and resetting the counter value may include:

[0061] Step S111a: Obtain the reset counter value and synchronization counter value stored locally through the simulation master node.

[0062] Step S111b: Modify the locally stored reset counter value to obtain the modified reset counter value.

[0063] Step S111c: Construct a synchronization message based on the synchronization counter value and the modified reset counter value.

[0064] Step S111d: Parse the synchronization counter value and reset counter value from the synchronization message through simulation.

[0065] The implementation of steps S111a to S111d above is as follows: the reset counter value and synchronization counter value stored locally are obtained by simulating the master node, and the reset counter value stored locally is modified by an executable program compiled or interpreted using a preset programming language to obtain the modified reset counter value. Then, a synchronization message is constructed based on the synchronization counter value and the modified reset counter value. Finally, the synchronization counter value and reset counter value are parsed from the synchronization message by simulating the slave node. The programming languages ​​that can be used include C, C++, Java, BASIC, JavaScript, LISP, Shell, Perl, Ruby, Python, and PHP, etc.

[0066] As an optional implementation of step S111 above, after constructing the synchronization message based on the synchronization counter value and the modified reset counter value in step S111c, it may further include:

[0067] Step S111e: Send a synchronization message to the component under test through the simulation master node so that the component under test can parse out the synchronization counter value and reset counter value used to build the freshness value.

[0068] An example implementation of step S111e above is as follows: The emulation master node in the electronic device sends a synchronization message to the component under test (DUT) via the CAN bus of the vehicle network. After receiving the synchronization message sent by the emulation master node, the DUT can also parse the synchronization counter value and reset counter value from the synchronization message. Then, it constructs a freshness value based on the synchronization counter value, reset counter value, locally stored message counter value, and reset flag value. A specific implementation of constructing the freshness value may include: concatenating the synchronization counter value, reset counter value, message counter value, and reset flag value to obtain a string, converting the string into a number according to a preset base (e.g., hexadecimal or base 32), and using this number as the aforementioned freshness value.

[0069] As an optional implementation of step S112, a first implementation of constructing the freshness value may include:

[0070] Step S112a: Construct a freshness value based on the synchronization counter value, the locally stored reset counter value, the message counter value, and the reset flag setting.

[0071] Alternatively, a second implementation of constructing freshness values ​​may include:

[0072] Step S112b: Construct a freshness value based on the synchronization counter value, the modified reset counter value, the message counter value, and the reset flag setting.

[0073] Understandably, in the specific implementation process, at least one of the aforementioned synchronization counter value, reset counter value, and / or message counter value can be modified, and a freshness value can be constructed based on at least one of the modified synchronization counter value, modified reset counter value, modified message counter value, and modified reset flag value. Specific modifications can be set according to the scenario. For ease of explanation and understanding, the following example illustrates a scenario where the synchronization counter in the current synchronization message is modified to 1, and the reset counter value is also 1.

[0074] In the first scenario, the reset counter value in the synchronization message of the CANoe master can be simulated to increment by 1 (the modified reset counter value is 2). The CANoe slave receives and updates the incremented synchronization message, and the component under test also receives and updates the incremented synchronization message. Specifically, the electronic device constructs a synchronization message based on the synchronization counter value (e.g., 1) and the modified reset counter value (e.g., 2) through the CANoe master. Then, it sends the synchronization message to the component under test via the CAN bus and forwards the synchronization message to the CANoe slave. Upon receiving the synchronization message, the simulated slave node parses the synchronization counter value (e.g., 1) and the modified reset counter value (e.g., 2) from the message. It then constructs a freshness value using the synchronization counter value (e.g., 1), the modified reset counter value (e.g., 2), and the message counter value (e.g., 0, with an initial value of 0). Next, it calculates a message verification code based on the data to be processed and the freshness value. Finally, it encapsulates the data to be processed, the freshness value, and the message verification code into a secure data message and sends it to the component under test (DUT) for processing. Similarly, upon receiving the synchronization message, the DUT parses the synchronization counter value (e.g., 1) and the modified reset counter value (e.g., 2) from the message. If it receives a secure data message from the simulated slave node in the electronic device, it uses the synchronization counter value (e.g., 1) and the modified reset counter value (e.g., 2) to process the secure data message. If the component under test (DUT) can process the safety data message normally within the preset fault tolerance range, then the DUT will not display any fault information (e.g., fault diagnostic codes). Conversely, if the DUT cannot process the safety data message within the preset fault tolerance range, then the DUT will display fault information. The electronic device can also obtain the fault information of the DUT through the CAN bus and determine the fault tolerance test result of the DUT based on the fault information after processing.

[0075] The second scenario simulates the incrementing of the reset counter value (Reset Counter) in the synchronization message of the CANoe master (the modified reset counter value is 2). The simulation then demonstrates an anomaly in the CANoe slave, resulting in the loss of the incremented synchronization message, while the component under test receives and updates the incremented synchronization message. The specific implementation of the second scenario is similar to that of the first scenario above, and therefore will not be repeated here.

[0076] In the third scenario, the reset counter value in the synchronization message of the CANoe master is simulated to increment by 1 (the modified reset counter value is 2). The simulation shows the slave node (CANoe slave) receiving and updating the incremented synchronization message, and the component under test malfunctions and loses the incremented synchronization message. The specific implementation of the third scenario is similar to that of the first scenario above, so it will not be described again here.

[0077] The fourth scenario simulates the incrementing of the reset counter value by 2 (the modified reset counter value is 3) in the synchronization message of the CANoe master. It also simulates an anomaly in the CANoe slave, causing it to lose the incremented synchronization message, while the component under test receives and updates the incremented synchronization message. The specific implementation of the fourth scenario is similar to that of the first scenario above, therefore, it will not be repeated here.

[0078] In the fifth scenario, the reset counter value in the synchronization message of the CANoe master is simulated to increment by 2 (the modified reset counter value is 3). The simulation shows the slave node (CANoe slave) receiving and updating the incremented synchronization message, and the component under test malfunctions and loses the incremented synchronization message. The specific implementation of the fourth scenario is similar to that of the first scenario above, therefore, it will not be described again here.

[0079] The sixth scenario simulates the incrementing of the reset counter value by 3 (the modified reset counter value is 4) in the synchronization message of the CANoe master. It also simulates an anomaly in the CANoe slave, causing it to lose the incremented synchronization message, while the component under test receives and updates the incremented synchronization message. The implementation of the fourth scenario is similar to that of the first scenario above, and therefore will not be repeated here.

[0080] In the seventh scenario, the reset counter value in the synchronization message of the CANoe master is simulated to increment by 3 (the modified reset counter value is 4). The simulation shows the slave node (CANoe slave) receiving and updating the incremented synchronization message, and the component under test malfunctions and loses the incremented synchronization message. The specific implementation of the fourth scenario is similar to that of the first scenario above, therefore, it will not be described again here.

[0081] In the implementation of the above scheme, by modifying the counter value (e.g., synchronizing the counter value, resetting the counter value, or the message counter value), and simulating various fault-tolerant scenarios of secure data packets based on the modified counter value, the tested components can withstand more complex network environments, effectively improving the security and reliability of the tested components.

[0082] As an optional implementation of step S120 above, the implementation of encapsulating the data to be processed, the freshness value, and the message verification code into a secure data message may include:

[0083] Step S121: Truncate the freshness value to obtain the truncated freshness value.

[0084] Step S122: Truncate the message verification code to obtain the truncated message verification code.

[0085] For example, steps S121 to S122 can be implemented as follows: An executable program compiled or interpreted using a preset programming language can be used to truncate the freshness value to obtain a truncated freshness value. Similarly, an executable program compiled or interpreted using a preset programming language can be used to truncate a message verification code to obtain a truncated message verification code. Examples of programming languages ​​that can be used include: C, C++, Java, BASIC, JavaScript, LISP, Shell, Perl, Ruby, Python, and PHP, etc.

[0086] Step S123: Encapsulate the data to be processed, the truncated freshness value, and the truncated message verification code into a secure data message. The message format of the secure data message is the message format accepted by the component under test.

[0087] It is understandable that when encapsulating secure data packets, it is not necessary to encapsulate the entire freshness value and the entire message verification code in the packet. Instead, the freshness value can be truncated, and / or the message verification code can be truncated, and the data to be processed, the truncated freshness value, and / or the truncated message verification code can be encapsulated into a secure data packet. The length of the data to be processed can be 10 bytes, the length of the freshness value before truncation can be 72 bytes, and the length of the truncated freshness value can be 2 bytes. The message verification code follows a similar principle, so it will not be elaborated further.

[0088] As an optional implementation of step S130 above, the electronic device can send a security data message to the component under test (DUT) via the Controller Area Network (CAN) bus of the vehicle network, so that the DUT can process the security data message. Before sending the security data message to the DUT, the electronic device can also obtain the communication key of the DUT and use the communication key to send the security data message to the DUT (e.g., encrypt the communication key or establish a secure channel). Optionally, if the DUT requires a power supply to operate normally, in practice, the DUT (KL30 and KL15 of the DUT) can be connected to a power supply with a supply voltage of 24V, so that the fault tolerance test is performed only after the DUT is connected to a power supply.

[0089] As an optional implementation of step S140 above, the implementation method for determining the fault tolerance test result of the component under test based on the fault information corresponding to the security data message may include:

[0090] Step S141: Determine whether there is a preset fault diagnosis code in the fault information corresponding to the security data message.

[0091] Step S142: If a preset fault diagnosis code exists in the fault information corresponding to the safety data message, then the fault tolerance test result of the component under test is determined to be a pass.

[0092] Step S143: If there is no preset fault diagnostic code in the fault information corresponding to the safety data message, then the fault tolerance test result of the component under test is determined to be a test failure.

[0093] For example, the implementation of steps S141 to S143 above involves using an executable program compiled or interpreted in a preset programming language to determine whether a preset fault diagnostic code exists in the fault information corresponding to the security data message. Here, the preset fault diagnostic code can be a preset SecOC fault code, and the fault information after processing the component under test (DUT) can be the fault code recorded by the DUT. Therefore, it can be determined whether the preset SecOC fault code is included in the fault codes recorded by the DUT. If the preset fault diagnostic code exists in the fault information corresponding to the security data message, i.e., it is determined that the preset SecOC fault code is included in the fault codes recorded by the DUT, then the fault tolerance test result for the component under test is determined to be a pass. If the preset fault diagnostic code does not exist in the fault information corresponding to the security data message, i.e., it is determined that the preset SecOC fault code is not included in the fault codes recorded by the DUT, then the fault tolerance test result for the component under test is determined to be a fail.

[0094] Optionally, after the test is completed, a Hyper Text Markup Language (HTML) format test report can be generated based on the fault tolerance test results of the component under test. This test report can record intermediate data recorded during the fault tolerance test (such as the content sent by the simulation master node, or the content received and processed by the simulation slave node), as well as the fault tolerance test results of the component under test (such as the test success or failure results), etc. In the implementation of the above scheme, generating an HTML format test report based on the fault tolerance test results of the component under test achieves the function of automatically generating test reports and recording intermediate data during the fault tolerance test, thereby improving the efficiency of fault tolerance testing.

[0095] Please see Figure 5 The diagram shown is a structural schematic of the fault-tolerant testing device provided in an embodiment of this application; this application provides a fault-tolerant testing device 200, including:

[0096] The message verification calculation module 210 is used to calculate the message verification code based on the data to be processed and the freshness value corresponding to the data to be processed. The freshness value is used to characterize the newness of the data during network transmission.

[0097] The data message encapsulation module 220 is used to encapsulate the data to be processed, the freshness value, and the message verification code into a secure data message.

[0098] The data message sending module 230 is used to send security data messages to the component under test so that the component under test can process the security data messages.

[0099] The test result determination module 240 is used to determine the fault tolerance test result of the component under test based on the fault information corresponding to the security data message.

[0100] Optionally, in this embodiment of the application, the fault-tolerant testing device further includes:

[0101] The counter value acquisition module is used to acquire the synchronization counter value, the reset counter value, and the message counter value corresponding to the security data message.

[0102] The freshness value construction module is used to determine the reset flag value based on the reset counter value, and to construct the freshness value based on the synchronization counter value, reset counter value, message counter value, and reset flag value.

[0103] Optionally, in this embodiment of the application, the counter value acquisition module includes:

[0104] The counter value acquisition submodule is used to obtain the reset counter value and synchronization counter value stored locally through the simulation master node.

[0105] The counter value modification submodule is used to modify the locally stored reset counter value and obtain the modified reset counter value.

[0106] The synchronization message construction submodule is used to construct synchronization messages based on the synchronization counter value and the modified reset counter value.

[0107] The counter value parsing submodule is used to parse the synchronization counter value and reset counter value from the synchronization message by simulating the slave node.

[0108] Optionally, in this embodiment of the application, the counter value acquisition module further includes:

[0109] The synchronization message sending submodule is used to send synchronization messages to the component under test through the simulation master node, so that the component under test can parse the synchronization counter value and reset counter value used to build the freshness value.

[0110] Optionally, in this embodiment of the application, the freshness value construction module includes:

[0111] The first freshness value construction submodule is used to construct a freshness value based on the synchronization counter value, the locally stored reset counter value, the message counter value, and the reset flag value.

[0112] Alternatively, a second freshness value construction submodule is used to construct a freshness value based on the synchronization counter value, the modified reset counter value, the message counter value, and the reset flag setting.

[0113] Optionally, in this embodiment of the application, the data packet encapsulation module includes:

[0114] The Freshness Value Truncation Submodule is used to truncate the freshness value to obtain the truncated freshness value.

[0115] The message verification truncation submodule is used to truncate the message verification code to obtain the truncated message verification code.

[0116] The secure message encapsulation submodule is used to encapsulate the data to be processed, the truncated freshness value, and the truncated message verification code into a secure data message. The message format of the secure data message is the message format accepted by the component under test.

[0117] Optionally, in this embodiment of the application, the test result determination module includes:

[0118] The fault diagnosis and judgment submodule is used to determine whether there is a preset fault diagnosis code in the fault information corresponding to the security data message.

[0119] The fault tolerance test determination submodule is used to determine that the fault tolerance test result of the component under test is passed if a preset fault diagnosis code exists in the fault information after the component under test is processed; otherwise, it is determined that the fault tolerance test result of the component under test is failed.

[0120] It should be understood that this device corresponds to the fault-tolerant testing method embodiment described above and is capable of performing the various steps involved in the above method embodiment. The specific functions of this device can be found in the description above, and detailed descriptions are appropriately omitted here. The device includes at least one software functional module that can be stored in memory or embedded in the device's operating system (OS) in the form of software or firmware.

[0121] Please see Figure 6 The diagram shows a structural schematic of an electronic device provided in an embodiment of this application. An electronic device 300 provided in this application includes a processor 310 and a memory 320. The memory 320 stores machine-readable instructions executable by the processor 310. When the machine-readable instructions are executed by the processor 310, the method described above is performed.

[0122] This application embodiment also provides a computer-readable storage medium 330, on which a computer program is stored. This computer program is executed by a processor 310 to perform the methods described above. The computer-readable storage medium 330 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0123] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For apparatus embodiments, since they are basically similar to method embodiments, the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0124] It should be understood that the disclosed apparatus and methods can also be implemented in other ways, as provided in the embodiments of this application. The apparatus embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in the flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the accompanying drawings. For example, two consecutive blocks may actually be executed substantially in parallel, or they may sometimes be executed in reverse order, depending primarily on the functions involved.

[0125] Furthermore, the functional modules of each embodiment in this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part. In addition, in the description of this specification, the reference to terms such as "one embodiment," "some embodiments," "example," "specific example," "some examples," etc., means that the specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described can be combined in a suitable manner in any one or more embodiments or examples. Furthermore, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0126] The above description is only an optional implementation of the embodiments of this application, but the protection scope of the embodiments of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the embodiments of this application should be covered within the protection scope of the embodiments of this application.

Claims

1. A fault-tolerant testing method, characterized in that, include: The reset counter value and synchronization counter value stored locally are obtained by simulating the master node; Modify the locally stored reset counter value to obtain the modified reset counter value; A synchronization message is constructed based on the synchronization counter value and the modified reset counter value; The synchronization counter value and the reset counter value, as well as the message counter value corresponding to the security data message, are parsed from the synchronization message by the node through simulation. The reset flag value is determined based on the reset counter value, and a freshness value is constructed based on the synchronization counter value, the reset counter value, the message counter value, and the reset flag value. The message verification code is calculated based on the data to be processed and the freshness value corresponding to the data to be processed. The freshness value is used to characterize the newness of the data during network transmission. The data to be processed, the freshness value, and the message verification code are encapsulated into a secure data message; The security data message is sent to the component under test so that the component under test processes the security data message. The fault tolerance test results of the component under test are determined based on the fault information corresponding to the security data message.

2. The method according to claim 1, characterized in that, After constructing the synchronization message based on the synchronization counter value and the modified reset counter value, the method further includes: The simulation master node sends the synchronization message to the component under test, so that the component under test can parse out the synchronization counter value and reset counter value used to construct the freshness value.

3. The method according to claim 1, characterized in that, The step of constructing the freshness value based on the synchronization counter value, the reset counter value, the message counter value, and the reset flag value includes: The freshness value is constructed based on the synchronization counter value, the locally stored reset counter value, the message counter value, and the reset flag value. Alternatively, the freshness value can be constructed based on the synchronization counter value, the modified reset counter value, the message counter value, and the reset flag setting.

4. The method according to any one of claims 1-3, characterized in that, The step of encapsulating the data to be processed, the freshness value, and the message verification code into a secure data message includes: The freshness value is truncated to obtain the truncated freshness value; The message verification code is truncated to obtain the truncated message verification code; The data to be processed, the truncated freshness value, and the truncated message verification code are encapsulated into a secure data message, the message format of which is the message format accepted by the component under test.

5. The method according to any one of claims 1-3, characterized in that, The step of determining the fault tolerance test result of the component under test based on the fault information corresponding to the security data message includes: Determine whether a preset fault diagnosis code exists in the fault information corresponding to the security data message; If yes, the fault tolerance test result of the component under test is determined to be a pass; otherwise, the fault tolerance test result of the component under test is determined to be a fail.

6. A fault-tolerant testing device, characterized in that, include: The message verification calculation module is used to calculate the message verification code based on the data to be processed and the freshness value corresponding to the data to be processed. The freshness value is used to characterize the newness of the data during network transmission. A data message encapsulation module is used to encapsulate the data to be processed, the freshness value, and the message verification code into a secure data message; A data message sending module is used to send the security data message to the component under test so that the component under test can process the security data message. The test result determination module is used to determine the fault tolerance test result of the component under test based on the fault information corresponding to the security data message; The fault-tolerant testing device also includes: The counter value acquisition module is used to acquire the synchronization counter value, the reset counter value, and the message counter value corresponding to the security data message; The freshness value construction module is used to determine the reset flag value based on the reset counter value, and to construct the freshness value based on the synchronization counter value, reset counter value, message counter value, and reset flag value. The counter value acquisition module includes: The counter value acquisition submodule is used to obtain the reset counter value and synchronization counter value stored locally through the simulation master node; The counter value modification submodule is used to modify the locally stored reset counter value and obtain the modified reset counter value; The synchronization message construction submodule is used to construct a synchronization message based on the synchronization counter value and the modified reset counter value. The counter value parsing submodule is used to parse the synchronization counter value and reset counter value from the synchronization message by simulating the slave node.

7. An electronic device, characterized in that, include: A processor and a memory, the memory storing machine-readable instructions executable by the processor, which, when executed by the processor, perform the method as described in any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the method as described in any one of claims 1 to 5.

Images