Iot system full-link resilience enhancement method and system

Abstract

The application relates to a kind of Internet of Things system full-link resilience enhancement methods, which comprises: based on protocol semantics and topological perception, fault injection is carried out, and injection data is collected, a multidimensional knowledge graph is constructed according to injection data and system running data after fault injection, reasoning is carried out based on Markov chain model, fault propagation path and corresponding probability are obtained according to the multidimensional knowledge graph, target fault propagation path is determined based on probability, the importance of services in the target fault propagation path is scored through a service scoring model, service degradation strategies are generated according to the importance score results, the health degree of the protocols used in the target fault propagation path is scored through a protocol evaluation model, and protocol switching strategies are generated according to the health degree score results. Through the application, the problem of inaccurate fault simulation of Internet of Things systems is solved, a multidimensional knowledge graph is constructed, fault types, topological relationships and protocol interaction states are integrated, and the restoration degree of fault scenarios is improved.

Description

Technical Field

[0001] This application relates to the field of Internet of Things (IoT) technology, and in particular to methods, systems, electronic devices, and storage media for enhancing the end-to-end resilience of IoT systems. Background Technology

[0002] With the exponential growth in the scale and complexity of the Internet of Things (IoT), IoT systems are severely lacking in resilience against advanced persistent threats (APTs) and complex chain failures, which has become a core security challenge that urgently needs to be overcome.

[0003] Current technical deficiencies are concentrated in four aspects: First, there is a severe disconnect between fault simulation and real-world scenarios. Mainstream solutions rely on preset random fault modes, and traditional chaos engineering tools can only disturb the basic resource layer, generally lacking topology awareness of attack chains and dynamic modeling capabilities for multi-level fault propagation. In particular, they cannot simulate semantic-level attacks against industrial protocols such as MQTT and OPC UA, resulting in a huge deviation between simulated scenarios and real advanced threats, rendering resilience verification ineffective. Second, diagnostic and recovery mechanisms are lagging and rigid. Existing diagnostics are mostly based on single-dimensional threshold alarms, unable to identify cross-device and cross-service related faults; recovery relies on static contingency plans, resulting in low success rates, and fault handling experience has not been structured and precipitated into a reusable knowledge system, leading to low self-healing efficiency. Third, resilience verification is costly and lacks quantitative assessment. Real-world fault testing in industrial settings carries destructive risks, and there is a significant deviation between simulation and production environments; at the same time, the industry lacks key quantitative indicator systems such as fault propagation entropy and recovery path optimality, making it impossible to scientifically assess and optimize system resilience levels. Fourth, there is a general lack of dynamic threat response capabilities. Existing architectures are unable to extract attack features in real time and map them to dynamic knowledge graphs, making them unable to adapt to rapidly evolving attack methods and failure modes, resulting in weak system adaptability. Summary of the Invention

[0004] This application provides a method, system, electronic device, and storage medium for enhancing the end-to-end resilience of an Internet of Things (IoT) system, in order to at least address the problem of inaccurate fault simulation in IoT systems in related technologies.

[0005] In a first aspect, embodiments of this application provide a method for enhancing the end-to-end resilience of an Internet of Things (IoT) system, the method comprising:

[0006] Fault injection is performed based on protocol semantics and topology awareness, and injection data is collected to obtain system operation data after fault injection. A multidimensional knowledge graph is constructed based on the injection data and the system operation data.

[0007] Based on Markov chain model reasoning, the fault propagation path and the corresponding probability of the fault propagation path are obtained according to the multidimensional knowledge graph, and the target fault propagation path is determined based on the probability.

[0008] The importance of services within the target fault propagation path is scored using a pre-built service scoring model, and a service degradation strategy is generated based on the importance score results.

[0009] Using a pre-built protocol evaluation model, the protocols used in the target fault propagation path are scored for health, and a protocol switching strategy is generated based on the health score results.

[0010] In some embodiments, the system operation data includes device status, network traffic, protocol behavior, and resource utilization; the construction of a multidimensional knowledge graph based on the injected data and the system operation data includes:

[0011] Based on the injected data, the device status, the network traffic, the protocol behavior, and the resource utilization, a topological graph of three types of nodes—devices, services, and networks—and their dependencies is constructed to obtain the multidimensional knowledge graph.

[0012] The multidimensional knowledge graph is stored in a graph database;

[0013] The system changes are monitored using topology discovery tools, and the multidimensional knowledge graph is incrementally updated based on the monitored system changes.

[0014] In some embodiments, the Markov chain model-based reasoning, which obtains the fault propagation path and its corresponding probability based on the multidimensional knowledge graph, and determines the target fault propagation path based on the probability, includes:

[0015] A Markov chain is used to model the fault propagation process, with the nodes in the multidimensional knowledge graph as states and the dependencies between nodes as the state transition matrix.

[0016] Based on the state transition matrix, determine the fault propagation path from the source node to the target node and the probability corresponding to the fault propagation path;

[0017] Fault propagation paths with a probability greater than a preset probability threshold are selected as the target fault propagation paths.

[0018] In some embodiments, the service rating model includes:

[0019]

[0020] Among them, S i Assign importance ratings, The number of nodes affected by service i. Let α be the average dependency strength of nodes that directly depend on service i in the multidimensional knowledge graph, and let β be the weighting coefficients, where α+β=1.

[0021] In some embodiments, generating a service degradation strategy based on the importance score results includes:

[0022] Based on the importance score and resource usage, the services within the target fault propagation path are ranked;

[0023] The target service instance to be downgraded is determined based on the sorting results, and the downgrade is performed on the target service instance.

[0024] Once the probability of fault propagation decreases to a preset probability threshold, a tiered traffic recovery strategy is implemented.

