Experiences of Oscillation Detection and Mitigation in Grid Operations at PEAK Reliability

Abstract

The use of synchrophasor technology in the Western Interconnection began with a collaborative project funded by the US Department of Energy. Various synchrophasor applications and tools were installed under this project. This chapter presents the details of the project and discusses the use of synchrophasor technology for oscillation detection and mitigation in grid operations at PEAK Reliability .

9.1 Introduction

The Western Interconnection Synchrophasor Program (WISP) began with a collaborative project to improve reliability of the Bulk Electric System (BES) in the Western Interconnection.

In 2010, the Western Electricity Coordinating Council (WECC) received $53.9 million in funding from the US Department of Energy (DOE) for WISP. The funding, awarded under the American Recovery and Reinvestment Act’s Smart Grid Investment Grant initiative, matched dollars committed by nine WISP partners to extend and deploy synchrophasor technologies within their western electrical systems. The total funding for WISP was $107.8 million.

Between 2010 and March 2014, WISP installed more than 480 new or upgraded phasor measurement units (PMUs ) in the Western Interconnection. PMUs deliver high-speed synchronized measurements using a secure communication network and software in order to better manage the power grid. Under the WISP project, WECC Reliability Coordinator (RC) installed many state-of-the-art synchrophasor applications and tools, such as

• OSI soft PI for PMU Historian

• V&R Energy ROSE Real-Time Voltage Stability Analysis (RT-VSA) software

• Alstom PhasorPoint platform integrated with Montana Tech developed Modal Analysis Software-MAS 1.0

• Alstom Grid Stability Assessment (GSA) application to transfer synchrophasor application results to EMS

• Alstom OpenPDC and e-Terravision (replaced by other products in 2016).

The new synchrophasor infrastructures and advanced applications enabled RC playing a leadership role in promoting new technologies for visualizing power system disturbances, and minimizing the risk of these disturbances from evolving into a major, system-wide event on the Western BES.

Since WISP’s phase-1 completion in March 2014, RC continued to improve the quality and use of the synchrophasor data it receives. Peak Reliability applied for an additional grant from the DOE for this next phase of WISP, subsequent to the bifurcation of WECC into a Regional Entity (WECC) and a Regional Coordinator (Peak Reliability ). The new DOE grant project is named Peak Reliability Synchrophasor Program (PRSP), which was widely considered WISP 2.0. The PRSP project was budgeted at $12.4 million. It consists of nine partner entities: BPA, CAISO , Idaho Power, NV Energy, PacifiCorp, PG&E, Salt River Project, Southern California Edison, and Peak Reliability .

Through the PRSP project, Peak Reliability plays an important role in the program by housing the PMU registry, MAS 2.0 software enhancement, historical data archives, PMU data accuracy and event data export tools, disturbance reports, linear state estimation , inter-area oscillation mode meters/forced oscillation detection , as well as the wide-area visualization tools.

Peak Reliability currently receives inbound 4000 PMU signals of 412 PMU from 18 WECC utilities. Most of the PMU are down-sampled sent out to SCADA . Hundreds of down-sampled PMU voltage phasors are enabled in EMS state estimation solution.

The oscillatory characteristics of power systems due to cyclic load variations were first uncovered in mid-1960s [1]. Since the 1990s, BPA has been one of pioneering utilities in development and implementation of system modal oscillation detection technology using high-resolution PMU signals in collaboration with Montana Tech, University of Wyoming, and PNNL et al. research institutions [2,3,4]. In the last decade, forced oscillations in power systems are caused by external sources such as cyclic loads and control failures in generation power plant. The identification of these forced oscillations has been challenging for the industry. Because of increase in PMU visibility, there is significant work being done in detecting and locating forced oscillations [5,6,7,8,9]. Thanks to advancement of PMU -based oscillation detection technology over the last decades, now more utilities are moving forward to implement real-time oscillation detection applications in control room settings.

In the following sections, we will focus on Peak Reliability experience in implementation of inter-area mode meters, forced oscillation detection , and source locating.

9.2 Overview of Montana Tech MAS Tool

Peak Reliability currently utilizes the GE-Alstom PhasorPoint integrating MAS 1.0 for real-time system oscillation monitoring in Production. The MAS tool, including Oscillation Detection Module (ODM) and Mode Meter Module (MMM ), was developed by Dr. Dan Trundnowski from Montana Tech University and Dr. John Pierre from the University of Wyoming. Peak Reliability MAS engine inherited most key features of BPA custom MAS tool that was developed and improved over the last decades [2, 3].

9.2.1 Mode Meter Functionality

The mode meter is designed to accurately track a known system mode. This purpose is different than detecting and estimating all system modal activity. The research focus for this type of tool is accuracy, and therefore, much effort has been expended in assessing and refining the most appropriate numerical and signal processing method for a known system mode under different stimulus conditions. For example, a numerical method that provides excellent accuracy while the system is being excited from a known external input may not represent the best algorithm when “probing” is turned off. In another example, an algorithm that performs well under low damping conditions may not provide the best accuracy under high damping conditions. The mode meter incorporates an expert system that selects the numerical algorithm delivering the best accuracy for the current system conditions.

The mode meter delivers a “mode estimate” as its result. The primary components of the mode estimate are estimates of the frequency, damping, energy, and shape of the system mode. Frequency and damping estimates can be used in conjunction with one another to assess system “stress”. Operating rules can be put in place that, when used in conjunction with system topology information, can direct system operators to reconfigure flows. Below is a list of Western inter-area oscillation modes widely recognized.

Peak Reliability successfully integrated MAS 1.0 into GE-Alstom PhasorPoint (PP) product for real-time mode meter validation and monitoring in Prod (NS modes A and B) and Test (All known modes) (Fig. 9.1).

Fig. 9.1

GE-Alstom PhasorPoint/MAS displays

