A fault knowledge base construction and intelligent auxiliary diagnosis method based on an Internet of Things platform alarm log

Abstract

The application discloses a kind of based on fault knowledge base construction and intelligent auxiliary diagnosis method of alarm log of Internet of Things platform, belong to Internet of Things intelligent operation and maintenance technical field.Historical alarm log and real-time alarm log are acquired, equipment physical topology and business call chain topology are collected, hard constraint skeleton is constructed to limit the generation range of causal edge, the co-occurrence frequency is counted along the skeleton and the time sequence condition transition probability is calculated, and the causal time sequence graph is constructed as a four-tuple fault knowledge base;When real-time alarm triggers, generate propagation path along the probability reverse direction in the fault knowledge base Reverse traceback, sort output root cause positioning result according to path confidence degree;Receive engineer confirmation feedback, when cumulative reach preset threshold, update time sequence condition transition probability by Bayes smoothing weighted fusion;Listen to topological change, reconstruct hard constraint skeleton and update fault knowledge base when it occurs;Accurate positioning and adaptive updating are realized.

Description

Technical Field

[0001] This invention relates to the field of IoT intelligent operation and maintenance technology, specifically to a method for constructing a fault knowledge base and intelligent auxiliary diagnosis based on IoT platform alarm logs. Background Technology

[0002] Existing methods for root cause analysis of IoT platform alarms mainly fall into three categories: one is based on alarm clustering convergence, which reduces the number of alarms by aggregating alarm similarity; another is based on data-driven causal discovery, which mines causal relationships from historical alarms; and the third is based on rule matching using static knowledge graphs. While these methods can assist in troubleshooting to some extent in routine operation and maintenance scenarios, they still have the following shortcomings: First, alarm clustering only reduces the number of alarms and lacks the interpretability of root cause propagation. Existing clustering methods cannot explain the causal propagation relationship between alarms and do not provide a complete fault propagation chain. Operation and maintenance personnel still need to check one by one among a large number of alarms, and the problem of root causes being overwhelmed by a large number of redundant alarms has not been solved. Secondly, statistical co-occurrence causal mining lacks topological constraints, which can easily lead to false causal relationships. Existing methods only determine causal relationships based on the statistical co-occurrence of alarm time series data, which lacks constraints on the physical connection of the system and the business call relationship. It is easy to misjudge indirect associations as direct causation. At the same time, it is difficult to explicitly incorporate the time series delay dimension into the model, which is insufficient for the dynamic characterization of fault propagation. Furthermore, the knowledge base is static and fixed, lacking feedback loop and topology adaptation capabilities; existing causal graphs are mostly static models, which on the one hand cannot incorporate the feedback knowledge of operation and maintenance personnel into the graph for continuous optimization, and on the other hand, when the system equipment topology changes, the static graph cannot automatically detect and update, and the inference accuracy continues to decline as the system evolves. Summary of the Invention

[0003] The purpose of this invention is to provide a fault knowledge base construction and intelligent auxiliary diagnosis method based on alarm logs of an IoT platform. It constructs a hard-constraint skeleton by using the device physical connection topology and business call chain topology to limit the range of causal edge generation. It calculates the temporal condition transition probability based on the co-occurrence frequency of historical alarm logs, constructing a causal temporal graph in the form of quadruples as the fault knowledge base. This solves the problems of existing methods, which are prone to generating false causal relationships due to a lack of topological constraints and cannot provide complete root cause propagation links. By introducing a Bayesian smooth update mechanism with engineer confirmation feedback and a topology change adaptive reconstruction mechanism, the fault knowledge base has continuous optimization and dynamic evolution capabilities, solving the problems of existing knowledge bases being static and unable to adapt to system topology changes.

[0004] The objective of this invention can be achieved through the following technical solution: This application provides a method for constructing a fault knowledge base and providing intelligent auxiliary diagnosis based on alarm logs from an IoT platform, comprising: S1. Obtain historical alarm logs from the IoT platform, receive real-time alarm logs from the IoT platform, and collect the device physical connection topology and business call chain topology of the IoT platform. S2. Based on the device physical connection topology and service call chain topology, construct a hard constraint skeleton for causal propagation. Use the hard constraint skeleton to limit the generation range of causal edges between alarm events, and only allow causal edges to be established between node pairs with connections in the hard constraint skeleton. Based on the historical alarm log, along the node pairs with connections in the hard constraint skeleton, count the co-occurrence frequency of alarm events between adjacent nodes within a preset time window, calculate the temporal condition transition probability, and construct a causal temporal graph in the form of a quadruple as a fault knowledge base. S3. When a new alarm event is received from the real-time alarm log, starting from the target node where the new alarm event is located, backtrack in the opposite direction of the temporal conditional transition probability in the fault knowledge base, and output the root cause location result. S4. Receive confirmation feedback from engineers regarding the root cause localization results. When the cumulative confirmation feedback for the same causal edge reaches a preset threshold, update the temporal conditional transition probability of the causal edge. S5. Continuously monitor the change events of the device physical connection topology and service call chain topology. When the topology changes, reconstruct the hard constraint skeleton and update the fault knowledge base.

[0005] The beneficial effects of this invention are as follows: This invention constructs a hard-constraint skeleton by combining the physical connection topology of the device and the business call chain topology to limit the range of causal edge generation. This solves the problem that existing statistical co-occurrence causal mining is prone to generating false causal relationships due to the lack of topological constraints, and achieves accurate causal relationship mining based on dual constraints of physical connection and business call. A fault knowledge base is constructed by using a four-tuple causal time sequence graph, and a complete propagation path is generated by reverse tracing when a real-time alarm is triggered. The root cause localization results are output in order of path confidence. This solves the problem that existing alarm clustering only achieves quantity compression but lacks the interpretability of root cause propagation. It realizes the full-link reverse inference from the target alarm to the root cause source and quantifiable confidence assessment. By introducing a Bayesian smooth update mechanism based on engineer confirmation feedback, and automatically reconstructing the hard constraint skeleton and updating the knowledge base when the topology changes, the problems of static solidification, inability to continuously optimize and adapt to topology changes in the existing knowledge base are solved. This enables the continuous iterative evolution of the fault knowledge base based on human-machine collaborative feedback and adaptive updates to topology dynamic changes. Attached Figure Description

