Fault monitoring and handling methods for EMS management system

Abstract

The present application relates to a fault monitoring and processing method for an EMS management system. On the one hand, different EMS controllers are divided into different clusters, which facilitates the collaborative work of multiple EMS controllers when there are many power units to be managed and the number of EMS controllers is also large. On the second hand, in a single cluster, multiple first-level EMS controllers and multiple second-level EMS controllers are set up. The first-level EMS controller, as the upper layer, can be responsible for global scheduling and coordination, and the second-level EMS controller, as the lower layer, is responsible for the specific control operations of downstream power units, achieving the purpose of multi-layer architecture design. On the third hand, by designing a master-slave mechanism in the first-level EMS controller, the first-level master EMS controller is re-elected when a fault occurs in the first-level master EMS controller, and when a fault occurs in the second-level EMS controller, all the power units managed by it are transferred to the first-level EMS controller to which it belongs for management, thereby realizing fault migration under the multi-layer management architecture and ensuring the continuity and stability of power supply.

Description

Technical Field

[0001] The present application relates to the technical field of green and low-carbon industries, and in particular to a fault monitoring and processing method for an EMS management system. Background Art

[0002] The cloud-based energy storage management system (EMS) is a collection of software and hardware that uses cloud computing technology to manage, monitor and optimize energy storage devices (such as battery energy storage systems). It is a collaborative effort between the cloud platform (cloud side) and the EMS controller (device side). Through real-time monitoring and intelligent control of all aspects of energy production, distribution and consumption, it achieves efficient management and optimal configuration of energy in a clustered manner on the cloud.

[0003] In the architecture of the traditional EMS management system, all equipment data is reported to the cloud platform through a single-layer EMS controller. The single-layer EMS controller is connected to the cloud platform at the top and to one or more energy storage cabinets at the bottom. Each single-layer EMS controller manages and controls one or more energy storage cabinets.

[0004] However, the architecture of the traditional EMS management system has a flaw: after the EMS controller fails, the management and control of the energy storage cabinet will be lost. This is because the traditional EMS management system uses a single-layer EMS controller, which will produce a single point of failure. Once a failure occurs, the energy storage cabinet cannot be controlled, and the continuity and stability of power supply cannot be guaranteed during power supply. Summary of the invention

[0005] Based on this, it is necessary to provide a fault monitoring and processing method for an EMS management system to address the problem that the traditional EMS management system architecture will lose the management and controller of the energy storage cabinet after the EMS controller fails.

[0006] The present application provides a fault monitoring and processing method for an EMS management system, including:

[0007] Divide all EMS controllers, all energy storage devices, all power generation units and all distributed resources into different clusters; each cluster includes multiple first-level EMS controllers and multiple second-level EMS controllers, and the multiple first-level EMS controllers include a first-level master EMS controller and multiple first-level slave EMS controllers. Each first-level master EMS controller manages multiple second-level EMS controllers downstream, and each first-level slave EMS controller manages multiple second-level EMS controllers downstream;

[0008] After each polling rest interval, all clusters are polled one by one to determine whether any cluster has a parameter failure;

[0009] If any cluster has a parameter fault, the power consumption units of the cluster with the parameter fault are allocated to the cluster without the parameter fault;

[0010] If no cluster with parameter failure occurs, further determine whether any cluster with primary main EMS controller failure occurs;

[0011] If any cluster has a primary master EMS controller failure, a re-election of the primary master EMS controller will be performed in the cluster where the primary master EMS controller failure occurs;

[0012] If there is no cluster with a primary main EMS controller failure, further determine whether there is any cluster with a secondary EMS controller failure;

[0013] If any cluster has a faulty secondary EMS controller, all power consumption units managed by the faulty secondary EMS controller in the cluster will be transferred to the primary EMS controller to which the faulty secondary EMS controller belongs for management;

[0014] Enter the polling rest interval, stop polling and wait for the next polling to start.

[0015] The present application relates to a fault monitoring and processing method for an EMS management system. On the one hand, different EMS controllers are divided into different clusters, which facilitates the collaborative work of multiple EMS controllers when there are many power units to be managed and the number of EMS controllers is also large. On the second hand, in a single cluster, multiple first-level EMS controllers and multiple second-level EMS controllers are set up. The first-level EMS controller, as the upper layer, can be responsible for global scheduling and coordination, and the second-level EMS controller, as the lower layer, is responsible for the specific control operations of downstream power units, achieving the purpose of multi-layer architecture design. On the third hand, by designing a master-slave mechanism in the first-level EMS controller, the first-level master EMS controller is re-elected when a fault occurs in the first-level master EMS controller, and when a fault occurs in the second-level EMS controller, all the power units managed by it are transferred to the first-level EMS controller to which it belongs for management, thereby realizing fault migration under the multi-layer management architecture and ensuring the continuity and stability of power supply. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1 A flowchart of a fault monitoring and processing method for an EMS management system provided in one embodiment of the present application.

[0017] Figure 2 A system structure diagram of an EMS management system provided in one embodiment of the present application.

[0018] Reference numerals:

[0019] 10- cloud server; 20- cluster; 210- first-level EMS controller; 220- second-level EMS controller;

[0020] 230-energy storage converter; 240-energy storage device; 30-first database; 40-second database;

[0021] 50-Electricity Unit. DETAILED DESCRIPTION

[0022] In order to make the purpose, technical solution and advantages of this application more clear, the following is a further detailed description of this application in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described here are only used to explain this application and are not used to limit this application.

[0023] The present application provides a fault monitoring and processing method for an EMS management system. It should be noted that the fault monitoring and processing method for an EMS management system provided by the present application is applicable to any type of EMS management system.

[0024] In addition, the fault monitoring and processing method of the EMS management system provided by the present application does not limit its execution subject. Optionally, the execution subject of the fault monitoring and processing method of the EMS management system provided by the present application can be the EMS management system. Specifically, the execution subject of the fault monitoring and processing method of the EMS management system provided by the present application can be the cloud server in the EMS management system.

[0025] like Figure 1 As shown, in one embodiment of the present application, the fault monitoring and processing method of the EMS management system includes:

[0026] S100, all EMS controllers, all energy storage devices, all power generation units and all distributed resources are divided into different clusters. Each cluster includes multiple first-level EMS controllers and multiple second-level EMS controllers, and the multiple first-level EMS controllers include a first-level master EMS controller and multiple first-level slave EMS controllers. Each first-level master EMS controller downstream manages multiple second-level EMS controllers, and each first-level slave EMS controller downstream manages multiple second-level EMS controllers.

[0027] S200, after each polling rest interval, all clusters are polled one by one to determine whether any cluster has a parameter failure.

[0028] S300: If any cluster has a parameter fault, the power consumption units of the cluster having the parameter fault are allocated to a cluster without the parameter fault.

[0029] S400: If any cluster with a parameter failure does not appear, further determine whether any cluster with a primary main EMS controller failure appears.

[0030] S510: If any cluster has a primary master EMS controller failure, a primary master EMS controller is re-elected in the cluster having the primary master EMS controller failure.

