Dynamic diagnosis task orchestration method based on alarm triggering and related device

Abstract

The application provides a dynamic diagnosis task arrangement method based on alarm triggering and related equipment, and belongs to the technical field of intelligent operation and maintenance of communication networks. The method comprises determining a plurality of candidate fault root causes according to a fault event, and initializing a root cause probability distribution. When a root cause detection convergence condition is currently reached, the candidate fault root cause with the highest root cause probability value is determined as a target fault root cause according to the current root cause probability distribution. When the root cause detection convergence condition cannot be reached at present, the dynamic task value of each dialing test task is calculated according to the root cause probability distribution and the conditional probability of each dialing test task under the observation result of different fault root causes, the highest dialing test task of the dynamic task value is selected for execution to obtain the current observation result of the dialing test task, and the root cause probability distribution is updated according to the current observation result. The above process is repeated until the convergence condition is reached. The application can improve the flexibility of task arrangement, improve the diagnosis efficiency, and reduce resource waste.

Description

Technical Field

[0001] This application relates to the field of intelligent operation and maintenance technology for communication networks, and in particular to a method for orchestrating dynamic diagnostic tasks based on alarm triggering and related equipment. Background Technology

[0002] In current network operation and maintenance systems, alarm monitoring systems and fault detection systems are deployed independently. Alarm systems achieve fault detection through device indicator collection, but fault location task orchestration largely relies on static rules or manual experience, failing to adapt to dynamic changes in network topology and fault modes. Fault detection systems execute probe tasks periodically based on a fixed probe task sequence, unable to dynamically adjust detection strategies according to real-time alarms. In summary, related technologies orchestrate probe tasks based on predetermined task flows according to fault conditions, unable to dynamically adapt to real-time fault detection, and the root cause of the detection process is difficult to quantify and converge, resulting in low diagnostic efficiency and significant resource waste. Summary of the Invention

[0003] The main objective of this application is to propose a dynamic diagnostic task orchestration method and related equipment based on alarm triggering, which aims to improve the flexibility of diagnostic task orchestration, increase diagnostic efficiency, and reduce resource waste.

[0004] To achieve the above objectives, one aspect of this application proposes a dynamic diagnostic task orchestration method based on alarm triggering, comprising the following steps: Based on the failure event, multiple candidate root causes of failure are identified, and the root cause probability distribution of the multiple candidate root causes of failure is initialized. Determine whether the root cause detection convergence condition has been met. If the root cause detection convergence condition is met, the candidate fault root cause with the highest root cause probability value is selected as the target fault root cause according to the current root cause probability distribution. If the root cause detection convergence condition cannot be met at present, the dynamic task value of each detection task in the task set is calculated based on the root cause probability distribution and the conditional probability of each detection task in the task set under the observation results of different root causes of the fault. Select the highest dynamic task value from the task set for execution to obtain the current observation results of the task. The root cause probability distribution is updated based on the current observation results, and the step of determining whether the root cause detection convergence condition has been met is repeated.

[0005] In some embodiments, the alarm-triggered dynamic diagnostic task orchestration method further includes the following steps: Collect fault alarm data and then preprocess the fault alarm data; The preprocessed fault alarm data is aggregated according to a preset time window to obtain a single fault event.

[0006] In some embodiments, initializing the root cause probability distribution of the plurality of candidate root causes includes the following steps: Obtain the historical occurrence frequency of each candidate root cause of the fault; The root cause probability value of each candidate fault root cause is determined by normalizing the historical occurrence frequency of each candidate fault root cause based on multiple historical occurrence frequencies. A root cause probability distribution is formed based on the root cause probability value of each candidate root cause of the fault.

[0007] In some embodiments, determining whether the root cause detection convergence condition has been met includes the following steps: Determine whether there is a root cause probability value in the root cause probability distribution that is greater than or equal to the termination threshold; If there is a root cause probability value that is greater than or equal to the termination threshold, then it is determined that the root cause detection convergence condition has been met. If there is no root cause probability value greater than or equal to the termination threshold, the convergence condition for root cause detection is determined based on the number of successfully executed test tasks reaching the preset maximum number of tasks.

[0008] In some embodiments, calculating the dynamic task value of each testing task in the task set based on the root cause probability distribution and the conditional probability of each testing task in the task set under different root causes of failure includes the following steps: Select multiple corresponding test tasks based on the fault event, and remove test tasks that have been successfully executed or are unusable from the multiple test tasks to form a task set; For each test task in the task set, the posterior probability of the test task under different observation results is calculated based on the conditional probability of the test task under different root causes of failure and the root cause probability distribution. The dynamic task value of the test task is calculated based on the posterior probability under different observation results and the execution cost of the test task.

[0009] In some embodiments, updating the root cause probability distribution based on the current observation results includes the following steps: Obtain the conditional probability of the current test task executed in the current round under the current observation results for different root causes of failure; Based on the acquired multiple conditional probabilities, the posterior probability of each candidate fault root cause under the current observation results of the probe task is calculated using Bayes' theorem. The root cause probability distribution is updated based on the posterior probability of each candidate root cause of failure.

[0010] In some embodiments, the alarm-triggered dynamic diagnostic task orchestration method further includes the following steps: Obtain the verification results of the target fault root cause; If the verification result is valid, the conditional probability of the successful test task performed in this fault event under the target fault root cause is updated based on the forgetting factor.

[0011] To achieve the above objectives, another aspect of this application proposes a dynamic diagnostic task orchestration system based on alarm triggering, comprising: An initialization module is used to determine multiple candidate root causes of failure based on a failure event, and to initialize the root cause probability distribution of the multiple candidate root causes of failure. The convergence judgment module is used to determine whether the root cause detection convergence condition has been met. The root cause localization module is used to select the candidate fault root cause with the highest root cause probability value as the target fault root cause when the current root cause detection convergence condition is met. The task value calculation module is used to calculate the dynamic task value of each probe task in the task set based on the root cause probability distribution and the conditional probability of each probe task in the task set under the observation results of different root causes of failure when the root cause detection convergence condition cannot be met at present. The task observation module is used to select the highest dynamic task value from the task set for execution in order to obtain the current observation results of the task. The update module is used to update the root cause probability distribution based on the current observation results and return it to the convergence judgment module.

[0012] To achieve the above objectives, another aspect of this application provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above-described method.

