Standard Data Formats for Disturbance Analysis

Alexander Apostolov
OMICRON electronics

Introduction
The August 2003 blackout in the North-East and the European disturbance in 2006 demonstrated
that the analysis of different electric power system events is a very important and extremely
complex process. It is required in order to determine the cause of the abnormal system condition,
to speed-up the restoration of the affected parts of the system, and to evaluate the performance of
different protection and control systems. System events and the effect they have on deviations of
the supply voltage may result in failure of sensitive equipment with significant economical
impact. To better understand the effects of different parameters of the power supplied to sensitive
customers, it is necessary to provide engineers with the right tools to allow them to establish the
correlation between the combination of certain attributes of the power and the failure of
equipment.
The integration of multifunctional intelligent electronic devices (IEDs) from different
manufacturers in substation protection, automation and control systems requires a significant
effort due to the different formats of the data available from these devices. Measurements, status,
event, disturbance, maintenance or configuration data is used at different times by different
applications. The paper discusses the requirements for a common data format for all these
different types of data in order to allow the development of tools that will simplify the
engineering and analysis process in electric utilities.
At this time the only common format that can be used for analysis of event data is IEC 61850,
but it covers only a couple of the requirements listed above and is also used only by devices that
support the standard. There are ongoing activities in the IEEE PES Power Systems Relaying
Committee working on the establishment of common data formats not only for IEC 61850 based
devices and systems, but also for any IED with communications capabilities.
The paper introduces the ongoing work on the following common data formats:
• IED configuration data
• IED event reports
• Sampled values based records
• Substation configuration description
• File naming convention
• IED naming convention
The use of all these standard data formats for disturbance analysis is described in the second part
of the paper.

Analysis of IED Operation

The analysis of protective relays operation is based on the different reporting functions in these
IEDs. They include:
• Event reports
• Fault records
• Waveform records
In many cases the fault records are included in the event report.
At the same time in order to determine if the relay operated as expected, it is necessary to know
what exactly the relay settings at the time of operation were.
The distribution of the fault currents and their magnitude at the time of a short circuit fault also
have an impact on the operation of protection devices. That is why the analysis needs to consider
the electric power system and substation topology at the time of the event.

Fig. 1 Relay operation analysis process

The experience from the analysis of many relay operations and system disturbances demonstrates
that one of the main problems (other than IEDs that are not time-synchronized) is the fact that all
the data available from different devices and tools is in proprietary formats that requires
significant effort to convert to a common format in order to perform the analysis. Usually this
processing of records and data is done manually, which slows down the process and can also lead
to errors that may affect the results from the analysis.
In order to improve the analysis process and create an environment supporting the development
of automatic fault and relay operation analysis tools, the industry has been working for years on
the standardization of reporting, recording and configuration data.

IED Configuration Data Standardization

The description of the functionality of protection devices for many years has been based on the
IEEE C37.2 standard that assigns function numbers to substation devices. The problem with this
standard is that it has been designed in the twentieth century with electromechanical devices in
mind and focused primarily on the representation of substation (including protection) functions
on a drawing.
The complexity of the protection functions in modern IEDs and their different possible states that
need to be understood during the process of relay analysis can not be modeled using IEEE C37.2.
IEC 61850 has made a significant progress in the definition of standard description of the
functionality of protection IEDs. The fact that any protection function element is represented by a
logical node (see an example of an overcurrent protection element represented by logical node
PTOC in Figure 2) that can have a Started and Operated state, as well as different modes,
associated measurements, settings, etc. allows the detailed description of the behavior of a
multifunctional protection IED under abnormal system conditions.

Fig. 2 PTOC (Protection Time Overcurrent) logical node data model