[0031] S520: If any cluster with a primary main EMS controller failure does not appear, further determine whether any cluster with a secondary EMS controller failure appears.

[0032] S521, if any cluster has a secondary EMS controller failure, all power consumption units managed by the secondary EMS controller with the failure in the cluster will be transferred to the primary EMS controller to which the secondary EMS controller with the failure belongs for management.

[0033] S600, entering the polling rest interval, stopping polling and waiting for the next polling to start.

[0034] Specifically, in S100, all EMS controllers, all energy storage devices, all power generation units and all distributed resources in this embodiment are organized into multiple different clusters. Figure 2 shown.

[0035] Optionally, in cluster design, redundant devices are configured for each key node (such as energy storage devices and controllers). When a node fails, the redundant device can immediately take over the task to ensure uninterrupted power supply. In a single cluster, multiple first-level EMS controllers and multiple second-level EMS controllers are set up, and the first-level EMS controllers and the second-level EMS controllers are mutually redundant.

[0036] The first-level EMS controller is further divided into the first-level main EMS controller and multiple EMS controllers, and there is a layer of redundancy between them. When a node fails, the redundant device can immediately take over the task to ensure uninterrupted power supply.

[0037] When the cloud server detects a cluster failure, it takes immediate action.

[0038] There are two types of failures. One is parameter failure. We use a failover mechanism to allocate the power consumption units of the cluster with parameter failure to the cluster without parameter failure. The other is the failure of the EMS controller, which is a communication or management failure. At this time, we can use redundancy to take over management and control tasks in a timely manner to ensure the normal operation of the EMS management system.

[0039] The power consumption unit varies according to the power supply service provided by the entire EMS management system. For example, the power consumption unit can be the electrical appliances of residents. The entire EMS management system supplies power to the electrical appliances of residents. Figure 2 The cluster in supplies power to residents' electrical appliances. Under the failover mechanism, S300 is executed, that is, all power consumption units under the failed cluster are managed by the cluster without parameter failure and are supplied with power by the cluster without parameter failure.

[0040] In this embodiment, the present application relates to a fault monitoring and processing method for an EMS management system. On the one hand, different EMS controllers are divided into different clusters, which facilitates the collaborative work of multiple EMS controllers when there are many power units to be managed and the number of EMS controllers is also large. On the second hand, in a single cluster, multiple first-level EMS controllers and multiple second-level EMS controllers are set up. The first-level EMS controller as the upper layer can be responsible for global scheduling and coordination, and the second-level EMS controller as the lower layer is responsible for the specific control operation of the downstream power units, thereby achieving the purpose of multi-layer architecture design. On the third hand, by designing a master-slave mechanism in the first-level EMS controller, the first-level master EMS controller is re-elected when a fault occurs in the first-level master EMS controller, and when a fault occurs in the second-level EMS controller, all the power units managed by it are transferred to the first-level EMS controller to which it belongs for management, thereby realizing fault migration under the multi-layer management architecture and ensuring the continuity and stability of power supply.

[0041] In one embodiment of the present application, S200 includes, that is, after each polling rest interval, polling all clusters one by one to determine whether any cluster with parameter failure occurs, including:

[0042] S210: Select a cluster and obtain at least one key parameter of the cluster.

[0043] S220: Select a key parameter and obtain the attention time and abnormal reference value of the key parameter.

[0044] S230, clearing the value of the timer.

[0045] S240, obtaining the value of the key parameter at the current system time node.

[0046] S250, comparing the value of the key parameter at the current system time node with the abnormal reference value, and determining whether the value of the key parameter at the current system time node is abnormal.

[0047] S261, if the value of the key parameter at the current system time node is abnormal, the value of the timer is increased by a preset time period on the original value.

[0048] S262, determining whether the value of the counter is greater than or equal to the attention time of the key parameter.

[0049] S263a, if the value of the counter is greater than or equal to the attention time of the key parameter, it is determined that the cluster has a parameter fault, and the subsequent steps are performed. If any cluster with a parameter fault occurs, the power consumption units of the cluster with the parameter fault are allocated to the cluster without the parameter fault.

[0050] S263b: If the value of the counter is less than the attention time of the key parameter, then after a preset time period, return to S240.

[0051] Specifically, the key parameters may be power output data, voltage, frequency, temperature, power and other parameters.

[0052] Each key parameter has a focus time, which can be within a time range of 10 seconds or more and 60 seconds or less. The focus time for each key parameter can be different or all the same, 60 seconds. The focus time is set to provide time tolerance. The duration of the abnormal situation needs to be greater than or equal to the focus time to trigger an alarm. Only then will the power consumption units of the cluster with parameter failure be allocated to the cluster without parameter failure.

[0053] Each key parameter has one or more abnormal reference values. If there are multiple abnormal reference values, an abnormal reference value range can be formed. The abnormal reference value is a qualitative consideration of whether an abnormal situation has occurred.

[0054] Optionally, you can set the attention time Tth = 60 seconds. This means that the abnormal duration of the key parameter must exceed this Tth to trigger the alarm. Our specific implementation method is to set a timer. The timer Ci (t) is used to record the abnormal duration of the key parameter t, and its initial value is 0.

[0055] Optionally, the abnormal reference values ​​of each key parameter can be set as follows:

[0056] The abnormal reference value of the power output data is the power output deviation threshold Tpo, for example, Tpo=10%.

[0057] The abnormal reference value of the voltage may be a voltage lower limit threshold Tvlow and a voltage upper limit threshold Tvhigh, for example, Tvlow=0.95V, for example, Tvhigh=1.05V.

[0058] The abnormal reference value of the frequency may be a frequency lower limit threshold Tflow and a frequency upper limit threshold Tfhigh, for example, Tflow=49.5 Hz, for example, Tfhigh=50.5 Hz.

[0059] The abnormal reference value of the temperature may be a temperature upper limit threshold Tthigh, for example, Tthigh=75 degrees Celsius.

[0060] The abnormal reference value of power may be a power factor lower limit threshold TpFlow, for example, TpFlow=0.9.

[0061] In this embodiment, a time threshold is set for each key parameter. An alarm is triggered only when the abnormality of the key parameter persists beyond the time threshold, providing time tolerance and making the abnormality determination result more accurate and more in line with the actual situation.

[0062] In one embodiment of the present application, the fault monitoring and processing method of the EMS management system further includes:

[0063] S264, if there is no abnormality in the value of the key parameter at the current system time node, return to S200, that is, return to the selection of a key parameter, obtain the focus time and abnormal reference value of the key parameter, until all key parameters of the cluster have been selected once.

[0064] S270, returning to S210, that is, returning to the step of selecting a cluster and obtaining at least one key parameter of the cluster until all clusters have been selected once.

[0065] S280, determining whether the values ​​of each key parameter at the current system time node of all clusters are normal.

[0066] S290, if the values ​​of each key parameter at the current system time node of all clusters are normal, it is determined that no cluster has a parameter failure, and the subsequent S400 is executed, that is, the subsequent further determination is performed as to whether any cluster has a main EMS controller failure.

