REQUIREMENTS FOR AUTOMATED FAULT AND DISTURBANCE

DATA ANALYSIS

Mladen Kezunovic*, Texas A&M University

Tomo Popovic, Test Laboratories International, Inc.
Donald R. Sevcik, CenterPoint Energy
Aniruddha Chitambar, Entergy Services, Inc.
U.S.A.

This paper gives an overview of future requirements for fault and disturbance analysis.
Special attention is given to the issues of the extent of analysis, data integration, information
exchange, speed of processing, database needs, dissemination of analysis results and related
user interface, and support through existing and new standards. Selecting implementation
options and moving towards more integrated solutions are discussed and supported with a
summary of the existing relevant standards as well as the need for defining new ones.
Examples of the most advanced solutions deployed by the utility companies are given as well.
Keywords: Fault, Disturbance, Digital Fault Recorder, Automated Analysis, Power Quality

1. INTRODUCTION
Fault and disturbance analysis is typically based on digital fault recorder (DFR) systems. Due
to evolving needs and requirements, a given utility may acquire a variety of DFR system
solutions and/or upgrades over a period of time. This paper gives an overview of requirements
for a universal approach to fault and disturbance analysis where a variety of DRFs from
different vendors are merged into one solution. Special attention is given to the issues of the
extent of the analysis, data integration, information exchange, database needs, dissemination
of analysis results and related user interfaces, and support through existing and new standards.
The extent of the analysis is the most critical issue when considering automating the analysis.
What is a reasonable level of automating the analysis tasks taking into account the
complexity of the software and cost of maintaining are discussed in a separate subsection.
Data integration and information exchange are two most important implementation issues. It
is noted what are the possible recording devices that may be considered as the sources of data
for the analysis as well as who may be the potential user of the results of analysis. The issues
associated with integrating data coming from diverse recording devices and the possibilities
of using the results by various utility groups are elaborated on.
Speed of automated processing is yet another rather important implementation requirement. It
is pointed out that the speed of operation requirement depends on the final users of the results
and their ability to act quickly as a consequence of receiving the results in a timely fashion.
*
Mladen Kezunovic, Texas A&M University, College Station, TX 77843-3128, U.S.A.
This requirement translates into the data processing architecture requirement deciding
whether the data is processed at the substation or at the centralized location.
Organization of databases is also very important when considering the need to provide both
the waveform records and results in an easy to follow display. Retrieving the historical data
and making quick searches of stored data by various criteria is presented.
One of the main differences in the new requirements versus the old ones is the ability to share
the recorded data and results of analysis with a number of individuals within the company
using the standard Intranet services. The need to design the automated analysis systems to
comply with the internal IT standards of the utility companies is considered a very important
requirement.
Last but not least, the discussion indicates that the new requirements need to be matched by
appropriate standards. A summary of the existing relevant standards as well as the need to
define the new ones is elaborated in a separate section.
The final part of the paper reflects on the requirements of the most advanced solutions
deployed by the utility companies co-authoring this paper.
2. REQUIREMENTS FOR AUTOMATED ANALYSIS
Automating the analysis of the fault and disturbance data is based on an idea to use an expert
system based solution. Such systems should be able to process the information on signal
waveforms and contact changes obtained from substations through Intelligent Electronic
Devices (IEDs) such as DFRs, Sequence of Event Recorders (SERs) and Digital Relays. Since
the first application of expert systems to fault analysis was reported in mid-eighties, a number
of solutions have been proposed [1]-[3]. A fully integrated and automated solution is yet to
come [4]. The requirements for an integrated system for automated fault and disturbance data
analysis are identified and described in the following subsections.
2.1. Extent of the Analysis
The scope of the analysis has the following general goals [5]:
Detection and classification of the fault or disturbances
Verification of the correctness of the protection system operation
Calculation of fault location and other important parameters (resistance, duration, etc.)
The event analysis should be triggered by an occurrence of the new DFR record. The analysis
system should process each DFR file individually. For a single DFR file, the analysis is
conducted for each circuit being monitored by that particular DFR.
An example of the conceptual model of the substation as seen by the system for automated
analysis is shown in Fig. 1. Primary object of the analysis is a circuit (transmission line,
generator, etc.). An example of a breaker-and-a-half scheme is also depicted in Fig. 1. The
system must support single-breaker and ring-bus scheme as well.
To achieve the goals, the analysis should rely on two sets of signals: analog and digital.
Analog signals should generally be used for fault detection, classification, and location
calculation, while digital signals should be used for the analysis of the protection system
operation [6]. Prior to being passed to the expert system, analog signals must be processed to
extract a set of parameters used by the expert systems rules. If we take line currents, for
example, one should extract the measurements for the pre-, fault, and post-fault values for a
particular event. One typical approach is to use phasors obtained using one-cycle DFT
algorithm. To be able to analyze events on a particular circuit, all three phases of line currents
(or two phases+zero seq.) should be monitored. Of course, voltage parameters should be used,
too. If the voltage measurements are not available, the analysis system can use the voltage
from some other reference taking into account the transformer ratio (if needed). Digital
signals in the preprocessed form should be used as well.
 67
