Alarm convergence method and apparatus, computer-readable medium, and electronic device

Abstract

The application belongs to the technical field of information processing, and relates to an alarm convergence method and device, a computer readable medium and an electronic device. The method comprises the following steps: acquiring an alarm information set, determining root cause device labels corresponding to alarm devices in the alarm information set according to a first rule; acquiring a device relationship graph corresponding to the alarm devices, determining parent devices and root devices corresponding to the alarm devices based on the device relationship graph and the root cause device labels; determining target alarm scenes corresponding to the alarm devices according to the parent devices and the root devices corresponding to the alarm devices, and determining root cause devices and root cause alarms corresponding to the alarm devices according to convergence rules corresponding to the target alarm scenes. The application can perform alarm convergence based on digital modeling, graph calculation and scene strategy technology, and improves the efficiency and accuracy of alarm convergence.

Description

Technical Field

[0001] This application belongs to the field of information processing technology, specifically relating to an alarm convergence method, an alarm convergence device, a computer-readable medium, and an electronic device. Background Technology

[0002] With the rapid development of the digital economy, various power network systems have become an indispensable part of life. During the operation and maintenance of power network systems, it is necessary to collect data on the operational status of various infrastructure components through sensors and analyze the collected information. When some devices in the system fail, their downstream devices will simultaneously trigger a large number of alarms. Therefore, identifying the root cause device and its corresponding root cause alarm from this large number of alarms is a key focus. Summary of the Invention

[0003] The purpose of this application is to provide an alarm convergence method, alarm convergence device, computer-readable medium, and electronic device that can overcome the problems of low alarm convergence efficiency and poor accuracy in related technologies.

[0004] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part from practice of this application.

[0005] According to one aspect of the embodiments of this application, an alarm convergence method is provided. The method includes: acquiring an alarm information set; determining root cause device tags corresponding to each alarm device in the alarm information set according to a first rule; acquiring a device relationship graph corresponding to the alarm devices; determining a parent device and a root device corresponding to each alarm device based on the device relationship graph and the root cause device tags; determining a target alarm scenario corresponding to each alarm device according to the parent device and root device corresponding to each alarm device; and determining a root cause device and a root cause alarm corresponding to each alarm device according to a convergence rule corresponding to the target alarm scenario.

[0006] According to one aspect of the embodiments of this application, an alarm convergence device is provided, the device comprising: a tag generation module, configured to acquire an alarm information set and determine root cause device tags corresponding to each alarm device in the alarm information set according to a first rule; a graph analysis module, configured to acquire a device relationship graph corresponding to the alarm devices and determine a parent device and a root device corresponding to each alarm device based on the device relationship graph and the root cause device tags; and a root cause determination module, configured to determine a target alarm scenario corresponding to each alarm device according to the parent device and the root device corresponding to each alarm device, and determine the root cause device and root cause alarm corresponding to each alarm device according to a convergence rule corresponding to the target alarm scenario.

[0007] According to one aspect of the embodiments of this application, a computer-readable medium is provided, on which a computer program is stored, which, when executed by a processor, implements the alarm convergence method as described in the above technical solutions.

[0008] According to one aspect of the embodiments of this application, an electronic device is provided, the electronic device comprising: a processor; and a memory for storing executable instructions of the processor; wherein the processor is configured to execute an alarm convergence method as described above by executing the executable instructions.

[0009] According to one aspect of the embodiments of this application, a computer program product is provided, the computer program product including computer instructions, which, when executed on a computer, cause the computer to perform the alarm convergence method as described in the above technical solutions.

[0010] The alarm convergence method provided in this application, after acquiring the alarm information set, determines the root cause device label corresponding to each alarm device in the alarm information set according to a first rule; then, it determines the parent device and root device corresponding to each alarm device according to the device relationship graph corresponding to the alarm devices and the root cause device label corresponding to each alarm device; finally, it determines the target alarm scenario corresponding to each alarm device according to the parent device and root device corresponding to each alarm device, and determines the root cause device and root cause alarm corresponding to each alarm device according to the convergence rule corresponding to the target alarm scenario. This application, on the one hand, can perform alarm convergence based on digital modeling, graph computation, and scenario strategies, improving the efficiency and accuracy of alarm convergence; on the other hand, it can comprehensively cover various system architectures in data centers, improving the universality of alarm convergence.

[0011] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0012] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0013] Figure 1 A schematic diagram of the system architecture for applying the alarm convergence method in the embodiments of this application is shown.

[0014] Figure 2 The schematic diagram illustrates the steps of the alarm convergence method in the embodiments of this application.

[0015] Figure 3 The schematic diagram illustrates the process of determining the root cause device tag corresponding to the alarm device in an embodiment of this application.

[0016] Figure 4 The schematic diagram illustrates the process of determining the root cause device tag corresponding to the alarm device in an embodiment of this application.

[0017] Figure 5 The illustration shows a flowchart of determining the root cause device label corresponding to the alarm device based on real-time device indicators, alarm type, and root cause alarm set in an embodiment of this application.

[0018] Figure 6 The illustration shows a flowchart of determining the root cause device label corresponding to the alarm device based on real-time device indicators, alarm type, and non-root cause alarm set in an embodiment of this application.

[0019] Figure 7 The diagram illustrates the structure of determining the parent and root devices of alarm devices based on a directed acyclic graph and root device labels in an embodiment of this application.

[0020] Figure 8 A schematic diagram of the architecture of a cabinet containing AC and DC power supplies is shown in an embodiment of this application.

[0021] Figure 9 A schematic diagram of the alarm convergence information interface in an embodiment of this application is shown.

[0022] Figure 10 The diagram illustrates an interface containing convergence information, including an alarm statistics table and a root cause device alarm list, in an embodiment of this application.

[0023] Figure 11 The schematic diagram illustrates the process of calling different services to achieve alarm convergence in the embodiments of this application.

[0024] Figure 12 A schematic block diagram of the alarm convergence device in an embodiment of this application is shown.

[0025] Figure 13 A schematic diagram of a computer system architecture suitable for implementing the embodiments of this application is shown. Detailed Implementation

[0026] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided to make this application more comprehensive and complete, and to fully convey the concept of the exemplary embodiments to those skilled in the art.

[0027] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this application.

[0028] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0029] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0030] In the relevant technologies of this application, taking alarm convergence of power systems as an example, when collecting alarms from power systems to obtain root cause devices and root cause alarms, there are mainly the following alarm convergence methods: alarm convergence based on case reasoning, alarm convergence based on rule reasoning, alarm convergence based on the hierarchical relationship of power distribution equipment, alarm convergence based on encoding, and alarm convergence based on neural networks.

[0031] Case-based alarm convergence involves reasoning about root cause devices and root cause alarms based on alarm cases that have already occurred. However, this method is not sensitive to changes in the power system network, the analysis is complex and time-consuming, the real-time performance is low, and there is no rigorous theoretical basis.

[0032] Alarm convergence based on rule-based reasoning involves experts summarizing a knowledge base based on experience and predictions, and then reasoning about the root cause devices and root cause alarms corresponding to the devices that generate alarms based on the knowledge base. However, this method suffers from the problem of cumbersome extraction of expert knowledge bases and difficulty in adapting to changes in power system networks.

[0033] Alarm convergence based on the hierarchical relationship of power distribution equipment is to converge the root cause device and root cause alarm according to the correlation of various power distribution equipment forming the power system. However, this method does not support IT warehouses, server racks, and air conditioning power distribution systems, and has the problem of not being able to fully cover the power distribution architecture in data centers.

[0034] Alarm convergence based on coding involves constructing corresponding pseudocodes for each device forming the power system and controlling alarm convergence through a programmable logic controller. However, the design and modification of the coding scheme require manual intervention, resulting in a low level of intelligence.

[0035] Alarm convergence based on neural networks involves training a neural network model to achieve alarm convergence. During training, a large number of alarm events are collected as training data. Then, the model parameters are adjusted based on the predicted root cause devices and predicted root cause alarms corresponding to the training data, as well as the root cause devices and root cause alarms corresponding to the training data, to obtain a neural network model for alarm convergence. However, this method has problems such as large training data requirements, difficulty in model training, poor interpretability, and the need to verify the convergence accuracy.

[0036] In view of the relevant technologies in this field, this application proposes an alarm convergence method. The alarm convergence method in this application can be applied to any scenario where a power network exists, such as power systems, HVAC systems, computer rooms, data centers, etc. Before describing the alarm convergence method in the embodiments of this application in detail, the technical terms involved in this application will be explained first.