[0025] In some embodiments, the protocol evaluation model includes:

[0026]

[0027] Among them, H p For the health of protocol p, γ1, γ2, and γ3 are the weighting coefficients for packet loss rate, latency, and connection success rate, respectively, and γ1 + γ2 + γ3 = 1. p T is the packet loss rate of protocol p. p For the delay of protocol p.

[0028] In some embodiments, the protocol switching strategy generated based on the health score results includes:

[0029] If the health of the primary protocol falls below the first health threshold and the duration exceeds the preset time threshold, a hot switch to the backup protocol is triggered.

[0030] After the health of the main protocol recovers to a level greater than the second health threshold, a step-by-step switchback strategy to the main protocol is executed.

[0031] In some embodiments, the fault injection based on protocol semantics and topology awareness includes:

[0032] A fault injection tool is encapsulated based on Kubernetes Operator. Fault tasks are defined by custom resources. Based on fault control policies, rollbackable fault injection operations are performed according to the fault tasks. The fault control policies include fault duration, fault intensity parameters, and rollback trigger conditions.

[0033] The fault injection supports serial or parallel modes, and the types of fault injection cover all dimensions of faults at the network layer, protocol layer, device layer, and application layer.

[0034] Secondly, embodiments of this application provide an end-to-end resilience enhancement system for an Internet of Things (IoT) system, the system comprising:

[0035] The intelligent fault injection layer is used to inject faults based on protocol semantics and topology awareness, and to collect injection data.

[0036] The knowledge graph reasoning layer is used to acquire system operation data after fault injection, and construct a multidimensional knowledge graph based on the injected data and the system operation data; based on the Markov chain model reasoning, the fault propagation path and the probability corresponding to the fault propagation path are obtained based on the multidimensional knowledge graph, and the target fault propagation path is determined based on the probability;

[0037] The dynamic resilience control layer is used to score the importance of services within the target fault propagation path using a pre-built service scoring model, and generate service degradation strategies based on the importance score results; and to score the health of protocols used within the target fault propagation path using a pre-built protocol evaluation model, and generate protocol switching strategies based on the health score results.

[0038] Thirdly, embodiments of this application provide a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the IoT system end-to-end resilience enhancement method as described in the first aspect above.

[0039] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the IoT system end-to-end resilience enhancement method as described in the first aspect above.

[0040] Compared to related technologies, the IoT system end-to-end resilience enhancement method provided in this application, based on protocol semantics and topology awareness, performs fault injection, which can better align with the actual communication rules and network architecture characteristics of IoT systems. Simultaneously, by combining injected data with post-fault system operation data to construct a multi-dimensional knowledge graph, it can comprehensively integrate multi-dimensional information such as fault type, system topology relationships, and protocol interaction status, significantly improving the fidelity and accuracy of fault scenario reconstruction and solving the problem of inaccurate fault simulation in IoT systems.

[0041] By leveraging Markov chain models to reason about multidimensional knowledge graphs, the probability of different fault propagation paths can be quantitatively calculated, and the target fault propagation path can be accurately identified. This process no longer relies on manual investigation or post-event analysis, but instead uses mathematical models to proactively predict fault propagation trends. This helps the system locate the core propagation links before the impact of a fault escalates, buying time for subsequent rapid recovery measures and effectively addressing the pain point of delayed diagnosis and recovery.

[0042] Service importance scoring based on the service scoring model can identify core and non-core services within the link. The resulting service degradation strategy can accurately cut non-core service resources, ensure the stable operation of core services, and avoid system performance loss caused by indiscriminate degradation. Protocol health scoring based on the protocol evaluation model can generate protocol switching strategies that can selectively replace protocols with low health within the link, thereby improving communication reliability. Attached Figure Description

[0043] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0044] Figure 1 This is a flowchart of an IoT system end-to-end resilience enhancement method according to an embodiment of this application;

[0045] Figure 2 This is a structural block diagram of an IoT system end-to-end resilience enhancement system according to an embodiment of this application;

[0046] Figure 3 This is an execution flowchart of an IoT system end-to-end resilience enhancement system according to an embodiment of this application;

[0047] Figure 4 This is a schematic diagram of the internal structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0048] To make the objectives, technical solutions, and advantages of this application clearer, the application is described and illustrated below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application. All other embodiments obtained by those skilled in the art based on the embodiments provided in this application without inventive effort are within the scope of protection of this application.

[0049] Obviously, the accompanying drawings described below are merely some examples or embodiments of this application. Those skilled in the art can apply this application to other similar scenarios based on these drawings without any inventive effort. Furthermore, it is understood that although the efforts made in this development process may be complex and lengthy, for those skilled in the art related to the content disclosed in this application, any changes to design, manufacturing, or production based on the technical content disclosed in this application are merely conventional technical means and should not be construed as insufficient disclosure of the content of this application.

[0050] In this application, the reference to "embodiment" means that a specific feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment that is mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described in this application may be combined with other embodiments without conflict.

[0051] Unless otherwise defined, the technical or scientific terms used in this application shall have the ordinary meaning understood by one of ordinary skill in the art to which this application pertains. The terms “a,” “an,” “an,” “the,” and similar words used in this application do not indicate quantity limitation and may indicate singular or plural. The terms “comprising,” “including,” “having,” and any variations thereof used in this application are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or device that includes a series of steps or modules (units) is not limited to the listed steps or units, but may also include steps or units not listed, or may include other steps or units inherent to these processes, methods, products, or devices. The terms “connected,” “linked,” “coupled,” and similar words used in this application are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect. “Multiple” used in this application refers to two or more. “And / or” describes the relationship between related objects, indicating that three relationships may exist; for example, “A and / or B” can represent: A alone, A and B simultaneously, and B alone. The character " / " generally indicates that the preceding and following objects are in an "or" relationship. The terms "first," "second," and "third" used in this application are merely to distinguish similar objects and do not represent a specific ordering of the objects.