[0067] Specifically, for each key parameter t, the occurrence of abnormal situations is judged:

[0068] 1) Detection of power output deviation;

[0069] Calculate the percentage of |Pout(t)-Pplan| in Pplan. If this percentage is greater than Tpo, then Ci(t)=Ci(t-1)+△t. That is, execute S261 to increase the value of the timer by the preset time period on the original value, and △t is the preset time period. If this percentage is less than or equal to Tpo, it is considered that there is no abnormal situation, and return to S200.

[0070] When Ci(t) is greater than or equal to Tth, it is determined that the cluster has a parameter failure, an alarm is triggered, and the cloud server identifies it as a power output failure.

[0071] 2) Voltage detection;

[0072] If V(t) is less than Tvlow, or V(t) is greater than Tvhigh, then Ci(t) = Ci(t-1) + △t. That is, execute S261 to increase the value of the timer by the preset time period on the original value, and △t is the preset time period. If this percentage is less than or equal to Tpo, it is considered that there is no abnormal situation, and return to S200.

[0073] When Ci(t) is greater than or equal to Tth, it is determined that the cluster has a parameter failure, an alarm is triggered, and the cloud server identifies it as a voltage failure.

[0074] 3) Frequency detection;

[0075] If F(t) is less than Tflow, or F(t) is greater than Tfhigh, then Ci(t) = Ci(t-1) + △t. That is, S261 adds the preset time period to the original value of the timer, and △t is the preset time period. If this percentage is less than or equal to Tpo, it is considered that there is no abnormal situation, and return to S200.

[0076] When Ci(t) is greater than or equal to Tth, it is determined that the cluster has a parameter failure, an alarm is triggered, and the cloud server identifies it as a frequency failure.

[0077] 4) Temperature detection;

[0078] If T(t) is greater than Tthigh, then Ci(t)=Ci(t-1)+△t. That is, S261 adds the preset time period to the original value of the timer, and △t is the preset time period. If this percentage is less than or equal to Tpo, it is considered that there is no abnormal situation, and return to S200.

[0079] When Ci(t) is greater than or equal to Tth, it is determined that the cluster has a parameter failure, an alarm is triggered, and the cloud server identifies it as a temperature failure.

[0080] 5) Detection of power factor;

[0081] If PF(t) is less than TpFflow, then Ci(t)=Ci(t-1)+△t. That is, S261 adds the preset time period to the original value of the timer, and △t is the preset time period. If this percentage is less than or equal to Tpo, it is considered that there is no abnormal situation, and return to S200.

[0082] When Ci(t) is greater than or equal to Tth, it is determined that the cluster has a parameter failure, an alarm is triggered, and the cloud server identifies it as a power factor failure.

[0083] Specific examples are as follows:

[0084] Assume that in a certain polling, Pout = 105MW, Pplan = 100MW, V(t) = 1.06 times the rated voltage, F(t) = 49.3Hz, T(t) = 77 degrees Celsius, and PF(t) = 0.88.

[0085] The power output deviation threshold is 1.05, the voltage upper limit threshold is 1.05, the voltage lower limit threshold is 1, the frequency upper limit threshold is 49.5, the frequency lower limit threshold is 47, the temperature upper limit threshold is 75 degrees Celsius, and the power factor threshold is 0.9.

[0086] Then the power output deviation is calculated to be 5%, which does not exceed the threshold, and it is determined that there is no abnormality, and the process returns to S200.

[0087] When the voltage is 1.06 and is greater than 1.05, it is determined that an abnormality occurs, and S261 is executed, and the value of the counter increases.

[0088] When the frequency 49.3 is greater than 49.5, it is determined that an abnormality occurs, and S261 is executed to increase the value of the counter.

[0089] When the temperature of 77 degrees Celsius is greater than 75 degrees Celsius, it is determined that an abnormality has occurred, and S261 is executed, and the value of the counter increases.

[0090] When the power factor 0.88 is greater than 0.9, it is determined that an abnormality occurs, S261 is executed, and the value of the counter increases.

[0091] In one embodiment of the present application, the S300 includes, that is, if any cluster with a parameter fault occurs, allocating the power consumption units of the cluster with the parameter fault to a cluster without a fault, including:

[0092] S310: If any cluster has a parameter failure, all clusters that have not had a failure are used as candidate clusters.

[0093] S320, selecting a cluster where a parameter fault occurs, and determining whether the cluster where the parameter fault occurs is in a failed operation state and has no replacement cluster assigned.

[0094] S331: If the cluster that generates the parameter failure is in a failed state and no backup cluster is assigned, a candidate cluster is selected.

[0095] S332: Determine whether the candidate cluster has an assigned label.

[0096] S333a: If the candidate cluster does not have an assigned label, calculate the assignment priority score of the candidate cluster.

[0097] S334, returning to S331, that is, returning to the step of selecting a candidate cluster until the allocation priority scores of all candidate clusters without allocated labels are obtained.

[0098] S335 , sorting the allocation priority scores in descending order, and taking the candidate cluster corresponding to the maximum allocation priority score as a substitute cluster.

[0099] S336: Give the backup cluster an allocated label.

[0100] S337: Allocate the power consumption units of the cluster where the parameter failure occurs to the backup cluster.

[0101] S338, return to S320, that is, return to the selection of a cluster with parameter failure, and determine whether the cluster with parameter failure is in a state where no backup cluster is assigned, until all clusters with parameter failure are in a state of failure and a backup cluster has been assigned.

[0102] Specifically, this embodiment selects the most suitable cluster to be used as a backup cluster for the faulty cluster from among multiple candidate clusters. Specifically, an allocation priority score algorithm is used, which comprehensively considers various key factors of the candidate clusters and calculates the priority score of each candidate cluster by assigning different weights to different factors. The higher the score, the more suitable the cluster is to be used as a backup cluster.

[0103] In this embodiment, a failover mechanism is provided. When a cluster fails, the system can automatically select the most suitable cluster to serve as a backup for the failed cluster from multiple surviving clusters, and allocate the power consumption units of the failed cluster to the backup cluster to ensure the continuity of power supply.

[0104] In one embodiment of the present application, the S333a includes, that is, the calculating of the allocation priority score of the candidate cluster includes:

[0105] S333a1, calculate the allocation priority score of the candidate cluster according to the following formula:

[0106] Formula 1

[0107] Among them, priority_score is the allocation priority score of the candidate cluster, S1 is the first parameter score, S2 is the second parameter score, S3 is the third parameter score, S4 is the fourth parameter score, α is the first parameter weight, β is the second parameter weight, γ is the third parameter weight, δ is the fourth parameter weight, available_capacity is the remaining output power currently available to the candidate cluster, required_capacity is the required power of the power unit of the cluster with parameter failure, SoH_score is the health status index of the candidate cluster, response_time is the time from the candidate cluster receiving the scheduling instruction to the start of executing the scheduling instruction, geographic_proximity_score is a score reflecting the geographical distance between the candidate cluster and the faulty cluster. The closer the candidate cluster is to the faulty cluster, the higher the score, because geographical proximity helps reduce power transmission losses and response delays.

