Protective Relays

Power industry deregulation trend and proliferation of digital electronic devices are deeply affecting operations of power utility companies. Engineering departments, in particular, must deal with increasing complexity of existing applications as well as with emergence of new applications. Such an environment, creates many new challenges for protection system engineers. Use of new business model, deployment of microprocessor relays, proliferation of intelligent devices, higher emphasis on power quality and shortage of personnel are among the main ones. As a result, engineers increasingly must rely on use of advanced engineering tools to perform their daily tasks. This paper describes several such tools developed at Texas A&M University's Power System Control and Protection Laboratory.

Over the past years, research and development of digital simulators for relay testing resulted in development of several configurations: a (customized) closed-loop simulator, Kezunovic at al (1), and an advanced low-cost relay-test bench, Kezunovic and Galijasevic (2). Main characteristics of these tools are hardware flexibility, automation of tasks, user-friendly GUI and simple integration with other applications.

Initial research in the area of automated fault analysis resulted in an expert-system, Kezunovic at al (3). After successful off-line testing, the system was installed in a substation of Reliant Energy HL&P transmission system where it has been working since 1995. Subsequently, a new generation of the system was developed to deal with multiple digital fault recorders and to facilitate data archiving. A GUI was also added to streamline system setup and visualization of the results, Kezunovic at al (4). The latest generation of the system was developed to address a need to integrate data analysis, archival and dissemination across the whole system, Sevcik at al (5).

The modeling and simulation of the protection system and its components is the latest tool that was added to our protection engineer's suite. It allows protection engineers to configure their applications in a very simple and efficient way by using the models of power system and relaying system components, Kezunovic and Kasztenny (6). The components are pre-defined and are available in the libraries that can also be enhanced by adding customized components developed by the users. This allows for modeling and simulation of complex power system and protective relaying scenarios including multi-terminal and multi-relay applications. The environment is very flexible and supports interfacing to the outside software packages.

Typically, relay testing is performed using phasor-based methods and conventional test sets. Due to its low cost and simplicity, this method especially suits routine testing aimed at verifying relay settings. However, some engineering tasks may require a more thorough relay evaluation based on transient testing (e.g. selecting a relay for a specific application, verifying the design of a new relay and analyzing the relay misoperations).

To meet the new needs, a variety of digital simulators has been developed. The closed-loop simulator provides very realistic test conditions, but most users cannot afford such a sophisticated tool. An alternative for them is an open-loop simulator, which performs transient testing using test signals simulated/recorded in advance. Many designs have been proposed, but most fail to find the balance between the functionality and the cost. A solution that offers such a balance is described here.

First set of design requirements aims at minimizing the cost and overcoming the limits of existing simulators:

• Simulator computer should be a personal computer (PC) due to its popularity, price and performances.
• Simulator hardware should be interchangeable, and the use of existing test sets is promoted.
• System software should be commercially available and should not require substantial investment.
• Application software should support horizontal and vertical portability across different platforms.

Second set of design requirements was constrained with some specifics of relay test applications:

• The simulator should operate in an open-loop one, but future extension could include real-time mode.
• The simulator should be able to use both recorded (DFRs) and simulated waveforms (EMTP).
• An easy-to-use GUI for test waveform processing and test results visualization must be provided.
• The integration with internal or external transient simulation programs should supported.

This section describes a simulator implemented to comply with requirements defined above (4). The architecture of that simulator is illustrated in Figure 1.

Figure 1: The architecture of the simulator

The hardware architecture allows for interchangeable output hardware. Table I shows technical specification of the two commonly used options (a relay test set and custom D/A converter designed by Texas A&M University).

Table I: I/O HARDWARE CHARACTERISTICS

The main element of the software architecture is the test software called Relay Assistant. Its design incorporates all original requirements through four layers:

• Modules for test creation enable: reading various waveform files (COMTRADE, ATP, MATLAB, native DFR) and creating arbitrary test waveforms.
• Modules for waveform processing enable waveform massaging (cut/paste, copy, crop, insert, rescale, resample, invert, pre-fault extension etc.).
• GUI modules enable user-friendly use of simulator functions (displaying waveforms, reviewing test results, editing test reports, signal massaging, etc.).
• Modules for waveform replaying that include drivers for various supported I/O hardware

Depicts integration with ATP (Alternative Transient Program) and ATPDraw using a special add-on option. The integration is done through the module called BGEN and this enables automated generation and execution of batch sequences consisting of hundreds or thousands of individual tests.

