System and method for automatically generating data center network maps with automatic alert consolidation

Abstract

The present application discloses a system and method for automatically generating a data center network map for automatic alarm merging. According to at least one aspect of the present invention, a system for automatically generating a data center network map for automatic alarm merging is provided, comprising a plurality of devices and at least one computing device communicatively coupled to each of the devices, the at least one computing device being configured to: receive operation data from each of the devices, the operation data indicating at least one of a power path, a cooling or temperature zone, or a communication path; determine a device relationship between each of the devices based on the operation data; receive a corresponding alarm from each of the devices; determine an alarm relationship between at least two of the plurality of alarms; merge the plurality of alarms into a merged alarm based on the determined device relationship and based on the determined alarm relationship; and provide the merged alarm to a user.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority under 35 USC §119(e) to U.S. Provisional Application Serial No. 62 / 743,986, filed on October 10, 2018, entitled “NETWORK INFERENCE FOR SYSTEM AVAILABILITY IN DATA CENTERS AND APPLICATIONS,” which is hereby incorporated by reference in its entirety. Background of the Invention

[0003] 1. Field of the Invention

[0004] At least one example consistent with the invention generally relates to monitoring devices and determining relationships between the devices in a data center.

[0005] 2. Discussion of related technologies

[0006] It is known to provide a data center with multiple interconnected devices, including uninterruptible power supplies, power distribution units, rack power distribution units, etc. The devices may be related by one of several parameters, including power, temperature, and communicability. For example, certain devices within a data center may be related by a shared power path, and may be unrelated to other devices within the data center that do not share a power path with the device under consideration.

[0007] Overview

[0008] According to at least one aspect of the present invention, a system is provided, which includes a plurality of interrelated devices and at least one computing device communicatively coupled to each of the plurality of interrelated devices, the at least one computing device being configured to receive data from each of the plurality of interrelated devices, determine a device relationship between each of the plurality of interrelated devices based on the received data, receive a corresponding alarm among a plurality of alarms from each of the plurality of devices, determine a relationship between at least two of the plurality of alarms based on the plurality of alarms, merge the plurality of alarms into a merged alarm based on the determined device relationship and based on the relationship between the at least two alarms, and provide the merged alarm to a user.

[0009] In one embodiment, the device relationship is based on at least one of a power path, a cooling or temperature zone, and a communication path. In an embodiment, the plurality of interrelated devices includes a power device, and wherein the data includes at least one of current data representing current provided by the power device, power data representing power provided by the power device, and voltage data representing voltage provided by the power device. In an embodiment, the at least one computing device is further configured to normalize the data with respect to a single polling frequency when determining the device relationship.

[0010] In at least one embodiment, the at least one computing device is further configured to round the data measurements to the nearest period of the single polling frequency when normalizing the data with respect to the single polling frequency, and to interpolate the data measurements for each period of the single polling frequency for which no data measurements exist. In one embodiment, the at least one computing device is further configured to perform at least one of a Bayesian network estimation technique, a correlation coefficient technique, a constrained regression optimization technique, and an ordinary least squares technique when determining the device relationships to generate a device map indicating the relationship between each of the plurality of devices.

[0011] In an embodiment, at least one computing device is further configured to: generate a first subset of alerts in the plurality of alerts when determining the relationship, the first subset of alerts being received from the plurality of devices at a first time; and generate a second subset of alerts in the plurality of alerts, the second subset of alerts being received from the plurality of devices at a second time, and the first time being different from the second time. In an embodiment, at least one computing device is further configured to determine a plurality of association rules when determining the relationship, the plurality of association rules indicating a relationship between the first subset of alerts and the second subset of alerts.

[0012] In one embodiment, the at least one computing device is further configured to evaluate the plurality of association rules when determining the relationship to determine an association rule of the plurality of association rules having a highest likelihood of representing a relationship between the first subset of alerts and the second subset of alerts. In an embodiment, the at least one computing device is further configured to present the association rule to a user when determining the relationship and receive a tag for the association rule from the user.

[0013] According to one aspect of the present invention, a method is provided, which includes the following actions: receiving data from each of a plurality of interrelated devices, determining a device relationship between each of the plurality of devices based on the received data, receiving a corresponding alarm among a plurality of alarms from each of the plurality of devices, determining a relationship between at least two of the plurality of alarms based on the plurality of alarms, merging the plurality of alarms into a merged alarm based on the determined device relationship and based on the relationship between the at least two alarms, and providing the merged alarm to a user.

[0014] In one embodiment, the device relationship is based on at least one of a power path, a cooling or temperature zone, and a communication path. In an embodiment, the data includes at least one of current data representing a current provided by a power device in the plurality of devices, power data representing a power provided by the power device, and voltage data representing a voltage provided by the power device. In an embodiment, determining the device relationship includes normalizing the data with respect to a single polling frequency. In some embodiments, normalizing the data with respect to the single polling frequency includes rounding the data measurements to the nearest period of the single polling frequency and interpolating the data measurements for each period of the single polling frequency for which no data measurements exist.

[0015] In an embodiment, determining the device relationship further comprises performing at least one of a Bayesian network estimation technique, a correlation coefficient technique, an ordinary least squares technique, and a constrained regression optimization technique to generate a device map indicating a relationship between each of the plurality of devices. In an embodiment, determining the relationship comprises: generating a first subset of alarms in the plurality of alarms, the first subset of alarms being received from the plurality of devices at a first time; and comprising generating a second subset of alarms in the plurality of alarms, the second subset of alarms being received from the plurality of devices at a second time, and the first time being different from the second time.

[0016] In one embodiment, determining the relationship further comprises determining a plurality of association rules, the plurality of association rules indicating a relationship between the first subset of alerts and the second subset of alerts. In some embodiments, determining the relationship further comprises evaluating the plurality of association rules to determine an association rule in the plurality of association rules having a highest likelihood of indicating a relationship between the first subset of alerts and the second subset of alerts. In an embodiment, determining the relationship further comprises presenting the association rules to a user, and receiving a tag for the association rule from the user.

[0017] According to one aspect, a system for automatically generating a data center network map for automatic alarm consolidation is provided, including a plurality of interconnected devices and at least one computing device communicatively coupled to each of the plurality of interconnected devices, the at least one computing device being configured to: receive operational data from each of the plurality of interconnected devices, the operational data indicating at least one of a power path, a cooling or temperature zone, or a communication path; determine a device relationship between each of the plurality of interconnected devices based on the operational data; receive a corresponding alarm of a plurality of alarms from each of the plurality of interconnected devices; determine an alarm relationship between at least two of the plurality of alarms based on the plurality of alarms; merge the plurality of alarms into a merged alarm based on the determined device relationship and based on the determined alarm relationship; and provide the merged alarm to a user.

[0018] In one example, the plurality of interrelated devices includes an electrical device, and wherein the operational data includes at least one of current data representing a current provided by the electrical device, power data representing a power provided by the electrical device, or voltage data representing a voltage provided by the electrical device, or temperature data representing an ambient temperature of the electrical device provided by the electrical device. In some examples, the at least one computing device is further configured to normalize the operational data with respect to a single polling frequency when determining the device relationship. In at least one example, the at least one computing device is further configured to round the data measurements to the nearest period of the single polling frequency when normalizing the operational data with respect to the single polling frequency, and to interpolate the data measurements for each period of the single polling frequency for which no data measurements exist.

[0019] In some examples, at least one computing device is further configured to: perform at least one of a Bayesian network estimation technique, a correlation coefficient technique, a restricted regression optimization technique, or an ordinary least squares technique when determining the device relationship to generate a device map indicating the relationship between each device in the plurality of interrelated devices. In at least one example, at least one computing device is further configured to: generate a first subset of alarms in the plurality of alarms when determining the alarm relationship, the first subset of alarms being received from the plurality of interrelated devices at a first time; and generate a second subset of alarms in the plurality of alarms, the second subset of alarms being received from the plurality of interrelated devices at a second time, and the first time being different from the second time.

[0020] In an example, at least one computing device is further configured to determine a plurality of association rules when determining the alarm relationship, the plurality of association rules indicating a relationship between the first subset of alarms and the second subset of alarms. In various examples, at least one computing device is further configured to evaluate the plurality of association rules when determining the alarm relationship to determine an association rule of the plurality of association rules having a highest likelihood of representing a relationship between the first subset of alarms and the second subset of alarms. In at least one example, at least one computing device is further configured to present the association rules to a user when determining the alarm relationship and to receive a label for the association rule from the user.

[0021] According to one aspect, a non-transitory computer-readable medium is provided on which a computer-executable instruction sequence for automatically generating a data center network map for automatic alarm consolidation is stored, the computer-executable instruction sequence including instructions instructing at least one processor to perform the following operations: receiving operational data indicating at least one of a power path, a cooling or temperature zone, or a communication path from each of a plurality of interconnected devices; determining a device relationship between each of the plurality of interconnected devices based on the operational data; receiving a corresponding alarm from each of the plurality of interconnected devices; determining an alarm relationship between at least two of the plurality of alarms based on the plurality of alarms; merging the plurality of alarms into a merged alarm based on the determined device relationship and based on the determined alarm relationship; and providing the merged alarm to a user.