[0108] Specifically, S1 is used to measure the ratio of the available capacity of the candidate cluster to the required capacity of the faulty cluster. The larger the value of S1, the greater the available capacity of the candidate cluster is than the required capacity, and it has a better ability to take over the power consumption units of the faulty cluster, thus increasing its priority.

[0109] S2 is used to measure the health status of the candidate cluster. SoH_score is the health status index of the candidate cluster, usually a value between 0 and 1, 1 indicates complete health, and 0 indicates complete failure. The larger the S2, the better the health status, the more stable and reliable the equipment status of the cluster, the lower the failure risk, and the higher the priority.

[0110] S3 is used to measure the response speed of the candidate cluster. Response_time is the time from when the candidate cluster receives the scheduling instruction to when it starts to execute the scheduling instruction. Since the shorter the response time, the better, we use To express, The larger it is, the shorter the response time is and the higher the score is.

[0111] S4 is used to measure the geographic distance between the candidate cluster and the fault cluster. Generally, the closer the distance, the higher the score, because geographic proximity helps reduce power transmission loss and response delay. The calculation formula of geographic_proximity_score in S4 is as follows:

[0112] Formula 2

[0113] Where geographic_proximity_score is a score reflecting the geographic distance between the candidate cluster and the fault cluster. is the Euclidean distance between candidate cluster i and fault cluster j. is the latitude of candidate cluster i in geographical coordinates. is the longitude in geographic coordinates of candidate cluster i. is the latitude of fault cluster j in geographical coordinates. is the longitude of fault cluster j in geographical coordinates.

[0114] The larger it is, the smaller the geographic_proximity_score will be.

[0115] The geographic_proximity_score value is between 0 and 1.

[0116] like is 0, then geographic_proximity_score is 1.

[0117] α is the first parameter weight, β is the second parameter weight, γ is the third parameter weight, and δ is the fourth parameter weight. Each weight parameter is used to adjust the influence of each factor on the final priority score. They are adjusted according to the design goals and actual needs of the system.

[0118] If the system has a high demand for capacity, you can increase the value of α. If the system is more concerned about the health status, you can increase the value of β. If the system requires fast response, you can increase the value of γ. If the system is required to pay more attention to the geographical distance between the candidate cluster and the fault cluster, you can increase the value of δ.

[0119] Suppose there are two candidate clusters A and B:

[0120] Cluster A: available_capacity = 100MW (MW is the abbreviation of Megawatt, a unit of power, which will not be explained again in the following text), SoH_score = 0.95, response_time = 5 seconds, geographic_proximity_score = 0.8. required_capacity = 70MW.

[0121] Cluster B: available_capacity=90MW, SoH_score=0.9, response_time=3 seconds, geographic_proximity_score=0.9.

[0122] required_capacity=70MW.

[0123] α=0.4, β=0.3, γ=0.2, δ=0.1.

[0124] By assigning priority scores to calculate the formula (i.e., Formula 2), we can calculate:

[0125] Cluster A's score:

[0126] priority_score_A=0.976

[0127] Cluster B Rating:

[0128] priority_score_B=0.8837

[0129] In this example, Cluster A has a higher assignment priority score, so it will be considered a more suitable backup cluster.

[0130] In this embodiment, when selecting the most suitable cluster to serve as a substitute for the faulty cluster from multiple clusters, the allocation priority score of each non-faulty cluster is calculated by assigning different weights to different factors, effectively evaluating the performance of the non-faulty cluster from multiple dimensions to ensure that no abnormalities occur during the handover of the power consumption unit.

[0131] In one embodiment of the present application, S337 includes, that is, allocating the power consumption units of the cluster with parameter failure to the backup cluster, including:

[0132] S337a, define the number N of power consumption units to be transferred each time. N is a positive integer.

[0133] S337b, adopting a step-by-step transfer method, N power consumption units in the cluster with parameter failure are transferred to the backup cluster every transfer time period until all power consumption units in the cluster with parameter failure are transferred to the backup cluster.

[0134] S337c, changing the running state of the cluster causing the parameter failure to a disabled state.

[0135] Specifically, a step-by-step transfer method is adopted to define the amount of power units to be transferred each time. Usually, it is calculated based on the available capacity and stability of the backup cluster, and the power units of the backup cluster are gradually increased to ensure stability. After all power units are successfully transferred, the use of the failed cluster is stopped and switched to the full power supply mode of the backup cluster.

[0136] In this embodiment, N load power units in the cluster with parameter failure are transferred to the backup cluster every other transfer time period through distributed transfer. This operation can prevent the occurrence of power instability. If all power units are transferred to the backup cluster at once, the backup cluster will have to perform high-power scheduling, which will cause a large delay. The step-by-step transfer method of this embodiment reduces the delay.

[0137] In one embodiment of the present application, after S337, that is, after allocating the power consumption units of the cluster with parameter fault to the cluster without fault, the fault monitoring and processing method of the EMS management system further includes:

[0138] S341, select a cluster where a parameter failure occurs.

[0139] S342: Determine whether the running status of the cluster where the parameter failure occurs is in a repaired state.

[0140] S343: If the running status of the cluster where the parameter fault occurs is in a repaired state, a functional test is initiated for the cluster where the parameter fault occurs to obtain data results of the functional test.

[0141] S344: Determine whether the cluster that has the parameter failure meets the reuse requirement based on the data result of the functional test.

[0142] S345a1, if the cluster that generates the parameter fault meets the reuse requirements, a step-by-step transfer method is adopted to transfer N power units in the backup cluster corresponding to the cluster that generates the parameter fault to the cluster that generates the parameter fault every other transfer time period, until all power units in the backup cluster corresponding to the cluster that generates the parameter fault are transferred to the cluster that generates the parameter fault.

[0143] S345a2, modifying the operating state of the cluster causing the parameter failure to a normal operating state.

[0144] S345a3, return to S341, that is, return to the step of selecting a cluster that generates parameter failure, until all clusters that generate parameter failure have been selected once.

[0145] Specifically, S344 satisfies the reuse requirement by calculating the health score of the cluster that generates the parameter failure to evaluate whether it can be reused.

[0146] The specific algorithm can be implemented using the cluster health score formula, as shown in Formula 3.

[0147] Formula 3

[0148] Among them, health_score is the cluster health score, stability_score is the power output stability score, A is the weight of power output stability, voltage_score is the voltage level score, B is the weight of voltage level, frequency_score is the frequency stability score, C is the weight of frequency stability, temperature_score is the temperature score, D is the weight of temperature, power_factor_score is the power factor score, E is the weight of power factor, SoH_score is the energy storage device monitoring status index score, F is the weight of energy storage device monitoring status index, capacity_scor is the remaining available capacity score, G is the weight of remaining available capacity, response_time_score is the response time score, H is the weight of response time, fault_history_score is the fault history score, I is the weight of fault history, communication_score is the data communication quality score, and J is the weight of data communication quality.