[0052] This embodiment provides a method for enhancing the end-to-end resilience of an Internet of Things (IoT) system. Figure 1 This is a flowchart of an IoT system end-to-end resilience enhancement method according to an embodiment of this application, such as... Figure 1 As shown, the process includes the following steps:

[0053] Step S101: Perform fault injection based on protocol semantics and topology awareness, collect injection data, obtain system operation data after fault injection, and construct a multi-dimensional knowledge graph based on the injection data and system operation data.

[0054] Fault injection based on protocol semantics and topology awareness differs from traditional random or single-dimensional fault injection methods, and can better align with the actual communication rules and network architecture characteristics of IoT systems. Furthermore, by combining injected data with post-fault system operation data to construct a multi-dimensional knowledge graph, it can comprehensively integrate multi-dimensional information such as fault type, system topology relationships, and protocol interaction status, avoiding the distortion of fault simulation caused by single data dimensions, and significantly improving the realism and accuracy of fault scenarios.

[0055] In some embodiments, the fault injection based on protocol semantics and topology awareness in step S101 includes:

[0056] Step S1011 involves encapsulating a fault injection tool based on the Kubernetes Operator. Fault tasks are defined through custom resources, and rollbackable fault injection operations are executed according to fault control policies. These policies include fault duration, fault strength parameters, and rollback trigger conditions. Fault injection supports serial or parallel modes, and covers fault types across the network layer, protocol layer, device layer, and application layer.

[0057] Based on Kubernetes Operator, fault injection tools (such as ChaosMesh) are encapsulated to support flexible definition of fault tasks through custom resource definitions (CRDs) to adapt to the distributed deployment architecture of IoT systems.

[0058] Supporting both serial and parallel fault injection modes, it can accurately simulate the chain reaction triggered by a single fault or complex anomaly scenarios involving multiple concurrent faults, closely matching the diverse fault characteristics encountered in the actual operation of IoT systems. Through fine-grained configuration of fault duration, fault intensity, and rollback trigger conditions, fault experiments possess precise control over the blast radius (using Kubernetes label selectors and percentage control, faults can be strictly isolated within specific namespaces, service versions, or non-core business modules), strictly limiting the impact of faults to a preset minimum target range. This prevents irreversible damage to core business operations caused by fault injection, ensuring parallel execution of fault testing and business operations.

[0059] CRD, combined with preset rollback trigger conditions (such as duration and monitoring thresholds), ensures that any fault can be automatically and cleanly recovered before or after reaching a critical point, eliminating the risk of human error and missed cleanup. By finely configuring fault duration and intensity parameters, stepped stress tests can be performed (such as gradually increasing the delay from 50ms to 500ms), accurately locating system performance inflection points and crash thresholds, making resilience levels measurable.

[0060] Preferably, it covers all types of faults (e.g., 28 types), including network layer (latency, packet loss, bandwidth limitation, DNS resolution failure), protocol layer (MQTT flooding, CoAP replay, OPC UA command injection), device layer (CPU overload, memory leak, disk failure, device power failure restart) and application layer (database connection pool exhaustion, microservice interface timeout), to achieve semantic-level attack injection of industrial protocols.

[0061] The attack payload is semantically represented, the attack chain is protocolized, and state awareness is protocolized through protocol semantics. Targets for fault injection are selected through topology awareness: based on a real-time understanding of the overall system architecture and dependencies, rather than random or static configuration.

[0062] In some embodiments, system operation data includes device status, network traffic, protocol behavior, and resource utilization; step S101, which constructs a multidimensional knowledge graph based on the injected data and system operation data, includes:

[0063] Step S1012: Based on the injected data, device status, network traffic, protocol behavior, and resource utilization, construct a topological graph of three types of nodes—devices, services, and networks—and their dependencies to obtain a multidimensional knowledge graph.

[0064] Step S1013 stores the multidimensional knowledge graph in a graph database.

[0065] Step S1014: Monitor system changes using topology discovery tools and perform incremental updates to the multidimensional knowledge graph based on the monitored system changes.

[0066] Optionally, multi-dimensional data such as device status (CPU utilization, memory usage, etc.), network traffic (packet loss rate, latency, etc.), protocol behavior, and resource utilization can be collected through node-exporter and a self-developed iot-agent. The collection frequency can be controlled, for example, with a basic collection frequency of 1Hz, which can be increased to 10Hz in abnormal scenarios to ensure data real-time performance.

[0067] The knowledge graph inference layer constructs a dependency graph between devices, services, and protocols by injecting data and system operation data from the IoT system. Neo4j 5.15 can be used as the graph storage. It defines three types of nodes: Device, Service, and Network, and three types of relationships: Connection (CONNECTED_TO), Dependency (DEPENDS_ON), ​​and Communication (COMMUNICATES_WITH). Dynamic topology updates are achieved through a self-developed topology discovery tool (based on nmap, ss commands, and the Kubernetes API). For example, incremental graph updates are completed within 30 seconds after a device / service change.

[0068] This embodiment also includes a historical fault mode library, used to structure and store multiple fault records, including information such as fault type, impact range, recovery strategy, and success rate, providing experience support for the inference engine. Fault propagation inference engine: Preferably, it implements real-time inference based on the Apache Flink stream computing framework, synchronously consuming real-time collected data and fault injection notifications, completing fault feature detection, topology graph loading, and inference computation within 5 seconds.

