ACCESS

[0001] The present disclosure relates to power systems, and more specifically, to management of power system events through phasor measurement units (PMUs).

Related Art

[0002] In the related art implementations, PMUs are used to monitor the power grid and provide real time feedback regarding power system disturbances. With high resolution, time-synchronized sensing schemes, PMUs can capture power system dynamics and transient switching events, such as line reclosing and breaker switching, the majority of which take place autonomously and may not be recorded. In the related art, use of PMUs throughout a power system may cause power operators to be inundated by massive amounts of data, which may prevent them from recognizing critical grid information or abnormal behavior and responding in a timely manner. For example, the use of PMUs monitoring a power grid can produce data volumes 100 to 1000 times larger than typically handled by related art supervisory control and data acquisition (SCAD A) systems used to remotely monitor and control facilities.

[0003] Further, in some related art implementations, searching a PMU database of past similar events may be used to help determine a power grid operator's action in response to a fault occurring in the power grid. Additionally, in some related art implementations prony analysis may be used to extract valuable information from uniformly sampled signals from the PMU and builds a series of damped complex exponentials or sinusoids. This type of analysis may allow for the estimation of frequency, amplitude, phase, and damping components of the signal from the PMU.

[0004] In one related art system., execution of each data thread is scheduled based on thread affinity. Thus, each thread can share common resources, such as common data, using a thread affinity graph. This process can improve performance of parallel computation.

[0005] In another related art implementation, known or predefined event information, along with analytics results data, is calculated and stored in wave form in a database in a batch mode. This event information contains an event name and a wavefonn identifier (ID) (e.g., a metric ID) and time stamps defining when an event occurred. When a new waveform arrives, die new wave form is checked to determine if the wave form contains any predefined events. If the new waveform contains any predefined events, event information can be retrieved from, the database using the event name, and waveform data, related to the event can be retrieved using the stored waveform id and timestamps.

[0006] However, management of these related art systems can become more difficult as more analytic features are stored and/or a data-mart is created. This is due to the additional features and/or data-mart requiring significant Central Processing Unit (CPU) and input/output (I/O) resources to create the feature values from the data in large databases. In systems with new? data being continuously received (e.g., streaming data such as a PMU database) obtaining sufficient computing resources to calculate feature values may be technically infeasible or cost prohibitive. For example, the computational time required to calculate feature values may exceed tens of milliseconds, or even a full second, which is infeasible when processing multiple incoming data streams from PMUs distributed within a power grid. Further, CPU costs and time required to calculate various oscillation stabilities are high and a user would need to wait a long time to obtain effective data necessary for online display.

[0007] Further, these related art systems are unable to detect similar events that have not been predefined. With power distribution systems it is not always possible to predefine events because many power system events can be caused by natural phenomena (e.g., storms, heat induced brown outs, etc.)

SUMMARY

[0008] There is a need for a system and method to quickly identify "events" from historical PMU database data similar to an ' ^" event" detected in incoming PMU data without relying on pre-defined feature values or a pre-defined event information index. Such "events" are not caused by normal load and generation variations, so that operators can be alerted early on and can take remedy actions in time. Such a system should allow an operator to retrieve data about similar events immediately after the new event data arrives even if the new event data, is not pre-defined or is first occurrence event. Additionally, the CPU costs of feature extraction and storage of analytics results should be avoided to enable retrieval of similar events even from data being stored continuously into a database. Further, there is also a need to be able to get prioritized data as fast as possible, and make of the data in online operations without long time. [0009] Example implementations of the present disclosure involve systems and methods to receive multiple event data sets related to an event, identify multiple windows of data, assign windows to threads, calculate a severity value for each combination of an event data set and a thread, and perform a prioritized similarity calculation for each combination.

[0010] Aspects of the present disclosure also include a system configured to manage one or more phasor measurement units (PMUs) in a power system. The system may include a memory configured to store measurement data from the one or more PMUs and a processor. The processor may be configured to receive a plurality of event data sets, which is each related to an event in the power system, identify a plurality of windows of the measurement data, assign each of the plurality of windows of measurement data to one of a plurality of threads, calculate a severity value for each combination of one of the plurality of event data sets, and one of the plurality of threads; and perform a similarity calculation for each combination of the one of the plurality of event data, sets, and the one of the threads, which is prioritized by the severity calculated for each combination,

[0011] Aspects of the present disclosure also include a method of managing one or more phasor measurement units (PMUs) in a power system. The method may include storing measurement data from the one or more PMUs, receiving a plurality of event data sets, which is each related to an event in the power system., identifying a plurality of windows of the measurement data, assigning each of the plurality of windows of measurement data to one of a plurality of threads calculating a severity value for each combination of one of the plurality of event data sets, and one of the plurality of threads; and performing a similarity calculation for each combination of the one of the plurality of event data sets, and the one of the threads, which is prioritized by the severity calculated for each combination.

[0012] Aspects of the present disclosure further include a non-transitory computer readable medium. The non-transitory computer readable medium may store instructions for managing one or more phasor measurement units (PMUs) in a power system. The instructions may include storing measurement data from the one or more PMUs, receiving a plurality of event data sets, which is each related to an event in the power system, identifying a plurality of windows of the measurement data, assigning each of the plurality of windows of measurement data to one of a plurality of threads, calculating a severity value for each combination of one of the plurality of event data sets, and one of the plurality of threads, and performing a similarity calculation for each combination of the one of the plurality of event data sets, and the one of the threads, which is prioritized by the severity calculated for each combination.

[0013] Aspects of the present disclosure further include an apparatus configured to manage one or more phasor measurement units (PMUs). The apparatus may include means for storing measurement data from the one or more PMUs, means for receiving a plurality of event data sets, which is each related to an event in the power system, means for identifying a plurality of windows of the measurement data, means for assigning each of the plurality of windows of measurement data to one of a plurality of threads, means for calculating a severity value for each combination of one of the plurality of event data sets, and one of the plurality of threads, and means for performing a similarity calculation for each combination of the one of the plurality of event data sets, and the one of the threads, which is prioritized by the severity calculated for each combination.

BRIEF DESCRIPTION OF DESCRIPTION

[0014] FIG. 1 illustrates an example waveform representative of data received from a PMU in accordance with an example implementation.

[0015] FIG. 2 illustrates an example waveform representative of data received from a PMU in accordance with an example implementation.

[0016] FIG. 3 illustrates an example waveform representative of data received from a PMU in accordance with an example implementation.

[0017] FIG. 4 illustrates a data table representative of PMU data in communication format in accordance with an example implementation.

[0018] FIG. 5 illustrates a data table representative of PMU data in a storage format for in accordance with an example implementation.

[0019] FIG. 6 illustrates a data table representative of filter values in accordance with an example implementation.

[0020] FIG. 7 illustrates a data table representative of settings used to define a window of data to be retrieved in accordance with an example implementation,

[0021] FIG. 8 illustrates a data table representative of search key data extracted from a PMU database in accordance with an example implementation. [0022] FIG. 9 illustrates a distance correspondence table representative of the physical distance between different PMUs in a power grid in accordance with an example implementation.

[0023] FIG. 10 illustrates a distance correspondence table representative of the physical distance between different geographic areas sen/iced by various PMUs in a power grid in accordance with an example implementation.

[0024] FIG. 1 1 illustrates a data type correspondence table in accordance with an example implementation.

[0025] FIG. 12 illustrates a general process flow of providing similarity analytics of detected events measured by a PMU located within a power grid in accordance with a first example implementation.

[0026] FIG. 13 illustrates a process flow for identifying the historical event from a PMU database in accordance with an example implementation.

[0027] FIG. 14 illustrates a process for identifying outliers present in a search key data table extracted from the PMU Database in accordance with an example implementation.

[0028] FIG. 15 illustrates a process for recognizing single events in accordance with an example implementation,

