CN117119950A

CN117119950A - Systems and methods for reducing alarm nuisance behavior in electrical systems

Info

Publication number: CN117119950A
Application number: CN202280026969.9A
Authority: CN
Inventors: J·门泽尔; J·A·比克尔
Original assignee: Schneider Electric USA Inc
Current assignee: Schneider Electric USA Inc
Priority date: 2021-03-31
Filing date: 2022-03-30
Publication date: 2023-11-24
Also published as: CN117461013A; CN117425831A

Abstract

Systems and methods for reducing alarm nuisance behavior in electrical systems are disclosed herein. In one aspect, a method for reducing alarm nuisance behavior includes processing electrical measurement data from or derived from energy-related signals captured or derived by at least one intelligent electronic device in an electrical system to identify events in the electrical system, and alarms triggered in response to identified events and/or other events in or associated with the electrical system. Information related to at least the identified event and the identified alert may be aggregated, and the aggregated information may be analyzed to identify at least one alert nuisance behavior. The at least one action may be taken or performed based on or in response to the at least one identified alarm nuisance behavior.

Description

Systems and methods for reducing alarm nuisance behavior in electrical systems

Cross Reference to Related Applications

The present application claims the benefits and priorities of U.S. provisional application No. 63/168,517, filed on 3 months 31 in 2021, U.S. provisional application No. 63/175,274, filed on 15 months 4 in 2021, and U.S. provisional application No. 63/287,835, filed on 9 in 2021, which are filed according to 35 u.s.c. ≡119 (e), and are incorporated herein by reference in their entirety.

Technical Field

The present disclosure relates generally to electrical systems, and more particularly to systems and methods related to reducing alarm nuisance behavior in electrical systems.

Background

The ever changing world of energy makes optimizing power reliability, energy costs, and operating efficiency more challenging, for example in critical power environments (e.g., hospitals, data centers, airports, and manufacturing facilities). Due to the added electronic control equipment, the utility grid becomes more dynamic and the facility power distribution system becomes more complex and sensitive to power quality issues, threatening network stability. Competitive pressures and environmental regulations are pushing the desire for energy efficiency and commercial sustainability to be higher than ever before. Solving these challenges requires new digital tools specifically designed to enable faster response opportunities and risks associated with electrical/power system reliability and operational stability.

Power quality problems are a major cause of unexpected service outages and equipment failures/damages/malfunctions. Examples of deleterious effects on equipment that may be due to power quality issues include overheating of equipment components (e.g., motors, capacitors, cables, transformers, etc.), accelerated wear, premature aging of equipment components, failure and malfunction, and erroneous circuit breaker or relay operation.

Economic impacts resulting from power quality issues may include increased energy bills, additional financial penalties (e.g., penalties due to power interruption), and potentially detrimental effects on the environment (e.g., increased carbon footprint). The power quality problem may also disadvantageously result in increased demand electricity costs, increased electrical/power system losses, and increased voltage drops. Three examples of areas affected by power quality problems include: normal run time, asset condition, and energy efficiency. For example, system uptime may be affected by electrical installations that are inadvertently removed from service due to voltage drops, interruption, and/or under/over voltage conditions. In addition, nuisance tripping of the circuit caused by harmonics, voltage expansion, or transients may also result in reduced uptime. Assets and infrastructure (e.g., cables, transformers, capacitor banks, etc.) can be adversely affected by power quality problems and associated conditions. For example, equipment overheating, unexpected changes in design characteristics, and/or reduced service life are just a few of the problems caused by power quality anomalies. Finally, the efficient use of energy is also affected by power quality problems.

According to a particular example, the capacitor bank may be affected by power quality issues (e.g., harmonics) characterized as steady-state distortion of the voltage and/or current signals. Nonlinear electrical loads from Electric Arc Furnaces (EAFs), electrified railway systems, thyristor-based voltage and frequency altering devices have become an important harmonic generation source in electrical grids. These techniques inject a large amount of harmonic current into the electrical system, resulting in source voltage distortion in the power grid. Harmonics can adversely affect the normal operation of a capacitor bank in a number of ways (e.g., increase power loss, create harmonic resonance, increase harmonic current, cause fuse failure, and reduce the life of the capacitor bank through additional heating). Many of the above events will generate event data and alert data.

Disclosure of Invention

Described herein are systems and methods related to providing electrical system analysis. For example, the electrical system may be associated with at least one load, process, building, facility, ship, aircraft, or other type of structure. In addition, the electrical system may be associated with one or more components (e.g., customer segments), such as retail stores, offices, semiconductor factories, automotive manufacturing facilities, hotels, hospitals, data centers, food and beverage, and oil and gas, among others.

It is well known that electrical system analysis can be very time consuming and is typically based on fixed thresholds and business intelligence (e.g., data cubes, tools that allow expert users to access event and alert data, navigation, selection, filtering, combining, aggregating results, or zooming in on details). Existing tools and techniques typically require expert users to conduct manual surveys. In order to be able to analyze all details, a lot of effort and time is required to filter all data and identify relevant information. As is known, electrical system analysis requires considerable understanding of application areas and expertise to identify and analyze solutions to problems, understanding of the context of sites/parts/buildings, and a good understanding of driving loads and processes.

The prior art requires system operators to evaluate alarms, event propagation, alarm nuisance behavior, alarm pattern recognition, coincidence waveform information, load effects, event source location, related event analysis, historical alarm data analysis to avoid over focus, spatial environment, etc. In short, evaluating an alarm may be overwhelming; however, not evaluating an alarm can be risky and expensive. Alarm analysis is time consuming and requires additional time in addition to supporting on-site operations (e.g., power system engineers point out that after a significant problem in a data center they may be required up to 3 weeks to perform post-alarm analysis to ensure that all potential causes of an event are identified).

The alarm may be a powerful tool that quickly identifies problems such that the uptime is improved. However, even for experienced end users, alarms can be offensive, untimely, and overwhelming, especially in larger systems. Some events generate different types of alarms (e.g., PQ events, over-current, communication errors, etc.), which may exacerbate confusion and ambiguity, cause errors, and waste time and/or resources. Ironically (and perhaps more importantly), the alert may cause the end user to ignore the value and information provided by the power monitoring system (EPMS) because the end user may not know how the alerts are interrelated. Threads associated with understanding the importance of alert data are typically distributed over multiple sources, multiple alert types, and/or time ranges. Because of the volume, complexity and potential importance of alarms originating from the end-user's electrical system, a firm understanding of their relevance is essential for obtaining the greatest benefit from EPMS. And this may be a major obstacle in the near future as qualified power system engineers leave the workforce and available expertise becomes scarce.

Herein, for simplicity, the term EPMS is also used to refer to a Monitoring and Control System (MCS), a Power Monitoring System (PMS), or any other system that measures, derives, controls, and/or provides/reports information about an electrical system. A supervisory control and data acquisition (SCADA) system (e.g., an electrical SCADA, a manufacturing SCADA), a Building Management System (BMS), a Programmable Logic Controller (PLC), an input/output system and device, and/or any other system or combination of systems and/or devices capable of at least one of monitoring, measuring, deriving, collecting, processing, generating, analyzing, alerting, communicating, displaying, reporting, storing, and/or any other actions and/or processes associated with utility system(s) of a facility (e.g., WAGES: water, air, gas, electricity, steam) or a portion thereof may be considered relevant to the application. Additionally, diagnostic systems are used herein as part or subset of an EPMS for identifying, analyzing, determining, ascertaining, learning, teaching, providing, benefiting, and/or otherwise evaluating data to obtain a better understanding of the meaning of one or more data.

One goal of alert analysis and identification of abnormal conditions occurring within an electrical system is to suggest and optimize mitigation actions. This requires a good understanding of customer subdivisions, the type of load associated with (or likely to be affected by) the power event, and the criticality of a particular load to the customer process or building function. Thus, a deep understanding of the field and customer systems is the basic element of successfully analyzing alarms, determining the cause of abnormal conditions, and defining, selecting and/or prioritizing potential solutions and mitigations.

As will be appreciated from the discussion below, the disclosed systems and methods automatically examine large amounts of data to more quickly identify and resolve EPMS (or other sources), electrical system and/or equipment problems. They distinguish between noise (alarm nuisance behaviour) and related signals/data. They identify possible sources of nuisance (e.g., loss events and alert time stamped data) and enable the EPMS (or other source) to correct certain types of lost data (e.g., partially correct lost data) by exploiting other available data and expertise. The system and method automatically processes all available data, reducing the risk of ignoring important data or derived information in the analysis, as may occur to human experts operating within set time constraints. In addition, the disclosed systems and methods provide guidance for potential impacts and reasons in analysis (source location) and provide recommendations based on partial context (e.g., data center vs. industry vs. office, etc.), load type (e.g., motor, automotive industry process, HVAC, lighting, IT rack, etc.), and other libraries and settings.

In addition to the benefits described above, it will be readily appreciated that there are many other benefits associated with the disclosed systems and methods. For example, as will be further appreciated from the following discussion in the summary and detailed description of the disclosure, the disclosed systems and methods are capable of:

Simplifying customer troubleshooting to more quickly alleviate or solve the problem,

reducing data confusion to reduce customer confusion,

automated event analysis to reduce customer errors and omissions,

prioritizing the events to help the customer focus on the most important questions,

enabling services such as cause analysis, problem localization, impact, long term problems, improvement opportunities, etc., and

-providing custom event analysis based on customer type/subdivision.

In one aspect of the present disclosure, systems and methods related to reducing alarm nuisance behavior in electrical systems are provided. A method for reducing alarm nuisance behavior in an electrical system may include, for example, processing electrical measurement data from or derived from energy-related signals captured or derived by at least one Intelligent Electronic Device (IED) in the electrical system to identify events (e.g., power events) in the electrical system, and alarms triggered in response to identified events and/or other events (e.g., events other than identified power events, such as HVAC control changes or manufacturing SCADA process control actions or detected load state changes) in the electrical system (or related to the electrical system). Information related to at least the identified event and the identified alert may be aggregated, and the aggregated information may be analyzed (e.g., automatically and/or dynamically analyzed) to identify at least one alert nuisance behavior. In some embodiments, at least one action may be taken or performed based on (or in response to) at least one identified alarm nuisance behavior. For example, at least one potential mitigation or remedy for addressing the at least one identified alarm nuisance behavior may be identified, and one or more of the at least one potential mitigation or remedy may be selected and recommended (e.g., based on a particular user and/or customer segment type associated with the electrical system).

According to some embodiments of the present disclosure, the aggregated information includes information from at least one of: EPMS, SCADA systems (e.g., power SCADA, manufacturing SCADA), building Management Systems (BMS), I/O devices, and system users (e.g., user initiated actions). In some embodiments, the EPMS may include at least one IED responsible for capturing or deriving the energy-related signal.

According to some embodiments of the present disclosure, the aggregated information may be further analyzed to identify lost or incomplete data (e.g., due to the IED losing control power), and the impact of the lost or incomplete data on at least one identified alarm nuisance behavior. In some embodiments, the at least one identified alarm nuisance behavior is an indication of a suboptimal alarm health condition. Additionally, in some embodiments, the at least one action taken or performed based on or in response to the at least one identified alarm nuisance behavior includes at least one action for improving alarm health.

According to some embodiments of the present disclosure, the at least one identified alarm nuisance behavior comprises behavior indicative of at least one predefined or prescribed alarm nuisance behavior, user-defined (e.g., customized) alarm nuisance behavior, or learned alarm nuisance behavior. In some embodiments, the predefined or prescribed alarm nuisance behavior is defined based at least in part on good engineering practices, thresholds defined during one of the typical steps of the American National Standards Institute (ANSI)/international automation Institute (ISA) 18.2 alarm "audit and philosophy cycle" (A, B, C, D, H, I, J), or at commissioning of the field (without a formal process such as recommended by ISA 18.2, this may be equivalent to steps a through E), or prescribed thresholds (e.g., such as re-implementing prescribed thresholds used and tested in previous installations when constructing a data center in an update of a different new project or process). Additionally, in some embodiments, the learned alarm nuisance behavior is learned from analysis of data received from at least one of: system users, and I/O systems and IEDs (or other sources). In some embodiments, at least one predefined or prescribed alarm nuisance behavior, user-defined alarm nuisance behavior, or learned alarm nuisance behavior is based at least in part on customer segment type or load type.

According to some embodiments of the present disclosure, the at least one action taken or performed based on or in response to the at least one identified alarm nuisance action includes characterizing and/or quantifying the at least one identified alarm nuisance action. In some embodiments, characterizing includes grouping the at least one identified alarm nuisance behavior into one or more of a plurality of predefined or prescribed alarm nuisance behaviors, a plurality of user-defined alarm nuisance behaviors, or a plurality of learned alarm nuisance behaviors. The plurality of predefined or prescribed alarm nuisance behaviors, the plurality of user-defined alarm nuisance behaviors, or the plurality of learned alarm nuisance behaviors may include, for example, at least one of: stale alarm nuisance behavior, dithered alarm nuisance behavior, transient alarm nuisance behavior, and flood alarm nuisance behavior. In some embodiments, in response to determining that the at least one identified alarm nuisance behavior meets a predefined, prescribed, user-defined, or learned (validation of nuisance problems) threshold associated with one or more of a plurality of predefined or prescribed alarm nuisance behaviors, a plurality of user-defined alarm nuisance behaviors, or a plurality of learned alarm nuisance behaviors, the at least one identified alarm nuisance behavior is grouped into one or more of a plurality of predefined or prescribed alarm nuisance behaviors, a plurality of user-defined alarm nuisance behaviors, or a plurality of learned alarm nuisance behaviors.

According to some embodiments of the present disclosure, information related to at least one identified alarm nuisance behavior is pre-processed prior to characterizing and/or quantifying the at least one identified alarm nuisance behavior. In some embodiments, preprocessing includes identifying, filtering, and/or correcting errors in information related to at least one identified alarm nuisance behavior. Errors may be based on, for example, incorrect or incomplete data (e.g., incorrect timestamps).

According to some embodiments of the present disclosure, it may be determined whether the at least one identified alarm nuisance behavior satisfies a prescribed condition. In some embodiments, the prescribed condition includes a minimum occurrence of at least one identified alarm nuisance behavior within a given analysis period for treating the at least one identified alarm nuisance behavior as nuisance behavior for purposes of future analysis. In some embodiments, in response to at least one identified alarm nuisance behavior not meeting a prescribed condition, the at least one identified alarm nuisance behavior may be filtered or removed from a dataset, processing step, graphical presentation, or report that includes the at least one identified alarm nuisance behavior.

According to some embodiments of the present disclosure, information related to the characterized and/or quantified at least one identified alarm nuisance behavior may be appended to time series information associated with the identified alarm. The additional information may include, for example, information related to the time of occurrence(s) of the identified alarm, the frequency of occurrence(s) of the identified alarm, the duration(s) of the identified alarm, the amplitude(s) of the identified alarm, the severity(s) of the identified alarm, the location(s) of the identified alarm, the group or cluster of the identified alarm, and the like.

A system for reducing alarm nuisance behavior in an electrical system is also provided. In one aspect, a system for reducing alarm nuisance behavior in an electrical system includes at least one processor and at least one memory coupled to the at least one processor. The at least one device and the at least one memory of the processor may be configured to process electrical measurement data from or derived from energy-related signals captured or derived by at least the IEDs in the electrical system to identify events in the electrical system, and to trigger alarms in response to the identified events and/or other events in or related to the electrical system. Information related to at least the identified event and the identified alert may be aggregated and the aggregated information may be analyzed (e.g., automatically and/or dynamically analyzed) to identify at least one alert nuisance behavior. In some embodiments, at least one action may be taken or performed based on or in response to at least one identified alarm nuisance behavior. According to some embodiments of the present disclosure, the system corresponds to, includes, or is part of an EPMS.

As will be further appreciated from the discussion in the detailed description section of the present disclosure, the disclosed systems and methods for reducing alarm nuisance behavior in electrical systems automatically examine large amounts of data to more quickly identify and resolve system and/or equipment problems. This includes different nuisance actions such as tremor alarms, transient alarms and flood periods. The present invention also identifies and proposes to automatically correct lost events and their time stamps that create nuisance behavior that can obscure alarm analysis and visualization.

It is important to note that ANSI/ISA 18.2 expressly excludes from its scope any method or any definition of operation of how to identify alarm nuisance behavior, potential causes of alarm nuisance behavior, how to reduce alarm nuisance behavior, etc. More specifically, the criteria do not define or require any particular method for alert identification. Instead, the criteria (e.g., in section 8.2 of the criteria) indicate that an alarm may be identified by various good engineering practices or regulatory requirements. Regarding the alarm type (e.g., section 10.4 of the standard), the standard indicates that the alarm type should be carefully selected based on engineering judgment. Certain types, such as rate of change, bias, bad measurements, and controller output alarms, may be sources of nuisance alarms if they are not properly applied. Accordingly, it is an object of the disclosed systems and methods for reducing alarm nuisance behavior to provide techniques for identifying alarm nuisance behavior, causes of alarm nuisance behavior, and techniques for reducing alarm nuisance behavior, etc., such that greater clarity and value can be achieved from ANSI/ISA 18.2 in electrical system applications.

Other exemplary benefits of the disclosed systems and methods for reducing alarm nuisance behavior in electrical systems include:

Reducing data clutter and nuisance information, to optimize processing, communication and storage requirements,

simplifying customer evaluation and problem-solving,

minimizing the expertise required by the customer,

automated alert analysis to reduce customer errors and omissions,

improving EPMS value by saving time, improving efficiency and insight, and

unique key assessment with customer segment and load type.

Systems and methods related to analyzing alarms to characterize electrical system problems are also provided herein. In one aspect, a method for characterizing an alarm of an electrical system problem includes processing electrical measurement data from or derived from energy-related signals captured or derived by at least one IED in an electrical system to identify an event (e.g., a power event) in the electrical system, and triggering an alarm in response to the identified event. Information related to at least the identified event and/or the identified alert may be aggregated and the aggregated information may be analyzed (e.g., automatically or dynamically analyzed) to determine problems associated with the electrical system, as well as the origin (e.g., time, location), source (e.g., process, specific load), cause (e.g., process or load being something such as a motor start in a process), transition/evolution (e.g., change over time), and/or interrelationships of the problems associated with the electrical system. The problem(s) associated with the electrical system may, for example, result in unsatisfactory operation of the electrical system.

According to some embodiments of the present disclosure, the aggregated information includes information from at least one of: EPMS (or other source), SCADA systems (e.g., power SCADA, manufacturing SCADA), building Management Systems (BMS), I/O devices, and system users (e.g., user initiated actions). In some embodiments, the EPMS (or other source) may include at least one IED responsible for capturing or deriving the energy-related signal. In some embodiments, for example, the aggregated information may be further analyzed to determine problems associated with the EPM. Problems associated with EPMS may include, for example, problems associated with EPMS not being detected or problems present in the electrical system not being sufficiently detected. In some embodiments, problems associated with EPMS may be addressed by modifying one or more settings associated with the EPMS (or other source). It should be appreciated that the problems associated with EPMS may be solved in various other ways, as will be appreciated by those of ordinary skill in the art.

According to some embodiments of the present disclosure, a problem present in an electrical system is indicative of a health condition of the electrical system. The health of the electrical system may correspond to, for example, the condition of the electrical system (or sub-components, such as loads/devices, infrastructure, etc.) or the ability of the electrical system to perform or operate as intended. According to some embodiments of the present disclosure, the health of the electrical system is related to an alarm health of the electrical system, and the alarm health of the electrical system may be indicative of the health of the electrical system. The alert health of the electrical system may be determined, for example, based at least in part on an analysis of at least one of: the number, type, behavior, impact, severity, breadth, and location of the identified alarms.

According to some embodiments of the present disclosure, the impact of the identified alarm and/or the alarm period associated with the identified alarm on the electrical system may be determined. Additionally, actionable recommendations may be provided to reduce or eliminate the cause of the problem and the identified alarms and/or the measured impact of the alarm period associated with the identified alarms. According to some embodiments of the present disclosure, actionable recommendations are based on subsection types (e.g., retail, office, hotel, hospital, data center, food and beverage, and oil and gas), load types, and/or customer configurations and/or determined preferences.

According to some embodiments of the present disclosure, relevant information related to the identified alert may be transmitted accordingly. The relevant information may, for example, provide real-time perception of one or more of the following: alert health, alert configuration(s), alert operation, alert source(s), alert impact, alert absence, and recent alert activity. The relevant information may be provided, for example, on an alarm data dashboard, report, text, email, audible communication, and/or another alarm. In some cases, the alert data dashboard may be customizable and configurable (e.g., based on user segments and/or in response to user input). Additionally, one or more aspects of the alarm data dashboard may be user selectable and capable of providing further insight and analysis in response to one or more user actions (e.g., clicks, gestures, or other interactions) on the alarm data dashboard. For example, communication may be provided to at least one of: end users, device manufacturers, service teams, other individuals or parties of interest (e.g., individuals or parties of interest provide user actions), and/or libraries.

According to some embodiments of the present disclosure, the identified events and/or identified alarms may be analyzed to identify co-occurrence groups of identified events and/or identified alarms, and a rendition of the identified co-occurrence groups of identified events and/or identified alarms. According to some embodiments of the present disclosure, information about the identified co-occurrence group of identified events and/or identified alarms may be included in the aggregated information for determining whether there is a problem or potential problem in the electrical system and the source or cause of the problem that caused the suboptimal operation of the electrical system.

According to some embodiments of the present disclosure, the identified events may include power quality events and/or events capable of triggering a protection device (e.g., a protection relay). The power quality event may, for example, indicate a power quality problem in the electrical system.

According to some embodiments of the present disclosure, information is aggregated and/or problems present in the electrical system are determined based on subdivision types (e.g., retail, office, hotel, hospital, data center, food and beverage, and oil and gas) (i.e., electrical system problems are dynamic for each field/customer application) and/or load types. In addition, according to some embodiments of the present disclosure, aggregated information is utilized to analyze information related to impact and location to determine whether a problem is associated with an electrical system, as well as the origin, source, cause, transition/evolution, and/or interrelationship of the problem associated with the electrical system.

In accordance with some embodiments of the present disclosure, after identifying the origin, source, cause, transition/evolution, and/or interrelationship of a problem associated with an electrical system, one or more actions may be taken to increase or improve the operation of the electrical system. The one or more actions may include, for example, adjustment of one or more alarm parameters or thresholds. In some embodiments, these actions are performed automatically by a control system associated with the electrical system. For example, the control system may be communicatively coupled to at least one IED responsible for capturing or deriving energy-related signals, and/or to cloud-based systems, field/edge software, gateways, and other headend systems associated with electrical systems.

A system for analyzing an alarm to characterize an electrical system problem is also provided. In one aspect, a system for analyzing an alarm to characterize an electrical system problem includes at least one processor and at least one memory coupled to the at least one processor. The at least one device and the at least one memory of the processor may be configured to process electrical measurement data from or derived from energy-related signals captured or derived by at least one IED in the electrical system to identify events (e.g., power events) in the electrical system and alarms triggered in response to the identified events. Information related to at least the identified event and/or the identified alert may be aggregated and the aggregated information may be analyzed to determine the problem associated with the electrical system and the origin, source, cause, transition/evolution and/or interrelationship of the problem associated with the electrical system.