Oscillation Detector Functionality: The oscillation detector is designed to rapidly detect oscillation energy in input signals. The research focus is speed, and therefore, much effort has been expended in assessing the fastest filtering algorithms that will accurately compute oscillatory energy. The oscillation detector is intended to be used for broad system coverage. Most often, the oscillation detector will be used operationally to detect forced oscillations . Forced oscillations are more common, in normal power system operations, than oscillations resulting from undamped natural modes. Most forced oscillations are not a threat to bulk grid stability, but early detection of forced oscillations can help system operators/dispatchers to assess which of their generation assets may be experiencing pre-failure characteristics. For example, if an operator can be alerted of a forced oscillation at a given power plant, they may be able to start thinking about how they will reconfigure the system if that power plant trips in the next few minutes.

The primary output of the oscillation detector is oscillation energy in four broad frequency bands. The four broadbands help simplify the output for system operators, and the four bands can often be used to quickly find the source of a forced oscillation. The oscillation detector also provides, in its “Spectrum” output, finer frequency resolution of oscillation energy. We expect that the “Spectrum” output will be most often used by engineers in offline analysis, while the four broadbands described below will be most often used in operations.

• Band 1, with a passband of 0.01–0.15 Hz, monitors very slow oscillations that typically involve speed-governor controllers. The response time is 200 s or less.

• Band 2, with a passband of 0.15–1.0 Hz, is tuned to oscillations typically observed in the electromechanical oscillation range. The response time is 12 s or less. Most of known inter-area oscillation modes are within Band 2, including

• Band 3, with a passband of 1.0–5.0 Hz, is typically associated with local electromechanical modes and generator controls. The response time is 6 s or less.

• Band 4, with a passband of 5.0 Hz to Nyquist, may be associated with torsional dynamics of a generator, for example, or may be related to voltage or other relatively high-speed controllers.

Early versions of the Band 1 filter implemented in BPA showed false alarms for ramp conditions on the Pacific HVDC Intertie (PDCI). A new version of the Band 1 filter has been designed to reject ramps to avoid the false alarms.

MAS Analytics

The oscillation detection (ODM) algorithm is an “RMS Energy Filter” as derived and described in [2] and is shown in Fig. 9.2. This extends a classic energy detector [3] to multiple frequency bands. A PMU -derived “Input” signal (e.g., active power or voltage magnitude) is formed and passed thru a bandpass (BP) filter that focuses on the desired bandwidth for oscillation detection . After BP filtering, the signal is then squared, passed thru an “Averaging Filter”,” and then square-rooted. The goal of the “Averaging Filter” is to estimate the mean of the squared signal and is matched to the BP filter. The resulting output signal will be an estimate of the RMS of the input signal in the bandwidth of the BP filter. A similar approach was used at BPA in the late 1990s for event detection.

Fig. 9.2

RMS energy filter in oscillation detection application

The RMS energy filter approach has several distinct advantages as an oscillation detection algorithm [2]. Firstly, the BP filter can be designed to focus on a specific desired frequency range. Secondly, it provides useful engineering units for the output, that is, the total RMS content in the signal. Though it is often convenient to use units of peak-to-peak value of the oscillation energy when visually examining time-domain waveforms during an oscillation event, the RMS value is a more accurate and consistent measure. Lastly, it is not dependent on the oscillation having a single frequency; many oscillations have multiple frequencies (e.g., harmonics).

Four different RMS energy filters are implemented for the operation control application. The response time is the max time the RMS energy filter takes to respond to an oscillation.

MAS 2.0 Enhancements: With PRSP funding support, Dr. Dan Trundnowski and Dr. Matt Donnelly upgraded the MAS from version 1 to version 2 with many software improvements. The highlights are:

• (1) An inverse time alarm (ITA) module is added. The ITA returns two Boolean outputs, “Alarm” and “Alert”. The ITA is user-configurable to accept a single frequency band from a single OD as its input. For example, four ITA analytics must be configured for each OD if the user wishes to alarm on all four frequency bands of an OD. The parameters of the inverse time curve follow standard industry practice and are user-configurable.

  Figure 9.3 contains a depiction of the inverse time curve capability. For any frequency band, the ITA will post an ALERT if oscillation energy exceeds the A0 threshold and remains above the A0 threshold for T_D0 s. If the oscillation energy and time duration in the band acting as the input to the ITA cross to above and to the right of the curve, the ITA will post an ALARM. It can be seen by examining the curve that the ITA will enter the ALARM state quickly if there is high energy in the band acting as the input to the ITA and more slowly if there is low energy.

  Fig. 9.3

  

  RMS energy

• (2) The mode meter has been significantly enhanced in MAS 2.0 by allowing for multiple input signals. In previous versions, a single instance of a mode meter could only accept one input. Users wishing to track a specific system oscillatory mode through multiple inputs needed to establish multiple mode meters. The problem with this approach comes in trying to determine which of the several result sets is most accurate for given system conditions. With multiple inputs, MAS 2.0 incorporates a decision structure that automatically excludes invalid data points. If one PMU stops reporting, MAS 2.0 is still able to provide accurate results from the other valid inputs.

• (3) A transparent and public API was developed to facilitate incorporating the MAS 2.0 engine into online environments. Two significant features of the API are the logging framework described above as well as clearly defined.NET configuration objects and configuration validation . The configuration information is passed to the engine in the form of a.NET object complying with an interface specification. The API was vetted by Peak in the design stage and has proven to be very flexible. The API has been successfully integrated into a commercial streaming synchrophasor service as well as into two separate offline analysis environments.

• (4) A different numeric engine for MAS 2.0 was chosen. The MAS 1.0 software used an “unmanaged” numeric library. The use of “unmanaged” code in V1 resulted in one instance of a memory leak and required the design team to use a third-party interface library. The MAS 2.0 software uses 100% “managed” code which should provide users with a greater degree of confidence with respect to memory management.

• (5) A set of tools making use of the MAS 2.0 engine was developed in MATLAB for offline analysis. The offline tools parse COMTRADE data files, provide the user with a sufficient degree of plotting and presentation capability, and are designed to facilitate automation. For example, the user can save configurations and run the stored configurations repetitively on any number of COMTRADE data sets. The offline tools use the same API approved by PEAK for the online engine. Therefore, the offline tool will provide results identical to the online version.