[0037] 1. Alarm Storm: Due to certain power anomalies (power equipment or line failures), a series of devices on the related links issue a large number of alarms in a short period of time.

[0038] 2. Root cause: The fundamental reason, here refers to the root cause that causes the alarm storm. For example, the tripping of circuit breaker A causes a series of alarms in downstream equipment. The tripping of circuit breaker A is the root cause.

[0039] 3. Alarm Convergence: When an alarm storm occurs, the root cause device and corresponding root cause alarm are analyzed from a large number of alarms and presented, which facilitates operation and maintenance to quickly locate the root cause and handle the fault.

[0040] 4. Terminal: The port on the device that connects to other devices.

[0041] 5. Data Center: A data center is a globally collaborative network of specific devices used to transmit, accelerate, display, compute, and store data information on an interconnected network infrastructure.

[0042] Next, an exemplary system architecture applying the technical solution of this application will be described.

[0043] Figure 1 An exemplary system architecture block diagram illustrating the application of the technical solution of this application is shown schematically.

[0044] like Figure 1As shown, the system architecture 100 may include terminal device 101, server 102, and network 103. Terminal device 101 can be various electronic devices with display screens, such as smartphones, tablets, laptops, desktop computers, smart TVs, and smart vehicle terminals. Terminal device 101 can receive and store device information and alarm information sent by sensors installed on devices within the various power systems. Device information may include real-time status information, etc., and it can also display alarm convergence results obtained from alarm convergence, such as root cause devices and root cause alarms corresponding to the alarm information. Server 102 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services. Network 103 can be a communication medium of various connection types that can provide a communication link between client 101 and server 102, such as a wired communication link or a wireless communication link.

[0045] Depending on the implementation requirements, the system architecture in this application embodiment can have any number of terminal devices, networks, and servers. For example, the server can be a server group composed of multiple server devices. Furthermore, the technical solutions provided in this application embodiment can be applied to terminal device 101.

[0046] In one embodiment of this application, after receiving alarm information, the terminal device 101 can send the alarm information to the server 102 via the network 103 in real time. After receiving a large number of alarm information, the server 102 can first determine the root cause device label corresponding to each alarm device according to a first rule. The first rule is related to the alarm type corresponding to the alarm device. For example, if any one of the alarms corresponding to an alarm device can be used as a root cause alarm, then the alarm device is marked as a candidate root cause device. If none of the alarms corresponding to an alarm device can be used as a root cause alarm, then the alarm device is marked as a non-root cause device. Furthermore, when all the alarms corresponding to an alarm device need to be determined based on the device status, whether... When an alarm can be identified as a root cause alarm, the real-time device status of the alarm device can be obtained. Based on the real-time device status, it can be determined whether the alarm device can be marked as a candidate root cause device or a non-root cause device. Next, a request can be constructed based on all alarm devices and the root cause device labels corresponding to each alarm device to obtain a device relationship graph corresponding to all alarm devices. Then, a directed acyclic graph is constructed based on the device relationship graph, and the parent device and root device corresponding to each alarm device are determined based on the directed acyclic graph and the root cause device labels. Finally, the target alarm scenario corresponding to each alarm device is determined based on the determined parent device and root device, and the root cause device and root cause alarm corresponding to each alarm device are determined based on the convergence rule corresponding to the target alarm scenario. The target alarm scenario is related to the number of parent devices and root devices. When there is only one parent device and one root device, the target alarm scenario is the first alarm scenario. The corresponding convergence rule is to take the root device as the root cause device and the alarm corresponding to the root cause device as the root cause alarm. When there are multiple parent devices and multiple root devices, the target alarm scenario is the second alarm scenario. The corresponding convergence rule is different depending on whether the alarm type is bound when the terminal is modeled in the first alarm scenario.

[0047] In one embodiment of this application, before determining the root cause device tag corresponding to the alarm device, an alarm storm judgment can be performed on all alarm information. If an alarm storm is determined to have occurred, the alarm device is tagged with the corresponding root cause device tag. Furthermore, after alarm convergence is performed according to the scenario strategy, an alarm storm judgment can be performed on all alarm information corresponding to each root cause device. If it is determined that an alarm storm still exists, the target root cause alarm corresponding to the root cause device is determined based on the alarm level and alarm time of all possible root cause alarms corresponding to the root cause device, and all analysis results are written to the storage medium. If it is determined that an alarm storm does not exist, alarm convergence is not performed on all alarm information corresponding to the root cause device, but the root cause device and its corresponding alarm information are directly fed back for maintenance personnel to view.

[0048] In one embodiment of this application, alarm convergence can also be performed through terminal device 101. The specific alarm convergence process is the same as that performed in server 102, and will not be described again here.

[0049] In one embodiment of this application, the server 102 in this application may be a cloud server that provides cloud computing services, that is, this application relates to cloud storage and cloud computing technologies.

[0050] Cloud storage is a new concept that extends and develops from the concept of cloud computing. A distributed cloud storage system (hereinafter referred to as a storage system) refers to a storage system that uses cluster applications, grid technology, and distributed storage file systems to bring together a large number of storage devices of various types (storage devices are also called storage nodes) in the network to work together through application software or application interfaces to provide data storage and business access functions to the outside world.

[0051] Currently, the storage method of storage systems is as follows: Logical volumes are created. During the creation of a logical volume, physical storage space is allocated to each logical volume. This physical storage space may consist of a single storage device or the disks of several storage devices. Clients store data on a logical volume, which means storing the data on the file system. The file system divides the data into many parts, each part being an object. Each object contains not only the data but also additional information such as a data identifier (ID, ID entity). The file system writes each object to the physical storage space of that logical volume and records the storage location information of each object. Therefore, when a client requests access to data, the file system can allow the client to access the data based on the storage location information of each object.

[0052] The process by which a storage system allocates physical storage space to a logical volume is as follows: the physical storage space is pre-divided into strips according to the capacity estimate of the objects stored in the logical volume (this estimate often has a large margin relative to the actual capacity of the objects to be stored) and the grouping of Redundant Array of Independent Disks (RAID). A logical volume can be understood as a strip, thus allocating physical storage space to the logical volume.

[0053] Cloud computing is a computing model that distributes computing tasks across a large pool of computers, enabling various application systems to access computing power, storage space, and information services as needed. The network providing these resources is called the "cloud." From the user's perspective, resources in the "cloud" appear infinitely scalable, readily available, on-demand, and expandable, with payment based on usage.

[0054] As a provider of fundamental cloud computing capabilities, a cloud resource pool (referred to as a cloud platform, generally called an IaaS (Infrastructure as a Service) platform) is established. Various types of virtual resources are deployed in the resource pool for external customers to choose from. The cloud resource pool mainly includes: computing devices (virtualized machines containing operating systems), storage devices, and network devices.

[0055] Based on logical function, a PaaS (Platform as a Service) layer can be deployed on top of the IaaS (Infrastructure as a Service) layer, and a SaaS (Software as a Service) layer can be deployed on top of the PaaS layer. Alternatively, SaaS can be deployed directly on top of IaaS. PaaS is a platform for running software, such as databases and web containers. SaaS refers to various types of business software, such as web portals and bulk SMS senders. Generally speaking, SaaS and PaaS are upper layers compared to IaaS.

[0056] The following detailed description of the alarm convergence method, alarm convergence device, computer-readable medium, and electronic device provided in this application, with reference to specific embodiments, provides a detailed explanation of these technical solutions.

[0057] Figure 2 This illustration schematically shows a flowchart of an alarm convergence method in one embodiment of this application. The alarm convergence method is executed by a server, which may specifically be... Figure 1 Server 102 in the middle. For example... Figure 2 As shown, the alarm convergence method in this application embodiment can mainly include the following steps S210 to S230.

[0058] Step S210: Obtain the alarm information set and determine the root cause device label corresponding to each alarm device in the alarm information set according to the first rule;

[0059] Step S220: Obtain the device relationship diagram corresponding to the alarm device, and determine the parent device and root device corresponding to each alarm device based on the device relationship diagram and the root cause device label;

[0060] Step S230: Determine the target alarm scenario corresponding to each alarm device based on the parent device and root device corresponding to each alarm device, and determine the root cause device and root cause alarm corresponding to each alarm device based on the convergence rule corresponding to the target alarm scenario.