[0006] To better understand and implement this application, the technical solution is described in detail below with reference to the accompanying drawings.

[0007] Figure 1 A flowchart illustrating a method for constructing a fault knowledge base and providing intelligent auxiliary diagnosis based on alarm logs from an IoT platform, as provided in this application; Figure 2 This is a flowchart illustrating the dynamic updating of a fault knowledge base based on alarm logs from an IoT platform, as provided in this application. Detailed Implementation

[0008] To further illustrate the technical means and effects adopted by the present invention to achieve its intended purpose, exemplary embodiments will be described in detail below, examples of which are illustrated in the accompanying drawings. In the following description, when referring to the 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 this application.

[0009] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used in this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more of the associated listed items.

[0010] The following detailed description of the specific implementation methods, features, and effects of the present invention, in conjunction with the accompanying drawings and preferred embodiments, is provided in detail.

[0011] Example 1, please refer to Figures 1 to 2 This embodiment provides a method for constructing a fault knowledge base and intelligent auxiliary diagnosis based on alarm logs from an IoT platform. The method acquires historical alarm logs, real-time alarm logs, device physical connection topology, and business call chain topology from the IoT platform. It performs structured event extraction and verification on the alarm logs, constructs a hard-constraint skeleton based on the two types of topologies to limit the range of causal edge generation, calculates the temporal condition transition probability based on the co-occurrence frequency along the skeleton from historical alarm logs, and constructs a causal temporal graph in the form of four-tuples as the fault knowledge base. When a real-time alarm is triggered, it backtracks along the probability in the opposite direction to generate a complete propagation path and outputs the root cause localization results sorted by path confidence. The knowledge base is continuously optimized through a Bayesian smooth update mechanism with engineer confirmation feedback, and dynamically updated with system evolution through a topology change adaptive reconstruction mechanism. The specific steps of the fault knowledge base construction and intelligent auxiliary diagnosis method based on alarm logs of an IoT platform described in this embodiment are as follows: S1. Obtain historical alarm logs from the IoT platform, receive real-time alarm logs from the IoT platform, and collect the device physical connection topology and business call chain topology of the IoT platform. Specifically, the historical alarm logs are obtained through the data export interface of the platform log system. In this embodiment, historical alarm logs from the past 90 days are obtained and stored as CSV log files. Each historical alarm log record contains the following fields: a unique event identifier, which is a UUID automatically generated by the platform log system; a timestamp, accurate to milliseconds; a device identifier, which is the device MAC address or service name; an alarm type, including connection timeout, response anomaly, data loss, etc.; and an alarm level, ranging from level one to level four. The amount of historical alarm logs is approximately 150,000 records per day, covering alarm types such as device offline, network timeout, service call anomaly, and data reporting interruption. For example, the event unique identifier is evt-20260701-080312-a3b4, the timestamp is 2026-07-01 08:03:12.345, the device identifier is GW-07-12, the alarm type is connection timeout, and the alarm level is level 2; Furthermore, the real-time alarm logs are continuously subscribed to and received in a streaming manner through the platform's message queue component. The data structure of each real-time alarm log is consistent with that of the historical alarm logs, including five fields: unique event identifier, timestamp, device identifier, alarm type, and alarm level. The receiving delay does not exceed 100 milliseconds. Specifically, structured event extraction and validation are performed on the collected alarm logs: After segmenting the original alarm log text by spaces and punctuation, it is input into a pre-trained language model for sequence labeling. The labeling tags include four categories: device name, time, alarm type, and alarm level. The model output is the text fragment corresponding to each tag. The system maps the tag type to structured fields, where the device name is mapped to the device identifier, the time is mapped to the timestamp, the alarm type tag is mapped to the alarm type, and the level tag is mapped to the alarm level. The pre-trained language model is a sequence labeling model based on the Transformers architecture. It takes the original alarm log text as input and outputs text segments corresponding to four tags: device name, time, alarm type, and alarm level. In this embodiment, the model uses a Chinese pre-trained language model based on the Transformers architecture as the base model. Based on pre-training with general Chinese corpus, it is fine-tuned using alarm log samples already labeled on the platform. The labeling rules for the labeled samples are as follows: device name indicates the name or number of the device from which the alarm originates; time indicates the specific time the alarm occurred; alarm type indicates the category to which the alarm belongs (including connection timeout, abnormal response, missing data, etc.); and alarm level indicates the severity level of the alarm. Labeling consistency is ensured by comparing differences after multiple people label back-to-back, and inconsistencies are resolved through third-party arbitration. The word segmentation of the original alarm log text uses a maximum matching word segmentation method based on a vocabulary, with the vocabulary derived from statistical results of high-frequency words in the platform's historical alarm logs. If any required field is missing in the model output, the extraction is deemed a failure. The original alarm text is retained, and a manual review task is generated. The structured event data is compared and verified with a preset device management information database, which is derived from the list of all currently registered device identifiers in the configuration management database. When the extracted device identifier is not within the range of the device management information database, the event data cannot be associated with a valid device node. The event data is discarded, and a manual review task is generated. When the extracted alarm type or alarm level is not within the range of preset standard enumeration values, the field is marked as an unknown type. The structured event data is retained, and a prompt message is generated. After confirmation or correction by the maintenance personnel in the manual review task, the information is stored in the database. Furthermore, the physical connection topology of the devices is collected through the configuration management database interface of the platform operation and maintenance management system. It includes all physical device nodes and the network cable connections, fiber optic connections, and wireless link connections between devices, and is exported in the form of a graph structure. The node file records the device identifier and device type, and the edge file records the start point, end point, and connection type of the physical link. The connection type includes network cable, fiber optic, and wireless. In this embodiment, the physical connection topology of the devices includes 876 physical device nodes, and the edge file contains 2847 physical connection links. The business call chain topology is collected through the configuration management database interface of the platform operation and maintenance management system. It includes all business service nodes and RESTful API calls, message queue subscriptions, and data flow dependencies between services. It is also exported in the form of a graph structure. The edge file records the start point, end point, and call type of the call relationship. The call types include HTTP, message queue, and data flow. In this embodiment, the business call chain topology includes 214 business service nodes. Both topology node and edge files are stored in JSON format. The topology version identifier is recorded in the version management module of the configuration management database, and the version identifier is automatically incremented each time the topology changes. In this embodiment, the topology version identifier format is V major version number.minor version number.patch number. Furthermore, S1 achieves standardized representation of heterogeneous alarm data by unifying the field structure of historical and real-time alarm logs. This structure includes a unique event identifier, timestamp, device identifier, alarm type, and alarm level, resolving the issue of incompatibility caused by inconsistent fields in subsequent co-occurrence frequency statistics. It also extracts semantic events using a pre-trained language model and verifies them using a device management information database, automatically converting the original unstructured alarm text into structured event data. Simultaneously, device identifiers that fail verification are discarded, and manual review tasks are generated, resolving the issue of missing or incorrect device identifiers in alarm logs. This addresses the issue of inaccurate device node location for causal edges, ensuring accurate mapping between alarm events and device nodes in S2. By collecting device physical connection topology and business call chain topology, the physical connection relationships between devices and the call relationships between services are obtained, providing a topological data foundation for the construction of the hard constraint skeleton in S2. This ensures from the source that causal edges are only established between node pairs with physical or logical connection relationships, solving the problem of false causal edges easily generated due to lack of topological constraints in subsequent causal mining. At the same time, the topology version identifier is obtained for the determination of topology changes in S5, providing a trigger basis for the dynamic reconstruction of the subsequent hard constraint skeleton. S2. Based on the device physical connection topology and service call chain topology, construct a hard constraint skeleton for causal propagation. Use the hard constraint skeleton to limit the generation range of causal edges between alarm events, and only allow causal edges to be established between node pairs with connections in the hard constraint skeleton. Based on the historical alarm log, along the node pairs with connections in the hard constraint skeleton, count the co-occurrence frequency of alarm events between adjacent nodes within a preset time window, calculate the temporal condition transition probability, and construct a causal temporal graph in the form of a quadruple as a fault knowledge base. Specifically, the construction process of the hard constraint skeleton is as follows: extract all physical device nodes and physical connection links between devices from the device physical connection topology; extract all service nodes and service call relationships between services from the service call chain topology; use all physical device nodes and service nodes together as graph nodes of the hard constraint skeleton, totaling 1090 nodes; use all physical connection links and service call relationships together as skeleton edges of the hard constraint skeleton, totaling 2847 skeleton edges. The edges of the hard constraint skeleton are only used to limit the candidate generation range of causal edges between alarm events. That is, causal edges are only allowed to be established between node pairs that are connected by an edge. The hard constraint skeleton itself does not limit the direction of alarm propagation. The direction of the causal edge between node pairs is determined by the time-series conditional transition probability based on the statistics of historical alarm logs. For any node pair, if there is at least one connection relationship between physical connection links or service call relationships, a skeleton edge is established between the node pairs to generate a hard constraint skeleton of the graph structure. The mapping of physical connection links to skeleton edges follows these rules: For wired and fiber optic connections, since the physical link itself does not limit the data flow direction, undirected edges are directly established in the hard-constrained skeleton, indicating that there is a physical connection between the node pairs, allowing the establishment of causal edges; subsequently, when calculating the transition probability based on the time-series condition, the transition probabilities in the two directions are calculated separately to determine the actual direction of the causal edge; the service call relationship is inherently directional, and is directly mapped to directed skeleton edges according to the call direction. Taking this embodiment as an example, when a service call relationship gateway device calls the authentication service, a path to the authentication service is established in the hard constraint skeleton for the gateway device on the skeleton edge. Furthermore, after the hard constraint skeleton is constructed, it is used to limit the generation range of causal edges between alarm events. Causal edges are only allowed between node pairs that have a connection relationship in the hard constraint skeleton, and causal edges are prohibited between node pairs that do not have a connection relationship in the hard constraint skeleton. The specific process of statistically analyzing the co-occurrence frequency along the hard constraint skeleton based on historical alarm logs is as follows: Taking a directed skeleton edge in the hard constraint skeleton as an example, the node at the starting point of the directed skeleton edge is recorded as the first node, and the node at the ending point of the directed skeleton edge is recorded as the second node; for undirected skeleton edges, the statistical process described in this step is performed with the two endpoints as the first node and the second node respectively; read the alarm event sequence of all nodes from the historical alarm log, each alarm event sequence includes all alarm events that occurred in the node during the historical period and the occurrence time of each alarm event; the preset time window is determined based on the statistical analysis of the historical alarm interval time of the platform. In this embodiment, the alarm event interval time between each node pair of the platform in the past 90 days is statistically analyzed, and the 95th percentile of the alarm event interval time is calculated to be 58 seconds. After rounding, the preset time window is set to 60 seconds; Extract the first alarm event sequence corresponding to the first node and the second alarm event sequence corresponding to the second node from the alarm event sequence; traverse each alarm event in the first alarm event sequence, taking the occurrence time of the current alarm event as the start time, and offsetting it backward by a preset time window length of 60 seconds to obtain the end time; retrieve alarm events in the second alarm event sequence whose occurrence time is between the start time and the end time; accumulate the retrieved alarm events after deduplication according to the unique event identifier, with the unique event identifier as the key. The same unique event identifier is counted only once in the statistical period of the same skeleton edge. If the same alarm event is retrieved by multiple upstream alarm windows, only the window corresponding to its first occurrence is counted. The accumulated result is used as the co-occurrence frequency of the second node alarming within 60 seconds after the first node alarms; repeat the above statistical process by swapping the order of the first node and the second node to obtain the co-occurrence frequency of the first node alarming within 60 seconds after the second node alarms; Specifically, the calculation method of the time-series conditional transition probability is as follows: obtain the total frequency of alarm events occurring in the historical alarm log of the first node, divide the co-occurrence frequency by the total frequency, and obtain the time-series conditional transition probability of the second node occurring an alarm event within a preset time window after the first node alarm event occurs. Furthermore, the construction method of the quadruple is as follows: taking the first node as the source node and the second node as the target node, and combining the temporal conditional transition probability and the preset time window, a quadruple is constructed. Its structure consists of four elements: source node, target node, temporal conditional transition probability value, and effective time window. The effective time window is the same parameter as the preset time window used when calculating the co-occurrence frequency. For undirected skeleton edges in the hard-constrained skeleton, the temporal conditional transition probabilities in both directions are calculated and quadruples are constructed for each. For directed skeleton edges, only the temporal conditional transition probability in the calling direction is calculated and quadruples are constructed. For example, taking the backbone edge gateway device and authentication service as an example: the gateway device had 342 alarm events in its historical alarm logs over the past 90 days, of which the authentication service alarmed 87 times within 60 seconds after the gateway device alarmed, with a co-occurrence frequency of 87. Dividing the co-occurrence frequency of 87 by the total frequency of 342, we get a timing condition transition probability of 0.2544. Using the gateway device as the source node and the authentication service as the target node, and combining the timing condition transition probability of 0.2544 with the preset time window of 60 seconds, a quadruple is constructed.