[0022] In various examples, the operational data includes at least one of current data representing current provided by an electrical device in a plurality of interrelated devices, power data representing power provided by the electrical device, or voltage data representing voltage provided by the electrical device, or temperature data representing ambient temperature of the electrical device provided by the electrical device. In at least one example, determining the device relationship includes normalizing the operational data with respect to a single polling frequency. In some examples, normalizing the operational data with respect to the single polling frequency includes rounding data measurements to the nearest period of the single polling frequency and interpolating data measurements for each period of the single polling frequency for which no data measurements exist.

[0023] In various examples, determining the device relationship also includes performing at least one of a Bayesian network estimation technique, a correlation coefficient technique, an ordinary least squares technique, or a constrained regression optimization technique to generate a device map indicating a relationship between each of the plurality of interrelated devices. In some examples, determining the alarm relationship includes generating a first subset of alarms in the plurality of alarms, the first subset of alarms being received from the plurality of interrelated devices at a first time; and generating a second subset of alarms in the plurality of alarms, the second subset of alarms being received from the plurality of interrelated devices at a second time, and the first time is different from the second time.

[0024] In at least one example, determining the alert relationship further includes determining a plurality of association rules indicating a relationship between the first subset of alerts and the second subset of alerts. In some examples, determining the alert relationship further includes evaluating the plurality of association rules to determine an association rule of the plurality of association rules having a highest likelihood of indicating a relationship between the first subset of alerts and the second subset of alerts. In one example, determining the alert relationship further includes presenting the association rules to a user and receiving a tag for the association rule from the user.

[0025] According to multiple aspects of the present disclosure, a method for automatically generating a data center network mapping for automatic alarm merging is provided, including: receiving operational data indicating at least one of a power path, a cooling or temperature zone, or a communication path from each of a plurality of interconnected devices; determining a device relationship between each of the plurality of interconnected devices based on the operational data; receiving a corresponding alarm from a plurality of alarms from each of the plurality of interconnected devices; determining an alarm relationship between at least two of the plurality of alarms based on the plurality of alarms; merging the plurality of alarms into a merged alarm based on the determined device relationship and based on the determined alarm relationship; and providing the merged alarm to a user.

[0026] According to multiple aspects of the present disclosure, a system for automatically generating a data center network map is provided, including: a plurality of interconnected devices and at least one computing device communicatively coupled to each of the plurality of interconnected devices, the at least one computing device being configured to: receive operational data indicating at least one of a power path, a cooling or temperature zone, or a communication path from each of the plurality of interconnected devices; determine a statistical probability of a connection based on the operational data and based on at least one of the power path, the cooling or temperature zone, or the communication path between each pair of devices in the plurality of interconnected devices; generate a device map indicating at least one predicted connection between at least one pair of devices in the plurality of interconnected devices based on the operational data; and provide the device map to a user.

[0027] In some examples, the plurality of interrelated devices include an electrical device, and wherein the operational data includes at least one of current data representing current provided by or to the electrical device, power data representing power provided by or to the electrical device, or voltage data representing voltage provided by or to the electrical device, or temperature data representing an ambient temperature of the electrical device provided by the electrical device. In various examples, the at least one computing device is further configured to normalize the operational data about a single polling frequency.

[0028] In at least one example, the at least one computing device is further configured to round the data measurements to the nearest period of the single polling frequency when normalizing the operational data with respect to the single polling frequency, and to interpolate the data measurements for each period of the single polling frequency for which no data measurements exist. In various examples, the at least one computing device is further configured to perform at least one of a Bayesian network estimation technique, a correlation coefficient technique, a constrained regression optimization technique, or an ordinary least squares technique when determining the statistical probability of a connection between each pair of devices. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] Various aspects of at least one embodiment are discussed below with reference to the accompanying drawings, which are not intended to be drawn to scale. The accompanying drawings are included to provide illustration and further understanding of the various aspects and embodiments, and are incorporated in and constitute a part of this specification, but are not intended as a definition of the limits of any particular embodiment. The accompanying drawings, together with the rest of the specification, are used to explain the principles and operation of the described and claimed aspects and embodiments. In the accompanying drawings, each identical or nearly identical component shown in various figures is represented by a like number. For the purpose of clarity, not every component may be labeled in every figure. In the drawings:

[0030] Figure 1 shows a schematic diagram of a data center according to an example;

[0031] Figure 2 shows a schematic diagram of an electronic equipment rack according to an example;

[0032] Figure 3A-3D shows a process for merging alerts according to an example;

[0033] Figure 4A-4C A process for determining equipment health and reliability according to an example is shown;

[0034] Figure 5A-Figure 5C A process for determining the impact of replacing and / or upgrading one or more devices according to one example is shown;

[0035] Figure 6A graph showing the results of p-value determination according to an embodiment;

[0036] Figure 7 A graph showing possible device relationships determined according to an embodiment;

[0037] Figure 8 is a block diagram of a computer system according to an embodiment.

[0038] Detailed Description of the Invention

[0039] The examples of the methods and systems discussed herein are not limited in application to the details of the structure and arrangement of the components set forth in the following description or shown in the accompanying drawings. The methods and systems can be implemented in other embodiments and can be practiced or executed in various ways. Examples of specific implementations are provided herein for illustrative purposes only and are not intended to be restrictive. In particular, the actions, components, elements, and features discussed with respect to any one or more examples are not intended to be excluded from similar effects in any other examples.

[0040] In addition, the words and terms used herein are for descriptive purposes and should not be considered limiting. Any reference to examples, embodiments, parts, elements, or actions of systems and methods mentioned herein in the singular may also include embodiments including the plural, and any reference to any embodiment, part, element, or action herein in the plural may also include embodiments including only the singular. References in the singular or plural are not intended to limit the presently disclosed systems or methods, their parts, actions, or elements. The use of "including," "comprising," "having," "including," and "involving" and variations thereof herein shall include the items listed thereafter and their equivalents as well as additional items.

[0041] References to "or" may be interpreted as inclusive, such that any item described using "or" may indicate any of the following: single, more than one, and all of the items described. Additionally, in the event of inconsistent usage of a term between this document and documents incorporated herein by reference, the usage of the term in the incorporated features supplements the usage of the term in this document; for irreconcilable differences, the usage of the term in this document controls.

[0042] As discussed above, it is known to provide a data center with multiple related devices. It may be beneficial to know the relationships between related devices. Continuing with the previous example, it may be beneficial to know that a UPS is related to an rPDU in terms of power paths. For example, and as discussed in more detail below, having information related to the relationships between devices may be beneficial for alarm filtering, determining the reliability and health of the equipment, determining the impact of replacing or upgrading components, determining equipment redundancy and capacity estimation, and providing a basis for any implemented control schemes.

[0043] In some traditional solutions, device relationships (e.g., device relationships in a data center) are mapped manually. For example, a trained operator may physically inspect the equipment and manually record the connections of the devices by inspecting the physical connections between the devices (e.g., via power cables). There are several drawbacks to manual mapping of device relationships. For example, manually mapping relationships may be time consuming and may require a skilled operator to perform. In addition, changes in device relationships are not automatically reflected in the device mapping. That is, after manually recording the connections, the operator must still take additional steps to manually update the device mapping, which is current only from the time the operator manually recorded the connections. Therefore, manually maintained device mappings may not provide reliable information because periodic manual updates are required and may not be current.

[0044] Devices may be related by one of several metrics (e.g., power, temperature, cooling, communication, physical location, or other metrics). For example, an uninterruptible power supply (UPS) may be related to a rack power distribution unit (rPDU) in terms of power paths (i.e., electrical connections through which power passes) because the UPS provides uninterruptible power to the rPDU. Therefore, embodiments relate to analyzing operational information (e.g., power, cooling, temperature, physical location, and / or communication information) to automatically identify device relationships based on network inference. Automatic network inference enables device network mapping to be generated regularly at a high frequency, thereby reducing the amount of time spent mapping devices and increasing the reliability of the generated device mapping. Therefore, the embodiments discussed herein are faster, cheaper, and more reliable in providing device mapping, which enables the generated device mapping to be used with greater efficiency. Device mapping can be used for various functions, including, for example, alarm filtering, determining the reliability and health of a device, determining the impact of replacing or upgrading components on the operation of other components, determining device redundancy and capacity estimation, and providing a basis for the implemented control scheme.

[0045] For purposes of clarity and illustration only, the various examples disclosed herein are directed to devices in a data center that are interconnected by power paths. The embodiments disclosed herein are applicable to various environments with multiple interconnected devices, and are not strictly limited to data center-based environments. As discussed above, devices may be related in terms of power, temperature, communication, physical location, or other shared parameters, and are not strictly limited to interconnections based on power paths. In addition, as used herein, "device relationship" may refer to the relationship between components and subcomponents of certain devices (such as sockets of an rPDU). Therefore, in the case where a UPS is coupled to a socket of an rPDU, the UPS and the rPDU may be interconnected devices in a shared device relationship in which the UPS shares a component sharing relationship with the rPDU.

[0046] In one embodiment, remote network inferences are determined based on asynchronous, incomplete, and unlabeled data. For example, the data can be current or voltage data indicating the power paths that interconnect devices in a data center, where the data is determined by sensors connected to the networked devices. Various examples determine the statistical significance of the tested connections by evaluating "micro" changes, "macro" system changes, and "event" data. Micro changes include changes in short-term time series data. Macro system changes include changes that are obvious in long-term trends and data. Event data includes data indicating electrical anomalies, semi-synchronous alarms, etc.