[0069] Step S102: Based on Markov chain model reasoning, the fault propagation path and the corresponding probability of the fault propagation path are obtained according to the multidimensional knowledge graph, and the target fault propagation path is determined based on the probability.

[0070] In some embodiments, step S102 specifically includes:

[0071] Step S1021: The fault propagation process is modeled using Markov chains, with nodes in the multidimensional knowledge graph as states, and the state transition matrix is ​​constructed based on the dependencies between nodes.

[0072] Step S1022: Based on the state transition matrix, determine the fault propagation path from the source node to the target node and the corresponding probability of the fault propagation path.

[0073] Step S1023: Select fault propagation paths with a probability greater than a preset probability threshold as target fault propagation paths.

[0074] A Markov chain is used to model the fault propagation process. The k-step propagation probability is calculated through the state transition matrix, and high-probability fault propagation paths are screened to provide accurate decision-making basis for the control layer.

[0075] In a multidimensional knowledge graph, nodes represent devices or services, edges represent dependencies, and the state transition matrix P∈R is defined. n×n ,in,

[0076]

[0077] In the formula, P ij Let C be the state transition probability of a fault propagating from node i to node j in one step. ij F represents the number of propagation times from node i to node j in historical faults. i Let be the total number of failures at node i.

[0078] The probability of a fault propagating from node s to node t in k steps is:

[0079]

[0080] By setting a probability threshold θ, high-probability propagation paths (critical paths) are selected:

[0081]

[0082] This model is trained and optimized using historical fault data. Every preset time (e.g., 5 minutes), the weights are corrected based on actual fault propagation feedback. When the deviation exceeds a set threshold (e.g., 20%), it is automatically fine-tuned to ensure inference accuracy.

[0083] Using nodes from a multidimensional knowledge graph as the states of a Markov chain, and constructing a state transition matrix based on the dependencies between nodes, this approach transforms the relationships between entities such as devices, protocols, and services in an IoT system into a quantifiable probabilistic model, accurately mapping the system's topology and entity interaction logic. Furthermore, the Markov chain's lack of aftereffects adapts to the dynamic state changes of IoT systems, avoiding interference from irrelevant historical states in propagation path reasoning and improving modeling accuracy. The "path + probability" output model enables a quantitative assessment of fault propagation risk, providing clear data for subsequent high-risk path selection.

[0084] Step S103: Using a pre-built service scoring model, the importance of services within the target fault propagation path is scored, and a service degradation strategy is generated based on the importance score results.

[0085] Preferably, the top-N (e.g., top-3) high-probability fault propagation paths are used as the sole basis for decision-making regarding service degradation and protocol switching, ensuring targeted control.

[0086] In some embodiments, the service rating model includes:

[0087]

[0088] Among them, S i Assign importance ratings, The number of nodes affected by service i. α represents the average dependency strength of nodes in the multidimensional knowledge graph that directly depend on service i, with α and β being weighting coefficients, where α + β = 1. By balancing the scope of influence and dependency strength through weighting, the score better reflects the actual importance of business operations; α and β can be dynamically adjusted according to different IoT scenarios to improve the model's adaptability.

[0089] In some embodiments, step S103, generating a service degradation strategy based on the importance score results, includes:

[0090] Step S1031: Sort the services within the target fault propagation path according to importance score and resource usage.

[0091] Step S1032: Determine the target service instance to be downgraded based on the sorting results, and perform downgrade on the target service instance.

[0092] Step S1033: After the probability of fault propagation is reduced to a preset probability threshold, a tiered traffic recovery strategy is executed.

[0093] Service degradation is restricted based on importance score results: core services (e.g., score greater than or equal to 80) are prohibited from degradation, important services (e.g., score of 50-79) can be downgraded, and general services (e.g., score less than 50) can be suspended. Precisely distinguishing service priorities ensures that core business operations are not interrupted during fault response and avoids the failure of core system functions due to indiscriminate degradation.

[0094] Sort services, for example, sort services in the Top-3 paths in ascending order by rating and resource usage, and prioritize downgrading instances with low ratings and high resource usage.

[0095] A tiered recovery strategy is adopted. After the probability of fault propagation decreases to a preset probability threshold (e.g., 0.5), a certain amount of traffic (e.g., 10% of the traffic) is restored every preset time interval (e.g., 30 seconds). If the probability (P) rises again, the restoration is paused. Performing tiered traffic restoration after the probability of fault propagation drops to the threshold, rather than a one-time full traffic restoration, effectively avoids secondary problems such as service overload and fault recurrence caused by sudden traffic surges. Simultaneously, a feedback mechanism of "pausing restoration when probability rises" ensures a smooth and controllable traffic restoration process, improving system resilience during the fault recovery phase.

[0096] Step S104: Using a pre-built protocol evaluation model, the health score of the protocols used in the target fault propagation path is calculated, and a protocol switching strategy is generated based on the health score results.

[0097] In some embodiments, the protocol evaluation model includes:

[0098]

[0099] Among them, H p For the health of protocol p, γ1, γ2, and γ3 are the weighting coefficients for packet loss rate, latency, and connection success rate, respectively, and γ1 + γ2 + γ3 = 1. p T is the packet loss rate of protocol p. p For the delay of protocol p;

[0100] In some embodiments, step S104, generating a protocol switching strategy based on the health score result, includes:

[0101] Step S1041: If the health of the main protocol is lower than the first health threshold and the duration exceeds the preset time threshold, a hot switch to the backup protocol is triggered.

[0102] Step S1042: After the health of the main protocol recovers to a level greater than the second health threshold, execute the stepwise switchback strategy to the main protocol.