• (6) A new derived signal type “Angle” as the raw angle of a synchrophasor input was created.

• (7) A list of multiple derived signals can be used as inputs to a mode meter . The design team added logic that discards input signals with unusable content and uses the remaining input signals for multi-input mode meter processing. The goal is to provide a slightly more accurate answer, but more importantly to allow users to configure a mode meter with multiple inputs such that the mode meter automatically drops bad inputs. The alternative with v1 was to configure multiple independent mode meters.

• (8) There is an additional “Spectrum” output for each band of the OD. The “Spectrum” output returns a scaled FFT of the energy content of the input signal within the band of interest. For example, the “Spectrum” output for Band 2 returns a spectrum from 0.15 to 1.0 Hz. The width of the frequency bins for the FFT is user-configurable. The benefit of the Spectrum output is better resolution of the primary frequency contributing to the oscillation energy in a given band. This feature adds lots of data to the result stream. It is anticipated that users will only retrieve the Spectrum output when the OD is in an alarm condition. It is anticipated that the “Spectrum” output will be most often used by engineers in offline analysis, while the four broadbands will be most often used in operations.

• (9) The Band 1 filter was redesigned to reject ramps typical of routine operational re-dispatching of generating resources. Previously, the Band 1 filter would show significant energy content during a ramp and this was causing some false positives.

• (10) The Band 4 filter was redesigned to extend to the Nyquist rate of the underlying derived signal input. Previously, the Band 4 filter had a cutoff at 15 Hz. This was appropriate for 30 sps PMU inputs but it unnecessarily limited the usefulness of the Band 4 output when PMUs with 60 sps or 120 sps capabilities were used.

Peak has started to validate MAS 2.0 for offline system oscillation event analysis . The integration of MAS 2.0 into real-time application platform is under evaluation.

9.3 Peak’s Experience with MAS Mode Meters (MMM)

BPA uses the same Montana Tech MAS tool as Peak in Real-Time, and a comparison of the real-time results was conducted to make sure Peak’s PhasorPoint (PP) MAS MMM tool function as expected.

Results Comparison—Peak versus BPA

Several key dates of MAS MMM results are compared in the following sections, including PDCI trip event, brake test, and some normal days.

PDCI Trip Event on April 28, 2015:

On April 28, 2015, around 6:06 a.m. PDT, Pacific DC Intertie (PDCI) tripped. Both Peak’s and BPA’s MAS tool were running during that time. The NS mode A and B frequency and damping are compared and shown in Figs. 9.4 and 9.5.

Fig. 9.4

PDCI trip event MAS Mode Meter NS mode A results comparison—peak versus BPA

Fig. 9.5

PDCI trip event MAS mode meter NS mode B results comparison—peak versus BPA

As mentioned in the previous section, there is a difference in results of the second NS mode A, the second signals used for BPA is the angle difference between Malin and Chief Joseph, instead of Custer and Captain Jack. Chief Joseph PMU measurements were not configured in Peak’s PP yet during the test period. The results match pretty well through pre-disturbance, during the disturbance, and post-disturbance.

By comparison of the damping variations during the event, PDCI trip event impacts NS mode B more than NS mode A. In Fig. 9.5, there is a clear difference in both the frequency and damping results during the disturbance and post-disturbance.

Since the signals used (Big Eddy and John Day) are really close to the DC intertie, during the disturbance, the signals are impacted by the disturbance a lot and thus may not provide actual estimation of modal frequency and damping. For the PDCI event, the fault is really close to Big Eddy and John Day, the PMU locations. If the PMU signals are used to estimate the mode, the results could be biased.

Post-disturbance situation, the results between Peak and BPA are quite different. Prior to performing modal analysis using MAS tool, BPA has a bad data check. It clearly shows in both frequency and damping results which BPA’s MAS tool stopped calculating for a while and restarted. Around 7:00 a.m., Peak and BPA’s results match again.

Brake Test: June 17, 2015:

BPA performed the brake test on June 17, 2015, at 9:14, 9:24, 15:14, and 15:24 PDT. The results comparisons (Peak Loveland and Vancouver Production versus BPA) are shown in Figs. 9.6 and 9.7 for the morning brake test.

Fig. 9.6

Brake test—NS mode A results comparison—peak versus BPA

Fig. 9.7

Brake test—NS mode B results comparison—Peak versus BPA

In Fig. 9.5, it clearly shows that using the angle difference between Chief Joseph and Malin, the results are quite different than using other signals. The rest of the results matches pretty well. It also shows that the brake test does not impact NS mode A damping that much.

In Fig. 9.7, the results among Peak Loveland and Vancouver Production servers and BPA are almost the same. The brake test impacts the NS mode B damping a lot. At around 9:14 a.m. when performing the first brake test, the NS mode B damping dropped from ~12 to ~8%.

Normal Operation Day: June 16, 2015:

A normal system day which is June 16, 2015, is picked to compare Peak’s and BPA’s MAS tool results, as shown in Figs. 9.8 and 9.9. The results of Peak Loveland and Vancouver servers match BPA results.

Fig. 9.8

June 16, 2015 NS mode A results comparison—Peak versus BPA

Fig. 9.9

June 16, 2015 NS mode B results comparison—Peak versus BPA

Fig. 9.10

Block diagram of WSU OMS tool

Based on the results presented above, Peak PhasorPoint MAS Mode Meter application provided consistent results with BPA’s MAS tool while monitoring NS mode A and NS mode B in Real-Time. Since mid-2015, Peak PhasorPoint MAS Mode Meter has been up running in Production environment for monitoring modes A and B in real time. The other inter-area modes have been configured in test server for validation test till date.

Future work is still needed which includes baselining of Mode Meter results to correlate modal frequency, damping, and shape with system conditions, the validation of the rest of the known WECC inter-area modes (Figs. 9.11, 9.12, 9.13 and 9.14).