[0047] As discussed above, operational data (including, for example, power, temperature, cooling, and / or communications) may be used to identify relationships and connections between devices in a group of devices.

[0048] Figure 1 A top view of a data center 100 according to an example is shown. As one of ordinary skill in the art will appreciate, a data center (e.g., data center 100) may include various computing systems (e.g., servers) to store data, and data center resources may be provided to support the operation of the computing systems. Data center resources may include, for example, any features of a data center that support and / or ensure the functionality of data center equipment. Examples of data center resources include power, cooling, physical space, weight support, remote equipment control capabilities, physical and logical security, and physical and logical network connections.

[0049] Power data center resources may include power distribution resources (e.g., transformers, PDUs, and sockets) and power available for distribution (e.g., utility power supplied to the data center, power generated by on-site generators, and power supplied by UPS). Physical space resources in a data center may include data center floor space and rack U space. Cooling resources in a data center may include cooling distribution capacity and cooling power generation capacity. Physical security resources in a data center may include security cameras and door locks. Logical network connection resources in a data center may include virtual LANs, domain name services, and dynamic host configuration protocol services. Physical network connection resources may include network cabling and patch panels. Remote device control capability resources in a data center may include keyboard video mouse services.

[0050] Data center 100 includes multiple rows of cabinets 102A, 102B, 102C, and 102D, cooling units 104A and 104B, and raised floor 106. Each row includes a cabinet 108, which may include a rack, PDU, or other data center equipment. At least a plurality of cabinets 108 may draw cool air from the front of the cabinet and return hot air to the back and / or top of the cabinet. Each rack may include U space locations designed to accommodate data center equipment (e.g., servers, cooling equipment, and network connection equipment) mounted on the rack.

[0051] As those skilled in the art will appreciate, in order to optimize cooling performance in a data center, rows of cabinets are often positioned to create alternating cold and hot aisles. Figure 1 In the configuration shown, aisles 110A, 110B, and 110C are hot aisles, and aisles 112A and 112B are cold aisles. To provide cooling to the cabinets 108, in front of each cabinet in the cold aisle, perforated floor tiles 114 are used to provide cooling air from under the raised floor 106. In the data center 100, the raised floor 106 may also include solid floor tiles in addition to the perforated floor tiles shown.

[0052] The cooling units 104A and 104B are designed to provide cool air to the area below the raised floor 106 and receive return hot air from the space adjacent to the ceiling of the data center. In other embodiments, in addition to or in place of the cooling units 104A and 104B, rows of cooling units, such as those available from American Power Conversion Corporation, may be used. In addition, in at least one embodiment, half-rack rows of cooling units may be used, as described in U.S. Patent Application Serial No. 11 / 335,901 (Attorney Docket No. A2000-704819), entitled “COOLING SYSTEM AND METHOD,” filed on January 19, 2006 by Neil Rasmussen et al. and incorporated herein by reference. As described in the referenced application, the half-rack row of units has a width of 12 inches, which is approximately half the width of a standard data center rack.

[0053] The data center 100 also includes a computing device 116 configured to monitor and control the operation of components of the data center. For example, the computing device 116 can be communicatively coupled (e.g., via wired and / or wireless connections) to each of the cabinets 108 and the cooling unit 104, as indicated by the dashed connections between the components. For purposes of clarity, the dashed connections are truncated, with each point labeled "A" representing a connection point with the computing device 116. It should be appreciated that although the computing device 116 is shown as being included in the data center 100, the computing device 116 can be internal or external to the data center 100.

[0054] Figure 2 2 shows a rear view of a rack 200 according to an example. For example, one or more cabinets 108 may be implemented as the rack 200. For clarity, Figure 2 The door of rack 200 is omitted. Rack 200 may include drawer housings, each of which is indicated at 220, including items for supporting power and / or network connections for other equipment installed in rack 200. UPS 240 can be installed as a rack-mounted device to increase the power supply redundancy of the rack. For example, each UPS 240 can be connected to an AC power source, such as a utility power source. UPS 240 can also supply power obtained from the AC power source to other components of rack 200 directly or via rPDU 210, and UPS 240 provides power to rPDU 210.

[0055] Other components of the rack 200 may include computing or networking technology devices, such as one or more data storage devices 250, servers 260, patch panels 270, keyboard trays 280, cable organizers 290, and / or monitors or other user interfaces that may be provided for an operator to communicate with the devices in the rack. In some examples, the rack 200 includes a communication interface that may be a wired or wireless interface to communicate with other entities (including, for example, one or more other cabinets 108, computing devices 116, or another entity). The rack 200 may be configured in any manner desired by the end user.

[0056] The rPDU 210 may be installed inside the rack 200. The rPDU 210 may be installed vertically, such as Figure 2 , or can be mounted horizontally in the rack with other equipment in the rack. Although one rPDU 210 is shown and described, two or more rPDUs can be provided in the rack. The rPDU 210 can receive power from one or more UPS 240 in the rack 200, from a PDU in another rack in the rack 200 or in the cabinet 108, or directly from an AC utility power source, and can include a power outlet to which power cords from various other equipment in the rack can be electrically connected. In one example, one of the UPS 240 can provide power to a PDU in another rack in the rack 200 or in the cabinet 108, and the PDU can distribute power to the rPDU 210. It should therefore be appreciated that in various examples, many different combinations of devices can be implemented in the power path.

[0057] The rPDU 210 may include a single type or different types of receptacles configured to receive corresponding types of plugs. As will be appreciated by one of ordinary skill in the art, the International Electrotechnical Commission (IEC) 60320 defines a set of standards for common plug and receptacle pairs. For example, the IEC 320-C19 / C20 standards respectively identify receptacles and plugs that are typically used in higher current applications (e.g., when providing power to a UPS).

[0058] As discussed above, at least one of the cabinets 108 can be implemented in conjunction with a PDU. For example, the PDU can be a standalone unit rather than implemented within the interior of the rack, or can be implemented within the interior of the rack (e.g., mounted on the rack). The PDU can, for example, receive power directly from a utility power source, or can receive power from a UPS. For example, a UPS (e.g., UPS 240) implemented in conjunction with one of the cabinets 108 can receive power from a utility and provide the power to the PDU.

[0059] As discussed above, it may be beneficial to analyze operational data (e.g., power, temperature, cooling, communications, etc.), automatically identify device relationships and connections between a set of devices based on the operational data, and automatically generate a map indicating the relationships and connections between the set of devices. For example, it may be beneficial to analyze operational data of the equipment of the data center 100, including the cabinets 108 and components thereof, such as UPS (including, for example, UPS 240), PDUs (including, for example, one of the cabinets 108), and rPDUs (including, for example, rPDU 210). Automatically generating device maps using power, temperature, cooling, communications, or other metrics may be implemented for a variety of purposes, including, for example, alarm filtering, determining the reliability and health of equipment, determining the impact of replacing or upgrading components, determining equipment redundancy and capacity estimation, and for providing a basis for any implemented control schemes.

[0060] Figure 3A-3C A process 300 is shown for automatically identifying device relationships and connections between a set of monitored devices using operational data (e.g., power, temperature, cooling information, communications, or other operational data) and managing alarms based thereon. The process 300 may be performed by one or more computing devices communicatively coupled to one or more interrelated devices. For example, the process 300 may be performed by the computing device 116 in conjunction with devices including the cabinet 108 and the cooling device 104.

[0061] At act 302, process 300 begins. At act 304, operational data is received. For example, data may be received by computing device 116 from one or more communication devices (including one or more cabinets 108 or components thereof, cooling device 104, or other devices). The operational data may be data indicating power consumption and / or provisioning of the communication device, ambient temperature information about the communication device, cooling information about the amount of cooling provided to or from the communication device, communication information about communications sent or received by the communication device, or any other information about the operation of the communication device. In one example, the operational data indicating power consumption of the communication device may include one or both of current and voltage data captured by one or more current or voltage sensors coupled to the communication device.

[0062] In some examples, the operational data received at act 304 may include or otherwise be associated with an indication of the type of device providing the operational data. For example, where UPS 240 is a communication device that provides power to rPDU 210, UPS 240 may use one or more current or voltage sensors to determine power consumption or supply information (i.e., information indicating the amount of power provided to rPDU 210) and communicate the power information to computing device 116 in addition to the indication of the device type of UPS 240. For example, the indication of the device type may indicate at least that UPS 240 is an uninterruptible power supply and may indicate additional details about UPS 240, such as the model type or quantity of UPS 240.

[0063] At act 306, a determination is made as to whether operational data is received from multiple types of devices. As discussed above, operational data may be received from various types of devices, including, for example, UPS, PDU, rPDU, cooling equipment, etc. Thus, act 306 may include determining whether operational data is received from multiple different device types. More particularly, act 306 may include analyzing the operational data to extract an indication of the device type, and determining whether any device type is distinct. If operational data is received from multiple different device types (306 yes), process 300 continues to act 308. Otherwise, if operational data is not received from multiple different device types (306 no), process 300 continues to act 310.

