CAN fault injection method, apparatus, equipment and storage medium
By generating and sending fault messages to the controller under test, the problem of the inability to effectively test vehicle controller units in the prior art is solved, and efficient fault injection and testing are achieved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- DONGFENG LIUZHOU MOTOR
- Filing Date
- 2023-10-08
- Publication Date
- 2026-06-30
AI Technical Summary
Existing technologies cannot effectively test for faults in vehicle controller units, making it impossible to accurately detect potential problems in vehicle control units.
By determining the fault type and the controller under test (DUT), a fault message is generated and sent to the DUT via the CAN channel connected to the DUT to achieve fault injection.
It improves fault injection efficiency, accurately meets the fault testing requirements of vehicle controllers, and enhances the accuracy of fault testing.
Smart Images
Figure CN117527516B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of fault testing technology, and in particular to a CAN fault injection method, apparatus, device, and storage medium. Background Technology
[0002] CAN (Controller Area Network) is a widely used communication protocol in automobiles and other vehicles, allowing for efficient data exchange and communication between different electronic control units (ECUs) within a vehicle. As the electronic systems in modern cars become increasingly complex and interconnected, the requirements for the reliability and security of vehicle communication networks are also rising. To ensure stable vehicle operation and passenger safety, comprehensive testing and verification of the vehicle's electronic systems are necessary. However, due to the increasing complexity of CAN wiring harnesses, it is currently impossible to effectively test for faults in the vehicle's controller units, leading to an inability to accurately identify potential problems within the vehicle's control units.
[0003] The above content is only used to help understand the technical solution of the present invention and does not represent an admission that the above content is prior art. Summary of the Invention
[0004] The main objective of this invention is to provide a CAN fault injection method, apparatus, device, and storage medium, aiming to solve the technical problem that existing technologies cannot effectively test the controller units on vehicles, resulting in the inability to accurately detect potential problems in vehicle control units.
[0005] To achieve the above objectives, the present invention provides a CAN fault injection method, the method comprising the following steps:
[0006] Determine the fault type and the controller under test based on the fault test requirements information;
[0007] Generate a fault message based on the fault type;
[0008] The fault message is sent to the controller under test via the CAN channel connected to the controller under test in order to inject faults into the controller under test.
[0009] Optionally, generating a fault message based on the fault type includes:
[0010] An initial message is generated based on the fault type;
[0011] Determine the CAN channel connected to the controller under test;
[0012] The target message identifier is determined based on the fault type and the CAN channel;
[0013] The identifier of the initial message is edited based on the target message identifier to obtain a fault message.
[0014] Optionally, generating the initial message based on the fault type includes:
[0015] The message format is determined based on the controller under test;
[0016] Determine the message data field based on the aforementioned fault test requirements information;
[0017] Based on the fault type, determine the fault simulation scenario;
[0018] The frame period is determined based on the fault simulation scenario.
[0019] An initial message is generated based on the message format, the message data field, and the frame period.
[0020] Optionally, before sending the fault message to the controller under test via the CAN channel connected to the controller under test to inject a fault into the controller under test, the method further includes:
[0021] Identify the fault events of the controller under test based on the fault type;
[0022] Based on the fault event, determine the signal to be blocked and the corresponding blocking message identifier of the signal to be blocked;
[0023] Based on the signal to be shielded and the shielding message identifier, the CAN message to be shielded of the controller under test is obtained, and the CAN message to be shielded is shielded.
[0024] Optionally, before determining the fault type and the controller under test based on the fault test requirement information, the method further includes:
[0025] Obtain the fault test file;
[0026] Extract the fault test parameters from the fault test file;
[0027] Define structure variables for the fault test parameters to obtain the test structure;
[0028] Based on the test structure, obtain fault test requirement information.
[0029] Optionally, before sending the fault message to the controller under test via the CAN channel connected to the controller under test to inject a fault into the controller under test, the method further includes...
[0030] Obtain CAN topology information;
[0031] The topological relationship between the controller under test and each CAN node is obtained based on the CAN topology information;
[0032] Configure the CAN environment based on the aforementioned topology;
[0033] The controller under test is pre-tested based on the configured CAN environment.
[0034] Optionally, before sending the fault message to the controller under test via the CAN channel connected to the controller under test to inject a fault into the controller under test, the method further includes:
[0035] Modify the CAN message to be sent;
[0036] The modified CAN message is sent to the controller under test via the CAN channel connected to the controller under test, and it is determined whether the controller under test verifies the integrity of the message.
[0037] Furthermore, to achieve the above objectives, the present invention also proposes a CAN fault injection device, the CAN fault injection device comprising:
[0038] The fault acquisition module is used to determine the fault type and the controller under test based on the fault test requirement information.
[0039] The message generation module is used to generate a fault message based on the fault type;
[0040] The fault injection module is used to send the fault message to the controller under test through the CAN channel connected to the controller under test, so as to inject faults into the controller under test.
[0041] Furthermore, to achieve the above objectives, the present invention also proposes a CAN fault injection device, the CAN fault injection device comprising: a memory, a processor, and a CAN fault injection program stored in the memory and executable on the processor, the CAN fault injection program being configured to implement the steps of the CAN fault injection method as described above.
[0042] Furthermore, to achieve the above objectives, the present invention also proposes a storage medium storing a CAN fault injection program, which, when executed by a processor, implements the steps of the CAN fault injection method as described above.
[0043] This invention determines the fault type and the controller under test (DUT) based on fault test requirements, generates a fault message based on the fault type, and sends the fault message to the DUT via the CAN channel connected to the DUT to inject faults. Because this invention generates a fault message and sends it to the DUT via the CAN channel connected to the DUT to inject faults, it effectively improves fault injection efficiency and accurately meets the fault testing requirements for vehicle controllers. Attached Figure Description
[0044] Figure 1 This is a schematic diagram of the structure of the CAN fault injection device in the hardware operating environment involved in the embodiments of the present invention;
[0045] Figure 2 This is a flowchart illustrating the first embodiment of the CAN fault injection method of the present invention;
[0046] Figure 3 This is a flowchart illustrating the second embodiment of the CAN fault injection method of the present invention;
[0047] Figure 4 This is a structural block diagram of the first embodiment of the CAN fault injection device of the present invention.
[0048] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation
[0049] It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the invention.
[0050] Reference Figure 1 , Figure 1 This is a schematic diagram of the CAN fault injection device structure in the hardware operating environment involved in the embodiments of the present invention.
[0051] like Figure 1As shown, the CAN fault injection device may include: a processor 1001, such as a central processing unit (CPU), a communication bus 1002, a user interface 1003, a network interface 1004, and a memory 1005. The communication bus 1002 is used to establish communication between these components. The user interface 1003 may include a display screen or an input unit such as a keyboard; optionally, the user interface 1003 may also include a standard wired interface or a wireless interface. The network interface 1004 may optionally include a standard wired interface or a wireless interface (such as a Wireless-Fidelity (Wi-Fi) interface). The memory 1005 may be high-speed random access memory (RAM) or stable non-volatile memory (NVM), such as a disk storage device. The memory 1005 may also optionally be a storage device independent of the aforementioned processor 1001.
[0052] Those skilled in the art will understand that Figure 1 The structure shown does not constitute a limitation on the CAN fault injection device and may include more or fewer components than shown, or combine certain components, or have different component arrangements.
[0053] like Figure 1 As shown, the memory 1005, which serves as a storage medium, may include an operating system, a network communication module, a user interface module, and a CAN fault injection program.
[0054] exist Figure 1 In the CAN fault injection device shown, the network interface 1004 is mainly used for data communication with the network server; the user interface 1003 is mainly used for data interaction with the user; the processor 1001 and the memory 1005 in the CAN fault injection device of the present invention can be set in the CAN fault injection device. The CAN fault injection device calls the CAN fault injection program stored in the memory 1005 through the processor 1001 and executes the CAN fault injection method provided in the embodiment of the present invention.
[0055] This invention provides a CAN fault injection method, referring to... Figure 2 , Figure 2 This is a flowchart illustrating the first embodiment of a CAN fault injection method according to the present invention.
[0056] In this embodiment, the CAN fault injection method includes the following steps:
[0057] Step S10: Determine the fault type and the controller under test based on the fault test requirement information.
[0058] It should be understood that the execution subject of the method in this embodiment can be a CAN fault injection device with data processing, network communication and program running functions, such as a computer, or other devices or equipment that can achieve the same or similar functions. Here, the above-mentioned CAN fault injection device (hereinafter referred to as fault injection device) is used as an example for explanation.
[0059] It should be noted that the fault test requirement information may include information about the controller that needs to be tested, the controller node name, information about the fault test items, and test environment requirements. The fault types mentioned above can be the types of test items that need to be tested. The controller under test mentioned above can be an on-board controller that needs to be tested, such as an engine controller, vehicle brake controller, and body controller.
[0060] It is understandable that the fault injection device can obtain information and parameters such as the identifier of the controller under test, node name, signal length, and signal name by reading the fault test file, and obtain the fault test requirement information based on the above information and parameters.
[0061] Furthermore, in order to accurately obtain information related to fault requirements, step S10 above may include:
[0062] Step S101: Obtain the fault test file;
[0063] Step S102: Extract fault test parameters from the fault test file;
[0064] Step S103: Define structure variables for the fault test parameters to obtain the test structure;
[0065] Step S104: Obtain fault test requirement information based on the test structure.
[0066] It should be noted that the fault test file can be a pre-packaged CSV file. The fault test parameters mentioned above can be various parameters within the DBC matrix: ID, node name, signal name, length, start bit, offset, precision, etc.
[0067] Understandably, the fault injection device defines a structure whose members include content from a CSV file, such as ID and node name; it defines a structure variable, reads the CSV file, uses a delimiter function to split it, and writes the splitting result into the defined structure variable.
[0068] In practical implementation, the fault injection device can prepare parameters in the DBC matrix in advance, such as ID, node name, signal name, length, start position, offset, precision, position and algorithm of chencksum, and organize the above parameters into a CSV file. When fault injection is required, the fault requirement information can be obtained by reading the CSV file.
[0069] Step S20: Generate a fault message based on the fault type.
[0070] It should be noted that fault messages can be CAN messages used to simulate fault messages. Fault messages can include error flags, bit errors, frame errors, transmission errors, etc. For example, a fault message can introduce a bit error by changing the value of certain bits. This error may cause the receiver to parse incorrect data or be unable to parse it correctly.
[0071] Understandably, the fault injection device determines the message parameters (e.g., message parameters may include message ID, data fields, control bits, etc.) based on the fault type, determines the message value, and configures the message format, and constructs a fault message based on the message parameters, message value, and message format.
[0072] Furthermore, in order to accurately generate fault messages, step S20 above may include:
[0073] Step S201: Generate an initial message based on the fault type;
[0074] Step S202: Determine the CAN channel connected to the controller under test;
[0075] Step S203: Determine the target message identifier based on the fault type and the CAN channel;
[0076] Step S204: Edit the identifier of the initial message based on the target message identifier to obtain the fault message.
[0077] It should be noted that the target message identifier can be the message ID that needs to be modified and edited. The fault injection device determines the information required for fault injection by designing the signal list and signal values, and selects the message ID corresponding to the fault type.
[0078] Understandably, address conflicts or network conflicts may occur on the CAN bus under certain circumstances. By modifying the message ID, these conflict scenarios can be simulated, and the stability and anti-interference capabilities of the controller under test (DUT) in such environments can be evaluated. In complex vehicle systems, multiple controllers operate simultaneously and communicate with each other. By modifying the message ID, messages sent by other controllers can be simulated, and the DUT's response and coordination capabilities to these messages can be tested.
[0079] Furthermore, in order to accurately construct the initial message simulating a fault, step S201 above may include:
[0080] The message format is determined based on the controller under test;
[0081] Determine the message data field based on the aforementioned fault test requirements information;
[0082] Based on the fault type, determine the fault simulation scenario;
[0083] The frame period is determined based on the fault simulation scenario.
[0084] An initial message is generated based on the message format, the message data field, and the frame period.
[0085] It should be noted that the fault injection device determines the message data field of the fault message based on the type of fault to be simulated. For example, if the fault type is a bit error, the value of the specific bit can be modified in the message data field. The frame period of the fault message is determined based on the behavior and impact of the fault. The frame period refers to the time interval or frequency of message transmission. Different types of faults may have different effects on the frame period. For example, some faults may cause the message transmission rate to become faster or slower.
[0086] It should be understood that the fault injection device can obtain the message parameters and message values corresponding to the fault type based on the fault type, and generate an initial message based on the message parameters and message values. The fault simulation parameters may include message ID, data fields, control bits, error flag bits, timestamps, etc.
[0087] Understandably, the fault injection device determines the specific values of each parameter in the message based on the fault type. For example, for a bit error, the value of a specific bit can be modified; for a transmission error, it can simulate situations such as message loss or duplication.
[0088] It should be understood that the fault injection device determines the CAN channel connected to the controller under test, obtains the CAN requirements based on the CAN channel, and configures the frame format of the fault message according to the CAN requirements, including standard frames or extended frames, as well as the corresponding control bits and data length, etc.
[0089] Step S30: Send the fault message to the controller under test through the CAN channel connected to the controller under test to inject faults into the controller under test.
[0090] It should be noted that the fault injection device ensures that the injected fault message is transmitted in the CAN network as expected by injecting the constructed fault message into the vehicle's CAN bus.
[0091] It is understandable that the fault injection device determines the CAN communication interface for communication connection with the controller under test (DUT), configures the communication according to the CAN configuration information, such as selecting the corresponding CAN communication rate and setting filters to filter specific messages, and sends the fault message to the DUT through the CAN channel connected to the DUT in order to inject faults into the DUT.
[0092] In practical implementation, the fault injection device simulates faults in external devices or other controllers through fault injection: by modifying the message ID, it can simulate external devices or other controllers sending error or fault messages. This allows testing the robustness and correctness of the controller under test in processing fault information from other sources.
[0093] Simulating network or address conflicts: In certain situations, address or network conflicts may occur on the CAN bus. By modifying the message ID, these conflict scenarios can be simulated, and the stability and anti-interference capability of the controller under test in this environment can be evaluated.
[0094] Testing the interaction between multiple controllers: In complex vehicle systems, multiple controllers operate simultaneously and communicate with each other. By modifying the message ID, messages sent by other controllers can be simulated, and the response and cooperation capabilities of the controller under test to these messages can be tested.
[0095] Furthermore, in order to pre-test whether there are communication problems in the CAN network, the following may be included before step S30 above:
[0096] Obtain CAN topology information;
[0097] The topological relationship between the controller under test and each CAN node is obtained based on the CAN topology information;
[0098] Configure the CAN environment based on the aforementioned topology;
[0099] The controller under test is pre-tested based on the configured CAN environment.
[0100] It should be noted that the fault injection device verifies network connectivity, confirming that all nodes and devices are correctly connected to the CAN bus. It checks the physical connections and power supply of each node to ensure they are normal, and verifies that the wiring between nodes conforms to the topology plan.
[0101] Monitor the CAN communication link by listening to the communication link on the CAN bus to ensure that messages can be transmitted normally between nodes. Check the sending and receiving of messages to verify the integrity and accuracy of the data.
[0102] Verify message IDs and data formats, monitor messages sent by each node, and verify that message IDs and data formats match expectations. Ensure that messages sent by each node meet the CAN protocol specifications and system design requirements.
[0103] To test synchronization performance, send synchronization messages to test the synchronization performance between nodes. Observe whether each node can receive the synchronization message within the predetermined time and evaluate the system's clock synchronization and coordination performance.
[0104] Furthermore, to verify whether the data is complete during transmission, the following may be included before step S30:
[0105] Modify the CAN message to be sent;
[0106] The modified CAN message is sent to the controller under test via the CAN channel connected to the controller under test, and it is determined whether the controller under test verifies the integrity of the message.
[0107] It should be noted that this embodiment uses checksum verification to detect whether bit errors, loss, or corruption have occurred during data transmission. When the sender calculates and appends a checksum to the data, the receiver can use the same verification algorithm to verify the integrity of the data. If the checksums do not match, it indicates that the data may be corrupted, and appropriate corrective measures need to be taken. Checksum verification ensures the consistency of data between transmission and reception. If the checksums match, it can be confirmed that the data has not changed or been corrupted during transmission. This is crucial for ensuring data synchronization and correctness between controllers.
[0108] It is understandable that the fault injection device determines whether the controller under test has verified message integrity by traversing all signals of the controller under test and checking whether the controller under test has a checksum.
[0109] This embodiment determines the fault type and the controller under test (DUT) based on fault test requirement information, generates a fault message based on the fault type, and sends the fault message to the DUT through the CAN channel connected to the DUT to inject faults into the DUT. Because this embodiment generates a fault message and sends it to the DUT through the CAN channel connected to the DUT to inject faults, it effectively improves fault injection efficiency and accurately meets the fault test requirements for vehicle controllers.
[0110] refer to Figure 3 , Figure 3 This is a flowchart illustrating a second embodiment of a CAN fault injection method according to the present invention.
[0111] Based on the first embodiment described above, in this embodiment, before step S30, the following is included:
[0112] Step S31: Determine the fault event of the controller under test based on the fault type;
[0113] Step S32: Determine the signal to be shielded and the shielding message identifier corresponding to the signal to be shielded based on the fault event;
[0114] Step S33: Obtain the CAN message to be shielded from the controller under test based on the signal to be shielded and the shielding message identifier, and shield the CAN message to be shielded.
[0115] It should be noted that the fault event can be a simulated fault event to be tested corresponding to the fault type. The signal to be blocked can be a message or packet that needs to be blocked. The blocked packet identifier can be the ID corresponding to the message or packet that needs to be blocked.
[0116] It is understood that this embodiment determines each signal channel of the controller under test's communication connection, determines whether each signal channel is a channel that needs to be tested for faults, determines the channel to be tested and the channel to be shielded in the signal channel based on the judgment result, and shields the messages of the channel to be shielded, thereby achieving the shielding of the CAN messages to be shielded.
[0117] For example, the controller being fault-injected is on CAN2, which needs to receive all signals on CAN1, and also needs to forward the signals from the fault-injected controller on CAN2 to CAN1. After inputting the mask ID: 0x216, the 0x216 signal will not be received on CAN2, thus realizing the communication loss fault injection for the fault-injected controller.
[0118] The controller affected by the fault injection is on CAN2 and needs to receive all signals on CAN1. The ID can be queried based on the node name; if the ID is known, this step can be ignored. Entering ID: 0x238 will retrieve all signals corresponding to that ID. Modify and confirm the changed identifier value as needed. Finally, after confirming the signal output, the channel IDs of the signals received by the fault-injected controller can be seen in the trace.
[0119] This embodiment determines the fault event of the controller under test (DUT) based on the fault type, determines the signal to be shielded and the shielding message identifier corresponding to the signal to be shielded based on the fault event, obtains the CAN message to be shielded of the DUT based on the signal to be shielded and the shielding message identifier, and shields the CAN message to be shielded. Because this embodiment reduces the risk of misoperation and test interference by shielding the CAN message to be shielded, it effectively improves the accuracy of fault testing by limiting the target range of fault injection.
[0120] Furthermore, this embodiment of the invention also proposes a storage medium storing a CAN fault injection program, which, when executed by a processor, implements the steps of the CAN fault injection method described above.
[0121] Since this storage medium adopts all the technical solutions of all the above embodiments, it has at least all the beneficial effects brought about by the technical solutions of the above embodiments, which will not be repeated here.
[0122] Reference Figure 4 , Figure 4 This is a structural block diagram of the first embodiment of the CAN fault injection device of the present invention.
[0123] like Figure 4 As shown, the CAN fault injection device proposed in this embodiment of the invention includes:
[0124] Fault acquisition module 10 is used to determine the fault type and the controller under test based on fault test requirement information;
[0125] Message generation module 20 is used to generate a fault message based on the fault type;
[0126] The fault injection module 30 is used to send the fault message to the controller under test through the CAN channel connected to the controller under test, so as to inject faults into the controller under test.
[0127] Furthermore, the message generation module 20 is also used to generate an initial message based on the fault type; determine the CAN channel connected to the controller under test; determine the target message identifier based on the fault type and the CAN channel; and edit the identifier of the initial message based on the target message identifier to obtain a fault message.
[0128] Furthermore, the message generation module 20 is also used to determine the message format based on the controller under test; determine the message data field according to the fault test requirement information; determine the fault simulation scenario based on the fault type; determine the frame period according to the fault simulation scenario; and generate an initial message based on the message format, the message data field, and the frame period.
[0129] Furthermore, the CAN fault injection device also includes:
[0130] The message masking module 40 is used to determine the fault event of the controller under test based on the fault type; determine the signal to be masked and the masking message identifier corresponding to the signal to be masked based on the fault event; obtain the CAN message to be masked of the controller under test based on the signal to be masked and the masking message identifier, and mask the CAN message to be masked.
[0131] Furthermore, the fault acquisition module 10 is also used to acquire a fault test file; extract fault test parameters from the fault test file; define structure variables for the fault test parameters to obtain a test structure; and acquire fault test requirement information based on the test structure.
[0132] Furthermore, the fault injection module 30 is also used to acquire CAN topology information; acquire the topology relationship between the controller under test and each CAN node based on the CAN topology information; configure the CAN environment based on the topology relationship; and perform pre-testing on the controller under test based on the configured CAN environment.
[0133] Furthermore, the fault injection module 30 is also used to modify the CAN message to be sent; send the modified CAN message to the controller under test through the CAN channel connected to the controller under test, and determine whether the controller under test verifies message integrity.
[0134] This embodiment determines the fault type and the controller under test (DUT) based on fault test requirement information, generates a fault message based on the fault type, and sends the fault message to the DUT through the CAN channel connected to the DUT to inject faults into the DUT. Because this embodiment generates a fault message and sends it to the DUT through the CAN channel connected to the DUT to inject faults, it effectively improves fault injection efficiency and accurately meets the fault test requirements for vehicle controllers.
[0135] It should be understood that the above are merely illustrative examples and do not constitute any limitation on the technical solution of the present invention. In specific applications, those skilled in the art can make settings as needed, and the present invention does not impose any restrictions on this.
[0136] It should be noted that the workflow described above is merely illustrative and does not limit the scope of protection of this invention. In practical applications, those skilled in the art can select some or all of the workflow to achieve the purpose of this embodiment according to actual needs, and no restrictions are imposed here.
[0137] In addition, for technical details not described in detail in this embodiment, please refer to the CAN fault injection method provided in any embodiment of the present invention, which will not be repeated here.
[0138] Furthermore, it should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or system. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or system that includes that element.
[0139] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.
[0140] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as read-only memory (ROM) / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of the present invention.
[0141] The above are merely preferred embodiments of the present invention and do not limit the patent scope of the present invention. Any equivalent structural or procedural transformations made based on the content of the present invention's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of the present invention.
Claims
1. A CAN fault injection method, characterized in that, The CAN fault injection method includes: Obtain the fault test file; Extract the fault test parameters from the fault test file; Define structure variables for the fault test parameters to obtain the test structure; Based on the aforementioned test structure, obtain fault test requirement information; Based on the fault test requirement information, determine the fault type and the controller under test; Generate a fault message based on the fault type; The fault message is sent to the controller under test via the CAN channel connected to the controller under test in order to inject faults into the controller under test; Before the step of sending the fault message to the controller under test via the CAN channel connected to the controller under test to inject a fault into the controller under test, the method further includes: Identify the fault events of the controller under test based on the fault type; Based on the fault event, determine the signal to be blocked and the corresponding blocking message identifier of the signal to be blocked; Based on the signal to be shielded and the shielding message identifier, the CAN message to be shielded of the controller under test is obtained, and the CAN message to be shielded is shielded.
2. The CAN fault injection method as described in claim 1, characterized in that, The generation of a fault message based on the fault type includes: An initial message is generated based on the fault type; Determine the CAN channel connected to the controller under test; The target message identifier is determined based on the fault type and the CAN channel; The identifier of the initial message is edited based on the target message identifier to obtain a fault message.
3. The CAN fault injection method as described in claim 2, characterized in that, The generation of the initial message based on the fault type includes: The message format is determined based on the controller under test; Determine the message data field based on the aforementioned fault test requirements information; Based on the fault type, determine the fault simulation scenario; The frame period is determined based on the fault simulation scenario. An initial message is generated based on the message format, the message data field, and the frame period.
4. The CAN fault injection method as described in claim 1, characterized in that, Before the step of sending the fault message to the controller under test via the CAN channel connected to the controller under test to inject a fault into the controller under test, the process also includes... Obtain CAN topology information; The topological relationship between the controller under test and each CAN node is obtained based on the CAN topology information; Configure the CAN environment based on the aforementioned topology; The controller under test is pre-tested based on the configured CAN environment.
5. The CAN fault injection method as described in claim 1, characterized in that, Before sending the fault message to the controller under test via the CAN channel connected to the controller under test to inject a fault into the controller under test, the method further includes: Modify the CAN message to be sent; The modified CAN message is sent to the controller under test via the CAN channel connected to the controller under test, and it is determined whether the controller under test verifies the integrity of the message.
6. A CAN fault injection device, characterized in that, The CAN fault injection device includes: The fault acquisition module is used to acquire fault test files; extract fault test parameters from the fault test files; define structure variables for the fault test parameters to obtain a test structure; and acquire fault test requirement information based on the test structure. The fault acquisition module is also used to determine the fault type and the controller under test based on the fault test requirement information; The message generation module is used to generate a fault message based on the fault type; The fault injection module is used to send the fault message to the controller under test through the CAN channel connected to the controller under test, so as to inject faults into the controller under test. The message masking module is used to determine the fault event of the controller under test based on the fault type; determine the signal to be masked and the masking message identifier corresponding to the signal to be masked based on the fault event; obtain the CAN message to be masked of the controller under test based on the signal to be masked and the masking message identifier, and mask the CAN message to be masked.
7. A CAN fault injection device, characterized in that, The CAN fault injection device includes: a memory, a processor, and a CAN fault injection program stored in the memory and executable on the processor, the CAN fault injection program being configured to implement the CAN fault injection method as described in any one of claims 1 to 5.
8. A storage medium, characterized in that, The storage medium stores a CAN fault injection program, which, when executed by the processor, implements the CAN fault injection method as described in any one of claims 1 to 5.