[0061] In the alarm convergence method provided in this application embodiment, after obtaining the alarm information set, the root cause device label corresponding to each alarm device in the alarm information set is determined according to a first rule; then, the parent device and root device corresponding to each alarm device are determined according to the device relationship graph corresponding to the alarm devices and the root cause device label corresponding to each alarm device; finally, the target alarm scenario corresponding to each alarm device is determined according to the parent device and root device corresponding to each alarm device, and the root cause device and root cause alarm corresponding to each alarm device are determined according to the convergence rule corresponding to the target alarm scenario. This application, on the one hand, can perform alarm convergence based on graph computation and scenario strategy, improving the efficiency and accuracy of alarm convergence; on the other hand, it can comprehensively cover various system architectures in the data center, improving the universality of alarm convergence.

[0062] The following section uses a power distribution system as an example to explain in detail the specific implementation of each step of the alarm convergence method.

[0063] In step S210, an alarm information set is obtained, and the root cause device label corresponding to each alarm device in the alarm information set is determined according to the first rule.

[0064] In one embodiment of this application, the power distribution system is a power network system composed of various power distribution equipment and facilities that transforms voltage and directly distributes electrical energy to end users. Each power distribution equipment and facility in the power distribution system is equipped with a sensor that can provide feedback on the real-time status of the power distribution equipment and facilities. The real-time status includes the energized status, alarm status, etc. of the power distribution equipment and facilities. In other words, the sensors can collect all alarm information in the power distribution system. The alarm information includes the identification information of the alarm equipment, the alarm type, the alarm level, and the alarm time, etc.

[0065] After obtaining the alarm information corresponding to the power distribution system, an alarm information set can be generated. Since not all alarm devices that issue alarms can be used as root cause devices, it is necessary to initially label whether the alarm devices can be used as root cause devices. Furthermore, among the alarm devices that can be used as root cause devices, the alarm devices that actually caused the alarms are converged and identified, i.e., the root cause devices. This can reduce the amount of data processing and improve the efficiency of alarm convergence.

[0066] In one embodiment of this application, a root cause device label corresponding to each alarm device in the alarm information set can be determined according to a first rule. This first rule is related to the alarm type corresponding to each alarm device, and the root cause device labels are divided into candidate root cause devices and non-root cause devices. When determining the root cause device label corresponding to each alarm device, the alarm type corresponding to each alarm device can be compared with the root cause alarm types in the root cause alarm set and the non-root cause alarm types in the non-root cause alarm set to obtain the root cause device label corresponding to each alarm device.

[0067] Figure 3 This schematically illustrates the process of determining the root cause device tag corresponding to the alarm device, such as... Figure 3 As shown, in step S301, the alarm type corresponding to the alarm device is compared with the root cause alarm type in the root cause alarm set; in step S302, when there is a root cause alarm type with the same alarm type in the root cause alarm set, the alarm device is marked as a candidate root cause device; in step S303, when there is no root cause alarm type with the same alarm type in the root cause alarm set, the root cause device label corresponding to the alarm device is determined according to the non-root cause alarm set.

[0068] Since an alarm device may correspond to one alarm type or multiple alarm types, in step S302, if an alarm device corresponds to multiple alarm types, when determining whether there is a root cause alarm type with the same alarm type in the root cause alarm set, it is only necessary to determine that at least one of the multiple alarm types is the same as the root cause alarm type in the root cause alarm set to mark the alarm device as a candidate root cause device. Meanwhile, since whether an alarm type can be a root cause alarm or a non-root cause alarm may be related to the real-time device metrics of the alarm device, when determining that an alarm device is not a candidate root cause device based on the root cause alarm set, the alarm type can be compared with the non-root cause alarm set. If the alarm type corresponding to the alarm device also does not belong to the non-root cause alarm set, then it is necessary to obtain the real-time device metrics to assist in determining whether the alarm device is a candidate root cause device or a non-root cause device.

[0069] Figure 4 This schematically illustrates the process of determining the root cause device tag corresponding to the alarm device, such as... Figure 4 As shown, in step S401, the alarm type corresponding to the alarm device is compared with the non-root cause alarm types in the non-root cause alarm set; in step S402, when there is a non-root cause alarm type with the same alarm type in the non-root cause alarm set, the alarm device is marked as a non-root cause device; in step S403, when there is no non-root cause alarm type with the same alarm type in the non-root cause alarm set, the real-time device index corresponding to the alarm device is obtained; in step S404, the root cause device label corresponding to the alarm device is determined according to the real-time device index, alarm type and root cause alarm set, or according to the real-time device index, alarm type and non-root cause alarm set.

[0070] After obtaining the real-time device metrics corresponding to the alarm device, the alarm type can be classified into root cause alarms or non-root cause alarms based on the real-time device metrics. Then, the alarm device is marked as a candidate root cause device or a non-root cause device. Therefore, it is necessary to determine an alarm type to be processed based on the real-time device metrics and the alarm type. Then, the alarm type to be processed is compared with the root cause alarm set or the non-root cause alarm set to determine the root cause device label corresponding to the alarm device.

[0071] Figure 5 This diagram illustrates the process of determining the root cause device label corresponding to an alarm device based on real-time device metrics, alarm type, and root cause alarm set. Figure 5 As shown, in step S501, the alarm type to be processed is determined according to the real-time device indicators and the alarm type; in step S502, when there is a root cause alarm type in the root cause alarm set that is the same as the alarm type to be processed, the alarm device is marked as a candidate root cause device; in step S503, when there is no root cause alarm type in the root cause alarm set that is the same as the alarm type to be processed, the alarm device is marked as a non-root cause device.

[0072] Figure 6 This diagram illustrates the process of determining the root cause device label corresponding to an alarm device based on real-time device metrics, alarm type, and non-root cause alarm set. Figure 6 As shown, in step S601, the alarm type to be processed is determined according to the real-time device indicators and the alarm type; in step S602, when there is a non-root cause alarm type in the non-root cause alarm set that is the same as the alarm type to be processed, the alarm device is marked as a non-root cause device; in step S603, when there is no non-root cause alarm type in the non-root cause alarm set that is the same as the alarm type to be processed, the alarm device is marked as a candidate root cause device.

[0073] For example, there are three alarm types: transformer switch tripping, inverter AC input overvoltage, and abnormal C-phase voltage of the A-channel mains input in the integrated distribution cabinet. Transformer switch tripping belongs to the root cause alarm set, while inverter AC input overvoltage belongs to the non-root cause alarm set. For the abnormal C-phase voltage of the A-channel mains input in the integrated distribution cabinet, the root cause and non-root cause alarms need to be determined based on the device status information of the alarming device. When the alarm type corresponding to the alarming device is transformer switch tripping, the alarming device can be marked as a candidate root cause device. When the alarm type corresponding to the alarming device is inverter AC input overvoltage, the alarming device can be marked as a non-root cause device. When the alarm type corresponding to the alarming device is abnormal C-phase voltage of the A-channel mains input in the integrated distribution cabinet, the real-time device indicators of the alarming device can be obtained. Then, based on the real-time device indicators, the alarm type, and the root cause or non-root cause alarm set, the alarming device can be further analyzed. Specifically, when the alarm type is "abnormal C-phase voltage of A-channel mains input in integrated distribution cabinet," it is necessary to determine the corresponding root cause device tag based on the current energized state of the integrated distribution cabinet. An abnormal C-phase voltage of A-channel mains input can only be considered a root cause alarm when the integrated distribution cabinet is de-energized; otherwise, it cannot. Once it is determined whether the integrated distribution cabinet is energized or de-energized, the pending alarm type, formed based on the cabinet's energized state and alarm type, can be compared with the root cause alarm set or non-root cause alarm set to determine the root cause device tag. For example, when the integrated distribution cabinet is energized, comparison with the root cause alarm set or non-root cause alarm set determines the root cause device tag as a non-root cause device; when the integrated distribution cabinet is de-energized, comparison with the root cause alarm set or non-root cause alarm set determines the root cause device tag as a candidate root cause device.

[0074] In one embodiment of this application, before determining the root cause device tag corresponding to each alarm device in the alarm information set, it is possible to determine whether the large number of received alarm information belongs to an alarm storm. When it is determined that an alarm storm has occurred, an alarm information set is constructed based on the alarm information in the same alarm storm, and the root cause device tag of each alarm device in the alarm information set is marked.