Line
Status BUS #1

Backup 52 Bus Breaker

52 52

Trip TCF Tran. Remote 52 Middle Breaker

TCF Rec. Substation
21 TC Tran.
Current TC Rec.
52

BUS #2

Voltage

Fig. 1. An example of one line-diagram and the bus-breaker arrangement

Each substation needs to be equipped with one or more IEDs that will provide monitoring of
all important signals. For analog signals, it is recommended to monitor all three phases as well
as the residual for both voltages and currents. For digitals, it is recommended to monitor as
many as possible of the signals related to protection circuits such as primary and backup relay
trip, breaker open and close position, breaker failure, carrier start and receive contacts etc.
2.2.Data Integration and Information Exchange
Each substation needs to be equipped with at least one communication channel (e.g. telephone
line with modems, Ethernet, etc.) enabling easy access to IED data. Communication has to
provide an ability to query IEDs for presence of new data as well as to enable quick data
transfer.
Various schemes for collecting data from IEDs may take place. Typically, there is a need for
vendors software to be running continuously and collecting event data automatically. There
are two typical setup configurations: 1) auto-poll, when master station software polls IEDs
and downloads new data; 2) auto-call, when IED initiates uploading of new data to master
station software. An alternative option is to have third-party products for direct
communication with and automated data collection from IEDs. This alternative solution may
be hard to maintain because of variety of transfer protocols, native IEDs file formats etc.
All the IED data needs to be converted to COMTRADE file format according to the most
recent version of the standard, prior to any further processing [7-9]. A standardized approach
to file naming should take place as well [11]. This issue will be discussed in more details in
the next section. Collecting event data and performing file format conversion need to be a part
of the fully automated analysis that is typically triggered by the occurrence of new incoming
IED data.
Integrated system needs to be compatible with the PC configuration running Windows
operating system and capable of using available communication and network protocols as
well as web technologies for intensive data exchange.
2.3. Organization of Databases
It is recommended to provide a centralized database system. The database system should
contain two main types of information: 1) system components information; 2) event data and
analysis reports.
System should support handling descriptions and important information on system
components being monitored. Examples of such parameters are: transmission line and circuit
breaker names, line length, line impedances, relation between signals and objects, etc.
The IED data (once converted to COMTRADE), together with the analysis reports and
additional available information, should be automatically stored into a centralized database.
The database should allow an easy access and retrieval as well as advanced features for
searching. Besides, live data such as IED recordings and analysis reports, the database has
to contain the system configuration data used to describe various components.
2.4.Dissemination of Analysis Results
System needs to provide the means for automated dissemination of both DFR data and
relevant additional information such as analysis reports, component parameters etc. System
should provide automated file copying over corporate Intranet for the archival purposes as
well as sending notifications and reports using emailing, faxing, paging and/or printing
services.
2.5. User Interfaces
System needs to provide tools for searching, accessing, and viewing DFR data, analysis
reports as well as the system configuration data. All the user interface tools need to be
universal and enable viewing the information in the same way regardless of the origin and
type.
The implementation of user interfaces should gradually be moved towards use of modern web
technologies. Users should be able to navigate through the event tables and specify search
criteria in order to quickly locate events of interest. User interfaces, implemented as web
applications, should also provide means for detailed inspection of the waveforms and analysis
reports.
In addition to DFR data and analysis reports, user interface should provide the means for
accessing and configuring the system component information (parameters describing
transmission lines, circuit breakers etc.).
Besides the obvious benefits of accessing the database using web application through the
corporate Intranet, there is a benefit of easier maintenance. The web application, typically
stored only on the server computer and users workstations, does not require installation of
any software except the web browser that is typically a part of the operating stem.
2.6. Implementation Options
A system for automated analysis must provide options to be configured in several different
ways to match various system requirements and to serve the various needs of different users.
For example, system should be able to support different protection schemes. An
implementation of the system should use modular approach to enable different configuration
options. Examples of systems deployed in the utilities are illustrated in the following section.
3. APPLICATION EXAMPLES
In this section, examples of the advanced solutions recently deployed by the utility companies
co-authoring this paper are described. The presented examples cover three main types of the
implementation options: autonomous, centralized, and distributed.
The solution is based on the suite of software applications that feature client/server platform
[5]. The architecture of the client and server modules is depicted in Fig. 2.