As will be further appreciated from the discussion in the detailed description section of the disclosure, the disclosed systems and methods for analyzing alarms to characterize electrical system problems analyze alarm data to determine correlations of alarms, system effects, spatial environments, segment types, and/or load types to determine the scope and effect of electrical events. The context data (of both the end user's electrical system and its EPM) can be used to determine the history, simultaneous and potential future impact of the event associated with the alert data. Guidance is provided in the analysis regarding possible effects and reasons (source location). In addition, recommendations may be provided based on subdivisions (data center vs. industry vs. office) and their corresponding typical loads (motors, automotive industry processes, HVAC, lighting, IT racks, etc.) and settings.

Since each energy consumer is unique in its energy usage, the priority, threshold, and/or merging of multiple alarms may also be unique. The disclosed systems and methods for analyzing alarms to characterize electrical system problems automatically process alarms to simplify indications from EPMs, which improves the ability of end users to respond in time. The purpose of this is to utilize the market segments/types of end users to evaluate alerts by their importance to the energy segment of a particular customer. For example, experiencing a voltage dip event in one market segment/type (e.g., semiconductor factory, data center, etc.) may have a more detrimental effect on operation than in a second market segment/type (e.g., business office building, etc.). In addition, the time of the event (e.g., day, night, etc.) in one market segment/type may be more detrimental than another market segment/type. The disclosed systems and methods for analyzing alarms to characterize electrical system problems facilitate the merging of alarm data to help end users identify problems for troubleshooting and provide causal analysis.

Example benefits of the disclosed systems and methods for analyzing alarms to characterize electrical system problems include:

simplify customer fault removal to identify problems faster,

minimize "false positives" from alert data to reduce customer confusion,

automated event analysis to reduce customer errors and omissions,

prioritizing alarms in order to focus on the most important electrical problems,

enabling new services such as cause analysis, problem localization, impact and effect, long term problems, etc., and

custom event analysis with customer segments/types.

Systems and methods related to analyzing alarms to address electrical system issues are also provided herein. In one aspect, a method for alerting to solve an electrical system problem includes processing electrical measurement data from or derived from energy-related signals captured or derived by at least one IED in an electrical system to identify at least one of: event(s) (e.g., power events) in an electrical system, alarm(s) triggered in response to identified event(s), and cause(s) and/or source(s) of identified event(s) and/or identified alarm(s). Information related to at least one of the following may be aggregated: identified events, identified alarms, and/or identified causes and/or origins of identified events and/or identified alarms, and the aggregated information may be analyzed to identify mitigation and/or remediation opportunities and techniques to address at least one of: the sign of the event, the source of the alarm and the identified cause/source of the identified event and/or the identified alarm.

The identified mitigation and/or remediation opportunities and techniques may include, for example, recommended changes to at least one of an operation, a device type, and an aspect of an EPMS associated with the electrical system to improve at least one of a characteristic, a parameter, a property, and an attribute of the electrical system or the EPMS. According to some embodiments of the present disclosure, based on the analysis of the aggregated information, at least one action (e.g., at least one type of mitigation and/or remediation) may be taken or performed to improve or address at least one of: an event symptom, an alarm source, and an identified cause/source of an identified event and/or an identified alarm.

According to some embodiments of the present disclosure, at least one of the location, event type, segment type, number, etc. of at least one of the event symptoms, alert sources, and identified causes and/or origins of the identified events and/or identified alerts may be used to determine at least one action to take or perform. Additionally, according to some embodiments of the present disclosure, prioritization of at least one action taken or performed may be recommended using at least one of: the location of at least one of the event symptom, the alert source, and the identified cause/origin of the identified event and/or the identified alert, the event type, the segment type, the number, etc. The recommended prioritization may also be based on, for example, at least one of: event symptom(s), alert source(s), and cause(s) identified and/or severity, impact, and popularity of at least one of origin(s).

According to some embodiments of the invention, after the at least one action is taken or performed, the validity of the at least one action may be assessed (e.g., verified and validated) (e.g., after a predetermined period of time). The evaluating may include analyzing and comparing information from the aggregation prior to taking or performing the at least one action with information from the aggregation after taking or performing the at least one action. The aggregated information before taking or performing the at least one action may be derived, for example, from energy-related signals captured or derived by the at least IED at a first time before taking or performing the at least one action. In addition, aggregated information after taking or performing the at least one action may be derived from energy-related signals captured or derived by the at least IED at a second time after taking or performing the at least one action.

According to some embodiments of the present disclosure, the validity of at least one action taken or performed is quantified (e.g., measured, verified, and confirmed) by evaluation. In response to the quantified effectiveness meeting or exceeding an acceptable threshold, a determination may be made as to whether at least one action needs to be continued to be taken or performed. Additionally, in response to the validity of the quantification not meeting or exceeding an acceptable threshold, it may be determined whether any adjustments to the at least one action taken or performed are required, or whether at least one alternative action should be taken or performed.

According to some embodiments of the present disclosure, segment and/or load type information associated with a first facility or location may be utilized to more effectively and/or proactively mitigate/remedy event symptoms, alert sources, and identified events and/or identified causes/origins of identified alerts at a second facility or location.

According to some embodiments of the present disclosure, the aggregated information includes information from at least one of: EPMS, SCADA systems (e.g., power SCADA, manufacturing SCADA), building Management Systems (BMS), I/O devices, system users (e.g., user initiated actions), and libraries. In some embodiments, the EPMS may include at least one IED responsible for capturing or deriving the energy-related signal. In some embodiments, for example, the aggregated information may be further analyzed to identify and/or determine mitigation/remediation opportunities and techniques/approaches/methods to address issues associated with EPMS (or other sources). Problems associated with EPMS may include, for example, problems associated with EPMS not being detected or problems present in the electrical system not being sufficiently detected. In some embodiments, the identified and/or determined mitigation/remedy opportunities and techniques/approaches/methods for addressing problems associated with EPMS include changing one or more settings associated with EPMS to address problems associated with EPMS. According to some embodiments of the present disclosure, the aggregated information may be further analyzed to determine the number, placement, type, and/or configuration of at least one IED to improve and/or enhance the quality of alarms and associated data in the EPMS.

According to some embodiments of the present disclosure, one or more alerts may be generated, or initiated using an EPMS associated with an electrical system to indicate an opportunity to alleviate/remedy at least one of the symptoms of the event, the source of the alert, and the cause/origin of the identified event and/or the identified alert. Additionally, in accordance with some embodiments of the present disclosure, the disclosed systems and methods may be used to plan and/or provide benefits (e.g., monetary benefits) associated with mitigating/remediating problems in an electrical system and/or EPMS associated with the electrical system.

A system for analyzing an alarm to address an electrical system problem is also provided. In one aspect, a system for analyzing an alarm to address an electrical system problem includes at least one processor and at least one memory coupled to the at least one processor. The at least one processor and the at least one memory device may be configured to: processing electrical measurement data from or derived from energy-related signals captured or derived by at least one IED in the electrical system to identify at least one of: event(s) (e.g., power events) in an electrical system, alarm(s) triggered in response to identified event(s), and cause(s) and/or source(s) of identified event(s) and/or identified alarm(s). Information related to at least one of the following may be aggregated: identified events, identified alarms, and/or identified causes and/or origins of identified events and/or identified alarms, and the aggregated information may be analyzed to identify mitigation and/or remediation opportunities and techniques to address at least one of: the sign of the event, the source of the alert, and the identified cause and/or origin of the identified event and/or the identified alert. According to some embodiments of the present disclosure, based on the analysis of the aggregated information, at least one action may be taken or performed to improve or address at least one of: an event symptom, an alarm source, and an identified cause and/or source of an identified event and/or an identified alarm.

As will be further appreciated from the discussion in the detailed description section of the disclosure, a final objective of the disclosed systems and methods for analyzing alarms to address electrical system problems is to understand potential abnormal conditions occurring within an electrical system and to suggest mitigating or remedial actions. Analysis of the alarm is an important factor in determining the cause(s) of the abnormal condition and how to resolve/alleviate/remedy it. In addition, analysis of the alert may help the end user verify the success (or failure) of the mitigation or remediation steps taken to correct the problem and learn how to optimize mitigation and remediation solution selection and implementation in the future. These problems may be related to difficulties associated with the end user's electrical system or even the EPMS itself. Because of the volume, complexity and potential importance of alarms originating from the end-user's electrical system, a firm understanding of their relevance is essential for obtaining the greatest benefit from EPMS. Resolution may be provided from data within the system originating from the end user or from recommendations determined from other similar types of subdivisions. Additionally, automatic auditing of alarms may be used to determine risks associated with EPMS configuration and/or insufficient coverage to ensure optimal performance of the EPMS. Alarm correlations may be evaluated and determined to facilitate faster understanding of future events and mitigation/remedial actions for future events. In addition, market segments and/or load information are used to recommend "tuned" alert settings.

Example benefits of the disclosed systems and methods for analyzing alarms to address electrical system issues include:

reduce the requirements for customer expertise and analysis,

improving the action time by more efficient and automated operation,

alert setting and report advice automation with market segments (and their respective load types),

providing specific mitigation suggestions for electrical system and EPMS problems,

prioritization of automated mitigation techniques,

validating mitigation effects by reporting and interfacing, and

enabling the service to evaluate and provide mitigation methods as needed.

According to some embodiments of the present disclosure, the above-described systems and methods (and other systems and methods disclosed herein) may be implemented using one or more of the above-described at least one IED described as capturing or deriving energy-related signals. Additionally, in some embodiments, the method (or portions thereof) may be implemented remotely from at least one IED, for example, on a diagnostic system and/or on other portions of an EPMS associated with an electrical system. In some embodiments, at least one IED may be coupled to measure an energy related signal, receive electrical measurement data at an input from the energy related signal or electrical measurement data derived from the energy related signal, and configured to generate at least one or more outputs. The output may be used to identify a power event in the electrical system, trigger other actions, and/or identify an alarm triggered in response to the identified power event. Examples of at least one IED may include an intelligent utility meter, a power quality meter, and/or another metering device (or device). The at least one IED may include, for example, a circuit breaker, a relay, a power quality correction device, an Uninterruptible Power Supply (UPS) filter, and/or a Variable Speed Drive (VSD). Additionally, in some embodiments, the at least one IED may include at least one virtual meter.

In some embodiments, each of the at least one IED is installed or located at a respective metering point of a plurality of metering points (e.g., physical or virtual metering points) in the electrical system, and the energy related signals captured or derived by each of the at least one IED are associated with the respective metering point. For example, at least one load (e.g., an electrical equipment or device) may be installed or located at each of a plurality of metering points, and each of the at least one IEDs may be configured to monitor the at least one load installed or located at the respective metering point at which the IED is installed or located. In the illustrated example, the energy related signal captured or derived by the at least one IED may be associated with at least one load.

As used herein, an IED (e.g., a portion of an EPMS) is a computing electronic device optimized to perform a particular function or group of functions. As described above, examples of IEDs include intelligent utility meters, power quality meters, and other metering devices. The IEDs may also be embedded in a Variable Speed Drive (VSD) Uninterruptible Power Supply (UPS), circuit breakers, relays, transformers, or any other electrical device. IEDs may be used to perform monitoring and control functions in various installations. Installation may include utility systems, industrial facilities, warehouses, office buildings or other commercial complexes, campus facilities, computing co-location centers, data centers, power distribution networks, and the like. For example, where the IED is a power monitoring device, it may be coupled to (or installed in) a power distribution system and configured to sense and store data as electrical parameters representative of the operating characteristics (e.g., voltage, current, waveform distortion, power, etc.) of the power distribution system. These parameters and characteristics may be analyzed by a user to assess potential performance, reliability, or issues related to power quality. The IEDs may include at least a controller (which in some IEDs may be configured to run one or more applications simultaneously, serially, or both), firmware, memory, communication interfaces, and connectors that connect the IEDs to external systems, devices, and/or components at any voltage level, configuration, and/or type (e.g., AC, DC). At least some aspects of the IED's monitoring and control functions may be embodied in a computer program accessible to the IED.

In some embodiments, the term "IED" as used herein may refer to a hierarchy of IEDs operating in parallel and/or in series. For example, an IED may correspond to a hierarchy of energy tables, power tables, and/or other types of resource tables. The hierarchy may include a tree-based hierarchy, such as a binary tree, a tree with one or more child nodes descending from each parent node or multiple parent nodes, or a combination thereof, where each node represents a particular IED. In some examples, the hierarchy of IEDs may share data or hardware resources and may execute shared software.

It should be appreciated that the energy related signals captured or derived by the at least one IED described above may include, for example, at least one of voltage signals, current signals, input/output (I/O) data, and derived or extracted values. In some embodiments, the I/O data includes at least one of a digital signal (e.g., two discrete states) and an analog signal (e.g., continuously variable). The digital signal may include, for example, at least one of an on/off state, a high/low state, a synchronization pulse, and any other representative bistable signal. In addition, the analog signals may include at least one of, for example, temperature, pressure, volume, space, rate, humidity, and any other physical or user/usage representative signals.

According to some embodiments of the present disclosure, the derived or extracted values include at least one of calculated, estimated, derived, developed, interpolated, extrapolated, estimated, and otherwise determined additional energy related values from at least one of the measured voltage signal and/or the measured current signal. In some embodiments, the derived value additionally or alternatively includes at least one of: active power, apparent power, reactive power, energy, harmonic distortion, power factor, amplitude/direction of harmonic power, harmonic voltage, harmonic current, inter-harmonic voltage, amplitude/direction of inter-harmonic power, amplitude/direction of sub-harmonic power, single-phase current, phase angle, impedance, sequence component, total voltage harmonic distortion, total current harmonic distortion, three-phase current, phase voltage, line voltage, spectral analysis, and/or other similar/related parameters. In some embodiments, the derived value additionally or alternatively comprises at least one energy-related characteristic comprising an amplitude, a direction, a phase angle, a percentage, a ratio, a level, a duration, an associated frequency component, an energy-related parameter shape, and/or a decay rate. According to some embodiments of the present disclosure, for example, the derived or extracted values may be linked to at least one process, load identification, or the like.

It should be appreciated that the energy related signals captured or derived by the at least one IED may include (or utilize) substantially any electrical parameter derived from, for example, at least one of the voltage and current signals (including the voltage and current itself). It should also be appreciated that the energy related signals may be captured/recorded and/or transmitted and/or recorded continuously or semi-continuously/periodically by the at least one IED, and that the power events and/or alarms may be detected/identified based on the energy related signals.

In some embodiments, identifying the power event from the electrical measurement data from or derived from the energy-related signal includes identifying a power quality event type of the power event. The power quality event type may include, for example, at least one of the following: voltage dip, voltage surge, voltage or current transient, temporary interruption, and voltage or current harmonic distortion. It should be appreciated that there are multiple types of power quality events and that there are certain characteristics of these types of power quality events. According to IEEE standard 1159-2019, for example, a voltage dip is a decrease at power frequency in root mean square voltage or current units to between 0.1 and 0.9 per unit (pu) over a duration of 0.5 cycles to 1 minute. Typical values are 0.1 to 0.9pu. In addition, according to IEEE standard 1159-2019, voltage scaling is the increase in root mean square voltage or current at power frequency over a duration from 0.5 cycles to 1 minute. It should be appreciated that IEEE standard 1159-2019 is one standard body (in this case IEEE) way of defining/characterizing power quality events. It should be appreciated that other standards defining power quality classes/events exist, such as the International Electrotechnical Commission (IEC), the American National Standards Institute (ANSI), and the like, which may have different descriptions or power quality event types, characteristics, and terminology. In some embodiments, the power quality event may be a customized power quality event (e.g., defined by a user or for a subsection and/or application such as the semiconductor industry).

In some embodiments, the above-described systems and methods may include one or more of the following features, alone or in combination with other features in some embodiments. In some embodiments, at least one of the alarms is triggered in response to the electrical measurement data being above one or more upper alarm thresholds or below one or more lower alarm thresholds. For example, an abnormal voltage condition as one example type of power event corresponds to the measured IED voltage being above one or more upper alarm thresholds or below one or more lower alarm thresholds.

In some embodiments, at least one alarm is additionally or alternatively triggered in response to a plurality of power events. For example, an alarm may be triggered in response to a dip and disruption (or other set of power events) occurring within a particular period of time. In another embodiment, many alarms may co-occur during the same time period (e.g., during a 10 minute time period) or during a sequence of events in which the alarms co-occur (also known as an "accident," also known as an "overlapping sequence of events (SooE)"). In one case we may have a short burst of alarms, which may be very intense but not persistent. These will be considered "alarm spikes". One example is one hundred twenty slump alarms, all of which occur in a duration of less than one minute. In another case, these overwhelming alarms may be considered "peak periods" characterized by a longer duration. The longer duration may be defined by a fixed period of time (duration), for example, spanning three different 10 minute periods, or having a duration of more than 20 minutes. Alternatively, they may occur dynamically and be derived from the normal duration period. For example, the system may determine a "normal duration" using the third quantile multiplied by the duration of factor 3, and then classify the event as a peak period when the event duration is longer than the "normal duration". A typical example is 21 voltage harmonic alarms lasting 2 hours.

In some embodiments, discriminant features may be identified in the aggregated information. Identifying discriminant characteristics can include, for example, identifying breakpoints associated with any type of event (power event or other event as previously described) and/or alert period, modeling each event and/or alert period, classifying each modeled event and/or alert period, and identifying discriminant characteristics in each modeled event and/or alert period. In some embodiments, events and/or alert periods may be identified based on detected changes in relevant data from the aggregated information. For example, a breakpoint associated with an event and/or alert period may correspond to a significant point of change in aggregated information separating one of the event and/or alert periods from the next event and/or alert period.

In some embodiments, modeling each of the event and/or alarm periods includes determining a best possible model for each of the event and/or alarm periods, and modeling each of the event and/or alarm periods based on the determined best possible model. For example, the best possible model may be determined by comparing each event and/or alert period of the event and/or alert period with a previous event and/or alert period of the event and/or alert period. As one example, the impact of each event and/or alert period on the electrical system may be compared to the impact of previous events and/or alert periods on the electrical system to determine the best possible model. For example, the current date/real-time number of alarms/events may be determined to have significantly more alarms/events than any previous date in the past five years (or another time period). In addition, the current date may be determined to have SoE ten times (or another multiple) greater than the previous event sequence (SoE) group. Both may generate actions that trigger a diagnostic report, e.g., show discrimination differences to help identify and focus on situations where errors occur, or at least in the event of errors, or when an alarm/event begins.

In some embodiments, each modeled event and/or alarm period may be classified as stable, ascending, or descending, for example, based on analysis of the modeled event and/or alarm period. Additionally or alternatively, each of the events and/or alert periods may be classified by curve fitting techniques, for example, using one or more statistical or machine learning algorithms to provide a rich or finer model. For example, a statistical or machine learning algorithm may model the slope or slope change of an event and/or alert period. A simple median model (as well as many other models and/or modeling techniques) may be used. This may be used to define trends and infer priorities for mitigation and/or remediation solutions.

In some embodiments, for example, a relative criticality score for each of the identified discriminant characteristics may be determined for a process or application associated with the electrical system. In some embodiments, a relative criticality score may be determined for a particular time period. For example, the particular time period may be associated with one or more of an event period and/or an alert period. In some embodiments, the relative criticality score is based on the impact of the identified discriminating characteristic on the process or application over a particular period of time. As one example, the impact of the identified discriminant characteristics on a process or application may involve tangible or intangible costs associated with the identified discriminant characteristics. In some embodiments, the relative criticality score may be used to prioritize responding to the identified alert. In another embodiment, the relative criticality score may be determined based on risk and/or measured impact and/or possibly impact assessment for a given segment, application, process, building, or current load type of a venue.

In some embodiments, the identified events and/or identified alarms are enriched with normal behavioral profiles derived from waveform captures associated with the energy-related signals, and then used as a comparison to discriminate dimensional identifications and groupings, for example, using waveform captures of normal operation (not triggered by abnormal conditions) and derived profiles that create "normal profiles" and store these profiles in a digital repository. In some embodiments, these profiles may be linked to load on/off or power consumption profiles, as well as state changes or processes of other systems. This provides a more complete or accurate context for diagnosis, recommendation, action for the current application, especially when affecting other systems. It also enriches the analysis and interpretation of alarms/events/alarms as it provides additional context information (providing more meaning or assistance) to identify possible or possible sources. Examples may include using machine learning or other AI algorithms to identify the most likely source or combination of sources to account for changes in state or changes in value.

Additional objects and advantages will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the disclosure. At least some of these objects and advantages may be realized and attained by means of the elements and combinations particularly pointed out in the disclosure.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention as disclosed.

Drawings

The foregoing features of the present disclosure, as well as the present disclosure itself, may be more fully understood from the following detailed description of the drawings, in which:

FIG. 1 illustrates an example network system architecture according to an embodiment of this disclosure;

FIG. 1A illustrates an example Intelligent Electronic Device (IED) that may be used in a network system according to embodiments of the disclosure;

fig. 1B shows an example configuration of an IED according to an embodiment of the present disclosure;

FIG. 2 illustrates an example method for reducing alarm nuisance behavior in an electrical system, according to embodiments of the disclosure;

FIG. 3A illustrates an example diagram of aggregated information that may be generated in accordance with embodiments of the present disclosure;

FIG. 3B illustrates a tremor alert nuisance behavior in accordance with embodiments of the present invention;

FIG. 3C illustrates an example analysis of recurring events and/or alarms according to an embodiment of the present invention;

FIG. 3D illustrates an example of an initial statistical analysis for identifying potential alarm setting changes and their impact on reducing nuisance behavior according to embodiments of the present invention;

FIG. 4 illustrates an example method for analyzing and taking actions in response to identified alarm nuisance behavior in accordance with embodiments of the invention;

FIG. 5 illustrates an example method for characterizing identified alarm nuisance behavior in accordance with embodiments of the invention;

FIG. 6 illustrates an example method for analyzing an alarm to characterize an electrical system problem according to an embodiment of this disclosure;

FIG. 7 illustrates an example alarm data dashboard in accordance with an embodiment of the present disclosure;

FIG. 8 illustrates another example method for analyzing an alarm to characterize an electrical system problem according to an embodiment of this disclosure;

FIG. 9 illustrates various concepts related to identifying overwhelming periods according to an embodiment of the present invention;

fig. 9A shows a first perspective view of fig. 9;

fig. 9B shows a second perspective view of fig. 9;

fig. 9C shows a third perspective view of fig. 9;

FIG. 10 illustrates various concepts related to identifying overwhelming periods according to an embodiment of the present invention;

FIG. 11 illustrates an example of utilizing a machine learning change point identification algorithm in accordance with an embodiment of the present disclosure;

FIG. 12 illustrates another example method for analyzing an alarm to characterize an electrical system problem according to an embodiment of this disclosure;

FIG. 13 illustrates example scrambling source location information in accordance with an embodiment of the present disclosure;

FIG. 14 illustrates an example mode according to an embodiment of the present invention;

FIG. 15A illustrates an example of sequence analysis according to an embodiment of the present disclosure;

FIG. 15B illustrates another example analysis of a sequence according to an embodiment of the present disclosure;

FIG. 16 illustrates two types of overwhelming periods according to an embodiment of the present invention;

FIG. 17 illustrates several example conditions that may reduce the benefits provided by an alert according to an embodiment of the present invention;

FIG. 18 illustrates an example method for analyzing an alarm to address an electrical system problem according to an embodiment of this disclosure;

FIG. 19 illustrates another example method for analyzing an alarm to address an electrical system problem according to an embodiment of this disclosure; and

FIG. 20 illustrates how setpoint-driven alarms work with alarm pickup, loss, and delay according to an embodiment of the invention.

Detailed Description

Features and other details of the concepts, systems, and technologies sought to be protected herein will now be described in more detail. It should be understood that any particular embodiments described herein are shown by way of illustration and not as limitations to the present disclosure and concepts described herein. Features of the subject matter described herein may be employed in various embodiments without departing from the scope of the concept for which protection is sought.

Referring to FIG. 1, a schematic diagram of an exemplary network system architecture configured to perform intelligent event and/or alarm analysis and management, etc., is shown. The architecture includes an electrical or power monitoring and control system, referred to herein as an EPMS, that includes one or more network nodes 126 and user devices 114 and 116 to monitor and control equipment or other devices 102, 104 and 106 of the facilities 108, 110 and 112. The network system architecture also includes an electrical or power system including power generation node(s) 122 to power facilities 108, 110, and 112 across the utility's power distribution network (e.g., grids 118 and 120) and facilities 108, 110, and 112. Facilities 108, 110, and 112 may be or include automated industrial facilities, or may be commercial buildings or university campuses, as one example of many other facilities. Systems and devices in the network architecture may use a Local Area Network (LAN), a Wide Area Network (WAN), or the internet, including the internet, to communicate over the communications network 124. The communication network 124 may be a wired and/or wireless network that uses, for example, physical and/or wireless data links to carry network data among (or between) network nodes.

Each network node 126 may include a computer system, such as an Intelligent Electronic Device (IED), to sense, monitor, capture, and analyze energy related data on the electrical system. According to various embodiments, the IED may capture signal waveforms representative of voltage, current, power, or other measurable electrical characteristics across the electrical system, create a power event profile, perform event analysis to identify power events and additional information including alarms triggered in response to the power events, and perform other operations as part of the systems and methods for managing intelligent alarms described herein. The IEDs may be intelligent devices, such as intelligent power meters or other power devices, or incorporated into or associated with power meters or other power devices on the electrical system. The architecture may include a plurality of IEDs arranged in a hierarchical or layer relationship at different upstream and downstream locations on the electrical system (e.g., as shown in fig. 1B, as will be discussed below) to monitor, derive or calculate, analyze, and share energy-related information (e.g., measurement data, derived data, event data and additional information, results of event analysis, event profiles, etc.) at any desired location along the electrical system (including locations along the grid, between utilities, and within the facilities). Each of the IEDs may be installed at a respective metering point or location of a plurality of metering points or locations in the electrical system (e.g., as shown in fig. 1B, as will be discussed below).

In some embodiments, a user may use at least one of the user devices 114 and 116 to view information about the IED (e.g., IED make, model, type, etc.) and data collected by the IED (e.g., energy usage statistics). Additionally, in some embodiments, a user may configure the IED using at least one of the user devices 114 and 116. Each user device 114 and 116 may comprise a computing device, such as a desktop computer, laptop computer, handheld computer, tablet computer, smart phone, or the like. In addition, each user device 114 and 116 may include or be coupled to one or more input/output devices, e.g., to facilitate user interaction with the IED (e.g., to view information about the IED).

In some embodiments, the EPMS may also include a diagnostic system 125, or be communicatively coupled to the diagnostic system 125 via a communication network 124. In some embodiments, the IED and user devices 114 and 116 of the EPMS described above may be directly communicatively coupled to the diagnostic system 125. In other embodiments, the IEDs and user devices 114 and 116 may be communicatively coupled to the diagnostic system 125 indirectly, for example, through an intermediary device (such as a cloud-connected hub or gateway). The hub (or gateway) of the cloud connection may, for example, provide IED and user devices 114 and 116 with access to the diagnostic system 125.

Diagnostic system 125 may be an example of a cloud computing system or a cloud-connected computing system. In an embodiment, diagnostic system 125 may be a server located within one or more of facilities 108, 110, and 112, or may be a remotely located cloud-based service. In some embodiments, diagnostic system 125 may include computing functional components similar to those of an IED, but may generally have a greater number and/or more powerful version of the components involved in data processing, such as processors, memory, storage, interconnection mechanisms, and the like. The diagnostic system 125 may be configured to implement various analysis techniques to identify patterns in measurement data received from the IED, as discussed further below. The various analysis techniques discussed herein also involve executing one or more software functions, algorithms, instructions, applications, and parameters stored on one or more memory sources communicatively coupled to diagnostic system 125. In some embodiments, the terms "function," "algorithm," "instruction," "application," or "parameter" may also refer to a hierarchy of functions, algorithms, instructions, applications, or parameters operating in parallel and/or in series, respectively. The hierarchy may include a tree-based hierarchy, such as a binary tree, having the following features: one or more child nodes descending from each parent node, or a combination thereof, wherein each node represents a particular function, algorithm, instruction, application, or parameter.

In an embodiment, since diagnostic system 125 is connected to the cloud, it may access additional cloud connection devices or databases (not shown) via the cloud. For example, the diagnostic system 125 may access historical measurement data, historical power events, and/or alarm data previously received from at least one IED, or other data that may be useful in analyzing current measurement data received from at least one IED. In embodiments, the cloud-connected device or database may correspond to a device or database associated with one or more external data sources.

In an embodiment, by utilizing cloud connectivity and enhanced computing resources of the diagnostic system 125 relative to the IEDs, complex analysis may be performed as appropriate on data retrieved from one or more IEDs and on additional data sources that may be received (e.g., from other devices in the electrical system, such as humidity and temperature sensors). The analysis may be used to dynamically control one or more parameters, processes, conditions, or devices (e.g., 102, 104, and 106) associated with the electrical system.

In an embodiment, the parameter, process, condition, or device is dynamically controlled by one or more control devices of the EPM. In an embodiment, the control device may correspond to, comprise or be comprised within or outside one or more of the above-mentioned IEDs, diagnostic systems and/or other devices.

It should be understood that the network architecture shown in fig. 1 is but one example network architecture among many potential network architectures that may be suitable for use with the systems and methods described herein. Any suitable network architecture may be used that allows communication and interaction between components of the EPMS (e.g., IEDs, diagnostic systems, user equipment, etc.), devices or loads, facilities, etc., to perform the operations described herein. For example, the systems and methods herein, including but not limited to, identification of events (e.g., power events) and identification of alarms triggered in response to the events, may be implemented through a cloud-based architecture via one or more network nodes.

Referring to fig. 1A, an example IED 140 that may be suitable for use with the network system architecture 100 shown in fig. 1 includes, for example, a controller 141, a memory device 142, a storage 144, and an interface 145.IED 140 also includes an input-output (I/O) port 146, a sensor 147, a communication module 148, and an interconnection 143 for communicatively coupling two or more IED components 141-148.

Memory device 142 may include volatile memory such as DRAM or SRAM. The memory device 142 may store programs and data collected during operation of the IED 140. For example, in embodiments in which the IED 140 is configured to monitor or measure one or more electrical parameters associated with one or more devices or loads in an electrical system, the memory device 142 may store the monitored electrical parameters (e.g., from energy-related signals captured or derived by the IED 140).

The storage system 144 may include a computer-readable and writable nonvolatile recording medium such as a magnetic disk or a flash memory in which signals defining a program executed by the controller 141 or information processed by the program are stored. Controller 141 may control the transfer of data between storage system 144 and memory device 142 in accordance with known computing and data transfer mechanisms. In an embodiment, electrical parameters monitored or measured by the IED140 may be stored in the storage system 144.

The I/O port 146 may be used to couple a load (e.g., 111 shown in fig. 1A) to the IED140, and the sensor 147 may be used to monitor or measure an electrical parameter associated with the load. The I/O ports 146 may also be used to couple external devices, such as sensor devices (e.g., temperature and/or motion sensor devices) and/or user input devices (e.g., local or remote computing devices) (not shown), to the IED 140. The I/O ports 146 may also be coupled to one or more user input/output mechanisms, such as buttons, displays, acoustic devices, etc., to provide an alarm (e.g., display a visual alarm, such as text and/or steady or flashing light, or provide an audio alarm, such as a beep or long-term sound) and/or to allow a user to interact with the IED 140.

The communication module 148 may be configured to couple the IED 140 to one or more external communication networks or devices. These networks may be private networks within the building in which the IED 140 is installed, or public networks such as the internet. In an embodiment, the communication module 148 may be further configured to couple the IED 140 to a cloud-connected hub or cloud-connected central processing unit associated with a network system architecture including the IED 140.

The IED controller 141 may include one or more processors configured to perform specified functions of the IED 140. The processor may be a commercially available processor such as the well known PentiumTM, coreTM or atom type processor available from intel corporation. Many other processors are available, including programmable logic controllers. The IED controller 141 is capable of executing an operating system to define a computing platform on which applications associated with the IED 140 can run.

In an embodiment, electrical parameters monitored or measured by the IED 140 may be received as IED input data at an input of the controller 141, and the controller 141 may process the measured electrical parameters to generate IED output data or signals at an output thereof. In an embodiment, the IED output data or signal may correspond to the output of the IED 140. For example, IED output data or signals may be provided at I/O ports 146. In an embodiment, the IED output data or signals may be received by a diagnostic system, for example, for further processing (e.g., to identify a power event, as briefly discussed above in connection with fig. 1), and/or by a device (e.g., a load) to which the IED is coupled (e.g., for controlling one or more parameters associated with the device, as will be discussed further below). In one example, the IED 140 may include an interface 145 for displaying a visualization indicating the IED output data or signals. In an embodiment, the interface 145 may correspond to a Graphical User Interface (GUI).

The components of the IED 140 may be coupled together by an interconnection mechanism 143, and the interconnection mechanism 143 may include one or more buses, wiring, or other electrical connection devices. Interconnection mechanism 143 can enable communication (e.g., data, instructions, etc.) to be exchanged between system components of IED 140.

It should be appreciated that the IED 140 is only one of many potential configurations of IEDs in accordance with aspects of the present disclosure. For example, an IED according to an embodiment of the present disclosure may include more (or fewer) components than IED 140. Additionally, in an embodiment, one or more components of IED 140 may be combined. For example, in an embodiment, memory 142 and storage 144 may be combined.

Referring to fig. 1B, an example configuration (e.g., hierarchical configuration) of IEDs, such as IED 140, in an electrical system is shown. As described above, electrical systems typically include one or more metering points or locations. As also described above, one or more IEDs may be mounted or positioned (temporarily or permanently) at a metering location, e.g., to measure, protect, and/or control one or more loads in an electrical system. In some cases, the IED may be part of or associated with a power monitoring system (EPMS). For example, the EPMS may be responsible for monitoring and/or controlling the electrical system.

The electrical system shown includes a plurality of metering locations (here M ₁ 、M ₂ 、M ₃ Etc.). In embodiments where the electrical system is a "full metering" system, for example, at least one IED is mounted at the first metering location M ₁ At least one IED is mounted at a second metering position M ₂ And so on. Connection 1 is a physical point in the electrical system where the energy flow (by the installation in M ₁ At least one IED at M ₁ Measured at) diverges to the left electrical system branch (with metering position M ₃ 、M ₄ 、M ₇ 、M ₈ Associated) and a right electrical system branch (associated with metering position M ₂ 、M ₅ 、M ₆ 、M ₉ 、M ₁₀ Associated) provides energy. According to some embodiments of the present disclosure, as will be discussed further below, IEDs (here M ₁ 、M ₂ 、M ₃ Etc.) may share electrical measurement data from or derived from energy-related signals captured by or derived from the IED. The shared electrical measurement data may be used, for example, to identify power events in the electrical system, and to identify alarms triggered in response to the identified power events. For example, at metering position M ₇ 、M ₈ The IED at the site can be mounted at the metering position M ₃ IEDs at the site share electrical measurement data to identify a metering location M ₃ A power event at, and identifying a response to the metering location M ₃ An alert triggered by the identified power event.

In the example shown, mounted in metering position M ₃ The IED at is considered to be installed at metering position M ₇ 、M ₈ "upstream" of the IED at. In addition, in the example shown, it is mounted in a metering position M ₇ 、M ₈ The IED at is considered to be mounted in relation to the metering position M ₃ Downstream of the IED. As used herein, the terms "upstream" and "downstream" are used to refer to electrical locations within an electrical system. More havePhysically, the electrical positions "upstream" and "downstream" are relative to the electrical positions of the IEDs that collect data and provide that information. For example, in an electrical system including a plurality of IEDs, one or more IEDs may be positioned (or installed) at an electrical location upstream relative to one or more other IEDs in the electrical system, and one or more IEDs may be positioned (or installed) at an electrical location downstream relative to one or more other IEDs in the electrical system. A first IED or load located on a circuit upstream of a second IED or load may, for example, be electrically positioned closer to an input or source (e.g., utility feed) of an electrical system than the second IED or load. Conversely, a first IED or load on a circuit downstream of a second IED or load may be electrically positioned closer to an end or terminus of the electrical system than another IED. The first and second IEDs described above may record voltage and current phase information of the electrical event (e.g., by sampling the corresponding signals) and send the information communicatively to a diagnostic system (e.g., 125 shown in fig. 1). The EPMS may then analyze the voltage and current phase information (e.g., instantaneous, root mean square (rms), waveform, and/or other electrical characteristics) to determine whether the source of the voltage event is electrically upstream or downstream of the first IED and/or the second IED electrically coupled to the electrical system (or network), e.g., to determine the direction of the power event (i.e., upstream or downstream).

It should be appreciated that the configuration or arrangement of the IEDs discussed above is only one of many potential configurations of IEDs in an electrical system.

Referring to fig. 2 and the following drawings, several flowcharts (or flow charts) are shown to illustrate various methods of the present disclosure. Rectangular elements (represented by element 205 in fig. 2) as may be referred to herein as "processing blocks" may represent computer software and/or IED algorithm instructions or groups of instructions. Diamond-shaped elements, which may be referred to herein as "decision blocks", represent computer software and/or IED algorithm instructions or groups of instructions that affect execution of the computer software and/or IED algorithm instructions represented by the processing blocks. The processing blocks and decision blocks may represent steps performed by functionally equivalent circuits such as a digital signal processor circuit or an Application Specific Integrated Circuit (ASIC).

The flow chart does not describe the syntax of any particular programming language. Rather, the flow diagrams illustrate the functional information one of ordinary skill in the art requires to fabricate circuits or to generate computer software to perform the processing required of the particular apparatus. It should be noted that many routine program elements are not shown, such as initialization of loops and variables and the use of temporary variables. Those of ordinary skill in the art will understand that the specific ordering of the blocks described is merely illustrative and that variations are possible, unless otherwise indicated herein. Thus, unless otherwise indicated, the blocks described below are unordered; this means that the blocks may be performed in any convenient or desired order, including sequential blocks that are performed at the same time, and vice versa, where possible. It should also be appreciated that in some embodiments, various features from the flowcharts described below may be combined. Thus, unless otherwise indicated, features from one of the flowcharts described below may be combined with features of other ones of the flowcharts described below, e.g., to capture various advantages and aspects associated with providing the analysis of electrical systems that are intended to be protected by this disclosure.

Systems and methods for reducing alarm nuisance behavior in electrical systems

Referring to fig. 2-5, exemplary diagrams relating to systems and methods for reducing alarm nuisance behavior in electrical systems are shown. According to various aspects of the invention, an important analysis is alarm nuisance behavior identification. As known to those skilled in the art, and to anyone working with alarms, and described in advanced definition in the American National Standards Institute (ANSI)/international automation association (ISA) 18.2 "management of alarm systems for the process industry" dedicated to alarm management in manufacturing, the nuisance behavior of alarms can be detected and remedied for proper operation. Alarm nuisance behavior tends to overwhelm users and/or confuse understanding and analysis, for example, by flooding users and/or confuse understanding and analysis during periods of time when an alarm flood or some alarms may recur rapidly (tremor behavior alarms) or for short durations (brief) or with long-term alarms (stale behavior alarms).

These nuisance behavior alarms become very "noisy" (e.g., when a user sees hundreds of alarms coming within a brief period, such as within one minute of observation), and make it increasingly difficult or even impossible for any user of a human observer or alarm system to discern what is important, what is new, what is changing, or what is a co-occurring alarm pattern. This noise level may even increase in an accumulated manner, thereby reducing the effectiveness of the alarm system (and thus the value of the alarm system) because each new problem increases the previously unresolved problem if it is not resolved immediately or as soon as possible (before the next new type of problem occurs or the known pattern reoccurs).

The disclosed systems and methods provide techniques for automatic nuisance analysis to process a large number of events and alarm data to reduce nuisance alarm behavior, which can provide related diagnostic, recommended, and potential corrective actions for such alarm nuisance behavior. This in turn should help analyze the alarm by reducing noisy behavior and helping the user focus and prioritize the real problems that need to be addressed. For example, a maintenance engineer may use event and alarm nuisance analysis to reduce the number of stale alarms that may have been generated due to communication loss of event data due to unreliable Wi-Fi communications or power loss in a gateway before an alarm system receives a signal and stores it correctly in an alarm database.

Today, maintenance engineers may be exposed to a large number of alarms (e.g., more than 500 alarms in 2 seconds). Using the disclosed systems and methods, operational safety, response time, recovery time, and/or efficiency may be improved. Adverse effects of power quality issues or other undesirable conditions on electrical/power systems or facilities may also be constrained. In addition, the quality of the mitigation and remedial actions may be improved due to faster identification of the cause of the problem. Such reduction in alarm nuisance behavior may, for example, help maintenance engineers focus properly on impact analysis and reduce data clutter associated with post analysis of event or related event data and alarm data.

Referring now to fig. 2, a flow chart illustrates an example method 200 for reducing alarm nuisance behavior in an electrical system. The method 200 may be implemented, for example, on a processor of at least one IED (e.g., 121 shown in fig. 1A) in an electrical/power system, a processor of a diagnostic system (e.g., 125 shown in fig. 1) in an electrical/power system, and/or remotely from at least one IED and the diagnostic system, e.g., on a cloud computing device. For example, as discussed above in connection with fig. 1, at least one IED, diagnostic system, and/or other device on which the method 200 may be implemented may be included in or associated with an EPMS in an electrical/power system.

As shown in fig. 2, the method 200 begins at block 205, where an energy-related signal (or waveform) is captured or derived by at least one IED in an electrical/power system. At least one IED may be mounted or positioned (temporarily or permanently) at a respective metering location in the electrical/power system, and the energy-related signal may be associated with the respective metering location (or one or more loads mounted at the respective metering location). In some embodiments, the respective metering location may be a respective metering location of a plurality of metering locations in the power system, e.g., in embodiments in which the at least one IED includes a plurality of IEDs. In these embodiments, the energy-related signals may be captured or derived by a plurality of IEDs at each of a respective plurality of metering locations. For example, a first one of the IEDs may be installed or located at a first metering location in the power system (e.g., M shown in fig. 1B ₁ ) At this point, and the energy related signal captured by the first IED may be captured at the first metering location or derived from measurements made at the first metering location. In addition, a second one of the IEDs may be installed or located at a second metering location in the power system (e.g., M shown in fig. 1B ₂ ) At this point, and the energy related signal captured by the second IED may be captured at the second metering location or derived from measurements made at the second metering location.

The energy related signals measured or derived by the at least one IED may comprise, for example, at least one of: voltage, current, energy, active power, apparent power, reactive power, harmonic voltage, harmonic current, total voltage harmonic distortion, total current harmonic distortion, harmonic power, individual phase current, three-phase current, phase voltage, and line voltage, as just a few examples. It should be appreciated that other types of energy related signals (e.g., alarm signals or indications related to activity on an electrical system or from an EPM) may be captured or derived by at least one IED. For example, other examples of energy-related signals are discussed in the summary section of this disclosure.

At block 210, electrical measurement data from or derived from the energy-related signals captured or derived by the at least one IED at block 205 is processed, e.g., on the at least one IED, on a diagnostic system, and/or at a location remote from the at least one IED and the diagnostic system, to identify events in the electrical/power system. The identified events may be associated with a metering location in which the at least one IED is installed, one or more loads (e.g., 102, 104, 106 shown in fig. 1) monitored by the at least one IED, and/or other portions (e.g., remote portions) or devices of the electrical/power system.

According to some embodiments of the present disclosure, the identified events include power events and/or events that can trigger a protection device (e.g., a protection relay). For example, the identified event may include tripping the motor offline under different fault conditions including: thermal stress, single phase, ground fault/ground fault, short circuit, locked rotor, excessive duty cycle, bearing fault, under voltage conditions or harmonics cause circuit breakers to trip offline, overcurrent events, etc. For example, the power event may include a power quality event. In embodiments where the power event comprises a power quality event, identifying the event at block 210 may include identifying a power quality event type of the power event. The power quality event type may include, for example, at least one of the following: voltage dips, voltage or current transients, temporary interruptions, sustained interruptions, and voltage or current harmonic distortions, as a few examples. It should be appreciated that other types of events may be identified. Other types of events may include manufacturing process(s) or load related event(s), HVAC related event(s), including user override settings of the BMS, over-current, peak demand, low or advanced power factor, I/O input(s) indicating a change on or related to the electrical system, detected and signaled by the manufacturing device via the I/O signal or SCADA system, for example.

Identifying an event may additionally or alternatively include identifying the magnitude of the event, the duration of the event, the location of the event in the electrical/power system, and/or other information that may be helpful in identifying an alarm (i.e., a smart alarm) triggered in response to the identified event, as will be discussed further below. In some embodiments, for example, in embodiments in which at least one IED includes a plurality of IEDs located at a respective plurality of metering locations in an electrical/power system, the amplitude(s), duration(s), location(s), and/or other information may be determined based on electrical measurement data from or derived from energy-related signals captured or derived by the plurality of IEDs. For example, the plurality of IEDs may share energy related signals captured or derived by the plurality of IEDs with a selected IED (or EPMS) of the plurality of IEDs, and the shared energy related signals may be used to determine amplitude, duration, location, and/or other information associated with the identified event. This may include determining a difference between different measured levels (e.g., amplitudes or durations) of nuisance of events propagated through the power system, as this may be inferred from the energy-related signals and the location of each IED. In some embodiments, the energy related signals captured or derived by the plurality of IEDs may be stored on a memory device associated with the plurality of IEDs, on a memory device associated with the diagnostic system, and/or on another memory device, depending on the implementation of the method 200 (e.g., on at least one IED, on the diagnostic system, and/or on another device or system).

In one example embodiment, each of the at least one IEDs may measure the voltage and current of each phase and derive additional measurements (e.g., frequency, power factor, reactive power, voltage harmonics, current harmonics, etc.) from these voltages and currents. Based on any combination of these measurements, an event may be detected, for example, when a threshold is exceeded (e.g., a voltage dip is detected when the voltage drops below 10% of the nominal voltage). The event generates a set of event data characterizing the event. Typically, events will have common data such as "duration" or "affected phases". Other data (e.g., "amplitude," "worst phase," "imbalance," "voltage THD," etc.) may be more specific to the type of event.

At block 215, it is determined whether any alarms have been, should have been or should have been triggered in response to an identified event (e.g., a power event) in or associated with the electrical system. In some embodiments, an alarm may be triggered (e.g., automatically or semi-automatically) in response to an identified event. For example, a load monitored by an IED in an electrical/power system may have an upper alarm threshold limit and/or a lower alarm threshold limit, and an alarm (or alarms) may be triggered in response to, for example, a voltage and/or current signal captured by the IED at block 205 being above the upper alarm threshold limit and/or below the lower alarm threshold limit. For example, an abnormal voltage condition as one example type of power event corresponds to the measured IED voltage being above one or more upper alarm thresholds or below one or more lower alarm thresholds. In some embodiments, an alarm (or alarms) may be triggered in response to an abnormal voltage condition. In some embodiments, the upper and lower alarm thresholds associated with, for example, abnormal voltage conditions and/or other power events are aligned with recommended operating ranges of one or more loads, processes, and/or systems monitored by the IEDs in the electrical/power system.

The alarm triggering may result in one or more portions (e.g., loads) of the electrical/power system being automatically controlled, for example, by the IED, the diagnostic computing device, and/or other system or device on which the method 200 is implemented. For example, the alarm trigger may cause the load monitored by the IED to be adjusted (e.g., turned off, or one or more parameters adjusted).

Additionally or alternatively, the alert trigger may result in a notification or alert indicating that the alert is being sent to one or more devices or systems, such as an EPMS. In some embodiments, the EPMS or a user of the EPMS may take an action (or actions) in response to a notification or alert. Example actions may include controlling one or more portions of the electrical/power system described above, or delaying, changing order, or even deferring a process in another system (e.g., in a power SCADA system, or in a building management system, or in manufacturing a SCADA system, just to name a few examples). It should be understood that other actions may of course be performed.

In one example embodiment, based on the detected event, an alarm may be triggered on the same threshold or a different threshold tailored for installation. For example, a site, a portion of a site, or even an IED may be configured to generate an alarm only when a voltage dip affects the system, thereby utilizing the load loss value (as described by the inventors in another invention). At least one IED may send/store event data as time stamped event data. This means that the data can receive a time stamp of the exact detection time of the event and/or alarm. This may include the start of AN event, any significant change or highest significant value (such as worst amplitude), or change from "AB phase voltage dip" to "AB and AN phase voltage dip", and a missing timestamp of AN event (such as, for example, when all voltage levels return to +/-10% nominal voltage levels).

In addition to event/alarm data, at least one IED may also capture waveform data. This may enable and enhance further analysis and visualization of events/problems. In addition, the value of the constant interval record may also be used to describe the statistical context of each event/alert. For example, this may include utilizing measurements captured for each 10 or 15 minute constant interval, such as for illustration purposes, median and/or average voltage levels, minimum and maximum voltage levels per phase, mean and/or average power and/or minimum and/or maximum power. It should be appreciated that other data may be captured and utilized in the present invention, such as data related to the device (e.g., device settings, such as thresholds for trigger events and alarm detection, whether waveforms are captured or not), other data related to the electrical system and installation (e.g., electrical single line graphs, descriptive loads, nameplate information, infrastructure equipment, etc.), data describing the type of load monitored by the IED (e.g., lighting, HVAC), physical location (e.g., GPS coordinates, address, site, building, floor, impedance, etc.), I/O data, PLC data, and data related to the process and control system (e.g., building management system or manufacturing SCADA system).

At block 220, the selection information is aggregated. For example, in one example embodiment, information about the identified events and the identified alarms may be aggregated (e.g., the number of daily events or alarms, the number of time overlapping event groups, the impact on downstream loads, etc.). Information about the identified events and the identified alarms may be aggregated, for example, as an amount for a particular time period or interval (i.e., block 301), for example, quarterly as shown in graph 300 in fig. 3A (i.e., block 302), as will be further described below, or hourly, weekly, monthly, etc. Additionally or alternatively, information related to the identified event and the identified alarm may be aggregated based on event type, alarm type, IED type, load type, metering location, alarm hazard for a particular process or application, etc. The aggregated information may indicate the number (or frequency) of events and/or alarms occurring within a particular time period. Additionally, the aggregated information may indicate the number (or frequency (s)) of events and/or alarms occurring based on event type, alarm type, IED type, load type, metering location(s), etc.

As one example, the aggregated information may include a number (or count) of aggregations of events and/or alarms for a day, as shown in fig. 3A. The aggregate sum may, for example, be indicative of or interpreted as determining whether the number of events and/or alarms is within acceptable limits. Additionally, in some cases, the aggregate sum may indicate whether an operator of a facility (e.g., 108, 110, 112 shown in fig. 1) having at least one IED capturing or deriving energy-related signals has lost or is at risk of losing control of alarms in the facility (e.g., because the aggregate sum is above an acceptable threshold). As one example, the aggregate sum of hundreds of alarms over a period of a day may indicate that a facility operator has lost control of events/alarms of the facility. In some embodiments, the aggregated information (and aggregate totals) may be stored on a memory device associated with at least one IED, EPMS, and/or other system or device on which the method 200 is implemented.

As is apparent from the discussion above, in some embodiments, aggregated information may be plotted as shown by curve 300 shown in fig. 3A. However, it should be understood that in some embodiments, the aggregated information need not be drawn or otherwise visualized. In an embodiment of drawing aggregated information, the drawing may be presented, for example, on a display device of a user device (e.g., 114 shown in FIG. 1) and/or another device of the EPMS or a display device associated with the EPMS and/or included in a report and/or notification sent to the user.

Fig. 3A shows how events and/or alarms evolve out of control and affect the health of the alarm electrical/power system. For example, as shown in fig. 3A, there is a very long period of time before the first quarter, where little to no matter is detected; neither events nor alarms (this may be the case just after commissioning the site). Within quarter 1, there may be long periods of time where alarms or events may occur sparsely, while most of the 10 minute period or even days have no events or alarms. At quarter 2 (and 310), the system changes. Installing new loads, the power system and its operation may evolve with modifications (e.g., within a manufacturing plant or process thereof, changing HVAC rooftop units, etc.), and may enable expansion of the field (e.g., adding warehouses, adding new processes to expand production capacity, etc.), with maintenance teams changing due to the occurrence of problems or as a preventative action. This becomes visible as the number of alarms begins to rise (e.g., the frequency and number of alarms occur increases).

At quarter 3 (and after 311), it can be observed that the user has lost control over their number of alarms; the number does not return to 0. There may be many different reasons for this. For example, a maintenance manager or some critical expert with the understanding and maintenance of the power system is no longer managing the EPMS (e.g., retired, relocated, new work). Replacement may not understand the load, equipment, process, system, EPMS, etc. on site and therefore may not understand the cause of the alarm well. At this point, the alarm may begin to accumulate (e.g., high THD may become new normal, voltage imbalance may fail to resolve, voltage dip may be caused by a new motor), and the alarm health may deteriorate, as indicated in block 313.

It should be appreciated that the example types of aggregated information (e.g., events and alerts) and illustrations discussed above are just a few of the many possible example types of aggregated information that may be aggregated at block 220 according to embodiments of the present disclosure. For example, according to some embodiments of the present disclosure, the aggregated information may also include information from at least one of: power Monitoring Systems (EPMS), SCADA systems (e.g., power SCADA, manufacturing SCADA), building Management Systems (BMS), I/O devices, and system users (e.g., user initiated actions). As previously noted in this disclosure, in some examples, the EPMS may include at least one IED responsible for capturing or deriving the energy-related signal (e.g., at block 205 of method 200).

At block 225, the aggregated information is analyzed to identify at least one alarm nuisance behavior. More specifically, at block 225, the aggregated information is analyzed to generally determine whether one or more portions or sub-divided portions of the aggregated information include an action indicative of alarm nuisance actions. According to some embodiments of the present disclosure, the act of indicating an alarm nuisance act may include an act of indicating at least one predefined or prescribed alarm nuisance act, user-defined alarm nuisance act, or learned alarm nuisance act.

In one aspect of the invention, the predefined or prescribed alarm nuisance behavior is defined based at least in part on good engineering practices, during one of the typical steps of an alarm ISA 18.2 "audit and philosophy cycle" (A, B, C, D, H, I, J), or at the time of field commissioning (which may be equivalent to the threshold defined by steps a through E in the absence of a formal process such as ISA 18.2 recommendation), or a prescribed threshold (e.g., data centers established in new projects, updates to processes, re-enforcing prescribed thresholds from previous installations). Additionally, in one aspect of the disclosure, the user-defined alarm nuisance behavior is an alarm nuisance behavior defined by a system user, operator, or the like. For example, a user may define an alarm duration of 8 hours as being considered a "stale alarm" in a subdivision or in a particular scene. In another setting, an alarm that a user may use for a 24 hour duration is considered to be a "stale alarm". It is reasonable that in the first case, there may be 3 different work shifts, and any alarm longer than a single shift will be considered a "stale alarm" (i.e., if not resolvable or unprocessed within a shift). In the second case, there is only one team maintenance system, so 24 hours is the normal workday duration of the field. Further, in one aspect of the disclosure, the learned alarm nuisance behavior is learned from at least one of: system users, and I/O systems and devices (e.g., during a learning period). For example, in one application, a user of an EPMS may use a mobile application that enables marking an alert as a nuisance (e.g., based on an understanding of its manufacturing process). The system may then apply a filter (shown at block 312 in fig. 3) in the visualization on the alert that shows the nuisance behavior.

It will be appreciated that many variables and measurements may be utilized for learning. For example, the system may utilize "time to acknowledge an alarm" as a metric to determine when a flood period is reached. The idea is to detect a threshold (e.g., the number of alarms in a 10 minute interval) after which the user cannot maintain the previous normal metrics. For example, the system may infer a normal "time to acknowledge an alarm" ranging between 10 minutes and 1 hour. The system may calculate a model of the relationship between the number of alarms and the validation time (e.g., using a multi-segment regression curve). The system may then detect an inflection point between two segments of the regression line using a machine learning algorithm (e.g., segmented R-packets), for example. Is (is) break points or inflection points can be used to detect flood nuisance behavior. The system may iterate until the inferred threshold value for the number of alarms is considered significant and repetitive. In some embodiments, the threshold may be dynamic in view of improvement and further degradation. For example, the threshold may also be adjusted to a work shift or team. Other possible variables and measurements may include time-dependent (e.g., "time to identify problem," "time to define mitigation action," etc.) or user-defined variables and measurements (e.g., user presses a button while submerged in an alarm).

In some cases, at least one predefined or prescribed alarm nuisance behavior, user-defined alarm nuisance behavior, or learned alarm nuisance behavior is based at least in part on customer type/segment (e.g., retail, office, hotel, hospital, data center, food and beverage, oil and gas, etc.). More specifically, since each client type/segment has its own unique configuration, requirements, and constraints, at least one predefined or prescribed alarm nuisance behavior, user-defined alarm nuisance behavior, or learned alarm nuisance behavior may not necessarily be the same for different client types/segments. Conversely, in some cases, at least one predefined or prescribed alarm nuisance behavior, user-defined alarm nuisance behavior, or learned alarm nuisance behavior may need to be calibrated, configured, and/or learned differently for different customer types/subdivisions. For example, the reactivity in a data center is much more critical than the reactivity in an office building. Thus, the duration of the stale nuisance alarm may be 24 hours in an office building. In contrast, the duration of the stale nuisance alarms may be only 3 hours in the data center.

Additional aspects related to identifying, defining, characterizing, quantifying, etc., at least one alarm nuisance behavior will be further appreciated from the discussion in connection with block 230 and the figures that follow.

It should be appreciated that in some cases, the information analyzed at block 225 (i.e., the aggregated information discussed above) may be further evaluated to identify additional situations, problems, concerns, or conditions (i.e., beyond identifying alarm nuisance behavior). For example, the aggregated information may be analyzed to identify missing or incomplete data (e.g., due to IED cycling of control power) and its impact on at least one identified alarm nuisance behavior and/or on a process of identifying at least one alarm nuisance behavior. For example, the system may run an analysis to identify the consistency of the alarm type with the detected stale alarm nourishment behavior for the stale nuisance alarms. There is a definition of the alarm type that cannot be a stale alarm. For example, a voltage dip may be defined as the maximum duration of an event of 1 minute. If the IED does not detect loss of an event for a maximum of 1 minute duration, the IED changes the alarm type and tag to another type of power quality event (e.g., under-voltage). The type of event provided by the IED is important for detecting incorrect stale alarm nuisance behavior and implementing system remedial or mitigation actions (e.g., filtering the stale alarm, supplementing the maximum actual duration related end loss end timestamp to provide a data quality confidence level for the supplemented timestamp in one embodiment). This specific example will be described in more detail in later sections.

It should also be appreciated that in some cases, the information analyzed at block 225 may be analyzed automatically or dynamically (i.e., without user-triggered analysis), semi-automatically (e.g., with user-defined triggers or conditions), or manually (e.g., in response to user input), e.g., based on predefined settings or user-configured preferences.

After block 225, at least one action may be taken or performed at block 230 based on or in response to the at least one identified alarm nuisance behavior. For example, as will be discussed further below in connection with the figures, in some cases, the at least one action taken or performed may include characterizing and/or quantifying the at least one identified alarm nuisance behavior. Additionally, in some cases, the at least one action taken or performed may include at least one action that improves the alert health, e.g., in embodiments where the at least one identified alert nuisance behavior is an indication of a suboptimal alert health.

After block 230, or after block 225, in the event that no alarm nuisance behavior is detected at block 225, the method may end, return to block 205, or may take one or more actions. For example, in embodiments where it is desired to continuously or semi-continuously or periodically capture energy-related signals and dynamically analyze these captured energy-related signals to identify alarm nuisance behavior, the method may return to block 205 (e.g., for capturing and analyzing further energy-related signals). Alternatively, in embodiments where it is desired to analyze a single set of captured energy-related signals, for example, the method may end or one or more actions may be taken. Example actions may include storing, displaying, and/or analyzing previously captured or derived energy-related signals. Other example actions may be appreciated from the further discussion below. In embodiments where the method ends after block 230 (or block 225), the method may be reinitiated, for example, in response to user input and/or control signals (e.g., a timer/clock).

It should be appreciated that in some embodiments, the method 200 may include one or more additional blocks. Other exemplary aspects, features and variations of the disclosed invention will be apparent from the following discussion.

Referring to FIG. 4, a flow chart illustrates an example method 400 for analyzing and taking actions in response to identified alarm nuisance behavior. In accordance with some embodiments of the present disclosure, method 400 illustrates example steps that may be performed in conjunction with method 200 discussed above in conjunction with fig. 2. For example, in one example embodiment, one or more steps of method 400 may correspond to example steps that may be performed at block 230 of method 200 after at least one alarm nuisance behavior is identified at block 225 of method 200. Similar to method 200, method 400 may be implemented on a processor of at least one IED (e.g., 121 shown in fig. 1A) in an electrical/power system, a processor of a diagnostic system (e.g., 125 shown in fig. 1) in an electrical/power system, and/or remote from at least one IED and the diagnostic system.

As shown in FIG. 4, the method 400 begins at block 405, where information relating to at least one identified alarm nuisance behavior is received. The received information may include, for example, information associated with identifying at least one alarm nuisance behavior at block 225 of method 200. For example, the received information may include aggregated information (e.g., event and/or alarm information) from block 220 of method 200 for identifying at least one alarm nuisance behavior at block 225.

At block 410, at least one identified alarm nuisance behavior is characterized and/or quantified based on the information received at block 405.

According to embodiments of the present invention, various metrics may be detected or derived from the detected nuisance behavior of the at least one identified alarm nuisance behavior. For example, metrics may be detected or derived for each IED of the at least one IED and for each alarm type detected by each IED, similar to the following example metrics:

the number of alarms for a time period,

the number of alarms per interval when the nuisance acts occur,

80 th percentile, 90 th percentile, 95 th percentile, 98 th percentile of duration, duration to next alarm,

extremum distribution (e.g., what is amplitude, imbalance, etc.),

etc.

According to some embodiments of the invention, the correlation depends on the type of nuisance behavior and the event and/or alarm type. For example, in some cases, any measurements used to detect/identify an event (e.g., at block 210 of method 200) may generate a nuisance alert. Thus, settings may sometimes be incorrectly defined, and the threshold may be too low or too high to capture events and alarms, without actually having events and alarms present or having no impact. This is typically where knowledge of subdivisions and related types of loads helps identify nuisance events and/or alarms, as there is no possible impact on the load at this site.

More detailed aspects related to characterizing and/or quantifying at least one identified alarm nuisance behavior are further discussed in connection with the following figures (e.g., fig. 5). However, it suffices to say here that, in addition to or instead of the above, the characterizing and/or quantifying may comprise grouping the at least one identified alarm-nuisance behavior into one or more of a plurality of: predefined or prescribed alarm nuisance behavior, user-defined alarm nuisance behavior, or learned alarm nuisance behavior.

At block 415, after characterizing and/or quantifying the at least one identified alarm nuisance behavior, a determination is made as to whether the at least one identified alarm nuisance behavior satisfies at least one prescribed condition. More specifically, information related to the characterization and/or quantification of the at least one identified alarm nuisance behavior is analyzed to determine whether the at least one identified alarm nuisance behavior satisfies at least one prescribed condition. The prescribed condition may include, for example, a minimum occurrence of at least one identified alarm nuisance behavior within a given analysis period for treating the at least one identified alarm nuisance behavior as nuisance behavior for purposes of future analysis. In one example embodiment, the steps that occur at block 415 include a filtering step. For example, a simple rendition (or another selected number of occurrences or renditions) may not be considered a nuisance behavior. According to some embodiments of the present disclosure, this type of behavior may be filtered or removed from the dataset, including at least one identified alarm nuisance behavior.

A single occurrence may be effective for a stale alert. For example, 10 stale alarms that exist over a longer period of time (e.g., hours or even days and weeks) will become the baseline for the alarm (when present), and thus will not need to be repeated multiple times to be designated as nuisance behavior. As for alert floods, nuisance behavior may be effective even if only one 10 minute interval shows flood behavior for a particular analysis period (e.g., 550 alert hit systems in 2 minutes). Some embodiments may consider a flood period too short to "permanently overwhelm" a team. In this case, the system may employ a correlation filter. Some examples of possible implementations include: (1) At least 3 consecutive 10 minute intervals are required to display flood behavior, or (2) a composite average alert volume over a sliding window of 3 consecutive 10 minute intervals may be required to declare flood nuisance behavior effective. It should be understood that these are but a few of the many possible example implementations.

At block 415, if it is determined that at least one identified alarm nuisance behavior satisfies prescribed conditions (such as those discussed above), the method may proceed to block 420. Alternatively, if it is determined that the at least one identified alarm nuisance activity does not meet the prescribed conditions, the method may end or return to block 405 (e.g., for processing additional or newly received information related to the at least one identified alarm nuisance activity).

At block 420, information related to the at least one identified nuisance activity may be appended to time series information associated with an identified alert (e.g., the alert identified at block 215 of method 200). The additional information may include, for example, information related to the time of occurrence(s) of the identified alarm, the frequency of occurrence(s) of the identified alarm, the duration(s) of the identified alarm, the amplitude(s) of the identified alarm, the severity(s) of the identified alarm, the location(s) of the identified alarm, the group or cluster of the identified alarm, metadata, and the like. According to some embodiments of the present disclosure, additional information is layered at block 420 over information that may be marked or appended at block 410 (e.g., when performing the example steps discussed in connection with fig. 5, as will be discussed further below).

In one example embodiment, the event that passed the filter at block 415 appends information associated with the nuisance data to existing event and/or alarm data for later processing steps. More specifically, the data may be enriched with existing event and/or alert data. For example, it may provide additional new data to be used for later processing steps (e.g., filtering nuisance actions in the visualization, taking action only on nuisance events and/or alarms, or conversely, taking action only on events and/or alarms that do not display any nuisance actions). The data may be made available or pushed to other layers of the alert analysis system or any other system that utilizes or analyzes any event and/or alert data. In addition, the data may be stored in the same database or appended to an event data file (e.g., inside a json file, an appended json file, etc.). It may also be pushed and published in a similar manner as other event data.

At block 425, at least one potential nuisance remedy may be identified to address at least one identified alarm nuisance behavior, e.g., based on analysis of information appended or tagged to time series information (e.g., at blocks 410 and/or 420). According to some embodiments of the present invention, at least one potential nuisance remedy may be identified from a list, library, or repository of possible nuisance remediation techniques, devices, suggested settings adjustments, or the like. Additionally, according to some embodiments of the invention, the at least one identified potential nuisance remedy may include recommendations as to how to avoid nuisance behavior with respect to alarms/events. For example, the at least one identified potential nuisance remedy may include timestamp correction, removal of false stale alert duration, and possible removal of nuisance characteristics of stale alerts. For each IED, each event type of a given IED, and each event and/or alarm, the duration may be checked and verified, for example, using the time stamp and duration provided by the IED. If there is a discrepancy between the two, a possible remedial action may be identified. For example, the duration reported by the device may be used to replace the lost/end timestamp of the loss or error (e.g., pick up timestamp plus event duration reported by the IED to create the lost/end timestamp). This may trigger an alarm health status update as it indicates adverse event data quality (and may include lost data affecting the final data quality).

In addition, for each IED, each event type of a given IED, and each event and/or alarm, the maximum possible or applicable duration of the event type may be utilized to evaluate and verify the duration. If the duration derived from the time stamp exceeds the maximum duration of the event type, the loss/end time stamp and duration of the event may be marked as "quality bad-error" in the system. This in turn may trigger a system analysis to identify possible remedial actions. For example, the maximum possible duration of the event type may be used to replace the lost/end timestamp of the loss or error (e.g., pick up timestamp plus event duration reported by IED to create the lost/end timestamp). Again, this may trigger an alarm health status update, as it indicates adverse event data quality (and may include lost data affecting the final data quality).

There are several types of mitigation and/or remediation for tremor nuisance alarm behavior. Remediation may be performed at the source or at each subsequent layer and sub-layer (e.g., preprocessing layer, analysis layer, and action layer, which may be subdivided again according to the type of action, such as visualization and/or control sub-layer). The remedies of the prior art are generally focused on the source. The first idea is to use the duration to avoid triggering a "very short duration event" before an alarm is considered valid. Alternatively, another idea is to extend the duration to avoid detecting a "quick return event" that is different from the previous alert. The proposed remedy may utilize expertise to extend the on delay setting (i.e., extend the time before an event and/or alarm is triggered or "on") or the off delay setting (i.e., extend the time before an event and/or alarm is "off"). These remedial steps are described, for example, in ISA 18.2 standards and are applied, for example, in departments such as oil and gas.

It should be appreciated that a major disadvantage of these types of remedies is that they reduce the ability to detect event occurrences and their associated details within each occurrence, resulting in information loss. For example, if ten events or alarms occur again within 1 minute after the end of the previous event, and the expert has defined a 2 minute off delay time setting to reduce chatter behavior, only one alarm is triggered instead of ten different alarms. As another example, if five original alarms determine that the source of an event is upstream of the connection point of their IEDs and five subsequent alarms determine that the source of an event is downstream of the connection point of their IEDs, then this critical information will be lost and not captured as being different from the first alarm and/or event. In the same way, if the five final alarms have different levels of load influence/loss (e.g. 30, 40, 50, 40, 30), this detailed information will also be lost, since only one event/alarm will be detected at the IED level.

In one embodiment, the disclosed invention proposes to automatically recommend (e.g., report) set changes in the on-delay and off-delay duration for each IED and alarm. In another embodiment, the disclosed invention proposes to automatically recommend updating the settings of the on-delay and off-delay duration of each IED. At constant periods or at any detected pattern change of each IED and/or each type of event and/or alarm, the system can derive recommended optimal settings from the duration and duration of the next alarm reproduction for all events up to that period to reduce chatter behavior.

For example, for all "quick recurring events and/or alarms", the system may define an ideal closing delay duration, which reduces the number of nuisance recurring. This is shown, for example, in fig. 3C by graph 330. Reference numeral 331 denotes the y-axis, which is the event duration in seconds. In addition, reference numeral 332 indicates an x-axis, which is the duration in seconds until the next occurrence of an alarm again. Reference numeral 333 indicates that the alarm occurred once as a small bubble, and reference numeral 334 indicates a vertical line of the 90 th percentile of all alarms on the x-axis. The line shows all alarms representing 90% of all data points to the left (i.e., all chatter alarms reoccur). Reference numeral 335 represents a horizontal line for the 90 th percentile of all alarms on the y-axis. This line shows all alarms at the bottom representing 90% of all data points (i.e., all chatter alarms occur again). In addition, reference numeral 336 denotes an amount related to the vertical and horizontal lines of the blocks 334 and 335, and is linked to the junction of these two lines.

It should be appreciated that there are several ways to infer this duration from the data to the next alarm threshold. A simple embodiment would use statistics such as (in many other ways) "what is the number of alarms for the 80 th percentile, 90 th percentile, 95 th percentile, 98 th percentile for the duration of the alarms until the next re-occurrence of the dithered behavior? The system may select a predetermined highest aggregate value (e.g., 95 th percentile or 98 th percentile) and add the corresponding duration value to the shutdown delay duration. The system may also be configured with a more optimized approach, such as using penalty scores to determine relative improvements to avoid over-tuning of the system that may not pick up additional different events/alarms. For example, the system may calculate the improvement ratio based on a percentage increase in the amount of the tamper remedy or a percentage increase in the duration to the next alarm.

It should be appreciated that other metrics may be used as optimization metrics. For example, the system may compare the alert average value for each interval calculated for an analysis period to a previous period using a global metric. When a large change occurs (e.g., an increase in the number of nuisance alarm recurrences), the system may recommend updating the settings so that the number of nuisance alarms automatically decreases. In this case, instead of using a fixed percentile, the system may determine the percentile to return to the previous number of nuisance acts (e.g., if those acts are deemed acceptable). The system may also be trained by the user by implementing a user feedback loop to train acceptable (and conversely unacceptable) content to train the system when too many alarms occur again. The system user may, for example, use an input mobile interface on their smartphone to select when too many alarms again occur on the visualization screen of the alarm system.

As described above, with respect to the remedial examples discussed, the disclosed invention enables a simple solution. As explained above, this basically creates a filter, as more detailed and relevant information may no longer be available to supplement the analysis steps, as IED sensitivity is reduced. Under certain conditions, reduced sensitivity may be required if a particular setting on a system or a particular device is overly sensitive (e.g., captures redundant or unimportant events and/or alarms). The disclosed invention focuses on the appropriate level of remediation, which means that the system does not reduce the data captured at the source by applying any filters (changing the device on-delay and off-delay duration settings) but by adding the corresponding remedies required for each discrete use in the subsequent layers.

Relief and remediation may also be defined and tuned to the needs of each layer and sub-layer. The layers and sub-layers may include a preprocessing layer, an analysis layer, and an action layer, which may again be subdivided according to the type of action (e.g., visualization and/or control sub-layers). For example, the system may be set without applying any signal reduction (i.e., filtering) at the source (e.g., IED on-delay or off-delay duration settings) and without changing any threshold settings (unless something is wrong or inconsistent with the measurements and other information associated with the event and alarm). This means that events are captured each time the relevant measurement (e.g. voltage, current, power factor, THD, reactive power, etc.) crosses a threshold value. If a certain threshold is exceeded, a corresponding alarm may be triggered each time. At this point, in contrast to ISA 18.2, the number of events or alarms is not considered a nuisance to the system. The user does not need to see the amount of alarms that the system processes and solves or "drown" or "overwhelm" the amount of alarms that the system processes and solves. The invention focuses on parsing each layer (one at a time) and responding accordingly to the added value of each layer. The data presentation layer enables simple presentation of the results after distinguishing the basic information of a particular user, subdivision and/or profile.

After removing nuisance behavior at each tier, the present invention identifies the initial source, breadth, propagation of events, and identifies the impact of events and/or alarms on the system (e.g., initial IED pickup, initial meter location, event source, propagation of events within the system, with or without impact, etc.). As already discussed, this is an important reason for not reducing the signal level (e.g., artificially reducing granularity, sensitivity, and frequency of occurrence of information).

According to some embodiments of the present disclosure, no remediation may be applied at the preprocessing step (e.g., at block 510 of method 500, as will be discussed further below). Events and alarms are analyzed and any nuisance behavior (according to any criteria, such as ISA18.2 and any additional user/system definitions) will be identified and characterized. In some embodiments, chatter alarm removal of the system is not performed in the cause and effect analysis layer; however, it depends on the analytical step being performed.

Other remedial options may be provided, for example, on a visual interface, according to some embodiments of the present disclosure. For example, aggregation of "event sequence advanced" visualizations may be provided. In this visualization, only one event aggregates all chat events from the initial pick-up timestamp to the end of the overlapping event sequence. The sequence of events has metrics such as the number of chatter alarms, pickup time stamps, and/or worst effects for each event and/or alarm type that occurs during the sequence. In another embodiment, related and/or associated actions may be distinguished, classified, separated, analyzed, processed, managed, or otherwise within a single alarm type. For example, a voltage dip may be separated or classified into a voltage dip originating from upstream of the IED and a voltage dip originating from downstream of the IED. Similarly, for example, the affected phases (e.g., A, B, C or 1, 2, 3 neutral conductors, etc.) may be separated or sorted accordingly. Upstream and downstream sources are distinguished and attached to event and/or alarm tags and are shown as distinct lines in the figure. An aggregate "event present 1 minute or 10 minute intervals" visualization may also be provided. In this visualization, events may be considered to be present in every 1 minute or every 10 minute interval, whether occurring one or more times during the interval. If any chatter occurs during this period, the interval marks and/or marks may simply be designated as "chatter occurrence". Marking and/or marking may be performed using specific color or intensity heat map color codes to indicate such dithering. This may be performed in a graph/graph separate from the global "event present" visualization. Flood analysis visualization may also be provided, wherein discrete flood periods are identified, and the contribution of the dithering behavior to each flood period is discernable as a stacked graph of each event/alarm of each IED.

It should be appreciated that more global metrics may be provided for nuisance behavior. The data may be aggregated, including, for example, the amount of jitter nuisance behavior in an analysis period and trends relative to previous analysis periods, etc. Details of each event and/or alarms for each device may also be presented. These may include global metrics to identify the particular alarm and the IED that contributes most to a given nuisance behavior, the first ten worst contributors (e.g., event and/or alarm types, IEDs accumulating all events and/or alarms, etc.). In some cases, specific metrics associated with the recommendations may be provided in the report or in the user interface for each event and/or alarm of each IED. At the action layer (control sub-layer), for example, an extremum distribution (e.g., amplitude, imbalance, etc.) may be provided.

For transient nuisance alert behavior, it is understood that there are many possible mitigation and/or remedial actions. In one embodiment, the system may prepare the analysis to help the expert adjust the alarm threshold. For example, the alarm threshold may be analyzed to determine whether the threshold level is properly configured/set. According to some embodiments of the present disclosure, this may require domain expertise and cannot be performed independently (i.e., autonomously) by the system. However, the system may prepare the analysis and use a graph similar to the tremor behavior analysis. This type of graph helps the user understand which extrema (e.g., maximum/minimum amplitude of events) that trigger an alarm occur. This helps to determine a threshold to reduce the number of alarms triggered/detected. Consistent with the load loss algorithm, this feature helps determine the magnitude by which the load can traverse without significantly affecting the load and process. Thus, the expert may use this analysis to determine an event-set threshold that will be different from an alarm that is determined to be triggered only when an influential event threshold is exceeded (e.g., capturing a dip at 90% of the nominal voltage and related information, but not triggering an alarm until the dip falls below 60% of the nominal voltage). Fig. 3D shows such a graph 340. In this case, the measured value indicated by reference numeral 341 is the voltage THD. As can be seen in the line associated with reference numeral 342, most occurrences are associated with a value of 6%. However, in some cases, some occurs at 6% of the voltage THD, as indicated by reference numeral 343.

In some cases, resolution of flood periods may be more complex, as such nuisance behavior is often not directly linked to a single alarm or a particular IED. In some cases, a single IED may generate many/most of the flood periods. In one example, this may be due to an incorrect or allergic alarm threshold (e.g., a slump threshold configured to be 5% of nominal voltage). In this case, the extremum map of the system may be sufficient for the expert to identify the anaphylaxis threshold, as they will see many slump alarms (i.e., obvious outlier thresholds) between 95% and 90% of the nominal voltage. The mitigation actions will be apparent to the expert to reduce flood conditions and possibly also to reduce tremor alarm nuisance behavior or transient alarm nuisance behavior. This may also indicate incorrect settings (e.g. wrong CT/PT ratio) or malfunctioning IEDs. An expert is required to evaluate the IEDs and their configuration to identify problems. However, the system may identify a single source of flood periods to help guide maintenance actions. In many cases, multiple IEDs and alarms of similar and different types are involved and co-occur within a flood period, each flood period possibly different. The system may require a higher level analysis of IEDs and alarms that occur together during each and all flood periods.

In some cases, the at least one identified alarm nuisance behavior may be indicative of a problem associated with the electrical system (e.g., the electrical system itself or with an associated EPMS device), as will be appreciated from the further discussion below. At least one action or type of mitigation may be taken or performed to improve or solve the problem. It should be appreciated that in some cases, this at least one action or type of mitigation may be related to at least one potential nuisance remedy identified at block 425.

After identifying at least one potential nuisance remedy at block 425, at least one action may be taken or performed at block 430 based on or in response to the at least one identified potential nuisance remedy. For example, the at least one action taken or performed may include one or more of selecting and recommending at least one potential nuisance remedy. For example, one or more of the at least one potential nuisance remedy may be selected and recommended based on the particular user and/or customer segment type associated with the electrical system. In addition, the at least one potential nuisance remedy (e.g., the selected and recommended at least one potential nuisance remedy) may be applied or initiated (e.g., automatically, semi-automatically, or manually). According to some embodiments of the present disclosure, the recommendation may be provided to the end user by at least one of: text, email, reports, alarms, audible communications, and communications on the screen/display interface (e.g., of the user device).

According to some embodiments of the present disclosure, it is important to ensure the consistency of such possible remedial solutions before taking action on the event. For example, the meter may pick up a series of different types of events, all of which are continuous nuisances that are actually part of the initial event. This has been observed with respect to example voltage nuisances that can begin as a line-to-line fault event and become a two-phase ground fault event, each aspect having its own duration. Thus, the system can check whether only one single event occurs for a given IED and within a given sequence of overlapping events. Alternatively, it may be determined whether several events follow each other or even co-occur. At this point, the system may insert reconciliation steps with different durations of the correct individual events. The entire event may be a complex event suite consisting of at least two consecutive and/or co-occurring events, each event having a duration of possible correction. This coordination step ensures that the overall event will get the correct duration (i.e., consider all constituent durations) and use these to validate existing complex event durations or create one complex event and associated overall duration.

After coordinating the duration and the missing time stamp, the missing pick time stamp of the event data can now be evaluated, which is a process symmetrical to the missing time stamp. For example, the system may identify missing timestamps that do not have matching pickoff timestamps for a given IED or each type of event and/or alarm (e.g., find a pattern such as one pickoff timestamp for two missing timestamps). If the event loss timestamp is associated with a device event duration in the event data sent by the IED, a missing pickup timestamp of the event may be inferred (e.g., the duration is inferred using the loss timestamp). The system determines the maximum duration of the event type. For the above-described slump example, the maximum duration will be between 2.55 seconds and 1 minute, depending on the geographic location and specifications of the IED and/or standard versions or potential custom settings. If the event loss timestamp does not have any associated duration and the event type has a maximum duration, the system will trigger the creation of a lost pickup timestamp. The pick-up timestamp will be calculated by taking the missing timestamp and deriving the maximum possible duration. The created event and/or alert pickup time stamp will be marked as "less valid data".

In some example embodiments, one or more alert system health indicators may be used to observe and provide an improvement or degradation in alert system health. For example, if a non-proportional increase in the number of lost timestamps is detected by the process, the indicator may highlight the alarm system health degradation from the measurement. In this case, additional analysis of a particular source of poor data quality (e.g., a single device associated with such an increase, or whether it is propagating on the system) may be provided. Conversely, if the proportional amount of lost time stamps decreases (such as when changing from 3% to 1%), the alarm system health confidence index should increase.

In each case, if the system later receives measured event and/or alarm data, it is important to enable the system to correct any replacement data by going through these steps again. This should re-trigger the mechanism to re-check for stale alarm nuisance behavior because late data may provide some, but not all, lost timestamps. In one example embodiment, at least some of the detected stale alert behavior may be removed and remediated with a lower data quality timestamp.

As previously mentioned and further described in connection with fig. 5, several nuisance actions may occur simultaneously in some cases. This is for example evident during a flood period, which is one example type of behavior detected by nuisance occurring for example within 10 minute intervals. During flood periods, several alarms may be observed that display dithered alarm behavior (such as each alarm repeated 10 times within the 10 minute interval).

According to some embodiments of the invention, the system may choose to apply different mitigation or remedial actions, depending on, for example, the type of nuisance activity. The most obvious but easiest to adjust may be the settings on at least one IED responsible for capturing the energy related signals. This should first be analyzed to identify any incorrect settings or problems of the at least one IED. If all settings are appropriate and correspond to standard or reasonable engineering practices and process types or monitored loads in this section, no further action needs to be taken at the source without completely affecting the analysis. As this may cause the system to become blind to the actual active alarms and/or actual active events. If an erroneous setting is achieved, a problem may not be detected.

According to some embodiments of the present disclosure, the second most obvious step may be to preserve complexity in the different processing and analysis steps and simplify presentation for the user. This is typically an essential part of the UX/UI operation, e.g., each user only needs to see what is relevant to their respective roles. For example, only high-level statistics may appear in the C-level report, along with possible graphs showing global trends and few points. For these users, the time to absorb the information may be about five seconds; therefore, a quick understanding of all alarm nuisance behaviors is needed. In another case, an expert may need to analyze all events and alarms for a period of time prior to a critical outage in a data center to accurately post event. For this example, a survey is described that ranges from hours to days (even weeks) to ensure and verify that the situation is minimized for future reproduction.

It should be appreciated that many different solutions may be implemented. In one example implementation, the most obvious solution is to simply present an alarm at a value of 1 or not present an alarm at a value of 0. Any such graph will be easily readable as this is a presence/absence state graph. This helps the human brain to visualize the co-occurrence of alarms (and conversely, when alarms are not co-occurring). This helps to eliminate chat behavior in the user's UX. In further example implementations, the solution may be to remove stale alarms and create a specific/different graph for all stale alarms for the analysis period (e.g., month being analyzed). In another example embodiment, flood periods may be presented in a separate graph and analyzed separately from other alert periods. This will generally avoid the phenomenon of "skewing the graph" with the highest value of the other periods. By removing and processing/analyzing floods separately, additional patterns that occur during non-flood periods can become more visible.

In another possible implementation, a real-time system (e.g., a SCADA system) may enable a user to study each event more deeply when an alert arrives. It may still have a "simplified layer" where nuisance behavior does not clutter the screen, but the system will enable expert users to zoom in on basic aspects without the need to initially display any alert related nuisance behavior, such as chat or transient behavior (but still be able to display and highlight flood periods). In another example embodiment, the system may generate periodic (e.g., monthly) nuisance alert reports suggesting specific nuisance behavior reduction (mitigation and remediation) actions.

In another example embodiment, the system may remove nuisance behavior in certain processing steps that do not require details. For chat behavior, the system can determine what the typical duration until the next occurrence of an event is. It may then determine that the setting(s) of the alarm are continuous alarms. This may be done, for example, by varying the duration of time before the exit (alarm end). According to some embodiments of the present disclosure, the system may be able to distinguish between a flutter meter (i.e., a meter with a flutter alert), a flutter alert (i.e., an alert with a flutter behavior), and a flutter alert nuisance behavior (i.e., when it is fluttering). The system may also be able to classify whether the source (IED) is continuously vibrating, and then may analyze whether any obvious patterns are present and refine accordingly as the meter is continuously vibrating. For example, when HVAC cools or heats a facility, or only during certain processes that run at certain times of the day, the source may tremble during on-site startup.

In some cases, a continuously vibrating meter/alarm may be identified and indicated. This distinction may be important to provide the correct recommendation, as chat behavior is a relative concept. For example, it may be defined at the system level, at each device level, may be based on a fixed duration (e.g., 1 hour) to the next alarm, or it may be relative to each location/meter. For example, the system may infer what threshold is relevant to attributing the meter to chat behavior to the typical duration of the next rendition of the same alert based on a mixture of statistics and domain-specific knowledge-based rules. In another embodiment, the system may propose or even take action to automatically correct or propose to the user to verify the correction prior to the embodiment (e.g., create missing pick-up timestamps or missing loss timestamps as previously described).

It should be appreciated that many other example actions may be taken or performed at block 430. For example, for a given nuisance behavior, several mitigation and remedial actions may be triggered at different levels; the alarm data may not be removed in the process. A specific visualization may be created in which nuisance behavior is removed in the real-time system UX interface (e.g., SCADA system). A nuisance reduction report may be created and waveform capture may be marked as including nuisance behavior. Filtering of nuisance behavior may be enabled (e.g., only relevant event data is shown in EPMS for class C dashboards). False stale alarms may be filtered and a missing pickup timestamp or missing timestamp may be created.

After block 430, the method may end, return to block 405, or may take one or more actions. For example, in embodiments where it is desired to continuously (or semi-continuously) analyze received information related to at least one identified alarm nuisance behavior (i.e., one or more different points in time), the method may return to block 405 (e.g., analyze further received information). Alternatively, in embodiments where it is desired to analyze a single set of received information, for example, the method may end or one or more actions may be taken. Example actions may include storing, displaying, and/or analyzing previously received information related to at least one identified alarm-specific behavior. Other example actions will be apparent to those of ordinary skill in the art. In embodiments where the method ends after block 430, the method may be reinitiated, for example, in response to user input and/or control signals.

It should be appreciated that in some embodiments, the method 400 may include one or more additional blocks. For example, additional example blocks may occur in method 400 and/or other methods disclosed herein, and may include the ability to correct alert information (such as a pickup timestamp) sent by a device based on a text/tag description. For example, today's events may be marked at the moment of detection; however, the analysis period may have already started earlier. This is true for any RMS calculation done over a period of time (e.g., over 1, 2, 5, 10, or 15 minute intervals or even 1, 2, 6, 8, or 24 hours). In each of these cases, the system analyzes the text or tag or type of the alarm/event and extracts therefrom the time period/interval at which the event was calculated. If an alarm or event is detected and triggered, the IED or system corrects the event pick-up timestamp to cover the entire interval/period of each event. For example, "10 minutes alarm beyond THD average" associated with a pick-up timestamp and a missing timestamp "2021.03.01 22:00:00", the missing timestamp "2021.03.01 22:00:00" is when the IED has a value above the alarm threshold and issues an alarm. This will then be corrected to "event pick-up timestamp= 2021.03.01 21:50:00" and "missing timestamp= 2021.03.01 22:00:00". This more accurately reflects the reality between coverage areas. In this case, the system creates a new timestamp distinction between the event itself (i.e., with the correction period associated with the interval for average calculation) and when the alarm was detected and sent (i.e., at the 10 minute interval at the end of this time).

Other exemplary aspects, features and variations of the disclosed invention will be apparent from the following discussion.

Referring to FIG. 5, a flowchart illustrates an example method 500 for characterizing identified alarm nuisance behavior. In accordance with some embodiments of the present disclosure, method 500 illustrates example steps that may be performed in conjunction with methods 200 and 400 discussed above in conjunction with fig. 2 and 4. For example, in one example embodiment, the steps performed in method 500 may correspond to example steps that may be performed at one or more of blocks 405, 410, and 415 of method 400. Similar to methods 200 and 400, method 500 may be implemented on a processor of at least one IED (e.g., 121 shown in fig. 1A) in an electrical/power system, a processor of a diagnostic system (e.g., 125 shown in fig. 1) in an electrical/power system, and/or remote from at least one IED and the diagnostic system.

As illustrated in fig. 5, method 500 begins at block 505, where information relating to at least one identified alarm nuisance behavior is received. Similar to block 405 of method 400, in some cases, the received information may include aggregated information from block 220 of method 200 for identifying at least one alarm nuisance behavior at block 225 of method 200.

At block 510, the information received at block 505 is preprocessed. It should be understood that the preprocessing of the information may take various forms and include various steps. For example, in one example of an implementation, obvious errors (e.g., date of error) may be filtered out of the information. For example, possible dates before installation and/or recording capabilities (e.g., dates of the 19 th century) or future dates (e.g., five days in the future), errors that may be caused by errors and/or malfunctions of the IEDs, or errors that may be caused by communication errors (e.g., when using radio transmissions, and signals may be modified or only partially received), or errors that occur more frequently due to system configuration changes (e.g., time stamp conventions) may be filtered from the information. According to some embodiments of the present disclosure, the system may provide useful information and warnings to the user regarding filters of any application, as well as regarding the degree of each filter (e.g., the percentage of data filtered) and possible impact.

It should be appreciated that the preparation process at block 510 may include many additional or alternative steps. For example, the duration of an event may be detected and/or analyzed for each event identified from electrical measurement data from or derived from energy-related signals captured by at least one IED (e.g., at block 205 of method 200). In one aspect of the invention, the duration of an event may be recalculated based on available events and/or alert data. Additionally, the alarm health status indicator may be recalculated to evaluate coherence and data quality. Thus, it can be observed whether the received and/or stored data is complete (e.g., with event type, there is event pick-up timestamp data and event miss timestamp data for the same event). It is important to distinguish between missing data that produces spurious nuisance behavior and actual events and/or alarms that display nuisance behavior (e.g., stale alarms remain active for days or even weeks until acknowledged or an event is received to end).

In some embodiments of the present disclosure, each alarm duration may be checked for events and/or alarm types. For example, many power quality events have a specified maximum duration associated with the event type. For example, according to IEEE standard 1159-2019, the voltage dip is limited to a duration of less than 1 minute, which may vary from standard to standard. In some cases, this definition and many other definitions may be included in the device setup data. If the system(s) and/or device(s) implementing method 500 indicate a slump alarm as including nuisance behavior (e.g., 10 hours duration), this is incorrect by definition. Thus, it may be considered an erroneous nuisance behavior, and most likely due to the loss of missing event timestamps. In some cases, the duration until the next event is detected/triggered may also be determined. For example, this may be a key metric for detecting a particular type of nuisance behavior, including chat and brief periods for a given event or alert.

At block 510, a time period (e.g., monthly, quarterly, yearly) associated with the information to be analyzed may also be determined. For example, time-dependent frames required for further analysis may be created/defined/determined at block 510. For example, it may be determined that each 10 minute time interval from the pickup time stamp to the missing time stamp should be analyzed. Thus, 10 minute intervals may be created, including intervals where no events occur in some cases. It should be appreciated that in other cases, each 1 minute interval frame, 1 hour interval frame, etc. may additionally or alternatively be analyzed.

At block 510, incident frames (i.e., sequences of overlapping events) may also be inferred from events from individual devices or all devices. In an example embodiment of the invention, at block 510, all events that are persistent events (e.g., events that last more than 10 minutes, 1 hour, or another defined period of time) may be filtered or removed. This is done to avoid creating a heterogeneous sequence (e.g., one long event and/or alarm lasting 3 hours would aggregate very short duration events of about 21 sub-sequences, such as a series of voltage drops). This creates a sequence of overlapping events that infer possible temporal relationships.

At block 510, a correlation metric (an example of a 10 minute interval, but is also true for an incoming frame) may also be identified for each of the above frames. These metrics may include, for example, (1) events and/or alarms present (in every 10 minute interval), (2) types of events and/or alarms occurring (in every 10 minute interval), and/or (3) different IED sources of these events and/or alarms (in every 10 minute interval). It should be appreciated that many other additional or alternative metrics are possible and contemplated by the present invention.

At block 510, relevant information may also be identified for each event and/or alarm. For example, an extremum (e.g., amplitude of a slump event, maximum imbalance between two phases of a voltage imbalance event, etc.) may be identified. In addition, all relevant text information may be extracted and a mapping to a unique reference to different types of events and/or alarms may be created. These events and/or alarms may include, for example, power quality events or any other type of event and/or alarm present in the system (e.g., protection events and/or alarms, operating states, settings changes, etc.).

It should be appreciated that many additional or alternative steps may be performed at block 510. In one aspect of the invention, additional or alternative steps may be performed with several objectives in mind. These targets may include, for example, refinement analysis. For example, the sequence of overlapping events may be further subdivided by grouping only events of similar type (e.g., grouping only voltage dips and voltage surges in one group separately from any voltage imbalance or voltage harmonic sequence). The primary goal may also include a preparatory action/suggestion. For example, a single line diagram may be used to create branches related to a particular type of load (e.g., a motor that may create a voltage dip when energized).

Following block 510, information from blocks 505 and/or 510 is used in subsequent blocks of method 500 to characterize at least one identified alarm nuisance behavior. More specifically, the at least one identified alarm nuisance behavior is analyzed to determine whether the at least one identified alarm nuisance behavior can be grouped into one or more of a plurality of predefined or prescribed alarm nuisance behaviors, user-defined alarm nuisance behaviors, and/or learned alarm nuisance behaviors. In the illustrated embodiment, the plurality of predefined or prescribed alarm nuisance behaviors, user-defined alarm nuisance behaviors, and/or learned alarm nuisance behaviors include at least one of: stale alarm nuisance behavior, dithered alarm nuisance behavior, transient alarm nuisance behavior, and flood alarm nuisance behavior, as will be further appreciated from the discussion below. It should be understood that these are just a few of the possible types of alarm nuisance behavior described by the disclosed invention. Other example types of alert nuisance acts will be apparent to those of ordinary skill in the art (e.g., an alert that does not adequately exhibit a severity or a critical score may be considered an alert nuisance act, a non-affecting alert may be considered an alert nuisance act, etc.).

Returning now to block 510, after preprocessing the data at block 510, the method proceeds to block 515 where it is determined whether a first type of nuisance alarm behavior (i.e., stale alarm nuisance behavior) is detected. For example, the pre-processed data having information related to the at least one identified alarm nuisance behavior may be analyzed to determine whether the at least one identified alarm nuisance behavior meets a predefined, prescribed, user-defined, or learned threshold associated with stale alarm nuisance behavior.

Stale alarm nuisance behavior is a well-known class of nuisance behavior that is described in very general terms within standards such as ISA 18.2. For example, ISA18.2 defines a stale alert as "an alert that remains advertised for an extended period of time (e.g., 24 hours"). The disclosed invention can utilize a user-defined duration threshold, such as "any alert that lasts longer than x hours". It should be appreciated that x may vary at each site (e.g., one site may use 8 hours as a threshold to work shifts over 8 hours, while another site may use 24 hours to reflect daily rates).