[0029] FIG. 16 illustrates another process for recognizing single events in accordance with an example implementation.

[0030] FIG. 17 illustrates a process for calculating a time duration preceding an occumng event and a time duration following an occurring event to be used to define a time window of historic PMU data for comparison to a current window containing the occurring event in accordance with an example implementation.

[0031] FIG. 18 illustrates a process for performing similarity analytics between the candidate events identified in the processes of either FIGS. 15 and 16 and the search key- data representative of an occurring event in accordance with an example implementation.

[0032] FIG. 19 illustrates a process for assigning the retrieved data waveforms to different threads to create the multi-threading according to an example implementation.

[0033] FIG. 20 illustrates another process for assigning the retrieved data waveforms to different threads to create the multi-threading according to an example implementation. [0034] FIG. 21 illustrates a process for determining index values for stability analytics of each detected event in an example implementation of the present application.

[0035] FIG. 22 illustrates a process for determining index values for stability analytics of each detected event in an example implementation of the present application.

[0036] FIG. 23 illustrates a process for determining index values for stability analytics of each candidate event or thread in an example implementation of the present application.

[0037] FIG. 24 illustrates a process for determining index values for stability analytics of each candidate event or thread in an example implementation of the present application.

[0038] FIG. 25 illustrates a process of performing oscillation stability calculation to the multiple threads.

[0039] FIG. 26 illustrates a process for ranking the candidate events or threads based on the calculated similarity.

[0040] FIG. 27 illustrates a process for updating filter table values based on a detected ongoing event or a detected historical event recognized during the processes discussed above.

[0041] FIG. 28 illustrates a schematic representation of an example implementation of combinations of events and threads that may be used to calculate severity values.

[0042] FIG. 29 illustrates a user interface displaying data relating to an occurring event and a retrieved historical event in accordance with an example implementation.

[0043] FIG. 30 illustrates an example system upon which example implementations may be applied.

[0044] FIG. 31 illustrates a PMU in accordance with an example implementation.

DETAILED DESCRIPTION

[0045] The following detailed description provides further details of the figures and example implementations of the present application. Reference numerals and descriptions of redundant elements between figures are omitted for clarity. Terms used throughout the description are provided as examples and are not intended to be limiting. For example, the use of the term "automatic" may involve fully automatic or semiautomatic implementations involving user or administrator control over certain aspects of the implementation, depending on the desired impleme tation of one of ordinary skill in the art practicing implementations of the present application. Selection can be conducted by a user through a user interface or other input means, or can be implemented through a desired algorithm. Example implementations as described herein can be utilized either singularly or in combination and the functionality of the example implementations can be implemented through any means according to the desired implementations.

[0046] Example implementations involve a method to detect anomalies or events in PMU data and calculating similarities with anomalies or events from historical PMU data, which can be implemented as a similar event detection module. The anomalies may arise from various power system events, such as transient phenomena (usually lasting less than one second) introduced by line breaker operation, reclosing, and faults, as well as steady state changes (lasting on the order of seconds) from topology and power flow variations. Our method is robust, fast, and scalable, making it suitable for use in real-time detection.

[0047] The input to the similar event detection module is a set of time series data collected by PMUs. The basic series are frequency, voltage, and power data, reported at a fixed sample rate, such as 30 Hertz (Hz). In some implementations, current data may alternatively be reported and power data calculated based on the received voltage and current data. The data may be historical, streaming, or both.

[0048] To allow visualization of anomalies, the data received may be plotted over time to produce a waveform representative of the received data. FIGS. 1-3 illustrate example waveforms representative of data received from a PMU in accordance with an example implementation. FIG. 1 illustrates a plot 10 of received voltage data at different time intervals. Reference lines 12 and 14 representative of maximum and minimum threshold values of voltage may also be plotted with the received voltage data. The threshold values may be used to identify outlier values that can be used to detect potential events in the received voltage data. As illustrated in FIG. 1 , some event may have occurred at to ( 12:26: 15) causing outliers I 6a-16f where the voltage values of the received data is either above (16b, 16d, 16f) or below (16a, 16c, 16e) the threshold reference lines 12, 14. As discussed below, detection of these outliers (16a-16f) may be used to identify similar events in historical PMU data automatically.

[0049] FIG. 2 illustrates a plot 20 of received frequency data at different time intervals. Reference lines 22 and 24 representative of maximum and minimum threshold values of frequency may also be plotted with the received frequency data. The threshold values may be used to identify outlier values that can be used to detect potential events in the received frequency data. As illustrated in FIG. 2, some event may have occurred at to (12: 26: 15) causing outliers 26a-26d where the frequency values of the received data is either above (26b, 26c) or below (26a, 26d) the threshold reference lines 22, 24. As discussed below, detection of these outliers (26a-26d) may be used to identify similar events in historical PMU data automatically.

[0050] FIG. 3 illustrates a plot 30 of received power data at different time intervals. As illustrated, the power data may have a region 32 of power ramp-up where the power is increasing to an operating range based on the load being experienced. Additionally, the power data, may illustrate one or more operating regions 34, where the power fluctuates over time during normal operation. As illustrated in FIG. 3, some event may- have occurred at to ( 12:26: 15) and caused the power data plot 30 to drop below the region 34 of normal operation. In the depressed region 36, the power has dropped significantly following the event at to. As discussed in greater detail below, the frequency and voltage data are relative constant during normal operation, allowing recognition of outliers to be used to identify events. Conversely, power data values can fluctuate widely during normal operation, making it difficult to detect outliers indicative of events based on power data.

[0051] FIG. 4 illustrates a data table 400 representative of PMU data in communication format received from each PMU in accordance with an example implementation. Each row in the data table 400 is representative of all data received from a specific PMU at a specific moment of time and includes 10 columns of information. Column 405 is representative of the time stamp associated with the received data. Column 410 is representative of the PMUJd associated with the PMU from which the data was received. Column 415 is representative of the geographic area associated with the PMU from which the data was received. Column 420 is representative of a frequency data value measured by the PMU. Column 425 is representative of a voltage data value measured by the PMU. Column 430 is representative of an active power data value measured by the PMU. Column 435 is representative of a current angle value measured by the PMU . Column 440 is representative of a current magnitude data value measured by the PMU. Column 445 is representative of a reactive power data value measured by the PMU. Column 450 is representative of a rate of change of frequency (ROCOF) data value calculated by the PMU or the system based on the other data received from the PMU.

[0052] FIG. 5 illustrates a data table 500 representative of PMU data converted from the communication format of FIG. 4 to a storage format for storage to a database and processing by the similar event detection module in accordance with an example implementation. Each row in the data table 500 is representative of a single measurement value receive from a specific PMU at a specific moment of time and includes 4 columns of information. Column 505 is representative of a row number sequentially assigned to each row and used for cross-references and data handling. Column 510 is representative of a value of the measured data in a given row. The physical property (e.g. voltage, power, frequency) associated with each row may vary. For example, as illustrated row# 1 -5 contain frequency values and row# 6-10 contain voltage values.

[0053] Column 515 is representative of the time stamp associated with the measured data in a given row. Column 520 is representative of an Item_id associated with the measured data in a given row. The Item id is an identifier string generated by combining a PMU_ID associated with the measure data in a given row and physical property associated with the measured data in a given row (e.g. voltage, power, frequency). For example, in row #1 the Item id may be the identifier string "PMU1 - Frequency," which corresponds to the combination of ^" 'PMU Γ ¹ and "Frequency." Thus, the Item_id in row #1 indicates that the value (Column 510) corresponds to frequency data from PMU ! captured at the timestamp (Column 515).