[0013] To achieve the above objectives, another aspect of the embodiments of this application proposes a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0014] The embodiments of this application include at least the following beneficial effects: This application provides a method and related equipment for dynamic diagnostic task orchestration based on alarm triggering. This scheme determines multiple candidate root causes of faults based on fault events and initializes the root cause probability distribution of multiple candidate root causes of faults. When the current root cause detection convergence condition is met, the candidate root cause with the highest root cause probability value is selected as the target root cause of fault based on the current root cause probability distribution. When the current root cause detection convergence condition cannot be met, the dynamic task value of each testing task in the task set is calculated based on the root cause probability distribution and the conditional probability of each testing task in the task set under the observation results of different root causes of faults. Then, the testing task with the highest dynamic task value is selected from the task set for execution to obtain the current observation results of the testing task. The root cause probability distribution is then updated based on the current observation results, and the above process is repeated until the convergence condition is met. This scheme calculates the task value by combining the conditional probability of the task under the observation results of different root causes of failure during the task orchestration process. Based on this, after selecting a suitable test task, the task value is iteratively calculated according to the actual fault observation results and a more suitable task is selected for execution. This achieves dynamic task orchestration, which improves the flexibility of test task orchestration. At the same time, it sets the convergence conditions of the detection process, which improves diagnostic efficiency and reduces resource waste. Attached Figure Description

[0015] Figure 1 This is a flowchart of the dynamic diagnostic task orchestration method based on alarm triggering provided in the embodiments of this application; Figure 2 This is a flowchart of a dynamic diagnostic task orchestration method based on alarm triggering provided in another embodiment of this application; Figure 3 yes Figure 1 The flowchart of step S101 in the text; Figure 4 yes Figure 1 The flowchart of step S102 in the document; Figure 5 yes Figure 1 The flowchart of step S104 in the process; Figure 6 yes Figure 1 The flowchart of step S106 in the process; Figure 7 This is a flowchart of a dynamic diagnostic task orchestration method based on alarm triggering provided in another embodiment of this application; Figure 8 This is a schematic diagram of a dynamic diagnostic task orchestration system based on alarm triggering provided in an embodiment of this application; Figure 9 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application; Figure 10This is a system architecture diagram provided in the embodiments of this application; Figure 11 This is a flowchart of dynamic diagnostic sequence arrangement provided in the embodiments of this application. Detailed Implementation

[0016] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit it. In the following description, when referring to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with those of this application; they are merely examples of apparatuses and methods consistent with some aspects of the embodiments of this application as detailed in the appended claims.

[0017] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0018] Before providing a detailed description of the embodiments of this application, some of the nouns and terms involved in the embodiments of this application will be explained first. The nouns and terms involved in the embodiments of this application are subject to the following interpretations.

[0019] Time window aggregation merges similar alarms from the same device or devices with direct dependencies within a preset time window (default 60 seconds), generating a single fault event. This avoids alarm duplication and redundancy. Device dependencies refer to direct physical connections (such as direct fiber optic connections) or business logic dependencies (such as parent-child service relationships) between devices, which can be determined through topology information in a knowledge graph.

[0020] Entropy measures the uncertainty of the probability distribution of failure assumptions; the higher the value, the greater the uncertainty.

[0021] Marginal probability represents the total probability of a given observation occurring.

[0022] Posterior probability (Bayes' theorem) refers to the probability of each candidate root cause of failure calculated based on the observation results.

[0023] Posterior entropy represents the uncertainty remaining after a specific outcome has been observed.

[0024] Conditional entropy represents the expected remaining uncertainty after performing the test task T.

[0025] Information gain represents the amount of uncertainty that can be reduced by performing the test task T.

[0026] Task value score indicates the cost-effectiveness of a task and is used to select the optimal task.

[0027] Cost level indicates the quantitative standard of task execution cost, such as low cost (1): execution time < 1 second, bandwidth consumption < 10KB; medium cost (2): 1 second ≤ execution time < 3 seconds, bandwidth consumption 10KB ~ 100KB; high cost (3): execution time ≥ 3 seconds, bandwidth consumption ≥ 100KB or involving device write operation.

[0028] The task timeout threshold is used as the basis for judging task fault tolerance and replacement. For example, Ping has a default timeout of 3 seconds, and HTTP GET has a default timeout of 5 seconds. If no result is returned after this time, the task is considered to have failed. Dynamic configuration is supported, and it can be adjusted through the management interface according to network conditions.

[0029] The forgetting factor (α) is used to make the system pay more attention to recent fault characteristics. For example, the default value is 0.95. It is used to balance the weights of historical data and new observation data in the conditional probability table.

[0030] Knowledge updates involve smoothly updating conditional probabilities using new observational data, with more recent data having greater weight.

[0031] Fault hypothesis refers to the candidate root causes of a fault event. Each candidate root cause hypothesis corresponds to a set of fault characteristics and conditional probabilities.

[0032] Prior probability, the initial confidence probability of the fault hypothesis, is obtained by normalizing the historical occurrence frequency of similar faults. It is the initial probability before the test verification is performed. It is different from the posterior probability updated after the test task is performed, and serves as the calculation benchmark for each iteration.

[0033] The termination threshold is a probability threshold used to determine whether the diagnostic process should terminate, such as 0.8. It can be dynamically configured according to the fault tolerance requirements of the operation and maintenance scenario and does not constitute a limitation of this invention. The termination condition is met when the probability of the highest probability fault assumption is greater than or equal to this threshold.

[0034] System-level anomalies refer to scenarios where the test task ultimately fails to return valid business observation results, such as not receiving a response after the test task execution or test task delivery failure. In this scenario, there are no valid observation results, and the task does not participate in Bayesian belief updates; only task fault-tolerant replacement is triggered.

[0035] Maximum number of tasks: The maximum number of test tasks allowed to be executed during the diagnostic iteration process, such as 5 times. It can be dynamically configured according to business timeliness requirements. Only successfully executed tasks are counted, and tasks that fail to execute are not included in the count.

[0036] Successful execution means the test command was issued, executed, and returned a clear business observation result, regardless of whether the result is positive (e.g., Ping successful) or negative (e.g., Ping timed out). Only successfully executed tasks will have their returned business results used for Bayesian belief updates.

[0037] The core shortcomings of existing solutions can be summarized into four categories, and this solution proposes targeted solutions: First, the testing task is completely decoupled from the fault scenario: fixed-cycle and fixed-sequence testing cannot perform targeted verification of fault assumptions associated with real-time alarms, resulting in a high proportion of invalid probes and serious waste of network resources. At the same time, key verification links are missing, and the root cause location efficiency is extremely low. Second, the convergence of root causes of faults lacks a quantitative iterative mechanism: it relies on static rules or human experience, cannot dynamically update the fault confidence based on real-time test evidence, cannot adaptively converge the range of root causes, and has poor diagnostic accuracy and interpretability. Third, the diagnostic process lacks engineering-based fault tolerance: when the test task is executed abnormally due to probe failure or network timeout, there is no automated backup replacement mechanism, which can easily lead to interruption of the diagnostic process and make it impossible to guarantee the continuity of fault location. Fourth, the fault diagnosis model lacks self-optimization capability: it cannot continuously optimize the probability of fault features based on historical diagnosis results, cannot adapt to dynamic changes in network topology and fault modes, and cannot guarantee long-term diagnostic accuracy.

[0038] Furthermore, the existing alarm aggregation mechanism is completely disconnected from the subsequent diagnostic process. The aggregated alarms cannot be directly linked to the generation of fault assumptions, resulting in redundant diagnostic inputs and numerous interference items, which further reduces diagnostic efficiency.

[0039] In view of this, this application provides a dynamic diagnostic task orchestration method and related equipment based on alarm triggering. It mainly solves the technical problems of decoupling the testing task orchestration from the fault scenario, the inability to dynamically adapt to real-time fault detection, and the difficulty in quantifying and converging the root causes of the detection process, resulting in low diagnostic efficiency and serious resource waste. In the task orchestration process, the solution combines the conditional probability of the task under the observation results of different fault root causes to calculate the task value. Based on this, after selecting a suitable testing task, the solution iteratively calculates the task value according to the observation results of the actual fault and selects a more suitable task to execute, thereby realizing dynamic task orchestration and improving the flexibility of testing task orchestration. At the same time, it sets the convergence conditions of the detection process to improve diagnostic efficiency and reduce resource waste.

[0040] The alarm-triggered dynamic diagnostic task orchestration method provided in this application relates to the field of intelligent operation and maintenance technology for communication networks. This alarm-triggered dynamic diagnostic task orchestration method can be applied to terminals, servers, or software running on either terminal or server. In some embodiments, the terminal can be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, or vehicle terminal, but is not limited to these. The server can be configured as an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The server can also be a node server in a blockchain network. The software can be an application implementing the alarm-triggered dynamic diagnostic task orchestration method, but is not limited to the above forms.

[0041] This application can be used in a wide variety of general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics devices, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices. This application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0042] The method in this application embodiment can be implemented with the following system architecture, please refer to... Figure 10 The system architecture diagram shown includes the following core modules, which communicate through standardized interfaces, with the diagnostic decision engine serving as the core control unit: Alarm access module: Receives real-time alarms from external alarm systems, performs standardization, deduplication, and time window aggregation processing, and generates a single fault event; Diagnostic Decision Engine: Includes core units such as hypothesis generation, value assessment, task scheduling, belief updating, termination judgment, and root cause output, and is responsible for the orchestration of the entire diagnostic logic process; Distributed probing executor cluster: Probing probes deployed on various network nodes receive task instructions from the diagnostic decision engine, execute probing, and return results (such as Ping, Traceroute, HTTPGet, etc.). Knowledge graph database: Stores network topology information, conditional probability tables for fault hypothesis-probe tasks, historical frequency of similar faults, equipment dependencies, and other data to provide data support for the diagnostic process.