[0012] The system iterates through all 2847 skeleton edges in the hard-constrained skeleton, performing the same statistical and calculation process as described above for each edge. Quadruples are constructed only for skeleton edges with a co-occurrence frequency greater than zero; skeleton edges with a co-occurrence frequency of zero are not constructed. Excluded skeleton edges do not participate in the current fault knowledge base inference during subsequent system operation. However, if new co-occurrence patterns appear in the real-time alarm data, the system will re-statistically analyze and evaluate their inclusion in the next knowledge base update cycle. Statistically, 523 skeleton edges with a co-occurrence frequency greater than zero are found, corresponding to 523 quadruples. All 523 quadruples are aggregated, and a causal time-series graph with a directed graph structure is generated using the quadruples as the basic storage unit. This graph is stored in the graph database as the fault knowledge base.

[0013] For example, the co-occurrence frequency statistics and probability calculations for other skeleton edges are as follows: For skeleton edge switches and gateway devices, the total alarm frequency of the first node is 156 times, the co-occurrence frequency is 64 times, and the timing condition transition probability is 0.4103; For skeleton edge master database and authentication service, the total alarm frequency of the first node is 98 times, the co-occurrence frequency is 18 times, and the timing condition transition probability is 0.1837; For skeleton edge sensors and gateway devices, the total alarm frequency of the first node is 423 times, the co-occurrence frequency is 3 times, and the timing condition transition probability is 0.0071. Furthermore, S2 integrates the device physical connection topology and the service call chain topology into a unified hard-constraint skeleton, strictly limiting the generation range of causal edges between alarm events to node pairs with connections in the skeleton. This solves the problem that existing statistical co-occurrence causal mining methods are prone to misjudging indirect associations as direct causality due to the lack of topological constraints, achieving accurate causal relationship mining based on dual constraints of physical connection and service call. By statistically analyzing the co-occurrence frequency along the hard-constraint skeleton and deduplicating by unique event identifiers, the temporal conditional transition probability is calculated. Combined with a preset time window to construct quadruples, the temporal co-occurrence relationship between alarms is quantified into a calculable transition probability value, providing a quantitative basis for subsequent reverse backtracking reasoning. By summarizing all quadruples to generate a causal temporal graph as a fault knowledge base, the alarm propagation pattern is solidified and stored in the form of a structured graph, providing a data foundation that can be directly queried and reasoned for subsequent real-time alarm diagnosis and root cause localization. S3. When a new alarm event is received from the real-time alarm log, starting from the target node where the new alarm event is located, backtrack in the opposite direction of the temporal conditional transition probability in the fault knowledge base, and output the root cause location result. Specifically, it continuously consumes real-time alarm logs from the message queue; at a certain time, it receives a new alarm event, the device to which the alarm event belongs is the authentication service, and the alarm type is response timeout; Starting from the target node where the new alarm event occurs, which is the authentication service, a reverse backtracking is performed in the fault knowledge base along the opposite direction of the temporal conditional transition probability. The specific process of the reverse backtracking is as follows: taking the target node authentication service as the current node, all causal edges with the current node as the target node are searched in the fault knowledge base. Two causal edges are found, one from the gateway device and the other from the main database. For each causal edge found, the source node corresponding to the causal edge is obtained, namely the gateway device and the main database, forming a single-step backtracking path from the target node to the source node. During the reverse backtracking process, in order to avoid the same node being repeatedly accessed due to bidirectional causal edges and forming a loop, the node accessed each time is marked. When the backtracking path reaches the marked node again, the backtracking of this branch is terminated. Using the gateway device as the new current node, search the fault knowledge base for all causal edges with the gateway device as the target node. If a causal edge from the switch is found, the source node switch is obtained. Using the master database as the new current node, search for causal edges with the master database as the target node. If no causal edge is found, the backtracking of this branch terminates. Using the switch as the new current node, search for causal edges with the switch as the target node. If no causal edge is found, the backtracking of this branch terminates. When there is no causal edge with the current node as the target node in the fault knowledge base, it indicates that this node is the upstream node of the current branch, and the backtracking of this branch is terminated. This terminated node is the candidate root cause source node. If the target node itself does not have a causal edge with the target node as the target node in the fault knowledge base, then the target node itself is output as the candidate root cause source node. Connect all causal edges and nodes traversed in each backtracking step in the backtracking order to generate a complete propagation path from the target node to each termination node; the termination node of path one is the switch, and the propagation path is from the switch to the gateway device, and from the gateway device to the authentication service; the termination node of path two is the main database, and the propagation path is from the main database to the authentication service. The specific process for outputting the root cause localization result is as follows: Obtain the temporal conditional transition probabilities corresponding to each causal edge in each complete propagation path. For each propagation path, multiply the temporal conditional transition probabilities corresponding to each causal edge it contains, and then divide by the number of causal edges in the path to obtain the path confidence score after length normalization. The reason for using geometric mean for length normalization is that when the number of causal edges in a path is different, directly using probability multiplication will cause the confidence score of long paths to systematically decrease as the number of edges increases, thus underestimating the failure scenario where the true root cause is located at the end of the long chain. After using geometric mean, the confidence scores of paths of different lengths are comparable, eliminating the systematic bias of path length on the ranking results. All candidate root cause nodes are sorted from high to low according to path confidence and then output. The node types of the candidate root cause nodes include physical device nodes and service nodes. As an example, in this embodiment, the ranking results are as follows: the first candidate root cause source node is the switch, the node type is a physical device node, and the path confidence is the highest; the second candidate root cause source node is the main database, the node type is a service node, and the path confidence is the second highest. Furthermore, the root cause localization results are displayed on the operation and maintenance monitoring interface in the form of a visualized causal propagation path diagram. The diagram uses different colors to mark candidate root cause source nodes and propagation paths. S3 performs reverse backtracking in the fault knowledge base along the opposite direction of the temporal conditional transition probability, tracing the possible root cause source nodes upward from the target alarm node, generating a complete alarm propagation path. This solves the problem that existing alarm clustering methods only compress the number of alarms but cannot explain the causal propagation relationship between alarms or provide a complete fault propagation link. By multiplying the temporal conditional transition probabilities of each causal edge in the propagation path to obtain the path confidence and sorting it from high to low, the system provides operation and maintenance personnel with a candidate root cause ranking based on quantifiable confidence, solving the problem of the lack of interpretability of root cause localization results. S4. Receive confirmation feedback from engineers regarding the root cause localization results. When the cumulative confirmation feedback for the same causal edge reaches a preset threshold, update the temporal conditional transition probability of the causal edge. Specifically, after displaying the root cause location results on the operation and maintenance monitoring interface, the engineer confirms or corrects the root cause location results based on the actual fault investigation. In this embodiment, the engineer confirms that the root cause location results are correct, that is, the fault does indeed originate from the abnormal operation of the switch, which causes the gateway device to disconnect, thereby triggering the authentication service response timeout. The engineer clicks the confirmation button on the monitoring interface to submit the confirmation feedback. During the reverse backtracking and root cause localization process, the system records the total number of times each causal edge has been triggered in history before the current trigger. After receiving confirmation feedback from engineers, the system counts the cumulative number of times each causal edge has been confirmed as valid by engineers in different fault diagnosis instances. When the cumulative number of confirmations corresponding to the same causal edge reaches a preset threshold, the system triggers an update of the temporal condition transition probability of that causal edge. The preset threshold is: the cumulative number of confirmations in N consecutive different fault diagnosis instances reaches M times; in this embodiment, N is 5 and M is 3, that is, when the cumulative number of confirmations in 5 consecutive different fault diagnosis instances reaches 3 times, the update is triggered; the continuity judgment criterion is: the continuity is defined as no other unconfirmed fault instances are inserted between two adjacent confirmations, and if there are unconfirmed diagnosis instances in the middle, the counting is interrupted and the accumulation is restarted. Furthermore, after the update is triggered, the updated time-series condition transition probability is calculated using a Bayesian smooth weighted fusion method. Taking the confirmed causal edge switch pointing to the gateway device as an example, the time-series condition transition probability before the causal edge update is used as the historical statistical probability value. The total number of historical triggers before this trigger is used as the weight of the historical statistical probability value. The cumulative number of confirmations is used as the weight of the manual confirmation experience. The sum of the historical cumulative number of triggers and the cumulative number of confirmations is used as the total fusion weight. The weighted average of the historical statistical probability value and the preset manual confirmation confidence level is calculated to obtain the updated time-series condition transition probability. Specifically, the formula for calculating the updated temporal conditional transition probability is as follows: P_new = (T × P_old + K × Con) / (T + K) Where P_old is the temporal conditional transition probability before the update, T is the total number of historical triggers of this causal edge before this trigger, K is the cumulative number of confirmations, and Con is the preset human confirmation confidence level. Since this formula is a weighted average and T and K are both positive, P_new always lies between P_old and Con. Therefore, the updated probability always lies between the probability before the update and the human confirmation confidence level. When the number of confirmations increases, the weight of the human confirmation confidence level increases, and the probability converges towards the direction of human confirmation. When the number of confirmations is zero, the probability remains unchanged. The preset confidence level for manual confirmation is determined as follows: based on the statistical matching degree between engineers' historical confirmation records and the actual root cause of the fault, the average engineer confirmation accuracy rate is calculated. This can be recalculated and determined according to the engineers' historical accuracy statistics for different application scenarios. As an example, the timing condition transition probability of the cause-side switch pointing to the gateway device before the update is 0.4103. The total number of historical triggers before this trigger is 3, the total number of confirmations is 3, and the preset confidence level of manual confirmation is 0.85. The calculated timing condition transition probability after the update is (3×0.4103+3×0.85) / (3+3)=0.6302. Furthermore, the updated temporal conditional transition probability is stored in the corresponding quadruple in the fault knowledge base, replacing the original probability value, and used for path confidence calculation of the causal edge in subsequent reverse backtracking; S4 receives confirmation feedback from engineers on the root cause location results and counts the cumulative number of valid confirmations of the same causal edge in different fault diagnosis instances. When the cumulative number of confirmations reaches a preset threshold, the probability update is triggered, and the engineers' experience judgment is quantitatively integrated into the knowledge base, solving the problem that the existing knowledge base is static and cannot incorporate the feedback knowledge from maintenance personnel into the graph for continuous optimization; by adopting a Bayesian smooth weighted fusion method, the historical statistical probability value and the confidence of manual confirmation are weighted and fused, so that the updated probability is adjusted towards the direction of manual confirmation, realizing the continuous iterative evolution of the knowledge base based on human-machine collaborative feedback; S5. Continuously monitor the change events of the device physical connection topology and service call chain topology. When the topology changes, reconstruct the hard constraint skeleton and update the fault knowledge base. Specifically, the system continuously monitors for changes in the physical connection topology of devices and the business call chain topology by subscribing to the topology change notification interface of the configuration management database. The criterion for determining a change event is that a topology change has occurred when the topology version identifier in the configuration management database changes. At a certain time, the operation and maintenance personnel perform a capacity expansion operation on the platform, adding a new gateway device and connecting it to the switch via fiber optic cable. At the same time, they add the gateway device's call relationship to the authentication service. After the configuration management database completes the configuration update, the topology version identifier changes and sends a change notification. After the system receives the notification, it triggers a hard constraint skeleton reconstruction. After a topology change event is triggered, all physical device nodes and physical connection links are re-extracted from the updated physical device connection topology, and all service nodes and service call relationships are re-extracted from the updated service call chain topology. The re-extracted physical device nodes and service nodes are used as graph nodes, and the re-extracted physical connection links and service call relationships are used as skeleton edges to generate an updated hard constraint skeleton. For newly added gateway devices in the updated hard constraint skeleton, a preset default probability value is used as the initial value of the temporal conditional transition probability of the causal edge between the node and other nodes in the hard constraint skeleton that have a connection relationship. The preset default probability value is an order of magnitude lower than the minimum probability value of the historical skeleton edge, indicating that the initial confidence of the newly added causal edge is extremely low. In this example, the minimum probability value of the historical skeleton edge is 0.0071, and the default probability value is 0.01. The new gateway device has an optical fiber connection with the switch and a service call relationship with the authentication service. Therefore, multiple causal edges are added to the fault knowledge base, all with an initial probability value of 0.01. Each causal edge is stored in the fault knowledge base as a quadruple. The default probability value of the newly added node is also included in the trigger record and confirmation record after being passed through and output during subsequent diagnosis, participating in Bayesian smoothing updates and gradually converging towards the actual fault propagation pattern. For device nodes that have been taken offline during topology changes, remove the node and all its associated skeleton edges from the hard constraint skeleton, and remove all causal edges in which the node participates from the fault knowledge base. After the update is complete, the fault knowledge base has been synchronized to the latest topology status; subsequent real-time alarm diagnosis will be performed based on the updated hard constraint skeleton and fault knowledge base. Furthermore, S5 continuously monitors topology change events and uses changes in the topology version identifier as trigger conditions. When a topology change occurs, it automatically reconstructs the hard constraint skeleton and updates the fault knowledge base, solving the problem that the existing knowledge base is static and cannot automatically detect and adapt to system topology changes. By initializing causal edges for newly added nodes with preset default probability values ​​and deleting all edges associated with offline nodes, it achieves synchronization and consistency between the fault knowledge base and the topology state of the physical world, ensuring that subsequent root cause localization is always based on the correct system structure for reasoning. In summary, this embodiment constructs a hard-constraint skeleton by combining the physical connection topology of the devices and the business call chain topology to limit the range of causal edge generation, thus solving the problem that existing statistical co-occurrence causal mining is prone to generating false causal relationships due to the lack of topological constraints. It constructs a fault knowledge base by building a four-tuple causal time-series graph and generates a complete propagation path by backtracking when a real-time alarm is triggered, outputting root cause localization results sorted by path confidence, thus solving the problem that existing alarm clustering only achieves quantity compression but lacks interpretability of root cause propagation. By introducing a Bayesian smooth update mechanism based on engineer confirmation feedback, and automatically reconstructing the hard-constraint skeleton and updating the knowledge base when the topology changes, it solves the problems of static solidification, inability to continuously optimize, and inability to adapt to topology changes in existing knowledge bases, achieving continuous iterative evolution of the fault knowledge base based on human-machine collaborative feedback and adaptive updates to dynamic topology changes.