[0075] When determining whether an alarm storm has occurred, all alarm information within a preset time period can be acquired, and the number of acquired alarm information can be counted. When the number of alarm information is greater than or equal to a first threshold, an alarm storm is determined to have occurred. Then, an alarm information set can be generated based on the alarm information within the preset time period, and alarm convergence can be performed to obtain the root cause device and root cause alarm corresponding to each alarm information. For example, the preset time period can be set to 5 minutes, and the first threshold can be set to 3. That is, when the number of alarm information within 5 minutes is greater than or equal to 3, an alarm storm is determined to exist. Of course, the preset time period and the first threshold can also be set to other values; this application embodiment does not specifically limit this.

[0076] Furthermore, newly received alarm information can be evaluated. If the time interval between the alarm time of the newly received alarm information and the latest alarm time of the alarm information in the alarm information set is less than a second threshold, then the newly received alarm information is considered to belong to the same alarm storm as the previously received alarm information, and the newly received alarm information is added to the alarm information set. For example, the second threshold can be set to 5 minutes. That is, if the time interval between the alarm time of the newly received alarm information and the alarm time of the previous alarm information is less than 5 minutes, then the newly received alarm information and the previous alarm information are considered to belong to the same alarm storm. Of course, the second threshold can also be set to other values ​​according to actual needs, and this application embodiment does not specifically limit it.

[0077] In one embodiment of this application, before judging the alarm storm, it is also possible to judge whether the received alarm information participates in alarm convergence. This judgment is mainly implemented based on the configuration corresponding to the alarm information. Specifically, when the alarm type corresponding to the alarm information is generated by non-electrical factors, it is determined that the alarm information does not participate in alarm convergence and is removed from all alarm information. When the alarm type corresponding to the alarm information is generated by electrical factors, it is determined that the alarm information participates in alarm convergence. For example, when the alarm information is caused by environmental factors such as excessively high temperature or humidity, it means that the alarm information does not need to participate in alarm convergence and can be deleted to ensure that the alarm information set is formed based on all alarm information that can participate in alarm convergence. This can reduce the amount of data processing and improve the efficiency of root cause finding.

[0078] In step S220, a device relationship diagram corresponding to the alarm device is obtained, and the parent device and root device corresponding to each alarm device are determined based on the device relationship diagram and the root cause device label.

[0079] In one embodiment of this application, since the graph structure represents the real-world data structure through vertices and edges, it is more intuitive to observe. Therefore, after determining the root cause device label corresponding to each alarm device in the alarm information set, the hierarchical relationship between the alarm device and other devices can be intuitively determined based on the graph structure, thereby obtaining the root cause device that caused the alarm device to generate an alarm. In this embodiment of the application, after determining the root cause device label corresponding to each alarm device, a device relationship graph corresponding to each alarm device can be obtained. This device relationship graph can specifically be a power distribution relationship graph, that is, a connection relationship graph between various power distribution devices or power distribution facilities in the power distribution system. For example, if all alarm devices corresponding to the alarm information set correspond to a medium-voltage power distribution network, then the device relationship graph corresponding to the medium-voltage power distribution network can be obtained, and so on. Then, a corresponding directed acyclic graph can be constructed based on the device relationship graph, and the parent device and root device corresponding to each alarm device can be obtained based on the directed acyclic graph and the root cause device label corresponding to each alarm device. The root device may be the same as or different from the finally determined root cause device, depending on the subsequent scenario judgment.

[0080] In one embodiment of this application, when obtaining the device relationship diagram, it can first be obtained from the local cache. If the local cache does not contain a device relationship diagram corresponding to all alarm devices in the alarm information set, it can be obtained from a graph storage medium storing various power distribution system architecture diagrams. If the device relationship diagram can be obtained from the local cache, the acquisition time can be reduced and the convergence efficiency improved. After obtaining the device relationship diagram, a directed acyclic graph can be constructed based on the connection relationships between various power distribution devices or power distribution facilities in the device relationship diagram. Based on the directed acyclic graph and the root cause device labels corresponding to the alarm devices, the parent device and root device of the alarm devices can be determined. The parent device is the device corresponding to each parent node in the directed acyclic graph, and the root device is the alarm device corresponding to the node marked as a candidate root cause device in the directed acyclic graph.

[0081] Figure 7 This schematically illustrates the structure for determining the parent and root devices of alarm devices based on a directed acyclic graph and root cause device labels, as shown below. Figure 7As shown, the directed acyclic graph 700 includes six vertices, labeled AF, where nodes A, B, D, and F correspond to alarm devices. The alarm devices corresponding to nodes B and D are candidate root cause devices, and the alarm device corresponding to node A is a non-root cause device. Based on the directed acyclic graph 700 and the root cause device labels, the parent and root devices corresponding to the alarm devices corresponding to nodes A, B, D, and F can be obtained. Specifically, the alarm device corresponding to node A has no parent or root device. The parent device of the alarm device corresponding to node B is the alarm device corresponding to node A, and it has no root device. The parent device of the alarm device corresponding to node D is the alarm device corresponding to node B and the device corresponding to node C, and its root device is the alarm device corresponding to node B. The parent device of the alarm device corresponding to node F is the device corresponding to node E, and its root device is the alarm device corresponding to node B.

[0082] In one embodiment of this application, when determining the parent device and root device corresponding to the alarm device, the graph computing framework Tinkerpop can be used for calculation. Of course, other programming methods can also be used for graph computing, such as upward recursive tracing, depth-first search traversal, breadth-first search traversal, etc. This application embodiment does not specifically limit this.

[0083] In one embodiment of this application, the device relationship diagram is a power distribution relationship diagram generated by digital modeling based on the architecture of the power distribution system before alarm convergence of the alarm information set. During digital modeling, a corresponding modeling template can be selected from the modeling tool, such as a template for medium-voltage power distribution, an IT warehouse template, etc. If no corresponding template exists in the modeling tool, modeling is performed directly by creating a blank template and dragging and dropping device icons and lines to construct the template. After selecting the required template, the device names are filled in batches in the association table, and then the template is imported to generate the corresponding power distribution relationship diagram. The device names represent the device type and device number corresponding to each device. By associating the devices in the template with their device numbers, the devices in the relationship diagram can be further associated with the devices in the data center through the object model. This allows for accurate location and maintenance of the root cause device in the data center based on the device number corresponding to the root cause device after identifying the root cause device and root cause alarm based on the power distribution relationship diagram. It is worth noting that other power systems can also be modeled using the above digital modeling method to obtain corresponding power distribution relationship diagrams, and the devices in the power distribution relationship diagram can be associated with the devices in the data center through the object model. This embodiment of the application will not elaborate further here.

[0084] In one embodiment of this application, after all the device relationship diagrams are built, the device relationship diagrams obtained by digital modeling can be verified. Specifically, the verification can be performed according to the alarm list corresponding to different alarm convergence scenarios. The alarm list includes alarm devices, alarm types, root cause devices, and root cause alarms. By inputting the alarm devices and alarm types, the corresponding root cause devices and root cause alarms are obtained. Then, the output root cause devices and root cause alarms are compared with the root cause devices and root cause alarms in the alarm list. If they are the same, it means that the digital modeling is correct. If they are different, it means that the digital modeling is incorrect and the modeling tool needs to be corrected.

[0085] In step S230, a target alarm scenario corresponding to each alarm device is determined based on the parent device and root device corresponding to each alarm device, and a root cause device and root cause alarm corresponding to each alarm device are determined based on the convergence rule corresponding to the target alarm scenario.

[0086] In one embodiment of this application, after obtaining the parent device and root device corresponding to each alarm device, the number of parent devices and root devices corresponding to each alarm device can be counted, and the root cause device and root cause alarm corresponding to the alarm generated by each alarm device can be obtained by combining the scenario strategy decision.

[0087] The number of parent devices and root devices corresponding to each alarm device, determined based on the device relationship diagram, may be one, multiple, or zero, or there may be multiple parent devices and one root device, etc. Corresponding to different numbers, the determined target alarm scenario and convergence rules will also differ. In the embodiments of this application, when the number of parent devices and root devices is one, or when there are multiple parent devices and one root device, the first alarm scenario is taken as the target alarm scenario; when the number of parent devices and root devices is multiple, the second alarm scenario is taken as the target alarm scenario. The strategies corresponding to the first alarm scenario and the second alarm scenario are different.

[0088] In one embodiment of this application, when the target alarm scenario is the first alarm scenario, that is, when there is only one path and one root cause device or multiple paths and one root cause device, the root device corresponding to the alarm device can be taken as the root cause device, and the alarm type corresponding to the root cause device can be taken as the root cause alarm. For example, if the transformer switch trips, causing alarms in the low-voltage distribution cabinet and distribution drawer, then the alarm convergence can be obtained to find that the root cause device is the transformer, and the root cause alarm is the transformer switch tripping.