[0043] Figure 1 This is an optional flowchart of the alarm-triggered dynamic diagnostic task orchestration method provided in the embodiments of this application. Figure 1 The method may include, but is not limited to, steps S101 to S106.

[0044] S101, determine multiple candidate root causes of failure based on the failure event, and initialize the root cause probability distribution of multiple candidate root causes of failure. S102, determine whether the root cause detection convergence condition has been met; S103, If the current root cause detection convergence condition is met, select the candidate fault root cause with the highest root cause probability value as the target fault root cause according to the current root cause probability distribution. S104. In the case that the root cause detection convergence condition cannot be met at present, calculate the dynamic task value of each detection task in the task set based on the root cause probability distribution and the conditional probability of each detection task in the task set under the observation results of different root causes of the fault. S105, Select the highest dynamic task value from the task set for execution to obtain the current observation results of the task. S106, Update the root cause probability distribution based on the current observation results, and repeat step S102.

[0045] Steps S101 to S106 as shown in the embodiments of this application calculate the task value by combining the conditional probability of the task under the observation results of different root causes of the fault during the task orchestration process. Based on this, after selecting a suitable test task, the task value is iteratively calculated according to the observation results of the actual fault and a more suitable task is selected for execution. This realizes dynamic task orchestration, improves the flexibility of test task orchestration, and sets the convergence conditions of the detection process to improve diagnostic efficiency and reduce resource waste.

[0046] In step S101 of some embodiments, multiple candidate root causes of failure are determined based on the failure event, and the root cause probability distribution of the multiple candidate root causes of failure is initialized. Specifically, the system can generate candidate failure hypotheses (including candidate root causes of failure) based on relevant data of the failure event, and can initialize the root cause probability value (i.e., initial prior probability) of each candidate failure hypothesis based on human experience, historical occurrence of candidate root causes of failure, and other data to form a root cause probability distribution.

[0047] In some embodiments, please refer to Figure 2 The alarm-triggered dynamic diagnostic task orchestration method in this application embodiment may also include, but is not limited to, the following steps: S201, Collect fault alarm data and then preprocess the fault alarm data; S202, the preprocessed fault alarm data is aggregated according to a preset time window to obtain a single fault event.

[0048] In this embodiment, the alarm access module receives real-time alarm data from an external alarm system, performs preprocessing such as standardization (unified field format, alarm type normalization) and deduplication, and then merges and aggregates similar alarm data from the same device or devices with direct dependencies based on a preset time window (default 60 seconds, configurable) and the device dependencies indicated in the knowledge graph, generating a single fault event. This fault event includes core information such as event identifier, involved devices, and associated services. The fault event is then pushed to the diagnostic decision engine to trigger the subsequent diagnostic process.

[0049] This embodiment uses a preset time window and aggregation rules associated with device dependencies to merge similar alarms from the same device and devices with direct dependencies, generating a single fault event. The aggregation result can then be directly linked to fault hypothesis matching and initial prior probability assignment, solving the problems of alarm redundancy, disconnect between diagnostic input and subsequent processes, and numerous interference items. This provides accurate input for subsequent diagnostic processes and reduces invalid calculations.

[0050] In some embodiments, please refer to Figure 3 The initialization of the root cause probability distribution of multiple candidate fault root causes in step S101 may include, but is not limited to, the following steps: S301, obtain the historical occurrence frequency of each candidate root cause of the fault; S302, normalize the historical occurrence frequency of each candidate fault root cause based on multiple historical occurrence frequencies to determine the root cause probability value of the candidate fault root cause. S303, form a root cause probability distribution based on the root cause probability value of each candidate fault root cause.

[0051] In this embodiment, the diagnostic decision engine queries a knowledge graph database for possible candidate root causes and their historical occurrence frequencies based on fault events. The historical occurrence frequencies are normalized to obtain the initial prior probability of each candidate root cause, i.e., the root cause probability value, representing the initial confidence probability of the fault hypothesis. Specifically, multiple sets of fault features for different alarms can be extracted from fault events. Each fault feature is matched with a corresponding candidate root cause and a corresponding set of conditional probabilities from the knowledge graph database to generate candidate fault hypotheses, which serve as the data basis for subsequent diagnostic analysis. This embodiment generates root cause hypotheses by linking fault events and determines their initial prior probabilities based on the historical occurrence frequencies of each root cause hypothesis. This improves the accuracy of root cause probability value initialization, reduces the number of subsequent iterations, and increases diagnostic efficiency.