[0103] Based on a protocol health assessment model, the protocol status is monitored in real time. p A switchover is triggered when the health threshold is below the first threshold (e.g., 0.7) and the duration exceeds a preset time threshold (e.g., 10 seconds). For the primary protocol (MQTT / OPC UA / CoAP) used within the Top-N paths, a hot standby protocol is used to directly migrate sessions, and the old protocol connection is gracefully closed after the gateway layer updates the route. A tiered switchback strategy to the primary protocol is employed: for example, if HP ≥ 0.9 and persists for 5 minutes, a tiered switchback to the primary protocol is initiated, increasing the number of connections by 20% at each step.

[0104] By employing a dual trigger condition combining health thresholds and duration, instantaneous fluctuations in protocol health can be effectively filtered, preventing erroneous switching due to occasional network jitter or excessive instantaneous load. The switching method utilizes hot standby protocols and direct session migration, combined with dynamic gateway-level route updates and graceful closure of old protocol connections, ensuring uninterrupted service traffic transmission during protocol switching. A tiered switchback approach effectively avoids the impact of a large number of instantaneous connection migrations on the primary protocol service, prevents health drops due to sudden increases in protocol load, and ensures a smooth and controllable switchback process.

[0105] After any action of the recovery strategy (service degradation and protocol switching) is completed, within a preset time (e.g., 5 seconds), data such as "actual number of degraded services, new value of protocol health, and CPU decline" are fed back to the knowledge graph inference layer through the Kafka topic control-feedback. The inference layer recalculates the fault propagation probability P based on the feedback data, adjusts the inference model parameters, and realizes closed-loop control of "fault injection - inference decision - control execution - feedback optimization" to continuously improve system resilience.

[0106] By employing the above steps, fault injection based on protocol semantics and topology awareness can align with the actual communication rules and network architecture characteristics of IoT systems. Furthermore, by constructing a multi-dimensional knowledge graph by combining injected data with post-fault system operation data, a comprehensive integration of information such as fault type, system topology relationships, and protocol interaction status can be achieved. This significantly improves the accuracy and realism of fault scenarios, resolving the problem of inaccurate fault simulation in IoT systems.

[0107] By leveraging Markov chain models to reason about multidimensional knowledge graphs, the probability of different fault propagation paths can be quantitatively calculated, and the target fault propagation path can be accurately identified. This process no longer relies on manual investigation or post-event analysis, but instead uses mathematical models to proactively predict fault propagation trends. This helps the system locate the core propagation links before the impact of a fault escalates, buying time for subsequent rapid recovery measures and effectively addressing the pain point of delayed diagnosis and recovery.

[0108] Service importance scoring based on the service scoring model can identify core and non-core services within the link. The resulting service degradation strategy can accurately cut non-core service resources, ensure the stable operation of core services, and avoid system performance loss caused by indiscriminate degradation. Protocol health scoring based on the protocol evaluation model can generate protocol switching strategies that can selectively replace protocols with low health within the link, thereby improving communication reliability.

[0109] It should be noted that the steps shown in the above process or in the flowchart of the accompanying figures can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0110] This embodiment also provides an end-to-end resilience enhancement system for an Internet of Things (IoT) system. This system is used to implement the above embodiments and preferred embodiments, and details already described will not be repeated. As used below, the terms "module," "unit," "subunit," etc., can refer to a combination of software and / or hardware that performs a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0111] Figure 2 This is a structural block diagram of an IoT system end-to-end resilience enhancement system according to an embodiment of this application, such as... Figure 2 As shown, the system includes:

[0112] The intelligent fault injection layer 21 is used to inject faults based on protocol semantics and topology awareness, and to collect injection data.

[0113] The knowledge graph reasoning layer 22 is used to obtain system operation data after fault injection, and construct a multidimensional knowledge graph based on the injected data and system operation data. Based on the Markov chain model reasoning, the fault propagation path and the corresponding probability of the fault propagation path are obtained based on the multidimensional knowledge graph, and the target fault propagation path is determined based on the probability.

[0114] The dynamic resilience control layer 23 is used to score the importance of services within the target fault propagation path using a pre-built service scoring model, and generate service degradation strategies based on the importance scoring results; and to score the health of protocols used within the target fault propagation path using a pre-built protocol evaluation model, and generate protocol switching strategies based on the health scoring results.

[0115] In some embodiments, system operation data includes device status, network traffic, protocol behavior, and resource utilization; the knowledge graph inference layer 22 includes:

[0116] The graph construction module is used to construct a topological graph of three types of nodes—devices, services, and networks—and their dependencies based on injected data, device status, network traffic, protocol behavior, and resource utilization, thereby obtaining a multidimensional knowledge graph.

[0117] The storage module is used to store multidimensional knowledge graphs in a graph database.

[0118] The graph update module is used to monitor system changes through topology discovery tools and perform incremental updates to the multidimensional knowledge graph based on the monitored system changes.

[0119] In some embodiments, the knowledge graph reasoning layer 22 includes:

[0120] The matrix construction module is used to model the fault propagation process using Markov chains, with nodes in a multidimensional knowledge graph as states and the dependencies between nodes as the state transition matrix.

[0121] The path generation module is used to determine the fault propagation path and the corresponding probability of the fault propagation path from the source node to the target node based on the state transition matrix.

[0122] The filtering module is used to filter fault propagation paths with a probability greater than a preset probability threshold as target fault propagation paths.

[0123] In some embodiments, the service rating model includes:

[0124]

[0125] Among them, S i Assign importance ratings, The number of nodes affected by service i. Let α be the average dependency strength of nodes that directly depend on service i in the multidimensional knowledge graph, and let α and β be weighting coefficients, where α + β = 1.

[0126] In some embodiments, the dynamic resilience control layer 23 includes:

[0127] The sorting module is used to sort services within the target fault propagation path based on importance scores and resource usage.

[0128] The degradation module is used to determine the target service instance to be degraded based on the sorting results, and to perform degradation on the target service instance.

[0129] The traffic recovery module is used to execute a tiered traffic recovery strategy after the probability of fault propagation decreases to a preset probability threshold.

[0130] In some embodiments, the protocol evaluation model includes:

[0131]

[0132] Among them, H p For the health of protocol p, γ1, γ2, and γ3 are the weighting coefficients for packet loss rate, latency, and connection success rate, respectively, and γ1 + γ2 + γ3 = 1. p T is the packet loss rate of protocol p. p For the delay of protocol p.

[0133] In some embodiments, the dynamic resilience control layer 23 includes:

[0134] The protocol switching module is used to trigger a hot switch to the backup protocol when the health of the main protocol is lower than the first health threshold and the duration exceeds the preset time threshold.

[0135] The protocol switchback module is used to execute a tiered switchback strategy to the main protocol after the health of the main protocol recovers to a level greater than the second health threshold.

[0136] In some embodiments, the intelligent fault injection layer 21 is specifically used to encapsulate a fault injection tool based on the Kubernetes Operator, define fault tasks through custom resources, and perform rollbackable fault injection operations according to the fault tasks based on fault control policies. The fault control policies include fault duration, fault intensity parameters, and rollback trigger conditions. Fault injection supports serial or parallel modes, and the types of fault injection cover all dimensions of faults at the network layer, protocol layer, device layer, and application layer.

[0137] The aforementioned system, based on protocol semantics and topology awareness, enables fault injection that aligns with the actual communication rules and network architecture characteristics of IoT systems. Furthermore, by constructing a multi-dimensional knowledge graph by combining injected data with post-fault system operational data, it comprehensively integrates multi-dimensional information such as fault type, system topology relationships, and protocol interaction states. This significantly improves the fidelity and accuracy of fault scenario simulation, resolving the issue of inaccurate fault simulation in IoT systems.

[0138] By leveraging Markov chain models to reason about multidimensional knowledge graphs, the probability of different fault propagation paths can be quantitatively calculated, and the target fault propagation path can be accurately identified. This process no longer relies on manual investigation or post-event analysis, but instead uses mathematical models to proactively predict fault propagation trends. This helps the system locate the core propagation links before the impact of a fault escalates, buying time for subsequent rapid recovery measures and effectively addressing the pain point of delayed diagnosis and recovery.

[0139] Service importance scoring based on the service scoring model can identify core and non-core services within the link. The resulting service degradation strategy can accurately cut non-core service resources, ensure the stable operation of core services, and avoid system performance loss caused by indiscriminate degradation. Protocol health scoring based on the protocol evaluation model can generate protocol switching strategies that can selectively replace protocols with low health within the link, thereby improving communication reliability.

[0140] Example of intelligent fault injection layer implementation:

[0141] Hardware and basic environment configuration: Hardware: 8C32G×5-node server cluster; Software: Ubuntu 22.04 operating system + Docker 24.0.7 + Kubernetes 1.29 cluster; ChaosMesh installation: Create ChaosMesh-related CRDs, controller managers, schedulers, and webhook components within the K8s cluster to complete the basic management environment setup for fault injection tasks.

[0142] Fault injection scheduling strategies include timed scheduling and event-triggered scheduling. Timed scheduling can be set to trigger routine resilience tests during the daily off-peak business period from 02:00 to 04:00 to avoid affecting normal business operations. Event-triggered scheduling can be set to immediately trigger a targeted fault injection task for 5 minutes when the monitoring system detects abnormal fluctuations in cluster resources such as CPU utilization >80% or memory utilization >85%, to verify the system's resilience under high load.

[0143] The following is an example of how to build a fault policy library:

[0144] Fault Type Compilation: Typical faults are compiled, covering the network layer, device layer, protocol layer, and application layer, and the injection parameters, scope of impact, and judgment criteria for each type of fault are clarified.

[0145] Fault template definition: Fault templates are defined using YAML format, supporting dynamic parameter replacement. An example of a network latency fault template is shown below:

[0146] yaml

[0147] apiVersion: chaos-mesh.org / v1alpha1

[0148] kind: NetworkChaos

[0149] metadata:

[0150] name: network-delay-template

[0151] spec:

[0152] action: delay

[0153] mode: one

[0154] selector:

[0155] labelSelectors:

[0156] app: iot-gateway

[0157] delay:

[0158] latency: "${latency}" # Default 500ms, can be dynamically adjusted

[0159] jitter: "${jitter}" # Default 100ms, can be dynamically adjusted

[0160] duration: "${duration}" # Default is 10m, can be dynamically adjusted

[0161] Fault Injector Development: Developed using Python and Kubernetes client libraries, it consists of an interface layer, a logic layer, and a driver layer. The interface layer receives fault injection instructions (in JSON format, including fault type, target device, parameters, etc.) by listening to the Kafka topic `fault-inject-topic`. The logic layer parses the instructions and matches them with the corresponding fault template. The driver layer encapsulates the implementation details of fault injection to ensure injection accuracy.

[0162] For range control and data collaboration, the target device / region is precisely located using the K8s tag selector based on range parameters such as "single-device," "regional," and "global" in the command. The injector communicates in real time with the knowledge graph inference layer via the gRPC protocol (port 50051), and injection details (fault type, time, target device, duration) are pushed instantly during fault injection, as shown in the example below:

[0163] json

[0164] {

[0165] "fault_type": "network_delay",

[0166] "inject_time": "2024-12-19T10:30:00Z",

[0167] "target_device": "iot-gateway-10-20-30-40",

[0168] "duration": "300s"

[0169] }