[0054] FIG. 6 illustrates a data table 600 representative of filter values stored in memory to be used by the similar event detection module in accordance with an example implementation. The filter values may correspond to threshold values used to identify outliers in received frequency and voltage data as discussed above with respect to FIGS. 1 and 2. Each row in the data table 600 is representative of a different filter value used to define a threshold for identifying an outlier in a received data associated with one physical property or PMU providing data. Column 605 is representative of the type of physical property associated with the filter value (e.g., Voltage, Frequency). Column 610 is representative of a percentage used, in combination with the base value discussed below (Column 620), to determine a minimum filter value, which may be used to identify outliers when the measured value falls below the minimum filter value. Column 615 is representative of a percentage used, in combination with the base value discussed below (Column 620), to determine a maximum filter value, which may be used to identify outliers when the measured value exceeds the maximum filter value. Column 620 is representative of a base value that is used in combination with the percentages of Columns 610 and 620 to determine the thresholds used to identify outliers in data. For example, an upper threshold value in the first row may correspond to 110% of the base value (e.g. 550 volts) and the lower threshold value in the first row may correspond to 90% of the base value (e.g. 450 volts).

[0055] Further, Column 625 is representative of the Item id associated with the filter values of each row. As illustrated, different filter values may be used for the same physical property measured by different PMUs. For example, the base value associated with the voltage measured at PMU1 may be 500 volts, but the base value associated with the voltage measured at PMU2 may be 230 volts. Further, the same filter values may be used for the same physical property measured by different PMUs. For example, the base value associated with frequency measured at both PMU 1 and PMU2 may be 60 Hz, [0056] FIG. 7 illustrates a data table 700 representative of settings used to define a window of data to be retrieved from historical PMU data when identifying similar events in accordance with an example implementation. Column 705 is representative of a minimum event duration used to separate different events occurring in short duration. If multiple outliers are found within a time window corresponding to the minimum event duration of column 705, all outliers may be grouped and considered a single event. Conversely, multiple outliers separated by a time window exceeding the minimum event duration of column 705 may be treated as different events. The value of column 705 may be defined by a user, a system operation, or may be dynamically determined based on previously detected events.

[0057] FIG. 8 illustrates a data table 800 representative of search key data extracted from a PMU database to identify outliers in historical data in accordance with an example implementation. The search key data is a window of data extracted from a PMU database to be used to identify outliers in historical PMU data. The size of the window of data may correspond to window size of data being received currently received by a PMU that is experiencing an occurring event.

[0058] Each row in the data table 800 is representati ve of different data set (e.g. a set of received data values) received from a single PMU at specific time. Column 805 is representative of a timestamp associated with the received data set in each row. Column 810 is representati ve of the PMU id associated with the received data set. Column 815 is representative of a frequency value associated with the received data set. Column 820 is representative of a voltage value associated with the received data set. Column 825 is representative of an oscillation seventy value associated with the received data set. Oscillation severity value can be calculated using equation 1 below:

[0059] Oscillation + _Wy Verne

(eq. 1)

[0060] where and w _v are user defined weighting factors:

[0061] f _t and V _t correspond to frequency and voltage measurements for a current timestamp (e.g., a current row of FIG. 8);

[0062] f _t > and V _t > correspond to frequency and voltage measurements for a preceding current timestamp (e.g., row above in FIG. 8); and

[0063] f _ave wd V _ave correspond to baseline frequency and voltage values associated with a particular PMU (e.g., Column 620 of FIG. 6 discussed above).

[0064] Usage of the data table 800 is discussed in greater detail below.

[0065] FIG. 9 illustrates a distance correspondence table 900 representative of the physical distance between different PMUs in a power grid. The table includes three PMUs with the PMU ids associated with each PMU being provided in the top row and in the left most column. The remaining fields indicate a physical distance between the respective PMUs. For example, the distance between PMUl and PMU2 is 10 km (the units of measurement are not particularly limited and are provided merely for illustration purposes).

[0066] FIG. 10 illustrates a distance correspondence table 1000 representative of the physical distance between different geographic areas serviced by various PMUs in a power grid. The cable includes three areas with the Area ids associated with each area being provided in the top row and in the left most column. The remaining fields indicate a physical distance between the respective geographic areas. For example, the distance between Area 1 and Area 2 is 110 km (the units of measurement are not particularly- limited and are provided merely for illustration purposes).

[0067] FIG. 11 illustrates a data type correspondence table 1100 representative of the data types of physical properties that correlates with, or is dependent upon, another data type. In the table 1 100, each row illustrates a different correspondence or relationship. Column 1105 is representative of a measured data type (e.g., Frequency, Voltage, and Angle). Column 1110 is representative of data types that can be correlated io the measured data type of Column 1105. For example, both frequency and ROCOF (Column 1110) can be correlated to measured frequency (Column 1105). Further, as illustrated, both voltage and reactive power (Column 1 1 10) can be correlated to measured voltage (Column 1105). Additionally, angle and active power (Column 1110) can be correlated to measured angle (Column 11 10).

[0068] FIG. 12 illustrates a general process flow 1200 of providing similarity analytics of detected events measured by a PMU located within a power grid in accordance with a first example implementation. In the general process 1200, an event or anomaly occurs and is detected at 1205. The anomalies may arise from various power system, events, such as transient phenomena (usually lasting less than one second) introduced by line breaker operation, reclosing, and faults, as well as steady state changes (lasting on the order of seconds) from topology and power flow variations.

[0069] The occurring event may be detected by determining that measured data associated with one or more of frequency and voltage is outside of normal range specified by filter values, such as those illustrated in FIG. 6 above. For example, an event may be detected by determining that measured data associated with voltage exceeds a specified base value (e.g., Col. 620) by more than a specified in max percentage (e.g., Column 615),

[0070] Once the occurring event is detected, a historical event similar to the occurring event is identified from a database of historical PMU data at 1210. As used herein the term "historical" merely refers to PMU data that was previously received and has been stored to a database for later use. The process of identifying the historical event is discussed in greater detail below with respect to FIGS. 14-18 and may be performed by the similar event detection module. The output of the similar event detection module may be a set of timestamps, and one or more item_ids at which historical anomalies have been detected, and associated measurement data indicative of the anomaly occurring. The output of the similar event detection module may also include similarity data and similarity analytics numerically representing a degree of similarity between the historical event and the occurring event.

[0071] At 1215, the output of the similar event detection module may be used to correlate and display a comparison between the occurring event and the identified historical event, FIG. 29 discussed below illustrates an example implementation of the displayed comparison. Further, in addition to displaying a comparison between the occurring event and the identified historical event, results of similarity analytics between the occurring event and the identified historical event a historic log of actions taken in response to the historic event, and the effect may be displayed. The displayed historic log may be used to recommend actions to be taken in response to the occurring event as discussed in greater detail below with respect to FIG. 29.

[0072] FIG. 13 illustrates a process flow 1300 for identifying the historical event from a PMU database in accordance with an example implementation. At 1305, an outlier search is performed to identify outliers in the PMU database that may be indicative of candidate events to be identified as the historical event. FIG. 14 discussed below illustrates an example process for performing an outlier search in the PMU database.

[0073] After the outlier search has been performed, a single event recognition process may be performed at 1310 to determine if the outliers are indicative of a candidate event to be identified as the historical event. FIGS. 15 and 16 discussed below illustrate example implementations of single event detection processes. The output of the single event recognition process may be a list of candidate events. By performing the outlier search and the single event detection processes, similar historical events can be extracted from, the PMU database in a few seconds. Conventional historical event detection processes relying on feature extraction have required nearly five years to identify similar historical events making real-time use of historical event data infeasible.

[0074] After the single event recognition process, similarity analytics may be performed to calculate a similarity between each candidate event on the list of candidate events and the occurring event. FIG. 20 illustrates an example implementation of a similarity analytics process. Once the similarity between each candidate event is determined, the candidate events having the greatest similarity may be identified, the process 1300 may end. When the process 1300 ends, the candidate events having the greatest similarity may be used in 1215 of process 1200 to correlate and display a comparison between the occurring event and the identified historical events, along with similarity analytics and the historic log of actions taken in response to the historic event as discussed above.