[0052] In other embodiments, this embodiment also sets cold start processing rules. If there is no historical frequency data of the corresponding fault in the knowledge graph, an initial prior probability of equal value can be assigned to each candidate fault based on expert experience, or a value can be assigned according to the general industry occurrence probability of the fault type.

[0053] Furthermore, after initializing the root cause distribution probability, a boundary processing rule is used to determine whether to proceed to the subsequent probing process. The boundary processing rule states that if only one valid fault hypothesis is matched, or the prior probability of a hypothesis (i.e., a candidate root cause) is greater than or equal to the termination threshold, then the current detection convergence condition is considered met, and the process directly jumps to step S103 to output the root cause, without needing to execute the subsequent probing process. This embodiment can also initialize an executed task count to 0, incrementing this value by 1 for each successful task execution, used to determine whether the current detection convergence condition has been met.

[0054] In step S102 of some embodiments, it can be determined whether the probe convergence condition has been met based on the root cause distribution probability or the number of tasks executed. The diagnostic decision engine verifies whether any of the following termination conditions are met: Condition 1: The updated root cause distribution probability has a root cause probability value (i.e., posterior probability) of a certain fault hypothesis ≥ the preset termination threshold (default 0.8). Condition 2: The number of successfully executed test tasks has reached the preset maximum number of tasks (default 5 times, configurable). If any termination condition is met, proceed to step S103; if not, proceed to step S104, recalculate the value score of the remaining tasks based on the updated probability distribution, and start the next iteration.

[0055] In some embodiments, please refer to Figure 4 Step S102 may include, but is not limited to, the following steps: S401, Determine whether there is a root cause probability value in the root cause probability distribution that is greater than or equal to the termination threshold; S402, if there is a root cause probability value that is greater than or equal to the termination threshold, then it is determined that the current root cause detection convergence condition has been met. S403, when there is no root cause probability value greater than or equal to the termination threshold, determine whether the root cause detection convergence condition has been met based on the number of successfully executed probing tasks reaching the preset maximum number of tasks.

[0056] In this embodiment, it is determined whether there is a root cause probability value (initial prior probability or iterative posterior probability) in the root cause probability distribution that is greater than or equal to the termination threshold. If it exists, it is determined that the current root cause detection convergence condition has been met, and step S103 is executed to output the root cause. If it does not exist, it is determined whether the number of successfully executed test tasks (this value is 0 in the initialization process) has reached the preset maximum number of tasks (e.g., 5 times), or whether the number of candidate fault root causes is 1. If either condition is met, it is determined that the current root cause detection convergence condition has been met, and step S103 is executed to output the root cause. Otherwise, it is determined that the current root cause detection convergence condition has not been met, and step S104 is executed to continue the iteration.

[0057] In this embodiment, the root cause localization and testing orchestration process is configured with conditions such as whether there is a root cause probability value greater than or equal to the termination threshold in the root cause probability distribution, and whether the number of successfully executed testing tasks has reached the preset maximum number of tasks. This allows the iterative process of task orchestration and execution to be terminated at the appropriate time, thereby achieving dynamic focusing on the root cause of the fault and reducing invalid detection and resource waste.

[0058] In step S103 of some embodiments, if the detection convergence condition is met, the fault hypothesis with the highest probability in the current root cause probability distribution is output as the final root cause, along with the posterior probability of the root cause and a confidence level label indicating whether the termination threshold is met. This result can be directly used as input for extended functions such as confidence quantification and alarm suppression.

[0059] In step S104 of some embodiments, if the root cause detection convergence condition cannot be met at present, the dynamic task value of each detection task in the task set is calculated based on the root cause probability distribution and the conditional probability of each detection task in the task set under the observation results of different fault root causes.

[0060] In some embodiments, please refer to Figure 5 Step S104 may include, but is not limited to, the following steps: S501: Select multiple corresponding test tasks based on the fault event, and remove test tasks that have been successfully executed and those that are unusable from the multiple test tasks to form a task set; S502, for each test task in the task set, calculate the posterior probability of the test task under different observation results based on the conditional probability and root cause probability distribution of the test task under different root causes of failure, and calculate the dynamic task value of the test task based on the posterior probability under different observation results and the execution cost of the test task.

[0061] In step S501 of some embodiments, the diagnostic decision engine retrieves the test tasks corresponding to the current fault event from the knowledge graph database, excludes test tasks that have been successfully executed and those that are unavailable, and forms a task set. Unavailable test tasks refer to test tasks that fail to execute due to system-level anomalies. That is, when a task fails to return a valid result after execution due to probe failure, timeout, or other anomalies, it is marked as unavailable. Unavailable tasks will not appear in the subsequent task set that needs to be orchestrated, and therefore their task value will not be calculated for repeated execution, nor will they participate in the root cause distribution probability update, nor will they be included in the maximum task count. By excluding test tasks with execution anomalies, problems such as interruption of subsequent diagnostic processes and poor engineering availability can be avoided, ensuring the continuity and stability of fault diagnosis.

[0062] In step S502 of some embodiments, the execution cost and conditional probability of each task in the task set are obtained; based on the current root cause probability distribution, the entropy value H(P) is calculated to measure the uncertainty of the current root cause of the fault; for each candidate test task, the marginal probability, posterior entropy, conditional entropy, and information gain are calculated sequentially, and finally the dynamic task value of each task is calculated using the formula Value(T)=IG(T) / Cost(T). The specific calculation process and related calculation formulas are explained in subsequent embodiments.

[0063] In step S105 of some embodiments, the test task with the highest dynamic task value in the task set is selected and sent to the distributed test executor cluster. Further, the following fault-tolerant processing rules can be set to determine the next operation: If the currently selected test task is successfully executed and a valid business observation result is returned, proceed to step S106; If a task fails to return a valid business observation result (regardless of the underlying reason), the task is marked as unavailable, and no belief update is performed in this round. The task with the second highest current value score is automatically selected for execution. If the second highest value task also fails to return a valid result, this fault tolerance rule is repeated. If all candidate test tasks are marked as unavailable, terminate the diagnostic process directly, record the exception log, and report to the operations and maintenance personnel for manual intervention.

[0064] By adopting a fault-tolerant replacement strategy for testing tasks, the problem of diagnostic process interruption and poor engineering availability caused by abnormal execution of testing tasks in existing technologies is solved, ensuring the continuity and stability of fault diagnosis.

[0065] In step S106 of some embodiments, if the currently selected test task is successfully executed and returns a valid business observation result, the root cause probability distribution is updated according to the current observation result, and iterative execution begins from step S102.