The IEEE PES Power System Relaying Committee understood the need for standardization of
the modeling of IED configuration data and started a working group – H5a - in the Relay
Communication subcommittee with the task to define a common data format for relay
configuration.
The work of this working group concentrated on the definition of the distance function model,
since it was considered as the most complex function in a protection IED. The idea was to get a
consensus in the industry that the function that can be implemented in many different ways by
different relay manufacturers, can be represented using a common model and file format. Once
this report is published, a new working group will be formed with the goal to complete the
models of all remaining protection functions and develop the standard file format to exchange the
settings between relay configuration software and different tools used by protection engineers in
the analysis of relay operations.

Fig. 3 Model of polygon distance characteristic defined by IEEE PES PSRC WG H5a

The file format will be based on XML and the substation configuration language as defined in
IEC 61850 Part 6. This will allow the import and export of the settings for any multifunctional
protection IED (they do not need to be IEC 61850 compliant in that case) in a common format
that can be imported into an event analysis tool for the automatic analysis of a protection or other
system operation.

IED Event Reports

Event reports are available from any multifunctional protection IED and have been used for more
than twenty years. They are typically in the form of a record available in the memory of the relay
that can be viewed from the front panel or can be extracted locally or remotely using the IED
communications capabilities.
The format of the event reports are different for the different manufacturers, which makes it
difficult to process in automatic fault analysis tools.
IEC 61850 made the first significant step in the development of data models and services that
define standard reporting that can be used in automatic event analysis.
Event reports in IEC 61850 are based on Report Control Blocks. They control the procedures
required for reporting values of event data from one or more logical nodes to one client. Instances
of report control are configured in the IED at configuration time.
IEC 61850 defines two classes of report control:
• Buffered Report Control Block (BRCB)
• Unbuffered Report Control Block (URCB)
Buffered Report Control Blocks are used for sequence of event purposes. They define internal
events (caused by trigger options data-change, quality-change, and data-update) that issue
immediate sending of reports or buffer the events for transmission. This prevents from data being
lost in case of loss of connection.
Unbuffered Report Control Blocks are quite similar to the BCRB. However they don’t buffer the
data, so event information may be lost in the case of communication problems. Obviously the
unbuffered report control block does not support sequence of events reporting in case of loss of
communications.

Fig. 4 IEC 61850 reporting services

The only problem with the use of the reports described above is the fact that they are available
only from IEDs that support IEC 61850. That is why the IEEE PES Power System Relaying
Committee understood the need for standardization of the event reporting and started a working
group – H5b - in the Relay Communication subcommittee with the task to prepare a Report on a
Common Data Format for IED Event Data.
The report defined a common XML-based file format for describing and exchanging event data
records collected from power systems. It addressed the fact that protection relays and other IEDs
store in their memory historical event data. The main categories of event data considered in this
report were:
 • Sequence of events (SOE)
• Fault reports
• Summary reports
• IED Status
• other
The content and the format of the data recorded are vendor specific and therefore cannot be
easily integrated in a power network post analysis tool.
The main purpose of this file format is to facilitate power systems event data integration and analysis by
enabling event data exchange between multiple data sources from different vendor devices and vendor-
independent analysis tools.

Fig. 5 Event data exchange process

The report was completed and published in 2008. A new working group (H16) was started with the task to
define a new standard IEEE PC37.239 Standard Common Format for Event Data Exchange
(COMFEDE) for Power Systems.

Sampled Values Based Records