[0149] 1) Power output stability

[0150] Power output stability score calculation formula: stability_score = max(0, 100-(|actual output-planned output| / planned output)×2000)

[0151] If the actual output is exactly the same as the planned output, the stability_score is 100. If the deviation exceeds 5%, the stability_score will be reduced to 0.

[0152] 2) Voltage level

[0153] Voltage level score calculation formula: voltage_score=max(0,100-(|actual voltage-rated voltage| / rated voltage) ×2000)

[0154] Within ±5% of the rated voltage, the voltage_score is 100. Outside this range, the voltage_score decreases.

[0155] 3) Frequency stability

[0156] Frequency stability score calculation formula: frequency_score=max(0,100-(|actual frequency-standard frequency| / standard frequency) ×2000)

[0157] Within ±0.5Hz of the frequency, the frequency_score is 100. Outside this range, the frequency_score is reduced.

[0158] 4) Temperature

[0159] Temperature score calculation formula: temperature_score = max(0, 100-[(actual temperature-ideal temperature range) / tolerance temperature range) × 100]

[0160] If the temperature is within the ideal temperature range, the temperature_score is 100. If the temperature exceeds the tolerance range, the score drops to 0.

[0161] 5) Power factor

[0162] Power factor score calculation formula: power_factor_score=power_factor×100

[0163] The power factor is between 0 and 1, and if the power factor is 1, the power_factor_score is 100. If the power factor is 0.9, the score is 90. A power factor below 0.95 may indicate excessive reactive power, which can reduce grid efficiency and increase equipment load.

[0164] 6) Energy storage equipment health status index (SoH)

[0165] Energy storage equipment health status index score calculation formula: SoH_score=SoH×100

[0166] SoH is usually between 0 and 1. A SoH of 1 means the device is completely healthy, with a SoH_score of 100; a SoH of 0.8 means the SoH is 80%, with a SoH_score of 80. Devices with a SoH below 80% may need maintenance or replacement.

[0167] 7) Remaining available capacity

[0168] The remaining available capacity fraction calculation formula is:

[0169] capacity_score=(available_capacity / total_capacity) ×100

[0170] The remaining available capacity fraction is expressed as a percentage of the remaining available capacity to the total capacity. 100% corresponds to a capacity_score of 100, and 20% corresponds to a capacity_score of 20. At least 20% should be used as redundancy (depending on system design).

[0171] 8) Response time

[0172] Response time score calculation formula: response_time_score=max(0,100-((response time-ideal response time) / tolerance response time) ×100)

[0173] The shorter the response time, the better. Within the ideal response time range, the response_time_score is 100. Beyond the tolerance range, the response_time_score drops to 0.

[0174] 9) Fault history records

[0175] Fault history score calculation formula: fault_history_score=max[0,100-(number of faults×10)]

[0176] The fewer the number of faults, the higher the fault_history_score. Each time a historical fault occurs, the score decreases by 10 points. If there are 10 faults, the fault_history_score is 0.

[0177] 10) Data communication quality

[0178] Data communication quality score calculation formula: communication_score=max[0,100-(data packet loss rate×10000+delay(ms) / 10)]

[0179] The lower the packet loss rate and communication delay, the higher the communication_score. When the packet loss rate is 0 and the delay is 0, the communication_score is 100; when the packet loss rate is 0.01% (i.e. 0.0001) and the delay is 100ms, the communication_score is 90.

[0180] According to the actual application scenario, the weight of each parameter A, B, C, ... can be adjusted to reflect its importance in the overall health assessment. For example, if the temperature has a particularly large impact on the cluster, the weight of δ* can be increased, that is, D can be increased.

[0181] The specific method for determining whether the cluster with parameter failure meets the reuse requirements is:

[0182] If the cluster health score is 90-100 points, the cluster with parameter failure is very healthy after repair.

[0183] If the cluster health score is 70-89 points, the cluster with parameter failure is healthy after repair, but attention is required.

[0184] If the cluster health score is 60-69 points: The cluster with parameter failure is barely usable after repair and needs intervention as soon as possible.

[0185] If the cluster health score is below 60 points: The cluster with parameter failure is still unavailable after repair and needs to be processed immediately (it may be repaired again or processed in other ways, such as elimination).

[0186] It can be seen that the cluster health score of formula 3 uses more dimensions, 10, while the candidate cluster allocation priority score of formula 1 uses fewer dimensions, 4. This is because the cluster health score of formula 3 is used to determine whether the cluster has faults, while formula 1 further determines the candidate cluster allocation priority based on the cluster being healthy and fault-free, which represents the performance of the cluster.

[0187] Therefore, it can be seen that Formula 3 has more dimensions and includes some dimensions used in Formula 1.

[0188] The dimensions used by both Formula 1 and Formula 3 are overlapping dimensions:

[0189] 1) Energy storage equipment health status dimension: SoH_score7

[0190] 2) Remaining available capacity dimension: capacity_score

[0191] 3) Response time dimension: response_time_score

[0192] In this embodiment, after the original cluster that generated the parameter failure is repaired, the cluster health score of the cluster that generated the parameter failure is calculated to determine whether the cluster that generated the parameter failure can be reused. If the reuse adjustment is met, it can be switched back according to the aforementioned step-by-step transfer method. In this way, the equipment loss of each cluster in the entire system can be averaged, and a situation where a cluster is not put into use after a failure will not occur.

[0193] In one embodiment of the present application, S510 includes, that is, re-electing a primary master EMS controller in a cluster where a primary master EMS controller failure occurs, including:

[0194] S511 , determining whether there is any first-level slave EMS controller that has not failed in the cluster where the first-level master EMS controller fails.

[0195] S512a: If any one of the first-level slave EMS controllers in the cluster where the first-level master EMS controller fails does not fail, a non-failed first-level slave EMS controller is selected from the cluster where the first-level master EMS controller fails.

[0196] S512b, calculating the evaluation score of the first-level slave EMS controller that has not experienced a fault.

[0197] S512c, return to S512a, that is, return to selecting a non-faulty first-level slave EMS controller from the cluster where the first-level master EMS controller fault occurs, until the evaluation scores of all non-faulty first-level slave EMS controllers are obtained.

[0198] S512d, sort the evaluation scores in descending order, and use the first-level slave EMS controller corresponding to the maximum evaluation score as the new first-level master EMS controller.

[0199] Specifically, the EMS controller in each cluster adopts a two-layer architecture. The upper layer is responsible for global scheduling and coordination. It consists of a first-level master EMS controller and multiple first-level slave EMS controllers. The first-level slave EMS controller is upgraded to the master controller as a redundant configuration when the master controller fails, so that the control of the cloud platform is not interrupted. The second-level EMS controller on the second layer is responsible for specific execution operations and controls the energy storage cabinets below according to the instructions received. The management unit of the cloud platform monitors the heartbeats of the upper-level master and slave EMS controllers at the same time. If the heartbeat of the master EMS controller disappears, the cloud platform will give instructions to the slave EMS controller to upgrade it to the master EMS controller. The new master EMS controller tells the second-level EMS controller through the broadcast mechanism.