Automated fault analysis can facilitate assessment of the fault clearing and location, thereby enabling timely and appropriate restorative action. Such solutions could provide a detailed system-wide analysis within seconds following occurrence of an event. SCADA systems cannot offer such functions since they lack detailed data on transient waveforms and contact changes. However, thanks to expanding use of Intelligent Electronic Devices (IEDs) such systems can be built utilizing high-speed data communications and advanced software approaches. After the idea of automated fault analysis was originated in mid-eighties, a number of solutions were proposed (4). To the best of our knowledge, system presented here is one of the few to offer fully automated operation mode (5).

Design of the system was mostly constrained by the objective to achieve a high degree of flexibility. This section outlines the most important requirements.

• The same architecture must be configurable for variety of applications and installations
• System must be able to import data from different digital fault recorders (DFRs)
• Analysis must include assessment of the following: fault characteristics, protection system operation and fault location
• Modules for fault event analysis must be universal, intelligent, expandable and interchangeable
• Fault data and report archival and retrieval must be centralized and automated
• Dissemination of the event reports must be both automated and customized
• The system response time must be minimized in each possible installation

New architecture uses client/server paradigm (Figure 3). Client implements data processing and event analysis. Server implements data archival and dissemination of event reports. This architecture is distributed as Clients may reside in different locations (substation, regions, etc.). The architecture consists of: Application Layer, Data Management Layer and Data Presentation Layer. As these layers are loosely connected, it is not required that any particular layer be functional in order for any other layer to function properly. Therefore, no change or problem in the system elements (e.g. adding or repairing a DFR) requires a complete shutdown of the system.

Figure 4 shows the Client in one particular system installation) and details of its operation are given next:

Figure 3: The architecture of the new system

Figure 4: The architecture of Client

• Client constantly queries DFR for new events. When a new event is detected, Client uploads it.
• Client uses embedded file format filters to extract event data from a native DFR file.
• Client performs various signal processing to extract representative parameters of an event.
• Expert system classifies the event. If the event is as a fault, Fault Locator calculates fault location.
• Event report and associated event file are sent to Server for further processing.

Main elements of Data Management Layer are shown in Figure 3. Their functionality is as follows:

• Server Manager constantly monitors the incoming folders for new event reports and files
• Event Parser parses the event report and archives pertinent data into the database
• Database is used for storing both the system (configuration) and event data (files and reports)

The main blocks of the Data Presentation Layer can be also seen in Figure 3. Their functionality is:

• Web Server responds to user queries by retrieving and preparing requested data
• Broadcaster sends data (files, reports, pages) to the users that have requested them
• System wide analysis is performed using the stored events and system data.

The evaluation of a relay is usually performed through testing and advanced test tools may greatly facilitate this effort. In some cases, however, it may be possible to evaluate relay models instead actual relays. Such an approach calls for software tools capable of modeling both the relays and the surrounding power system.

The following are main requirements for development of advanced tools for relay and system modeling.

• Relay Elements: generic relay components must enable one to create various digital relay models
• Relays: usual protective relay models (overcurrent, impedance and differential) must be available
• Protection Systems: modeling complete protection terminals and/or schemes must be possible
• Input Signals: specialized signal generators and file converters must be available

A package developed at Texas A&M University using Matlab and SIMULINK provides such capabilities through five standard component libraries. For example, Relay Element library contains: Data Acquisition Board, Digital Filter, Digital Fourier Transform, Basic Measurement, Differential Equation-Based Impedance Measurement, Universal Comparator, Zone Comparator, Triggering Element, Symmetrical Components and Bias Characteristic.

Using elements from Relay Library, one can quickly model a given relay . Developed models can be made part of existing or new libraries.

Models of protective relays or systems developed using the libraries can be tested with the input signals from one of the following sources:

• signal generators of the Input Signals library
• Power System Blockset of MATLAB
• ATP output files via the developed file converter
• Transient data files via the developed file converter

The results of testing can be seen using waveform display or saved into a file of appropriate format.

This paper points out three types of advanced engineering tools that facilitate the daily tasks performed by protection engineers. The tools include: digital simulators, software for automated fault analysis, and software for relay modeling and simulation. Using these tools the engineers can experience these benefits:

• protective relay operation can be assessed in great detail using digital simulators
• monitoring of the protective relay operation can be facilitated by automating the analysis of DFR recordings
• relay selection and evaluation can be pursued in a very flexible way using the relay models