[0089] In one embodiment of this application, when the target alarm scenario is the second alarm scenario, that is, when there are multiple paths and multiple root cause devices, it is necessary to determine the corresponding convergence rule based on whether the terminals related to the alarm device and the parent device are bound to a preset alarm type during modeling. Specifically, based on whether the preset alarm type is bound during terminal modeling, there are three scenarios: (1) the terminals of the alarm device and the parent device are bound to a preset alarm type during modeling; (2) the terminals of the parent device of the alarm device are bound to a preset alarm type during modeling; and (3) neither the terminals of the alarm device nor the parent device are bound to a preset alarm type during modeling. Next, the convergence rules corresponding to these three scenarios will be described in detail.

[0090] When alarm devices and parent devices have preset alarm types bound to their terminals during terminal modeling, the alarm type corresponding to the alarm device can be compared with the preset alarm types. If the preset alarm type exists, the terminal bound to that alarm type is taken as the first target terminal, and backtracking convergence is performed starting from this first target terminal to obtain the root cause device and root cause alarm corresponding to that alarm type. For example, if the cabinet has AC and DC, such as... Figure 8 As shown, in cabinet 800 (only a partial structure is shown), AC is connected to the left side and DC to the right side. Therefore, when modeling the terminals of the alarm device and its parent device, alarm types corresponding to AC and DC will be bound. For example, preset alarm types that might be bound when modeling the left-side terminals include: cabinet AC phase A circuit breaker tripped, cabinet phase B circuit breaker tripped, cabinet phase C circuit breaker tripped, etc. Preset alarm types that might be bound when modeling the right-side terminals include: cabinet DC phase A circuit breaker tripped, cabinet DC phase B circuit breaker tripped, etc. So, when the alarm type is cabinet AC phase A circuit breaker tripped... When the alarm type is present in the preset alarm types bound during the modeling of the left terminal, the terminal corresponding to the circuit breaker on the left can be used as the first target terminal. Then, backtracking convergence is performed starting from the first target terminal. When the alarm type is that the cabinet DC B circuit breaker is open, and the alarm type is present in the preset alarm types bound during the modeling of the right terminal, the terminal corresponding to the B circuit breaker on the right can be used as the first target terminal. Then, backtracking convergence is performed starting from the first target terminal until the root cause device and root cause alarm are obtained.

[0091] When the parent device of an alarm device binds a preset alarm type to its upper-level terminal model, that is, when the terminal model corresponding to the alarm device is not bound to a preset alarm type, but the terminal model corresponding to the parent device and the upper-level device of the parent device is bound to a preset alarm type, the alarm type corresponding to the alarm device can be compared with the preset alarm type. When the preset alarm type exists, the terminal bound to the alarm type is taken as the second target terminal, and backtracking convergence is performed starting from the second target terminal to obtain the root cause device and root cause alarm corresponding to the alarm type. For example, if the B-circuit distribution drawer trips, the automatic transfer switch connected to the integrated distribution cabinet will generate a B-circuit trip alarm. Then, the automatic transfer switch will switch to A-circuit, and the A-circuit distribution drawer will trip again, generating an A-circuit trip alarm. In this case, for the A-circuit trip alarm, the alarm type should converge from the preset alarm type bound to the terminal of the integrated distribution cabinet to the A-circuit distribution drawer. Similarly, for the B-circuit trip alarm, the alarm type should converge from the preset alarm type bound to the terminal of the integrated distribution cabinet to the B-circuit distribution drawer.

[0092] When neither the alarm device nor the parent device has a preset alarm type bound during terminal modeling, the alarm times corresponding to multiple root devices associated with the alarm device can be obtained, and the root device corresponding to the earliest alarm time can be taken as the root cause device, and the alarm type corresponding to that root device can be taken as the root cause alarm.

[0093] It is worth noting that in power systems, for devices composed of multiple identical components, alarm convergence is performed on the device as the object of alarm convergence, not on the individual components within the device. This simplifies drawing and reduces the workload of digital modeling. However, when providing feedback to maintenance personnel and displaying relevant alarm convergence information, the components that make up the device will be displayed as the convergence object. For example, if a power system contains a battery pack composed of a large number of individual cells, the object of alarm convergence for all alarm information in the power system is the battery pack, not the individual cells. Only when displaying the data can the individual cells be displayed as the convergence object.

[0094] In one embodiment of this application, after determining the root cause device and root cause alarm corresponding to each alarm device according to the convergence rule corresponding to the target alarm scenario, the root cause alarm and root cause alarm can be stored in a storage medium and fed back to the operation and maintenance personnel so that the operation and maintenance personnel can accurately locate the device to be repaired in the data center, improve the operation and maintenance efficiency, and ensure the normal operation of the power distribution system.

[0095] In one embodiment of this application, since alarms are continuously generated before maintenance personnel perform repairs, after determining the root cause device and root cause alarm based on the alarm information set, a re-evaluation of alarm storms can be performed based on all alarms under each root cause device. If it is determined that an alarm storm does not exist, alarm convergence is not performed on the alarm information corresponding to that root cause device. If it is determined that an alarm storm still exists, alarm convergence is performed on all alarm information corresponding to that root cause device that can be considered root cause alarms, and the most accurate target root cause alarm is determined from them. When determining whether an alarm storm exists, the judgment method used is the same as the method for judging alarm storms before determining the root cause device label. By obtaining the number of alarms and alarm time corresponding to each root cause device, and then judging whether the number of alarm information within a preset time period is greater than or equal to a first threshold based on the number of alarms and alarm time, if yes, it is determined that an alarm storm still exists; if no, it is determined that an alarm storm does not exist. When an alarm storm is determined to persist, a root cause alarm list can be formed based on all candidate root cause alarms corresponding to the root cause device. This list includes not only the candidate root cause alarms but also their corresponding alarm levels and alarm times. When determining the target root cause alarm corresponding to the root cause device, this alarm level and alarm time can be used. Specifically, if the root cause alarm list contains a root cause alarm with the highest alarm level, that alarm is designated as the target root cause alarm. If all root cause alarms in the list have the same alarm level, the root cause alarm with the earliest alarm time is designated as the target root cause alarm. For example, if the root cause alarm list includes two root cause alarms: circuit breaker tripping and switch opening, if the alarm level of circuit breaker tripping is higher than that of switch opening, even if the alarm time of circuit breaker tripping is later than that of switch opening, circuit breaker tripping will be used as the target root cause alarm. If the alarm level of circuit breaker tripping is the same as that of switch opening, but the alarm time of circuit breaker tripping is later than that of switch opening, then switch opening will be used as the target root cause alarm.

[0096] By re-evaluating alarm storms in alarm information from each root cause device, and obtaining the corresponding root cause device and target root cause alarms when it is determined that the alarm storm still exists, the accuracy is higher than that of obtaining root cause devices and root cause alarms solely based on scenario policies.

[0097] In one embodiment of this application, after determining the root cause device and target root cause alarm through alarm storming, the determined root cause device and target root cause alarm can be stored in a storage medium, and then fed back to the operation and maintenance personnel through active push and request methods. Active push means that when the alarm console is open, the root cause device and root cause alarm are pushed to the alarm console for operation and maintenance personnel to view. Active push can be based on the WebSocket protocol, but other types of protocols can also be used; this embodiment of the application does not specifically limit this. Request method means that after receiving an alarm convergence information retrieval request from the operation and maintenance personnel, the determined root cause device and root cause alarm are sent to the operation and maintenance personnel for their viewing.

[0098] Figure 9 This diagram illustrates the interface for alarm convergence information, such as... Figure 9 As shown, the alarm convergence information includes alarm level, root cause device type, alarm type, alarm description, number of derived alarms, and earliest detection time. According to the number of derived alarms, a total of 604 alarm messages occurred, of which device 1 had 430 alarm messages and device 2 had 174 alarm messages. The analysis shows that the root cause alarms of device 1 and device 2 are both circuit breaker tripping, and the corresponding root cause devices are both high-voltage feeder cabinets. The alarm convergence information also includes multiple operation items, such as power line diagram, transfer event, and shutdown. By triggering the corresponding operation controls, the corresponding page can be opened. For example, triggering the power line diagram can display the alarm convergence information on the power line diagram.