[0200] The master-slave election of the first-level EMS controller is implemented by the platform based on a multi-parameter path optimization algorithm. The algorithm calculates the evaluation score of each first-level slave EMS controller by comprehensively considering multiple key network and controller performance parameters, and thus selects the best first-level slave EMS controller as the new first-level master EMS controller.

[0201] The path quality can be used to calculate the evaluation score.

[0202] The evaluation score algorithm uses six key path quality parameters to evaluate the path quality between the cloud platform and the first-level slave EMS controller:

[0203] Network delay (Latency): Indicates the communication delay between the cloud platform and the controller, in milliseconds (ms). The smaller the delay, the better the path quality.

[0204] Network bandwidth: Indicates the available bandwidth between the cloud platform and the controller, measured in megabits per second (Mbps). The larger the bandwidth, the stronger the data transmission capacity.

[0205] Packet Loss Rate: Indicates the loss rate of data packets during communication, expressed in percentage (%). The lower the packet loss rate, the higher the reliability of communication.

[0206] Network jitter: indicates the fluctuation of network delay, measured in milliseconds (ms). The smaller the network jitter, the better the network stability.

[0207] Hop Count: Indicates the number of intermediate nodes in the routing path from the cloud platform to the controller. The fewer the hops, the more direct the path.

[0208] Controller Health Status: Indicates the health status of the controller itself, including CPU load, memory usage, disk IO, etc. The value range is 0 to 1, and the higher the value, the better.

[0209] Before calculation, the key parameters of path quality are normalized:

[0210] These key parameters of path quality are integrated into a unified scoring system, and each key parameter of path quality is normalized. The normalization formula is as follows:

[0211] Normalized Value = (Actual Value - Min Value) / (Max Value - Min Value) where Normalized Value is the normalized path quality key parameter, Actual Value is the path quality key parameter of the first-level slave EMS controller, Min Value is the minimum value of the path quality key parameters of all first-level slave EMS controllers, and Max Value is the maximum value of the path quality key parameters of all first-level slave EMS controllers.

[0212] For the key path quality parameters such as delay, packet loss rate, jitter and hop count, we take their inverse values ​​after normalization, because the smaller the values ​​of these key path quality parameters, the better.

[0213] The formula for negating the value is as follows:

[0214] Normalized Value (Inverted)=1-Normalized Value

[0215] Among them, Normalized Value (Inverted) is the value of the normalized path quality key parameter after inversion, and Normalized Value is the normalized path quality key parameter.

[0216] After normalization, we also need to remove noise:

[0217] The normalized value of each key path quality parameter will be weighted averaged according to the pre-set weight. Assuming the weight is W and the normalized key path quality parameter value is P, the calculation formula for the evaluation score is shown in Formula 4:

[0218] Formula 4

[0219] Among them, S is the evaluation score, is the normalized value of network delay, is the weight of network delay, is the normalized value of network bandwidth, is the weight of network bandwidth, is the normalized value of the packet loss rate, is the weight of packet loss rate, is the normalized value of network jitter, is the weight of network jitter, is the normalized value of the path hop count, is the weight of the path hop count, is the normalized value of the controller health status, is the weight of the controller health status.

[0220] Specific distance description:

[0221] Assume that there are two controllers A and B, and their path quality key parameter values ​​are as follows:

[0222] ControllerA: Network latency: 50ms, network bandwidth: 100Mbps, packet loss rate: 1%, network jitter: 5ms, path hops: 5, controller health status: 0.9.

[0223] ControllerB: Network latency: 70ms, network bandwidth: 150Mbps, packet loss rate: 2%, network jitter: 10ms, path hop count: 4, controller health status: 0.8.

[0224] The weights are set as: network delay (0.3), network bandwidth (0.2), packet loss rate (0.2), network jitter (0.1), path hop count (0.1), and controller health status (0.1).

[0225] Substituting these values ​​into the formula, we can calculate the composite score of each primary slave EMS controller. For example, the normalized value of latency is 50ms, assuming the maximum value of the normalized values ​​of all primary slave EMS controllers is 100ms, and the minimum value of the normalized values ​​of all primary slave EMS controllers is 0ms, the normalized + negated value of ControllerA is:

[0226] Normalized Latency for A=1-(50-0) / (100-0)=1-0.5=0.5

[0227] Other key parameters of path quality are calculated similarly, and the final evaluation scores of ControllerA and ControllerB are:

[0228] S_A=0.3×0.5+0.2×0.5+0.2×0.8+0.1×0.75+0.1×0.5+0.1×0.9=0.61.

[0229] S_B=0.3×0.3+0.2×0.75+0.2×0.6+0.1×0.5+0.1×0.6+0.1×0.8=0.55.

[0230] According to the calculation results, the first-level slave EMS controller with the highest evaluation score will be selected as the new first-level master EMS controller. In this example, ControllerA scored 0.61, while ControllerB scored 0.55. Therefore, ControllerA is selected as the new first-level master EMS controller. The new first-level master EMS controller is broadcast to all other first-level slave EMS controllers, as well as all second-level EMS controllers.

[0231] In this embodiment, since the first-level slave EMS controller does not usually participate in control tasks, the system design is relatively simplified. There is no need to deal with complex issues such as power unit balancing and data synchronization between multiple first-level EMS controllers. Maintenance and management are also relatively simple, and the administrator only needs to focus on the health of the master controller. In addition, the first-level master EMS controller is responsible for all control decisions, avoiding the problem of inconsistent decisions that may be caused by multiple EMS controllers working in parallel and avoiding conflicts.

[0232] In one embodiment of the present application, S510 includes, that is, re-electing a primary master EMS controller in a cluster where a primary master EMS controller failure occurs, and further includes:

[0233] S513a: If there is no first-level slave EMS controller that has not failed in the cluster where the first-level master EMS controller fails, it is determined that all first-level EMS controllers in the cluster where the first-level master EMS controller fails fail.

[0234] S513b, calculating the evaluation score of each secondary EMS controller.

[0235] S513c, sort the evaluation scores in descending order, and use the secondary slave EMS controller corresponding to the maximum evaluation score as a temporary primary master EMS controller.

[0236] Specifically, if all controllers in one layer fail, that is, all first-level EMS controllers fail, the cloud platform selects a temporary master controller from the second-level EMS controllers according to the optimal solution algorithm. Once any first-level EMS controller resumes working, the temporary master controller immediately restores the function of the second-level EMS controller, and the master control is transferred to the first-level EMS controller. The change of the master EMS controller is notified to all levels of EMS controllers through broadcast.

[0237] In this embodiment, when all the first-level EMS controllers on the first layer fail, an optimally performing one can be selected from the second-level EMS controllers on the second layer to temporarily become the first-level main EMS controller, without affecting the normal operation of the system and the management and control of other EMS controllers. Since the second-level EMS controllers on the second layer do not usually participate in control tasks, the system design is relatively simplified, and there is no need to deal with complex issues such as load balancing and data synchronization between multiple EMS controllers. Maintenance and management are also relatively simple, and the administrator only needs to focus on the health of the main controller.