[0170] Meanwhile, resource data during the fault injection process is collected through Prometheus exporter 0.5. Optionally, it is pushed to the knowledge graph inference layer (interface address: http: / / <knowledge graph inference layer IP>:8080 / fault-feedback) every 10 seconds via HTTP POST request in JSON format.

[0171] Example of implementing the knowledge graph reasoning layer:

[0172] Data collection agent deployment: Node-exporter and self-developed iot-agent are deployed on each device node to collect multi-dimensional indicators such as device status, network traffic, and service performance; Data preprocessing: Outliers are removed using a moving average algorithm, and the data is uniformly converted into JSON format and gzip compressed before being pushed to the Kafka topic iot-raw-data for consumption by the inference engine.

[0173] Topology graph construction and updates. Graph configuration: Deploy Neo4j 5.15 graph database, defining three types of nodes: Device (id, type, ip, fw_ver), Service (name, ver, port), and Network (segment, gw, bw), and three types of relationships: CONNECTED_TO (including latency and bw attributes), DEPENDS_ON (including level attribute), and COMMUNICATES_WITH (including proto attribute); Topology discovery and updates: Deploy a self-developed topology discovery tool to periodically scan the system network and service deployment status; When a device / service changes are detected by the agent, a Kafka topic topo-change notification tool is used. The tool rescans the changed area within 30 seconds to complete the incremental graph update.

[0174] Historical Fault Mode Library Construction. 21,400 fault records from January 2022 to May 2024 were compiled and structured, storing information such as fault type, occurrence time, impact scope, duration, handling measures, and recovery success rate in a MySQL database, which is then linked to the Neo4j graph database to provide historical experience data for the inference engine.

[0175] Fault propagation inference engine deployment. The inference engine is deployed based on Apache Flink 1.17, and a Kafka data source is configured (subscribing to iot-raw-data and fault-inject-topic). The Flink job continuously consumes data; upon detecting fault characteristics, it loads the latest topology subgraph from Neo4j, calls the fault propagation path probability model to calculate high-probability paths, completes inference within 5 seconds, and pushes the results (JSON format) to the Kafka topic inference-result for the dynamic resilience control layer to subscribe to.

[0176] Example of implementation of dynamic resilience control layer:

[0177] Control caching and decision-making mechanisms. Deploy a control caching service, subscribe to the Kafka topic inference-result in real time, extract and store the top-3 high-probability fault propagation paths; both the service degradation module and the protocol switcher obtain decision-making basis from the control caching to ensure control consistency.

[0178] Service degradation module implementation. Pre-configure service importance scoring weights α=0.6, β=0.4 (can be adjusted according to the scenario); calculate the Si value of each service in real time, and sort the services in the top-3 paths in ascending order of Si; deploy traffic control components to perform traffic restriction or suspension operations according to degradation rules; collect the fault propagation probability P in real time through monitoring components and execute tiered recovery strategies.

[0179] Protocol switcher implementation. Pre-configured protocol health weights γ1=0.4, γ2=0.3, γ3=0.3, threshold. Deploy a protocol gateway and pre-configure a hot standby environment for MQTT / OPC UA / CoAP protocols; calculate the HP value in real time, and when a switchover is triggered, update the routing rules through the gateway to complete session migration and close old connections; continuously monitor the HP value and execute a tiered switchover when the switchover conditions are met.

[0180] Closed-loop feedback implementation. A feedback collection component is integrated into the service degradation module and protocol switcher, pushing feedback data to the Kafka topic `control-feedback` within 5 seconds of action completion. A data processing component is deployed in the knowledge graph inference layer to consume feedback data and correct fault propagation probability model parameters, achieving 30-second closed-loop optimization.

[0181] After deployment using this implementation plan, the system can achieve: accurate fault injection with a fault simulation deviation of ≤5% from the real scenario; fault response latency of ≤100ms and a fault recovery success rate of ≥95%; and the average system service interruption time is reduced to less than 3 minutes, significantly improving resilience. Figure 3 This is an execution flowchart of an IoT system end-to-end resilience enhancement system according to an embodiment of this application.

[0182] It should be noted that the above modules can be functional modules or program modules, and can be implemented through software or hardware. For modules implemented through hardware, the above modules can reside in the same processor; or the above modules can be located in different processors in any combination.

[0183] This embodiment also provides an electronic device, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0184] Optionally, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor and the input / output device is connected to the processor.

[0185] Optionally, in this embodiment, the processor can be configured to perform the following steps via a computer program:

[0186] S1 performs fault injection based on protocol semantics and topology awareness, collects injection data, obtains system operation data after fault injection, and constructs a multi-dimensional knowledge graph based on the injection data and system operation data.

[0187] S2, based on Markov chain model reasoning, obtains the fault propagation path and the corresponding probability of the fault propagation path according to the multidimensional knowledge graph, and determines the target fault propagation path based on the probability.

[0188] S3 uses a pre-built service scoring model to score the importance of services within the target fault propagation path and generates service degradation strategies based on the importance score results.

[0189] S4 uses a pre-built protocol evaluation model to score the health of protocols used in the target fault propagation path and generates a protocol switching strategy based on the health score results.

[0190] It should be noted that the specific examples in this embodiment can refer to the examples described in the above embodiments and optional implementations, and will not be repeated here.

[0191] In one embodiment, Figure 4This is a schematic diagram of the internal structure of an electronic device according to an embodiment of this application, such as... Figure 4 As shown, an electronic device is provided, which can be a server, and its internal structure diagram can be as follows. Figure 4 As shown, the electronic device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The database stores data. The network interface communicates with external terminals via a network connection. When the computer program is executed by the processor, it implements a method for enhancing the end-to-end resilience of an Internet of Things (IoT) system.