[0014] Example 2: This example provides a method for constructing a fault knowledge base and intelligent auxiliary diagnosis based on alarm logs of an IoT platform. Compared with Example 1, the core difference of this example is that the method is deployed in the operation and maintenance monitoring scenario of an IoT platform in an industrial park, demonstrating the entire process from alarm data collection, fault knowledge base construction, real-time alarm diagnosis to root cause location result output. This embodiment is deployed in the IoT platform operation and maintenance center of an industrial park and includes an equipment management system, a network management system, a business service management system, and a fault knowledge base construction platform. It runs six core functional modules: historical alarm log collection, acquisition of device physical connection topology and business call chain topology, construction of hard constraint skeleton, generation of causal time series graphs, real-time alarm reverse backtracking diagnosis, and engineer confirmation feedback updates. The alarm diagnosis process to be processed sequentially includes five operations: collecting alarm logs from various systems of the IoT platform, collecting device physical connection topology and business call chain topology, constructing hard constraint skeleton and fault knowledge base, receiving alarms in real-time and outputting root cause location results through reverse backtracking, receiving engineer confirmation feedback, and updating the knowledge base. The knowledge base can only be constructed after the alarm logs and topology data are successfully collected; real-time alarm diagnosis can only be performed after the knowledge base is successfully constructed; and engineer confirmation feedback can only be received after the diagnosis results are output, indicating a clear cross-system dependency chain. Since the alarm root cause location results directly affect the efficiency of equipment fault handling and business service continuity in the industrial park, the consistency level is determined to be strong consistency. Based on the historical alarm data of each system device of the IoT platform, a preset time window is determined by statistical analysis; based on the decay law of historical alarm co-occurrence relationship, the probability update is triggered when the cumulative number of confirmations in Bayesian smooth update reaches a preset threshold; based on the statistics of engineers' historical confirmation records, a preset confidence level for manual confirmation is determined. In a real-time monitoring scenario of IoT platform devices, the platform continuously receives alarm logs reported by various systems; at a certain moment, the business service management system reports a new alarm event. The service node to which this alarm event belongs is the authentication service, and the alarm type is response timeout. Starting from the target node where the new alarm event is located, a reverse backtracking is performed in the fault knowledge base along the opposite direction of the temporal conditional transition probability. The specific process of the reverse backtracking is as follows: taking the target node authentication service as the current node, searching for all causal edges with the current node as the target node in the fault knowledge base, finding two causal edges, one from the gateway device and the other from the main database; for each causal edge found, obtaining the source node corresponding to the causal edge, obtaining the gateway device and the main database respectively, forming a single-step backtracking path from the target node to the source node; taking the gateway device as the new current node, searching for all causal edges with the gateway device as the target node in the fault knowledge base, finding a causal edge from the switch, obtaining the source node switch; taking the main database as the new current node, searching for causal edges with the main database as the target node, if not found, the backtracking terminates for this branch; taking the switch as the new current node, searching for causal edges with the switch as the target node, if not found, the backtracking terminates for this branch; when the current node does not have a causal edge with that node as the target node, the backtracking terminates, and this terminated node is the candidate root cause source node; Connect all causal edges and nodes traversed in each backtracking step in the backtracking order to generate a complete propagation path from the target node to each termination node: the termination node of path one is the switch, the propagation path is the switch pointing to the gateway device, and the gateway device pointing to the authentication service; the termination node of path two is the main database, and the propagation path is the main database pointing to the authentication service; the termination node switch and the main database are the candidate root cause source nodes. All candidate root cause nodes are sorted from highest to lowest according to path confidence and then output. The sorting result is as follows: the first candidate root cause node is the switch, the node type is a physical device node, and the path confidence is the highest; the second candidate root cause node is the main database, the node type is a business service node. The root cause location results are displayed on the IoT platform operation and maintenance monitoring screen in the form of a visual causal propagation path diagram. After investigation, the engineer confirmed that the root cause analysis was correct, indicating that the fault indeed originated from a malfunctioning switch that caused the gateway device to disconnect, leading to an authentication service timeout and ultimately causing the main database access failure. The engineer clicked the confirmation button on the monitoring interface to submit confirmation feedback. The system recorded the total number of historical triggers before this trigger, which was triggered by the cause-side switch pointing to the gateway device, and updated it after this trigger. When the cumulative number of confirmations reached a preset threshold, the trigger probability was updated. The updated temporal condition transition probability was calculated using a Bayesian smooth weighted fusion method and replaced the original probability value. The execution process also includes a topology change adaptive update process: Operations personnel perform expansion operations on the IoT platform, adding a new gateway device connected to the switch via fiber optic cable, and simultaneously adding the gateway device's call relationship to the authentication service; after the configuration management database completes the configuration update, the topology version identifier changes, and the system triggers hard constraint skeleton reconstruction; nodes and edge relationships are re-extracted from the updated topology to generate the updated hard constraint skeleton; the newly added gateway device is included in the new skeleton, and its connection relationship with the switch and authentication service is included in the edge set of the new skeleton; a preset default probability value is used as the initial value of the temporal conditional transition probability of the causal edges related to the newly added node; after the update is completed, the fault knowledge base is synchronized to the latest topology status, and subsequent real-time alarm diagnosis is performed based on the updated hard constraint skeleton and fault knowledge base. If, in a subsequent real-time alarm diagnosis, a new gateway device actually triggers an alarm and reverse backtracking, its relevant causal edge will be traversed and output during the diagnosis. After confirmation by engineers, a probability update will be triggered, gradually converging towards the actual fault propagation pattern. This embodiment validates the method in the operation and maintenance monitoring scenario of an IoT platform in an industrial park: by constructing a hard constraint skeleton through the physical connection topology of devices and the business call chain topology to limit the range of causal edge generation, it achieves accurate causal relationship mining based on dual constraints of physical connection and business call; by generating a complete propagation path through reverse backtracking when a real-time alarm is triggered and outputting the root cause location results in order of path confidence, it achieves full-link reverse inference from the target alarm to the root cause and quantifiable confidence assessment; by introducing a Bayesian smooth update mechanism based on engineer confirmation feedback, and automatically reconstructing the hard constraint skeleton and updating the knowledge base when the topology changes, it achieves continuous iterative evolution of the fault knowledge base based on human-machine collaborative feedback and adaptive updates to the topology dynamics; it fully demonstrates that this method can effectively solve the problems in IoT platform operation and maintenance monitoring, such as the lack of topological constraints leading to false causal relationships, lack of root cause propagation interpretability, static solidification of the knowledge base preventing continuous optimization, and the inability to adapt to topology changes.