It should be appreciated that the threshold may be set differently depending on the event and the type of alarm. For example, by definition, steady state power quality events last much longer than transient events. The threshold may be set by a domain expert, refined by a user, and/or by a system engineer at commissioning time (e.g., 24 hours for any steady-state type of event and/or alarm, and 8 hours for any non-steady-state type of event and/or alarm (for work shift duration)).

It should also be appreciated that the threshold may also be inferred by the system by learning the "normal" duration of each type of event and/or alarm. For example, the system may use statistical methods, including accounting for any extreme outliers in terms of duration anomalies (e.g., statistical status of IQR with median duration+3 times duration using prior art). In another embodiment, the system may use a machine learning algorithm to detect outliers or model "normal behavior. All of these machine learning algorithms may be included in the term "anomaly detection algorithm" in the field of unsupervised machine learning (e.g., cluster-based, K nearest neighbor, LSTM, ARIMA, neural network, etc.). In summary, there will be many different implementations and algorithm combinations possible.

At block 515, if it is determined that the at least one identified alarm nuisance behavior meets a predefined, prescribed, user-defined, or learned threshold associated with stale alarm nuisance behavior, the method may proceed to block 520, where the at least one identified alarm nuisance behavior may be identified and/or marked as exhibiting stale alarm nuisance behavior. Alternatively, if it is determined that the at least one identified alarm nuisance behavior does not meet the predefined, prescribed, user-defined, or learned threshold associated with stale alarm nuisance behavior, the method may proceed to block 525, where it may be determined whether the at least one identified alarm nuisance behavior meets the predefined, prescribed, user-defined, or learned threshold associated with a second type of alarm nuisance behavior (i.e., dithered alarm nuisance behavior).