[0192] Those skilled in the art will understand that Figure 4 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the electronic device to which the present application is applied. The specific electronic device may include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements.

[0193] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0194] Those skilled in the art should understand that the technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments have been described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0195] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A method for enhancing the end-to-end resilience of an Internet of Things (IoT) system, characterized in that, The method includes: Fault injection is performed based on protocol semantics and topology awareness. The attack payload is semanticized, the attack link is protocolized, and the state awareness is protocolized through protocol semantics. The protocol semantic level attack injection includes MQTT flooding, CoAP replay, and OPC UA command injection at the protocol layer. Injection data is collected, and system operation data after fault injection is obtained. A multi-dimensional knowledge graph is constructed based on the injection data and the system operation data. Based on Markov chain model reasoning, the fault propagation path and the corresponding probability of the fault propagation path are obtained according to the multidimensional knowledge graph, and the target fault propagation path is determined based on the probability. Using a pre-built service scoring model, the importance of services within the target fault propagation path is scored, and a service degradation strategy is generated based on the importance score results, including: Based on the importance score and resource usage, the services within the target fault propagation path are ranked; The target service instance to be downgraded is determined based on the sorting results, and the downgrade is performed on the target service instance. Once the probability of fault propagation decreases to a preset probability threshold, a tiered traffic recovery strategy is implemented. Using a pre-built protocol evaluation model, the protocols used in the target fault propagation path are scored for health, and a protocol switching strategy is generated based on the health score results.

2. The method according to claim 1, characterized in that, The system operation data includes device status, network traffic, protocol behavior, and resource utilization; the construction of a multidimensional knowledge graph based on the injected data and the system operation data includes: Based on the injected data, the device status, the network traffic, the protocol behavior, and the resource utilization, a topological graph of three types of nodes—devices, services, and networks—and their dependencies is constructed to obtain the multidimensional knowledge graph. The multidimensional knowledge graph is stored in a graph database; The system changes are monitored using topology discovery tools, and the multidimensional knowledge graph is incrementally updated based on the monitored system changes.

3. The method according to claim 1, characterized in that, The Markov chain model-based reasoning, based on the multidimensional knowledge graph, obtains the fault propagation path and the corresponding probability of the fault propagation path, and determines the target fault propagation path based on the probability, including: A Markov chain is used to model the fault propagation process, with the nodes in the multidimensional knowledge graph as states and the dependencies between nodes as the state transition matrix. Based on the state transition matrix, determine the fault propagation path from the source node to the target node and the probability corresponding to the fault propagation path; Fault propagation paths with a probability greater than a preset probability threshold are selected as the target fault propagation paths.

4. The method according to claim 1, characterized in that, The service rating model includes: Among them, S i For importance scoring, N i D represents the number of nodes affected by service i. i Let α be the average dependency strength of nodes that directly depend on service i in the multidimensional knowledge graph, and let β be the weighting coefficients, where α+β=1.

5. The method according to claim 1, characterized in that, The protocol evaluation model includes: Among them, H p For the health of protocol p, γ1, γ2, and γ3 are the weighting coefficients for packet loss rate, latency, and connection success rate, respectively, where γ1 + γ2 + γ3 = 1, L p T is the packet loss rate of protocol p. p For the delay of protocol p.

6. The method according to claim 5, characterized in that, The protocol switching strategy generated based on the health score results includes: If the health of the primary protocol falls below the first health threshold and the duration exceeds the preset time threshold, a hot switch to the backup protocol is triggered. After the health of the main protocol recovers to a level greater than the second health threshold, a step-by-step switchback strategy to the main protocol is executed.

7. The method according to claim 1, characterized in that, The fault injection based on protocol semantics and topology awareness includes: A fault injection tool is encapsulated based on Kubernetes Operator. Fault tasks are defined by custom resources. Based on fault control policies, rollbackable fault injection operations are performed according to the fault tasks. The fault control policies include fault duration, fault intensity parameters, and rollback trigger conditions. The fault injection supports serial or parallel modes, and the types of fault injection cover all dimensions of faults at the network layer, protocol layer, device layer, and application layer.

8. A system for enhancing the end-to-end resilience of an Internet of Things (IoT) system, characterized in that, The system includes: The intelligent fault injection layer is used for fault injection based on protocol semantics and topology awareness. It semanticizes attack payloads, protocolizes attack links, and protocolizes state awareness through protocol semantics. The protocol semantic level attack injection includes MQTT flooding, CoAP replay, and OPC UA command injection at the protocol layer, and collects injection data. The knowledge graph reasoning layer is used to acquire system operation data after fault injection, and construct a multidimensional knowledge graph based on the injected data and the system operation data; based on the Markov chain model reasoning, the fault propagation path and the probability corresponding to the fault propagation path are obtained based on the multidimensional knowledge graph, and the target fault propagation path is determined based on the probability; A dynamic resilience control layer is used to score the importance of services within the target failure propagation path using a pre-built service scoring model, and generate service degradation strategies based on the importance score results, including: Based on the importance score and resource usage, the services within the target fault propagation path are ranked; The target service instance to be downgraded is determined based on the sorting results, and the downgrade is performed on the target service instance. Once the probability of fault propagation decreases to a preset probability threshold, a tiered traffic recovery strategy is implemented. Using a pre-built protocol evaluation model, the protocols used in the target fault propagation path are scored for health, and a protocol switching strategy is generated based on the health score results.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the IoT system end-to-end resilience enhancement method as described in any one of claims 1 to 7.

Images