[0015] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make some modifications or alterations to the above-disclosed technical content to create equivalent embodiments without departing from the scope of the present invention. Any simple modifications, equivalent changes and alterations made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the scope of the present invention.

Claims

1. A method for constructing a fault knowledge base and providing intelligent auxiliary diagnosis based on alarm logs from an IoT platform, characterized in that, Includes the following steps: S1. Obtain historical alarm logs from the IoT platform, receive real-time alarm logs from the IoT platform, and collect the device physical connection topology and business call chain topology of the IoT platform. S2. Based on the device physical connection topology and service call chain topology, construct a hard constraint skeleton for causal propagation. Use the hard constraint skeleton to limit the generation range of causal edges between alarm events, and only allow causal edges to be established between node pairs with connections in the hard constraint skeleton. Based on the historical alarm log, along the node pairs with connections in the hard constraint skeleton, count the co-occurrence frequency of alarm events between adjacent nodes within a preset time window, calculate the temporal condition transition probability, and construct a causal temporal graph in the form of a quadruple as a fault knowledge base. S3. When a new alarm event is received from the real-time alarm log, starting from the target node where the new alarm event is located, backtrack in the opposite direction of the temporal conditional transition probability in the fault knowledge base, and output the root cause location result. S4. Receive confirmation feedback from engineers regarding the root cause localization results. When the cumulative confirmation feedback for the same causal edge reaches a preset threshold, update the temporal conditional transition probability of the causal edge. S5. Continuously monitor the change events of the device physical connection topology and service call chain topology. When the topology changes, reconstruct the hard constraint skeleton and update the fault knowledge base.

