Fault test method, device and equipment of DDS network, medium and program product
By triggering the eBPF program in the DDS network to perform protocol parsing and fault rule matching, the shortcomings of existing DDS network fault detection methods are addressed, enabling accurate simulation and reliability verification of the DDS network, and ensuring the real-time performance and accuracy of fault injection.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- ZEBRED NETWORK TECH CO LTD
- Filing Date
- 2025-12-31
- Publication Date
- 2026-04-28
AI Technical Summary
Existing DDS network fault detection methods are unable to cover the diversity and dynamism of real network faults, have high testing costs, poor repeatability, and cannot accurately simulate network faults to verify the reliability of DDS.
By triggering the eBPF program when a network packet arrives at the mount point, performing protocol parsing and fault rule matching, the type of injected fault in the network packet is determined, and fault injection tests are performed using flow control tools, thereby achieving accurate simulation and reliability verification of the DDS network.
Without relying on hardware devices, the functional correctness and system stability of the DDS network under abnormal network conditions were verified, ensuring the real-time and accuracy of the fault injection process.
Smart Images
Figure CN121940327A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of network communication technology, and in particular to a fault testing method, apparatus, equipment, medium, and program product for DDS networks. Background Technology
[0002] With the rapid development of autonomous driving technology, in-vehicle networks place extremely high demands on the real-time performance, reliability, and security of communication protocols. However, the in-vehicle network environment is complex and susceptible to factors such as temperature fluctuations, electromagnetic interference, and vibration. The probability of network failures (such as packet loss, out-of-order delivery, delays, and duplicate packets) is significantly higher than in laboratory environments. If the DDS (Digital Data System) cannot guarantee reliable data transmission under real-world network failures, it may lead to misjudgments or malfunctions in the autonomous driving system, posing serious safety hazards.
[0003] Currently, the detection of DDS network faults mainly relies on unit testing methods and chaos engineering tools. However, these methods depend on hardware devices or intrusive code modifications, making it difficult to cover the diversity and dynamism of real-world network faults. Furthermore, they are costly and lack repeatability. For example, unit testing verifies the ability of a single module to handle specific network faults by adding DDS source code; this method relies on vendor-released source code, making it difficult to establish a unified standard, and it can only cover localized scenarios, failing to simulate network faults in real-world environments. Similarly, detection methods relying on chaos engineering tools can randomly generate various network faults, but they are too inefficient for verifying the functional correctness and reliability of DDS.
[0004] Therefore, there is an urgent need for a DDS network fault testing scheme that can accurately simulate network faults and verify the reliability of DDS. Summary of the Invention
[0005] This application provides fault testing methods, apparatus, equipment, media, and program products for DDS networks, which can accurately simulate network faults and verify the reliability of DDS.
[0006] In a first aspect, embodiments of this application provide a fault testing method for a DDS network, including: triggering an eBPF program when a network packet arrives at a mount point; wherein the eBPF program is mounted in the mount point of the corresponding network namespace, and the eBPF program is used to perform protocol parsing and fault rule matching on the network packet;
[0007] Determine the identifier field corresponding to the network packet, and check if the identifier field is the same as the identifier field corresponding to the RTPS packet; if the identifier field is the same as the identifier field corresponding to the RTPS packet, then determine that the network packet is an RTPS packet.
[0008] Perform protocol parsing on network packets to obtain the corresponding protocol fields;
[0009] The protocol fields are matched with the fault injection rules to determine the type of injected fault corresponding to the network packet; based on the injected fault type, the TC action code corresponding to the network packet is determined; the TC action code is used to indicate the fault injection operation corresponding to the network packet.
[0010] Using flow control tools, fault injection tests are performed on network packets based on the corresponding TC action codes.
[0011] Secondly, embodiments of this application provide a fault testing apparatus for a DDS network, comprising:
[0012] The trigger module is used to trigger the eBPF program when a network packet arrives at the mount point. The eBPF program is mounted in the mount point of the corresponding network namespace and is used to perform protocol parsing and fault rule matching on the network packet.
[0013] The determination module is used to determine the identification field corresponding to the network packet and to determine whether the identification field is the same as the identification field corresponding to the RTPS packet; if the identification field is the same as the identification field corresponding to the RTPS packet, then the network packet is determined to be an RTPS packet.
[0014] The processing module is used to parse network packets to obtain the protocol fields corresponding to the network packets.
[0015] The processing module is also used to match the protocol fields with the fault injection rules to determine the type of injected fault corresponding to the network packet; based on the type of injected fault, it determines the TC action code corresponding to the network packet; wherein, the TC action code is used to indicate the fault injection operation corresponding to the network packet;
[0016] The execution module is used to perform fault injection tests on network packets based on the TC action codes corresponding to the network packets using flow control tools.
[0017] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor;
[0018] The memory stores instructions that the computer executes;
[0019] The processor executes computer execution instructions stored in memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.
[0020] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.
[0021] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.
[0022] The fault testing method, apparatus, device, medium, and program product for DDS networks provided in this application triggers an eBPF program when a network packet arrives at the mounting point; determines the identification field corresponding to the network packet and judges whether the identification field is the identification field corresponding to an RTPS packet; if the identification field is the identification field corresponding to an RTPS packet, the network packet is determined to be an RTPS packet; performs protocol parsing on the network packet to obtain the corresponding protocol field; matches the protocol field with fault injection rules to determine the injection fault type corresponding to the network packet; determines the TC action code corresponding to the network packet based on the injection fault type; and performs fault injection testing on the network packet using a flow control tool based on the TC action code corresponding to the network packet. This application mounts an eBPF program in the kernel space; the eBPF program has protocol parsing and rule matching functions to achieve accurate matching of RTPS packet parsing and fault injection rules; in addition, the low latency and low resource consumption execution capability of the eBPF program ensures the real-time performance and accuracy of the fault injection process, thereby realizing the functional correctness and system stability verification of DDS under abnormal network conditions without relying on hardware devices. Attached Figure Description
[0023] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.
[0024] Figure 1 A flowchart illustrating a fault testing method for a DDS network provided in this application. Figure 1 ;
[0025] Figure 2 A flowchart illustrating a fault testing method for a DDS network provided in this application. Figure 2 ;
[0026] Figure 3 A schematic diagram of the structure of a fault testing device for a DDS network provided in this application;
[0027] Figure 4 This is a schematic diagram of the structure of an electronic device provided in this application.
[0028] The accompanying drawings have illustrated specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to specific embodiments. Detailed Implementation
[0029] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.
[0030] With the rapid development of autonomous driving technology, in-vehicle networks place extremely high demands on the real-time performance, reliability, and security of communication protocols. However, the in-vehicle network environment is complex and susceptible to factors such as temperature fluctuations, electromagnetic interference, and vibration. The probability of network failures (such as packet loss, out-of-order delivery, delays, and duplicate packets) is significantly higher than in laboratory environments. If the DDS (Digital Data System) cannot guarantee reliable data transmission under real-world network failures, it may lead to misjudgments or malfunctions in the autonomous driving system, posing serious safety hazards.
[0031] Currently, the detection of DDS network faults mainly relies on unit testing methods and chaos engineering tools. However, these methods depend on hardware devices or intrusive code modifications, making it difficult to cover the diversity and dynamism of real-world network faults. Furthermore, they are costly and lack repeatability. For example, unit testing verifies the ability of a single module to handle specific network faults by adding DDS source code; this method relies on vendor-released source code, making it difficult to establish a unified standard, and it can only cover localized scenarios, failing to simulate network faults in real-world environments. Similarly, detection methods relying on chaos engineering tools can randomly generate various network faults, but they are too inefficient for verifying the functional correctness and reliability of DDS.
[0032] Therefore, there is an urgent need for a DDS network fault testing scheme that can accurately simulate network faults and verify the reliability of DDS.
[0033] The fault testing method, apparatus, equipment, medium, and program products for DDS networks provided in this application trigger an eBPF program when a network packet arrives at the mounting point; determine the identification field corresponding to the network packet, and determine whether the identification field is the same as the identification field corresponding to an RTPS packet; if the identification field is the same as the identification field corresponding to an RTPS packet, then the network packet is determined to be an RTPS packet; perform protocol parsing on the network packet to obtain the corresponding protocol field; match the protocol field with fault injection rules to determine the type of injected fault corresponding to the network packet; determine the TC action code corresponding to the network packet based on the injected fault type; and perform fault injection testing on the network packet using a flow control tool based on the TC action code corresponding to the network packet. This application mounts an eBPF program in the kernel space; the eBPF program has protocol parsing and rule matching functions to achieve accurate matching of RTPS packet parsing and fault injection rules; in addition, the low latency and low resource consumption execution capability of the eBPF program ensures the real-time performance and accuracy of the fault injection process, thereby achieving the functional correctness and system stability verification of DDS under abnormal network conditions without relying on hardware devices.
[0034] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.
[0035] Figure 1 A flowchart illustrating a fault testing method for a DDS network provided in this application. Figure 1 ,like Figure 1 As shown, the method includes:
[0036] S101. When a network packet arrives at the mount point, the eBPF program is triggered. The eBPF program is mounted in the mount point of the corresponding network namespace. The eBPF program is used to perform protocol parsing and fault rule matching on the network packet.
[0037] Among them, network namespace refers to a network isolation mechanism provided by the Linux kernel. It provides independent network environments for different process groups, with independent network cards, routing tables, sockets, etc., and their configurations do not affect each other.
[0038] For example, when the received network packet 1 arrives at the mount point while flowing through the network, the eBPF program mounted on the mount point is triggered to perform protocol parsing and fault matching on network packet 1.
[0039] S102. Determine the identification field corresponding to the network packet, and determine whether the identification field is the same as the identification field corresponding to the RTPS packet; if the identification field is the same as the identification field corresponding to the RTPS packet, then determine that the network packet is an RTPS packet.
[0040] Upon triggering the eBPF procedure, the first step is to determine whether network packet 1 is an RTPS packet. Only if network packet 1 is an RTPS packet will protocol parsing and fault rule matching be performed on it. Specifically, the identification field used for packet type in the network packet is determined; for example, identification field 1 corresponding to network packet 1 is compared with the identification field corresponding to the RTPS packet. If identification field 1 matches the identification field corresponding to the RTPS packet, then network packet 1 is determined to be an RTPS packet.
[0041] S103. Perform protocol parsing on the network packet to obtain the protocol field corresponding to the network packet;
[0042] The pre-generated eBPF program contains RTPS protocol parsing rules; the protocol parsing field rules are: "RTPS protocol parsing is divided into two levels: header parsing and SubMessage parsing; header parsing is used for basic information such as protocol version, vendor ID, and GUID prefix; SubMessage parsing is performed for different message types (such as Data, AckNack, Heartbeat, Gap, etc.) to obtain the field structure and byte order corresponding to different message types."
[0043] Therefore, based on the protocol parsing rules of RTPS packets, network packet 1 can be parsed to obtain the protocol field A corresponding to network packet 1. Protocol field A includes fields such as entity_id, sequence_number, and submessage_type.
[0044] S104. Match the protocol fields with the fault injection rules to determine the type of injected fault corresponding to the network packet; based on the type of injected fault, determine the TC action code corresponding to the network packet; wherein, the TC action code is used to indicate the fault injection operation corresponding to the network packet.
[0045] By matching all fields corresponding to protocol field A with the fault injection rules; when all fields in protocol field A match any rule in the fault injection rules, such as matching fault injection rule a, the injection fault type corresponding to network packet 1 is determined to be the injection fault type corresponding to fault injection rule a.
[0046] In one possible implementation, the protocol field is matched with the fault injection rules to obtain the injected fault type corresponding to the network packet. The specific process is as follows:
[0047] Match the protocol fields with the injection conditions corresponding to the fault injection rules;
[0048] If the protocol field meets the injection conditions corresponding to the fault injection rule, then the injection fault type corresponding to the network packet is determined based on the injection conditions that the protocol field meets.
[0049] For example, fault injection rule 'a' is a packet loss rule: "data,writer_id:0x100c2=>drop,60@out1"; where "data" represents the message type corresponding to fault injection rule 'a', "writer_id:0x100c2" represents the writer ID of the message corresponding to fault injection rule 'a' as 0x100c2, "=>" indicates that the following action is executed when the condition is met, "drop" indicates that the packet loss action is executed, and "@out1" indicates that the action is applied 60 times in the outbound direction of network namespace ns1.
[0050] The injection condition is "message type is data, message writer ID is 0x100c2". When the corresponding message type in protocol field A is "data" and the message writer ID is "0x100c2", protocol field A is determined to meet the injection condition, and the fault injection type corresponding to protocol field A is "packet loss". Based on the fault injection type, the TC action code corresponding to network packet 1 is determined to be "execute packet loss operation".
[0051] In one possible implementation, the TC action code corresponding to the network packet is determined based on the injected fault type, including:
[0052] Update the execution count for the injection failure type corresponding to the network packet;
[0053] Determine whether the number of times the injection fault type corresponding to the network packet is executed exceeds a preset execution threshold. If the number of times the injection fault type corresponding to the network packet is executed does not exceed the preset execution threshold, then mark the TC action code corresponding to the network packet based on the injection fault type.
[0054] Based on the above, the injection fault type corresponding to network packet 1 is determined to be "packet loss", and the threshold for the number of times packet loss is executed is 60. Then, the packet loss count of network packet 1 corresponding to fault injection rule a is incremented by 1. If network packet 1 has already performed packet loss operation 45 times, the packet loss count corresponding to the currently updated network packet is 45+1=46 times. By comparison, it can be seen that the packet loss count corresponding to network packet 1 does not exceed the threshold for the number of times packet loss is executed. Therefore, the TC action code corresponding to network packet 1 is determined to be "execute packet loss operation".
[0055] This step determines whether the number of times network packet injection failures have reached the execution threshold, thereby enabling precise control of the failure testing intensity.
[0056] In one possible implementation, the injected fault type includes packet modification operations, and before marking the TC action code corresponding to the network packet based on protocol fields, it also includes:
[0057] Determine if the injection failure type is a package modification operation;
[0058] If the injected fault type is a packet modification operation, the network packet will be modified based on the corresponding modification information in the fault injection rule.
[0059] Furthermore, before determining the TC action code corresponding to the network packet, it is necessary to determine whether the injected fault type for the network packet is a packet modification operation. If it is a packet modification operation, the network packet is modified according to the corresponding modification information in the fault injection rules; accordingly, the TC action code corresponding to the modified network packet is "continue to flow the network packet in the network". By determining whether the injected fault type is a packet modification operation, if it is, the modification is performed directly in the eBPF program.
[0060] S105. Using a flow control tool, perform fault injection testing on the network packet based on the TC action code corresponding to the network packet.
[0061] In conjunction with the foregoing, if the TC action code corresponding to network packet 1 is "execute packet loss operation", then the packet loss operation test will be performed on network packet 1 through the flow control tool.
[0062] This application provides a fault testing method for a DDS network. When a network packet arrives at the mount point, an eBPF program is triggered. The method determines the identifier field corresponding to the network packet and checks if it matches the identifier field of an RTPS packet. If the identifier field matches, the network packet is identified as an RTPS packet. Protocol parsing is performed on the network packet to obtain its corresponding protocol field. The protocol field is matched with fault injection rules to determine the type of fault to be injected. Based on the fault type, the corresponding TC action code is determined. A flow control tool is used to perform fault injection testing on the network packet based on its corresponding TC action code. This application mounts an eBPF program in the kernel space. The eBPF program has protocol parsing and rule matching functions to achieve accurate matching of RTPS packet parsing with fault injection rules. Furthermore, the low latency and low resource consumption of the eBPF program ensure the real-time performance of the fault injection process, thus enabling the verification of the functional correctness and system stability of the DDS under abnormal network conditions without relying on hardware devices.
[0063] In one possible implementation, the injected fault types also include packet loss operations, delayed packet operations, reordered packet operations, and duplicated packet operations. Based on the TC action code corresponding to the network packet, fault injection testing is performed on the network packet, including:
[0064] If the injected fault type is packet loss operation, then a packet loss test is performed on the network packet based on the TC action code corresponding to the network packet.
[0065] If the injected fault type is a packet modification operation, the network packet continues to circulate in the network;
[0066] If the injected fault type is any one of delayed packet operation, reordered packet operation, or duplicated packet operation, the network packet is sent to the netem queue corresponding to each operation, and the corresponding fault injection test is performed on the network packet.
[0067] For flow control, upon receiving a TC action code, the corresponding test operation is executed based on the TC action code's instruction. For example, if the injected fault type corresponding to the network packet is packet loss, the flow control tool transmits the network packet to the corresponding packet loss operation channel and performs packet loss based on the TC action code "execute packet loss operation." If the injected fault type corresponding to the network packet is packet modification, the network packet continues to circulate in the network. If the injected fault type is any of the following operations: delayed packet operation, reordered packet operation, or duplicated packet operation, for example, if the injected fault type of the network packet is "delayed packet operation," the flow control tool transmits the network packet to the netem queue corresponding to the delayed packet operation to perform a network packet delay operation.
[0068] This step achieves precise isolation of fault testing by transmitting different fault injection types to the corresponding channels, while also adapting to the testing needs of different fault types and improving testing effectiveness.
[0069] In one possible implementation, the method further includes:
[0070] If the identifier field is not the same as the identifier field corresponding to the RTPS packet, then the network packet is determined not to be an RTPS packet, and the network packet continues to flow in the network;
[0071] or;
[0072] If the fault injection rule does not match the protocol field, the network packet will continue to flow in the network.
[0073] In summary, if network packet 1 is not an RTPS packet, no fault injection test will be performed on network packet 1, and network packet 1 will continue to flow in the network. In addition, if network packet 1 is an RTPS packet, but the fault injection rule does not match the protocol field, no fault injection test will be performed on network packet 1, and network packet 1 will continue to flow in the network.
[0074] By filtering network packets, only those that meet the conditions for injecting faults are subjected to fault injection tests, thereby enabling targeted fault testing of network packets and improving the reliability and efficiency of the tests.
[0075] In one possible implementation, the method further includes:
[0076] Create multiple network namespaces; connect the multiple network namespaces through virtual network devices to generate a virtual network topology; each network namespace can run an independent DDS node, and each DDS node corresponds to a unique network node ID;
[0077] Obtain the user's fault injection rules and the corresponding parsing rules for the RTPS protocol. The fault injection rules include the injection conditions and the type of fault to be injected.
[0078] The injection conditions and injection fault types are parsed to obtain the rule data corresponding to the fault injection rules; the rule data is grouped according to the network node ID and traffic direction to obtain the grouping results;
[0079] Based on the grouping results and the parsing rules corresponding to the RTPS protocol, generate the eBPF program for each traffic direction for each network node ID;
[0080] Deploy the eBPF program corresponding to each network node ID at the mount point in the corresponding network namespace.
[0081] To address the issue that existing DDS network fault testing methods lack the ability to parse key fields of the RTPS protocol, making it difficult to accurately inject network faults and leading to discrepancies between test results and real-world scenarios, this application leverages the flexibility and kernel-level performance of eBPF to dynamically compile fault injection rules into executable programs. Furthermore, it constructs a multi-network node test environment using network isolation technology, thereby achieving end-to-end network anomaly verification for the DDS system.
[0082] Specifically, for example, multiple isolated network namespaces can be created on the same Linux host, and then the multiple network namespaces can be connected to communicate through virtual network devices to generate a virtual network topology, thereby simulating various network scenarios.
[0083] Furthermore, the fault injection rules input by the user are obtained. These rules are input in the format of "condition-action-target," for example, "data,writer_id:0x100c2=>drop,60@out1." A parser identifies keywords (such as data, drop, delay, etc.), operators (such as =>, @, :, etc.), numeric types (hexadecimal, range values, ordinary numbers), and identifiers in the fault injection rules. The fault injection rules are then parsed, resulting in the rule data: "When a Data type RTPS packet containing writer_id 0x100c2 is detected, drop this packet 60 times in the outbound direction of network namespace 1."
[0084] Here, traffic direction refers to the direction of network packet transmission; for example, network node IDs include network node 1 and network node 2; traffic direction includes: inflow direction of network node 1, outflow direction of network node 1, inflow direction of network node 2, and outflow direction of network node 2. Each fault injection rule corresponds to the network namespace and traffic direction it affects; the rule data is matched and grouped with the network node ID and traffic direction to obtain the grouping results. For example, for the aforementioned rule, it affects the outflow direction of out1, that is, the outflow direction of network node 1 corresponding to this rule.
[0085] Specifically, the parsing rules corresponding to the protocol can be set in the eBPF program. Therefore, based on the packet results and the parsing rules corresponding to the RTPS protocol, an eBPF program corresponding to each traffic direction for each network node ID is generated; and the eBPF program corresponding to each network node ID is deployed to the mount point in the corresponding network namespace.
[0086] Figure 2 A flowchart illustrating a fault testing method for a DDS network provided in this application. Figure 2 ,like Figure 2 As shown, when a network packet arrives at the mount point, it triggers the eBPF program to perform network packet identification, protocol parsing, and fault rule matching. Specifically, it first determines whether the network packet is an RTPS packet. If the network packet is not an RTPS packet, the fault injection test is not performed on the network packet, and the network packet continues to flow in the network.
[0087] If the network packet is an RTPS packet, RTPS protocol parsing is performed on the network packet to obtain the protocol field; the protocol field is then matched against fault injection rules; if a fault injection rule is matched in the protocol field, the corresponding injection fault type is determined based on the corresponding fault injection rule. Further, the execution count for the corresponding injection fault type of the network packet is updated, and it is determined whether this execution count has reached a preset execution count threshold; if the execution count has not reached the preset execution count threshold, a TC action code is generated; and a fault injection test is performed on the network packet based on the TC action code using a flow control tool.
[0088] If the protocol field does not match the fault injection rule, the network packet will not be tested for fault injection and will continue to flow in the network.
[0089] Figure 3 A schematic diagram of a fault testing device for a DDS network provided in this application is shown below. Figure 3 As shown, the fault testing device 300 for the DDS network provided in this embodiment includes:
[0090] Trigger module 301 is used to trigger the eBPF program when a network packet arrives at the mount point; wherein, the eBPF program is mounted in the mount point of the corresponding network namespace, and the eBPF program is used to perform protocol parsing and fault rule matching on the network packet.
[0091] The determination module 302 is used to determine the identification field corresponding to the network packet and to determine whether the identification field is the identification field corresponding to the RTPS packet; if the identification field is the identification field corresponding to the RTPS packet, then the network packet is determined to be an RTPS packet.
[0092] Processing module 303 is used to parse network packets to obtain the protocol fields corresponding to the network packets;
[0093] The processing module 303 is also used to match the protocol field with the fault injection rule to determine the type of injected fault corresponding to the network packet; and based on the type of injected fault, to determine the TC action code corresponding to the network packet; wherein, the TC action code is used to indicate the fault injection operation corresponding to the network packet.
[0094] Execution module 304 is used to perform fault injection tests on network packets based on the TC action codes corresponding to the network packets using flow control tools.
[0095] In one possible implementation, the processing module 303 is further configured to:
[0096] Match the protocol fields with the injection conditions corresponding to the fault injection rules;
[0097] If the protocol field meets the injection conditions corresponding to the fault injection rule, then the injection fault type corresponding to the network packet is determined based on the injection conditions that the protocol field meets.
[0098] In one possible implementation, the processing module is further configured to:
[0099] Update the execution count for the injection failure type corresponding to the network packet;
[0100] Determine whether the number of times the injection fault type corresponding to the network packet is executed exceeds a preset execution threshold. If the number of times the injection fault type corresponding to the network packet is executed does not exceed the preset execution threshold, then mark the TC action code corresponding to the network packet based on the injection fault type.
[0101] In one possible implementation, the processing module 303 is further configured to:
[0102] Determine if the injection failure type is a package modification operation;
[0103] If the injected fault type is a packet modification operation, the network packet will be modified based on the corresponding modification information in the fault injection rule.
[0104] In one possible implementation, the execution module 304 is further configured to:
[0105] If the injected fault type is packet loss operation, then a packet loss test is performed on the network packet based on the TC action code corresponding to the network packet.
[0106] If the injected fault type is a packet modification operation, the network packet continues to circulate in the network;
[0107] If the injected fault type is any one of delayed packet operation, reordered packet operation, or duplicated packet operation, the network packet is sent to the netem queue corresponding to each operation, and the corresponding fault injection test is performed on the network packet.
[0108] In one possible implementation, the processing module 303 is further configured to:
[0109] Create multiple network namespaces; connect the multiple network namespaces through virtual network devices to generate a virtual network topology; each network namespace can run an independent DDS node, and each DDS node corresponds to a unique network node ID;
[0110] Obtain the user's fault injection rules and the corresponding parsing rules for the RTPS protocol. The fault injection rules include the injection conditions and the type of fault to be injected.
[0111] The injection conditions and injection fault types are parsed to obtain the rule data corresponding to the fault injection rules; the rule data is grouped according to the network node ID and traffic direction to obtain the grouping results;
[0112] Based on the grouping results and the parsing rules corresponding to the RTPS protocol, generate the eBPF program for each traffic direction for each network node ID;
[0113] Deploy the eBPF program corresponding to each network node ID at the mount point in the corresponding network namespace.
[0114] In one possible implementation, the processing module 303 is further configured to:
[0115] If the identifier field is not the same as the identifier field corresponding to the RTPS packet, then the network packet is determined not to be an RTPS packet, and the network packet continues to flow in the network;
[0116] or;
[0117] If the fault injection rule does not match the protocol field, the network packet will continue to flow in the network.
[0118] The fault testing device for the DDS network provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.
[0119] Figure 4 This is a schematic diagram of the structure of an electronic device provided in this application. Figure 4 As shown, the electronic device 40 provided in this embodiment includes at least one processor 401 and a memory 402. Optionally, the device 40 further includes a communication component 403. The processor 401, memory 402, and communication component 403 are connected via a bus 404.
[0120] In a specific implementation, at least one processor 401 executes computer execution instructions stored in memory 402, causing at least one processor 401 to perform the above-described method.
[0121] The specific implementation process of processor 401 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.
[0122] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.
[0123] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.
[0124] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.
[0125] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.
[0126] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.
[0127] The aforementioned readable storage medium 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. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.
[0128] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.
[0129] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.
[0130] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0131] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.
[0132] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0133] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.
[0134] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.
Claims
1. A fault testing method for a DDS network, characterized in that, include: When a network packet arrives at the mount point, the eBPF program is triggered; wherein, the eBPF program is mounted in the mount point of the corresponding network namespace, and the eBPF program is used to perform protocol parsing and fault rule matching on the network packet; Determine the identifier field corresponding to the network packet, and determine whether the identifier field is the identifier field corresponding to the RTPS packet; if the identifier field is the identifier field corresponding to the RTPS packet, then determine that the network packet is an RTPS packet; The network packet is parsed to obtain the protocol field corresponding to the network packet; The protocol field is matched with the fault injection rules to determine the injection fault type corresponding to the network packet; based on the injection fault type, the TC action code corresponding to the network packet is determined; wherein, the TC action code is used to indicate the fault injection operation corresponding to the network packet; Using a flow control tool, a fault injection test is performed on the network packet based on the TC action code corresponding to the network packet.
2. The method according to claim 1, characterized in that, The step of matching the protocol field with the fault injection rules to obtain the injected fault type corresponding to the network packet includes: Match the protocol fields with the injection conditions corresponding to the fault injection rules; If the protocol field meets the injection conditions corresponding to the fault injection rule, then the injection fault type corresponding to the network packet is determined based on the injection conditions met by the protocol field.
3. The method according to claim 2, characterized in that, The step of determining the TC action code corresponding to the network packet based on the injected fault type includes: Update the execution count of the injection fault type corresponding to the network packet; Determine whether the number of times the injected fault type corresponding to the network packet is executed exceeds a preset execution count threshold. If the number of times the injected fault type corresponding to the network packet is executed does not exceed the preset execution count threshold, then mark the TC action code corresponding to the network packet based on the injected fault type.
4. The method according to claim 3, characterized in that, The injected fault type includes packet modification operation. Before generating the TC action code corresponding to the network packet based on the protocol field, the method further includes: Determine whether the injected fault type is a package modification operation; If the injected fault type is a packet modification operation, then the network packet is modified based on the corresponding modification information in the fault injection rule.
5. The method according to claim 4, characterized in that, The injected fault types also include packet loss, delayed packet operation, packet reordering, and packet duplication. The step of performing fault injection testing on the network packet based on the TC action code corresponding to the network packet includes: If the injected fault type is packet loss operation, then a packet loss test is performed on the network packet based on the TC action code corresponding to the network packet; If the injected fault type is a packet modification operation, the network packet continues to circulate in the network; If the injected fault type is any one of the delayed packet operation, the reordered packet operation, and the copied packet operation, then the network packet is sent to the netem queue corresponding to each operation, and the corresponding fault injection test is performed on the network packet.
6. The method according to claim 1, characterized in that, The method further includes: Multiple network namespaces are created; the multiple network namespaces are connected through virtual network devices to generate a virtual network topology; wherein each network namespace can run an independent DDS node, and each DDS node corresponds to a unique network node ID; Obtain the user's fault injection rules and the parsing rules corresponding to the RTPS protocol. The fault injection rules include injection conditions and injected fault types. The injection conditions and the injection fault type are parsed to obtain the rule data corresponding to the fault injection rule; the rule data is grouped according to the network node ID and traffic direction to obtain the grouping results; Based on the grouping results and the parsing rules corresponding to the RTPS protocol, generate an eBPF program for each traffic direction for each network node ID; Deploy the eBPF program corresponding to each network node ID at the mount point in the corresponding network namespace.
7. The method according to claim 1, characterized in that, The method further includes: If the identification field is not the identification field corresponding to the RTPS packet, then the network packet is determined to be not an RTPS packet, and the network packet continues to flow in the network; or; If the fault injection rule does not match the protocol field, the network packet will continue to flow in the network.
8. A fault testing device for a DDS network, characterized in that, include: The triggering module is used to trigger the eBPF program when a network packet arrives at the mount point; wherein, the eBPF program is mounted in the mount point of the corresponding network namespace, and the eBPF program is used to perform protocol parsing and fault rule matching on the network packet; The determination module is used to determine the identification field corresponding to the network packet, and to determine whether the identification field is the identification field corresponding to the RTPS packet; if the identification field is the identification field corresponding to the RTPS packet, then the network packet is determined to be an RTPS packet. The processing module is used to perform protocol parsing on the network packet to obtain the protocol field corresponding to the network packet; The processing module is further configured to match the protocol field with the fault injection rules to determine the injection fault type corresponding to the network packet; and based on the injection fault type, determine the TC action code corresponding to the network packet; wherein the TC action code is used to indicate the fault injection operation corresponding to the network packet. The execution module is used to perform fault injection tests on the network packet based on the TC action code corresponding to the network packet using a flow control tool.
9. An electronic device, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-7.
10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-7.
11. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method described in any one of claims 1-7.