[0099] To view alarm statistics, you can trigger an action on the number of derived alarms to display an interface diagram containing an alarm statistics table and a root cause device alarm list. Figure 10 This diagram illustrates an interface containing convergence information, including an alarm statistics table and a root cause device alarm list. Figure 10 As shown, the alarm convergence information includes alarm quantity 1001, alarm statistics 1002, and root cause device alarm list 1003. The number of alarms is the same as the number of derived alarms triggered. The alarm statistics record the alarm type, device type, and corresponding alarm quantity for all alarms. For example, the alarm type is "rectifier module fault alarm", the corresponding device type is REC, and the alarm quantity is 32, etc. The root cause device alarm list records the alarm level, device number, alarm type, alarm time, and specific operation. For example, an alarm with an alarm level of level 1 has an alarm type of "circuit breaker tripping" and an alarm time of 2022-01-04 15:19:01. By triggering the details control in the operation bar, the alarm details corresponding to the root cause device can be expanded.

[0100] The alarm convergence method in this application embodiment can be applied to any system involving electrical connections, such as power transmission systems, power distribution systems, etc., that make up a power system, or HVAC systems, computer rooms, various systems that make up a data center, etc. Taking a data center as an example, it may include IT warehouses, power distribution warehouses, diesel generator warehouses, air conditioning warehouses, water treatment warehouses, etc. Each warehouse is a system with electrical connections, and there are also electrical connections between each warehouse. Therefore, the alarm convergence method in this application embodiment can be used to converge alarms generated by these systems to obtain the corresponding root cause devices and root cause alarms, thereby helping maintenance personnel to locate and repair faulty devices more quickly and accurately, ensuring the normal operation of the system, and avoiding impacts on life and the economy.

[0101] Next, taking alarm convergence of alarms generated in the air conditioning warehouse in the data center as an example, the alarm convergence method in this application embodiment will be specifically explained.

[0102] The air conditioning unit is connected to the mains power supply. After the mains power is connected, it is connected to the air conditioner through equipment such as transformers and circuit breakers to provide power for the air conditioner to operate. If a power anomaly occurs during the operation of the air conditioning unit, it will cause a series of devices on the related links to issue a large number of alarms in a short period of time. After a large number of alarm messages appear, it is necessary to converge the alarm messages, eliminate irrelevant, duplicate and non-serious alarm interference, and help maintenance personnel quickly and accurately locate the root cause device and root cause alarm.

[0103] The system related to the alarm convergence method in the embodiments of this application involves multiple data services, and alarm convergence can be achieved by calling different services. Figure 11 This diagram illustrates the process of calling different services to achieve alarm convergence, such as... Figure 11 As shown, the alarm convergence process is as follows:

[0104] After receiving a large number of alarm messages uploaded by the air conditioning warehouse, the alarm messages can be stored in message queue 1101. Then, the alarm storm service 1102 can be called to consume the real-time alarm messages from the message queue. The message queue can be a message queue built on any distributed message publish / subscribe delivery platform, such as a message queue built on Kafka, Pulsar, RocketMQ, RabbitMQ, NSQ, etc.

[0105] Next, it can be determined whether the alarm information participates in alarm convergence and whether it constitutes an alarm storm. When it is determined that the alarm information participates in alarm convergence and an alarm storm has occurred, an alarm information set is constructed based on all alarm information belonging to the same alarm storm. The alarm information set is then used as input to call the convergence scenario service 1103 to label all alarm devices that have generated alarms with candidate root cause device tags. Specifically, all alarm types corresponding to each alarm device in the alarm information set can be compared with the root cause alarm types in the root cause alarm set and the non-root cause alarm types in the non-root cause alarm sets. If the alarm device matches the root cause alarm type, it is marked as a candidate root cause device. If it matches the non-root cause alarm type, it is marked as a non-root cause device. If it does not match either the root cause alarm type or the non-root cause alarm type, the real-time device metrics service 1104 can be called to obtain the device status corresponding to the alarm device. Then, the root cause device label corresponding to the alarm device is determined according to the alarm type, device status and root cause alarm set or non-root cause alarm set. In other words, all alarm devices will be labeled as candidate root cause devices or non-root cause devices.

[0106] Next, a request can be constructed based on the alarm device and its corresponding root cause device label to request the root cause calculation service 1105. The root cause calculation service 1105 can obtain the corresponding device relationship graph from the local cache or graph storage medium S1, and then construct a directed acyclic graph based on the device relationship graph. Based on the directed acyclic graph and the root cause device labels of each alarm device, the parent device and root device of each alarm device are determined. The root cause calculation service 1105 needs to call the graph data service 1106 to obtain the corresponding device relationship graph from the graph storage medium. Furthermore, the device relationship graphs stored in the graph storage medium are formed by the user through digital modeling service 1107 for different power network system architectures. The digitally modeled device relationship graphs are also associated with the devices in the data center through the object model 1108. To verify the correctness of the modeled device relationship graph, the simulation verification service 1109 can be called to verify the device relationship graph.

[0107] For the same alarm device, there may be one or more parent devices and root devices. Therefore, the target alarm scenario can be determined based on the parent device and root device corresponding to the alarm device. Then, alarm convergence is performed according to the convergence rules corresponding to the target alarm scenario to obtain the root cause device and the corresponding root cause alarm. The result is returned to the alarm storm service 1102 so that the alarm convergence information can be stored in the convergence data storage medium S2 through the alarm storm service 1102.

[0108] To further ensure the accuracy of alarm convergence, alarm information corresponding to each identified root cause device can be re-acquired, and alarm storms can be re-evaluated. If an alarm storm still exists, a candidate root cause alarm list is constructed based on all alarm information corresponding to each root cause device. The target root cause alarm corresponding to the root cause device is then determined based on the alarm level and alarm time of each candidate root cause alarm in the candidate root cause alarm list. After obtaining the target root cause alarm corresponding to the root cause device, the alarm convergence information can be returned to the alarm storm service 1102, which stores the alarm convergence information in the convergence data storage medium S2. Maintenance personnel can log in to the alarm workbench through a terminal device, call the convergence service 1110 to obtain the alarm convergence information from the convergence data storage medium S2, and perform fault location and repair on the air conditioning unit based on the obtained alarm convergence information.

[0109] The alarm convergence method in this application, after acquiring the alarm information set, determines the root cause device label corresponding to each alarm device in the alarm information set according to a first rule; then, it determines the parent device and root device corresponding to each alarm device according to the device relationship graph corresponding to the alarm devices and the root cause device label corresponding to each alarm device; finally, it determines the target alarm scenario corresponding to each alarm device according to the parent device and root device corresponding to each alarm device, and determines the root cause device and root cause alarm corresponding to each alarm device according to the convergence rule corresponding to the target alarm scenario. This application, on the one hand, can perform alarm convergence based on digital modeling, graph computation, and scenario strategies, improving the efficiency and accuracy of alarm convergence; on the other hand, it can comprehensively cover various system architectures in data centers, adapt to changes in different power network systems, and improve the universality of alarm convergence; furthermore, it avoids the problems of collecting large amounts of training data for model training and unstable model performance.

[0110] It should be noted that although the steps of the method in this application are described in a specific order in the accompanying drawings, this does not require or imply that the steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0111] The following describes an embodiment of the apparatus described in this application, which can be used to execute the alarm convergence method in the above embodiments of this application. Figure 12 A schematic block diagram of the alarm convergence device provided in an embodiment of this application is shown. Figure 12 As shown, the alarm convergence device 1200 includes: a tag generation module 1210, a graph analysis module 1220, and a root cause determination module 1230, specifically:

[0112] The tag generation module 1210 is used to acquire an alarm information set and determine the root cause device tag corresponding to each alarm device in the alarm information set according to a first rule; the graph analysis module 1220 is used to acquire a device relationship graph corresponding to the alarm devices and determine the parent device and root device corresponding to each alarm device based on the device relationship graph and the root cause device tag; the root cause determination module 1230 is used to determine the target alarm scenario corresponding to each alarm device according to the parent device and root device corresponding to each alarm device, and determine the root cause device and root cause alarm corresponding to each alarm device according to the convergence rule corresponding to the target alarm scenario.

[0113] In some embodiments of this application, the alarm information set further includes alarm types corresponding to each alarm device; based on the above technical solutions, the tag generation module 1210 includes: a first comparison unit, used to poll each alarm device and compare the alarm type corresponding to the alarm device with the root cause alarm types in the root cause alarm set; a first marking unit, used to mark the alarm device as a candidate root cause device when there is a root cause alarm type in the root cause alarm set that is the same as the alarm type; and a second marking unit, used to determine the root cause device tag corresponding to the alarm device based on the non-root cause alarm set when there is no root cause alarm type in the root cause alarm set that is the same as the alarm type.