Signal Expert Result Centralized

Analysis System Processing Database

Waveforms
DFR File & Reports Broadcaster
DFR Comm. User
Conversion Services Reports Interface

Client Server

Fig. 2. Client/server architecture of the software for automated analysis

Both client and server applications can be configured in several ways in order to better
accommodate the specific system requirements. The client performs file format conversion,
signal processing and expert system analysis, and delivers waveforms and reports to the
server. The server processes all the incoming client data, broadcasts the reports and
notifications, and finally hosts the web application for interfacing to data and reports stored in
database.
The following building blocks used for describing the application:
File format filters modules for converting native disturbance and event data into
COMTRADE file format.
Signal Analysis module for signal processing and extraction of all the parameters
needed for the analysis.
Expert System module for analysis, classification, and fault location calculation.
DFR Communication module for direct interfacing to DFRs (without master station)
Broadcaster modules that provides services for dissemination of both event data and
analysis reports (fax, email, print, pager, web).
Database centralized database and file repository for archival of event data, analysis
reports, system configuration.
System Analysis module for more elaborate substation and system-wide analysis.
GUI set of user interface applications.
Web server centralized web-based application for Intranet access to event data and
reports.
3.1. Autonomous System CenterPoint Energy
An automated fault and disturbance data analysis system, configured as autonomous
(substation based) system has been installed at CenterPoint Energys South Texas Project
(STP) switchyard for several years. The heart of the system was DFR file analysis software
capable of analyzing events recorded by the local DFR and faxing event reports to various
users [6]. The configuration is shown in Fig. 3.
DFR File Signal Expert Result Local
Conversion Analysis System Processing Storage

EMTP File User

Conversion Interface Fax
Reports

Fig. 3. The old system as it was installed in STP switchyard