2. The method according to claim 1, characterized in that, The hard constraint framework for causal propagation constructed in S2 based on the device physical connection topology and the service call chain topology specifically includes: Extract physical device nodes and physical connection links between devices from the device physical connection topology, and extract service service nodes and service call relationships between services from the service call chain topology; The physical device nodes and the service service nodes together serve as the graph nodes of the hard constraint skeleton, and the physical connection links and the service call relationships together serve as the skeleton edges of the hard constraint skeleton. The skeleton edges include directed skeleton edges and undirected skeleton edges. Service call relationships are mapped as directed skeleton edges, and physical connection links are mapped as undirected skeleton edges. For any pair of nodes, if at least one of physical connection links and service call relationships exists, a skeleton edge is established between the pair of nodes to generate the hard constraint skeleton of the graph structure.

3. The method according to claim 2, characterized in that, In S2, for pairs of nodes connected along the hard-constrained skeleton, the co-occurrence frequency of alarm events between adjacent nodes within a preset time window is counted, specifically including: Read the alarm event sequence of each node from the historical alarm log, the alarm event sequence including the occurrence time of each alarm event; Traverse each skeleton edge in the hard-constrained skeleton, and record the node at the starting point of the directed skeleton edge as the first node and the node at the ending point of the directed skeleton edge as the second node; for undirected skeleton edges, perform the statistical process described in this claim with the two endpoints as the first node and the second node respectively. Extract the first alarm event sequence corresponding to the first node and the second alarm event sequence corresponding to the second node from the alarm event sequence; Iterate through each alarm event in the first alarm event sequence, taking the occurrence time of the current alarm event as the start time, and offsetting it backward by a preset time window length to obtain the end time; Retrieve alarm events whose occurrence time is between the start time and the end time in the second alarm event sequence; deduplicate the retrieved alarm events according to their unique event identifiers and accumulate them as the co-occurrence frequency of the skeleton edge.