[0066] In some embodiments, please refer to Figure 6 The step S106, updating the root cause probability distribution based on the current observation results, may include, but is not limited to, the following steps: S601, obtain the conditional probability of the current round of test task under different root causes of failure under the current observation results; S602, based on the acquired multiple conditional probabilities, calculate the posterior probability of each candidate fault root cause under the current observation results of the test mission using Bayes' formula; S603, update the root cause probability distribution based on the posterior probability of each candidate root cause of failure.

[0067] In this embodiment, based on the valid observation results returned by the test task (observation results of whether the cause of the fault is located), the posterior probability of each fault hypothesis is updated by Bayes' formula. The updated posterior probability of each fault hypothesis is used as the prior probability of the next iteration, forming a new prior probability distribution (i.e., root cause probability distribution).

[0068] This embodiment is based on the fault hypothesis-testing task conditional probability table pre-stored in the knowledge graph. Using Bayes' theorem, the posterior probability of each fault hypothesis is updated in real time with the valid observation results returned by the testing task. The updated probability distribution is used as the calculation benchmark for the next round of task value assessment. This solves the problems of existing technologies, such as the inability to quantify and converge the root cause of faults, reliance on static rules, and poor diagnostic accuracy. It achieves dynamic focusing on the root cause of faults, and the entire diagnostic process is quantifiable and interpretable.

[0069] In some embodiments, please refer to Figure 7 The alarm-triggered dynamic diagnostic task orchestration method in this application embodiment may also include, but is not limited to, the following steps: S701, Obtain the verification results of the target fault root cause; S702, if the verification result is valid, update the conditional probability of the successful test task executed in this fault event under the target fault root cause based on the forgetting factor.

[0070] In this embodiment, a valid verification result means that the action is only taken when the root cause conclusion is confirmed to be valid. Validity determination rules: 1. Root causes manually reviewed and marked as correct; 2. Root causes with high confidence that are terminated from output, and whose conclusion is not overturned by subsequent fault recovery verification and business recovery results, are considered valid; Root causes that have reached the maximum number of tasks and are used as a fallback output do not automatically trigger knowledge updates and must be manually confirmed as valid before the update can be executed; If the root cause conclusion is subsequently determined to be an incorrect diagnosis, this update will not be executed; If a conditional probability update has been completed, the corresponding probability value must be rolled back to its original value before this update to avoid erroneous data contamination.

[0071] The observation results of all successfully executed testing tasks in this diagnosis are extracted. Based on an update formula with a forgetting factor, the conditional probabilities corresponding to the confirmed root cause hypothesis in the knowledge graph are updated. Simultaneously, the probabilities of complementary results are updated to ensure probability normalization. The update formula can be an exponentially weighted moving average method with a forgetting factor; the specific update formula will be explained in subsequent embodiments.

[0072] The forgetting factor-driven conditional probability table self-optimization mechanism in this embodiment employs an exponentially weighted moving average method with a forgetting factor. Updates are performed based on confirmed root cause diagnostic results, and rollback rules for erroneous diagnoses are set to prevent erroneous data from polluting the knowledge graph. This addresses the problems of existing fault diagnosis models, such as their inability to adaptively iterate, adapt to changes in networks and fault modes, and insufficient long-term diagnostic accuracy. It enables continuous self-optimization of the diagnostic model, making it increasingly accurate with use.

[0073] It is understood that the iteration rule of this application is to execute only one optimal task in each iteration, update the belief, and re-evaluate the value of all remaining tasks, rather than executing them in a fixed sequence. All default thresholds, periods, and parameters in this application can be dynamically adjusted through the management interface, and do not constitute a limitation of this invention.

[0074] In addition, for scenarios with no matching fault assumptions, if there is no matching fault assumption in the knowledge graph, the system records the anomaly, terminates the automatic diagnosis process, and reports to the maintenance personnel for manual intervention.

[0075] The arrangement method in this application is only responsible for the arrangement of diagnostic sequences and task selection. The underlying execution and exception handling of the probing tasks are all handled by the distributed probing execution system. This system executes belief update or task replacement logic based on whether there are valid observation results returned in the end, to ensure that the diagnostic process is not blocked.

[0076] The embodiments of the method of this application will be described in detail below with reference to specific scenarios.

[0077] Example 1: A complete iterative scenario for backbone network link congestion fault diagnosis.

[0078] Scenario Description: In a certain operator's backbone network, the network management system received three alarms in succession within 60 seconds: "CE01 BGP neighbor reset", "PE02 to CE01 link utilization > 90%", and "Multiple video services are stuck". The root cause of the fault needs to be diagnosed using this method.

[0079] The preceding data includes: Historical frequency of knowledge graph failures: 50 times due to link failures, 30 times due to origin server failures, and 20 times due to BGP configuration errors. The preset termination threshold is 0.8, and the maximum number of tasks is 5. The predefined testing tasks, costs, and conditional probabilities are shown in Table 1: Table 1

[0080] Please refer to Figure 11 The flowchart shown below illustrates the dynamic diagnostic sequence orchestration process, and the diagnostic execution flow is as follows: Step 1: Alarm Access and Aggregation The alarm access module receives the above three alarms, completes standardization and deduplication, and merges them through a 60-second time window and device dependency relationship to generate fault event EV001, which is then pushed to the diagnostic decision engine.

[0081] Step 2: Fault Hypothesis Generation and Initial Probability Assignment: The diagnostic decision engine queries the knowledge graph for historical frequencies of similar faults, normalizes the frequencies, and obtains three candidate fault hypotheses (in this embodiment, these refer to candidate fault root causes H). i The initial prior probability of ) H1 (CE01-PE02 link congestion / failure): 50 / (50+30+20)=0.5; H2 (Video source station egress congestion): 30 / (50+30+20)=0.3; H3 (CE01BGP configuration error): 20 / (50+30+20)=0.2; The current fault hypothesis probability distribution is P=[p1,p2,p3]=[0.5,0.3,0.2]. There are no hypotheses that meet the termination condition, so the iterative diagnosis process begins.

[0082] First iteration: Value assessment → Task execution → Belief update (root cause probability distribution update) → Termination judgment.

[0083] 1. Calculate the current entropy H(P). The entropy formula is expressed as follows: ; in, It is the first The initial prior probabilities of each candidate fault hypothesis.

[0084] Substituting the values, we calculate: H(P) = -[0.5 × log₂₀.₅ + 0.3 × log₂₀.₃ + 0.2 × log₂₀.₂] = -[0.5 × (-1) + 0.3 × (-1.737) + 0.2 × (-2.322)] = -[-0.5 - 0.5211 - 0.4644] = 1.4855; 2. Taking the test task T1 as an example, the complete process of its task value scoring is as follows: (1) Calculate the marginal probability of the result T1; The marginal probability formula is expressed as follows: ; in, It is the first The initial prior probabilities of the candidate fault hypotheses Based on candidate failure assumptions Under the given conditions, the execution result of the test task T1 is: The conditional probability can be obtained by looking up Table 1.