Fig. 9.11

User interface of WSU OMS Tool—Real-time dashboard

Fig. 9.12

User interface of WSU OMS tool—history viewer

Fig. 9.13

User interface of WSU OMS tool

Fig. 9.14

User interface of WSU OMS tool

9.4 Forced Oscillation Detection and Analysis at PEAK

Forced oscillations occurred in WECC system. Usually they are caused by abnormalities in unit excitation and governor systems. They were characterized by

• Very low damping (near zero)

• High-energy and unknown modes

• A clear peak in power spectral density.

BPA was the first Western utility using MAS tool-oscillation detection application to locate a large number of oscillation events in real time since the tool was implemented in 2013. Most of the events were local forced oscillations due to equipment issues or bad operating point summarized below [2, 3]:

• Wind Power Plant Oscillation (in bands 3 and 4) due to the problematic wind turbine voltage controller.

• Hydro Power Plant Rough Zone Oscillation (in band 2): Hydro turbines are designed for most efficient operation at nominal head and flow. Hydrodynamic instability (rough zone operation) occurs at partial load, typically 25–60% of rated generator power. Multiple sustained oscillations were detected at the hydro power plants, while the hydro units were continuously operated in a rough zone. Hydro power plant rough zone oscillation is very undesirable because mechanical forces cause premature wear of equipment or even catastrophic damage.

• Hydro plant oscillation due to interactions between power system stabilizers (PSSs) and under-excitation limiters (UELs) (in bands 3 and 4): The oscillation occurred in 2015. That year was a low hydro generation year in the Pacific Northwest, as a result, transmission voltages were high due to lighter transmission loading, and fewer generators were available to absorb the increased reactive power. The oscillation problem was resolved successfully after BPA technical staff re-tuned the UEL gains later.

• Large Power Plant Active Power Oscillation (in band 1) due to issues with an interface between a plant controller and a generating unit’s governor.

• Central Oregon Plant Oscillation (in band 3) as a result of the plant control system being supplied an erroneous measurement from its local meter. The wires terminating at the meter had been poorly crimped and generated enough heat to start a fire. The plant operator powered down the unit in response to the fire, and the sustained oscillation stopped 5 min later.

• Generator oscillations because of transmission outages (in band 2): Those oscillation events usually clear in 5–10 min, mainly by taking oscillating generators offline.

• PDCI high energy oscillation (mainly in bands 3 and 4) due to equipment failure at converter stations.

From the above oscillation events detected by BPA, forced oscillation is usually caused by local generators operating abnormally. Unlike system oscillation modes that are usually well-damped, forced oscillation shows up as a sustained oscillation and can damage power plant equipment. It will be present in the grid until the underlying problem is corrected.

Through DOE CERTS project [10], Peak first adopted Washington State University (WSU) offline Oscillation Monitoring System (OMS) software for oscillation event analysis in 2015. Then, we installed WSU online OMS tool at Peak engineering laboratory and kept it running since May 2016. The objective of WSU online OMS tool is to provide real-time oscillation monitoring results in the system. OMS tool is a group of custom action adapters in OpenPDC. OMS results include oscillation frequency, damping ratio, modal energy, confidence level, and mode shapes.

Along with that, WSU also provides two C sharp.net-based user interface applications which allow us to visualize real-time and historical OMS results. Real-time visualize tool allows us to monitor power system oscillation stability in real time to enhance control room situation awareness. And the historical visualization tool enables us to review oscillation events and perform post-event analysis. Peak EMS Network Applications team has been testing the software and expanding use cases within engineering laboratory environment [11].

WSU OMS Tool Framework

WSU online OMS tool has three OpenPDC custom action adapters. They are FFDD, EVENT, and HISTORIAN. The input of OMS is real-time streaming PMU data in c37.118 format. OMS gets the data through OpenPDC. The output of OMS (oscillation frequency, damping ratio, modal energy, confidence level and mode shapes) is saved as OpenPDC measurements which allows us to publish them directly into PI data system just as what we did with raw PMU measurements. The results can also be saved as csv files in local drive.

The FFDD adapter is the engine for damping monitor based on Fast Frequency-Domain Decomposition algorithm. This is the one that outputs continuous results for every 10 s. The EVENT adapter would be switched in if it detects an oscillation event. The type of results from EVENT adapter is the same as in FFDD adapter. HISTORIAN adapter saves all FFDD, and EVENT adapter results into OpenPDC Historian.

WSU OMS Tool Highlights

Comparing to Montana Tech MAS tool, the main benefits of WSU OMS tool are:

• (1) It uses a much shorter time window (1–5 min) comparing to 20–30 min time window used by MAS Mode Meter . Shorter time window means the engine could react and detect much faster to oscillatory system changes.

• (2) Unlike Mode Meter which requires user to specify input signals and frequency bands for each mode, WSU tools simply uses all available PMU signals in OpenPDC to analyze. In this way, it can capture more oscillation modes than Mode Meter , especially for forced oscillation modes .

• (3) It automatically detects bad PMU signals and excludes them from oscillation analysis. It estimates the confidence level for each detected oscillation mode, e.g., higher confidence level, more creditable oscillation detection results.

• (4) OMS results can be directly saved into PI data system which is easier for baselining studies.

• (5) WSU OMS tool is self-reliant, e.g., unnecessary to be integrated into another vendor platform such as GE-Alstom PhasorPoint.

Since WSU OMS tool and Montana Tech MAS tool use different algorithms, different inputs, and different setting parameters, it is not very meaningful to compare their damping results directly. But, overall, results from both engines meet each other in a closed range for most cases.

WSU OMS Tool UI Features

The WSU OMS tool Real-Time Dashboard allows users to monitor system oscillation in real time. It provides trend charts for oscillation frequency, damping ratio, modal energy, and confidence level for each mode it detected (up to 4 modes at one time). Users can detect poorly damped modes in real time by using this tool.