4. The method according to claim 3, characterized in that, The S2 step calculates the temporal conditional transition probability and constructs a causal temporal graph in the form of four-tuples as a fault knowledge base, specifically including: Obtain the total frequency of alarm events occurring in the historical alarm log of the first node; divide the co-occurrence frequency by the total frequency to obtain the temporal conditional transition probability of the second node occurring an alarm event within a preset time window after the first node's alarm event occurs; Using the first node as the source node and the second node as the target node, a quadruple is constructed by combining the temporal conditional transition probability and the preset time window; the quadruples corresponding to the skeleton edges with a co-occurrence frequency greater than zero in the hard constraint skeleton are summarized to generate a causal temporal graph as a fault knowledge base. The quadruple includes: source node, target node, temporal conditional transition probability value, and effective time window.

5. The method according to claim 4, characterized in that, In step S3, starting from the target node where the new alarm event is located, a reverse backtracking is performed in the fault knowledge base along the opposite direction of the temporal conditional transition probability. Specifically, this includes: Using the target node as the current node, search for all causal edges in the fault knowledge base that use the current node as the target node; for each causal edge found, obtain the source node corresponding to the causal edge to form a single-step backtracking path from the target node to the source node. Using the source node as the new current node, repeat the above search and retrieval steps until the current node does not have any causal edges with that node as the target node, then terminate the backtracking. Connect all causal edges and nodes traversed in each backtracking step in the backtracking order to generate a complete propagation path from the target node to each termination node.