[0064] At action 308, the operational data is filtered based on the device type. For example, operational data received from a UPS (e.g., UPS 240) can be grouped together by computing device 116. Grouping operational data by device type can provide various advantages. For example, it can be assumed that one rPDU does not provide output power to another rPDU or does not receive input power from another rPDU. Similarly, it can be assumed that one UPS does not provide power to another UPS. Therefore, by classifying devices by device type, certain device relationships can be initially assumed to be invalid, such as one rPDU providing power to another rPDU.

[0065] At act 310, a determination is made as to whether computing device 116 requires supplemental data. Supplemental data may include any data not included in the received operational data, and it may be desirable to extend or enhance the value of the received operational information. For example, operational data received from a UPS (e.g., UPS 240) may indicate power consumption as a percentage of rated active power, but may not indicate output active power in watts nor rated active power. Therefore, computing device 116 may determine whether supplemental data is desirable for determining the rated active power of UPS 240, and use the rated active power and the percentage of the rated active power to determine the output active power provided by UPS 240. If computing device 116 determines that supplemental data is desirable (310 yes), process 300 continues to act 312. Otherwise, if computing device 116 determines that supplemental data is not desirable (310 no), process 300 continues to act 314.

[0066] At action 312, supplemental data is accessed. As discussed above, supplemental data may be retrieved by computing device 116 where such supplemental data is desired. Supplemental data may be retrieved from one of several sources. Supplemental data may be stored locally by computing device 116, or may be stored remotely by computing device 116. For example, if an operator of data center 100 knows that data center 100 will include a particular model of UPS, the operator may configure computing device 116 to locally store information about known models of UPS, such as a manufacturer's specification sheet. Alternatively, in an example where computing device 116 determines that ideal supplemental data is not stored locally, computing device 116 may communicate (e.g., remotely via a wired or wireless connection) with an external information source that stores supplemental data (e.g., a database maintained by a manufacturer of a particular UPS) to retrieve the supplemental data. Supplemental data may optionally be stored for later use.

[0067] At action 314, a determination is made as to whether it is desirable to resample the operational data. For example, the computing device 116 may analyze the operational data received at action 304 to determine whether it is desirable to resample the operational data. As discussed above, data received from multiple devices may not be synchronized. For example, the devices that generate the operational data may sample the operational data at different times and at different frequencies. Therefore, in the presence of any differences in sampling frequency or time, the operational data received from a group of devices may not be synchronized. Therefore, the operational data may be resampled so that the measurements are standardized to a uniform polling frequency. For example, where a uniform polling frequency is selected to be once per minute, resampling may include rounding all timestamps to the nearest minute.

[0068] In some examples, resampling may be desirable when operational data received from multiple devices is not completely synchronized. In other examples, resampling may be desirable when operational data is not synchronized outside a certain threshold. For example, if only one device in a group of devices provides operational data that is not completely synchronized with other devices in the group of devices, computing device 116 may determine that resampling is not desirable given the relatively small deviation. The threshold (outside of which resampling is performed) may be configured by a user, or determined dynamically by computing device 116.

[0069] If the computing device 116 determines that resampling the operational data is desirable (314 YES), the process 300 continues to act 316. Otherwise, if the computing device 116 determines that resampling the operational data is undesirable (314 NO), the process 300 continues to act 318. At act 316, the operational data is resampled. As discussed above, resampling the operational data may include, for example, the computing device 116 rounding all timestamps to the nearest period, such as the nearest minute, at a selected frequency.

[0070] At action 318, the data is interpolated. As discussed above with respect to actions 314 and 316, the operational data can be rounded to a uniform polling cycle at a selected frequency. However, the data of some devices may not have measurements at each polling cycle. For example, when a device has a separate polling frequency of once every two minutes but a uniform polling frequency is selected to be once every minute, the device will only have measurements corresponding to uniform polling cycles every one minute. Therefore, at action 318, the computing device 116 can interpolate the measurements for each timestamp (within which no measurements are made). For example, interpolation can include estimating the measurements by copying the most recent measurements so that each device has a measurement for each polling cycle. In other examples, other interpolation methods can be used, such as averaging the nearest neighboring values, predicting the next value based on the previous value, or other interpolation methods.

[0071] At act 320, the operational data is analyzed. Analyzing the pre-processed data may include performing one or more statistical analysis techniques by the computing device 116 to determine the corresponding statistical significance of the tested connections. For example, statistical significance may be determined by evaluating micro-variation, macro-variation, and event data, as described below with respect to Figure 6 and Figure 7 discussed in more detail.

[0072] At act 322, a device mapping is determined. Determining the device mapping may include determining, by computing device 116, relationships among devices that are related by, for example, power, temperature, cooling, communication, or other parameters indicated by the operational data based on the analysis of the operational data at act 320. For example, determining a power relationship may include determining that a UPS (e.g., UPS 240) provides a UPS to an rPDU (e.g., rPDU 210).

[0073] In some embodiments, a single method (such as the method shown in the examples discussed below) is implemented to generate a device map. In other embodiments, a combination of two or more methods (such as two or more statistical methods discussed below) is implemented to generate a device map. For example, in one embodiment, as discussed below, a Bayesian network estimation technique is implemented by combining a correlation coefficient technique and a constrained regression optimization technique to generate a device map.

[0074] At act 324, the device mapping is output. For example, computing device 116 may include a display configured to display the device mapping determined at act 322. In other examples, computing device 116 may include a communication interface (e.g., a wired or wireless communication interface) configured to provide the device mapping to a remote device. For example, computing device 116 may provide the device mapping to a remote user device (e.g., a mobile phone or a computer terminal), and the remote user device may be configured to display the device mapping.

[0075] The device mapping determined at act 322 can be output to a user at act 324 so that the user has useful information about device relationships. As discussed above, the device mapping can also be used for other opportunities, including alarm filtering, determining the reliability and health of devices, determining the impact of replacing or upgrading parts, determining device redundancy and capacity estimation, and for providing a basis for any implemented control schemes.

[0076] For example, in some data center environments (e.g., data center 100), an alarm may include an error, warning, or critical alarm determined to be present by a device in data center 100. In response to determining the presence of an alarm, the device that determines the presence of an alarm may output an alarm or notification to one or more users responsible for overseeing the device. For example, where the device is a UPS (e.g., UPS 240), UPS 240 may be configured to output an alarm, such as a user notification, in response to determining that power from a power grid connected to UPS 240 is no longer available.

[0077] While alarm notifications may be beneficial in notifying users of abnormal conditions, in some examples users may receive redundant alarms. Redundancy may be particularly possible when a group of devices do not communicate with each other when determining when to generate an alarm. For example, if a data center with many UPSs loses access to utility power, each of the UPSs can send an alarm notification to the user in response to each individual UPS detecting a loss of access to utility power. As discussed above, for example, rack 200 includes multiple UPSs 240, each of which can receive utility power from the same source. If rack 200 loses access to utility power, each of UPS 240 can provide an alarm to the user, assuming that a single alarm will alert the user to the fact that rack 200 has lost access to utility power, and the user can consider this to be redundant.

[0078] Thus, a user may find it more useful to receive a single alert rather than multiple redundant alerts. For example, a user may find it more useful to receive a single notification indicating that all UPSs in data center 100 or in a single rack of racks 108 have lost access to utility power due to a failure of the utility grid or a failure of the utility grid connection at one of racks 108.

[0079] Thus, process 300 may enable device and alarm associations that group individual alarms into groups of similar alarms to be determined. Alarm associations may be defined by users, subject matter experts, network inferences of general population alarms, and network inferences of specific device groups (e.g., devices in a single facility). Alarm notifications may be delivered to a single point, such as computing device 116, where the alarm notifications are analyzed and merged, and one or more merged alarm notifications may be delivered to a user. Alarm merging may be effective in reducing redundant alarms and diagnosing the event that triggered the alarm.

[0080] At action 326, an alarm is received. The alarm may be received by the computing device 116 from a device of the data center 100. Some or all of the devices of the data center 100 may be configured to generate an alarm based on monitored parameters, which may be similar or identical to the parameters indicated by the operational data. The devices may include an rPDU 210, a UPS 240, etc. in the data center 100 that is configured to send an alarm to the computing device 116. In one example, the UPS 240 may generate an alarm when the UPS 240 determines that access to utility power has been lost.

[0081] At action 328, the alarms are grouped to generate a subset of alarms. The computing device 116 can group the alarms based on one or more of the organization alarm information, the group alarm information, and the user grouping information according to the availability of the corresponding information type. The organization alarm information includes alarm information that is specific to the organization (e.g., the data center 100) and can be determined based on performing network reasoning techniques. The group alarm information includes alarm information that is not specific to the organization, and is instead common to different organizations. In one embodiment, for example, a UPS that activates an alarm indicating a transition to battery power in response to a power outage is not organization-specific because most organizations' UPSs will activate the alarm in a similar manner. The user grouping information includes user-defined alarm groups.

[0082] Alarms can be grouped based on device type and based on the occurrence of the alarms within a period of time. For example, the period of time can be 15 minutes, 1 hour, 1 day, etc. Alarms that occur within the period of time can be grouped together because alarms that occur very close in time may be more likely to be related than alarms that occur at significantly different times.