[0075] FIG. 14 illustrates a process 1400 for identifying outliers present in a search key data table extracted from the PMU Database in accordance with an example implementation. FIG. 8 discussed above illustrates an example implementation of a search key data table 800 that could be used in the process 1400. The search key data illustrated in the search key data table 800 may be received data associated with an occurring event. However, in some implementations, the search key may also be historical data representing one or more events selected for a user for comparison with other historical events

[0076] At 1405, each unique PMUJd (e.g., column 810) is extracted from the search key data table 800. At 1410, each extracted PMU id from the search key data table 800 is used to construct an Item id string including the PMU Id and the measured quantity (e.g., Frequency and voltage) illustrated in the search key data. For example, constructed Item ids may include: PMUl-voltage, PMU 1 -frequency, PMU2 -voltage, and PMU2-frequency.

[0077] After the Item__ids are constracted, all time stamps in a PMU database (e.g., table 500 illustrated in FIG. 5) having an Ttemjd corresponding to the constructed Item ids is identified at 1415. The row of the filter value table (e.g., table 600 of FIG. 6) associated with the constructed Item ids may also be identified in 1415.

[0078] At 1420, the data, value (e.g.. Column 510 of table 5) associated with the identified timestamps is compared to base value (Column 620 of table 600) of the identified filter value table row to determine if the data value exceeds the base value by more than the maximum percentage (e.g., Max%, column 615 of table 600) of the filter value table. Any timestamps associated with data values exceeding the base value by- more than the maximum percentage (e.g., data value>base value+ (base value* Max%/ 100) are selected to be returned as PMU database search results.

[0079] As illustrated in FIGS. 1-3 discussed above, the frequency and voltage data are relative constant during normal operation. Thus, the data values associated with voltage or frequency may be used in the process 1400 because these values tend to remain constant unless an event has occurred. Thus, outliers in voltage or frequency may be correlated to potential events. Conversely, power data values, and other measured values (e.g., current, angle, ROCOF) etc.) can fluctuate widely during normal operation, making it difficult to detect outliers indicative of events in power data or other measured data values. Thus, power data values, and other measured values (e.g., current, angle, ROCOF) may not be used in the process 1600.

[0080] At 1425, the data value (e.g.. Column 510 of table 5) associated with the identified timestamps is also compared to base value (Column 620 of table 600) of the identified filter value table row to determine if the data value is less than the base value by more than the minimum percentage (e.g., Min%, column 610 of table 600) of the filter value table. Any timestamps associated with data values less than the base value by more than the minimum percentage (e.g., data value<base value-(base value*Min%/100) are also selected to be returned as PMU database search results. Again, the data values associated with voltage or frequency are used because these values tend remain constant unless an event has occurred and thus outliers in voltage or frequency can be correlated to potential events.

[0081] At 1430, the selected timestamps and the associated Item ids are sorted based on Item_id and ordered based on the timestanip order to produce PMU database search results. After the selected timestamps and associated Item ids are sorted and ordered at 1430, the process 1400 ends. After the process 1400 ends, the produced PMU database search results may be used for single event recognition processes 1500, 1600 discussed below with respect to FIGS. 15 and 16.

[0082] FIG. 15 illustrates a process 1500 for recognizing single events in accordance with an example implementation. The process 1500 uses the produced PMU database search results from 1430 of process 1400 of FIG. 14 discussed above to recognize single events as candidates for comparison to the occurring event that was detected. At 1505, each record identified in the PMU database search results is examined to determine whether the Item_id has been encountered before. If a PMU database search result includes an Item__id that has not been encountered before (YES at 1505), the timestanip associated with the search result is added to a candidate list of similar events at 1515 and the process 1500 ends for that PMU database search result.

[0083] Conversely, if a PMU database search result includes an Item_id that has been encountered before (NO at 1505), each record identified in the PMU database search results is examined to determine whether the difference between the timestamp value associated with the PMU database search result and a timestamp value associated with a previous occurrence of the Item_id is greater than a defined single event duration value (e.g., the single event duration value of column 705 of table 700 of FIG. 7) at 1510. If the difference between the timestanip value associated with a PMU database search result and a timestamp value associated with a previous occurrence of the Item_id is greater than a defined single event duration value (YES at 1510), the timestamp associated with the search result is added to a candidate list of similar events at 1515 and the process 1500 ends for that PMU database search result.

[0084] Conversely, if the difference between the timestamp value associated with a PMU database search result and a timestamp value associated with a previous occurrence of the Item id is not greater than a defined single event duration value (NO at 1510), the process 1500 ends for that PMU database search result without the PMU database search result being added to the candidate list of similar events.

[0085] FIG. 16 illustrates another process 1600 for recognizing single events in accordance with an example implementation. The process 1600 uses the produced PMU database search results from 1430 of process 1400 of FIG. 14 discussed above to recognize single events as candidates for comparison to the occurring event that was detected. At 1605, each record identified in the PMU database search results is examined to determine whether the difference between the timestamp value associated with the PMU database search result and a timestamp value associated with a previous event timestamp and the current record time stamp is greater than or equal to a defined single event duration value (e.g., the single event duration value of column 705 of table 700 of FIG. 7). If the difference between the timestamp value associated with a PMU database search result and a timestamp value associated with a previous event time stamp is greater than the defined single event duration value (YES at 1605), the timestamp associated with the current search result record is added as an event timestamp to the event candidate list of similar events at 1625.

[0086] After the timestamp is added to the event candidate list, a determination is made whether the Item_id associated with the current search result has been encountered before at 1620. If the current PMU database search result includes an Item id that has not been encountered before (YES at 1620), the item id associated with the search result is also added to the candidate list of similar events at 1630 and the process 1600 ends for that PMU database search result. Conversely, if the current PMU database search result includes an Item id that has been encountered before (NO at 1620), the process 1600 ends for that PMU database search result without the Item id associated with the PMU database search result being added to the candidate list of similar events.

[0087] Returning to 1605, if the difference between the timestamp value associated with a current PMU database search result and a timestamp value associated with a previous event is not greater than or equal to the defined single event duration value (NO at 1605), the process 1600 continues to 1610. At 1610, a determination is made whether a distance between a PMU associated with the search result and a PMU associated with previous event exceeds a threshold, or whether a distance between an area associated with the search result and an area associated with a previous event exceeds a threshold. The distances between PMUs may be determined based on a stored table (e.g., table 900 in FIG. 9). The distances between areas may also be determined based on a stored table (e.g., table 1000 in FIG. 10). The threshold values used may be user defined or system defined or may be dynamically adjusted based on the characteristics of the occurring event.

[0088] If either the distance between a PMU associated with the search result and a PMU associated with a previous event, or a distance between an area associated with the search result and an area associated with a previous event exceeds the threshold (YES at 1610), the timestamp associated with the current search result record is added as an event timestamp to the event candidate list of similar events at 1625.

[0089] After the timestamp is added to the event candidate list, a determination is made whether the Item_id associated with current search result has been encountered before at 1620. If the current PMU database search result includes an Item_id that has not been encountered before (YES at 1620), the item id associated with the search result is also added to the candidate list of similar events at 1630 and the process 1600 ends for that PMU database search result. Conversely, if the current PMU database search result includes an Item_id that has been encountered before (NO at 1620), the process 1600 ends for that PMU database search result without the Item id associated with the PMU database search result being added to the candidate list of similar events.

[0090] Returning to 1610, if neither the distance between a PMU associated with the search result and a PMU associated with a previous event, nor a distance between an area associated with the search result and an area associated with a previous event exceeds the threshold (NO at 1610), the process 1600 continues to 1615. At 1615, the data type associated with the current search result is compared to the data type associated with a previous event to determine if the data types are correlated to each other based on a data type correlation table (e.g., Table 1100 of FIG. 11). If the data type associated with the current search result is not correlated to the data type of a previous event, based on the data type correlation table, (NO at 1615), the timestamp associated with the current search result record is added as an event timestamp to the event candidate list of similar events at 1625.

[0091] After the timestamp is added to the event candidate list, a determination is made whether the Item id associated with current search result has been encountered before at 1620. If the current PMU database search result includes an Item id that has not been encountered before (YES at 1620), the item_id associated with the search result is also added to the candidate list of similar events at 1630 and the process 1600 ends for that PMU database search result. Conversely, if the current PMU database search result includes an Item id that has been encountered before (NO at 1620), the process 1600 ends for that PMU database search result without the Item id associated with the PMU database search result being added to the candidate list of similar events,

[0092] Returning to 1615, if the data type associated with the current search result is correlated to the data type of a previous event, based on the data type correlation table, (YES at 1615), a determination is made whether the Item id associated with current search result has been encountered before at 1620. If the current PMU database search result includes an Item id that has not been encountered before (YES at 1620), the item id associated with the search result is also added to the candidate list of similar events at 1630 and the process 1600 ends for that PMU database search result. Conversely, if the current PMU database search result includes an Item_id that has been encountered before (NO at 1620), the process 1600 ends for that PMU database search result without the Item id associated with the PMU database search result being added to the candidate list of similar events,

[0093] FIG, 17 illustrates a process 1700 for calculating a time duration (tj) preceding an occurring event and a time duration (t ₂ ) following an occurring event to be used to define a time window of historic PMU data for comparison to a current window containing the occurring event in accordance with an example implementation . The process 1700 uses the search key data (e.g., table 800 of FIG. 8) to determine the time durations (tj & t ₂ > preceding and following the occurring event so that a similarly sized window of historical PMU data can be extracted to allow a waveform similarity determination to be performed.

[0094] In the process 1700, each time series data sets associated with each PMU in the key search data is considered a waveform to be used for a similarity analytics determination to be performed in the process 1800 of FIG. 18. For each waveform contained in the search key data, the first occurring timestamp associated with a data value meeting one of two conditions is retrieved at 1705. The two conditions considered in 1705 are whether 1) the value exceeds an associated filter table base value (e.g., Column 620 of table 600 of FIG, 6) by the Max% (e.g., Column 615 of table 600 of FIG. 6) or 2) that is less than an associated filter table base value (e.g., Column 620 of table 600 of FIG. 6) by the min% (e.g., Column 610 of table 600 of FIG. 6).