Dithered alert nuisance behavior is a well-known class of nuisance behavior that is described in very general terms within standards such as ISA 18.2. For example, ISA18.2 defines a chatter alert as an alert that repeatedly transitions between an active state and an inactive state for a short period of time. For example, fig. 3B provides an illustration of a tremor alert nuisance behavior. The first graph 320 gives an overview of the alarms for a number of months per 10 minute interval. These range from 0 alarms per interval to 76 alarms per interval, as indicated by reference numeral 322. Reference numeral 321 shows a scaling period used in the graph 325. In graph 325, the proportion of alarms that display the dithered alarm nuisance behavior becomes visible. As shown at reference numeral 326, all alarms are marked to show a chatter alarm nuisance behavior. Alternatively, only a portion of the alert presented in the interval indicated by reference numeral 327 shows the nuisance behavior of tremor.

According to some embodiments of the invention, the threshold associated with the tremor alert nuisance behavior may include at least one user-defined threshold. For example, the user-defined threshold may include a user-defined duration threshold (e.g., "any alarm whose duration to the next alarm is below a certain threshold"). For example, Y may be a standard value, so "if an alarm is repeated within 1 hour, it is marked as a tremor alarm". For example, one site may use 1 hour as a threshold based on measured or assumed response capabilities, so the alert's ability to take action by the administrative team, maintenance team, or another team can analyze, resolve, and/or confirm the alert. However, at another location, Y may be set to ten minutes, because team reactivity is much higher, so only faster reproduction is considered chat behavior.