During the 2008 Georgia Tech Fault and Disturbance Analysis Conference Benton Vandiver
presented the results from the IEEE PSRC Working Group H5-c Report on a Common Data
Format for IED Sampled Data.
This report presented different methods of sampling data in modern IED’s. Three standards were
identified and reviewed, COMTRADE - IEEE Std C37.111-1999, PQDIF - IEEE Std 1159.3-2002 and
IEC-61850. The different data formats, types and attributes to the corresponding standards were
compared. Different possible conversions of sampled data between the different standard formats were
presented for consideration. Recommended changes to the COMTRADE standard were made in order to
harmonize these data between the three standard formats. The recommendation of this working group was
that consideration be given to formally harmonize these standards in the next revision of COMTRADE
and also to adopt the XML format for self-description of data and file verification. Finally, after that
revision is prepared, to have a new working group that will develop a guide for loss-less conversion
between these standards for the industry at large in order to support automatic fault analysis.
Advantage should be taken of the definition of the fault and disturbance recording model that defines a
standard naming for the different analog and binary channels based on the standardized names of data
objects and attributes defined in different parts of the IEC 61850 standard.
Figure 6 shows a simplified block diagram of the logical nodes used to model the different
components of the waveform recording function.
The status of the breakers in the substation is modeled using the XCBR logical node. It will
provide information on the three phases or single-phase status of the switching device, as well as
the normally open or closed auxiliary contacts. Pxxx is used to indicate any protection functional
element whose status is recorded in the waveform record. RDRE is the logical node representing
the acquisition functions for voltage and current waveforms from the power process (CTs, VTs),
and for position indications of binary inputs. Calculated values such as frequency, power and
calculated binary signals may also be recorded by this function if applicable. RDRE is used also
to define the trigger mode, pre-fault, post-fault etc. attributes of the disturbance recording
function, as shown in Table 1.

TCTR
RADR
TVTR

Pxxx RDRE

XCBR RBDR

Fig. 6 Logical Nodes for waveform recording

The logical node class RADR is used to represent a single analog channel, while RBDR is used
for the binary channels. Thus the disturbance recording function is modeled as a logical device
with as many instances of RADR and RBDR logical nodes as analog and binary channels are
available.
The sampled values from TCTR and TVTR are directly used as analog signals by the waveform
recording function.
Any disturbance recording device has to be configured to perform this function. The available
configuration parameters in a specific device are mapped to the mandatory or optional data
objects in the different disturbance recording related logical nodes described above.
Fig. 7 Mapping to disturbance recording LN

Figure 7 shows the mapping of the different configuration parameters of a disturbance recording
function in a protection relay to the RDRE, RADR and RBDR logical nodes defined in parts 5
and 7 of IEC 61850.

Substation Configuration Description

In order to analyze the operation of a relay, we need to know the substation topology and the
association of the individual IEDs with the primary equipment in the substation. IEC 61850
defines the substation configuration description file that supports standardized description of the
substation primary and secondary equipment that can be used for automatic fault and disturbance
analysis.

Fig. 8 Simplified UML diagram of the substation configuration language

IEC 61850 defines four types of files required to support the intended engineering process. In
order for an IED or a system solution by a manufacturer to be compliant with the standard, they
have to support the use of the files described below directly from the IEDs or through tools
delivered with the system.
System Specification Description
The description of the system is the first step in the engineering process and until now has not
been based on any standardized approach. The IEC 61850 engineering process envisions the use
of substation specification tools that allow the user to describe the substation design and
associated functional requirements for the substation protection and automation systems.
The data exchange from such a system specification tool and other tools utilized in the process
should be based on the System Specification Description files defined in the standard. They have
an SSD extension.
The SSD file describes the single line diagram of the substation and the functional requi9rements
represented by logical nodes. The logical nodes can be abstract in the sense that they are not
allocated to specific IEDs.
IED Capability Description
The default functionality of an IED in the substation configuration language is represented by the
IED Capability Description (ICD) file. It is used for data exchange from the IED configuration
tool to the system configuration tool.
This ICD file describes the capabilities of an IED. It contains exactly one IED section for the IED
whose capabilities are described. Since it represents the default functionality (i.e. before it has
been configured), the IED name in this file is TEMPLATE.
The file also includes the different logical node types as they are instantiated in the device.
The file extension shall be .ICD for IED Capability Description.
IEC 61850 does not specify where the ICD file comes from. In IEDs designed for IEC 61850
environment and with large memory, this XML file may be available from the device itself.
For IEDs that are based on existing platforms that were adapted to support the standard, the
manufacturer is required to provide tools that output ICD files.
Substation Configuration Description
The configuration of the system is represented by the Substation Configuration Description
(SCD) file. It contains:
• substation description section
• communication configuration section
• all IEDs
The IEDs in the SCD file are not anymore in their default configuration, but as they are
configured to operate within the substation protection and automation system. These files are
then used to configure the individual IEDs in the system.
Configured IED Description
The difference between the IED Capability Description (CID) file and the Configured IED
Description file is that the second includes the substation specific names and addresses instead of
the default ones in the first.
The CID file represents a single IED section of the SCD file described above.