6. The method according to claim 5, characterized in that, The root cause localization results output in S3 specifically include: Obtain the temporal conditional transition probabilities corresponding to each causal edge contained in each complete propagation path; calculate the path confidence of each complete propagation path, wherein the path confidence is the geometric mean of the temporal conditional transition probabilities of each causal edge contained in the path; Sort each complete propagation path in descending order of path confidence, and output the sorted complete propagation paths and corresponding candidate root cause source nodes as the root cause localization results. The root cause localization results include: the device identifier and node type of each candidate root cause source node, the complete propagation path corresponding to each candidate root cause source node, and the path confidence level corresponding to each complete propagation path.

7. The method according to claim 1, characterized in that, In step S4, when the cumulative confirmation feedback for the same causal edge reaches a preset threshold, the temporal conditional transition probability of the causal edge is updated, specifically including: During the process of reverse backtracking and generating root cause localization results, the total number of times each causal edge involved in root cause localization was triggered before the current trigger was counted and recorded. Receive confirmation feedback from engineers regarding the root cause localization results, and for each causal edge, count the cumulative number of times it has been confirmed as valid by engineers in different fault diagnosis instances; When the cumulative number of acknowledgments corresponding to the same causal edge meets a preset threshold, the temporal conditional transition probability of that causal edge is updated. The preset threshold is when the cumulative number of acknowledgments in N consecutive different fault diagnosis instances reaches M times, where N and M are both positive integers. The updated temporal conditional transition probability is calculated using a Bayesian smooth weighted fusion method.

8. The method according to claim 7, characterized in that, The method of calculating the updated temporal conditional transition probabilities using Bayesian smoothing weighted fusion specifically includes: The historical statistical probability value is the transition probability of the time sequence condition before the update; the weight of the historical statistical probability value is the total number of times the causal edge was triggered before this trigger; and the weight of the cumulative number of confirmations is the weight of the manual confirmation experience. The historical statistical probability value is weighted and fused with the preset manual confirmation confidence level. The total number of historical cumulative triggers and the total number of cumulative confirmations of the causal edge before the current trigger are used as the total fusion weight. The weighted average of the historical statistical probability value and the manual confirmation confidence level is calculated to obtain the updated temporal condition transition probability. The updated temporal conditional transition probability is located between the historical statistical probability value and the manually confirmed confidence level.

9. The method according to claim 1, characterized in that, In step S5, when the topology changes, the hard constraint skeleton is reconstructed and the fault knowledge base is updated, specifically including: When a topology change event is triggered, physical device nodes and physical connection links are extracted from the updated physical connection topology, and business service nodes and business call relationships are extracted from the updated business call chain topology. The extracted physical device nodes and business service nodes are used as graph nodes, and the extracted physical connection links and business call relationships are used as skeleton edges to generate the updated hard constraint skeleton. For newly added nodes in the updated hard constraint skeleton, a preset default probability value is used as the initial value of the temporal conditional transition probability of the causal edge between the node and other nodes in the hard constraint skeleton that have a connection relationship, and each causal edge is stored in the fault knowledge base.

10. The method according to claim 1, characterized in that, S1 also includes structured event extraction and verification of alarm logs: semantic event extraction is performed on the historical alarm logs and real-time alarm logs using a preset training language model to generate structured event data containing a unique event identifier, timestamp, device identifier, alarm type, and alarm level; the structured event data is compared and verified with a preset device management information database; when the extracted device identifier is not within the range of the device management information database, the event data is discarded and a manual review task is generated; when the extracted alarm type or alarm level is not within the range of preset standard enumeration values, the field is marked as an unknown type, the structured event data is retained, and a manual review task is generated.

Images