The system may also infer thresholds associated with tremor alert nuisance behavior by learning, for example, the "normal" duration of each type of event and/or alert to the next alert occurrence. For example, the system may infer from the data what is considered a short period of time. Additionally, the system may utilize action data (e.g., confirm, resolve, rest, etc.) to learn the normal times of team reactivity involved in alarm management. In one example embodiment, it may compare the time an alarm occurs in the system (e.g., when the alarm is presented or transmitted to a team responsible for validating the alarm) with the time required to take an action on the alarm (e.g., confirm, rest, etc.). The time (i.e., duration) required for functioning can then be analyzed to determine a typical (e.g., median or average time) reactivity time. The system may also infer bandwidth around the median value from this data based on any statistical value, such as standard deviation or IQR.

By utilizing typical reaction times and bandwidths (e.g., typical reaction durations plus the sum of typical bandwidth durations), the system can infer "reactive durations" for each scene, and even for each event type. Applying this inferred "reactivity duration" to the time of the next alarm allows determining which alarm occurrence exhibits "a short period of time to transition between active and inactive states". This may be adjusted, for example, according to each event and/or alarm type, as different teams may be affected. In addition, this may be adjusted on a per team basis, as reactivity may be different between day and night shifts (e.g., the number of workers may be different and thus the reactivity may be affected).

If it is determined that the at least one identified alert nuisance behavior meets a predefined, prescribed, user-defined, or learned threshold associated with dithered alert nuisance behavior, then the method may proceed to block 530, where the at least one identified alert nuisance behavior may be identified or marked as including dithered alert nuisance behavior. Alternatively, if it is determined that the at least one identified alarm nuisance behavior does not meet the predefined, prescribed, user-defined, or learned threshold associated with the dithered alarm nuisance behavior, then the method may proceed to block 535, wherein it may be determined whether the at least one identified alarm nuisance behavior meets the predefined, prescribed, user-defined, or learned threshold associated with a third type of alarm nuisance behavior (i.e., transient alarm nuisance behavior).

Transient alarm nuisance behavior is a well-known class of nuisance behavior that is described in very general terms within standards (e.g., ISA 18.2). For example, ISA 18.2 defines a transient alarm as "an alarm that transitions between an active alarm state and an inactive alarm state in a short time without rapid repetition".

The disclosed invention can utilize a user-defined duration threshold (e.g., "any alert whose duration to the next alert is below a certain threshold"). For example, Z may be a user-defined threshold (e.g., "duration to next alarm longer than 1 hour, but less than 3 hours"). Similar to tremor alarms, for example, transient alarms may be different for each site, location, building, process, etc., and sensitive to segment context. In one example embodiment, the same chat threshold as the lower starting point may be used to infer transient alerts (i.e., any frequently recurring alerts that do not display chat behavior may be candidates for transient behavior), and then a higher threshold may be defined or inferred. For example, the higher threshold may be determined by utilizing rules or expertise (i.e., simple thresholds, making it a hybrid inference + expertise-based model). The higher threshold may also be inferred, for example, using an extreme outlier detection method or finding a "next normal/outlier breakpoint" algorithm (e.g., using change point identification or median +3×iqr). For example, Z will be any reoccurring alarm where the duration to the next alarm falls within a lower threshold and an upper threshold.

If it is determined that the at least one identified alarm nuisance behavior meets a predefined, prescribed, user-defined, or learned threshold associated with transient alarm nuisance behavior, the method may proceed to block 540, where the at least one identified alarm nuisance behavior may be identified or marked as including transient alarm nuisance behavior. Alternatively, if it is determined that the at least one identified alarm nuisance behavior does not meet the predefined, prescribed, user-defined, or learned threshold associated with the transient alarm nuisance behavior, then the method may proceed to block 545, wherein it may be determined whether the at least one identified alarm nuisance behavior meets the predefined, prescribed, user-defined, or learned threshold associated with a fourth type of alarm nuisance behavior (i.e., flood alarm nuisance behavior).

Flood alert nuisance behavior is a well known class of nuisance behavior, described in very general terms within standards such as ISA 18.2. For example, ISA 18.2 defines flood alarms as "alarm rate greater than conditions that an operator can effectively manage (e.g., more than 10 alarms every 10 minutes)".

The disclosed invention can utilize a user-defined alarm rate threshold (e.g., more than ten alarms per ten minutes). For example, the threshold may be relative to the number of operators (e.g., two operators would be at a rate of more than 20 alarms per 10 minutes, and three operators would be at a rate of more than 30 alarms per 10 minutes). Similar to other nuisance activity alarms, the alarm rate ratio per subdivision (oil and gas, semiconductor manufacturer, data center or office building), site, location, building, process may be very different. In addition, the alarm rate ratio may be inferred, e.g., using action data (i.e., confirm, resolve, lay down, etc.) to learn the normal times of team reactivity involved in alarm management. In one example embodiment, the time that an alarm occurs in the system (time presented or transmitted to the team responsible for validating the alarm) may be compared to the time required to take an action (validation, rest, etc.) on the alarm. The time (duration) required for functioning can then be analyzed to determine a typical (e.g., median or average time) reactivity time. The bandwidth around the median based on any statistical value (e.g., standard deviation or IQR) can also be inferred from this data.

With typical reaction times and bandwidths (e.g., typical reaction durations plus the sum of typical bandwidth durations), a "reactivity duration" can be inferred for each scene and each type of event. By applying this inferred "reactivity duration" alarm rate, it is possible to determine an alarm rate that makes it impossible to process data within a 10 minute time interval, or if greater than a 10 minute interval, determine a normal action duration. According to some embodiments of the present disclosure, this may be adjusted for each event and/or alarm type, as different teams may be affected. In addition, this may be adjusted on a team-by-team basis, as reactivity may be different between shift and night shift (e.g., the number of workers may be different and thus the reactivity may be affected).

For flood alert nuisance classifications at block 545, and for other alert nuisance classifications (such as those noted above), it should be appreciated that analysis of user interactions can also be used to teach the system which thresholds (and other characteristics) are typical for each given nuisance behavior. In addition, thresholds (and other characteristics) may be inferred (i.e., learned, derived) from the user indicia. For example, each team may have an interface or tool to mark an alert as displaying nuisance behavior, enabling a user to select the type of nuisance behavior displayed. In some embodiments, the system may summarize team or user definitions of alarms. For example, the system may also adjust the alert definition to each event and/or alert type, each team, each location or process within the field.

Returning now to block 545, if it is determined that the at least one identified alarm nuisance behavior meets a predefined, prescribed, user-defined, or learned threshold associated with flood alarm nuisance behavior, the method may proceed to block 550, wherein the at least one identified alarm nuisance behavior may be identified or marked as including flood alarm nuisance behavior. Alternatively, if it is determined that the at least one identified alarm nuisance behavior does not meet a predefined, prescribed, user-defined, or learned threshold associated with flood alarm nuisance behavior, the method may proceed to block 555, where it may be determined whether all time periods (and associated data) have been analyzed.

At block 555, if it is determined that all time periods (and associated data) have been analyzed, the method may end, return to block 505, or one or more actions may be taken. For example, in embodiments where new information is received that is related to at least one identified alarm nuisance behavior, it may be desirable to return to block 505 to receive and then process and analyze the newly received information (e.g., to further characterize and/or re-characterize the newly received information). In addition, in the event that one or more of predefined, prescribed, user-defined, or learned thresholds associated with various types of alarm nuisance behavior are redefined (e.g., due to changes in customer demand or constraints), it may be desirable to further characterize and/or re-characterize previously characterized alarm nuisance behavior. Further, with the addition of a new type of alarm nuisance behavior (i.e., beyond the four example alarm nuisance behaviors discussed above), it may be desirable to further characterize and/or re-characterize previously characterized alarm nuisance behaviors. Other example actions (e.g., storing and displaying information related to the characterized alarm nuisance behavior, etc.) will be apparent to those of ordinary skill in the art. In embodiments where the method ends after block 555, the method may be reinitiated in response to user input and/or control signals, for example.

Returning now to block 555, if it is determined that all time periods (and associated data) have not been analyzed, the method may return to block 510 for preprocessing and characterizing the time periods (and associated data) that have not been analyzed.

It should be appreciated that in some embodiments, the method 500 may include one or more additional blocks. Other exemplary aspects, features and variations of the disclosed invention will be apparent from the following discussion.

System and method for analyzing alarms to characterize electrical system problems

In accordance with another aspect of the present disclosure, a system and method for analyzing an alarm to characterize an electrical system problem is provided. It is well known that an important purpose of an alarm in an EPMS is to inform customers of the occurrence of an abnormal event within their electrical system. Alarms can be a powerful tool to quickly identify problems to improve uptime; however, even for experienced end users, alarms can be offensive, untimely, and overwhelming, especially in larger systems. Some events may generate different types of alarms (e.g., PQ events, over-current, communication errors, etc.), which may exacerbate confusion and ambiguity, cause errors, and waste time and/or resources. Ironically (and perhaps more importantly), the alert may cause the end user to ignore the value provided by his EPMS, as the end user may not know how the alerts are interrelated.