[0238] In one embodiment of the present application, after S513c, that is, after sorting the evaluation scores in descending order and using the secondary slave EMS controller corresponding to the maximum evaluation score as a temporary primary master EMS controller, the process further includes:

[0239] S513d, determine whether any first-level EMS controller has recovered from a fault state to a normal operating state.

[0240] S513e: If any one of the first-level EMS controllers recovers from the fault state to the normal operating state, determine whether there are multiple first-level EMS controllers that recover from the fault state to the normal operating state.

[0241] S513f1: If there are multiple first-level EMS controllers that recover from a faulty state to a normal operating state, calculate the evaluation score of each first-level EMS controller that recovers from a faulty state to a normal operating state.

[0242] S513f2, sort the evaluation scores in descending order, use the first-level EMS controller corresponding to the maximum evaluation score that has recovered from the fault state to the normal operating state as the new first-level main EMS controller, and downgrade the temporary first-level main EMS controller to a second-level EMS controller.

[0243] S513g, if the number of first-level EMS controllers that have recovered from a faulty state to a normal operating state is not multiple, the only first-level EMS controller that has recovered from a faulty state to a normal operating state is used as the new first-level main EMS controller, and the temporary first-level main EMS controller is downgraded to a second-level EMS controller.

[0244] Specifically, when the faulty controller resumes operation, the cloud platform can re-elect a new master controller based on the optimal solution mentioned above, instead of having to elect it among the first-level EMS controllers that have recovered from a faulty state to a normal operating state, but instead expanding the election scope to all first-level EMS controllers.

[0245] In addition, a heartbeat is maintained between all secondary EMS controllers and downstream energy storage cabinets. Once the downstream energy storage cabinet detects a failure in a secondary EMS controller, it will report the failure to the cloud platform and directly jump to management by the primary EMS controller. Figure 2 The connection between the modules is a heartbeat connection. Figure 2 The dotted line in the figure is the MQTT communication connection method.

[0246] In this embodiment, when any one of the first-level EMS controllers recovers from a fault state to a normal operating state, the control and management rights are handed over to the first-level EMS controller of the first layer by calculating the evaluation score of each first-level EMS controller that recovers from a fault state to a normal operating state, so that the entire system has only one main EMS controller under any circumstances. In terms of system architecture and software implementation, a single main controller design is implemented, which is relatively simple, avoiding complex coordination and synchronization mechanisms between multiple controllers, and reducing the difficulty of development and maintenance. In addition, the responsibilities between the first and second layers are clear, with different priorities, and multi-level distribution is implemented, which effectively solves the problem of avoiding single point failure points while maximizing the reduction of the overall complexity of the system, making it easier to manage.

[0247] The present application also provides an EMS management system.

[0248] like Figure 2As shown, in one embodiment of the present application, the EMS management system includes a cloud server 10, multiple clusters 20, a first database 30 and a second database 40, and each cluster 20 is remotely connected to the cloud server 10. Each cluster 20 includes multiple first-level EMS controllers 210 and multiple second-level EMS controllers 220. Each first-level controller manages at least one second-level EMS controller 220. Each second-level EMS controller 220 manages at least one energy storage inverter 230 and at least one energy storage device 240. The EMS management system also includes multiple power consumption units 50.

[0249] Specifically, the cloud server 10 is equipped with a cloud platform, and the storage unit of the cloud platform uses a first database 30 and a second database 40 to store information. The first database 30 is a Master database, which is the main database. The second database 40 is a Slave database, which is a slave database. The master and slave (Master / Slave) databases store information of all controllers on both layers. The Master database has both read and write functions, and the Slave database can only read data from it, but cannot write data. There can be multiple Slave databases. When a problem occurs in the Master database, one of the multiple Slave databases is temporarily upgraded to the Master database.

[0250] Each cluster 20 has one or more power consumption units 50 under it.

[0251] The technical features of the above-described embodiments may be arbitrarily combined, and the execution order of the method steps is not limited. To make the description concise, not all possible combinations of the technical features in the above-described embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0252] The above-described embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present application. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.

Claims

1. A fault monitoring and processing method for an EMS management system, characterized in that: The method comprises: Divide all EMS controllers, all energy storage devices, all power generation units and all distributed resources into different clusters; each cluster includes multiple first-level EMS controllers and multiple second-level EMS controllers, and the multiple first-level EMS controllers include a first-level master EMS controller and multiple first-level slave EMS controllers. Each first-level master EMS controller manages multiple second-level EMS controllers downstream, and each first-level slave EMS controller manages multiple second-level EMS controllers downstream; After each polling rest interval, all clusters are polled one by one to determine whether any cluster has a parameter failure; If any cluster has a parameter fault, the power consumption units of the cluster with the parameter fault are allocated to the cluster without the parameter fault; If no cluster with parameter failure occurs, further determine whether any cluster with primary main EMS controller failure occurs; If any cluster has a primary master EMS controller failure, a re-election of the primary master EMS controller will be performed in the cluster where the primary master EMS controller failure occurs; If there is no cluster with a primary main EMS controller failure, further determine whether there is any cluster with a secondary EMS controller failure; If any cluster has a faulty secondary EMS controller, all power consumption units managed by the faulty secondary EMS controller in the cluster will be transferred to the primary EMS controller to which the faulty secondary EMS controller belongs for management; Enter the polling rest interval, stop polling and wait for the next polling to start; If any cluster with parameter fault occurs, allocating the power consumption units of the cluster with parameter fault to the cluster without parameter fault includes: If any cluster with parameter failure occurs, all clusters that have not failed are considered candidate clusters; Select a candidate cluster; Calculate the allocation priority score of the candidate cluster; Returning to the step of selecting a candidate cluster until the allocation priority scores of all candidate clusters without the allocated labels are obtained; Sort the allocation priority scores from large to small, and use the candidate cluster corresponding to the maximum allocation priority score as the backup cluster; Allocating power consumption units of the cluster with parameter failure to a backup cluster; The step of calculating the allocation priority score of the candidate cluster includes: The allocation priority score of the candidate cluster is calculated according to the following formula: Among them, priority_score is the allocation priority score of the candidate cluster, S1 is the first parameter score, S2 is the second parameter score, S3 is the third parameter score, S4 is the fourth parameter score, α is the first parameter weight, β is the second parameter weight, γ is the third parameter weight, δ is the fourth parameter weight, available_capacity is the remaining output power currently available for the candidate cluster, required_capacity is the required power of the power unit of the cluster with parameter failure, SoH_score is the health status index of the candidate cluster, response_time is the time from the candidate cluster receiving the scheduling instruction to the beginning of executing the scheduling instruction, geographic_proximity_score is a score reflecting the geographical distance between the candidate cluster and the faulty cluster.