[0114] In some embodiments of this application, based on the above technical solutions, the second marking unit includes: a second comparison unit, used to compare the alarm type corresponding to the alarm device with the non-root cause alarm types in the non-root cause alarm set; a third marking unit, used to mark the alarm device as a non-root cause device when there is a non-root cause alarm type in the non-root cause alarm set that is the same as the alarm type; an indicator acquisition unit, used to acquire a real-time device indicator corresponding to the alarm device when there is no non-root cause alarm type in the non-root cause alarm set that is the same as the alarm type; and a fourth marking unit, used to determine the root cause device label corresponding to the alarm device based on the real-time device indicator, the alarm type, and the root cause alarm set, or based on the real-time device indicator, the alarm type, and the non-root cause alarm set.

[0115] In some embodiments of this application, based on the above technical solutions, the fourth marking unit is configured to: determine the alarm type to be processed according to the real-time device indicators and the alarm type; when there is a root cause alarm type in the root cause alarm set that is the same as the alarm type to be processed, mark the alarm device as a candidate root cause device; when there is no root cause alarm type in the root cause alarm set that is the same as the alarm type to be processed, mark the alarm device as a non-root cause device; or, when there is a non-root cause alarm type in the non-root cause alarm set that is the same as the alarm type to be processed, mark the alarm device as a non-root cause device; when there is no non-root cause alarm type in the non-root cause alarm set that is the same as the alarm type to be processed, mark the alarm device as a candidate root cause device.

[0116] In some embodiments of this application, based on the above technical solutions, the graph analysis module 1220 is configured to: obtain a device relationship graph corresponding to the alarm device from a local cache or graph storage medium; construct a directed acyclic graph based on the device relationship graph; and determine the parent device and root device corresponding to each alarm device based on the directed acyclic graph and the root cause device label corresponding to each alarm device.

[0117] In some embodiments of this application, based on the above technical solutions, the root cause determination module 1230 includes: an acquisition unit, configured to acquire the number of parent devices and the number of root devices; a first scenario determination unit, configured to use a first alarm scenario as the target alarm scenario when the number of parent devices and the number of root devices are both one; and a second scenario determination unit, configured to use a second alarm scenario as the target alarm scenario when the number of parent devices and the number of root devices are both multiple.

[0118] In some embodiments of this application, based on the above technical solutions, the first scenario determination unit is configured as follows: when the target alarm scenario is the first alarm scenario, the root device corresponding to the alarm device is taken as the root cause device, and the alarm type corresponding to the root cause device is taken as the root cause alarm.

[0119] In some embodiments of this application, based on the above technical solutions, the second scenario determination unit includes: a judgment unit, configured to, when the target alarm scenario is the second alarm scenario, acquire terminals related to the alarm device and the parent device, and determine whether there is a preset alarm type corresponding to the terminal; a first root cause determination unit, configured to, when it is determined that the preset alarm type exists, determine the root cause device and root cause alarm corresponding to each of the alarm devices according to the preset alarm type and the convergence rule; and a second root cause determination unit, configured to, when it is determined that the preset alarm type does not exist, acquire the alarm time corresponding to each of the root devices, and take the root device corresponding to the earliest alarm time as the root cause device and the alarm type corresponding to the root device as the root cause alarm.

[0120] In some embodiments of this application, based on the above technical solutions, the second root cause determination unit is configured as follows: when both the terminals corresponding to the alarm device and the parent device have corresponding preset alarm types, the alarm type is compared with the preset alarm type to determine a first target terminal; convergence is performed starting from the first target terminal to obtain the root cause device and the root cause alarm; and when the terminal corresponding to the alarm device does not have a corresponding preset alarm type, but the terminals corresponding to the parent device and the upstream device corresponding to the parent device have corresponding preset alarm types, the alarm type is compared with the preset alarm type to determine a second target terminal; convergence is performed starting from the second target terminal to obtain the root cause device and the root cause alarm.

[0121] In some embodiments of this application, based on the above technical solutions, the alarm convergence device 1200 is configured to: acquire all alarm information within a preset time period before acquiring the alarm information set, and acquire the number of the alarm information; when the number of the alarm information is greater than or equal to a first threshold, determine that an alarm storm has occurred, and generate the alarm information set according to the alarm information within the preset time period.

[0122] In some embodiments of this application, based on the above technical solutions, the alarm convergence device 1200 is further configured to: when receiving new alarm information, obtain the time interval between the alarm time of the new alarm information and the latest alarm time corresponding to the alarm information in the alarm information set; when the time interval is less than a second threshold, add the new alarm information to the alarm information set.

[0123] In some embodiments of this application, based on the above technical solutions, the alarm convergence device 1200 further includes: an acquisition module, configured to acquire the number of alarms and alarm time corresponding to each of the root cause devices after determining the root cause device and root cause alarm corresponding to each of the alarm devices according to the convergence rule corresponding to the target alarm scenario; a judgment module, configured to determine whether each of the root cause devices is experiencing an alarm storm based on the number of alarms and the alarm time; and a determination module, configured to acquire a root cause alarm list constructed based on the candidate root cause alarms corresponding to the root cause device when it is determined that an alarm storm has occurred, and determine the target root cause alarm corresponding to the root cause device based on the root cause alarm list.

[0124] In some embodiments of this application, based on the above technical solutions, the determining module is configured to: when there is a root cause alarm with the highest alarm level in the root cause alarm list, take the root cause alarm with the highest alarm level as the target root cause alarm; and when each root cause alarm in the root cause alarm list has the same alarm level, take the root cause alarm corresponding to the earliest alarm time as the target root cause alarm.

[0125] In some embodiments of this application, based on the above technical solutions, the alarm convergence device 1200 is further configured to: digitally model the devices in the data center to obtain the device relationship diagram.

[0126] The specific details of the alarm convergence device provided in the various embodiments of this application have been described in detail in the corresponding method embodiments, and will not be repeated here.

[0127] Figure 13 This schematically illustrates a computer system architecture block diagram for an electronic device used to implement embodiments of the present application. The electronic device may be, for example... Figure 1 The terminal device 101 and server 102 shown are illustrated.

[0128] It should be noted that, Figure 13 The computer system 1300 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0129] like Figure 13As shown, the computer system 1300 includes a central processing unit (CPU) 1301, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 1302 or programs loaded from storage section 1308 into random access memory (RAM). The RAM 1303 also stores various programs and data required for system operation. The CPU 1301, ROM 1302, and RAM 1303 are interconnected via a bus 1304. An input / output interface 1305 (I / O interface) is also connected to the bus 1304.

[0130] In some embodiments, the following components are connected to the input / output interface 1305: an input section 1306 including a keyboard, mouse, etc.; an output section 1307 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 1308 including a hard disk, etc.; and a communication section 1309 including a network interface card such as a local area network card, modem, etc. The communication section 1309 performs communication processing via a network such as the Internet. A drive 1310 is also connected to the input / output interface 1305 as needed. A removable medium 1311, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 1310 as needed so that computer programs read from it can be installed into the storage section 1308 as needed.

[0131] Specifically, according to embodiments of this application, the processes described in the various method flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 1309, and / or installed from removable medium 1311. When the computer program is executed by central processing unit 1301, it performs various functions defined in the system of this application.

[0132] It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium, a computer-readable medium, or any combination of the above. A computer-readable medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such transmitted data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The computer-readable signal medium can also be any computer-readable medium other than a computer-readable medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0133] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0134] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to the embodiments of this application, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0135] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, and includes several instructions to cause an electronic device to execute the method according to the embodiments of this application.

[0136] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein.

[0137] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. An alarm convergence method, characterized by, include: Obtain an alarm information set, and determine the root cause device label corresponding to each alarm device in the alarm information set according to a first rule. The first rule is related to the alarm type corresponding to the alarm device, and the root cause device label is used to indicate whether the corresponding alarm device is a candidate root cause device or a non-root cause device. Obtain the device relationship diagram corresponding to the alarm device, and determine the parent device and root device corresponding to each alarm device based on the device relationship diagram and the root cause device label; The target alarm scenario corresponding to each alarm device is determined based on the number of parent devices and root devices corresponding to each alarm device, and the root cause device and root cause alarm corresponding to each alarm device are determined based on the convergence rule corresponding to the target alarm scenario; wherein, the target alarm scenario includes a first alarm scenario and a second alarm scenario, the first alarm scenario is a scenario in which there is one or more paths between the alarm device and the root device and the number of the root device is one, and the second alarm scenario is a scenario in which there are multiple paths between the alarm device and the root device and the number of the root devices is multiple.