WSU OMS tool saves oscillation results in two forms. The first one saves results directly into OpenPDC historian, and the other one creates daily csv files in the local drive. It has provided two user interface API to view each kind of historical results. The OMS History Viewer pulls results directly from OpenPDC historian and plots them into trend charts for user to review.

There is another visualization tool which could load csv files to perform analysis review.

In the example below, we can see NS mode B was poorly damped for about 3 h. By using this tool, we can better learn the behaviors of these system dominant modes.

WSU FFDD Tool for Forced Oscillation Detection

An oscillation event (denoted Event 1) occurred on January 27, 2015, in western interconnection power system. It has been detected during offline studies using Fast Frequency-Domain Decomposition (FFDD) algorithm [13].

As shown in Fig. 9.15a, the oscillation started at approximately 11:00 a.m. and lasted till about 11:40 a.m. according to FFDD analysis of the WECC PMU data. Analysis window length for FFDD was 180 s which was updated every 10 s in a moving window formulation [8]. The mode frequency was at around 1.12 Hz with a low damping ratio below 1%. Figure 9.15b shows the average mode shape for the 1.12 Hz oscillation of Fig. 9.15a. The mode shape pointed to an area with low PMU coverage consisting of more than 50 generation substations. The presence of the forced oscillation can be clearly seen in the line current measurement from one of the PMUs in Fig. 9.15c. Although the oscillation magnitude is small, the FFDD algorithm [13] can detect it well as shown in the summary plot Fig. 9.15a.

Fig. 9.15

Detection of the forced oscillation using FFDD

In order to identify the specific source of the forced oscillation, three-hour SCADA data (9:30 a.m. to 12:30 p.m.) recorded from over 2000 generators in western interconnection power system was used for analysis. The discussion in this paper assumes the oscillation source to be a generator, while similar analysis can be applied for load sources as well.

Because of the vast amount of SCADA data, even with the indication from mode shape results, it took several weeks to identify the oscillation source through the manual search process. Subsequently, the oscillation event motivated Peak to work with WSU team for development of efficient methods for locating the source of forced oscillations automatically from among thousands of SCADA signals.

Use of SCADA Data for Source Location

Both WSU OMS and Montana Tech MAS tools have allowed engineers to detect oscillation issues that may have previously gone undetected. Although such an oscillation can be flagged and its mode shape can indicate the general vicinity of its source, low penetration of synchrophasors means that a specific generator or load that is the root cause of an oscillation cannot easily be pinpointed. Fortunately, SCADA serves as a much more readily available telemetered source of data if only at a relatively low sampling rate of 1 sample every 1–10 s. According to Nyquist criterion, this low sampling rate would be too slow for analyzing typical forced oscillations that occur in the frequency range of 1–5 Hz. However, since the SCADA measurements are not time-synchronized, the asynchronous sampling does preserve the oscillation amplitude to a great extent which can be exploited.

Through the DOE CERTS project, Peak collaborated with WSU to design and employ an online forced oscillation detector and source locator. Real-time WSU damping monitor results (oscillation frequency, damping ratio, and confidence level) are used to detect a forced oscillation. When a forced oscillation of significant energy is detected in the PMU data, the source locator would then pull the corresponding MW and MVAR SCADA data for all the generators in the Western Interconnection. Two algorithms are then used to find the source of oscillation by analyzing the generator SCADA data. For multiple recent oscillation events, the new developed methods were successful in correct identification of the oscillation source which was confirmed in each case by discussion with respective generation plant owners.

Unlike the high sampling rate PMU data, the SCADA system only provides data from generators and substations every 1–10 s. Measurement and collection of SCADA data are not time-synchronized. Therefore, SCADA data has been first interpolated like a synchronized stream of data with one sample every 10 s. The sampling rate then becomes 0.1 Hz which suggests that the corresponding Nyquist frequency is 0.05 Hz. It is impossible to analyze a forced oscillation at 1.12 Hz of Event 1 with such low sampling rate data using any existing signal processing technique.

Another challenge in using SCADA data is that the signals are recorded with different resolutions (tenth of MW or MVAR for some channels, and one MW or MVAR for some channels). Moreover, the sensitivities of the signals vary a lot in different areas of the system. Therefore, some of the signals can be very noisy, whereas others may remain unchanged for long periods.

Two methods that can handle all these practical issues are proposed in this section. Purely from the very large number of generators in a large power system, it is very difficult to identify the oscillation source effectively while avoiding false alarms. For this purpose, the two slightly different methods can be used to reinforce the ranking of possible source locations.

The start time and end time of the forced oscillation need to be known from a PMU -based oscillation detection engine such as by using FFDD of [13] before applying these two methods to the SCADA data. The time window in between the start and end times of oscillation detection will be referred to as the oscillation window for the rest of the paper. Non-oscillation time period is accordingly referred to as the ambient window. The oscillation window of Event 1 in Sect. 9.2 is from 11:00 a.m. to 11:40 a.m.

In order to properly distinguish from a generator which shows oscillating characteristics within the oscillation window versus another generator that has these characteristics throughout the entire data set, an initial ambient window is needed for baselining. Both methods will compute the ranking index $K \in \Re^{n}$ for all the generator outputs, where n is the number of channels.

A. Pattern Mining Algorithm (PMA)

To begin with, the data goes through a pre-screening process (denoted the data sanity check) to ensure that the generator is in use and there is some minimum variation within the output for the set. The channel whose maximal output is less than 10 MW or MVAR, and the one whose maximal difference for the entire data set is less than 1 MW or MVAR is ignored.

Next, a 25-point median filter is applied for detrending. The absolute values of the differences between the raw measurements and the filtered data, denoted the detrended data, can be used as a measure of the oscillation activity as seen in the SCADA signal. When an oscillation occurs, the amplitude of the differences during the oscillation window should be relatively higher than the amplitudes during the ambient window. Accordingly, a threshold is needed in order to rule out small differences. The threshold (denoted the 3σ threshold) is set to be three times the standard deviation of the detrended data in the ambient window.