2. The fault monitoring and processing method of the EMS management system according to claim 1 is characterized in that: After each polling rest interval, all clusters are polled one by one to determine whether any cluster with parameter failure occurs, including: Select a cluster and obtain at least one key parameter of the cluster; Select a key parameter and obtain the attention time and abnormal reference value of the key parameter; Clear the timer value to zero; Get the value of the key parameter at the current system time node; Compare the value of the key parameter at the current system time node with the abnormal reference value to determine whether the value of the key parameter at the current system time node is abnormal; If the value of the key parameter at the current system time node is abnormal, the value of the timer is increased by a preset time period on the original value; Determine whether the value of the counter is greater than or equal to the attention time of the key parameter; If the value of the counter is greater than or equal to the attention time of the key parameter, it is determined that the cluster has a parameter fault, and the subsequent steps are performed. If any cluster with a parameter fault occurs, the power consumption units of the cluster with the parameter fault are allocated to the cluster without the parameter fault. If the value of the counter is less than the attention time of the key parameter, then after a preset time period, the method of obtaining the value of the key parameter at the current system time node is returned.

3. The fault monitoring and processing method of the EMS management system according to claim 2 is characterized in that: After each polling rest interval, all clusters are polled one by one to determine whether any cluster with parameter failure occurs, and further comprising: If the value of the key parameter at the current system time node does not show any abnormality, then return to the step of selecting a key parameter, obtaining the focus time and abnormal reference value of the key parameter, until all key parameters of the cluster have been selected once; Returning to the step of selecting a cluster and obtaining at least one key parameter of the cluster until all clusters have been selected once; Determine whether the values ​​of each key parameter at the current system time node of all clusters are normal; If the values ​​of each key parameter at the current system time node of all clusters are normal, it is determined that no cluster has a parameter failure, and the subsequent process is performed to further determine whether any cluster has a main EMS controller failure.

4. The fault monitoring and processing method of the EMS management system according to claim 3 is characterized in that: Before selecting a candidate cluster, the method further includes: A cluster with a parameter fault is selected to determine whether the cluster with the parameter fault is in a failed operation state and a backup cluster is not allocated; If the cluster that generates the parameter failure is in a failed state and no backup cluster is assigned, then selecting a candidate cluster is performed; After allocating the power consumption units of the cluster with parameter failure to the backup cluster, the method further includes: Return to the step of selecting a cluster with parameter failure, and determine whether the cluster with parameter failure is in a state where no backup cluster is allocated, until all clusters with parameter failure are in a state where failure occurs and backup clusters are allocated.

5. The fault monitoring and processing method of the EMS management system according to claim 4 is characterized in that: After selecting a candidate cluster and before calculating the allocation priority score of the candidate cluster, the method further includes: Determine whether the candidate cluster has an assigned label; If the candidate cluster does not have an assigned label, then calculating the assignment priority score of the candidate cluster is performed; After sorting the allocation priority scores in descending order and selecting the candidate cluster corresponding to the maximum allocation priority score as the substitute cluster, and before allocating the power consumption units of the cluster with parameter failure to the substitute cluster, the method further includes: Give the backup cluster an assigned label.

6. The fault monitoring and processing method of the EMS management system according to claim 5 is characterized in that: The step of allocating the power consumption units of the cluster with parameter failure to the backup cluster includes: Define the number of electricity consumption units N transferred each time; N is a positive integer; A step-by-step transfer method is adopted to transfer N power consumption units in the cluster with parameter failure to the backup cluster every transfer time period until all power consumption units in the cluster with parameter failure are transferred to the backup cluster; Change the running status of the cluster that caused the parameter failure to disabled.

7. The fault monitoring and processing method of the EMS management system according to claim 6 is characterized in that: After allocating the power consumption units of the cluster with parameter fault to the cluster without parameter fault, the method further includes: Select a cluster that produces parameter failure; Determine whether the running status of the cluster where the parameter failure occurred has been repaired; If the running status of the cluster where the parameter fault occurs is in the repaired state, a functional test is initiated for the cluster where the parameter fault occurs to obtain the data results of the functional test; Based on the data results of the functional test, determine whether the cluster with parameter failure meets the reuse requirements; If the cluster with parameter failure meets the reuse requirement, a step-by-step transfer method is adopted to transfer N power consumption units in the backup cluster corresponding to the cluster with parameter failure to the cluster with parameter failure every other transfer time period until all power consumption units in the backup cluster corresponding to the cluster with parameter failure are transferred to the cluster with parameter failure; Change the running state of the cluster causing the parameter failure to a normal running state; Return to the step of selecting a cluster that generates parameter failures until all clusters that generate parameter failures have been selected once.

8. The fault monitoring and processing method of the EMS management system according to claim 7, characterized in that: The re-election of the primary master EMS controller in the cluster where the primary master EMS controller failure occurs includes: Determine whether there is any first-level slave EMS controller that has not failed in the cluster where the first-level master EMS controller fails; If any one of the first-level slave EMS controllers in the cluster where the first-level master EMS controller fails does not fail, a non-failed first-level slave EMS controller is selected from the cluster where the first-level master EMS controller fails; Calculate the evaluation score of the primary slave EMS controller that has not failed; Returning the method of selecting a non-faulty first-level slave EMS controller from the cluster where the first-level master EMS controller fault occurs, until the evaluation scores of all non-faulty first-level slave EMS controllers are obtained; The evaluation scores are sorted in descending order, and the first-level slave EMS controller corresponding to the maximum evaluation score is used as the new first-level master EMS controller.

9. The fault monitoring and processing method of the EMS management system according to claim 8, characterized in that: The re-election of the primary master EMS controller in the cluster where the primary master EMS controller failure occurs also includes: If there is no first-level slave EMS controller that has not failed in the cluster where the first-level master EMS controller fails, it is determined that all first-level EMS controllers in the cluster where the first-level master EMS controller fails fail; Calculate the evaluation score of each secondary EMS controller; The evaluation scores are sorted in descending order, and the secondary slave EMS controller corresponding to the maximum evaluation score is used as a temporary primary master EMS controller.

10. The fault monitoring and processing method of the EMS management system according to claim 9, characterized in that: After the evaluation scores are sorted in descending order and the secondary slave EMS controller corresponding to the maximum evaluation score is used as a temporary primary master EMS controller, the method further includes: Determine whether any primary EMS controller has recovered from a fault state to a normal operating state; If any one of the first-level EMS controllers recovers from the fault state to the normal operating state, determining whether the number of the first-level EMS controllers that recovers from the fault state to the normal operating state is multiple; If there are multiple first-level EMS controllers that recover from a fault state to a normal operating state, then the evaluation score of each first-level EMS controller that recovers from a fault state to a normal operating state is calculated; The evaluation scores are sorted in descending order, and the first-level EMS controller corresponding to the maximum evaluation score that has recovered from the fault state to the normal operating state is used as the new first-level main EMS controller, and the temporary first-level main EMS controller is downgraded to a second-level EMS controller; If the number of first-level EMS controllers that recover from a faulty state to a normal operating state is not multiple, the only first-level EMS controller that recovers from a faulty state to a normal operating state will be used as the new first-level main EMS controller, and the temporary first-level main EMS controller will be downgraded to a second-level EMS controller.

Images