[0095] After one or more timestamps are retrieved in 1705, the retrieved timestamp values are compared to determine the minimum timestamp value in 1710-1720. At 1710, a determination is made whether a just found timestamp is less than a minimum time stamp. If the just found timestamp is less than the minimum timestamp (YES at 1710), the just found timestamp is set as the minimum timestamp at 1715 and the process 1700 proceeds to 1725. Conversely, if the just found time stamp is not less than the minimum timestamp (NO at 1710), the process 1700 proceeds to 1725.

[0096] At 1725, a determination is made whether all retrieved timestamps have been compared to the minimum timestamp. If not all retrieved timestamps have been compared (NO at 1725), the process 1700 returns to 1710 to compare a new just found timestamp with the minimum timestamp. Conversely, if all retrieved timestamps have been compared to the minimum timestamp, the process 1700 continues to 1725.

[0097] At 1725, values of time durations (ti & t ) preceding and following the occurring event are calculated. Time duration preceding the occurring event (ti) may be calculated by determining a difference between the minimum timestamp and the timestamp of the first record of the search key data. The time duration following the occurring event (ti) may be calculated by determining a difference between the timestamp of the last record of the search key data and the minimum timestamp. After the values of time durations (t; & t?) preceding and following die occurring event are calculated, the process 1700 ends.

[0098] FIG. 18 illustrates a process 1800 for performing similarity analytics between the candidate events identified in the processes of either FIGS. 15 and 16 and the search key data (e.g., Table 500 of FIG. 5) representative of an occurring event in accordance with an example implementation. However, the process 1800 is not limited use with identified candidate events and may also be used to perform similarity analytics between a plurality of event data sets and a plurality of windows of PMU data.

[0099] At 1805, a time duration preceding an occurring event (ti) and time duration after the occurring event (ti) are calculated for the search key data using the process 1700 discussed above with respect to FIG. 17.

[0100] At 1810, a set of item ids is created from the PMU id in the search key data. The Itemjds may be created by combining the PMU_id identified in the search key data with each data type included in the search key data (e.g., Frequency, voltage, current, power, angle, etc.). As discussed above, frequency and voltage were used for event detection. However, other data types (e.g., current, power, angle, etc.) may be used in the wavefonn correlation to improve a similarity calculation accuracy.

[0101] For each PMU id and for each time stamp in the candidate list of similar events, a data waveform is retrieved from the PMU table (e.g., table 500 of FIG. 5) at 1815. The retrieved data waveform is made up of any data having an tem id that matches the Item ids created in 1810 and having a time stamp value greater than the candidate timestamp-ti and less than the candidate tiniestamp+t _2. Thus, a window of data surrounding each candidate event is retrieved that is of the same size as the window of data provided by the search key data. Additionally, the candidate event and the occurring event should be temporally aligned within the respective data windows (e.g., the candidate event and the occurring event are preceded by equal time durations within their respective data windows).

[0102] At 1820, each retrieved data waveform is assigned to a data thread to create multi-threading. A process, such as processes 1900 and 2000 of FIGS. 19 and 20 may be used to assign the retrieved data waveforms to create the multi-threading.

[0103] Once the data multi-threading is created, oscillation stability is calculated for each thread at 1825 using a process, such as process 2400 of FIG. 24 to calculate a similarity between each identified event and the detected event.

[0104] After the oscillation stability is calculated, the candidates may be ranked based on the similarity using a process, such as process 2600 of FIG. 26. After the candidates are arranged using the similarity based on the oscillation stability calculation, the search results having most similarity may be displayed. FIG. 28 illustrates an example implementation of displayed search results.

[0105] FIG. 19 illustrates a process 1900 for assigning the retrieved data waveforms to different threads to create the multi-threading according to an example implementation. At 1905, a plurality of threads is created. In some example implementations, the number of threads created may be the number of candidates recognized during the single event recognition processes 1500 and 1600 of FIGS. 15 and 16, respectively. In other example implementations, the number of threads may- correspond to die number of Central Processing Units (CPUs) available to perform the similarit ' analytics.

[0106] After the plurality of threads is created, each retrieved data waveform may be assigned to a different thread at 1910. When each retrieve data waveform is assigned to a thread, set of data that makes up the tiiread includes a period of data points (tl) before the event and a period of data points (t2) after the event to ensure that the size of the data sets and the temporal location of event wi thin the data set are close.

[0107] After each retrieved data waveform is assigned to a thread, an index value of stability analytics is determined for each detected event (e.g., each set of search key data) at 1915. The stability analytics index values may include I _W i _< .¼,, which may represent an event occurring across a wide area of a power system, Ij _ocal , which may represent an event occurring across a local area of a power system, and I _OS cfliarion severity, which may represent the oscillation severit ' associated with the event (as illustrated in Col. 825 of FIG. 8). A process, such as the process 2100 of FIG. 21 may be used to determine these stability analytics index values.

[0108] After the index value of stability analytics is determined for each detected event, an index factor of stability analytics is determined for each thread associated with a candidate event at 1920. The stability analytics index values may include L, winch may represent whether an event occurred recently in time, and I _pmu, which may represent event occurring within a certain group of identified PMUs (e.g., PMUs belong to a particular user.) A process, such as the process 2300 of FIG. 23 may be used to determine these stability analytics index values.

[0109] After the index factor is determined for each thread, a severity value is calculated for each combination of a detected event (e.g., each set of search key data) and a thread at 1925. FIG. 28 discussed below illustrates an example implementation of the combinations of detected events and threads for which severity values may be calculated at 1925. The severity value for each combination may be calculated using the following equation:

[0110] Severity=w _t / _t + w _pmu l _pmu + w _wide I _wide + w _iocal I _iocal +

^oscillation severity oscillation severity?

|01 1 1 ] where w _t , w _pm u, w _W ide, wiocai, and w _OS ciiiation severity are user defined weighting factors.

[0112] After the severity values are calculated for each combination, the

combinations of threads and events are classified into severity categories based on the calculated severity values at 1930. As illustrated by the processes 2100 and 2300 of FIGS. 21 and 23, a lower severity value corresponds with a more severe event. Thus, combinations receiving the lowest values may be categorized as the most severe.

Conversely, combinations receiving higher seventy values may be categories as less severe. However, example implementations of the present application are not limited to this configuration and in other example implementations, a lower severity value may correspond to a lower severity category, and higher severity values may correspond to a higher severity category. [0113] After die combinations have been classified into severity categories, the elements of the combinations (e.g., the thread, and the event) may be visualized at 1935, and similarity analytics may be performed using the process 2500 of FIG. 25 and the process 1900 may end.

[0114] FIG. 20 illustrates another process 2000 for assigning the retrieved data waveforms to different threads to create the multi-threading according to an example implementation. At 2005, a plurality of threads is created. In some example implementations, the number of threads created may be the number of candidates recognized during the single event recognition processes 1500 and 1600 of FIGS. 15 and 16, respectively. In other example implementations, the number of threads may correspond to the number of Central Processing Units (CPUs) available to perform the similarity analytics.

[0115] After the plurality of threads are created, each retrieved data waveform may be assigned to a different thread at 2010. When each retrieve data waveform, is assigned to a thread, set of data that makes up the thread includes a period of data points (tl) before the event and a period of data points (t2) after the event to ensure that the size of the data sets and the temporal location of event within the data set are close.

|01 16] After each retrieved data waveform is assigned to a thread, an index value of stability analytics is determined for each detected event (e.g., each set of search key- data) at 2015. The stability analytics index values may include I _W j _f j _e , which may- represent an event occurring across a wide area of a power system, Ii _ocal , which may represent an event occurring across a local area of a power system, losdiiaUon seventy, which may represent the oscillation severity associated with the event, and I _prr ,„, which may represent event occurring within a certain group of identified PMUs (e.g., PMUs belong to a particular user.) (as illustrated in Col. 825 of FIG. 8). A process, such as the process 2200 of FIG. 22 may be used to determine these stability analytics index values.

[0117] After the index value of stability analytics is determined for each detected event, an index factor of stability analytics is determined for each thread associated with a candidate event at 2020, The stability analytics index values may include I _t , which may represent whether an event occurred recently in time. A process, such as the process 2400 of FIG. 24 may be used to determine these stability analytics index values.

[0118] After the index factor is determined for each thread, a seventy value is calculated for each combination of a detected event (e.g., each set of search key data) and a thread at 2025. FIG. 28 discussed below illustrates an example implementation of the combinations of detected events and threads for which severity values may be calculated at 2025. The severity value for each combination may be calculated using the following equation:

[0119] Severity=w _t / _t + w _pmu ! _pmu + w _wide l _wide + w _local I _local +

^'oscillation severity I oscillation severity?

[0120] where w _t , Wpum, w _W ide, w _ioca i, and _ose iiiation severity are user defined weighting factors.

[0121] After the severity values are calculated for each combination, the combinations of threads and events are classified into severity categories based on the calculated severity values at 2030. As illustrated by the processes 2200 and 2400 of FIGS. 22 and 24, a lower severity value corresponds with a more severe event. Thus, combinations receiving the lowest values may be categorized as the most severe.

Conversely, combinations receiving higher severity values may be categories as less severe. However, example implementations of the present application are not limited to this configuration and in other example implementations, a lower seventy value may correspond to a lower severity categor ', and higher severity values may correspond to a higher severity category.

[0122] After the combinations have been classified into se verity categories, the elements of the combinations (e.g., the thread, and the event) may be visualized at 2035 and similarity analytics may be performed using the process 2500 of FIG. 25 and the process 2000 may end.

[0123] FIG. 21 illustrates a process 2100 for determining index values for stability analytics of each detected event in an example implementation of the present application. For each detected event or received data, a determination is made at 2105 whether the event has been detected as occurring on more than a threshold number of PMUs. In the example implementation of FIG . 21 , the threshold number is 5 PMUs. However, the threshold number of PMUs is not limited to this value and other threshold numbers may be set or selected by a user.

[0124] If an event is detected as occurring on more than 5 PMUs (YES at 2105), iwide is set to equal 1 and I _loc ai is set to equal 0 at 2110, and process 2100 continues to 2120 discussed below. Conversely, if an event is detected as occurring on 5 or less PMUs (No at 2105), I _w j _de is set to equal 0, and Ij _ocal is set to equal 1 at 2115, and process 2100 continues to 2120 discussed below. [0125] At 2120, a determination is made whether the oscillation severity associated with the event exceeds a threshold value. In the example implementation of FIG. 21, the threshold number is 5 PMUs. However, the threshold value is not limited to this value and other threshold values may be set or selected by a user.

[0126] If the oscillation severity associated with the event is equal to or less than 5, (No at 2120), IosciUation se erity is set to equal 1 at 2125 and the process 2100 ends.

Conversely, if the oscillation severity associated with the event is greater than 5, (Y es at 2120), loscfflaUon seventy is set to equal 0 at 2130 and the process 2100 ends.

[0127] FIG. 22 illustrates a process 2200 for determining index values for stability analytics of each detected event in an example implementation of the present application. For each detected event or received data, a determination is made at 2205 whether the event has been detected as occurring on more than a threshold number of PMUs. In the example implementation of FIG. 22, the threshold number is 5 PMUs. However, the threshold number of PMUs is not limited to this value and other threshold numbers may be set or selected by a user.

[0128] If an event is detected as occurring on more than 5 PMUs (YES at 2205), iwide is set to equal 1 and Ii _ocal is set to equal 0 at 2210, and process 2200 continues to 2220 discussed below. Conversely, if an event is detected as occurring on 5 or less PMUs (No at 2205), I _svide is set to equal 0, and Ii _oca i is set to equal 1 at 2215, and process 2200 continues to 2220 discussed below.

[0129] At 2220, a determination is made at whether the oscillation seventy associated with the event exceeds a threshold value. In the example implementation of FIG. 22, the threshold number is 5 PMUs. However, the threshold value is not limited to this value and other threshold values may be set or selected by a user.

[0130] If the oscillation severity associated with the event is equal to or less than 5, (No at 2220), I _OS efflation severity is set to equal 1 at 2225, and the process 2200 continues to 2235 discussed below. Conversely, if the oscillation severity associated with the event is greater than 5, (Yes at 2220), lo _b ulation seventy is set to equal 0 at 2230, and process 2200 continues to 2235 discussed below.

[0131] At 2235, a determination is made whether the event is detected as occurring to one of several PMUs having a specific identifier. In the example implementation of FIG. 22, the specific identifier is an identifier being within a specified range of # 1-10. However, the specific identifier is not limited to this specified range and other specified identifiers may be set or selected by a user. [0132] If the event is detected as not occurring to one of several PMUs having an identifier within the range #1-10, (No at 2235), 1 _PMU is set to equal 1 at 2240 and the process 2200 ends. Conversely, if the event is detected as occurring to one of several PMUs having an identifier within the range #1-10, (Yes at 2235), I _PM u is set to equal 0 at 2245 and the process 2200 ends.

[0133] FIG. 23 illustrates a process 2300 for determining index values for stability analytics of each candidate event or thread in an example implementation of the present application. For candidate event or thread, a determination is made at 2305 whether the event has a timestamp more than a threshold period in the past. In the example implementation of FIG. 23, the threshold period is 2 weeks. However, the threshold period is not limited to this value and other threshold periods may be set or selected by a user.