Typically, cues to understand the importance of alarm data are scattered across multiple alarms, various alarm types, and/or time ranges. The disclosed systems and methods for analyzing alarms to characterize electrical system problems analyze alarm data to determine correlations of alarms, system effects, spatial context, subdivision types, and/or load types to determine the scope and effect of electrical events. The context data (of both the end user's electrical system and its EPMS) can be used to determine the history, simultaneous and potential future impact of the event associated with the alert data.

Guidance regarding potential impacts and reasons (e.g., source location) may be provided from the analysis. For example, recommendations for solving or addressing problems may be based on subdivisions (e.g., data center vs. industrial vs. office building) and typical loads (e.g., motors, lighting, automotive industrial processes, HVAC, IT racks, etc.) and settings. Because each energy consumer uses energy "uniquely," the priority, threshold, and/or merging of multiple alarms may also be unique. The disclosed systems and methods automatically process alarms to simplify the indication from the EPMS, which improves the ability of the end user to respond in time. The purpose of this is to utilize the market segments/types of end users to evaluate alerts by their importance to the energy segment of a particular customer. For example, experiencing a voltage dip event in one market segment/type (e.g., semiconductor factory, data center, etc.) may have a more detrimental effect on operation than in a second market segment/type (e.g., business office building, etc.). In addition, the time that an event occurs in one market segment/type (e.g., day, night, etc.) may be more detrimental than in another market segment/type. The disclosed systems and methods facilitate the merging of alert data to assist end users in identifying problems for troubleshooting and cause analysis.

Referring to fig. 6, a flow chart illustrates an example method 600 for analyzing an alarm to characterize an electrical system problem in accordance with an aspect of the present disclosure. Similar to the previously discussed methods (e.g., methods 200, 400, 500), method 600 may be implemented on a processor of at least one IED (e.g., 121 shown in fig. 1A) in an electrical/power system, a processor of a diagnostic computing system (e.g., 125 shown in fig. 1) in an electrical/power system, and/or remote from at least one IED and the diagnostic computing system.

As shown in fig. 6, the method 600 begins at block 605 with energy-related signals (or waveforms) being captured or derived by at least one IED in the power system, similar to block 205 of the method 200 discussed above. At block 610, similar to block 210 of method 200, electrical measurement data from or derived from the energy-related signal is processed to identify an event (e.g., a power event) in the electrical/power system. Additionally, at block 615, similar to block 215 of method 200, in response to an identified event in or associated with the electrical system (e.g., a power event), it is determined whether any alarms have, should, or should have been triggered.

At block 620, the selection information is aggregated. For example, in one example embodiment, information about at least the identified events and/or the identified alarms may be aggregated (e.g., the number of daily events or alarms, the number of time-overlapping event groups, the impact on downstream loads, etc.). It should be appreciated that other example types of information may be aggregated at block 620, similar to the comparable blocks of the previous method (e.g., block 220 of method 200). For example, according to embodiments of the present disclosure, the aggregated information may also include information from at least one of: EPMS, SCADA systems (e.g., power SCADA, manufacturing SCADA), building Management Systems (BMS), I/O devices or data, PLC data, and system users (e.g., user initiated actions). As previously noted in this disclosure, in some examples, the EPMS may include at least one IED responsible for capturing or deriving energy-related signals (e.g., at block 605 of method 600).

Similar to block 220 of method 200, the information aggregated at block 620 may be aggregated based at least in part on customer or segment types (e.g., retail, office, hotel, hospital, data center, food and beverage, and oil and gas) because electrical system issues may be unique to each field/customer application, according to some embodiments of the present disclosure.

At block 625, the aggregated information is analyzed to determine problems associated with the electrical system. In some embodiments, for example, problems associated with electrical systems may include problems associated with EPMS responsible for monitoring electrical systems. The problem(s) associated with the EPMS may include, for example, the problem(s) associated with the EPMS not detecting or not adequately detecting the problem(s) present in the electrical system (e.g., unconfigured, misconfigured, IED problems, communication problems, etc.). It should be appreciated that many other types of problems may exist and are identified. For example, a problem may be associated with a load, an infrastructure (e.g., a transformer), and/or other types of monitoring devices other than an EPMS in an electrical system. For example, data events and/or alarm data from a first IED can be used to identify events and/or alarms that should or should have been (but are not) captured from a second IED. The method may be used to identify erroneous configurations (e.g., incorrect threshold settings), missing data, improper IED applications, etc. In another application, the system may detect that all IEDs use only default settings and/or do not tune or configure alarms for the field. In either case, the system will optionally issue an alarm and send a report to the user of the EPMS.

It should be appreciated that various types of information may be used to determine problems associated with the electrical system. For example, in some example embodiments, aggregated information may be utilized to analyze information related to impact and location to determine problems associated with electrical systems. Additionally, in accordance with some embodiments of the present disclosure, problems associated with the electrical system may be determined based at least in part on the customer or the type of subdivision.

According to some embodiments of the present disclosure, a problem associated with an electrical system may be indicative of a health condition of the electrical system. The health of the electrical system may correspond to, for example, the condition of the electrical system or the ability of the electrical system to perform or operate as intended. In some example embodiments, the health of the electrical system may be related to an alarm health of the electrical system, wherein the alarm health of the electrical system is indicative of the health of the electrical system. The alert health of the electrical system may be determined, for example, based at least in part on an analysis of at least one of: the number(s) of alarms identified, type(s), behavior(s), impact(s), and location(s).

The aggregated information may also be analyzed to determine the origin, source, cause, transition/evolution, and/or interrelationship of the problem associated with the electrical system at block 630. Similar to block 625, the aggregated information may be utilized to analyze information related to impact and/or location to determine the origin, source, cause, transition/evolution, and/or interrelationship of problems associated with the electrical system, according to some embodiments of the present disclosure.

According to some embodiments of the present disclosure, the origin may include the time, location, etc. of the problem. In addition, the source(s) may include process(s) and/or specific load(s) associated with the problem(s). The reason(s) may include the process (es) or what the particular load(s) is doing (e.g., motor start-up in the process). The transition/evolution may include a change in the problem(s) over time. For example, the transition/evolution of the problem(s) may indicate the severity(s), impact(s), priority(s), type(s), etc. of the problem(s) over time. For example, a problem may transition/evolve over time from a first problem type to a second problem type (e.g., relatively changing to relatively failing).

The interrelationship of the problems may indicate a relationship between various problems associated with the electrical system. For example, a first problem in an electrical system may be directly or indirectly associated with a second problem in the electrical system. Knowing the interrelationship between these problems can help better characterize the problem and more effectively identify solutions to solve or solve the problem. For example, continuing with the example above, an initial alarm is generated by a branch blowing onto one phase of the overhead three-phase circuit (e.g., a phase-to-ground fault). Then, an arc is generated due to the fault condition and flashes into a second phase of the overhead three-phase circuit (e.g., phase-to-phase ground fault).

At block 635, one or more actions may be taken or performed to solve a problem associated with the electrical system, e.g., based on the origin, source, cause, transition/evolution, and/or interrelationship of the problem determined at block 630. For example, actions may be taken to increase or improve the operation of the electrical system. More detailed aspects related to analyzing alarms to address electrical system issues are discussed further later in this disclosure. However, it suffices to say here that, in an example, the one or more actions to address the problem associated with the electrical system may include an adjustment to one or more alert parameters or thresholds. Additionally, in embodiments where the problem associated with the electrical system includes a problem associated with an EPMS responsible for monitoring the electrical system, the one or more actions may include adjusting one or more settings associated with the EPMS configuration to address the problem associated with the EPMS.

In one example embodiment, one or more actions to address a problem are automatically performed by a control system associated with an electrical system. The control system may be communicatively coupled to at least one IED responsible for capturing or deriving energy-related signals, and/or to cloud-based systems, field/edge software, gateways, and/or other headend systems associated with electrical systems, for example.

It should be appreciated that in some embodiments, the method 600 may include one or more additional blocks. For example, in some embodiments, the method 600 may further include determining an impact of the identified alarm and/or an alarm period associated with the identified alarm on the electrical system and providing an actionable advice for reducing or eliminating the impact of the identified alarm and/or the alarm period associated with the identified alarm on the electrical system. According to some embodiments of the present disclosure, actionable recommendations may be based on customer or segment types and/or customer configured or determined preferences.

In addition, the method 600 (and other methods disclosed herein) may also include transmitting relevant information related to the identified alert. The relevant information may, for example, provide real-time perception of one or more of the following: alert health, alert configuration(s), alert operation(s), alert source(s), alert impact(s), and recent alert activity. According to some embodiments of the present disclosure, the relevant information may be provided on an alarm data dashboard, report, text, email, and/or audible communication. Referring briefly to fig. 7, an exemplary alarm data dashboard is shown in accordance with some embodiments of the present disclosure. In some example implementations, the alert data dashboard may be customizable and configurable (e.g., based on customer segments and/or in response to user input). Additionally, in some example embodiments, one or more aspects of the alarm data dashboard may be user selectable and capable of providing more detailed insight and analysis in response to one or more user actions on the alarm data dashboard.

It is well known that alerts provide one of the most important values of EPMS to customers. Unfortunately, they can also be one of the greatest complications if not properly configured and/or applied. People with EPMS generally need to manage countless alarms, some are critical, some are trivial, some are frequent, and some are occasional; and customers are always concerned about the distinction between the two. There are many problems associated with alarms faced by customers, including: excessive alarms, extraneous alarms, alarm criticality, and most particularly their implications for the overall system. Unfortunately, the event that generates the alert is probably the most critical impact of the facility on profitability, loss, and overall productivity. Enterprises are limited by their resources and expertise, and it is therefore important to simplify/optimize alert information to help customers simplify, interpret and resolve EPMS alerts (and the events that generate them).

For example, the alarm data dashboard shown in FIG. 7 provides a number of tools to facilitate these needs. For example, the alarm data dashboard provides customers with a clear view/understanding of the alarm superstructure of their EPMS. Each "desktop applet" (e.g., alert health desktop applet, alert configuration desktop applet, etc.) shown in the alert data dashboard is presented at a high level; however, the customer may be allowed to "dive" into the information of any He Xiao component (e.g., based on or responsive to user interaction with the widget). These tools allow facility managers to more easily understand and quickly respond in real-time to electrical alarms and events. They can also be used to "tune" the end user's EPMS according to the needs/requirements of a particular market segment (i.e., what is important and what is not important). Ultimately, this feature increases the value and usefulness of the EPMS, thereby saving facility manager time, money, and resources.

Those of ordinary skill in the art will appreciate that an alarm data dashboard similar to that shown in fig. 7 may provide many benefits in addition to those described above. For example, the alarm data dashboard may: (1) simplifying multiple alert sets on one page/screen, (2) providing both experts and non-experts with an "overview" of alert health, configuration, operation, source, impact, and recent activity real-time perception, (3) enabling standard configuration of widgets based on customer segment context, providing continuous assessment of alert information and questions, (4) highlighting key alert priorities, (5) providing important alert health metrics via partitioning based on their impact (or potential impact), (6) partitioning configuration questions according to projected impact on EPMS, (7) normalizing and partitioning operational impact according to historical problems related to the end user's electrical system, and (8) providing the ability to "deep submerge" alert information from comprehensive to detailed.

It should be appreciated that the alarm data dashboard shown in fig. 7 is one of many example dashboards contemplated herein.

Referring to fig. 8, a flow chart illustrates another example method 800 for analyzing an alarm to characterize an electrical system problem. In accordance with some embodiments of the present disclosure, method 800 illustrates example steps that may be performed in conjunction with one or more of the methods discussed above (e.g., method 600). Similar to the methods discussed above, the method 800 may be implemented on a processor of at least one IED (e.g., 121 shown in fig. 1A) in an electrical/power system, a processor of a diagnostic computing system (e.g., 125 shown in fig. 1) in an electrical/power system, and/or remote from at least one IED and the diagnostic computing system.

As shown in fig. 8, method 800 begins at block 805, where an energy-related signal (or waveform) is captured or derived by at least one IED in an electrical/power system, similar to block 205 of method 200 discussed above. At block 810, electrical measurement data from or derived from the energy-related signal is processed to identify overwhelming periods (as distinguished from normal operating levels). More specifically, the electrical measurement data is processed to identify overwhelming periods of events and/or alarms in the electrical system. For example, overwhelming periods of events and/or alarms may be identified based on analysis of aggregated information associated with the events and/or alarms identified in the electrical system. As noted in the previous figures, in some cases, an alarm may be triggered in response to an identified event.

According to some embodiments of the present disclosure, the goal at block 810 is to identify and flag all periods of overwhelming events and/or alarms. These may be equivalent to, for example, abnormally high event and/or alarm rates occurring over a particular time period (or over one or more particular time periods). It should be appreciated that different time periods may be analyzed, for example, the time periods may be selected/analyzed based on best fit each analysis and/or presentation (e.g., graphics in a report or graphics in the UX of software), and several time periods may be combined to extract different information from each time period analysis. Fig. 16 provides an illustration of two types of overwhelming periods: spike (1620) and peak period (1630). As can be seen on this figure, a threshold is inferred from statistical analysis of the number of alarms per interval in 1635 (e.g., based on the normal outliers of the median +1.5×iqr) and in 1625 (e.g., based on the extreme outliers of the median +3×iqr). These longer durations may be defined by a fixed period of time (duration), for example, spanning 3 different 10 minute periods or having a duration of more than 20 minutes. Alternatively, they may be dynamically derived from the normal duration period. For example, the system may determine a "normal duration" using the third quantile multiplied by a factor of 3 and then classify the event as a peak period when the duration is longer than the "normal duration".

Fig. 9 and 10 illustrate various concepts related to identifying overwhelming periods. For example, in fig. 9, a fixed 10 minute interval period is used, which may be typical for an electrical utility (depending on geographic location, since some countries use 15 minute interval periods, but both may be considered similar). This 10 minute interval period is also used as a reference within the ISA18.2 standard. It is easy to understand and very intuitive; however, a disadvantage is that an alarm may occur at any time within any given 10 minute interval. Thus, a series of alarms may occur at the last minute of a given 10 minute interval, for example, lasting for 12 minutes. In this case, it starts at the last minute of interval 1, continues for the entire interval 2, and ends at the end of minute 1 of interval 3. For example, these series of alarms may be reported by 3 different 10 minute intervals. The non-professional can view the series of alarms as 30 minutes in duration, which is obviously incorrect.

It should be appreciated that there are several other fixed time periods that may be used. For example, a period of 1 minute may be used. An example advantage of this time period is a higher resolution of the start and end of the event. An example drawback of this period is less aggregation, which may create more complexity for the user. In addition, it is not used in ISA18.2 and may be considered to be too short in duration to measure any response capability. The one minute time interval period also typically does not match any team or process reactivity measurements (10 minutes is typically used as the minimum time required for a team to be alerted and may have a rapid first-level response to new events and/or alarms).

According to embodiments of the present disclosure, a period of 1 hour may also be used. The main advantage of this period is that the data is aggregated over a longer period of time (relative to a 1 minute or 10 minute period). In addition, for example, the maintenance manager easily treats eight 1 hour periods as representative of a work shift. The main disadvantage is that 1 hour is very long compared to the duration of certain types of events, such as voltage dips or voltage surges or transients. In addition, several occurrences or occurrences may occur during the long time interval. It should be appreciated that in some cases, this period of time may not provide sufficient granularity for certain types of analysis to be performed later in the step.

A 2 hour period may also be used in accordance with embodiments of the present disclosure. It should be appreciated that, for example, the 2 hour period has similar benefits and disadvantages as the 1 hour time interval period. In some cases, a 2 hour period may be used to trigger certain steady state alarms (e.g., an "average THD over a 2 hour period" alarm). Thus, the aggregate alarm will match the interval used to trigger the alarm (e.g., 2 hours for calculating the average) over a 2 hour interval duration. An example benefit may be that the analysis period matches the alarm trigger period for these types of alarms. An example disadvantage is a reduction in granularity. Likewise, if events with a duration of less than 1 second are compared to a 2 hour interval, the accuracy of the time analysis is reduced to 1:7200 (2 hours x 60 minutes x 60 seconds).

It should be appreciated that other fixed time periods may be used, such as 8 hours (i.e., corresponding to a typical work shift), daily, weekly, monthly, quarterly, every school, yearly. These time periods are useful for reporting aggregate results, such as highlighting an increasing trend of the average rate of alarms or the number of overwhelming periods when comparing different seasons over a 1 year analysis period.

It should be appreciated that there are also event/alert driven periods (i.e., event/alert inference periods). These periods are not based on any fixed reference, such as the duration of the interval, the pick-up timestamp, or the missing timestamp. By definition, events and/or alarms are triggered only when they are detected, which may sometimes make the fixed time period less relevant. In some cases, only a few time periods may have events and/or alarms. In addition, in some cases, there may be very short bursts of alarms (e.g., alarms within 2 seconds). There may also be several alarm bursts within 10 minutes (e.g., four bursts of 70 alarms picked up by 35 different IEDs) or another time interval, e.g., where each burst is short (e.g., a few seconds) and more than one minute from the next alarm burst.

Fig. 10 shows a cycle using event and/or alarm actuation, e.g. "detection of overlapping event sequences", which typically have different durations. For example, some may last only 2 seconds. As described in co-pending U.S. patent application No. 17/044,934, for example, entitled "Systems and Methods for Intelligent Alarm Grouping" and assigned to the same assignee as the present disclosure, the system may add some duration to extend the missing timestamps of these sequences with the goal of extending the sequences and grabbing any relevant but delayed events and/or alarms (or compensating for clock drift). As a result, any sequence will be considered to have ended if no new event/alarm has occurred during a given duration. This may be a fixed duration (e.g., a minimum of 60 seconds where no events and/or alarms occur) or may be inferred from the first few months (e.g., based on a typical duration to the next overlapping sequence of events when no time extension calculations are applied). In addition, this may even be tuned to the type of power quality or the type of protection of the event and/or alarm.

Fig. 10 has a group similar to block 930 in block 1030. They are the groups calculated by the system based on the alarm co-occurrence in all sequences (number 1015 shows the number of sequences on the X-axis of the graph). The lines in numeral 1010 are also similar to numeral 910. The numeral 1020 is also similar to 920. This is a graphical representation of a single sequence (similar to a 10 minute interval). Numeral 1040 shows the same event as in 940. This provides more detail for the user and for the automated analysis. At 940, three consecutive 10 minute intervals show voltage drops from all of these IEDs. In 1040, the system detects that 9 sequences become visible. The internal details of these sequences can be further visualized in fig. 15B, where numeral 1510 shows that the same IED first detects the event in eight of these sequences, always indicating a downward direction into the electrical system. Numeral 1050 shows a single event similar to 920, so the amplified sequence does not provide additional distinguishing information from analyzing the 10 minute interval data.

Different implementations of how to detect overwhelming periods are possible and are covered by the present disclosure. In one example implementation, the median and quartile ratios (i.e., the distance between the IQR or 25 th percentile and the 75 th percentile) may be calculated using statistical methods, such as calculation over an analysis period (e.g., 1 month or 1 quarter as an example). For example, two different thresholds may be determined based on "median+1.5 iqr" (i.e., the "outlier" threshold) and "median+3 iqr" (i.e., the extreme outlier threshold).

FIG. 11 illustrates the utilization of a machine learning change point identification algorithm (e.g., based on median or mean changes or variance changes). For example, using these algorithms, the system may calculate the locations of all the change points (one of which is shown at numeral 1120). From each new change point forward until the next change point is detected, the algorithm will be able to define the median value for the segment (one of these is shown at numeral 1130). Each section consists of all time intervals comprised between two consecutive change points. Once these segments are identified, each segment may be weighted by the number of intervals contained in the segment, and then methods defining normal, abnormal, and extreme may be applied. It may rely on statistics (e.g., median and IQR described above, "mean+2 x standard deviation" of outliers, mean+4 x standard deviation "of extreme outlier thresholds) or some other machine learning method (e.g., clustering).

In another example embodiment, a machine learning or artificial intelligence algorithm or tool may be used for the same purpose. For example, using the example of alarms represented by fig. 11 and using clusters, we can find 4 clusters (e.g., cluster 1 covers a range from 0 to 2 values, cluster 2 covers a range between 3 and 10 alarms, cluster 3 covers a range from 15 to 45, and cluster 4 covers a range from 55 to 210). With the upper limit value for each cluster we can derive the thresholds at 2, 10 and 45 (alarms every 10 minute intervals). By examining this against the distribution we see that there are only very few values in cluster 4, few values in cluster 3, and most values (> 50% of the total amount of values) in clusters 1 and 2. Keeping two higher clusters we can consider the value 45 (and thus all points above) as an extremely high value as a threshold, and we can consider the threshold of abnormally high values (also called outliers) as values between 15 and 44.

It should be appreciated that there are many other algorithms and tools and methods that can be considered and implemented or utilized by any person skilled in the AI, machine learning arts, particularly in the field of outlier identification or outlier detection.

At block 815, the overwhelming period identified at block 810 may be characterized. For example, by utilizing the outliers and extreme outlier thresholds identified above, each interval and/or sequence may be marked as a potential "overwhelming period/interval" (i.e., the number of alarms is above the outlier threshold) or "extreme overwhelming period/interval" (i.e., the number of alarms is above the extreme outlier threshold).

After this statistical and/or machine learning labeling, some expertise or common sense rules should be applied to filter "paradoxical" classifications (e.g., from a pure statistical approach, when most values are 0 alarms per interval, 2 alarms per interval may have been considered outliers and 4 alarms are considered extreme outliers). These rules may be very simple, e.g. "if less than 15 alarms are every 10 minutes interval, the threshold is not used", or "if more than 50 alarms are every 10 minutes interval, the threshold is created". Or they may be specifically set by using expertise and knowledge in the field (e.g., if the number of operators is known). Comprehensive alarm knowledge and knowledge of maintenance alarm handling capabilities help to formulate these rules. In addition, expert rules, statistical or machine learning algorithms may be used to derive typical thresholds for particular customer segments or driving processes or load types.

After marking each interval as "normal", "overwhelming period/interval" or "extremely overwhelming period/interval", the system may append relevant characteristics to each interval (e.g., number of alarms present, number of different IEDs where alarms are present, different types of alarms present, etc.), and may enrich these characteristics progressively as analysis proceeds (e.g., adding the number of clusters present during an interval, e.g., as seen in block 820).

It should be appreciated that the identification period is an important step in elucidating the potential impact of mitigating and remedial actions, and more particularly on alert health. To determine the actions to prioritize, it may be useful to know which part and how many of the "overwhelming periods/intervals" may be reduced or resolved.

At block 820, a set of co-occurring events may be identified. As is apparent from the previous steps, it is unclear how events and/or alarms may relate to each other. Without looking for co-occurrence, it would produce a very blurred alarm picture and would not see a clear pattern even to the expert's eyes, which makes any analysis very difficult. Today, the expert uses the location of the IEDs to select a subset of IEDs or to attempt to identify the relevant IEDs, and may typically select a time window of events and/or alarms to concentrate analysis. Once the subset is analyzed, the analysis is tested to see if it is generalizable (e.g., if it solves the alarm problem that occurred during this time period). This may be iterated several times in an attempt to reduce the number of events/alarms, looking at other IEDs or time periods. By not analyzing all available data (i.e., focusing on a subset of meters and/or time intervals/periods), the necessary components may be lost and there is no distinction between alarms that are common to anomalies and alarms that are always or generally common to anomalies.

In one example embodiment, the co-occurrence alarm groups may be based on pairwise correlation calculations to provide distance measurements between each IED pair. It may then be transformed into a matrix, which is an input to a hierarchical clustering algorithm (e.g., using K-means clustering). The cluster tree may be cut at a level defined as optimal using any method to determine the optimal number of clusters (e.g., a single method or a combination of methods such as described in the "nbculst" R package). In another example embodiment, the system may use any relevant distance measurement computation (e.g., euclidean, correlation, z-score, DTW, shape-based distance, etc.) or any machine-learned time-series clustering algorithm or suite (e.g., dynamic time warping, shape-based clustering, permutation-distribution clustering, tadpole clustering, k-shaped clustering, etc.). Not or only rarely simultaneously during the analyzed time period).

There are several novel steps. For example, the system may look for co-occurrence of alarms. To perform this, the system utilizes only one step of the analysis (i.e., a value of 1 for the alarm present in the time interval, or 0 if not present during the same interval (active alarm). In a later step, the number of alarms (e.g., impact of possible impact of mitigation actions on mitigation prioritization in the assessment, mitigation performance measurement) is utilized.

The system may iterate through the sequence of overlapping events, recalculating the subsequence of each cluster. Initially, as a first step, the sequence of overlapping events may consider all alarms and events that occur together. This may confuse the true boundaries of the sequence (e.g., this may link all alarms that occur during a cluster).

According to some embodiments of the present disclosure, the system may use different time periods to calculate clusters, analyze, and reconcile any differences. At least, for example, the system can run clustering based on the presence (or absence) of alarms in a fixed "10 minute interval" and a dynamic (event inferred) "sequence of overlapping events". For each of these, the system may identify the best number of clusters and identify clusters of co-occurrences of the alert (e.g., and the alert is contained in each cluster).

The system may then identify any discrepancies, for example, by comparing the cluster identified by the "overlapping event sequence" to the cluster of the "10 minute interval". The system may address the discrepancy based on several principles. For example, the differences may be resolved using the finest granularity of information, which is typically an "overlapping event sequence" cluster. Since these sequences may be much shorter (sometimes less than 1 second) and since there is detail of all sequences that occur during the 10 minute interval, more information will be available. Iterations may be triggered, for example, to refine the clusters in a later step, possibly each time more information is attached to the clusters. An example of additional data for each sequence may be whether an event is determined to originate upstream or downstream of the IED. Additionally, the highest confidence level of the sources from the IEDs may be determined sequentially. In some cases, load impact information may also be determined. For example, it may be determined whether any load loss is detected due to a voltage dip. In addition, the greatest effect can be determined in each sequence.

According to some embodiments of the present disclosure, the system may apply business logic to these statistics and machine learning tools. In one example implementation of the business logic, all clusters containing only one (e.g., or 2, 3) alarms may be clustered into a "unique set of single alarms". Each of these alarms may have a very unique presence signature (i.e., it is clustered by itself and does not overlap with other alarms, each alarm being a separate group) so that each cluster can be correctly identified. Thus, it can be determined that machine learning does the intended thing. However, a single alarm cluster does not represent anything useful for alarm management. The system may then apply business logic to group all of these single cluster alarms into a new set of "unique single alarms". The system may apply a similar process to clusters of 2 or 3 alarms depending on the number of unique alarms that occur during the analysis period. The main advantage is to understand that a pattern that repeatedly appears and has a set of all alarms that do not display any pattern, except that there is no common pattern that can also be considered a pattern. These groupings may be useful in further analysis to filter alarms from further analysis, display/graphics, or for example, to mitigate action surveys.

According to some embodiments of the present disclosure, the system may infer hierarchical relationships from clustering and co-occurrence analysis and add these to refine the groupings. In fig. 9A, for example, we can visually show links such as (1) cluster 6 (block 961) being included in cluster 5 (block 962) and (2) cluster 5 (block 962) being included in cluster 4 (block 963). Block 965 shows one example occurrence of cluster 7 being different from cluster 4. In this illustration, the system uses the term "cluster" rather than "group" as a synonym. For example, in cluster 1, alarms A, B, C always co-occur. Alarm D also often co-occurs with ABC, but sometimes does not exist. Expert rules may utilize event and/or alert information (e.g., size, duration, location within the electrical installation, etc.) to verify relationships. In some example implementations, the system may recalculate the clusters when significant changes in the input data are detected. For example, when a new sub-sequence of overlapping events is detected, the system may use the new sub-sequence to recalculate a group (also referred to as a cluster).

At block 825, a determination may be made as to whether the set of co-occurring events reoccurs, e.g., the frequency of pattern repetition. In addition, it may be determined whether the pattern reappears in at least one group. The system may then evaluate the usefulness of the clusters. To perform this evaluation, the system may first identify how many events re-occur in each packet. This is one criterion for evaluating the usefulness of a created cluster (i.e., a group of co-occurring events and/or alarms).

The previous steps use co-occurrence as a key input to define similar and dissimilar groupings. Meaning that it identifies a discriminant pattern based on the time stamp and duration. However, at this stage, the system has not yet determined that the impact of the mitigation action on the system is defined. By evaluating each cluster and determining the number of reoccurring sequences, the system will be able to predict the likely decrease in future alarms for each cluster, as well as whether a given mitigation action is achieved and the expected outcome is achieved.

For example, cluster 1 may have 30 different alarms. On average, each sequence may include 45 alarms within the sequence, some of which repeat. In one example embodiment, cluster 1 may have 20 sequences in which similar patterns occur. By focusing on solving the problem associated with cluster 1, the number of alarms should be reduced by 900 alarms in the next month (20 sequences with an average number of alarms per sequence of 45). If all other alarms are only rarely repeated (e.g., 5 times or less), the system may determine that more repeated alarms are of interest as most useful based on the count of alarms and the recurrence of the pattern. For example, other usefulness criteria may be derived from alert data (e.g., impact) or from context data (e.g., type of segment, load type, etc.).

At block 825, if it is determined that at least one co-occurring event group re-occurs, the method may proceed to block 830. Alternatively, if it is determined that no co-occurring event has re-occurred, the method may end or return to block 805 (e.g., capture and analyze additional energy-related signals).

At block 830, a group signature for each repeatedly occurring co-occurrence group of events is determined. For example, each of these groups (i.e., clusters) can be characterized by its content and pattern. For example:

the number and typical pattern of the different alarms occurring in each group,

the number of different IEDs in each group and the source of the alarm,

the number of reappearance in the analysis period of each group,

a list of typical alarm types for each group,

a list of alarm types in each group,

a list of infrequent event types co-occurring in each group,

identifying groups to be further separated based on expertise-based rules (e.g., identifying "no possible links" between event types occurring in the same group), and

determine typical event related measurements or derived values for each group (e.g., typical duration of events and/or alarms, typical number of phases of influence, typical amplitude, etc.).

These characteristics (e.g., adding root cause identification, impact assessment, location analysis, direction detection, possible mitigation actions, impact assessment of mitigation and remediation solutions, etc.) may be accomplished iteratively as the system moves through the workflow.

At block 835, the cause analysis enabler or simper of the group/event is identified. For example, the group characteristics of each recurring set of co-occurrence events identified at block 830 may be used to determine a problem associated with the electrical system, such as the origin, source, cause, transition/evolution, and/or interrelationship of the problem.

It should be understood that all of the following steps may be combined and any of these steps may be run sequentially or in parallel with any of the other steps. For the purposes of clarity of the application, each step will be described as a separate step. But the application will be derived from cross-correlation and cross-checking to determine any combination of analysis enablers. When one or more of these steps are combined and considered to apply to only one of the event and/or alert groups, the analysis may become more relevant. Ideally, if each group has an associated set of different correlation characteristics, the cause analysis of each group should trigger specific and different relief and/or remedial actions. In parallel, the system can always check for loss of discrimination by evaluating whether other groups start correlation by each combining step.

A high-level principle is that anything (or any particular combination) specific to a group of events and/or alarms, a particular list of IEDs of the group, or any particular type of event and/or alarm occurring only on these IEDs in the group can be considered as possible unique analysis enablers. Anything that creates an overlap of groups will be re-evaluated and possibly re-combined with other measurements and/or enablers (e.g., IED lists may appear in groups 1 and 5). In group 1, the event type is all voltage dips with a very short duration. In group 5, all events are related to the voltage THD as steady state events. In this case, the combination of IED list+pq event type will be a distinguishing characteristic and may become important. Thus, with the location of the associated IED, the associated load, the affected circuit branches and any other enablers, it is possible to link to a specific combined key of events of ied+pq type. For example, the load impact may be determined (e.g., 50% loss of load) and related to the operation of the load (e.g., the protection relay of the motor has tripped), and the location inside the electrical system may be utilized in connection with a particular process (e.g., capacitor bank energized) and related to the PQ type (e.g., voltage dip). By looking at all of this information and the associated time series, the system can infer that the energized capacitor bank has a voltage dip that triggers the motor protection relay, thereby affecting 50% of the motor drive load in a particular production site location. This may be limited to only two branches of the electrical system (i.e. the other branches are not affected by the event, since no alarm is detected to co-occur on the other IEDs).

At block 840, one or more actions are taken or performed in response to the identified cause analysis, enabler, or facilitator. For example, these actions may be taken to alleviate or remedy problems associated with the electrical system based in part on the identified cause analysis, enabler, or simplifier. By addressing the problems associated with electrical systems, operation of the electrical systems may be improved in some cases.

It should be appreciated that there are many types of signals, data, and/or information that may be used as inputs to select (e.g., best match) and/or trigger a mitigation and/or remedial action. For example, in one example embodiment, the system may utilize as input an ordered list of each group (e.g., as described in connection with fig. 12), several groups, and/or all groups. Additionally, in another example embodiment, the system may use any or all of the results of the steps described in connection with fig. 12 as input, for example. In another example embodiment, any direct measurement, any information about subdivision type, field size, load type, any other field, field group, customer group, and/or user group used to define benchmarks, etc., may be used as input. In another example embodiment, any previous actions and associated triggers, measurements, information, events, alarms, and/or any other relevant data may be used as input. In another example embodiment, any learned trigger (e.g., trigger, measurement, information, event, alarm, and/or any other relevant data) may be used as an input. It should be appreciated that the actions that trigger and select/best match actions may be predefined or learned (e.g., user input from expert rules, based on example thresholds, selecting a best solution using some mobile application, defining, describing, and/or triggering a best action). It should be appreciated that each of these embodiments may be combined or arranged in any manner as desired.

For example, various embodiments of remedial and/or mitigation actions that may be taken at block 840 will be discussed later in this disclosure.

After block 840, the method may end, return to block 805, or may take one or more actions. For example, in one embodiment, the method may continue to method 1200 for further analysis. Other example aspects, features and/or variations of the disclosed invention will be apparent from the following discussion.

Referring to fig. 12, a flow chart illustrates another example method 1200 for analyzing an alarm to characterize an electrical system problem. In accordance with some embodiments of the present disclosure, method 1200 illustrates example steps that may be performed in conjunction with one or more of the methods discussed above (e.g., method 800). Similar to the methods discussed above, the method 1200 may be implemented on a processor of at least one IED (e.g., 121 shown in fig. 1A) in an electrical/power system, a processor of a diagnostic computing system (e.g., 125 shown in fig. 1) in an electrical/power system, an EPMS, and/or remote from at least one IED and the diagnostic computing system (e.g., in another portion/location of the EPMS).

As shown in fig. 12, method 1200 begins at block 1205, similar to block 820 of method 800 discussed above, a co-occurring event and/or alarm set may be identified. At block 1210, each event (sequence/event) in each set of events/alarms may be characterized. This block is similar to block 830 of method 800, in that the group characteristics of each repeatedly occurring event and/or alarm group are determined, according to some embodiments of the present disclosure.

At block 1215, it may be determined that the location is the location of the enabler (key discrimination factor). For example, which IED first picks up the event, where the IED is located in the electrical system, etc. The system will search for the event source location (i.e., sequence of overlapping events) for each event. According to some embodiments of the present disclosure, event source locations may be identified by utilizing all IEDs present in a given cluster and in unrelated clusters that may frequently co-occur but occur in at least one of the sequences of the given cluster. For example, the IED list and hierarchical information contained in the electrical single line diagram for each cluster may be utilized to establish any typical specific branch location for each event for each cluster. In addition, this information may be used to infer general impact events (e.g., all branches of the power system detect the event and/or alarm).

According to some embodiments of the present disclosure, it may be determined whether there are any positions overlapping other groups. If so, a discrepancy or relationship may be inferred. For example, the same IED may be present in cluster 1 and cluster 2; however, the event type may be different between the two clusters. The identification of each location may also be performed, for example, with additional relevant characteristics (e.g., number of sequences, number of alarms, IED capabilities and settings for each type of event, etc.). In addition, the identification of each cluster may be performed by utilizing the IED list and more general context information. In some cases, a link may be determined for each cluster to any physical building location (e.g., event zone, distance) or to any typical application derived from location analysis (e.g., HVAC, lighting, motor, etc.), potentially creating a specific graphical representation or graph to aid expert analysis (e.g., extended heatmap, electrical system branch visualization for each cluster affected, etc.).

Analyzing nuisance source location information itself may already provide some useful information, according to some embodiments of the present disclosure. For example, if all nuisance source location measurements indicate a source within the power system, analysis can clearly infer that the cause/source is most likely to be in-site (i.e., not originating from utility) even without an electrical system diagram (e.g., single line diagram or SLD). If the source of disturbance location information is available in addition to the electrical system map, the system can use the location as possible discrimination information for even further analysis. Further visualizations may be generated, for example as shown in fig. 13. There, the nuisance source location information is represented by a grayscale or color scheme (e.g., the downstream source is red, the upstream source is blue) and by grayscale (e.g., high confidence is black, low confidence is light gray) or color intensity (e.g., high confidence is a very intense color, low confidence is a less obvious color). Numeral 1310 shows one of the nuisance source locations in the graph.

At block 1220, it may be determined where the context data is enabled (key discrimination factor). According to some embodiments of the present disclosure, context data may be defined as all data that is not a measurement but describes some aspects of the environment of those measurements. Some examples provided for illustration are loads (e.g., motors or capacitor banks), building and manufacturing processes, applications such as lighting or HVAC, and the like. According to some embodiments of the present disclosure, available and relevant context data may be determined for each incident.

Examples of different contexts are provided below.

Building related loads (e.g., HVAC rooftop units, water pumps, etc.), building related applications (e.g., lighting, elevators, etc.), building related processes and controls (e.g., BMS, etc.).

Manufacturing-related loads (e.g., motors in conveyor belts, etc.), manufacturing-related applications (e.g., automated paint booth applications, etc.), manufacturing-related processes and controls (e.g., manufacturing SCADA systems, etc.).

Loads associated with the power system (e.g., transformers, capacitor banks, etc.), applications associated with the power system (e.g., power monitoring systems), processes and controls associated with the power system (e.g., power system SCADA systems, etc.).

Each of these contexts may provide useful data such as settings, time stamped settings changes, time stamped status changes of I/O, control or process pick-up or loss time stamps, load description with nameplate information, just to provide examples of data. This is very extensive and is typically related to customer segments, building type, application type, site size, and other variables used to categorize activities of sites, buildings, and customers, which may be standard practices for customer segments or customer applications.

According to some embodiments of the present disclosure, the system may link contextual data to event and/or alert groups and time of occurrence. In one example embodiment, the time-stamped context data is combined with the alert group and each event occurrence period (e.g., sequence and/or 10 minute interval). Additionally, in one example embodiment, global settings (e.g., configuration of a BMS or a power SCADA system, etc.) related to the events, alarms, and/or IEDs of the set of events and/or alarms may be appended to the set as metadata. In one example embodiment, the identified loads monitored by the IEDs present in the set of events and/or alarms may be appended as metadata to each event and/or alarm set. As is apparent from the above examples, different attachment layers are possible, e.g. from each event and/or alarm to the IED, and up to any one of the whole system or application. The system may use this data to identify potential enablers for discriminant analysis.

With this particular type of data, the system may identify a particular link between the data of the event and/or alarm group and the particular data. To determine whether the link is specific, the groups may be compared to each other. If any of the data is specific to a given group and does not appear or cannot be linked to any other group by the system (e.g., BMS process changes always occur with certain alarms), the system may consider the data to be related to and different from a particular group. The system or user input may then apply expert rules to teach the system how to determine what is the discriminant enabler. To move the "potential enabler" to the verified "enabler" state, the system may utilize rules based on expertise (e.g., normal measurements of a power system for a given event (such as a transformer or capacitor bank being energized) or knowledge (e.g., field type, customer segment type, installation size, etc.). The system may also learn and derive enablers from user inputs (e.g., maintenance team, etc.) over time (e.g., a 6 month learning period).

At block 1225, it may be determined where the impact is an enabling factor (i.e., a key discrimination factor). For example, the possible and measured impact within each event of each set of alarms may be identified. It should be appreciated that different impact measurements or possibly impact evaluations are the core area of research. One example of such impact analysis and measurement may include impact analysis and measurement of load loss (i.e., generally due to events). Load loss describes the percentage of load loss between pre-event and post-event time periods. For example, the current and/or power level is normalized to 100% before the event is triggered, and the loss load indicates a reduction/loss after the event. For example, only 30% of the pre-event current or power is retained after the event ends.

According to some embodiments of the present disclosure, the impact of all measurements within each event of each set of alarms may be identified. Each incident may include several occurrences of the same type of event and/or alarm from the same IED. Additionally, each of the events and/or alarms may have an impact measurement associated therewith. If no measurements are available, then possible effects can be identified. Additionally, a confidence level may be associated with the estimate. With the sections and building types, a list of possible loads can be inferred. In addition, the system may utilize expertise-based rules to determine possible effects. For example, it should be appreciated that the contactor will not have enough energy to remain closed at a certain amplitude and/or duration of the slump event. If this is a "normally open" contactor, the contactor will open and all loads driven by the contactor will be de-energized. This type of analysis will achieve a higher confidence in combination with location, application, load, or electrical system drawing information. The system may be able to estimate the impact with an associated confidence level.

According to some embodiments of the present disclosure, an alert group may be characterized by measuring or estimating the impact and determining the impact level (real or likely = risk). For example, the information may be aggregated at the incident level and if the system recognizes that it looks like a stepwise incremental impact, the system may select the highest impact or cumulative effect to characterize the alarm set by the measured impact.

An example situation is now described in which a series of consecutive losses or loads are observed. It has been shown that fifteen different slump sequences occur within a month in a cluster (i.e., a co-occurring alarm set). But eight of these occur in less than an hour (i.e., each separated from the next occurrence by at least a minute, typically less than a few seconds in duration). By comparing the load levels of all these slumps occurring within one sequence of overlapping events (i.e., incidents) or between some very close sequences (e.g., three slump sequences occurring within a 20 minute interval), the system may infer that each load loss is different, or the system may infer that the load losses are additive (i.e., the effects are cumulative).

The system may infer that each load loss is different. In this case, the system may show a very flexible power system and driving load if each pre-event returns to a similar level to the first initial pre-event level. For example, the power before the first dip event is normalized to 100% and the load loss after the first event is 72%. The load is then restored to 99% before the second dip event occurs, e.g., the load loss is reduced to 75% after the second event. In this case it indicates that any load loss is recovered before the next voltage dip occurs. This is possible if the process is automatically restarted by a BMS or some control system (e.g. roof unit control, etc.) within the load itself and will give an indication of maximum recovery time (described in the previous patent application). The system may also detect an initial impact and then stabilize, for example, if only the first voltage dip occurs with a load loss and all consecutive occurrences of voltage dips do not generate any load loss.

The system may also detect the progressive effect of voltage dips (i.e., cumulative loss of load). For example, the first voltage dip occurrence may detect that 30% of the load is removed from the system, e.g., at 60% of the nominal voltage (i.e., during the voltage dip). Subsequently, a more severe voltage dip may occur shortly after the first occurrence (e.g., 30 seconds after the initial voltage dip). An additional load loss can be detected, again 50% drop. The system can infer 65% of the total load loss (initial 30++ (50% of 70% on the left) from the initial level before the first voltage dip occurs).

To characterize the alarm set by the estimated impact, the estimated impact may be aggregated at the incident level. Described now are examples of the estimation of the impact that may be used. For example, in a wastewater treatment plant, a number of large motors critical to the process may be used. If a voltage dip occurs and an alarm is generated that does not contain any loss of load measurement for a relatively long duration (e.g., the voltage drops to 30% of nominal voltage in less than one second), expert rules may dictate that if no ride-through capability is installed in the field (e.g., no uninterruptible power supply) then all contactors are open. This would mean that the system could infer the impact estimate to be greater than 90% of the load loss of the water treatment plant.

At block 1230, it may be determined that the sequence analysis (i.e., the minimal identification of the first event and/or alarm in the sequence) is the location of the enabling factor (i.e., the key discrimination factor). This type of analysis for a particular event is extensive in its use. Thus, this will not be developed herein, but will be simply described and illustrated at a high level. The core assumption underlying this type of analysis is that the IED first detects the event and potentially triggers an alarm closest to the problem source. An implicit condition for making it valid is that the clocks of the IEDs should be synchronized (i.e. the pick-up time stamps all occur within a fraction of a second).

The application will focus on the specific application of the first event and/or alarm in relation to the analysis of the group, i.e. in the claims. An example novel aspect of the present application is to utilize identification of a first event and/or an alert for a set of co-occurrence events. By first grouping and then applying this analysis only to the IEDs of the group, it enables to distinguish between possible co-occurrence events at one specific accident time, but may be completely uncorrelated. The main benefit is to reduce the probability of erroneously identifying the first IED to pick up an event and/or alarm. Thus, such grouping enables viewing of the actual first location associated with each set of events and/or alarms in each event. Thus, it determines a localized (i.e., alarm limited to only that group) first event and/or alarm for each group.

After establishing the first location for all events present in each group, the system may look for any pattern indicating incorrect groupings or for any relationship between groups. If an incorrect packet is detected, the system will attempt to divide the group into multiple groups. The system may trigger the reprocessing of step 1215 and infer a new co-occurrence group list. After these steps, a more robust assessment of the alarms of IST events and/or all events associated with each particular group may be provided. The system may identify patterns and infer a typical sequence of events that occur within all events of the group.

Fig. 15A provides an illustration of sequence statistics for fourteen occurrences of an event. In addition, FIG. 15B provides a detailed view of different events. Sequences 106 through 113 show the same repeating pattern, starting with 8045 downstream alarms at a time. These sequences correspond to 940 and 1040 and can be considered as progressive scaling of events and detailed views of the sequences (based on time stamps). Notably, fig. 15B appears to confirm that the time stamps appear to be synchronized because no meters are always lagging or leading with respect to time. The system may perform an automatic check as described previously. Another automatic check performed is to detect any outlier behavior. The sequence 174 stands out and will be re-analyzed when 1590 is considered, and this may re-trigger potential clustering iterations. In one example embodiment, some analysis rules may be utilized. In other cases, the system may request user/expert evaluation, and may then learn from these classifications and suggest them to the user for verification.

The system may identify different patterns for each group. The "most frequently repeated pattern", e.g., the first pattern repeated among 8 adjacent sequences (106-113), represents 57% of the occurrences in the group (i.e., 8 of the 14 sequences in the group). This primary pattern is believed by the system to reoccur in sequence 140 after a few days. The second mode will be distinguished as "partial present" occurring in two adjacent sequences (169 and 170). In one embodiment, the system may decide to aggregate 170 into 169, and may consider 170 as a "copy" of the event of 170.

Three other single occurrences of the alert sequence will be considered distinct and analyzed separately. The system may learn expert analysis to infer additional rules to automate the process. These sequences are 114, 150 and 174. Furthermore, the system may apply different simulation options to check for potential matches. For example, the system may mark 174 as specific because most alarms appear to be closely related to each other, albeit in an abnormal relationship (in time) with the detected first event (i.e., 1590). Then, if the 1590 event is not considered to be part of the sequence, the system may compare at 174 to a similar first alert detected at 114.

With additional data available from the above application, the duration of alarm 1590 is known to last less than 0.05 seconds. Thus, the system will analyze the difference between the durations of the alarms in one application, 1) the fact that only one alarm appears separately from all other alarms, 2) the fact that all other alarms appear to be aligned with each other, and 3) the fact that the distance between the first alarm and all subsequent alarms is 4 seconds, providing a ratio of 80 (i.e., the "next time" of 4 seconds/the "alarm duration" of 0.05 seconds). By using all of these indications, the system can split the particular event into two separate events.