[0085] Marginal probability of success: P(success) = p1 P(success|H1)+p2 P(success|H2)+p3 P(success|H3) = 0.5 × 0.7 + 0.3 × 0.9 + 0.2 × 0.9 = 0.35 + 0.27 + 0.18 = 0.80; The marginal probability of failure is: P(failure) = 1 - P(success) = 0.20.

[0086] (2) Calculate the posterior probability and posterior entropy for different outcomes (success and failure): The posterior probabilities (Bayes' theorem) for a successful outcome (under different candidate failure hypotheses) are as follows: ; in, Candidate fault hypothesis under successful observation results The posterior entropy, This represents the marginal probability of a successful observation.

[0087] P(H1|Success) = [P(Success|H1)] p1] / P(success) = (0.7 × 0.5) / 0.80 = 0.4375; P(H2|Success) = [P(Success|H2)] p2] / P(success) = (0.9 × 0.3) / 0.80 = 0.3375; P(H3|Success) = [P(Success|H3)] p3] / P(success) = (0.9 × 0.2) / 0.80 = 0.2250; Among them, the posterior entropy under successful observation results: H(P|success) = -[0.4375×log20.4375+0.3375×log20.3375+0.2250×log20.2250]≈1.543; Posterior probability of a failed observation: P(H1|failure) = (0.3 × 0.5) / 0.20 = 0.75; P(H2|failure) = (0.1 × 0.3) / 0.20 = 0.15; P(H3|failure) = (0.1 × 0.2) / 0.20 = 0.10; Posterior entropy under failed observations: H(P|failure) = -[0.75×log20.75 + 0.15×log20.15 + 0.10×log20.10] ≈ 1.014.

[0088] (3) Calculate the conditional entropy of the test task T1: According to the conditional entropy formula: H(P|T1) = P(success) H(P|Success) + P(Failure) H(P|failure); Substituting the values: H(P|T1)=0.80×1.543+0.20×1.014=1.2344+0.2028=1.4372.

[0089] (4) Calculate the information gain of the test task T1: According to the information gain formula: IG(T1) = H(P) - H(P|T1); Substituting the values: IG(T1) = 1.4855 - 1.4372 = 0.0483.

[0090] (5) Calculate the task value score of the test task T1: According to the task value scoring formula: Value(T1)=IG(T1) / Cost(T1), where Cost(T1) is the task cost and T1 cost is 1, therefore Value(T1)=0.0483 / 1=0.0483.

[0091] 3. Value score calculation for other tasks (same as T1 calculation logic). The calculation results for different testing tasks are shown in Table 2.

[0092] Table 2

[0093] 4. Optimal task execution and fault tolerance.

[0094] Comparing the value scores of each task, T1 has the highest score of 0.0483, so T1 is executed in the first round. In this example, T1 executes normally and returns a valid result of "success".

[0095] 5. Bayesian belief update (i.e., root cause distribution probability update).

[0096] Based on the "success" result of T1, the calculation has been completed using the Bayesian formula mentioned above. The updated probability distribution of the failure hypothesis is: P=[0.4375,0.3375,0.2250] 6. Termination Condition Judgment The current maximum probability is 0.4375, which is less than the preset termination threshold of 0.8; the number of tasks executed is 1, which is less than the maximum number of tasks of 5. The termination conditions are not met, and the second round of iteration will begin.

[0097] Second iteration: Re-evaluate based on new probabilities → Task execution → Belief update → Termination judgment.

[0098] 1. Recalculate the value score of the remaining tasks.

[0099] Based on the updated probability distribution [0.4375, 0.3375, 0.2250], and following the complete calculation logic of the first round, the value scores for T2, T3, T4, and T5 were recalculated, and the results are shown in Table 3. Table 3

[0100] 2. Tasks will be selected based on their merit.

[0101] T2 has the highest value score of 0.042 among the remaining tasks, so it is executed in the second round. In this example, T2 executes normally and returns a valid result "failure".

[0102] 3. Bayesian belief renewal.

[0103] The current prior probability P = [0.4375, 0.3375, 0.2250].

[0104] The conditional probabilities of T2 (failure scenario): P(failure|H1)=0.7, P(failure|H2)=0.1, P(failure|H3)=0.2; Step 1: Calculate the marginal probability of failure.