File Naming Convention

At the 2001 and 2005 Georgia Tech Fault and Disturbance Analysis Conferences Amir Makki
presented the results from the IEEE PSRC Working Group H8 File Naming Convention for Time
Sequence Data that later became IEEE C37.232 standard (paper presented by Amir Makki at the
2008 conference).
The file naming convention defines a readable, delimited filename format. The delimiting
character between the filename fields is the “,” comma. In all cases where an alphabetical
character is called for, the character can be either upper or lower case. Software should treat
upper and lower case letters in the same way. The fields for the filename shall be as follows and
in order as shown here:
The standard defines a readable, comma delimited, text format. The file name includes the
following required fields:
Start Date, Start Time, Time Code, Station Identifier, Device Identifier, Company Name
Additional fields may be added as needed by the user and are called “user fields”. The standard
requires that the user fields follow directly after the required fields and in order:
, User-1, User-2, User-3, User-4, and so on. Extension
All required and user fields are separated by commas. Only one comma is used to separate
between fields (trailing commas should not be used). The extension will always follow at the end
as shown above. In order to conform to the standard.

IED Naming Convention

A common naming convention for specifying IED designations would help solve many of the
problems that are associated with the analysis of different electric power system events. That is
why the IEEE PES Power System Relaying Committee understood the need for standardization
of the IED names and started a working group – H10 - in the Relay Communication
subcommittee with the task to create a PSRC Report that describes a convention to uniquely identify
(name) installed Intelligent Electronic Devices (IEDs) including measured and calculated quantities
for the purpose of sharing data collected by these devices. The common convention will, in turn,
have a positive impact on maintenance, protection, operations, and on engineering applications.
To that extent, the main objective of the H10 working group is to address and report on the issues
related to specifying IED designations. The report explains the need for having a common
naming convention and provides a brief, high level, survey of current and best practices.

Conclusions
The use of the different standard data formats and naming conventions allows the development of
automatic fault analysis tools that will improve the quality of electric power systems event
analysis and significantly reduce the required time based on the elimination of the manual
conversion of proprietary data formats.
This can be achieved only through the joint efforts of utilities, consultants and manufacturers,
based on the numerous working group activities in IEEE, IEC and CIGRE.
Biography
Alexander Apostolov received a MS degree in Electrical Engineering, MS in Applied
Mathematics and Ph.D. from the Technical University in Sofia, Bulgaria. He has more than 30
years experience in power systems protection, automation, control and communications.
He is presently Principal Engineer for OMICRON electronics in Los Angeles, CA. He is IEEE
Fellow and Member of the Power Systems Relaying Committee and Substations C0 Subcommittee.
He is the past Chairman of the Relay Communications Subcommittee, serves on many IEEE PES
Working Groups and is Chairman of Working Group D21: Contribution to IEC TC 95 WG MT4
Protection Functions Testing.
He is member of IEC TC57 and Convenor of CIGRE WG B5.27 ”Implications and Benefits of
Standardized Protection Schemes” and member of several other CIGRE B5 working groups. .He is
Chairman of the Technical Publications Subcommittee of the UCA International Users Group. He
holds four patents and has authored and presented more than 300 technical papers.
He is Editor-in-Chief of PAC World.