This method then counts the number of the high-amplitude peaks in the raw measurements whose detrended values are outside the 3σ threshold in the oscillation window, denoted NUM _osc , and in the ambient window, denoted NUM _amb . In this context, the amplitude of the peaks is ignored per se. The ranking index of each channel is then formulated as,

$$ K_{PMA\_i} = \frac{{NUM_{osc\_i} }}{{Length_{osc} }} - \frac{{NUM_{amb\_i} }}{{Length_{amb} }},\;\quad i = 1,\;2,\; \ldots ,\;n, $$

(9.1)

where Length _osc and Length _amb represent the lengths (total number of samples) of the oscillation and the ambient windows, respectively (Table 9.1).

Table 9.1 Western inter-area oscillation modes

In order to determine relative ranking between the generators, the main steps of the pattern mining algorithm are summarized as below.

• (1) Input SCADA data of generators and the oscillation event time as detected by FFDD using PMU data.

• (2) Data sanity check.

• (3) Apply the median filter and subtract the median filtered data from the raw data for detrending.

• (4) Calculate the absolute values of the differences between the raw measurements and the filtered data.

• (5) Reject the channel if the maximal absolute value of the differences is less than 1 MW or MVAR.

• (6) Count NUM _{osc_i} and NUM _{amb_i} .

• (7) Compute the ranking index K _{PMA_i} based on (1).

• (8) Apply step 2–7 for the rest of channels.

• (9) Select top 3 (user-configurable) channels based on the ranking index.

• (10) Inspect the MW outputs of the possible oscillation sources for manual verification.

Event 1 from Sect. 9.2 is analyzed using the pattern mining algorithm. The three highest ranked possible sources are listed in Table 9.2, and Fig. 9.16 shows their MW outputs. In Fig. 9.16, the actual MW plots of each generator are presented on the left side of each subplot. The right side of the subplots shows the values of the detrended data. The red horizontal line in the right subplot of Fig. 9.16 depicts the 3σ threshold for this data set. The inflection points above this 3σ threshold are marked in red circle, and they contribute to the counts NUM_amb and NUM_osc in the ambient and oscillation windows, respectively.

Fig. 9.16

MW outputs of the three highest ranked generators using PMA

The pattern mining algorithm selects generators 1085, 1088, and 1087 as the potential candidates for the oscillation source according to Table 9.2. Observable oscillations can be seen from all three MW outputs during the oscillation window. However, generator 1085 has a ranking index two times that of the indexes for the other two. Indeed, higher-amplitude oscillation activity can be seen in generator 1085 MW output in Fig. 9.16a compared to the MW outputs in Fig. 9.16b, c.

B. Maximal Variance Ratio Algorithm (MVRA)

The same data sanity check as in the pattern mining algorithm is first applied. The data is then detrended using a third-order bandpass filter. For the 0.1 Hz sampling rate (10 s SCADA update rate), the corner frequencies are set to be 0.005–0.035 Hz for the bandpass filter. Then, the MW (or MVAR depending on the nature of the oscillation) output of the generator causing the oscillation is expected to show sustained oscillation (like in Fig. 9.15) with the highest “amplitude” among all such signals.

Two key factors are considered when calculating the ranking index K _MVRA in this approach. One is the number of times the data values cross their mean value within the oscillation window N _osc , which indicates how much the MW data is showing sustained oscillations . The other one is the average standard deviation of the SCADA signal, which is a measure of the oscillation amplitude.

In order to accommodate the slow sampling rate of the SCADA data, we suggest estimating the oscillation amplitude by taking an average of standard deviations from multiple moving windows. That is, let us first compute the standard deviation σ₁ of a defined analysis window, say 30 samples (5 min). And then move the analysis window along the time axis with a fix step, say 6 samples (1 min). Next, calculate the standard deviation σ₂ of the new window. Keep moving the analysis window and computing the standard deviation σ _i (i = 3, 4,…) until the end of the data.

The initial ambient window is set to be the first 20 min of the data set (9:30 a.m. to 9:50 a.m.). The moving standard deviations are calculated over both the initial ambient window and the oscillation window, and the averages of the moving standard deviations for the two windows are denoted as STD _amb and STD _osc , respectively.

This moving window approach can be used to extend the algorithm toward online implementation in the future. STD _amb can easily be estimated in online framework from routine ambient SCADA data that is available all the time. Then, once a sustained oscillation is detected by a PMU -based oscillation detection algorithm such as FFDD in [13], if the oscillations persist long enough (say longer than 5 min), the corresponding SCADA data during the oscillation time period can be used to estimate STD _osc from SCADA data.

The ranking index for each signal is defined as

$$ K_{MVRA\_i} = N_{osc\_i} \frac{{STD_{osc\_i} }}{{STD_{amb\_i} }},\;\quad i = 1,\;2,\; \ldots ,\;n. $$

(9.2)

It is noted that K _{MVRA_i} will become very large when STD _{amb_i} is too small. This can happen for the generators which were off during the window and for SCADA signals with low resolution or low sensitivity . Such signals that remained mostly unchanged during the initial ambient window will be excluded with Filter 1. For example, Fig. 9.17a shows a generator MW output whose STD _{amb_i} is zero, so that its K _{MVRA_i} in (2) is infinity.

Fig. 9.17

Example of signals ruled out by different filters in MVRA

The second check is for the moving variance STD _{osc_i} of the signal during the oscillation window. Low value of STD _{osc_i} suggests there was mainly ambient activity (not oscillations ) in the MW data during the oscillation window. Such generators are not candidates to be oscillation sources and can be omitted from further analysis. An example of such a signal is shown in Fig. 9.17b, which will be ruled out by Filter 2.