[0134] If an event is detected as having a time stamp more than 2 weeks old, (YES at 2305), it is set to equal 1 at 2310, and process 2300 continues to 2320 discussed below. Conversely, if an event is detected as having a time stamp less than or exactly 2 weeks old, (No at 2305), I _t is set to equal 0 at 2315, and process 2300 continues to 2320 discussed below.

[0135] At 2320, a determination is made whether the event is detected as occurring to one of several PMUs having a specific identifier. In the example implementation of FIG. 22, the specific identifier is an identifier being within a specified range of #1-10. However, the specific identifier is not limited to this specified range and other specified identifiers may be set or selected by a user.

[0136] If the event is detected as not occurring to one of several PMUs having an identifier within the range #1-10, (No at 2320), IPMU is set to equal 1 at 2325 and the process 2300 ends. Conversely, if the event is detected as occurring to one of several PMUs having an identifier within the range #1-10, (Yes at 2320), I _PMU is set to equal 0 at 2330 and the process 2300 ends.

[0137] FIG. 24 illustrates a process 2400 for determining index values for stability analytics of each candidate event or thread in an example implementation of the present application. For candidate event or thread, a determination is made at 2405 whether the event has a timestamp more than a threshold period in the past. In the example implementation of FIG . 24, the threshold period is 2 weeks. However, the threshold period is not limited to this value and other threshold periods may be set or selected by a user. [0138] If an event is detected as having a time stamp more than 2 weeks old, (YES at 2405), I _t is set to equal 1 at 2410, and process 2400 ends. Conversely, if an event is detected as having a time stamp less than or exactly 2 weeks old, (No at 2405), I _t is set to equal 0 at 24 5, and process 2400,

[0139] FIG. 25 illustrates a process 2500 of performing oscillation stability calculation to the multiple threads. At 2505, machine resources such as CPU or memory are assigned to the threads that have been grouped based on their classification based on the calculated severity values discussed above. For example, in some example implementations, 60% of machine resources may be assigned to process threads that were classified as the most severe category (e.g., lowest value), 20% of machine resources may be assigned to process threads that were classified as the second most severe category (e.g., second lowest value), 15% of machine resources may be assigned to process threads that were classified as the third most severe category (e.g., third lowest value), and 5% of machine resources may be assigned to process threads that were classified as the fourth most severe categor ' (e.g., highest value). However, example implementations are not limited to this configuration and other ratio of division of machine resources may be used.

[0140] After the machine resources are allocated, stability analytics may be performed at 2510 for each combination of a thread and a detected or received event to obtain oscillation analytics such as Frequency (J), Damping (d). Amplitude (A), and weighting factors. These calculations are not particularly limited and may include any stability analytics that may be apparent to a person of ordinary skill in the art.

[0141] After the oscillation analytics results have been determined, a similarity between the detected o d at 2515 using the equat ⁱ on;

[0142] Sinii!anlv

[0143] Where w _t , w _t , and w _t are user defined weighting factors and

[0144] where P is a time series pow er wave form associated with the candidate event of thread.

[0145] After the similarity is calculated for each thread at 2515, the process 2500 ends.

[0146] FIG. 26 illustrates a process 2600 for ranking the candidate events or threads based on the calculated similarity. At 2605, candidates are first grouped or categorized based on the associated severity values. For example, threads having the lowest score may be classified as the most severe category, threads having the second lowest score may be classified as the second most severe category, threads having the third lowest score may be classified as the third most severe categosy, and threads having the highest score may be classified as the least severe category. However, example implementations are not limited to this configuration and other classification schemes that may be apparent to a person of ordinary skill in the art may be used.

[0147] After the candidates are grouped based on their associated severity values, the threads to the different categories may received prioritized threading at 2610. For example as discussed with respect to FIG. 25, computational resources may be assigned based on the severity classifications.

[0148] After the different categories of threads are prioritized based on their associated severity values, the candidates or threads may be compared and ranked within each severity category at 2615, based on a calculated similarity such as the similarity calculations discussed above with respect to FIG. 25.

[0149] After the threads or candidates have been compared and ranked, the candidates or threads having the greatest severity may be visualized or displayed on a UI at 2620. FIG. 29 discussed in greater detail below illustrates an example implementation of a UI that may be used to visualize the candidates having the greatest similarity.

[0150] FIG. 27 illustrates a process 2700 for updating filter table values (e.g. table 600 of FIG. 6) based on a detected ongoing event or a detected historical event recognized during the processes discussed above. At 2705, an event is detected based on detection of outliers in measured data values received from a PMU. Outliers may be detected using, for example, the process 1400 of FIG. 14. After an event is detected, an Item id, and filer values (e.g. Max% value, Base value, and Min% value) associated with the Item_id, are extracted at 2710, Based on the detected event, event detection statistics are calculated at 2715. The event detection statistics may include event duration, event frequency, max event data value, minimum event data value, average event data value, and average difference between event data value and filter value base value.

[0151] At 2720, the event detection statistics are compared to the filter table values and the stored minimum event duration value (e.g., column 705 of table 700 of FIG. 7) to determine if the filter table values and stored minimum event duration value should be updated using machine learning. For example, the calculated event duration is compared to stored minimum event duration value to determine if the stored minimum event duration captures the calculated event. Similarly, the max event data value, minimum event data value, and the average ev ent data values may be evaluated to determine if the e.g. Max% value. Base value, and Min% values should be updated.