[0105] P(failure) = 0.4375 × 0.7 + 0.3375 × 0.1 + 0.2250 × 0.2 = 0.30625 + 0.03375 + 0.045 = 0.385; Step 2: Calculate the posterior probability of each hypothesis (Bayes' theorem).

[0106] P(H1|failure) = (0.4375 × 0.7) / 0.385 = 0.7955; P(H2|failure) = (0.3375 × 0.1) / 0.385 = 0.0877; P(H3|failure) = (0.2250 × 0.2) / 0.385 = 0.1169; The updated probability distribution is: P = [0.7955, 0.0877, 0.1169].

[0107] 4. Termination condition determination.

[0108] The current maximum probability is 0.7955, which is still less than the termination threshold of 0.8; the number of tasks executed is 2, which is less than 5. The termination condition is not met, so proceed to the third iteration.

[0109] Third iteration: Reassessment → Task execution → Belief update → Termination of judgment.

[0110] 1. Recalculate the value score of the remaining tasks.

[0111] Based on the current probability distribution [0.7955, 0.0877, 0.1169], the value scores for T3, T4, and T5 were recalculated, and the results are shown in Table 4. Table 4

[0112] 2. Tasks will be selected based on their merit.

[0113] T4 has the highest value score of 0.025 among the remaining tasks, so it is executed in the third round. In this example, T4 executes normally and returns the valid result "Path interrupted".

[0114] 3. Bayesian belief renewal.

[0115] The current prior probability P = [0.7955, 0.0877, 0.1169]; The conditional probabilities of T4 (interruption scenario): P(interruption|H1)=0.8, P(interruption|H2)=0.2, P(interruption|H3)=0.2.

[0116] Step 1: Calculate the marginal probability of the interruption result.

[0117] P(interruption) = 0.7955 × 0.8 + 0.0877 × 0.2 + 0.1169 × 0.2 = 0.6364 + 0.01754 + 0.02338 = 0.67732.

[0118] Step 2: Calculate the posterior probability of each hypothesis.

[0119] P(H1|Interruption) = (0.7955 × 0.8) / 0.67732 = 0.9396; P(H2|Interruption) = (0.0877 × 0.2) / 0.67732 = 0.0259; P(H3|Interrupt) = (0.1169 × 0.2) / 0.67732 = 0.0345; The updated probability distribution is: P = [0.9396, 0.0259, 0.0345].

[0120] 4. Termination condition determination The current maximum probability = 0.9396 ≥ the termination threshold of 0.8, which satisfies the termination condition, and the iteration loop ends.

[0121] Step 7: Root cause output.

[0122] Root cause: H1 (CE01-PE02 link congestion / failure), posterior probability 0.9396.

[0123] Step 8: Knowledge Update.

[0124] The diagnosis ultimately confirmed that the true root cause was H1 (CE01-PE02 link congestion). The T4 task observed an "interruption" result, so an update was performed on P(interruption|H1) under the H1 assumption.

[0125] Updated formula: ; in, Forgetting factor, This represents the number of root cause observations that match the target fault in this process. =0.95, =0.8, n=1 (1 interruption was observed this time), substitute into the numerical calculation: P(interruption|H1)_new=(0.95×0.8+1) / (0.95+1)=(0.76+1) / 1.95=1.76 / 1.95≈0.903.

[0126] The system replaces the old value in the knowledge graph with this new value, and at the same time updates the probability of the complementary result P(complete|H1)=1-0.903=0.097 to ensure probability normalization.

[0127] Example 2: Enterprise Network BGP Configuration Error Diagnosis Scenario.

[0128] Scene Description If only a single alarm, "CE02BGP Neighbor Status Idle," is received, with no performance alarms, this method is required to complete the fault diagnosis.

[0129] The prerequisite data includes: Preset rules: Termination threshold 0.8, maximum number of tasks executed 5; Knowledge graph historical data: The historical frequency of similar faults is 15 times for BGP configuration errors, 5 times for PE03 side configuration errors, and 30 times for link failures.

[0130] The core diagnostic process and key calculations are as follows: 1. Alarm access and aggregation.

[0131] The alarm access module receives alarms, completes standardized processing, generates fault event EV002, and pushes it to the diagnostic decision engine.

[0132] 2. Fault hypothesis generation and initial probability assignment.

[0133] Normalizing the historical frequency yields the initial prior probability: H1 (CE02BGP configuration error): 15 / (15+5+30)=0.3; H2 (PE03 side configuration error): 5 / (15+5+30)=0.1; H3 (CE02-PE03 link failure): 30 / (15+5+30)=0.6; The initial probability distribution is P=[0.3,0.1,0.6]. There are no assumptions that satisfy the termination condition, so the iteration process begins.

[0134] 3. First iteration: Based on the initial probability distribution, the value score of each candidate testing task is calculated. T2 (PingPE03Loopback) has the highest value score. T2 is executed, and a valid result "success" is returned. The posterior probability is updated based on Bayes' theorem, and the updated probability distribution becomes [0.45, 0.15, 0.40]. Termination decision: Maximum probability 0.45 < 0.8, number of tasks executed 1 < 5, continue iteration.

[0135] 4. Second iteration: Based on the updated probability distribution, the value scores of the remaining tasks are recalculated. T4 (NetConf query CE02BGP configuration) has the highest value score. Executing T4 returns a valid result "Configuration error detected". The posterior probability is updated based on Bayes' theorem. After the update, the posterior probability of H1 increases to 0.85 ≥ 0.8, which satisfies the termination condition.

[0136] 5. Root cause output and knowledge update.

[0137] Output root cause: H1 (CE02BGP configuration error), posterior probability 0.85; After diagnosis, update the corresponding conditional probability table in the knowledge graph based on the observation results.

[0138] Please refer to Figure 8 This application also provides a dynamic diagnostic task orchestration system based on alarm triggering, including: An initialization module is used to determine multiple candidate root causes of failure based on the failure event and initialize the root cause probability distribution of the multiple candidate root causes. The convergence judgment module is used to determine whether the root cause detection convergence condition has been met. The root cause localization module is used to select the candidate fault root cause with the highest root cause probability value as the target fault root cause when the current root cause detection convergence condition is met. The task value calculation module is used to calculate the dynamic task value of each probe task in the task set when the root cause detection convergence condition cannot be met at present. This is based on the root cause probability distribution and the conditional probability of each probe task in the task set under the observation results of different root causes of failure. The task observation module is used to select the highest dynamic task value from the task set for execution in order to obtain the current observation results of the task. The update module is used to update the root cause probability distribution based on the current observation results and return to the convergence judgment module.

[0139] It is understood that the methods described in the above method embodiments are applicable to this system embodiment. The specific functions implemented in this system embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0140] This application also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above-described method. This electronic device can be any smart terminal, including tablet computers, in-vehicle computers, etc.

[0141] It is understood that the content of the above method embodiments is applicable to this device embodiment. The specific functions implemented by this device embodiment are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0142] Please seeFigure 9 , Figure 9 The hardware structure of an electronic device according to another embodiment is illustrated. The electronic device includes: The processor 901 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application. The memory 902 can be implemented as a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 902 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 902 and is called and executed by the processor 901. The 903 input / output interface is used to implement information input and output. The communication interface 904 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.). Bus 905 transmits information between various components of the device (e.g., processor 901, memory 902, input / output interface 903, and communication interface 904); The processor 901, memory 902, input / output interface 903, and communication interface 904 are connected to each other within the device via bus 905.

[0143] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0144] It is understood that the content of the above method embodiments is applicable to this storage medium embodiment. The specific functions implemented in this storage medium embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0145] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0146] It is understood that the content of the above method embodiments is applicable to the embodiments of this program product. The specific functions implemented by the embodiments of this program product are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0147] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0148] The alarm-triggered dynamic diagnostic task orchestration method and related equipment provided in this application have at least one of the following beneficial effects: (1) A dynamic task value scoring mechanism based on the combination of information gain and cost ratio: The core formula is Value(T)=IG(T) / Cost(T), where IG(T) is the information gain of the task and Cost(T) is the execution cost of the task, quantified into three cost levels of 1 / 2 / 3 according to execution time and bandwidth consumption; each iteration recalculates the value score of all remaining candidate tasks based on the probability distribution of the current fault hypothesis. This solves the core problems of existing technologies such as decoupling of fixed probing and fault scenarios, many invalid probes, and low diagnostic efficiency, and achieves accurate matching between probing tasks and real-time fault hypotheses, balancing diagnostic efficiency and resource consumption.

[0149] (2) Real-time update mechanism of Bayesian belief: Based on the fault hypothesis-testing task conditional probability table pre-stored in the knowledge graph, the posterior probability of each fault hypothesis is updated in real time using the valid observation results returned by the testing task through Bayes' formula. The updated probability distribution is used as the calculation benchmark for the next round of task value assessment. This solves the problems of existing technologies such as the inability to quantify and converge the root cause of faults, reliance on static rules, and poor diagnostic accuracy. It realizes dynamic focusing of the root cause of faults, and the entire diagnostic process is quantifiable and interpretable.