As a next example, the signal in Fig. 9.17c has a high STD _{osc_i} value because of many spikes in the oscillation window even though the oscillation activity amplitude is relatively small. In our experience, forced oscillations tend to be sustained with high amplitude over the entire oscillation window (like in Fig. 9.16a) for the potential oscillation sources. Therefore, generator outputs like in Fig. 9.17c with many spikes will be ruled out from the analysis with Filter 4. This example in Fig. 9.17) is from another oscillation event which will be introduced in Sect. 9.4.

Filter 4 rejects the channel whose crossover number N _osc is too small. For example, the generator output in Fig. 9.17d ramped up and down during the oscillation window. Because of the MW ramp, it has a high moving standard deviation STD _{osc_i} . However, the generator can also be excluded because it did not show much oscillations during the time window of interest.

Detrending using a bandpass filter noted in the beginning of Sect. 9.3, and a clipping limiter have been applied in order to remove the slow trends of the signals and to reduce the effect of sudden data spikes, respectively.

The main steps of the maximal variance ratio algorithm are summarized below.

• (1) Input SCADA data of generators and the oscillation event time from FFDD analysis of PMU data.

• (2) Data sanity check.

• (3) Calculate the average of the moving standard deviations for the initial ambient window. Reject the channel if the maximal difference of the data during the window is less than a preset multiple of the average standard deviation (Filter 1).

• (4) Calculate the average of the moving standard deviations for the oscillation window. Reject the channel if this average standard deviation is less than the minimum oscillation threshold (Filter 2).

• (5) Detrend using the bandpass filter.

• (6) Reject the channel if the number of spikes inside the oscillation window is no less than the spike count threshold (Filter 3).

• (7) Apply the clipping limiter for the oscillation window.

• (8) Count the number of times the data values cross their mean value within the oscillation window N _{osc_i} .

• (9) Reject the channel if N _{osc_i} is less than a preset factor of the number of samples inside the oscillation window (Filter 4).

• (10) Recalculate the moving standard deviations over both the initial ambient window and the oscillation window for the filtered data, and compute the average STD _{amb_i} and STD _{osc_i} for the two windows, respectively.

• 11) Compute the ranking index K _{MVRA_i} according to (2).

• (12) Apply step 2 to 11 for the rest of channels.

• (13) Select top 3 channels based on the ranking index.

• (14) Inspect the MW outputs of the possible oscillation sources for manual verification.

The maximal variance ratio algorithm is applied to Event 1 in Sect. 9.2. Three generators with the largest ranking index values are listed in Table 9.3, and their MW outputs are plotted in Fig. 9.18.

Fig. 9.18

MW outputs of the three highest ranked generators using MVRA

According to Tables 9.2 and 9.3, same three generators have been selected by both methods, and the channel generator 1085 stands out from the rest of the channels.

Table 9.2 Possible sources identified using PMA

Table 9.3 Possible sources identified using MVRA

Table 9.4 Possible sources identified using PMA

Table 9.5 Possible sources identified using MVRA

C. Validation

The results from two methods mostly agree with each other. And, generator 1085 is located in the area where the mode shape results in Fig. 9.15b pointed to. In fact, the PMU channel with the largest magnitude in mode shapes is the one closest to generator 1085.

The findings have been verified by discussion with the owner of the generation station. A mechanical failure occurred on the particular generation unit we identified, which caused the forced oscillation in the system. The second- and third-ranked generators 1087 and 1088 are two other units in the same generation plant, and they were responding to the forced oscillation in unit 1085. Therefore, they likely had the next highest amplitudes after unit 1085. In conclusion, the ranking by the two methods PMA and MVRA has correctly identified the source of the forced oscillation from over 2000 generators in the system using SCADA data.

Other Oscillation Events

The proposed methods have been applied to two other oscillation events found in western interconnection power system for validation .

D. Event 2 on January 28, 2015

The same oscillation discussed in Event 1 on the next day which serves as the second validation case. Estimation results of PMU data using FFDD [13] are provided in Fig. 9.19. The oscillation returned from around 12:00 p.m. to 2:20 p.m. with an oscillation frequency at 1.11 Hz, and the damping ratio was again estimated to be very low at 1.0%. The mode shape shown in Fig. 9.19b was similar to that of Fig. 9.15b, and it pointed to the same area of the system as in Sect. 9.3. The SCADA data from 11 a.m. to 4 p.m. was pulled from the historian, and the two methods proposed in Sect. 9.3 are applied.

Fig. 9.19

Detection of the second forced oscillation using FFFD

Fig. 9.20

MW outputs of the three highest ranked generators using MVRA

E. Event 3 on March 10, 2015

The third oscillation event was detected on March 10, 2015, which propagated through a major portion of the western interconnection power system.

Figure 9.21 provides the estimation results of the FFDD engine from [13]. It shows that an oscillation was detected from around 11:02 a.m. to 11:07 a.m. The mode frequency was at 1.47 Hz and the damping ratio was very low as 0.34%, which indicated that a possible forced oscillation had occurred. In this event, since there was no PMU close to the oscillation source, there were dozens of PMU channels whose magnitudes were relatively large in the mode shape results in Fig. 9.19b. The oscillation can be clearly seen in the time plot of a line current magnitude from a PMU shown in Fig. 9.21c. Compared to the two previous oscillation events discussed earlier in the paper, this case is more challenging because the oscillations lasted only about 5 min. The 5-min oscillation window consists of only 30 SCADA data points at the 10-s sampling rate.

Fig. 9.21

Detection of the third forced oscillation event using FFDD

To apply the two algorithms of Sect. 9.3, SCADA data from 10 a.m. to 12 p.m. was extracted from the historian and the ranking indices of Sect. 9.3 were estimated. The three highest ranked possible oscillation sources identified using PMA and MVRA are summarized in Table 9.4 and Table 9.5, respectively. Their SCADA generation outputs are shown in Figs. 9.22 and 9.23.

Fig. 9.22

MW outputs of the three highest ranked generators using PMA

Fig. 9.23

MW outputs of the three highest ranked generators using MVRA