[0083] For example, if all UPS in data center 100 output alarm notifications indicating loss of grid power within one minute, there may be a common cause for the loss of grid power (e.g., due to a grid power failure to data center 100). In contrast, if two UPS in data center 100 determine loss of grid power one week apart, the causes of loss of grid power for the two UPS may be more likely to be unrelated. In other embodiments, the alarms may be grouped based on a correlation matrix of alarms using binary indicator variables within each selected time period, based on a Bayesian network construction using a Bayesian estimator, or based on another grouping scheme.

[0084] At act 330, association rules are determined between subsets of alarms. Computing device 116 may determine association rules to reflect relationships between two or more subsets of alarms. For example, a first subset of alarms may include alarms from each UPS in data center 100 indicating that access to utility power has been lost. The first subset of alarms may therefore indicate a grid power failure. A second subset of alarms may include alarms from PDUs and / or rPDUs (e.g., rPDU 210) connected to a UPS in data center 100 and indicating that access to power from the UPS has been lost.

[0085] The computing device 116 may determine that an association rule exists between the first and second subsets of alarms. For example, after a grid power failure indicated by the first subset of alarms, the UPS 240 may begin to deplete their respective backup power supplies in order to provide power to the rPDU 210, thereby triggering the second subset of alarms once the backup power supplies are depleted. Thus, an association rule may be generated to indicate that the first subset of alarms has a probability of preceding the second subset of alarms.

[0086] At action 332, the association rule is evaluated. The computing device 116 can evaluate the association rule to determine the probability that the association rule accurately represents the association or relationship between the subsets of alarms. The evaluation can be based on at least two criteria. The first criterion includes the probability that the association rule does not occur by chance. For example, the computing device 116 can calculate a p-value for each rule, indicating the probability that the association rule occurs by chance. The second criterion includes a lift, a factor indicating the increased likelihood that a subsequent subset of alarms will occur assuming that a previous subset of alarms has occurred. For example, as discussed above, a previous group of alarms from a UPS indicates a grid power failure that may be associated with a lift factor that indicates that a subsequent group of alarms from a PDU indicates an increased likelihood that a loss of uninterrupted power will occur.

[0087] At action 334, the association rules are labeled. Labeling the association rules may include rating the association rules evaluated at action 332 by the computing device 116, providing the rated association rules to one or more users, and assigning tags to selected association rules based on input from one or more users (e.g., subject matter experts). In one example, unlabeled association rules are provided to one or more users by providing a visual representation of a subset of alarms along with network sources, device information, and a rating metric for each association rule. One or more users may determine appropriate tags based on the information provided and label the association rules accordingly. For example, if the user determines that the association indicates a utility power failure based on the visual representation, device information, and rating metric, the tag may be "Utility Power Failure".

[0088] At act 336, the marked association rule is implemented. The computing device 116 may execute the association rule to merge the alerts received at act 326 and generate one or more merged alerts to provide to the user. At act 338, the merged alerts are provided to the user. For example, the computing device 116 may provide the merged alerts to the user via a display interface that is local to the computing device 116 or via a wired or wireless connection to one or more user-accessible devices (e.g., a mobile electronic device). At act 340, the process 300 ends.

[0089] Thus, the volume of alerts delivered to a user can be reduced by merging redundant or less helpful alerts into user alerts. In addition to reducing the volume of alerts, user alerts can also provide additional information to the user. For example, rather than a user receiving several alerts, each from a respective UPS indicating a separate lack of utility grid power, a user can receive a single alert indicating a site-wide grid power failure to the data center housing the UPS.

[0090] Alerts may be generated based on device relationship information determined from network inference. As discussed above, device relationship information may be determined according to several types of relationships, including power paths. As discussed above, device relationship information may be useful because changes to a first device in a power path may affect other devices in the power path. Thus, device relationship information determined based on network inference helps consolidate alerts and provide useful alerts to users.

[0091] As discussed above, however, helping to consolidate alarms and provide useful alarms to users is only one example of the benefits that can be achieved in conjunction with eliciting network inferences. Other examples include helping to determine the reliability and health of equipment, determining the impact of replacing or upgrading components, determining redundancy and capacity estimates, mapping power systems and cooling systems, and for establishing and implementing control systems, some examples of which will be discussed in more detail below.

[0092] For example, Figure 4A-4C A process 400 is shown that uses operational data (e.g., power, temperature, cooling information, communications, or other operational data) to automatically identify device relationships and connections between a group of monitored devices and determine device health and reliability based thereon. Actions 402-424 of process 400 are substantially similar to actions 302-324 of process 300.

[0093] At action 426, after determining and outputting the device mapping, the device health and reliability can be determined. The computing device 116 can determine the device health and reliability based on the device mapping. For example, the computing device 116 can determine that a single UPS (e.g., UPS 240) provides power to a large number of rPDUs (including, for example, rPDU 210). The computing device 116 can determine that the UPS may fail faster than a similar UPS that provides power to a smaller number of rPDUs based on a large number of rPDUs powered by the UPS. Therefore, the computing device 116 can use information about the number of device connections and the duration of the device connection to determine the device health, and thus determine reliability, where the device experiences a higher level of use than a comparable UPS. The computing device 116 can output device health and reliability information to the user locally or via a wired or wireless connection to the user device. At action 428, the process 400 ends.

[0094] In another example, Figure 5A-Figure 5C A process 500 is shown that uses operational data (e.g., power, temperature, cooling information, communications, or other operational data) to automatically identify device relationships and connections between a group of monitored devices and based thereon determine the impact of device replacement or upgrades. Actions 502-524 of process 500 are substantially similar to actions 302-324 of process 300.

[0095] At action 526, after determining and outputting the device mapping, the impact of the device replacement and / or upgrade can be determined. The computing device 116 can determine the impact of such replacement and / or upgrade based on the device mapping. For example, the computing device 116 can determine that a single UPS (e.g., UPS 240) provides power to several PDUs. Therefore, the computing device 116 can determine therefrom that if a single UPS is replaced or upgraded, the PDUs powered by the UPS will temporarily lack access to power. Therefore, an operator who replaces or upgrades a device may wish to temporarily couple a PDU powered by a UPS to a replacement UPS during the replacement or upgrade.

[0096] In addition, the best replacement and / or upgrade solution can be determined based on the device mapping at action 526. For example, as discussed above with respect to action 426, the device health and reliability can be determined based on the device mapping. A determination can be made based on this determination that it is desirable to replace a low-health component with another component. In another example, the following determination can be made: because the UPS provides power to a considerable number of components, the UPS should be upgraded to a higher capacity UPS that can more easily support a considerable number of components. Therefore, the computing device 116 can provide the user with recommendations on which components should be replaced and / or upgraded based on the device mapping. At action 528, process 500 ends.

[0097] As discussed above with respect to action 320, analysis is performed by the computing device 116 on the operational data to determine the strength of the tested connection based on power, temperature, cooling, communication, or other relationships. In various examples, the strength of the tested connection is determined based on the statistical significance of the tested connection. The statistical significance of the tested connection can be assessed by analyzing micro changes in short-term time series data, macro system changes in long-term data integration, and event data including anomalies and semi-synchronous alarms to determine the statistical probability that the device is related. Example statistical analysis methods include correlation coefficient techniques, restricted regression optimization techniques, Bayesian network estimation techniques, and ordinary least squares (OLS) techniques, each of which is discussed in turn below.

[0098] The correlation coefficient technique will now be described in more detail. The correlation coefficient technique includes the determination of a correlation coefficient for two tested connections, where the correlation coefficient indicates the likelihood that the two tested connections are related. Two time series are defined, X i [t] and X j [t], where t = 1, 2, 3, ..., n. Each time series is derived from the pre-processed data generated at action 318 and represents a series of data points corresponding to a device. t corresponds to the polling period selected as a result of the resampling and interpolation discussed above with respect to action 318.

[0099] In X i [t] and X j The correlation coefficient between [t] is defined as:

[0100]

[0101] Among them, CC ij [τ] represents the correlation coefficient between devices i and j, τ represents the lag when calculating the correlation, and σ i and σ j Respectively represent X i and X j Next, let the maximum value of CCij[τ] for τ be expressed as:

[0102] s ij =max τ |CC ij [τ]| (2)

[0103] Maximum value ij is used as a statistic to measure the significance of the correlation between devices i and j. In order to make the cross-correlation approximately follow a normal distribution, the Fisher transformation is used, which is expressed as:

[0104]

[0105] After performing the Fisher transformation, the empirical standard deviation is calculated as:

[0106]

[0107] And the converted value expressed as

[0108]

[0109] The maximum absolute value of a sequence that can be expected to behave similarly to a standard normal random variable. From equations (1)-(5) it can be determined that:

[0110]

[0111] in:

[0112]

[0113] as well as