According to some embodiments of the present disclosure, the system may detect a probability that the IED clocks are not synchronized. Additionally, according to some embodiments of the present disclosure, the system may create a confidence index for the correct sequence by utilizing several indicators and comparing the time stamps of the pickup of events in pairs. This is particularly effective if similar lead or lag occurs in different groups for the same paired IED comparison. For example, if two particular IEDs are present in two or more different groups with different alarm types, and there is always a similar lead or lag time, this will indicate that the clocks are not synchronized. Comparing all pairs of lead or lag times, the system can determine whether the clocks of a particular device are not synchronized or whether different devices appear to all have clock synchronization problems. This may be used, for example, to improve EPMS by directing a mitigation action to establish a time synchronization process and possibly a system agent to periodically perform clock synchronization (e.g., once per day at 00h 00). The system may also derive a confidence index from such analysis. In the above example, several devices that appear to have similar leading time stamps can attribute the system to low confidence because possible clock synchronization problems occur. Conversely, if no pattern of leading or lagging regular timestamps occurs, the timestamp order will change and the system will get a high confidence of clock time synchronization.

According to some embodiments of the present disclosure, the system may also look for any recurring patterns in which alarms occur. This may be defined as a sequence of alarm analyses. The system may, for example, evaluate whether any patterns occur. If no pattern represents a certain weight (e.g., 15% of all current alarms in a group of 5 alarms), then a local pattern may be searched to focus on the first 2 or 3 steps. Fig. 14 provides an illustration of an example where some clear patterns appear, and one particular representation illustrates how such patterns are graphically displayed. The input data for the algorithm and the associated graphical output of the analysis is a series of 15 sequences, similar to but different from that described in fig. 15B). Figure 14 presents a graphical output of reading the order of occurrence within these sequences. The co-occurrence alert set analyzed contained twelve alerts and contained 15 different events-1410. For each of these events, the sequence of alarms that occurred in the event is used. In all 15 cases, alarms 3-1420 occur first. In all 15 cases, alarms 1, 5, 6 and 12 occur together just after alarms 3-1430. Subsequently, the pattern starts to diverge. In one case, no other alarms are triggered (e.g., path directly to end) -1440. In addition, in six cases, alarm 2 is triggered. In addition, in eight cases, an alarm 4 is triggered. It should be appreciated that additional analysis may be performed and that more alarms may be observed.

Another analysis of the sequence can be illustrated by fig. 15A. At reference numeral 1505, the measurement used on the x-axis is the duration in seconds from the first occurrence of an alarm. This provides a visual representation that the user can use to understand whether all alarms are very close in time or whether there is a time gap between the occurrence of one alarm and the subsequent alarm (i.e., further providing key information for source and cause and effect analysis). Reference numeral 1510 shows the median duration in sequential order (reference numeral 1540 shows this in the "box plot"). This ordered list of alarms has provided easy-to-read information to any expert, as the alarm that appears in the top row is the first most frequently occurring (reference numeral 1520). The type of statistical map used herein provides further readily readable information to any person skilled in the art of data analysis related to quartile (e.g., reference numeral 1530 is the second quartile and reference numeral 1550 is the third quartile) and outlier (e.g., reference numeral 1560). Then, FIG. 15B adds more detail for a given alarm group. Reference 1580 is the number of each sequence in which any alarm for a given group occurs. Reference numeral 1590 highlights some patterns that are very different from the most frequently displayed pattern (e.g., reference numeral 1510).

At block 1235, it may be determined where the type of event and/or alarm is an enabler. It should be appreciated that this determination may be the most common analysis performed by the alert user, the expert attempting to troubleshoot the alert, or even the It team querying the expert for a list of alert types.

Consider first a single type of event for each set of events and/or alarms. Returning now to fig. 9, as shown by reference numerals 940 and 955, several sets of co-occurring events and/or alarms (i.e., clusters) may have only one type of event and/or alarm. When the type of event and/or alarm is different for each set of events and/or alarms, the system may infer that the type of event and/or alarm is an enabler (i.e., a discrimination between sets). In addition, when a particular type of event and/or alarm is shared by several groups, the system uses this information to compare the groups and perform a link analysis (see 880-determine group relationships). The type of event and/or alarm is already a public key between at least two groups and will accordingly be used to identify possible links. The system also uses this information to distinguish groups that do not share this type of event and/or alarm.

When a single type of event and/or alarm occurs in most arrays, the type of event and/or alarm may be primarily an enabler for link analysis for all groups sharing the same type of event and/or alarm (as described in 880). They may also be more discriminative for one or several alert groups that do not share the same type of event and/or alert. However, in some cases, several types of alarms may co-occur within the same set of events and/or alarms, which may re-trigger the analysis (e.g., loop back to 1205).

According to some embodiments of the invention, groupings may be refined and divided into more coherent subgroups, e.g., based on expertise or rules. Some events may occur together but are of a different type in nature. In addition, there may be many possible reasons for an alarm to occur together, the simplest being a global process, turning on several machines/loads simultaneously. However, these machines/loads may have different problems and may be independently started by other processes. For example, HVAC control actions trigger only a number of actions (e.g., a number of pumps and rooftop units associated with one particular process step of the BMS) under certain conditions. Another example of a global process is the manufacture of complex production process steps in SCADA systems, which can start several motors and welders, while the motors and welders are not involved in other process steps.

Based on expert incompatibility rules, the system may group the components into subgroups with co-occurrence events and/or alarms of single or only considered compatible types. These rules may be predefined or may be learned (e.g., by user input). In one example embodiment, if several groups display the characteristic, the grouping may be refined and divided into more coherent subgroups based on the grouping (i.e., clustering) of events and/or alarms being specifically reapplied to the group or groups. The system may add additional criteria for clustering to extend beyond the temporal co-occurrence measure and move towards multidimensional clustering (e.g., add alarm duration, alarm type, alarm severity score, alarm impact, event source location, etc.).

After evaluation, the system may consider the groups as consistent. Further analysis may be performed to determine whether multiple types of events are related to the same event and/or alarm. If confirmed, this may be a strong indicator (enabler) of expert analysis. This, in combination with other enablers (e.g., first alarm in sequence, loss of load surge, event source location indicating a particular branch and load, etc.), will help to distinguish between a single cause (e.g., one motor start-up producing a voltage dip, etc.) and a global process-related problem.

As indicated by the above description, the type of event and/or alarm may be part of any analysis and will in many or most cases typically be the enabler of discriminant analysis of the event and/or alarm. This may be useful to better understand what is happening, the cause or result of the detected event and/or alarm, and the relationship between different events and/or alarms that may exist between and/or within different groups. It is important to note that due to the definition of typical durations of such events, the definition of power quality events and/or alarms, the pattern of steady-state events (e.g., harmonics, voltage imbalances) and the pattern of non-steady-state events (e.g., voltage drops, swells, transients) may be very different.

Steady state PQ events typically last longer than one or more 10 minute intervals, visually becoming an extended period (e.g., 950 in fig. 9 and 9A) that displays a period that may be referred to as a "half day open time" when an alarm occurs, or when a "several day continuous alarm" mode becomes visible (e.g., 960 in fig. 9 and 9A). Whereas by definition, non-steady-state events typically have a short duration. This means that such events and/or alarms are visible only within a single or very limited continuous 10 minute interval. This is illustrated by 942 in fig. 9 and 9B, where the voltage dip exists in only one single 10 minute interval, or 945 in fig. 9 and 9B, where the voltage dip exists in five consecutive intervals.

If the non-steady state event shows a pattern similar to 950 or worse (e.g., 960), then it may be apparent to any expert or anyone understanding the power quality event that the problem needs to be solved. The alarm may be problematic, for example, when the alarm setting may be sensitive (e.g., voltage dip setting of 5%) or the measurement may be incorrect (e.g., incorrect CT or PT ratio setting in the IED produces measurement errors). There may also be unresolved problems in the field, creating constantly recurring or redundant alarms.

In these cases, impact assessment analysis may be required to understand, with load loss or risk assessment of the affected load (i.e., using segment knowledge and load type sensitivity). If the load impact is not measured and the risk of impact is low, the end user may choose to change the alarm and/or event settings to reduce the associated alarm nuisance behavior. This is because events and/or alarms have no load impact and do not require any end user action, and are now classified as nuisance alarms. If a load impact is measured and/or there may be an impact risk, an alarm and/or a relief or corrective action should be triggered. As in other cases, the innovation is to apply this type of analysis to a set of co-occurring events and/or alarms.

At block 1240, a group relationship may be determined. In this step, the system may unify the different groupings and information from the previously performed analysis. The information may include, for example, different identified enablers (e.g., location, impact, event type, sequence, etc.). Thus, the system can determine the relationship that may exist between groups and the type of relationship that may exist between groups of commonly occurring alarms.

In one example embodiment, the system may infer that logic is included. For example, when group a contains group B, rules may be utilized. Rules may include general assumptions, for example, when a has more events/incidents than B. Absolute inclusion may also be inferred from simple rules, e.g., B is included in a each time a occurs (i.e., a co-occurrence). For "most frequent inclusion," B may be included most of the time it occurs. This "majority of the time" may be predefined (e.g., a 90% percent threshold) or inferred (e.g., from a group "learn" over a one year learning period, identifying a threshold as being within the same cluster a from co-occurrence of the cluster, creating a new cluster B). This is useful when the end user does not understand the system in depth (e.g., specifies a new maintenance manager).

It should be appreciated that in some cases, group a may be independent of group B. For example, there may be minimal overlap of alarms in an event (i.e., "sequence of overlapping events"). Absolute independence can be determined when there is no alarm overlap (i.e., no co-occurrence). For example, when observations indicate (typically) that B is not co-current when a occurs, general independence can be determined. For "most of the time," the above description of the methods defining these should be considered applicable (e.g., predefined, learned).

In another example embodiment, the system may analyze the group logic for "differences or proximity of event types". For example, when the type of event and/or alarm is different for a group of events and/or alarms, the system may confirm the group as independent. Additionally, when a particular type of event and/or alarm is shared by multiple groups, the system may run inclusion logic to check for any type of inclusion of those groups. The system may use this to reduce the subset of groups on which the analysis is performed. The method utilizes event type as a preliminary filter comparing which groups and which groups have been considered independent (i.e., due to the type of event and/or alarm). When a single type of event and/or alarm occurs in a majority of the arrays, the type of event and/or alarm may be primarily an enabler for confirming the independence of several groups (i.e., clusters) of different types of events and/or alarms belonging to the majority of the arrays.

In the event that several types of alarms may co-occur within the same set of events and/or alarms, the system may evaluate the probability that a cluster is an unrelated subgroup. For example, if the system evaluates a subgroup as uncorrelated based on a different type of event, the system will refine the group and divide the group into more coherent subgroups. As another example, the system may consider the group as consistent and utilize the group in further analysis after evaluation (e.g., multiple types of events are considered to be related to the same event and/or alarm).

This step of method 1200 focuses on identifying any type of relationship to verify and, if necessary, to refine the packet, according to some embodiments of the present disclosure. These groupings are key aspects of all analyses. In the above examples, emphasis is placed on validating or splitting groups. In another embodiment, groups may also be connected together to create a more global group. In fig. 9, cluster 7 may be considered to be included in cluster 2. Based on end user input using predefined rules (e.g., merging two groups if an absolute inclusion is identified), the system may merge the groups together.