Generator 1215 has been identified as the most likely cause of the forced oscillation by both methods. The generator owner has confirmed that a control problem occurred during the time period of the forced oscillation which validates the findings from the two proposed methods. It appears that the third-ranked generators in both methods look a little suspect, and they may be unrelated to the oscillation event at generator 1215. However, both methods are able to correctly identify the oscillation source, generator 1215 in Figs. 9.22a and 9.23a. They also correctly point to the next highest ranked unit, namely generator 2278, which is clearly reacting to the same oscillation event as shown in Figs. 9.22b and 9.23b.

F. Computational Times

The computational times for source locations of all three events using both methods are summarized in Table 9.6. They are reported from tests using MATLAB 8.1 on a workstation with Intel Xeon CPU E5-2650 v2 @ 2.60 GHz and Windows 7 operating system. All the times in Table  9.6 are well below the SCADA update rate of 10 s which indicates that the two methods can be extended for online implementation in the future.

Table 9.6 Computational time (s)

Wide-Area Oscillation Resonance Event on September 5, 2015

On September 05, 2015 , Peak real-time MAS Engine (Montana Tech) detected very low damping on the NS ‘B’ mode under normal operation conditions:

• No topology changes (quick)

• No gen/load/tie-line flows drop (slow)

When further analyzing the real-time Mode Meter results for NS mode B, a low damping about 2% for a period of ~ 30 min was identified as shown in Fig. 9.24. There is no major system changes such as topology, generation, load, tie-line flows during that time. The results were verified using WSU DMO tool shown in Fig. 9.25. Using the PMA tool, it is shown in Fig. 9.26 that a generator in Mid-America region is the likely source of the forced oscillation. The cause of the oscillation was verified with the generator owner which was a faulty combustion turbine MW transducer. There are two MW transducers for this unit, and the control logic uses a select logic of the two values to control the output to a MW set point. Of course if the measured output is incorrect or oscillating, then the control system attempts to correct to the set point and there will be real output swings.

Fig. 9.24

September 05, 2015 event—real-time Mode Meter results

Fig. 9.25

FFDD analysis of September 05, 2015

Fig. 9.26

September 05, 2015 event—DMO versus MAS results

Fig. 9.27

September 05, 2015 event—PMA results

Fig. 9.28

September 05, 2015 PMU validation of the oscillation source

Peak engineer ran PMA and MVRA algorithm to identify the source unit of the forced oscillation.

PMU validation for MW flow on a line nearby confirms the actual oscillation start/end times are 6.35–6.45. WSU FFDD tool detects the oscillation start/end times are 6.37 and 6.46, which is very close to what is found from PMU signal.

The mode shape plot in Fig. 9.29 clearly shows the source of the oscillation.

Fig. 9.29

September 05, 2015 event—mode shape

The significance of this event is the forced oscillation (~ 6 MW) resonance with the 0.4 Hz NS mode B which showed up on a major intertie in the Western Interconnection for ~ 40 MW as shown in Fig. 9.30.

Fig. 9.30

September 05, 2015 event—Intertie MW flow

Fig. 9.31

September 05, 2015 event analysis results with FSSI

Fig. 9.32

RT-FODSL data flow diagram

Fig. 9.33

RT-FODSL data flow diagram

In this event, MAS tool and WSU FFDD tools gave false alarms of low damping on NS mode B. In a frequency-domain simulation, an oscillation that appears at a frequency that is very close to that of another mode, it can “trick” the program into thinking that there is low damping on the inter-area mode. Control room need to know the difference between a “false alarm” due to a forced oscillation and an actual low damping event is a problem [8, 10]. Then, an operator could take actions where none is needed. Actual low damping on inter-area modes is usually caused by either light loads, high intertie flows, or forced outages, which need to be checked when a low damping alarm is received. To deal with the complexity of forced oscillation resonance issue, Peak was able to distinguish two different modes and confirm the resonance using WSU FSSI successfully [14]. Meanwhile, we used PMA algorithm to locate the source unit correctly.

9.5 Conclusion

PMU -based oscillation detection tools can detect occurrence of forced oscillations in power systems. They can provide a clear indication of the time window when the oscillations were present and related information such as frequency, damping ratio, and the mode shape. Although mode shape results can point to a specific area of the system that might cause the problem, they are often not conclusive enough. Further investigation is needed in order to locate the particular source of the oscillations .

In this section, SCADA data is used for automatic source location of forced oscillations for the first time. It is not straightforward to use SCADA data by itself to detect the oscillations due to its slow sampling rate and high noise level. However, this paper shows that SCADA data becomes extremely useful for source location when combined with oscillation monitoring results from PMU data.

Ongoing Oscillation Detection Work

In later 2016 Peak started a pilot project in collaboration with WSU team. The project aimed to use WSU damping monitor results to detect forced oscillation and then pull all generator’s MW/MVAR SCADA data around the oscillation time to determine the source of the forced oscillation. PI database is used to provide both WSU damping monitor results and SCADA data for the engine. And eventually, the results will be sent back to the PI database and be ready to be presented in a geographic wide-area visualization tool. By such forced oscillation detection tool, RC can contact the generator owner to report and confirm the issue and develop a resolution if the oscillation causes any reliability issue.

This new tool targets to be deployed in engineering laboratory by mid-2017 for daily monitoring by Network Applications engineers. The architecture of the integrated real-time forced outage detection and source locating (RT-FODSL) is described below.

A GIS-based overview to present in Fig. 9.33 to include two major executable components:

• (1) Forced Oscillation Detector

  • Start/end time, oscillation frequency, damping ratio, oscillation energy, confidence level

  • Average normalized mode shape, length = magnitude, east = 0 degree angle

• (2) Oscillation Source Locator

  • PMA result (red), MVRA result (white)

  • Area = ranking index

A few recent oscillation events were detected successfully by RT-FODSL (initial version). Peak team continually works on the tool development and tuning under WSU’s support. Currently, the tool is still under development and fine-tuning in Peak engineering laboratory. Ultimate goal is to deploy the tool in control room for system oscillation monitoring and source locating [12].