[0114] b n =a n -(2a n ) -1 (log(log(n))+log(4π) (8)

[0115] Using the previous example, we can calculate the conversion value for The p-value represents the approximate likelihood that devices i and j are uncoupled and uncorrelated based on a set of mathematical assumptions. The p-value is calculated for each pair of devices under consideration and is ordered such that p1≤p2≤…≤p m . The pairing for which the p-value is determined may be selected based on the device type. For example, in a system including three PDUs and three UPSs (as indicated by operational data received directly or indirectly from six devices), a user may assume that the PDUs are not connected to each other via a direct power path, and that the UPSs are not connected to each other via a direct power path. Thus, the p-value may be determined only between the UPSs and the PDUs. In other systems, a user may not want to make this simplifying assumption.

[0116] Each p-value pi is compared to a critical value q·i / m, where q is the false discovery rate (which can be user-defined or dynamically determined), i is an integer corresponding to the p-value under consideration, and m is an integer corresponding to the total number of p-values. If the p-value pi is greater than the critical value, then the pair of devices corresponding to pi is determined to be unrelated. Otherwise, if the p-value pi is less than the critical value, then the pair of devices corresponding to pi is determined to be related.

[0117] Consider an example in which equipment relationships are determined for a data center (e.g., data center 100) that includes three UPSs and three PDUs (e.g., each included in one or more cabinets 108). A total of nine p-values ​​can be determined that collectively represent the evaluated pairings between each UPS and each PDU. Figure 6 A graph 600 showing the results of a p-value determination is shown. Data points 602 represent the determined p-values, and line 604 represents a critical value above which the p-values ​​correspond to uncorrelated devices. Three of the data points 602 are below line 604, indicating that there are three pairs of devices that are statistically likely to be correlated.

[0118] Figure 7A graph 700 of possible device relationships determined is shown. Graph 700 indicates a first point 702 corresponding to a first UPS, a second point 704 corresponding to a second UPS, a third point 706 corresponding to a third UPS, a fourth point 708 corresponding to a first PDU, a fifth point 710 corresponding to a second PDU, and a sixth point 712 corresponding to a third PDU. As shown by the lines connecting the first point 702 and the fourth point 708, the first point 702 and the fifth point 710, and the second point 704 and the sixth point 712, it is determined that there are relationships between the first UPS and the first PDU, the first UPS and the second PDU, and the second UPS and the third PDU. For example, the first point 702 may correspond to the UPS 240, and the fourth point 708 may correspond to a PDU included in one of the cabinets 108.

[0119] As discussed above, operational data indicative of parameters (e.g., power, temperature, cooling, communications, etc.) can be analyzed to identify relationships between devices. The operational data can be analyzed using one of many implementations. An example of an implementation is provided for purposes of illustration and includes a constrained regression optimization technique. However, it should be appreciated that the constrained regression optimization technique is merely one example of a technique that can be implemented to analyze operational data indicative of parameters (e.g., power, temperature, cooling, communications, etc.), as identified above.

[0120] Restricted regression optimization techniques are linear methods for modeling the relationship between a scalar response (or dependent variable) and one or more explanatory variables (or independent variables). Given a data set of n statistical units The linear regression model assumes that the relationship between the dependent variable y and the p-vector of regressors x is linear. This relationship is modeled by a disturbance term of the error variable ε (an unobserved random variable) that adds "noise" to the linear relationship between the dependent variable and the regressors. Therefore, the model takes the following form:

[0121]

[0122] i=1,…,n

[0123] Where T represents transpose, so that is in the vector X i In traditional linear regression, the intercept and some slope coefficients β0,…,β p is calculated so that the sum of squared errors (SSE) is minimized, where SSE is denoted as:

[0124]

[0125] In this approach, the intercept is constrained to zero and some of the slope coefficients are constrained to zero or one. These constraints are based on the assumption that the connected devices should have a roughly one-to-one relationship according to the sensor measurements of interest. Therefore, this regression technique can be characterized as a generalized reduced gradient (GRG) nonlinear optimization problem.

[0126] The goal of GRG nonlinear optimization is to minimize the sum of the estimated mean squared errors for each constrained regression problem, where:

[0127]

[0128] The variables that are varied (i.e., the values ​​being optimized) in GRG nonlinear optimization are the partial slope coefficients β1,…,β2 corresponding to each independent variable or “sub” in the data set. p The partial slope coefficients are constrained to be either zero or one (i.e., binary), and each independent variable or child device is constrained to correspond to only one dependent variable or predecessor device. An output representing the predicted device connections is provided, and may be similar in form to that described above with respect to Figure 7 Examples provided.

[0129] Bayesian network estimation techniques will now be discussed in more detail. A Bayesian network is a probabilistic graphical model that represents a set of variables and conditional dependencies of the variables through a directed acyclic graph, which is a type of statistical model. Learning the structure of a Bayesian network can be accomplished using one of several methods, including a method that utilizes a test of node independence using a growing and shrinking Markov blanket algorithm.

[0130] The Markov blanket algorithm is based on two phases: a growing phase and a shrinking phase, during which the estimated Markov blanket is restored based on pairwise independence. Starting from an empty set S, the growing phase adds variables to the set S as long as the variables are related to X (a one-dimensional variable), given the current content of S. The premise of the growing phase is to add variables to the domain {X1,…,X n} add all variables in the universe U of variables in set S.

[0131] However, variables may be added to S that are actually outside the Markov blanket S. Such variables are those that become independent of X at a later point when the "middle" (d-separation) nodes of the underlying Bayesian net are added to S. Therefore, a shrinking phase is performed after the growing phase to identify and remove these variables. The Markov blanket algorithm can be mathematically represented as four steps, the second step representing the growing phase and the third step representing the shrinking phase:

[0132] 1.S←0

[0133] 2. When When Y⊥X|S, complete S←S∪{Y}

[0134] 3. When When Y⊥X|S-{Y}, complete S←S-{Y}

[0135] 4.B(X)←S

[0136] The Markov blanket algorithm may be trained with known device connections during a training period prior to implementation. The length of the training period may be user-configured or dynamically determined. For example, the training period may continue until the algorithm is able to predict device connections above a threshold accuracy based on the training data. The accuracy of the Markov blanket algorithm increases proportionally with the length of the training period, such that longer training periods correspond to more accurate algorithms. After the training period, the algorithm is executed to provide an output representing the predicted device connections, which may be similar in form to that described above with respect to Figure 7 Examples provided.

[0137] The OLS regression technique will now be described in more detail.The OLS regression technique is similar to the restricted regression optimization technique in that it is a linear method for modeling the relationship between a scalar response (or dependent variable) and one or more explanatory variables (or independent variables).

[0138] In one example, unique OLS modeling is applied because only one possible connection between devices is considered at a time (e.g., a UPS to a PDU), rather than considering all possible child devices associated with a "parent" device. Considering only one possible device connection at a time is beneficial because it reduces the impact of multicollinearity on the estimated values ​​of the parameters (β) and their associated significance levels (p-values). In applications where power paths are being instrumented in a data center, there is a possibility for devices to perform similar jobs, making the overall power requirements of the devices very similar. In this case, attempting to model the relationship between the related device time series and a potential parent device may lead to inconsistent results for parameter estimates and significance levels. Therefore, the first stage of the model takes the following form:

[0139] y i =β01+β1x i1 +ε i , (12)

[0140] i=1,…,n

[0141] In this method, the intercept is not limited to zero, and the partial slope coefficients are not limited to zero or one. Instead, the intercept and partial slope coefficients β0, β1 are calculated such that the SSE is minimized.

[0142] In addition to a potential explanatory sub-device (β1xi1 ) modeling, a time factor may also be incorporated to combat the presence of seasonality in the data. There may be trends in the power demand of devices due to the time of day or day of the week under consideration (e.g., increased power demand during typical working hours). This possible similarity in the power demand of multiple unrelated devices may result in erroneously predicted connections. To account for this, time factors for hour and day may be included in the OLS model, which now takes the following form:

[0143]

[0144] t=1,…,n; i=1,…,23; j=1,…,6

[0145] Among them, ω i is the estimated partial slope coefficient associated with the hour, θ j is the estimated partial slope coefficient associated with the day, and I{event}=1 if the event occurs, and I{event}=0 if the event does not occur.

[0146] The variables that are varied (i.e., the values ​​that are optimized) in the OLS regression are the intercept β0, the partial slope coefficients β1 corresponding to the independent variables or subvariables considered in the data set, and the time factor coefficient ω i and θ j The main estimates of interest are the partial slope coefficients β1 corresponding to the independent variables or subvariables considered in the data set. The output estimates of these values ​​for each possible device pairing are compared and ranked according to the significance level (p-value). An output representing the predicted device connections is provided (according to the highest significance level) and can be similar in form to that described above for Figure 7 Examples provided.

[0147] Some of the examples provided above are shown with respect to UPS and PDU. The principles disclosed herein are not limited to UPS and PDU provided for the purpose of explanation only. The principles disclosed herein are also generally applicable to power equipment (including, for example, UPS, PDU, transformer, rPDU, etc.), heating and cooling systems, communication equipment, etc.

[0148] As discussed above, device relationships can be based on power paths, temperature, cooling, communication paths, or other attributes. The various examples provided above are given with respect to power paths. A temperature-based device relationship can refer to a system of devices where the temperature of a first device in the system is related to the temperature of a second device in the system. For example, where a first device is close to a second device, heat output by the first device can be transferred to the second device. Reference Figure 1, a first one of the cabinets 108 adjacent to a second one of the cabinets 108 may be close enough to exchange a substantial amount of heat. Each of the cabinets 108 may include one or more temperature sensors configured to capture temperature information and provide the temperature information to the computing device 116, based on which the computing device 116 may perform one of the processes 300-500 discussed above.

[0149] In another example, a system of equipment can be cooled by a cooling system. For example, a cabinet 108 can be cooled by a cooling device 104. In order to operate the cooling system effectively, it may be beneficial to understand the temperature and cooling zone within a certain volume of space. For example, in addition to understanding how heat is transferred between devices, understanding temperature and cooling zones can also include understanding what effect cooling a first device has on cooling a second device. Therefore, understanding cooling and temperature relationships can make the cooling system operate more efficiently. The cooling system can automatically perform certain functions based on the temperature relationship. For example, the cooling system can modify the temperature, speed or direction of the cooling air provided by the cooling system. Therefore, in some examples, the computing device 116 can determine the cooling relationship between the cabinets 108 and provide information indicating the relationship with the cooling device 104. The cooling device 104 can be configured to modify the parameters discussed above to provide more effective cooling.

[0150] A device relationship based on a communication path may refer to a system of devices in which a first device communicates with a second device. For example, a communication sent by a first device may be routed through a second device to be transmitted to a third device, or a first device may repeatedly communicate with a second device. Figure 2 , for example, devices in rack 200 (e.g., UPS 240, rPDU 210, etc.) can communicate information, such as operational data, to computing device 116 via a communication interface in rack 200. Understanding the communication relationship can enable the system to operate more efficiently, for example, by detecting a loss of communication functionality by a device. For example, if a group of devices that generally route communications through a routing device detects that they cannot send communications at approximately the same time, it can be determined that the routing device is not functioning properly. In addition, alarms sent by the group of devices can be merged into a single alarm indicating that the routing device is not functioning properly.

[0151] As discussed above, various aspects and functions described herein may be performed in conjunction with one or more computer systems (e.g., computing device 116). For example, aspects and functions described herein may be included as dedicated hardware or software components executed in one or more computer systems. One or more actions of the above method may be performed with a computer (e.g., computing device 116), wherein at least one action is performed in a software program contained in the computer. Non-limiting examples of computer systems include network appliances, personal computers, workstations, mainframes, networked clients, servers, media servers, application servers, database servers, and web servers, among others. Other examples of computer systems may include mobile computing devices (e.g., cellular phones and personal digital assistants) and network devices (e.g., load balancers, routers, and switches). In addition, various aspects may be located on a single computer system or may be distributed among a plurality of computer systems connected to one or more communication networks.

[0152] For example, various aspects and functions can be distributed among one or more computer systems that are configured to provide services to one or more client computers or perform a total task as a part of a distributed system. For example, various aspects and functions can be performed on a client-server or multi-layer system including components distributed among one or more server systems that perform various functions. Therefore, the example is not limited to performing on any specific system or a group of specific systems. In addition, various aspects and functions can be implemented in software, hardware or firmware or any combination thereof. Therefore, various hardware and software configurations can be used to implement various aspects and functions in methods, actions, systems, system elements and components, and the example is not limited to any specific distributed architecture, network or communication protocol.

[0153] Figure 8A block diagram of a computer system 800 is shown in which various aspects and functions are practiced. As discussed above, the computer system 800 can be an example of a computing device 116. As shown, the computer system 800 includes a processor 802, one or more memory elements 804, an interconnect element 806, one or more interface devices 808 coupled to a communication network 812, and a data storage element 810. As shown, the computer system 800 is connected to the communication network 812 and can exchange data through the communication network 812. For example, data can be exchanged between the computing device 116 and the cabinet 108 and the cooling device 104 through the communication network 812. The communication network 812 can include any communication network through which a computer system can exchange data. To exchange data using the communication network 812, the computer system 800 may use various methods, protocols, and standards, including, among others, Fiber Channel, Token Ring, Ethernet, Wireless Ethernet, Bluetooth, IP, IPV6, TCP / IP, UDP, DTN, HTTP, FTP, SNMP, SMS, MMS, SS7, JSON, SOAP, CORBA, REST, and Web services. To ensure that data transmission is secure, the computer system 800 may use various security measures (including, for example, TLS, SSL, or VPN) to transmit data through the communication network 812.

[0154] The computer system 800 can be configured to exchange information with one or more devices. For example, and as discussed above with respect to action 304, the computer system 800 can be configured to receive operational data (e.g., current data or voltage data) from one or more sensors coupled to one or more devices in the data center 100. Thus, the computer system 800 can be configured to communicate with networked devices via the communication network 812.

[0155] In order to implement at least some of the various aspects, functions and processes disclosed herein, processor 802 executes a series of instructions that result in manipulated data. Processor 802 can be any type of processor, multiprocessor or controller. Some example processors include commercially available processors, such as Intel Atom, Itanium, Core, Celeron or Pentium processors, AMD Opteron processors, Apple A4 or A5 processors, Sun UltraSPARC or IBM Power5+ processors and IBM mainframe chips. Processor 802 is connected to other system components, including one or more memory elements 804, via interconnect element 806.

[0156] One or more memory elements 804 store programs and data during the operation of computer system 800. Therefore, one or more memory elements 804 can be relatively high-performance volatile random access memory, such as dynamic random access memory (DRAM) or static random access memory (SRAM). However, one or more memory elements 804 can include any device for storing data, such as disk drive or other non-volatile storage devices. Various examples can be organized into one or more memory elements 804 into specialized and unique structures in some cases to perform functions disclosed herein. These data structures can be manufactured and organized into storage values ​​for specific data and specific types of data according to size.

[0157] The components of computer system 800 are coupled by interconnect elements, such as interconnect element 806. Interconnect element 806 may include one or more physical buses, such as buses between components integrated within the same machine, but may include any communication coupling between system elements, including proprietary or standard computing bus technologies, such as IDE, SCSI, PCI, and InfiniBand. Interconnect element 806 enables communications (e.g., data and instructions) to be exchanged between components of computer system 800.

[0158] The computer system 800 also includes one or more interface devices 808, such as input devices, output devices, and combined input / output devices. An interface device can receive input or provide output. More particularly, an output device can reproduce information for external presentation. An input device can accept information from an external source. Examples of interface devices include keyboards, mouse devices, trackballs, microphones, touch screens, printing devices, display screens, speakers, network interface cards, etc. Interface devices allow the computer system 800 to exchange information and communicate with external entities (e.g., users and other systems).

[0159] Data storage element 810 includes a computer-readable and writable non-volatile or non-temporary data storage medium, wherein the instructions defining the program or other objects executed by processor 802 are stored. Data storage element 810 may also include information recorded on or in the medium and processed by processor 802 during the execution of the program. More particularly, information may be stored in one or more data structures that are specially configured to save storage space or improve data exchange performance. Instructions may be stored permanently as coded signals, and instructions may enable processor 802 to perform any function described herein. The medium may be, for example, an optical disk, a magnetic disk, or a flash memory. In operation, processor 802 or some other controller enables data to be read from a non-volatile recording medium into other memories (e.g., one or more memory elements 804), which allow faster access to information by processor 802 than the storage medium included in data storage element 810. The memory may be located in the data storage element 810 or in one or more memory elements 804, however the processor 802 manipulates the data in the memory and then copies the data to a storage medium associated with the data storage element 810 after the processing is complete. Various components may manage the movement of data between the storage medium and other memory elements, and the examples are not limited to specific data management components. Furthermore, the examples are not limited to specific memory systems or data storage systems.

[0160] Although computer system 800 is shown as an example of one type of computer system on which various aspects of the present disclosure may be practiced, the various aspects and functions are not limited to being implemented on computer system 800. The functions of the various aspects may be implemented on a computer system having the same Figure 8 The different architectures or components shown are implemented on one or more computers. For example, the computer system 800 may include specially programmed dedicated hardware, such as an application specific integrated circuit (ASIC), suitable for performing the specific operations disclosed herein. Although another example may use a grid of several computing devices running MAC OS X with IBM PowerPC processors and several dedicated computing devices running proprietary hardware and operating systems to perform the same functions.

[0161] The computer system 800 may be a computer system including an operating system that manages at least a portion of the hardware elements included in the computer system 800. In some examples, a processor or controller (e.g., processor 802) executes an operating system. Examples of specific operating systems that may be executed include Windows-based operating systems (e.g., Windows 10 operating system available from Microsoft), MAC OS X operating system or iOS operating system available from Apple Computer, one of many Linux-based operating system distributions available from Red Hat (e.g., Enterprise Linux operating system), Solaris operating system available from Oracle, or UNIX operating system available from various sources. Many other operating systems may be used, and the examples are not limited to any particular operating system.

[0162] The processor 802 defines a computer platform together with an operating system for which applications in high-level programming languages ​​are written. These component applications may be executable intermediate byte codes or interpreted codes that communicate over a communication network (e.g., the Internet) using a communication protocol (e.g., TCP / IP). Similarly, object-oriented programming languages ​​(e.g., .Net, SmallTalk, Java, C++, Ada, or C# (C-Sharp)) may be used to implement various aspects. Other object-oriented programming languages ​​may also be used. Alternatively, functions, scripts, and / or logic programming languages ​​may be used.

[0163] In addition, various aspects and functions can be implemented in non-programming environments (e.g., files created with HTML, XML or other formats), which can reproduce various aspects of a graphical user interface or perform other functions when viewed in a window of a browser program. In addition, various examples can be implemented as programmatic or non-programmatic elements or any combination thereof. For example, a web page can be implemented using HTML, and the data object called from the web page can be written in C++ or Python. Therefore, examples are not limited to specific programming languages, and any suitable programming language can be used. Therefore, the functional components disclosed herein can include multiple elements configured to perform the functions described herein, such as dedicated hardware, executable code, data structure or object.

[0164] In some examples, the components disclosed herein can read parameters that affect the functions performed by the components. These parameters can be physically stored in any form of suitable memory, including volatile memory (e.g., RAM) or non-volatile memory (e.g., magnetic hard drive). In addition, the parameters can be logically stored in a dedicated data structure (e.g., a database or file defined by a user mode application) or in a public shared data structure (e.g., an application registry defined by an operating system). In addition, some examples provide systems and user interfaces that allow external entities to modify parameters and thereby configure the behavior of the components.

[0165] Optionally, one or more computing devices executing the processes discussed herein may automatically perform one or more actions. Although the foregoing examples are directed to alarm merging, in other embodiments the computing devices executing the above processes may perform other functions. For example, the computing device may determine that the load cannot access sufficient redundant uninterruptible power, and in response thereto instruct the user to add additional redundant power supplies or automatically redirect the uninterruptible power to provide sufficient redundant power.

[0166] At least one embodiment discussed above provides automatic generation of a data center network map using power path, cooling or temperature zone, or communication path operation data. In other embodiments, the systems and methods described herein provide automatic generation of a data center network map for automatic alarm merging using power path, cooling or temperature zone, or communication path operation data. Current systems do not provide automatic generation of a data center network map using power path, cooling or temperature zone, or communication path operation data, or automatic generation of a data center network map for automatic alarm merging using power path, cooling or temperature zone, or communication path operation data. Developing a system for automatically generating such a map and for generating such a map for automatic alarm merging is a technical problem. An exemplary embodiment of a system having a plurality of interrelated devices can receive operation data indicating at least one of a power path, cooling or temperature zone, or communication path from each of a plurality of interrelated devices. The system can determine a statistical probability of a connection between two or more devices based on the operation data. The system can generate a device map indicating at least one predicted connection based on the operation data and provide the map to a user. At least this aforementioned combination of features includes a system architecture used as a technical solution to the aforementioned technical problem. This technical solution is not everyday, is non-traditional, and is not easily understood in the field of IP device mapping. This technical solution is a practical application of an exemplary system for automatic generation of data center network maps and automatic alarm consolidation for solving the above-mentioned technical problems, and constitutes an improvement in the technical field of IT equipment mapping by at least facilitating faster, more efficient and more accurate mapping and / or faster, more efficient and more accurate alarm consolidation.

[0167] It will be recognized that the above Figure 3A-3D Some of the actions discussed may be optional. That is, some of the actions of process 300 may or may not be performed in some examples. For example, actions 306-320, 324, and 330-334 may be optionally performed in some examples.

[0168] Having thus described several aspects of at least one embodiment of the present invention, it will be appreciated that various changes, modifications and improvements will readily occur to those skilled in the art. Such changes, modifications and improvements are intended to be a part of this disclosure and are intended to be within the spirit and scope of the present invention. Therefore, the foregoing description and accompanying drawings are intended only as examples.

Claims

1. A system for automatically generating a data center network map for automatic alarm consolidation, comprising: Multiple interconnected devices; as well as at least one computing device communicatively coupled to each of the plurality of interrelated devices, the at least one computing device being configured to: receiving operational data from each device of the plurality of interrelated devices, the operational data indicating at least one of a power path, a cooling zone, a temperature zone, or a communication path; determining a device relationship between each device in the plurality of interrelated devices based on the operational data; receiving a corresponding alert of a plurality of alerts from each device of the plurality of interrelated devices; determining, based on the plurality of alarms, an alarm relationship between at least two alarms in the plurality of alarms; merging the plurality of alarms into a merged alarm based on the determined device relationship and based on the determined alarm relationship; as well as providing the merged alert to a user, wherein the at least one computing device is further configured to: generate a first subset of alarms from the plurality of alarms when determining the alarm relationship, the first subset of alarms being received from the plurality of interrelated devices at a first time; and generate a second subset of alarms from the plurality of alarms, the second subset of alarms being received from the plurality of interrelated devices at a second time, and the first time being different from the second time; wherein the at least one computing device is further configured to determine a plurality of association rules when determining the alarm relationship, the plurality of association rules indicating a relationship between the first subset of alarms and the second subset of alarms; Wherein, the at least one computing device is further configured to evaluate the plurality of association rules when determining the alarm relationship to determine an association rule among the plurality of association rules having a highest likelihood of representing a relationship between the first subset of alarms and the second subset of alarms.

2. The system according to claim 1, wherein: The plurality of interrelated devices include electrical devices, and wherein the operational data includes at least one of: current data representing the current provided by the electrical device, power data representing the power provided by the electrical device, or voltage data representing the voltage provided by the electrical device; or Temperature data indicative of an ambient temperature of the electrical device provided by the electrical device.

3. The system according to claim 2, wherein: The at least one computing device is further configured to normalize the operational data about a single polling frequency when determining the device relationship.

4. The system according to claim 3, wherein: The at least one computing device is further configured to round data measurements to the nearest period of the single polling frequency when normalizing the operational data with respect to the single polling frequency, and to interpolate data measurements for each period of the single polling frequency for which no data measurements exist.

5. The system according to claim 4, wherein: The at least one computing device is further configured to perform at least one of a Bayesian network estimation technique, a correlation coefficient technique, a constrained regression optimization technique, or an ordinary least squares technique when determining the device relationships to generate a device map indicating a relationship between each of the plurality of interrelated devices.

6. The system according to claim 1, wherein: The at least one computing device is further configured to, when determining the alert relationship: presenting the association rules to the user; and A tag for the association rule is received from the user.

7. A non-transitory computer readable medium having stored thereon a sequence of computer executable instructions for automatically generating a data center network map for automatic alarm consolidation, the sequence of computer executable instructions comprising instructions for instructing at least one processor to perform the following operations: receiving operational data indicative of at least one of a power path, a cooling zone, a temperature zone, or a communication path from each of a plurality of interrelated devices; determining a device relationship between each device in the plurality of interrelated devices based on the operational data; receiving a corresponding alert of a plurality of alerts from each device of the plurality of interrelated devices; determining, based on the plurality of alarms, an alarm relationship between at least two alarms in the plurality of alarms; merging the plurality of alarms into a merged alarm based on the determined device relationship and based on the determined alarm relationship; as well as providing the merged alert to a user, wherein determining the alarm relationship comprises generating a first subset of the alarms of the plurality of alarms, the first subset of the alarms being received from the plurality of interrelated devices at a first time; and generating a second subset of the alarms of the plurality of alarms, the second subset of the alarms being received from the plurality of interrelated devices at a second time, and the first time is different from the second time; wherein determining the alarm relationship further comprises determining a plurality of association rules indicating a relationship between the first subset of alarms and the second subset of alarms; Wherein, determining the alarm relationship further comprises evaluating the plurality of association rules to determine an association rule of the plurality of association rules having a highest likelihood of representing a relationship between the first subset of alarms and the second subset of alarms.

8. The non-transitory computer readable medium of claim 7, wherein: The operation data includes at least one of the following items: current data representing current provided by an electrical device of the plurality of interrelated devices, power data representing power provided by the electrical device, or voltage data representing voltage provided by the electrical device; or Temperature data indicative of an ambient temperature of the electrical device provided by the electrical device.

9. The non-transitory computer readable medium of claim 8, wherein: Determining the device relationships includes normalizing the operational data about a single polling frequency.

10. The non-transitory computer readable medium of claim 9, wherein: Normalizing the operational data with respect to a single polling frequency includes rounding data measurements to the nearest period of the single polling frequency and interpolating data measurements for each period of the single polling frequency for which no data measurements exist.

11. The non-transitory computer readable medium of claim 10, wherein: Determining the device relationships further includes performing at least one of a Bayesian network estimation technique, a correlation coefficient technique, an ordinary least squares technique, or a constrained regression optimization technique to generate a device map indicating relationships between each device in the plurality of interrelated devices.

12. The non-transitory computer readable medium of claim 7, wherein: Determining the alarm relationship further includes: presenting the association rules to the user; and A tag for the association rule is received from the user.

13. A method for automatically generating a data center network map for automatic alarm consolidation, comprising: receiving operational data indicative of at least one of a power path, a cooling zone, a temperature zone, or a communication path from each of a plurality of interrelated devices; determining a device relationship between each device in the plurality of interrelated devices based on the operational data; receiving a corresponding alert of a plurality of alerts from each device of the plurality of interrelated devices; determining, based on the plurality of alarms, an alarm relationship between at least two alarms in the plurality of alarms; merging the plurality of alarms into a merged alarm based on the determined device relationship and based on the determined alarm relationship; as well as providing the merged alert to a user, wherein determining the alarm relationship comprises generating a first subset of the alarms of the plurality of alarms, the first subset of the alarms being received from the plurality of interrelated devices at a first time; and generating a second subset of the alarms of the plurality of alarms, the second subset of the alarms being received from the plurality of interrelated devices at a second time, and the first time is different from the second time; wherein determining the alarm relationship further comprises determining a plurality of association rules indicating a relationship between the first subset of alarms and the second subset of alarms; Wherein, determining the alarm relationship further comprises evaluating the plurality of association rules to determine an association rule of the plurality of association rules having a highest likelihood of representing a relationship between the first subset of alarms and the second subset of alarms.

Images