[0152] If the filter value table (e.g., table 600 of FIG. 6) or minimum event duration (e.g., column 705 of table 700 of FIG. 7 require an update (YES at 2720), new filter table values or minimum event duration values are updated at 2725 and the process 2700 ends. Conversely, if the filter value table (e.g., table 600 of FIG. 6) or minimum event duration (e.g., column 705 of table 700 of FIG. 7) do not require an update (NO at 2720), the process 2700 ends without an update.

[0153] FIG. 28 illustrates a schematic representation 2805 of an example implementation of combinations of events (2810a, 2810b, 2810c, 2810m) and threads (2815a, 2815b, 2815c, 2815n) that may be used to calculate severity values as used above. For example, a first event 2810a and second thread 2815b may be used to calculation severity value S-l-2. Other combinations of events 2810a-2810m and threads 2815a-2815n may be used to calculated different severity values as may be apparent to a person of ordinary skill in the art. Though example implementations of the present application may analyze multiple events, example implementations are not limited to this configuration and may only analyze a single event.

[0154] FIG. 29 illustrates a user interface (UI) 2900 displaying data relating to an occurring event and at least one retrieved historical event in accordance with an example implementation. As illustrated, the UI 2900 includes a graphical map of the power grid 2905, which might include updates or indicates of areas events are occurring in real time. The UI 2200 also includes a graphical display 2910 of the waveforms associated with an occurring event (E) and at least one candidate event (C) (e.g., a thread) having the highest degree of similarity to the occurring event, with the two wave forms overlaid as illustrated. The UI 2900 may also include an ordered listing 2915 of other events for which candidate events could be identified during either of the processes 1400, 1500 of FIGS. 14 and 15. Further, the UI 2900 also includes a display of a historical action log 2920 of the actions taken during the candidate event associated with waveforms displayed at 2910. Based on the displayed historical action log 2920, an operator can determine actions that should be taken in response to the occurring event. The UI 2900 may also include display parameters 2925 and 2930 indicative of the search parameters (such as Wide area events, age of event, and identifier associated with PMU) that may ^¬ be used to identify oilier candidate events. [0155] FIG. 30 illustrates an example system 3000 upon which example implementations may be applied. The system 3000 can include PMUs 21a, 21b, 21c, 21d, 21e distributed throughout the system 3000. Some PMUs 21a, 21b may connect to monitor generators 101a, 101b (e.g., hydroelectric generators, solar generators, and fossil fuel based generators). Other PMUs 21c may be connected to monitor transformers 102 and regulators 103. Still other PMUs 2 Id may be located to monitor transmission Sines, and electrical buses. Still other PMUs 21b, 21e may be positioned to monitor load devices 104 or local distribution power grids 105.

[0156] Each of the PMUs may be connected to a similar event search system 200 by a communication network 108. Similar event search system 200 is an apparatus that may be in the form of any system in accordance with a desired implementation (e.g., computer, data center, etc.). The similar event search system 200 may be configured to manage a plurality of PMUs in a power system, and can include a physical central processing unit (CPU) 201 , database 206, output interface (I/F) 202, communication processor 203, input I/F 204, and short term memory 205 (e.g. cache) connected by a communications bus 21 1. The CPU 201 may execute one or more flows as illustrated in FIGS. 12-27. The Database 206 may be in the form of one or more storage devices configured to manage data measurements provided by PMUs. Tire Output I/F 202 provide external output to the operator of the similar event search system 200, such as displays, meter gauges, and so on. The communication processor 703 can function as an interface for receiving data from the PMUs through communication network 108 and conducting initial processing. The Input I/F 204 provide interfaces for input from the operator, including keyboards, touchscreens, mouse and so on. The Short term memory 205 can function as a cache for temporary storage of data streamed from PMUs.

[0157] In example implementations, the database 206 may be configured to store measurement data from the one or more PMUs, the measurement data comprising first measurement data including at least one of frequency data and voltage data, and second measurement data such as the PMU data illustrated in FIGS. 4 and 5. The CPU 201 may be configured to, for an instance of the first measurement data being outside a threshold (such as the values illustrated in FIG. 6) identify a corresponding PMU from the one or more PMUs associated with the instance; and capture, based on the instance, a first window of the first measurement data and the second measurement data of the corresponding PMU. The CPU 201 may also be configured to process incoming data from the one or more PMUs. Further, the CPU 201 may be configured to for a second window of the incoming data corresponding to the first window, retrieve the first measurement data and the second measurement data corresponding with the instance; and conduct a comparison between the first window of the first measurement data and the second measurement data, and the second window of the incoming data as illustrated, for example, in the flow of FIG. 13.

[0158] In example implementations, the CPU 201 may also be configured to, for each of a plurality of instances of the first measurement data being outside the threshold (such as tlie values illustrated in FIG. 6), to identify the corresponding PMU from the one or more PMUs associated with each of the plurality of instances, capture a plurality of first windows of the fi rst measurement data and the second measurement data from the corresponding PMU associated with each of the plurality of instances, each of the plurality of the first windows corresponding with one of the plurality of instances, conduct a comparison between each of the plurality of the first windows and the second window of the incoming data, and select a window of the first measurement data and the second measurement data from the plurality of windows based on the comparison between each of the plurality of the first windows with respect to the second window of the incoming data as illustrated, for example, in the flows of FIGS. 14-20.

[0159] The CPU 201 may also be configured to combine two or more instances of the plurality of instances of the first measurement data being outside the threshold into a single instance, based on the two or more instances occurring within a time duration less than a minimum duration (such as the minimum event duration illustrated in column 705 of FIG. 7) as illustrated, for example, in the flows of FIG. 15 ,

[0160] The CPU 201 may also be configured to identify a first PMU corresponding with a first instance selected from the plurality of instances, and a second PMU corresponding with a second instance selected from the plurality of instances; and combine the first instance and the second instance into a single instance based on a distance between the first PMU and the second PMU being less than a distance threshold as illustrated, for example, in the flows of FIG. 16.

[0161] In example implementations, the output VF 202 may be configured to display information to a user or operation. Further, the CPU 201 may also be configured control the output I/F 202 to display a user interface (UI), such as the UI illustrated in FIG. 22. The UI may comprise a graphical representation of the second window of the incoming data; and a graphical representation of the window of first measurement data and the second measurement data selected from the plurality of windows as illustrated, for example, in the flow of FIG. 18.

101621 The CPU 201 may further be configured to capture a log of actions associated with a system user in response to each instance during each of the plurality of windows; and control the display device to display a log of actions taken in response to the instance corresponding to the window of first measurement data and the second measurement data selected from the plurality of windows as illustrated, for example, in the flows of FIGS. 12 and 18.

[0163] The CPU 201 is further configured to conduct the comparison between the first window of the first measurement data and the second measurement data, and the second window of the incoming data, by calculating a similarity value based on differences in data values between the first measurement data and the second measurement data, and the incoming data as illustrated, for example, in the flow of FIG. 18.

[0164] FIG. 31 illustrates a PMU 3100 in accordance with an example implementation. PMU 3100 may include a CPU 3101, memory 3104, sensor array 3102, and baseband processor 3103. Data from sensor array 3102 is streamed to memory 3104 and processed by CPU 3101 to be prepared in a format for use by the receiving apparatus such as similar event search system 200 of FIG. 30. Processed data is then transmitted to the receiving apparatus by baseband processor 3103, which can be implemented as streaming data or batch data.

[0165] Some portions of the detailed description are presented in terms of algorithms and symbolic representations of operations within a computer. These algorithmic descriptions and symbolic representations are the means used by those skilled in the data processing arts to convey the essence of their innovations to others skilled in the art. An algorithm is a series of defined steps leading to a desired end state or result. In example implementations, the steps carried out require physical manipulations of tangible quantities for achieving a tangible result.

[0166] Unless specifically stated otherwise, as apparent from the discussion, it is appreciated that throughout the description, discussions utilizing terms such as "processing," ^" 'computing," ^" 'calculating," ' ^" determining," "displaying," or the like, can include the actions and processes of a computer system or other information processing device that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system's memories or registers or other information storage, transmission or display devices.

101671 Example implementations may also relate to an apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may include one or more general-purpose computers selectively activated or reconfigured by one or more computer programs. Such computer programs may be stored in a computer readable medium, such as a compute -readable storage medium or a computer-readable signal medium. A computer-readable storage medium may involve tangible mediums such as, but not limited to optical disks, magnetic disks, read-only memories, random access memories, solid state devices and drives, or any other types of tangible or non-tra sitory media suitable for storing electronic information. A computer readable signal medium may include mediums such as carrier waves. The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Computer programs can involve pure software implementations that involve instructions that perform the operations of the desired implementation.

[0168] Various general-purpose systems may be used with programs and modules in accordance with the examples herein, or it may prove convenient to construct a more specialized apparatus to perform desired method steps. In addition, the example implementations are not described with reference to any particular programming language. It can be appreciated that a variety of programming languages may be used to implement the teachings of the example implementations as described herein. The instructions of the programming language(s) may be executed by one or more processing devices, e.g., central processing units (CPUs), processors, or controllers.

[0169] As is known in the art, the operations described above can be performed by hardware, software, or some combination of software and hardware. Various aspects of the example implementations may be implemented using circuits and logic devices (hardware), while other aspects may be implemented using instructions stored on a machine-readable medium (software), which if executed by a processor, would cause the processor to perform a method to carry out implementations of the present application. Further, some example implementations of the present application may be performed solely in hardware, whereas other example implementations may be performed solely in software. Moreover, the various functions described can be performed in a single unit, or can be spread across a number of components in any number of ways. When performed by software, the methods may be executed by a processor, such as a general purpose computer, based on instructions stored on a computer-readable medium. If desired, the instructions can be stored on the medium in a compressed and/or encrypted format.

[0170] Moreover, other implementations of the present application may be apparent to those skilled in the art from consideration of the specification and practice of the teachings of the present application. Various aspects and/or components of the described example implementations may be used singly or in any combination. It is intended that the specification and example implementations be considered as examples only, with the trae scope and spirit of the present application being indicated by the following claims.