[0150] (3) Fault-tolerant replacement strategy for probe testing tasks: Clearly define the judgment rules for system-level anomalies. When a task cannot return valid results due to probe failure, timeout, or other anomalies, mark the task as unavailable and automatically select the task with the second highest current value score for execution. Abnormal tasks do not participate in belief updates and are not included in the maximum number of tasks. This solves the problem of diagnostic process interruption and poor engineering availability caused by abnormal execution of probe testing tasks in existing technologies, and ensures the continuity and stability of fault diagnosis.

[0151] (4) Alarm-triggered time window aggregation mechanism linked to fault hypothesis generation: An aggregation rule based on a 60-second default time window and device dependencies is used to merge similar alarms from the same device and devices with direct dependencies, generating a single fault event. The aggregation result is directly linked to the initial prior probability assignment of the fault hypothesis. This solves the problems of alarm redundancy, disconnect between diagnostic input and subsequent processes, and numerous interference items, providing accurate input for subsequent diagnostic processes and reducing invalid calculations.

[0152] (5) Forgetting factor-driven conditional probability table self-optimization mechanism: An exponentially weighted moving average method with a forgetting factor is adopted, and updates are performed only based on confirmed and valid root cause diagnosis results. Rollback rules for erroneous diagnoses are set to avoid erroneous data polluting the knowledge graph. This solves the problems of existing fault diagnosis models being unable to adaptively iterate, unable to adapt to changes in networks and fault modes, and having insufficient long-term diagnostic accuracy, and achieves continuous self-optimization of the diagnostic model, becoming more accurate with use.

[0153] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0154] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0155] The system embodiments described above are merely illustrative. The modules described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0156] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0157] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or modules is not necessarily limited to those steps or modules explicitly listed, but may include other steps or modules not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0158] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0159] In the embodiments provided in this application, it should be understood that the disclosed systems and methods can be implemented in other ways. For example, the system embodiments described above are merely illustrative; for instance, the division of modules described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules 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.

[0160] The modules described above as separate components may or may not be physically separate. Similarly, the components shown as modules may or may not be physical modules; 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, depending on actual needs.

[0161] Furthermore, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module. The integrated modules described above can be implemented in hardware or as software functional modules.

[0162] If the integrated module is implemented as a software functional module 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 application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes multiple 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 application. The aforementioned storage medium includes various media capable of storing programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0163] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.

Claims

1. A method for orchestrating dynamic diagnostic tasks based on alarm triggering, characterized in that, Includes the following steps: Based on the failure event, multiple candidate root causes of failure are identified, and the root cause probability distribution of the multiple candidate root causes of failure is initialized. Determine whether the root cause detection convergence condition has been met. If the root cause detection convergence condition is met, the candidate fault root cause with the highest root cause probability value is selected as the target fault root cause according to the current root cause probability distribution. If the root cause detection convergence condition cannot be met at present, the dynamic task value of each detection task in the task set is calculated based on the root cause probability distribution and the conditional probability of each detection task in the task set under the observation results of different root causes of the fault. Select the highest dynamic task value from the task set for execution to obtain the current observation results of the task. The root cause probability distribution is updated based on the current observation results, and the step of determining whether the root cause detection convergence condition has been met is repeated.

2. The method for orchestrating dynamic diagnostic tasks based on alarm triggering according to claim 1, characterized in that, The alarm-triggered dynamic diagnostic task orchestration method further includes the following steps: Collect fault alarm data and then preprocess the fault alarm data; The preprocessed fault alarm data is aggregated according to a preset time window to obtain a single fault event.

3. The method for orchestrating dynamic diagnostic tasks based on alarm triggering according to claim 1, characterized in that, The initialization of the root cause probability distribution of the multiple candidate root causes of failure includes the following steps: Obtain the historical occurrence frequency of each candidate root cause of the fault; The root cause probability value of each candidate fault root cause is determined by normalizing the historical occurrence frequency of each candidate fault root cause based on multiple historical occurrence frequencies. A root cause probability distribution is formed based on the root cause probability value of each candidate root cause of the fault.

4. The method for dynamic diagnostic task orchestration based on alarm triggering according to claim 1, characterized in that, The determination of whether the root cause detection convergence condition has been met includes the following steps: Determine whether there is a root cause probability value in the root cause probability distribution that is greater than or equal to the termination threshold; If there is a root cause probability value that is greater than or equal to the termination threshold, then it is determined that the root cause detection convergence condition has been met. If there is no root cause probability value greater than or equal to the termination threshold, the convergence condition for root cause detection is determined based on the number of successfully executed test tasks reaching the preset maximum number of tasks.

5. The method for orchestrating dynamic diagnostic tasks based on alarm triggering according to claim 1, characterized in that, The step of calculating the dynamic task value of each testing task in the task set based on the root cause probability distribution and the conditional probability of each testing task in the task set under different root causes of failure includes the following steps: Select multiple corresponding test tasks based on the fault event, and remove test tasks that have been successfully executed or are unusable from the multiple test tasks to form a task set; For each test task in the task set, the posterior probability of the test task under different observation results is calculated based on the conditional probability of the test task under different root causes of failure and the root cause probability distribution. The dynamic task value of the test task is calculated based on the posterior probability under different observation results and the execution cost of the test task.

6. The method for orchestrating dynamic diagnostic tasks based on alarm triggering according to claim 5, characterized in that, Updating the root cause probability distribution based on the current observation results includes the following steps: Obtain the conditional probability of the current test task executed in the current round under the current observation results for different root causes of failure; Based on the acquired multiple conditional probabilities, the posterior probability of each candidate fault root cause under the current observation results of the probe task is calculated using Bayes' theorem. The root cause probability distribution is updated based on the posterior probability of each candidate root cause of failure.

7. The method for dynamic diagnostic task orchestration based on alarm triggering according to claim 1, characterized in that, The alarm-triggered dynamic diagnostic task orchestration method further includes the following steps: Obtain the verification results of the target fault root cause; If the verification result is valid, the conditional probability of the successful test task performed in this fault event under the target fault root cause is updated based on the forgetting factor.

8. A dynamic diagnostic task orchestration system based on alarm triggering, characterized in that, include: An initialization module is used to determine multiple candidate root causes of failure based on a failure event, and to initialize the root cause probability distribution of the multiple candidate root causes of failure. The convergence judgment module is used to determine whether the root cause detection convergence condition has been met. The root cause localization module is used to select the candidate fault root cause with the highest root cause probability value as the target fault root cause when the current root cause detection convergence condition is met. The task value calculation module is used to calculate the dynamic task value of each probe task in the task set based on the root cause probability distribution and the conditional probability of each probe task in the task set under the observation results of different root causes of failure when the root cause detection convergence condition cannot be met at present. The task observation module is used to select the highest dynamic task value from the task set for execution in order to obtain the current observation results of the task. The update module is used to update the root cause probability distribution based on the current observation results and return it to the convergence judgment module.

9. An electronic device, characterized in that, The electronic device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the method according to any one of claims 1 to 7.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 7.

Images