At block 1245, the groups may be regrouped or further divided into subgroups based on other enablers. For example, the group is separated using nuisance source location information such that all events and/or alarms are directed toward the source (i.e., possible sources upstream), and when nuisance source location is directed downstream or has a mixed direction (i.e., unclear source), all events and/or alarms are separated from events and/or alarms. The system may also divide the groups into more coherent subgroups with different sequence patterns (e.g., one group always has alarm #1 occurring first, while another group may aggregate all alarms, where no clear pattern of the first alarm occurs, and no other repeated sequence patterns may be identified).

At block 1250, an ordered list of discriminating characteristics and enablers may be defined. By this step, the system has iterated through the group and reached the stability of the group. This may be considered to be the best state for segmenting and grouping events and/or alarms. Each dimension of analysis (e.g., location, impact, time origin, load context, layout of electrical system) is now associated with each incident (i.e., "group of co-occurring events and/or alarms", "cluster of alarms").

It is necessary to understand that each or any of these dimensions may help identify the source and cause of the problem, or may be indicators of "where to focus in event analysis" and "which links to identify" for further analysis, according to some embodiments of the present disclosure. In each of these cases, the goal is to use automatic analysis to move toward identifying the cause of the problem (e.g., capacitor bank energized, motor started, etc.) or the source of the problem (e.g., the cause is unknown, but the location of the closest problem/event in the electrical system of the IED is known). In each case, such automatic analysis helps to characterize and understand each problem. For example, it may be determined whether there is a repeating pattern that may aid in prioritization. Additionally, it may be determined whether patterns and links exist that may be missed by a human analyst due to the amount of data or its complexity (e.g., correlation analysis of all events related to a set of events and/or alarms).

At block 1250, the list may be ordered, combined, and/or possibly decremented to maintain the most discriminant, important, and helpful information for future analysis. For example, this information may be used to select, trigger, and/or implement optimal actions for mitigation and remediation (e.g., at block 840 of method 800 and other methods disclosed herein). In some implementations, the system may utilize dimensions that may be considered "constant. For example, in one instance, all alarms in all groups may indicate the same type of event. Thus, a single type of event and/or alarm may be considered "constant. It is important to emphasize that this is very unusual (i.e., in general, many different types of alarms tend to occur over a longer period of time). In some cases, this may be the most relevant information to be utilized. Thus, end users and maintenance teams will only be concerned with one type of problem. Implementing mitigation actions (e.g., ride-through solutions for voltage drops) becomes easier to define or specify.

In another example, many alarms may be related to slump and the nuisance source location may be systematically indicated toward the source in all meters that use this feature. The system also knows from the electrical system layout that several IEDs are utility shadow meters (i.e., installed near utility meters). In this case, the system may report that all voltage drops appear to originate from the utility and that the voltage drops originate from the utility system. Thus, the system may generate a month report that indicates and quantifies process effects and evaluates financial effects based on knowledge of the affected loads.

In some example implementations, the system may establish a hierarchy of all different dimensions for each set of events and/or alarms. For example, the system may utilize measured information (e.g., load loss due to voltage dips), alarm settings (e.g., event severity), and more general site-related information (e.g., geographic location, customer segment, facility size, affected loads) to define a ranking of the most affected groups in the consumer and power system (i.e., alarm management). In some examples, the ranking may be based on measurements (e.g., with an average worst severity score defining the ranking for each group). Additionally, in some cases, the ranking may be based on expert rules. For example, depending on the type of event and/or alarm (e.g., a score of 100 for voltage dip, a score of 90 for voltage imbalance, a score of 80 for voltage THD, etc. when a load loss is detected), a relatively ranked predefined list may be utilized. Further, in some cases, the ranking may be based on learned information, for example, when an end user interface enables a user to assign a ranking score for each individual event and/or alarm or group of events and/or alarms analyzed. The system may use these and other means to establish a ranking of different dimensions.

The system may also filter dimensions that are not considered discriminant (i.e., "do not affect"). For example, after the ranking step described above, the system may apply a filter to remove dimensions that are considered to be irrelevant to the set of events and/or alarms. In some cases, it may be based on simple rules (e.g., a minimum ranking score 40 on a scale of 100) or any other more complex or learned behavior or pattern (e.g., when the user no longer marks an event and/or alarm group with a ranking score).

In some example embodiments, for each group and with an overall ranking score, the system may have a ranked list of possible dimensions at the end of all these possible processing steps. The list may be filtered per group. In general, there may be several dimensions. The system will utilize this combination of unfiltered dimensions to determine actions for possible mitigation and/or remediation. The global ranking score will be utilized to determine the priority between groups. Occasionally, there will be one dimension. In this case, the relative score is based on the single dimension, which is considered to be most important and sufficient for determining the action and the priority of the action. Infrequently, the dimensions will not exist (i.e., all dimensions will be filtered as uncorrelated). In this case, the system will infer that no further analysis of this particular alarm group is requested, and that the priority will be considered below a minimum threshold.

In one example embodiment, for example, the system may assign a higher priority to any group regularly associated with block 810 "identify overwhelming (from normal operation) period" and block 815 "characterize overwhelming period" of method 800. The reason for attributing higher ranking scores to groups that are regularly associated with overwhelming periods (i.e., "flood periods of alarms") is that if the system parses these periods, users of the alarms (e.g., maintenance teams, engineers) may be able to clearly observe that the alarms are overwhelming and/or associated with overwhelming periods.

After block 1250, the method may end, return to block 1205, or may take one or more actions, as will be appreciated by one of ordinary skill in the art.

Alarms are known for a number of purposes including enhancing security, identifying problems, improving quality and reducing risk. For example, EPMS (and related) alarms have historically been used to indicate or draw attention to important conditions or problems. These important conditions may include, for example, an abnormal event, meeting a threshold, exceeding a parameter, powering on or off a load, implementing certain criteria, and indicating that the dispense time has elapsed, to name a few.

An ideally configured EPMS will never alert on significant events and will never alert in the absence of events. Unfortunately, the actual EPMS may not be configured at all, may be incorrectly configured, may not use the appropriate IED (or other device) for the intended application, may not place or install the IED correctly, or some combination of these issues. FIG. 17 illustrates several example conditions that may reduce the benefit provided by an alert.

In order to optimize the value of the EMPS (and associated/related systems), it should be designed to capture only events related to the user; different types of users, end users, and partners (e.g., service teams) may exist. For example, setting the threshold too high would result in potentially losing an important event. In addition, setting the threshold too low may generate too many alarms, resulting in false alarms and alarm fatigue.

While alarms are typically used to indicate (e.g., audibly, visually, physically, etc.) some form of event, they may be used for other purposes as well. Separately and as a system to analyze alarms, also provides clues and information related to alarms:

origin (e.g., specific load type, operating parameters, etc.),

Causes (e.g., motor start-up, failure, variable speed drive operation, etc.),

location/source (e.g., utility, internal, etc.),

severity (e.g., amplitude of event, etc.),

criticality (e.g., the "priority" attached to each alarm in each IED),

system impact (e.g., part of the system experiencing an event, etc.),

an effect (e.g., an effect on load, recovery time, etc.),

occurrence (e.g., whether the event is an arbitrary or chronic problem, co-occurrence and recurrent pattern, etc.), and

importance (e.g., results, etc.).

It should be appreciated that a more comprehensive assessment may provide general and specific information regarding the effectiveness, redundancy, necessity, priority, and/or efficacy of an alarm.

Analyzing alarms provides insight into the events that initiate them; however, solutions to those events may also be inferred in some cases, particularly when viewed through the context (e.g., segment, load, etc.) of its application. Solving the alarm sources (and the events they indicate) by mitigation or remediation would potentially reduce electrical system problems, with a corresponding composite reduction in the number of alarms generated by the EPMS (depending on its number of devices).

The ultimate goal of having an alarm in an EPMS is to alleviate or remedy electrical system problems. EPMS alarms 24/7 (hope) can be used to provide a first indication that a problem exists, or will exist (e.g., when a recurring regularly recurring alarm pattern is detected and will occur again, unless mitigated or remedied in the foreseeable future). Once the problem is recognized and identified, the next step is to make it disappear by mitigation and/or remediation.

Referring now to fig. 18, a flow chart illustrates an example method 1800 for analyzing an alarm to address an electrical system problem, such as by mitigating and/or remediating, in accordance with an aspect of the disclosure. Similar to the previously discussed method, the method 1800 may be implemented on a processor of at least one IED (e.g., 121 shown in fig. 1A) in an electrical/power system, a processor of a diagnostic system (e.g., 125 shown in fig. 1) in an electrical/power system, and/or remote from at least one IED and the diagnostic system.

As shown in fig. 18, the method 1800 begins at block 1805, where an energy-related signal (or waveform) is captured or derived by at least one IED in an electrical/power system, similar to block 205 of the method 200 discussed above. According to an embodiment of the present disclosure, the at least one IED may be part of or associated with an EPMS.

At block 1810, similar to block 210 of method 200, electrical measurement data from or derived from the energy-related signal is processed to identify an event (e.g., a power event) in the electrical/power system. Additionally, at block 1815, similar to block 215 of method 200, a determination is made as to whether any alarms have been, should have been or should have been triggered in response to an identified event (e.g., a power event) in or associated with the electrical system.

At block 1820, a cause and/or origin of the identified event and/or the identified alert is identified. In this case, the reason is what initiated the event. Examples may include motor start-up, capacitor bank energization, lightning strikes, nonlinear load operation, illegal neutral-to-ground coupling, and so forth. In this case, the origin is where the event occurs or the location where the event occurs. Examples may include upstream of a reference point, downstream of a reference point, on a utility/source system, within a facility, etc. The reference points may include, for example, IEDs, capacitor banks, motors, variable speed drives, sockets, motor control centers, circuit breakers or relays, and the like.

At block 1825, the selection information is aggregated. For example, in one example embodiment, information about at least one of the following may be aggregated: identified events, identified alarms, and identified causes and/or origins of the identified events and/or identified alarms. For example, the number of daily events or alarms, or the number of time overlapping event groups, or the impact on downstream loads are just a few of many other examples. It should be appreciated that other example types of information may be aggregated at block 1825, similar to the comparable blocks of the previous method (e.g., block 220 of method 200). For example, according to embodiments of the present disclosure, the aggregated information may also include information from at least one of: EPMS, SCADA systems (e.g., power SCADA, manufacturing SCADA), building Management Systems (BMS), I/O devices and data, PLC data, and system users (e.g., user initiated actions). As previously noted in this disclosure, in some examples, the EPMS may include at least one IED responsible for capturing or deriving the energy-related signal (e.g., at block 205 of method 200).

Similar to block 220 of method 200, according to some embodiments of the invention, the information aggregated at block 1825 may be aggregated based at least in part on the type of division (e.g., retail, office, hotel, hospital, data center, food and beverage, and oil and gas). It is important to note that electrical system problems are typically unique to each field/customer application.

At block 1830, the aggregated information is analyzed to identify addressing opportunities. More specifically, in one example embodiment, the aggregated information may be analyzed to identify and/or determine mitigation/remediation opportunities and techniques/approaches/methods, e.g., to address at least one of: the event symptom(s), the alert source(s), and the cause(s) identified and/or the source(s) of the event(s) identified and/or the alert(s) identified. In this case, event symptoms are general and specific features that are typically associated with an event type. These may depend on the particular segment type, the particular load type, the operation or problem, the particular location within the facility, the particular time of day, etc. Examples may include a circuit breaker opening when a downstream fault occurs, a lamp dimming or flashing when the motor is started, a VSD off line when the capacitor bank is energized, etc. In this case, the alert source is a device, system, and/or other provider that provides an alert to the EPM. Examples may include metering devices, circuit breakers, relays, UPS, PLCs, analog or digital I/O sources, cloud-based storage libraries, edge systems, gateways, and the like. "resolving an alert source" means resolving an event or problem associated with the alert source, e.g., due to a misconfiguration, no data, too much data, not correct data, etc.

At block 1835, at least one action (e.g., at least one mitigation or remediation technique) is taken or performed to improve or address at least one of: the sign of the event, the source of the alarm, and the identified cause and/or the origin of the identified event and/or the identified alarm. At block 1830, at least one action is taken or performed based on an analysis of the aggregated information, according to some embodiments of the disclosure. Additional aspects related to at least one action, including exemplary types of actions and mitigation techniques, are further described below in connection with fig. 19.

After block 1835, the method may end, return to block 1805, or may take one or more actions. For example, in one embodiment, the method may further include evaluating the validity of at least one action taken or performed at block 1835. For example, other example aspects, features, and variations of the disclosed invention, including techniques associated with assessing the effectiveness of at least one action, will be appreciated from the discussion in connection with fig. 19.

Referring now to fig. 19, a flow chart illustrates another example method 1900 for analyzing an alarm to address an electrical system problem, for example, by mitigating and/or remediating, in accordance with an aspect of the disclosure. Method 1900 illustrates example steps that may be performed in conjunction with one or more of the methods discussed above (e.g., method 1800), in accordance with some embodiments of the present disclosure. Similar to the methods discussed above, method 1900 may be implemented on a processor of at least one IED (e.g., 121 shown in fig. 1A) in an electrical/power system, a processor of a diagnostic system (e.g., 125 shown in fig. 1) in an electrical/power system, and/or remote from at least one IED and the diagnostic system.

As shown in fig. 19, method 1900 begins with block 1905 in which a determination is made as to whether the associated alarm is properly configured. More specifically, in an EPMS system (e.g., including at least one IED discussed above in connection with fig. 18), an initial step is to ensure that the relevant alarm is properly configured for use in an alarm management system (i.e., AMS). The AMS may be located within an IED, edge, gateway, cloud-based, or any other internal or external location. The purpose of the AMS is to manage the alarm algorithms described in this document. EPMS generates many types of alarms including voltage dip, voltage swell, high speed transients, harmonic distortion, low power factor, leading power factor, frequency deviation, voltage and current imbalance, and over-current, to name a few. Because each parameter is unique, they will (in most cases) be triggered using a different threshold. They may also incorporate a form of delay (sometimes referred to as alarm hysteresis) prior to triggering to ensure that the threshold has exceeded a sufficient period of time to correlate events.

Because the present invention utilizes alarms, at least one alarm is required to initiate the process (here, at block 1910). The at least one alarm may originate anywhere within the EPMS, the PLC system, digital or analog I/O, and/or any other internal or external source affecting the system managing the alarm. This may include IEDs, other devices connected to the transducer, alarms at edge (field software) or derived from the gateway, cloud-based systems, and/or any other data source that may be alerted.

At block 1915, one or more alarms entering the AMS are analyzed accordingly to determine their relevance to the associated electrical system or EPM thereof. According to some embodiments of the present disclosure, various context databases relating to questions, events, alarm types, alarm sources, alarm characteristics, and segment information may be used in the analysis, e.g., as shown in blocks 1920, 1925, 1930, 1935. In addition, historical data (including past alarm data), historical analysis, and/or historical determinations may also be utilized. Although shown in separate functional blocks, in some cases, mitigation and remediation techniques and recommendations (here, block 1940) may also be included within the library functional blocks.

The AMS (or related components) contains libraries that are related to the application. The associated components may be located in a single repository (e.g., cloud-based memory) or across multiple repositories (e.g., EPMS and cloud-based repositories). One or more libraries may be updated as needed or desired to ensure the accuracy of the libraries and the resulting analysis accordingly.

Four general libraries (as described above) are shown in fig. 19; however, the application may use more or less information than is shown, including supplemental information needed to facilitate useful alert analysis. In addition, the algorithm may request additional information (e.g., metadata, user interactions, etc.) from the end user to provide more direct and useful results. The information included in the library may be prescribed, empirical/empirical, and/or theoretical.

The first example library shown in FIG. 19 is an alarm type and indication library (depicted by block 1925) that may be used to describe information related to alarm parameters, characteristics, types, data, indications, limitations, configurations, and so forth. For example, there are many alarm types including power quality related (e.g., sag, transients, harmonics, etc.), energy related (e.g., peak demand, power factor, consumption, etc.), and the like. Each intended for its own important area, may have unique alarm thresholds and setpoints, priorities, delays, etc. Alarms may be used for steady state problems/conditions and some alarms may be used for unselected events. Alarms may also be used in combination with other alarms (e.g., boolean alarms), while other alarms may act as "stand alone" alarms. Input/output (i.e., I/O) alarms may be used to introduce external information from switches and/or transducers or may be used to trigger output signals to external IEDs and/or other devices. Some IEDs (or other alert sources) may provide only a subset of the alerts, so understanding the constraints of the IEDs (or other alert sources) is important to understand the constraints of the proposed mitigation or remediation solution in turn. The key to the alarm type and incident library is to understand the received alarm data and ensure that the appropriate data is available for analysis and resolution of electrical problems. Fig. 20 provides a simple illustration of how setpoint-driven alarms work with alarm pickup, loss, and delay.

IEDs, edges, gateways, and/or cloud-based applications generate alarms, which in turn may provide and/or generate supplemental information. For example, a slump event may generate a slump alarm in the IED. The slump alarm may then trigger analysis of slump events, analysis of data associated with slump alarms, providing additional information about the impact, duration, type, recovery time, location, etc. of slump.

Because the alert source will have inherent limitations, the alert type and indication library will contain these limitations to the extent possible. For example, a particular metering device may have a limitation on its sampling rate, which may constrain information that is available or that may be derived from events. When analyzing an alarm to determine the best method of mitigation or remediation, it will be important to consider this information.

Configuration information may also be included in the alarm type and indication library, as incorrect configuration may affect the quality/number of alarms generated by the algorithm. Because a portion of the solution involves measuring, verifying, and/or confirming mitigation and/or remedial activities, proper configuration of the alert source is relevant. It should be appreciated that the evaluation may include at least one of: measure, verify, and confirm the mitigation and/or remedial actions. The configuration information may be associated with a single alert source or viewed through the shots of two or more alert sources (i.e., system view). In addition, it may be important to change/adjust the configuration of one or more alert sources to improve the quality/quantity of alert information generated by the EPMS (or other source). Finally, because the configuration of one or more devices can be changed/updated, a record of any changes to one or more alert configurations is maintained to ensure that consistency of analysis is relevant.

The second example library shown in fig. 19 is an event and problem feature library (described by block 1930) that may be used to describe information related to events and problems, including causes, symptoms, effects/branches, typical event waveform features, and the like. For example, alarms generated by EPMS (or other alarm sources) may be evaluated against the contents of an event and problem feature library to determine potential alarm causes, sources, locations, general effects, severity, recovery parameters, system effects, other symptoms, and/or additional conditions. Additionally, event and problem characteristics may be evaluated from discrete alert sources and/or from two or more alert sources as desired. The key to the library of event and problem signatures is to understand the external (i.e., alert source) stimulus that caused (or may have caused) the alert and its impact and/or consequences on the operation, process, system and/or equipment associated with the alert.

It should be appreciated that there are a series of events that lead to an alarm. Some exemplary event causes and associated alarms include, but are not limited to:

fault (voltage dip) capacitive fuse blow (unbalance)

Nonlinear load operation (harmonic) premature failure (overload of the device)

Heavy load power-on (voltage dip) intermittent load operation (voltage fluctuation)

Synchronization problem (frequency deviation) equipment component failure (pulse transient event)

Lamp failure (overvoltage) VSD trip (oscillation transient event)

Although the cause of the event may sometimes be considered a symptom, additional cues may indicate a potential problem. Although not an exhaustive list, some exemplary symptoms are listed here:

overheat/malfunction

Unscheduled shutdown-reduced product quality

Inefficiency/power-off

Life expectancy shortening and instability

2 effects/consequences associated with an event may include a range of adverse effects including (but not limited to):

higher utility cost, product quality degradation

Low productivity, increase in downtime

Higher maintenance cost and poor reliability

Greater capital expenditure and reduced operator-customer satisfaction

Expenditure (expenditure)

The event source location may be determined broadly by examining voltage and current alert waveform data generated from a single device or more precisely (i.e., from a system perspective) by examining voltage and current alert waveform data generated by multiple devices. The hierarchical context of the EPMS or electrical system may be used to provide a discrete relationship between the first alert source and the second alert source. The time interrelationship, the time stamp of the alarm, and the inferred order in the sequence of events may also indicate the source location. Additionally, the source location of an event may be manually entered by an end user and characterized over time to evaluate and determine alarms having similar parameters/characteristics to determine the potential source location of the event. The event source context may be determined from an event and problem characteristics library, derived from event and/or alert data, or retrieved from other sources.

The division between influencing and non-influencing events is important because it can be used to determine prioritization of mitigation and/or remediation solutions. It is important to note here that impact events are often problematic due to their impact on the end user's electrical system and business interests; however, the non-influencing event may simply be an annoyance. Because 1) there are different types of effects, and 2) an event may affect one system differently than another, it is important to consider the context of the application (e.g., market segments, processes, loads, etc.). For examples of different types of impacts, the interruption of the main power supply may be one type of impact, while the excessive harmonics (and their resultant effects on the device) may be another type of impact. The former interrupts production (i.e., production impact); which affects equipment life (and associated costs and production risks). For examples where events affect the impact of the system differently, a voltage dip in an office building will have a different impact on building operation than the same event will have on the operation of the data center. The former can operate with lower reliability requirements than the latter. Furthermore, the costs associated with mitigating or remediating an event will be different (in many cases significant) because an office building may not prove excellent reliability, which is critical to the operation of the data center.

The importance of the severity and breadth of the event is again determined (to some extent) by the application of the system and is basically a "subset" of the impact topics. The severity of the event impact may be determined based on the extent to which the load, process, system, and/or facility is affected, the time, place, and extent. Also, when key elements of a customer operation are affected, the breadth of the impact is more relevant. Also, the impact of an event on a system may be determined (to a greater extent) by the function or purpose of the associated system.

Another important parameter related to an event is the ability of an application/load/system/process/facility to recover from the event. Thus, the recovery period indicates the duration required to bring the electrical system back (to some extent) to its pre-event condition (e.g., load, operating characteristics, etc.). The recovery period may be different for different facilities or event types; however, the recovery periods may be (statistically) aligned within similar event types, especially if the source locations are similar. In some cases (and within some customer segments), this may not be the case, and so exceptions should be considered. Typical recovery periods over time can be learned by analyzing the continuous event characteristics accordingly. One or more EPMS components (or other sources) may be used to measure/determine the recovery period.

Additional system effects regarding the cause and effect of an event may be considered, including (but not limited to): energy reliability, system design (e.g., data centers 1, 2, 3, 4, 5 levels, equipment used, etc.), geographic location and local weather, regulations, technology, etc. There may be some overlap between the cause and effect of an event and the associated client segment experiencing the event, as will be provided below.

The third example library shown in fig. 19 is a segment information library (depicted by block 1935) that is used to describe specific characteristics, features, and/or requirements associated with unique customer segments (or customer types). Each customer segment uses energy for a different purpose. For example, automotive manufacturers use energy to manufacture automobiles, semiconductor manufacturing facilities use energy to produce silicon wafers and chips, and hospitals use energy to provide treatment to patients. Each of these examples is different from each other, but is generally similar to other examples performing the same function; the key to the segment information base is to understand the susceptibility to and impact of events associated with a particular type of customer and energy consumer, while properly considering their ultimate purpose of consuming energy.

As previously described, each event type affects the client subdivision in a different manner. For example, two customer segments (e.g., a data center and a semiconductor manufacturing facility) may have similar susceptibility to voltage dips; however, the effect is unique. A slump event may interrupt the operation of the data center, resulting in lost servers, impacted clients, and (importantly) compromised reputation. Alternatively, voltage dips in semiconductor manufacturing facilities may result in loss of product, time, and waste of resources (e.g., energy, water, etc.). Each will experience business impacts but in a different manner.

In addition, each segment tends to use a unique array of specific load types. For example, automotive manufacturers use compressed air systems for painting, plastic extrusion facilities use variable speed drives, hospitals use sensitive medical equipment (e.g., MRI, etc.), and so forth. Assuming that most customer groups use similar types of devices (within their subdivisions), they are also indicated as being comparable in sensitivity to certain events. By analyzing the alert based (to some extent) on the customer segment from which the alert originated, providing advice for mitigation and remediation is somewhat simplified. Also, even if two different customer groups use similar devices, they may still have different purposes, targets, products and systems for their facilities/services.

In summary, the segment information store shown in block 1935 is used to analyze whether particular client segments/types should be concerned with events, and if so, why they should be concerned with events, and how they should be prioritized when multiple events are detected in the system. Some customer groups are more prone to invest in mitigation and remediation solutions due to the criticality of their operation. Importantly, in analyzing alert data and events generated thereby, the unique devices and associated processes, susceptibility to events, business objectives, desired profit margins, and risks within the unique customer segments are considered.

The fourth example library shown in fig. 19 is a mitigation and remediation techniques and advice library (hereinafter referred to as a mitigation library for simplicity) (depicted by block 1940) that is used to provide applicable and relevant solutions to events and EPMS problems. As mentioned above, there are many types of events and problems associated with alarms, and each particular customer segment tends to be more susceptible to a particular set of event types (due to the equipment and processes they use). The library connects event and problem characteristics and segment information to appropriate mitigation or remediation solutions, which are ultimately driven by alert data. In short, the key to mitigating libraries is to address device, process, system, and/or facility susceptibility, risk, and problems to mitigate or eliminate the impact of events on the customer's facilities and business.

Returning now to the flow illustrated in fig. 19, after an alarm has occurred at least at block 1910, and at block 1915 the alarm is analyzed to determine if the alarm was triggered in response to an event, e.g., based on analysis information from or derived from the captured energy-related signals and the library described above, a determination is made at block 1945 as to whether there are any events associated with the alarm.

In one example embodiment, data from one or more libraries may be used to identify incipient, arbitrary, or long-term problems (i.e., "do there are problems. Once a question is identified, data from one or more libraries is optionally used to determine the relevance of the question to the customer's segment/type (i.e., "i should care about. Likewise, problems may be associated with aspects of the customer's electrical system (e.g., equipment, infrastructure, etc.) or its accompanying EPM. Furthermore, the presence (or absence) of an alarm may indicate a problem to be solved.

More simply stated, an alarm may indicate the occurrence of an event, and the event indicates that there may be a problem to be solved. Analysis of alarms through the shots of the library ties these concepts together. This block connects alarms to events because EPMS (or other source) alarms are the primary data used to identify events (and problems).

At block 1945, in some cases, alarms associated with the event may be filtered from alarms not associated with the event. If it is determined that there is at least one event associated with the alert(s), the method may proceed to block 1950 where it is determined whether there are any opportunities available to resolve the event(s). Alternatively, if it is determined that there is not at least one event associated with the alert(s), the method may end in some cases, or may decide to store the decision for future analysis, trend analysis, or other steps related to the algorithm.

At block 1950, a determination is made as to whether there is an opportunity to mitigate or remedy the event indicated by the alarm. In some cases, this step may optionally be bypassed until a threshold for a given event type (or event characteristic) is met. For example, an event may not indicate that a chronic problem exists; thus, providing relief may not be cost effective. However, a large number of events may indicate that there is a long-term problem, and thus relief or remedial measures should be considered. In one example embodiment, one or more alerts may be generated, or initiated (e.g., using an EPMS associated with an electrical system) to indicate an opportunity to mitigate or remedy at least one of a symptom of an event, a source of the alert, and a cause/origin of the identified event and/or the identified alert. In some cases, these alerts may be presented on a user interface, audibly, via text, etc.

Another assessment at block 1950 is the availability of mitigation or remediation techniques and/or advice associated with at least one event. In such a case, there may be no mitigation or remediation techniques or recommendations available, or there may be insufficient information available to determine the need for mitigation or remediation. In both cases, the analysis and decisions from the previous blocks are optionally stored for future analysis, trend, and/or other steps related to the algorithm accordingly. No sufficient information or no indication of mitigation or remediation techniques or advice would bypass the action taken to mitigate or remedy the event and optionally measure/verify/validate the event.

If the evaluation at block 1950 indicates that at least one mitigation or remediation technique and/or advice is available, the process proceeds to block 1955, where an optimal solution to the event is determined. The information provided by at least one of the libraries may be used to evaluate the ability to mitigate, remedy, and/or provide advice to address the event. Techniques, suggestions, and thresholds for determining whether at least one mitigation, remedy, and/or suggestion is viable may be updated in the library based on analysis/analysis, measurement/verification data, manual revisions, pushed from a cloud-based application or other source periodically or on demand.

At block 1955, an analysis is performed to provide an optimal solution to mitigate or remedy a problem that may require information from one or more libraries. For example, the mitigation library (e.g., block 1940) may include an array of mitigation and/or remediation techniques and recommendations that are generally associated with an array of problems and concerns related to electrical systems and/or EPMs. Thus, the array of problems and concerns associated with the electrical system and/or EPMS are related to information within other libraries (e.g., event and problem characteristics libraries, alarm types and indication libraries, etc.). Accordingly, mitigation and remediation techniques and recommendations may be prioritized and optimized based on a combination of segment types, event types, and/or alarm types. It should be appreciated that in all cases, the best goal is to alleviate or remedy the problem; not necessarily a single event (although it may be done). The indication of the occurrence of an event may be, but is not necessarily, problematic. Before knowing whether there is a problem, the threshold for the event should be determined/set/understood.

If it is determined that one or more problems are occurring/co-occurring within the system, a recommended mitigation and/or remediation method may be selected and provided based on one or more of several factors, including: 1) minimum cost, 2) minimum maintenance, 3) minimum space requirements, 4) industry and/or other similar customer type recommendations for problem and/or segment types, 6) standard recommendations for problem and/or segment types, 7) equipment manufacturer recommendations for problem and/or segment types, 8) best performing history solutions for measurement/verification/validation data for problem and/or segment types, 9) other methods that may be technically, operationally, and/or corporate considered satisfactory, and/or 10) any combination of the foregoing factors. Further, at least one historical or real-time metric may be used or utilized to identify one or more optimal methods of alleviating or solving one or more problems associated with the electrical system and/or EPM.

It should be appreciated that mitigation and remediation techniques may include a range of approaches to solving electrical or EPMS problems. The following table provides a few simple examples of problems and potential mitigation or remediation techniques, regardless of the cause of the problem.

It is important to reiterate that the mitigation or remediation techniques provided in the above table are for illustrative purposes only and (in fact) require additional information to verify or validate.

It should be appreciated that mitigation or remediation may involve other methods or suggestions for solving the problem. For example, it may be suggested to balance a long-term unbalanced three-phase circuit, install a buck starter to reduce voltage drop when the motor is started across the line, or shorten the lead length on the SPD. Mitigation or remedial advice is typically determined based on load/device type. For example, using data from the segment information store (depicted by block 1935), the type of device typically used at the customer facility may be determined. From there, alarms (and events they represent) are used to select methods or provide guidance to customers regarding solving certain problems.

It should be appreciated that information from one or more libraries may be used to help alleviate or remedy customer problems. In addition, data from one or more particular libraries may be prioritized or de-prioritized according to any number of factors, including (but not limited to): client subdivisions/types, event types, alarm types, device types, alarm sources, etc. Measured, derived, statistical, hierarchical, metadata or other forms of data/information may be used to update the library or used in conjunction with any one or more libraries to determine the best solution.

After identifying an optimal solution to the event at block 1955, one or more actions may be taken in response to the event. The action(s) may include, for example, optimal solution(s) for resolving the event(s) identified at block 1955. Additionally, the action(s) may include storing, displaying, and/or analyzing information related to the optimal solution(s).

After taking the appropriate action to process the event, the algorithm may optionally continue to evaluate the event to determine the impact or effectiveness of the action taken in response to the event to process the event. This optional step may occur permanently/continuously, periodically or specifically. In one example embodiment, evaluating includes analyzing and comparing information from an aggregation prior to taking or performing at least one action with information from an aggregation after taking or performing at least one action. According to some embodiments of the present disclosure, aggregated information prior to taking or performing at least one action is derived from energy-related signals captured or derived by at least the IED at a first time prior to taking or performing the at least one action. In addition, according to some embodiments of the present disclosure, the aggregated information after taking or performing the at least one action is derived from an energy-related signal captured or derived by at least the IED at a second time after taking or performing the at least one action.

The output/result of this step may be at least one of providing or indicating a context, purpose, validity, new or supplemental advice, request for additional information and/or opportunities, discrete or systematic benefits (e.g., ROI, reduced recovery time, monetary savings, reduced downtime, reduced events, etc.), and the like. In embodiments that evaluate the validity of at least one action that includes quantifying taken or performed, it may be determined whether the validity of the quantification meets or exceeds an acceptable threshold. In response to the quantified effectiveness meeting or exceeding an acceptable threshold, a determination may be made as to whether at least one action needs to be continued to be taken or performed. Additionally, in response to the quantified effectiveness not meeting or exceeding an acceptable threshold, it may be determined whether any adjustments to the at least one action taken or performed are required, or whether at least one alternative action should be taken or performed. Feedback from these (or other) outputs/results may also optionally be provided to at least one library for updating, improving, supplementing, and/or deleting information and/or data for mitigation or remediation advice.

At block 1970, data and/or information generated by the algorithm, attached to the library, and/or otherwise related to the processes described herein may be stored for historical use, integrated into the algorithm and/or library, analyzed for supplemental opportunities, and/or statistical evaluation for additional insight. The data and/or information generated by the algorithm may also be used to change/adjust EPMS (or other source) configuration settings and thresholds accordingly. Finally, this information may be used to update, change, delete, or adjust data located in any data repository (e.g., library, etc.) associated with the EPMS (or other source), including cloud-based repositories and libraries, edge-based systems, gateways, and/or any IEDs (or related devices).

At block 1975, the algorithm (or related system) optionally provides output (in some form) to the end user, system, support personnel, service personnel, and/or other interested parties. The output may be a report, email, notification, signal, and/or any other indication related to the steps, analysis, and/or conclusion of the algorithm/process. The output may be generated indiscriminately, periodically, and/or continuously as configured in the first configuration function. One or more records of one or more outputs from the application may be maintained as needed or desired. The output may contain recommendations/suggestions, actions, data, analyses, feedback, and/or information related to mitigating or remediating the at least one event indicated by the at least one alert. Additionally, the output may accordingly take into account any aspects, events, problems, and/or improvements of the EPMS (or other alert source) and/or the electrical system.

After block 1975, the method may end, return to block 1905, or one or more actions may be taken, as will be apparent to one of ordinary skill in the art.

As described above and as will be appreciated by those of skill in the art, embodiments of the disclosure herein may be configured as a system, method, or combination thereof. Accordingly, embodiments of the present disclosure may include various means including hardware, software, firmware, or any combination thereof.

It should be appreciated that the concepts, systems, circuits, and techniques sought to be protected herein are not limited to use in the example applications described herein (e.g., power monitoring system applications), but may be useful in substantially any application in which it is desirable to provide electrical system analysis. While particular embodiments and applications of the present disclosure have been illustrated and described, it is to be understood that the embodiments of the present disclosure are not limited to the precise construction and compositions disclosed herein, and that various modifications, changes, and variations may be apparent from the foregoing descriptions without departing from the spirit and scope of the present disclosure as defined in the appended claims.

Having described preferred embodiments for illustrating various concepts, structures and techniques that are the subject of this patent, it should now be apparent to those of ordinary skill in the art that other embodiments incorporating these concepts, structures and techniques may be used. Additionally, elements of different embodiments described herein may be combined to form other embodiments not specifically set forth above.

Accordingly, it is intended that the scope of the patent should not be limited to the described embodiments, but should be limited only by the spirit and scope of the appended claims.

Claims

1. A method for reducing alarm nuisance behavior in an electrical system, comprising:

processing electrical measurement data from or derived from energy-related signals captured or derived by at least one Intelligent Electronic Device (IED) in the electrical system to identify events in the electrical system, and alarms triggered in response to the identified events and/or other events in or related to the electrical system;

aggregating information related to at least the identified event and the identified alert;

analyzing the aggregated information to identify at least one alarm nuisance behavior; and

at least one action is taken or performed based on or in response to the at least one identified alarm nuisance behavior.

2. The method of claim 1, wherein the aggregated information further comprises information from at least one of: power Monitoring Systems (EPMS), SCADA systems, building Management Systems (BMS), I/O devices, programmable Logic Controller (PLC) data, and system users.

3. The method of claim 2, wherein the EPMS comprises the at least one IED responsible for capturing or deriving the energy-related signal.

4. The method of claim 1, wherein the aggregated information is further analyzed to identify missing or incomplete data and an impact of the missing or incomplete data on the at least one identified alarm nuisance behavior.

5. The method of claim 1, wherein the at least one identified alarm nuisance behavior is an indication of a suboptimal alarm health condition.

6. The method of claim 5, wherein the at least one action taken or performed based on or in response to the at least one identified alarm nuisance behavior comprises at least one action that improves the alarm health condition.

7. The method of claim 1, wherein the at least one identified alarm nuisance behavior comprises a behavior indicative of at least one of a predefined or prescribed alarm nuisance behavior, a user-defined alarm nuisance behavior, and a learned alarm nuisance behavior.

8. The method of claim 7, wherein the predefined or prescribed alarm nuisance behavior is defined based at least in part on good engineering practice, a threshold defined during one of typical steps of an alarm ISA 18.2 "audit and philosophy cycle" (A, B, C, D, H, I, J), or at field commissioning, or a prescribed threshold.

9. The method of claim 7, wherein the learned alarm nuisance behavior is learned from analysis of data received from system users and at least one of I/O systems and devices.

10. The method of claim 7, wherein the at least one predefined or prescribed alarm nuisance behavior, user-defined alarm nuisance behavior, or learned alarm nuisance behavior is based at least in part on customer segment types.

11. The method of claim 1, wherein the at least one action taken or performed based on or in response to the at least one identified alarm nuisance action comprises characterizing and/or quantifying the at least one identified alarm nuisance action.

12. The method of claim 11, wherein the characterizing comprises grouping the at least one identified alarm nuisance behavior into one or more of a plurality of predefined or prescribed alarm nuisance behaviors, a plurality of user-defined alarm nuisance behaviors, or a plurality of learned alarm nuisance behaviors.

13. The method of claim 12, wherein the plurality of predefined or prescribed alarm nuisance behaviors, the plurality of user-defined alarm nuisance behaviors, or the plurality of learned alarm nuisance behaviors comprise at least one of: stale alarm nuisance behavior, dithered alarm nuisance behavior, transient alarm nuisance behavior, and flood alarm nuisance behavior.

14. The method of claim 12, wherein the at least one identified alarm nuisance behavior is grouped into one or more of the plurality of predefined or prescribed alarm nuisance behaviors, a plurality of user-defined alarm nuisance behaviors, or a plurality of learned alarm nuisance behaviors in response to determining that the at least one identified alarm nuisance behavior satisfies a predefined, prescribed, user-defined, or learned threshold associated with one or more of the plurality of predefined or prescribed alarm nuisance behaviors, a plurality of user-defined alarm nuisance behaviors, or a plurality of learned alarm nuisance behaviors.

15. The method of claim 11, further comprising:

information related to the at least one identified alarm nuisance behavior is preprocessed prior to characterizing and/or quantifying the at least one identified alarm nuisance behavior.

16. The method of claim 15, wherein the preprocessing includes identifying, filtering, and/or correcting errors in information related to at least one identified alarm nuisance behavior.

17. The method of claim 16, wherein the error is based on incorrect or incomplete data.

18. The method of claim 16, wherein the error comprises a lost or incomplete timestamp and the preprocessing comprises correcting, creating, and/or appending a new or corrected timestamp.

19. The method of claim 11, further comprising:

determining whether the at least one identified alarm nuisance behavior satisfies a prescribed condition, the prescribed condition including a minimum number of occurrences of the at least one identified alarm nuisance behavior within a given analysis period for treating the at least one identified alarm nuisance behavior as nuisance behavior for purposes of future analysis.

20. The method of claim 19, further comprising:

in response to the at least one identified alarm nuisance behavior not meeting the prescribed condition, the at least one identified alarm nuisance behavior is filtered or removed from a dataset comprising the at least one identified alarm nuisance behavior.

21. The method of claim 11, further comprising:

information related to the characterized and/or quantified at least one identified alarm nuisance behavior is appended to time series information associated with the identified alarm.

22. The method of claim 1, wherein the at least one action taken or performed based on or in response to the at least one identified alarm nuisance behavior comprises:

At least one potential nuisance remedy is identified to address the at least one identified alarm nuisance behavior.

23. The method of claim 22, further comprising:

one or more of the at least one potential nuisance remediation is selected and recommended based on the particular user and/or customer segment type associated with the electrical system.

24. The method of claim 1, wherein the aggregated information is analyzed automatically or dynamically.

25. The method of claim 1, further comprising: the event time stamp associated with the identified alarm is corrected to the entire interval/period of the identified event and/or other event in or related to the electrical system responsible for triggering the identified alarm.

26. A system for reducing alarm nuisance behavior in an electrical system, comprising:

at least one processor;

at least one memory device coupled to the at least one processor, the at least one processor and the at least one memory device configured to:

27. The system of claim 26, wherein the system corresponds to, comprises, or is part of a power monitoring system (EPMS).

28. The system of claim 26, wherein the at least one identified alarm nuisance behavior comprises behavior indicative of at least one predefined or prescribed alarm nuisance behavior, user-defined alarm nuisance behavior, or learned alarm nuisance behavior.