2. The method of claim 1, wherein, The alarm information set also includes alarm types corresponding to each of the alarm devices; The step of determining the root cause device tag corresponding to each alarm device in the alarm information set according to the first rule includes: Poll each of the alarm devices and compare the alarm type corresponding to the alarm device with the root cause alarm type in the root cause alarm set; When the root cause alarm set contains a root cause alarm type that is the same as the alarm type, the alarm device is marked as a candidate root cause device. When there is no root cause alarm type with the same alarm type in the root cause alarm set, the root cause device tag corresponding to the alarm device is determined according to the non-root cause alarm set.

3. The method of claim 2, wherein, The step of determining the root cause device tag corresponding to the alarm device based on the non-root cause alarm set includes: The alarm type corresponding to the alarm device is compared with the non-root cause alarm types in the non-root cause alarm set; When the non-root cause alarm set contains a non-root cause alarm type that is the same as the alarm type, the alarm device is marked as a non-root cause device. When there is no non-root cause alarm type with the same alarm type in the non-root cause alarm set, obtain the real-time device metrics corresponding to the alarm device; The root cause device label corresponding to the alarm device is determined based on the real-time device metrics, the alarm type, and the root cause alarm set, or based on the real-time device metrics, the alarm type, and the non-root cause alarm set.

4. The method of claim 3, wherein, The step of determining the root cause device tag corresponding to the alarm device based on the real-time device metrics, the alarm type, and the root cause alarm set, or based on the real-time device metrics, the alarm type, and the non-root cause alarm set, includes: The alarm type to be processed is determined based on the real-time device indicators and the alarm type. When the root cause alarm set contains a root cause alarm type that is the same as the alarm type to be processed, the alarm device is marked as a candidate root cause device. When there is no root cause alarm type in the root cause alarm set that is the same as the alarm type to be processed, the alarm device is marked as a non-root cause device; or When the non-root cause alarm set contains a non-root cause alarm type that is the same as the alarm type to be processed, the alarm device is marked as a non-root cause device. When there is no non-root cause alarm type in the non-root cause alarm set that is the same as the alarm type to be processed, the alarm device is marked as a candidate root cause device.

5. The method of claim 1, wherein, The step of obtaining the device relationship diagram corresponding to the alarm device, and determining the parent device and root device corresponding to each alarm device based on the device relationship diagram and the root cause device tag, includes: Obtain the device relationship diagram corresponding to the alarm device from the local cache or graph storage medium; A directed acyclic graph is constructed based on the device relationship diagram. The parent device and root device corresponding to each alarm device are determined based on the directed acyclic graph and the root cause device label corresponding to each alarm device.

6. The method of claim 1, wherein, The step of determining the target alarm scenario corresponding to each alarm device based on the number of parent devices and the number of root devices corresponding to each alarm device includes: Obtain the number of parent devices and the number of root devices; When the number of parent devices and root devices is one, the first alarm scenario is taken as the target alarm scenario; When there are multiple parent devices and multiple root devices, the second alarm scenario is used as the target alarm scenario.

7. The method according to claim 6, characterized in that, When the target alarm scenario is the first alarm scenario, determining the root cause device and root cause alarm corresponding to each alarm device according to the convergence rule corresponding to the target alarm scenario includes: The root device corresponding to the alarm device is designated as the root cause device, and the alarm type corresponding to the root cause device is designated as the root cause alarm.

8. The method according to claim 6, characterized in that, When the target alarm scenario is the second alarm scenario, determining the root cause device and root cause alarm corresponding to each alarm device according to the convergence rule corresponding to the target alarm scenario includes: Obtain the terminals associated with the alarm device and the parent device, and determine whether there is a preset alarm type corresponding to the terminal; When it is determined that the preset alarm type exists, the root cause device and root cause alarm corresponding to each alarm device are determined according to the preset alarm type and the convergence rule. When it is determined that the preset alarm type does not exist, the alarm time corresponding to each root device is obtained, and the root device corresponding to the earliest alarm time is taken as the root cause device, and the alarm type corresponding to the root device is taken as the root cause alarm.

9. The method according to claim 8, characterized in that, The step of determining the root cause device and root cause alarm corresponding to each alarm device according to the preset alarm type and the convergence rule includes: When both the alarm device and the parent device have corresponding preset alarm types, the alarm type is compared with the preset alarm type to determine the first target terminal; Convergence is performed starting from the first target terminal to obtain the root cause device and the root cause alarm; and When there is no corresponding preset alarm type for the terminal corresponding to the alarm device, but there is a corresponding preset alarm type for the terminal corresponding to the parent device and the upper-level device corresponding to the parent device, the alarm type is compared with the preset alarm type to determine the second target terminal. Convergence is performed starting from the second target terminal to obtain the root cause device and the root cause alarm.

10. The method according to claim 1, characterized in that, Before acquiring the alarm information set, the method further includes: Obtain all alarm information within a preset time period, and obtain the number of alarm information; When the number of alarm messages is greater than or equal to the first threshold, an alarm storm is determined to have occurred, and the alarm message set is generated based on the alarm messages within the preset time period.

11. The method according to claim 10, characterized in that, The method further includes: When a new alarm message is received, the time interval between the alarm time of the new alarm message and the latest alarm time corresponding to the alarm message in the alarm message set is obtained; When the time interval is less than the second threshold, the newly added alarm information is added to the alarm information set.

12. The method according to claim 1, characterized in that, After determining the root cause device and root cause alarm corresponding to each alarm device according to the convergence rule corresponding to the target alarm scenario, the method further includes: Obtain the number of alarms and alarm time corresponding to each of the root cause devices; Determine whether an alarm storm has occurred in each of the root cause devices based on the number of alarms and the alarm time. When an alarm storm is detected, a root cause alarm list is obtained based on the candidate root cause alarms corresponding to the root cause device, and the target root cause alarm corresponding to the root cause device is determined based on the root cause alarm list.

13. The method according to claim 12, characterized in that, The root cause alarm list includes multiple root cause alarms, the alarm level corresponding to each root cause alarm, and the alarm time. The step of determining the target root cause alarm corresponding to the root cause device based on the root cause alarm list includes: When there is a root cause alarm with the highest alarm level in the root cause alarm list, the root cause alarm with the highest alarm level shall be used as the target root cause alarm. as well as When all root cause alarms in the root cause alarm list have the same alarm level, the root cause alarm corresponding to the earliest alarm time will be used as the target root cause alarm.

14. The method according to claim 1, characterized in that, Before acquiring the alarm information set, the method further includes: Digital modeling is performed on the equipment in the data center to obtain the equipment relationship diagram.

15. An alarm convergence device, characterized in that, include: The tag generation module is used to acquire an alarm information set and determine the root cause device tag corresponding to each alarm device in the alarm information set according to a first rule. The first rule is related to the alarm type corresponding to the alarm device. The root cause device tag is used to indicate whether the corresponding alarm device is a candidate root cause device or a non-root cause device. The graph analysis module is used to obtain a device relationship graph corresponding to the alarm device, and to determine the parent device and root device corresponding to each alarm device based on the device relationship graph and the root cause device label; The root cause determination module is used to determine the target alarm scenario corresponding to each alarm device based on the number of parent devices and the number of root devices corresponding to each alarm device, and to determine the root cause device and root cause alarm corresponding to each alarm device based on the convergence rule corresponding to the target alarm scenario; wherein, the target alarm scenario includes a first alarm scenario and a second alarm scenario, the first alarm scenario is a scenario in which there is one or more paths between the alarm device and the root device and the number of root devices is one, and the second alarm scenario is a scenario in which there are multiple paths between the alarm device and the root device and the number of root devices is multiple.

16. A computer-readable medium having a computer program stored thereon, which, when executed by a processor, implements the alarm convergence method according to any one of claims 1 to 14.

17. An electronic device, characterized in that, include: processor; as well as Memory, used to store instructions; The processor executes the instructions stored in the memory to implement the alarm convergence method according to any one of claims 1 to 14.

18. A computer program product, characterized in that, The computer program product includes computer instructions that, when executed on a computer, cause the computer to perform the alarm convergence method according to any one of claims 1 to 14.

Images