In the light of the positive experience, CenterPoint Energy has decided to deploy an integrated
LAN based system solution for automated analysis of events coming from all installed DFRs.
This solution has evolved into a client application as described next.
3.2. Centralized System CenterPoint Energy
A more complex solution that includes most of the implementation issues described in the
requirements section is implemented in this case. In the centralized system, as installed at
CenterPoint Energy, both client and server are installed on a single Windows 2000 server
computer in the central office. There are around 30 Rochester DFRs (~20 TR 1620 and ~10
TR100/2000 units) and two master station computers. First one polls the TR1620 DFRs and
downloads new event records automatically. The second one receives calls and uploads from
TR100/2000 DFRs, which are configured for auto-call. All the DFR data files are
automatically transferred to the server computer that hosts the analysis software.
3.3.Distributed System Entergy Services
Entergy Services deployed a distributed system configuration. It features acquiring event data
from more than a hundred DFRs made by several vendors: Rochester, Hathaway, Mehta-
Tech, E-MAX. The installation is also based on the client/server architecture described in the
previous example. However, this installation covers six regional centers and each regional
center has its own client installation. Master stations software of each vendor takes care of
collecting event data and delivers the event files in native DFR file format to the
corresponding client. The data and reports from each client are then sent to the server in the
centralized office via corporate network.
4. FURTHER INTEGRATION
In this section, a summary of the existing relevant standards and the need for defining the new
ones is discussed.
4.1. COMTRADE file format
The introduction of the COMTRADE file format was the first big move towards the
integration in the field of DFR systems [7]. The new file format is gradually being accepted
by DFR vendors, which opens a door for easier data integration. Most of the vendors are still
keeping their own native DFR file formats or developing new ones and just providing
additional utility programs or commands for exporting data in COMTRADE file format.
Unfortunately, this export-to-COMTRADE feature, in most cases, is not configurable for
automated operation. Also, the COMTRADE format specification allows freedom, to some
extent, on how to provide information inside the files. This leads to situations where different
software packages supporting COMTRADE file format cannot exchange data among
themselves due to the lack of standardized descriptions of the files and signals inside. In
addition to the original COMTRADE standard specification [7], there are the latest IEEE
revision [8] and IEC version [9]. Having three versions currently being widely accepted and
used increases a possibility not to be able to exchange DFR data among different types of
software packages due to incompatibilities among different versions.
4.2. IEEE File Naming Convention
One step further towards more integrated solutions was the introduction of the standardized
IEEE file naming convention for the time sequence data [10]. The proposed convention
defines coded schema for naming the data files. Such file names can enable easier handling of
large volume of files as well as unique file identification since the file name should contain
unique information about the event: date, time, station, company, duration, location, etc. The
naming convention anticipates using only two digits for the year in the date info, but that is
most likely going to be improved to using four digits. Benefits of using this standardized file-
naming schema should encourage vendors of DFR and other IEDs provide the support, which
is not a common feature today.
4.3. Communication Protocols
There is still a lack of a standardized approach to communication protocols. First, the standard
communication channels for DFR systems (examples are RS-232, RS-422/485, Ethernet, etc)
need to be utilized. Then formats for data exchange over the communication channels need to
be defined as well. Having a standardized communication protocols would allow much easier
integration of DFR systems and enable interchangeability of one type of DFRs with another.
Future DFR systems may utilize standards like the one recently proposed by IEC for
substation automation [11]. Unfortunately, at present, we may still be far from that possibility.
4.4. System Objects Description
There is an obvious need for establishing a convention for providing information on
parameters that describe system objects (signals and associated equipment) monitored by
DFRs. The COMTRADE standard allows entering some basic information on system objects
inside the .CFG or .INF files, but to enable automated processing and analysis of the DFR
records, there should be a standardized way of describing monitored system objects. The IEC
substation automation standard and IEEE file naming convention do not address this issue
either.
5. CONCLUSIONS
The paper outlines implementation requirements for an automated fault and disturbance data
analysis. The main topics related to the requirements are the extent of analysis, data
integration and information exchange, database needs, dissemination of analysis results and
related user interfaces. Flexibility in implementation options is a very important requirement,
too. Different configurations of the most advanced solutions deployed by the utility
companies co-authoring this paper are described.
The existence of relevant standards related to IEDs file formats and file naming as well as the
use of LAN connections allow moving towards more integrated solutions. However,
implementation of the existing standards is still not a common practice. At the same time,
there is a lack of the standardized approach to communicating data as well as describing the
parameters for system components. Ideally, any information system dealing with DFR system
files should be able to communicate, read and interpret, and analyze DFR data in the same
manner regardless of the DFR type.
6. BIBLIOGRAPHY
[1] C. Fukui, J. Kawakami, An expert system for fault section estimation using
information from protective relaying and circuit breakers, IEEE Trans. on Power
Delivery, vol. 1, Oct. 1986.
[2] Solveg Mahrs, et. Al., A Knowledge-Based System for Automatic Evaluation on
Disturbance Recordings, Eight Annual Fault & Disturbance Analysis Conference,
Texas A&M University, College Station, Texas, April 1993.
[3] M. Kezunovic, P. Spasojevic, C. W. Fromen, D. Sevcik, An expert system for
substation event analysis, IEEE Trans. on Power Delivery, vol. 8, pp. 1942-1949, Oct.
1993.
[4] M. Kezunovic, T. Popovic, Integration of Data and Exchange of Information in
Advanced LAN/Web Based DFR Systems, GeorgiaTech Fault and Disturbance
Analysis Conference, Atlanta, GA, USA, May 2002.
[5] D. Sevcik, R. Lunsford, M. Kezunovic, Z. Galijasevic, S. Banu, T. Popovic,
Automated analysis of fault records and dissemination of event reports, GeorgiaTech
Fault and Disturbance Analysis Conference, Atlanta, GA, May 2000.
[6] M. Kezunovic, I. Rikalo, C. W. Fromen, and D. R. Sevcik, Expert System Reasoning
Streamlines Disturbance Analysis, IEEE Computer Applications in Power, Vol. 7, No.
2, April 1994., pp. 15-19.
[7] IEEE Std. C37.111-1991, IEEE Standard Common Format for Transient Data
Exchange (COMTRADE) for Power Systems, IEEE Inc., 1991.
[8] IEEE Std. C37.111-1999, IEEE Standard Common Format for Transient Data
Exchange (COMTRADE) for Power Systems, IEEE Inc., 1999.
[9] IEC Std. 60255-24, Common format for transient data exchange (COMTRADE) for
power systems, First Edition 2001-05, International Electrotechnical Commission,
2001.
[10] File naming Convention for Time Sequence Data, Final Report of IEEE Power
System Relaying Committee Working Group H8, 2001.
[11] IEC Std. 61850, Communication networks and systems in substations, work in
progress, International Electrotechnical Commission, [Online]. Available: www.iec.ch