Ieee C37.244-2013

IEEE Guide for Phasor Data
Concentrator Requirements for Power

System Protection, Control, and
Monitoring

Sponsored by the
Power System Relaying Committee

IEEE
3 Park Avenue
New York, NY 10016-5997
USA

10 May 2013
IEEE Power and Energy Society

IEEE Std C37.244-2013

Authorized licensed use limited to: UNIVERSIDADE FEDERAL DE SANTA CATARINA. Downloaded on October 22,2013 at 14:03:42 UTC from IEEE Xplore. Restrictions apply.
IEEE Std C37.244-2013
Monitoring
Sponsor

Power System Relaying Committee
of the
IEEE Power and Energy Society

Approved 8 March 2013

IEEE-SA Standards Board


Abstract: The functional, performance, and testing guidelines for a phasor data concentrator are
described in this guide. Supporting information is also provided.

Keywords: data concentrator (DC), GPS synchronization, IEEE C37.244
TM
, phasor, phasor data
concentrator (PDC), phasor measurement, phasor measurement unit (PMU), synchrophasor

The Institute of Electrical and Electronics Engineers, Inc.
3 Park Avenue, New York, NY 10016-5997, USA

Copyright 2013 by The Institute of Electrical and Electronics Engineers, Inc.
All rights reserved. Published 10 May 2013. Printed in the United States of America.

IEEE is a registered trademark in the U.S. Patent & Trademark Office, owned by The Institute of Electrical and Electronics
Engineers, Incorporated.

PDF: ISBN 978-0-7381-8260-5 STD98159
Print: ISBN 978-0-7381-8261-2 STDPD98159

IEEE prohibits discrimination, harassment, and bullying.
For more information, visit http://www.ieee.org/web/aboutus/whatis/policies/p9-26.html.
No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior written permission
of the publisher.

Notice and Disclaimer of Liability Concerning the Use of IEEE Documents: IEEE Standards documents are developed
within the IEEE Societies and the Standards Coordinating Committees of the IEEE Standards Association (IEEE-SA)
Standards Board. IEEE develops its standards through a consensus development process, approved by the American National
Standards Institute, which brings together volunteers representing varied viewpoints and interests to achieve the final product.
Volunteers are not necessarily members of the Institute and serve without compensation. While IEEE administers the process
and establishes rules to promote fairness in the consensus development process, IEEE does not independently evaluate, test, or
verify the accuracy of any of the information or the soundness of any judgments contained in its standards.
Use of an IEEE Standard is wholly voluntary. IEEE disclaims liability for any personal injury, property or other damage, of
any nature whatsoever, whether special, indirect, consequential, or compensatory, directly or indirectly resulting from the
publication, use of, or reliance upon any IEEE Standard document.
IEEE does not warrant or represent the accuracy or content of the material contained in its standards, and expressly disclaims
any express or implied warranty, including any implied warranty of merchantability or fitness for a specific purpose, or that
the use of the material contained in its standards is free from patent infringement. IEEE Standards documents are supplied "AS
IS."
The existence of an IEEE Standard does not imply that there are no other ways to produce, test, measure, purchase, market, or
provide other goods and services related to the scope of the IEEE standard. Furthermore, the viewpoint expressed at the time a
standard is approved and issued is subject to change brought about through developments in the state of the art and comments
received from users of the standard. Every IEEE standard is subjected to review at least every ten years. When a document is
more than ten years old and has not undergone a revision process, it is reasonable to conclude that its contents, although still of
some value, do not wholly reflect the present state of the art. Users are cautioned to check to determine that they have the
latest edition of any IEEE standard.
In publishing and making its standards available, IEEE is not suggesting or rendering professional or other services for, or on
behalf of, any person or entity. Nor is IEEE undertaking to perform any duty owed by any other person or entity to another.
Any person utilizing any IEEE Standards document, should rely upon his or her own independent judgment in the exercise of
reasonable care in any given circumstances or, as appropriate, seek the advice of a competent professional in determining the
appropriateness of a given IEEE standard.
Translations: The IEEE consensus development process involves the review of documents in English only. In the event that
an IEEE standard is translated, only the English version published by IEEE should be considered the approved IEEE standard.
Official Statements: A statement, written or oral, that is not processed in accordance with the IEEE-SA Standards Board
Operations Manual shall not be considered the official position of IEEE or any of its committees and shall not be considered to
be, nor be relied upon as, a formal position of IEEE. At lectures, symposia, seminars, or educational courses, an individual
presenting information on IEEE standards shall make it clear that his or her views should be considered the personal views of
that individual rather than the formal position of IEEE.
Comments on Standards: Comments for revision of IEEE Standards documents are welcome from any interested party,
regardless of membership affiliation with IEEE. However, IEEE does not provide consulting information or advice pertaining
to IEEE Standards documents. Suggestions for changes in documents should be in the form of a proposed change of text,
together with appropriate supporting comments. Since IEEE standards represent a consensus of concerned interests, it is
important to ensure that any responses to comments and questions also receive the concurrence of a balance of interests. For
this reason, IEEE and the members of its societies and Standards Coordinating Committees are not able to provide an instant
response to comments or questions except in those cases where the matter has previously been addressed. Any person who
would like to participate in evaluating comments or revisions to an IEEE standard is welcome to join the relevant IEEE
working group at http://standards.ieee.org/develop/wg/.
Comments on standards should be submitted to the following address:
Secretary, IEEE-SA Standards Board
445 Hoes Lane
Piscataway, NJ 08854
USA
Photocopies: Authorization to photocopy portions of any individual standard for internal or personal use is granted by The
Institute of Electrical and Electronics Engineers, Inc., provided that the appropriate fee is paid to Copyright Clearance Center.
To arrange for payment of licensing fee, please contact Copyright Clearance Center, Customer Service, 222 Rosewood Drive,
Danvers, MA 01923 USA; +1 978 750 8400. Permission to photocopy portions of any individual standard for educational
classroom use can also be obtained through the Copyright Clearance Center.


Copyright 2013 IEEE. All rights reserved.
iv
Notice to users
Laws and regulations
Users of IEEE Standards documents should consult all applicable laws and regulations. Compliance with
the provisions of any IEEE Standards document does not imply compliance to any applicable regulatory
requirements. Implementers of the standard are responsible for observing or referring to the applicable
regulatory requirements. IEEE does not, by the publication of its standards, intend to urge action that is not
in compliance with applicable laws, and these documents may not be construed as doing so.
Copyrights
This document is copyrighted by the IEEE. It is made available for a wide variety of both public and
private uses. These include both use, by reference, in laws and regulations, and use in private self-
regulation, standardization, and the promotion of engineering practices and methods. By making this
document available for use and adoption by public authorities and private users, the IEEE does not waive
any rights in copyright to this document.
Updating of IEEE documents
Users of IEEE Standards documents should be aware that these documents may be superseded at any time
by the issuance of new editions or may be amended from time to time through the issuance of amendments,
corrigenda, or errata. An official IEEE document at any point in time consists of the current edition of the
document together with any amendments, corrigenda, or errata then in effect. In order to determine whether
a given document is the current edition and whether it has been amended through the issuance of
amendments, corrigenda, or errata, visit the IEEE-SA Website at http://standards.ieee.org/index.html or
contact the IEEE at the address listed previously. For more information about the IEEE Standards
Association or the IEEE standards development process, visit IEEE-SA Website at
http://standards.ieee.org/index.html.
Errata
Errata, if any, for this and all other standards can be accessed at the following URL:
http://standards.ieee.org/findstds/errata/index.html. Users are encouraged to check this URL for errata
periodically.

v
Patents
Attention is called to the possibility that implementation of this standard may require use of subject matter
covered by patent rights. By publication of this standard, no position is taken by the IEEE with respect to
the existence or validity of any patent rights in connection therewith. If a patent holder or patent applicant
has filed a statement of assurance via an Accepted Letter of Assurance, then the statement is listed on the
IEEE-SA Website at http://standards.ieee.org/about/sasb/patcom/patents.html. Letters of Assurance may
indicate whether the Submitter is willing or unwilling to grant licenses under patent rights without
compensation or under reasonable rates, with reasonable terms and conditions that are demonstrably free of
any unfair discrimination to applicants desiring to obtain such licenses.
Essential Patent Claims may exist for which a Letter of Assurance has not been received. The IEEE is not
responsible for identifying Essential Patent Claims for which a license may be required, for conducting
inquiries into the legal validity or scope of Patents Claims, or determining whether any licensing terms or
conditions provided in connection with submission of a Letter of Assurance, if any, or in any licensing
agreements are reasonable or non-discriminatory. Users of this standard are expressly advised that
determination of the validity of any patent rights, and the risk of infringement of such rights, is entirely
their own responsibility. Further information may be obtained from the IEEE Standards Association.


Participants
At the time this IEEE guide was completed, the Phasor Data Concentrator Requirements for Power System
Protection, Control, and Monitoring Working Group had the following membership:
Galina Antonova, Chair
Vasudev Gharpure, Vice Chair

Mark Adamiak
Alex Apostolov
Christoph Brunner
Bill Dickerson
Ron Farquharson
William Flerchinger
Allen Goldstein
Yi Hu
Zhenyu Huang
Ilija Jankovic
Mital Kanabar

Mladen Kezunovic
Harold Kirkham
Yuan Liao
Vahid Madani
Kenneth Martin
Harish Mehta
Rene Midence
Jay Murphy
Shyam Musunuri
Paul Myrda
Krish Narendra
Damir Novosel
Mahendra Patel
Manu Parashar
Farnoosh Rahmatian
Veselin Skendzic
Anurag Srivastava
Gerard Stenbakken
Eric Udren
Benton Vandiver
Solveig Ward
Tony Weekes
Zhiyang Zhang

The following members of the individual balloting committee voted on this guide. Balloters may have
voted for approval, disapproval, or abstention.

Mohamed Abdel Khalek
William Ackerman
Mark Adamiak
Ali Al Awazi
Mihaela Albu
Saleman Alibhay
John Anderson
Galina Antonova
Carlo Arpino
Jason Bank
Matthew Basler
David Bassett
Philip Beaumont
Robert Beresh
William Bush
Paul Cardinal
Arvind K. Chaudhary
Stephen Conrad
Luis Coronado
Randall Crellin
Randall Cunico
William Dickerson
Michael Dood
Douglas Dorr
Randall Dotson
Dan Evans
Ronald Farquharson
William Flerchinger
Fredric Friend
Frank Gerleve
Vasudev Gharpure
Jeffrey Gilbert
Jalal Gohari
Roman Graf
Stephen Grier
Randall Groves
Dennis Hansen
Roger Hedding
Gary Heuston
Yi Hu
C. Huntley
Gerald Johnson
Innocent Kamwa
Yuri Khersonsky
James Kinney
Harold Kirkham
J. Koepfinger
Jim Kulchisky
Chung-Yiu Lam
Raluca Lascu
Michael Lauxman
Federico Lopez
Greg Luri
Vahid Madani
Wayne Manges
Kenneth Martin
Pierre Martin
John McDonald
Rene Midence
Kimberly Mosley
Jerry Murphy
R. Murphy
Bruce Muschlitz
Pratap Mysore
Michael S. Newman
Gary Nissen
James O'Brien
Lorraine Padden
Donald Parker
Bansi Patel
Robert Pettigrew
Craig Preuss
Farnoosh Rahmatian
Michael Roberts
Charles Rogers
Joseph Rostron
M. Sachdev
Steven Sano
Sergio Santos
Bartien Sayogo
Thomas Schossig
Devki Sharma
Gil Shultz
Veselin Skendzic
James Smith
Jerry Smith
John Spare
Scott Sternfeld
Gary Stoedter
William Taylor
John Tengdin
Joe Uchiyama
Eric Udren
Marcelo Valdes
Benton Vandiver
John Vergis
Jane Verner
John Wang
Solveig Ward
Tony Weekes
Philip Winston
Sergio Zimath

vi

vii
When the IEEE-SA Standards Board approved this guide on 8 March 2013, it had the following
membership:

John Kulick, Chair
David J. Law, Vice Chair
Richard Hulett, Past Chair
Konstantinos Karachalios, Secretary
Masayuki Ariyoshi
Peter Balma
Farooq Bari
Ted Burse
Wael William Diab
Stephen Dukes
Jean-Philippe Faure

Alex Gelman
Mark Halpin
Gary Hoffman
Paul Houz
Jim Hughes
Mike Janezic
Joseph Koepfinger*
Oleg Logvinov
Ron Petersen
Gary Robinson
Jon Rosdahl
Adrian Stephens
Yatin Trivedi
Phil Winston
Yu Yuan
*Member Emeritus

Also included are the following nonvoting IEEE-SA Standards Board liaisons:
Dick DeBlasio, DOE Representative
Mike Janezic, NIST Representative

Patrick Gibbons
IEEE Standards Program Manager, Document Development

Erin Spiewak
IEEE Standards Program Manager, Technical Program Development

Soo H. Kim
IEEE Standards Client Services Manager, Professional Services


Introduction
This introduction is not part of IEEE Std C37.244-2013, IEEE Guide for Phasor Data Concentrator Requirements for
Power System Protection, Control, and Monitoring.
A phasor data concentrator (PDC) is a function that combines synchrophasor data from more than one
source for further processing. Originally the PDC purpose was to combine synchrophasor measurements
from many phasor measurement units (PMUs) into a single time synchronized data stream. Since the PDC
was the only common element in communications with all measurement units, its function included
monitoring the overall measurement system. As measurement systems and the deployment of applications
have increased in size, the functions of the PDC have expanded to include more data handling, processing,
and storage. At the same time, the rapid growth in technology is enabling the development of integrated
features for power systems applications. This guide provides definitions of the terminology, functional
descriptions, and what could be expected from a PDC. It is arranged with clauses describing the functions
and requirements in order for the user to identify the features desired for the respective applications. This
guide is communication protocol independent in terms of applications, and will also serve the industry with
common interpretation of terms for function standardization and data protocol implementation agreements.
Clause 7 offers practical methods for testing PDC functions, including example setups for data transport in
a production-type environment, in line with related IEC and IEEE standards.
This guide defines numerous functions that may be included in a PDC. Which ones are included depend on
the application and use of the PDC, as well as agreements between the PDC manufacturer and customer.
The functions presented in this guide may not be available; and it is anticipated that other functions which
have not been included here may exist and others may be developed in the future.

viii

Contents
1. Overview.................................................................................................................................................... 1
1.1 Scope ................................................................................................................................................... 1
1.2 Purpose ................................................................................................................................................ 2
2. Normative references.................................................................................................................................. 2
3. Definitions, acronyms, and abbreviations .................................................................................................. 2
3.1 Definitions ........................................................................................................................................... 2
3.2 Abbreviations and acronyms ............................................................................................................... 4
4. Synchrophasor measurement system overview.......................................................................................... 5
4.1 Synchrophasor network ....................................................................................................................... 5
4.2 Synchrophasor network elements ........................................................................................................ 6
4.3 Multiple data streams from PMUs and PDCs...................................................................................... 7
4.4 Synchrophasor system communications.............................................................................................. 7
4.5 Cyber security...................................................................................................................................... 8
5. PDC functional requirements ..................................................................................................................... 8
5.1 Data aggregation.................................................................................................................................. 9
5.2 Data forwarding................................................................................................................................. 10
5.3 Data communications ........................................................................................................................ 11
5.4 Data validation................................................................................................................................... 13
5.5 Data transfer protocol support ........................................................................................................... 13
5.6 Data transfer protocols conversion .................................................................................................... 13
5.7 Data format and coordinate conversion............................................................................................. 13
5.8 Data latency calculation..................................................................................................................... 13
5.9 Reporting rate conversion.................................................................................................................. 15
5.10 Output data buffering....................................................................................................................... 15
5.11 Configuration................................................................................................................................... 16
5.12 Phase and magnitude adjustment ..................................................................................................... 17
5.13 Performance monitoring.................................................................................................................. 18
5.14 Redundant data handling ................................................................................................................. 19
5.15 Duplicate data handling................................................................................................................... 19
5.16 Data re-transmission request............................................................................................................ 19
5.17 Cyber security.................................................................................................................................. 20
6. PDC performance requirements ............................................................................................................... 22
6.1 PDC latency....................................................................................................................................... 22
6.2 Robustness......................................................................................................................................... 25
6.3 Environmental ................................................................................................................................... 25
6.4 Availability and reliability................................................................................................................. 25
6.5 PDC data processing.......................................................................................................................... 25
7. Testing...................................................................................................................................................... 25
7.1 Categories of PDC tests..................................................................................................................... 25
7.2 Test interfaces.................................................................................................................................... 27
7.3 Test setups ......................................................................................................................................... 28
7.4 Tests outline....................................................................................................................................... 30
7.5 Test reporting..................................................................................................................................... 34
7.6 Testing tools ...................................................................................................................................... 34

ix

x
Annex A (informative) Relevant standards .................................................................................................. 40
A.1 IEEE Std 1344-1995 (R 2001), IEEE Std C37.118-2005, IEEE Std C37.118.1-2011 and IEEE Std
C37.118.2-2011 ....................................................................................................................................... 40
A.2 IEC 61850 ......................................................................................................................................... 40
A.3 IEC 61970 ......................................................................................................................................... 40
A.4 IEEE Std C37.111-1999 ................................................................................................................... 40
A.5 IEEE Std C37.232-2011 ................................................................................................................... 40
A.6 IEEE Std C37.233-2009 ................................................................................................................... 41
A.7 IEEE Std C37.238-2011 ................................................................................................................... 41
A.8 IEEE Std C37.239-2010 ................................................................................................................... 41
A.9 IEEE PC37.240, D13.0, March, 2013 ............................................................................................... 41
A.10 IEEE Std C37.242-2013 ................................................................................................................. 41
A.11 IEEE Std 1613-2009 and Amendment 1 - 2010.............................................................................. 41
Annex B (informative) Reporting rate conversion and the associated filtering ............................................ 42
B.1 Aliasing ............................................................................................................................................. 42
B.2 Down-conversion .............................................................................................................................. 43
B.3 Up-conversion ................................................................................................................................... 43
Annex C (informative) IEEE Std C37.118.1-2011 latency discussion ......................................................... 45
Annex D (informative) Bibliography ........................................................................................................... 52


1

Monitoring
IMPORTANT NOTICE: IEEE Standards documents are not intended to ensure safety, health, or environmental
protection, or ensure against interference with or from other devices or networks. Implementers of IEEE
Standards documents are responsible for determining and complying with all appropriate safety, security,
environmental, health, and interference protection practices and all applicable laws and regulations.
This IEEE document is made available for use subject to important notices and legal disclaimers.
These notices and disclaimers appear in all publications containing this document and may
be found under the heading Important Notice or Important Notices and Disclaimers
Concerning IEEE Documents. They can also be obtained on request from IEEE or viewed at
http://standards.ieee.org/IPR/disclaimers.html.
1. Overview
This clause describes the scope, purpose, and the limitation of applicability of the IEEE Guide for Phasor Data
Concentrator Requirements for Power System Protection, Control, and Monitoring, hereafter referred to as this
guide.
1.1 Scope
This guide describes performance, functional, and communication needs of phasor data concentrators (PDCs) for
power system protection, control, and monitoring applications. The guide covers synchrophasor system needs and
testing procedures for PDCs. It includes functional requirements for associated interfaces with phasor measurement
units (PMUs) to a PDC and PDC systems. In particular, it includes requirements for synchronization, synchrophasor
data processing, and real-time access.

IEEE Std C37.244-2013
IEEE Guide for Phasor Data Concentrator Requirements for Power System Protection, Control, and Monitoring

1.2 Purpose
The purpose of this guide is to assist users to specify the performance and functional requirements of typical phasor
data concentrators and define performance testing for PDC systems. It includes consideration of PDC latency, input
and output streams supported, interface and data transport protocols, the ability to configure output stream payload,
the communication media supported, time alignment functions, error handling, etc.
2. Normative references
The following referenced documents are indispensable for the application of this document (i.e., they must be
understood and used, so each referenced document is cited in text and its relationship to this document is explained).
For dated references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments or corrigenda) applies.
IEEE Std C37.118.1-2011, IEEE Standard for Synchrophasor Measurements for Power Systems.
1, 2

IEEE Std C37.118.2-2011, IEEE Standard for Synchrophasor Data Transfer for Power Systems.
IEC 61850-90-5, Communication networks and systems for power utility automationPart 90-5: Use of IEC 61850
to transmit synchrophasor information according to IEEE C37.118, Edition 1.0, May 2012.
3

3. Definitions, acronyms, and abbreviations
For the purposes of this document, the following terms and definitions apply. The IEEE Standards Dictionary
Online should be consulted for terms not defined in this clause.
4

3.1 Definitions
absolute wait time: The time interval added to the time corresponding to a given message timestamp. After this
interval, the collection of data with that timestamp is terminated.
anti-aliasing: The process of filtering a signal before sampling to remove components of that signal whose
frequency is equal to or greater than the Nyquist frequency (one-half the sample rate). If not removed, these signal
components would appear as a lower frequency component (an alias).
BPA/PDCstream: An extension and adaptation of IEEE Std 1344 for multiple phasor measurement units
(PMUs), widely used in the Western Electricity Coordinating Council (WECC) and throughout North America
before the advent of IEEE Std C37.118.
configuration: A data structure containing flags that control the operation of the runtime environment.
data aggregation: Forming a set of data from multiple inputs.

1
This publication is available from The Institute of Electrical and Electronics Engineers (http://standards.ieee.org/).
2
The IEEE standards or products referred to in this clause are trademarks of The Institute of Electrical and Electronics Engineers, Inc.
3
IEC publications are available from the International Electrotechnical Commission (http://www.iec.ch/). IEC publications are also available in
the United States from the American National Standards Institute (http://www.ansi.org/).
4
IEEE Standards Dictionary Online subscription is available at:
http://www.ieee.org/portal/innovate/products/standard/standards_dictionary.html.
2

IEEE Std C37.244-2013

data forwarding: Forwarding a set of data from an input to an output with no intentional delay and without data
aggregation.
duplicate data: Multiple copies of the same synchrophasor data received by a phasor data concentrator (PDC), with
all identical values, names, and timestamps.
frame: A data frame or a frame of data is a set of synchrophasor, frequency, and rate-of-change-of-frequency
measurements that corresponds to the same timestamp. The term frame is used to differentiate it from samples,
which are understood as points on an analog waveform.
intelligent electronic device (IED): Any device incorporating one or more processors with the capability to receive
or send data/control from, or to, an external source (e.g., electronic multifunction meters, digital relays, controllers).
PDC latency: The time difference between the arrival time of the first complete data message with a given
timestamp and its egress time from the phasor data concentrator (PDC).
PDC processing time: The time interval a phasor data concentrator (PDC) uses to complete the production of an
output stream. It starts when all data to be processed is received or wait times were reached, and ends at the data
egress time from the PDC.
phasor: A complex equivalent, in polar or rectangular form, of a sinusoidal wave quantity such that the complex
modulus is the cosine wave amplitude and the complex angle is the cosine wave phase angle.
phasor data concentrator (PDC): A function that collects phasor data, and discrete event data from PMUs and
possibly from other PDCs, and transmits data to other applications. PDCs may buffer data for a short time period,
but do not store the data. This guide defines a PDC as a function that may exist within any given device.
redundant data: Multiple synchrophasor data received by a phasor data concentrator (PDC), corresponding to the
same signal, and same timestamp. The redundant data should have different signal names, or different phasor
measurement unit (PMU) names, or both.
relative wait time: The time interval added to the arrival time of the first message with a given timestamp. After
this interval, the collection of data with that timestamp is terminated.
robustness: The degree to which a system or component can function in the presence of conditions outside of
system or component design specification.
synchronized phasor or synchrophasor: A phasor calculated from data samples using a standard time signal as the
reference for the measurement.
total vector error (TVE): The measure of error between the theoretical phasor value of the signal being measured
and the phasor estimate.
wait time: The maximum time interval during which the phasor data concentrator (PDC) collects data for a
particular output from one or more inputs. It is the time interval added to a message timestamp time or message-
arrival time after which no more data with that timestamp is accepted.

3

IEEE Std C37.244-2013

3.2 Abbreviations and acronyms
APDU application-layer protocol data unit
ASCII American Standard Code for Information Interchange
CIP critical infrastructure protection
CRC cyclic redundancy check
DFR digital fault recorder
DSCP differentiated services code point
ECN explicit congestion notification
EMC electromagnetic compatibility
EMS energy management system
fps frames per second, the rate that frames of synchrophasor data are transmitted
GOOSE generic object oriented substation event
GPS Global Positioning System
HMAC hash-based message authentication code
IED intelligent electronic device
IETF Internet Engineering Task Force
IP Internet Protocol (see IETF RFC 791)
IRIG-B Inter-Range Instrumentation Group B
ISO independent system operator
IT information technology
LDAP Lightweight Directory Access Protocol
MAC message authentication code
NaN not a number
PDC phasor data concentrator
PMU phasor measurement unit
QoS quality of service
RFC request for comments
4

IEEE Std C37.244-2013

SCADA supervisory control and data acquisition
SCL Substation Configuration Language
SSL secure socket layer
SSPP Substation Serial Protection Protocol
SV sample values
TCP Transmission Control Protocol (see IETF RFC 793)
TCP/IP Transmission Control Protocol/Internet Protocol
TO transmission owner
ToS type of service
UDP User Datagram Protocol (see IETF RFC 768)
UDP/IP User Datagram Protocol/Internet Protocol
UTC Coordinated Universal Time (initials are ordered based on French language)
VPN virtual private network
WAMPAC wide-area monitoring, protection, and control
WAMS wide-area measurement system
4. Synchrophasor measurement system overview
This clause provides a high level overview of the primary features and functions of a synchrophasor measurement
system, to which a PDC belongs. The concepts introduced in this clause are further developed into specific
functional requirements in Clause 5. Clause 6 introduces performance requirements for some of the functional
requirements in Clause 5. Finally, Clause 7 provides suggested testing outlines for some of the functional
requirements in Clause 5.
4.1 Synchrophasor network
A simple structure of a synchrophasor network consists of phasor measurement units (PMUs) and phasor data
concentrators (PDCs) as shown in Figure 1, where arrows indicate some possible interfaces. If multiple intelligent
electronic devices (IEDs) in a substation provide synchrophasor measurements, a local PDC may be deployed in
the substation. Typically, many PMUs located at various key substations gather data and send it in real time to a
PDC at the utility location where the data is aggregated. The data collected by PDCs may be sent to other
PDCs/synchrophasor systems and/or be used to support many applications, ranging from visualization of
information and alarms for situational awareness, to applications that provide sophisticated analytical, control, or
protection functionality. Applications, such as dynamics monitoring, use full-resolution, real-time data along with
grid models to support both operating and planning functions. The application(s) locally display measured
frequencies, primary voltages, currents, real and reactive power flows, and other quantities for system operators.
5

IEEE Std C37.244-2013

Many PDCs belonging to different utilities can be connected to a common central PDC to aggregate data across the
utilities, in order to provide an interconnection-wide snapshot of the power grid measurements.

Figure 1 Synchrophasor data collection network
4.2 Synchrophasor network elements
4.2.1 Synchrophasor measurement unit
The PMU is a function or logical device that provides synchrophasor, system frequency, and rate-of-change-of-
frequency estimates, as well as optional information such as calculated megawatts (MW) and megavars (MVAr),
other measurements, and Boolean status words. The PMU may provide synchrophasor estimates from one or more
voltage or current waveforms. The PMU can be realized as a stand-alone physical device or as a part of a
multifunction device such as a protective relay, digital fault recorder (DFR), or meter. This information may be
recorded locally or transmitted in real time to a central location as illustrated in Figure 1. This guide addresses the
real-time transfer of data from the PMU to the PDC or other devices.
4.2.2 Phasor data concentrator
A PDC works as a node in a communication network where synchrophasor data from a number of PMUs or PDCs is
processed and fed out as a single stream to the higher level PDCs and/or applications. The PDC processes
synchrophasor data by timestamp to create a system-wide measurement set.
Additional functions may be provided, as follows:
a) Performs various quality checks on the phasor data and inserts the appropriate flags into the correlated data
stream.
b) Checks for disturbance flags and recordings of data files for analysis.
c) Monitors the overall measurement system and displays the results, as well as recordings of the performance.
d) Includes a number of specialized outputs, such as a direct interface to a supervisory control and data
acquisition (SCADA) system or energy management system (EMS).
In one mode of operations, local PDCs, as shown in Figure 1, aggregate and time-align synchrophasor data from
multiple PMUs and feed the data to applications. Mid- and higher-level PDCs collect synchrophasor data from
6

IEEE Std C37.244-2013

multiple PDCs, conduct data quality checks, and feed the data to applications. The PDCs may be recognized as a
function rather than as a stand-alone device or hardware/software package, and can be integrated into other systems
and devices. A structured hierarchy of distributed PDCs may be formed to serve a hierarchy of systems: substation,
utility, control area, reliability coordinator, and interconnection level. Distributed PDCs may also interact with each
other on a peer-to-peer basis among utilities, control areas, and reliability coordinators. Each layer in the hierarchy
may be serving different data requirements (e.g., latency, quality, resolution), with archival and event triggering and
data capture requirements driven by applications. Since local PDCs represent a local point of failure for the data
stream, backup and bypass options are needed for mitigating such failures.
4.2.3 Application support
If a deployed synchrophasor system has only one real-time application, such a data concentration function could be
an integral part of the application. However, a synchrophasor system typically implements multiple functions, where
sharing the same phasor data concentration function by using a dedicated PDC device/subsystem may become a
more viable choice.
Typically, a PDC receives phasor data from multiple sources, performs aggregation of the data received following
the rules specified within the PDC, and makes the aggregated data available to applications. Examples of
applications utilizing phasor data are wide-area situational awareness, wide-area measurement system (WAMS), and
wide-area monitoring, protection, and control (WAMPAC). As a part of application support, a PDC may also
support data storage and archival, event detection/monitoring, etc. Applications may require real-time data access or
historical data access. A PDC uses real-time data access to limit overall synchrophasor data latency as shown in
Figure 2. A PDC uses historical data access to retrieve any logs.
In addition, a PDC may support other functions within the same system. Examples of such PDC functions are data
validation, data format, coordinate and/or protocol conversion, data scaling, etc. A PDC may also support
monitoring, alarming, and logging of its own performance, as well as the throughput statistics and other
characteristics of the data handled by the PDC.
If a PDC supports event logging, the event logs may be mapped into Common Format for Event Data Exchange
(COMFEDE) per IEEE Std C37.239-2010 [B16]. If it supports data logging, the data values may be mapped to
either a Comma Separated Value format (CSV) or a Common Format for Transient Data Exchange (COMTRADE)
per IEEE Std C37.111-1999 [B11]. When mapping synchrophasors into COMTRADE, the schema for the
mapping should be based on the IEEE PES PSRC Working Group H8 Report, Schema for Phasor Data Using the
COMTRADE File Standard [B19].
4.3 Multiple data streams from PMUs and PDCs
A PMU or a PDC may transmit its data in one or more separate data streams. Each stream may have different
content and may be sent at a different rate. The destination of each stream may be different device(s) and location(s)
(multicast data is sent to multiple destinations). Each stream must then be individually controllable, and have its own
identification and a separate configuration control. This feature is useful for sending data to different devices with
different purposes, allowing streams with different wait times and class of service (M and P class), as specified in
IEEE Std C37.118.1-2011.
4.4 Synchrophasor system communications
Synchrophasor system communication plays an important role in the overall functionality and performance of a
production-grade synchrophasor system. Communication systems should ensure that the required quality of service
(QoS) of each synchrophasor data flow can be met individually. QoS is stated in terms of IEEE Std 802.1Q [B5]
7

IEEE Std C37.244-2013

and IETF RFC 791 [B22]. The IEC 61850-90-5 profile requires that the data interface provides IEEE 802.1Q QoS
priority tagging. IEC 61850-90-5 also recommends the use of IETF RFC 2474 DSCP (differentiated services code
point) [B23] and IETF RFC 3168 ECN (explicit congestion notification) [B24] in the IETF RFC 791 type of service
(ToS) field in the IP header, where DSCP can be set by the PDC but the ECN is set by the intermediate systems.
IEEE Std C37.118.2-2011 provides no equivalent QoS and ToS requirements. When using the IEEE Std
C37.118.2-2011 and prioritization is required, QoS and ToS will have to be implemented either through
communications network design that is external to the protocol or through an implementation of QoS and ToS in the
PDC. PDCs implementing serial communications have no equivalent QoS or ToS mechanism.
4.4.1 Synchrophasor data transfer protocols
The synchrophasor communication protocols continue to evolve. There are a number of protocols that either have
been developed or are under active development. These include some custom protocols (e.g., BPA/PDCstream),
IEEE Std 1344-1995, IEEE Std C37.118-2005, IEEE Std C37.118.2-2011, and IEC 61850-90-5 protocols. The use
of IEEE Std 1344-1995 is discouraged. It should be noted that at present, there are two standards for the
communication of synchrophasorsthe IEEE Std C37.118.2-2011 and the IEC 61850-90-5. Additionally, it should
be noted that it is expected that the profiles defined in the IEC Technical Report are planned to be incorporated in
the addendum to Edition 2.0 of the IEC 61850 Standard [B1]. At present, the IEEE Std C37.118-2005 protocol is
widely implemented. Note that the IEEE Std C37.118.2-2011 protocol was designed to be backward compatible
with the 2005 version of the synchrophasor standard.
4.5 Cyber security
PMUs and PDCs can provide access to utility networks that can be serial and/or Ethernet network based.
Implementers should understand the security environment that these devices are placed within and include specific,
tangible requirements that must be implemented, so that the security requirements for that environment are met. It
should be noted that PMU/PDC functionality and/or performance may be impacted by security measures.
Specification of end-to-end security of a synchrophasor data system is beyond the scope of this guide.
Proposed IEEE PC37.240 Draft Standard D13.0, March 2013, Cyber Security Requirements for Substation
Automation, Protection, and Control Systems [B17] is one standard presently under development which specifically
addresses technical requirements for substation cyber security and presents sound engineering practices. IEEE Std
1686 [B9] defines the functions and features to be provided in IEDs to accommodate critical infrastructure
protection (CIP) programs. For protecting serial PDC communications, synchrophasor, or any other protocols
related to SCADA and engineering access, IEEE Std 1711 [B10] defines a cryptographic protocol to provide
integrity, and optional confidentiality, for cyber security of substation serial links. IEC 61850-90-5 refers to
IEC 62351 [B4], which defines cyber security functions such as authentication, encryption, and multicast key
exchange that can be applied to synchrophasors when using IEC 61850.
5. PDC functional requirements
A PDC may perform several functions applied to synchrophasor data streams. The need for these functions depends
on the applications being served by synchrophasor data and the design of the synchrophasor systems.
This clause provides a description of functional requirements of the following PDC functions:
a) Data aggregation
b) Data forwarding
8

IEEE Std C37.244-2013

c) Data communications
d) Data validation
e) Data transfer protocol support
f) Data transfer protocols conversion
g) Data format and coordinate conversion
h) Data latency calculation
i) Reporting rate conversion
j) Output data buffering
k) Configuration
l) Phase and magnitude adjustment
m) Performance monitoring
n) Redundant data handling
o) Duplicate data handling
p) Data re-transmission request
q) Cyber security
5.1 Data aggregation
Data aggregation function could be performed with or without time alignment. It should preserve data quality, time
quality, and time synchronization indications from each signal, and include the data quality information assigned by
the individual sending devices to the output data frames.
It would be desirable to include additional information about the data, such as the nature of any data
manipulation done by the PDC, e.g., calculation, interpolation, etc. This is currently not provided in the data
frames by IEEE Std C37.118.2-2011 and IEC 61850-90-5. However, IEEE C37.118.2-2011 provides this
information in the CFG-3 frame.
5.1.1 Data aggregation with time alignment
The PDC aligns data received from PMUs/PDCs and transmits the combined data in one or more output data
streams to other PDCs or applications such as archiving, visualization, or control.
Data coming into a PDC has been timestamped by the PMU with a time referenced to UTC, absolute time.
Data aggregation with time alignment refers to waiting for data with a given timestamp from all sources, placing that
data in a packet, and forwarding it. The PDC aligns received PMU/PDC data according to their timestamps, not their
arriving order or arriving time.
Time alignment to absolute time refers to waiting no more than a specified absolute wait time after a timestamp time
for data with that timestamp. This requires that the PDC is synchronized to UTC.
Time alignment to relative time refers to waiting no more than a specified relative wait time after an event. An event
may be the arrival of the first data with a specific timestamp.
9

IEEE Std C37.244-2013

Different applications may have different latency and data requirements, creating the need for the PDC to furnish
multiple data streams.
For example, a protection/remedial action application may require selected signals to be available with only a short
delay (such as 30 to 40 ms). If all the required signals are not available within the specified time, the control
application could act on as many signals as are available, rather than wait for each required signal to become
available.
A visualization application may require only the signals selected for the display, and it may be able to wait for as
long as one second before deciding to use whatever data is available rather than waiting any longer.
A long-term data archival application may need all the received data, and may be able to wait a very long time, as its
data may be useable for years.
The PDC should indicate when data is absent in its outgoing data stream. The PDC should also accept such
indications from the sender, and interpret them appropriately. For example, in IEEE Std C37.118.2-2011 specific
values (NaN) are used to substitute absent data. Other standards may use alternative methods, such as tagging the
data as absent, as done in IEC 61850.
5.1.2 Data aggregation without time alignment
For some applications, it is desirable to receive a set of synchrophasor measurements with minimum latency.
However, to reduce data loss due to late data arrival, longer wait times are needed. These increase latency. To
address these conflicting requirements (no loss of data due to late arrival and minimum latency), a PDC could
aggregate all the data required for the output destination without time alignment and transmit it periodically, for
example, by using a user-configurable input buffer time, as specified in IEC 61850.
Data aggregation without time alignment may include periodic data transmissions with a user-settable transmission
interval or data size.
As there are no requirements for time alignment, timestamps, data content, data sequence, etc. for an aggregated
stream without time alignment, the PDC should identify each signal in its aggregated data transmissions.
Note that data aggregation is performed from multiple input streams to one or multiple output streams.
5.2 Data forwarding
To minimize PDC latency, a PDC could support data forwarding. Data forwarding is performed from one input to
one output, or from one input to multiple outputs. No data aggregation is performed in this case.
Data forwarding can be performed without data modification (also referred to as pass through) or with data
modifications. Data modification may include data format and coordinate conversion, phase and magnitude
adjustments, decimation, interpolation, etc.
Selective data forwarding is the process of selecting and forwarding a specific subset of data to one or more outputs
and another subset of that data to other output(s). Selective data forwarding could also be supported as a data
forwarding function. Data modification may or may not be performed in this case.
Note that when data forwarding is used, time alignment may be performed by the receiving end devices or by the
application, if it is required.
A PDC manufacturer should specify if, and what kind of, data forwarding is supported.
10

IEEE Std C37.244-2013

5.3 Data communications
Data communications is one PDC function that allows a PDC to connect with other devices via serial- and Ethernet-
based networks. Typically, a PDC receives synchrophasor data and carries out data alignment or any other function
on synchrophasor data. In addition, the time-aligned, or otherwise processed, data are typically transmitted to either
a data storage system (internal or external to the PDC) or an application.
To be able to perform data alignment or any other function on data, a PDC needs to be able to receive synchrophasor
data. Accordingly, data communications using serial and/or Ethernet networks is one of the functions that a PDC
performs.
5.3.1 General aspects of synchrophasor system communications
The synchrophasor system communications include both data and command communications.
The data communications includes both streaming data and configuration information.
Data communicated in a synchrophasor system includes synchrophasors, frequency, rate-of-change-of-frequency,
analog values, digital values, and status information. The message includes a timestamp associated with the
measurements, and is transmitted from source to destination(s) on a continuous and sequential basis.
Data transfer is typically client-server based using either auto-initiation or a data request command. In the auto-
initiation mode, data transmission is implemented without waiting for any request from any destination
devices/applications for each individual data point in the series. In the data request command mode of operation a
client (the PDC) sends a data request command to the server (a PMU or another PDC). The server then responds
with the requested data.
The data communications in a synchrophasor system could be one-to-one (i.e., from one source to one destination)
and/or one-to-many (i.e., from one source to multiple destinations). Either mode may be implemented on Ethernet-
based networks, but serial networks are generally one-to-one unless the serial connection is specially modified to
allow a one-to-many connection.
The command communications of a synchrophasor system includes various synchrophasor command frames. For
example for IEEE Std C37.118.2-2011, the synchrophasor command frames provide commands to the PMU to
initiate streaming, to stop streaming, to retrieve the header frame, to retrieve the configuration frame, and to execute
user-defined controls. For IEC 61850-90-5, the control of the synchrophasor system is executed through a control
block. The control block manages enabling or disabling of streaming, controlling the reporting rate, configuration
revision, configuration of destination address, and enabling or disabling of security.
The command communications of a synchrophasor system may be one-to-one using serial or Ethernet networks.
When using Ethernet networks, command communications typically uses TCP over IP, but can also use UDP over
IP. Command communications are independent of the protocols used for the data transmission.
Depending on how a synchrophasor system is built, it may use single or multiple synchrophasor data transfer
protocols and single or multiple general communication protocols within the system, e.g., TCP/IP and UDP/IP. The
use of multiple protocols could result from the gradual system build-up or interconnection requirements with other
systems.
In addition, while most synchrophasor systems are deployed by individual entities, such as utilities and independent
system operators (ISOs), they generally need to interconnect with each other to utilize functions for wide-area
monitoring, protection, and control applications. Since the deployment pace of each individual system within an
entity is determined by that entity, and in many cases without specific coordination with other entities, there is a
probability that such interconnected systems may need to use multiple communication protocols.
11

IEEE Std C37.244-2013

5.3.2 Physical ports and communication channels
The PDC may be capable of supporting communications through multiple physical ports and/or communication
channels, using different physical media. This could be accomplished using multiple Ethernet ports and/or multiple
serial ports.
It may be possible to configure the PDC to carry all input and output data channels to use the same physical port or
communication channel, or to separate them to use different physical ports and/or communication channels.
Further, it may be possible to configure the PDC to separate multiple input data channels to use different physical
output ports and/or communication channels.
It may be possible to configure the PDC to carry both data and command traffic on the same physical port or
communication channel, or to separate them to use different physical ports and/or communication channels.
5.3.3 Ethernet ports
5.3.3.1 TCP and UDP
The PDC may be capable of supporting communications using both transmission control protocol (TCP) and user
datagram protocol (UDP), refer to IETF RFC 793 [B21] and RFC 768 [B20].
The PDC may be configurable to use either TCP or UDP for command communications with each PMU or PDC.
The PDC may be configurable to use either TCP or UDP for its data communications with each PMU or PDC.
The PDC may support using TCP for commands and using UDP for data communication and configuration with
each PMU or PDC.
5.3.3.2 IPv4 and IPv6
The PDC may support IPv4 and IPv6 protocols, refer to IETF RFC 791 [B22] and IETF RFC 2460 [B25].
5.3.3.3 Multicasting
The PDC may be capable of supporting IP multicast when using UDP/IP for streaming data communications.
The PDC may support receiving UDP/IP multicast input data from multiple data sources.
The PDC may support sending data as UDP/IP multicast output data stream. The destination multicast IP address
should be user-configurable.
5.3.4 Serial ports
The PDC may need to support communications using asynchronous serial communication physical or virtual ports.
These serial ports may support a variety of baud rates, where each end of the connection must match serial
communication configuration parameters such as baud rate, parity, and number of stop bits. Because PMUs and
PDCs are generally always transmitting data, serial channels are typically point-to-point. It is possible to modify
12

IEEE Std C37.244-2013

RS232 serial channels to allow one-to-many types of connections, where the PDC is transmitting synchrophasors to
many end points or a PMU is transmitting to redundant PDCs.
5.4 Data validation
A PDC may perform basic data validation and checking for the data arriving at the PDC. It includes checking the
data status flags and time quality of all PMUs, and performing data integrity checks (such as cyclic redundancy
check [CRC]) on all received data. Any errors detected and suspected corrupt data should be flagged in output data
stream(s). More advanced data validation techniques such as message authentication techniques, etc. could also be
supported. These techniques and their limitations should be clearly specified.
5.5 Data transfer protocol support
PMU data may be available in different synchrophasor data transfer protocols such as IEEE Std C37.118.2-2011,
IEEE Std C37.118-2005, IEEE Std 1344-1995, IEC 61850-90-5, and new profiles as they become defined. This
function allows a PDC to receive, interpret, and transmit data in the supported protocol. As a minimum, a PDC
should support receiving, parsing, interpreting, and sending data in compliance with at least one synchrophasor data
transfer protocol.
5.6 Data transfer protocols conversion
PMU data may be available in different synchrophasor data transfer protocols such as IEEE Std C37.118, IEEE Std
1344-1995, IEC 61850-90-5, etc. If a PDC supports multiple synchrophasor data transfer protocols, it should convert
synchrophasor data from one synchrophasor data transfer protocol to another to the extent possible.
5.7 Data format and coordinate conversion
Synchrophasor data may arrive at a PDC in rectangular or polar coordinates. In each of these, it may be in fixed
integer or floating-point format. A PDC may convert data between each of these formats, depending on the needs of
the applications used.
5.8 Data latency calculation
Latency, in a packet-switched network, is the delay time between a sender transmitting a packet and a user receiving
it. There are multiple sources of latency, for example: the physical distance between the two ends of the system and
the processing of the packet in intermediate network devices. Because communication traffic volume and errors in
transmission can affect intermediate delays, latency is sometimes not very predictable. Applied to the PMU/PDC
system, synchrophasor data latency could be taken to include the factors just described and also to include factors
such as PMU calculation and processing time, PMUPDC data transmission time, PDC processing time, etc. It will
be different at different points in a hierarchical data network. It will increase cumulatively at successive data
destinations such as the substation PDC, the TO control center PDC, the ISO control center PDC. Examples
showing synchrophasor data latencies for different use cases are given in IEC 61850-90-5.

13

IEEE Std C37.244-2013

In a synchrophasor data network, measurements are made at specific time instances, and they may be made at
physically distant locations. However, with a common, synchronized time source such as a GPS clock, the
measurements are synchronized in time. They are then transmitted to a common location for use by wide area
applications. A representative part of a synchrophasor data network with two synchrophasor data measurement
points is shown in Figure 2.

Figure 2 Example of synchrophasor system with synchrophasor data latencies
Real-time access refers to the PDCs ability to provide synchrophasor data fast enough to meet the destinations
needs. For real-time access, low data latency is important. If the data arrives too late, it may be useless for fast
control applications. Slower applications (such as visualization) can tolerate higher data latency, and a data archive
can tolerate the highest latencies.
The delay experienced by data from any given PMU between the originating PMU and the destination PDC is a
combination of several elements. It is identified as synchrophasor data latency in Figure 2. In this figure, two PMUs
are shown with the same latency (called PMU reporting latency). Data from one of the PMUs arrives at the next
PDC (PDC n) before the other, and the PDC waits for the second set of data before sending both on to the next PDC.
While the time from the arrival of the first data at the PDC to the time the complete set is sent forward is typically
thought of as PDC latency, at least some of the time is actually spent just waiting for the communication network.
Examples or cause of delay (or latency) and typical delay ranges can be found in IEEE Std C37.118.2-2011, Table C.2.
Among these are PDC processing and alignment (2 ms to 2+ s), communication distance (3.4 to 6 s/km),
communication system buffering and error correction (0.05 ms to 8 s), and application input (0.05 to 5 ms). More
details on IEEE Std C37.118.1-2011 latency specification can be found in Annex C.
A PDC may calculate, store, and communicate synchrophasor data latency of the data as it arrives and is validated at
the PDC. It may also support statistical computations to allow for additional latency analysis.
A PDC manufacturer should specify whether synchrophasor data latency calculation is supported. Latency
calculation requires synchronization to a UTC time source such as a GPS clock. The calculated latency values may
14

IEEE Std C37.244-2013

be stored for statistical analysis and reports to the user. These may include functions such as minimum, maximum,
average, deviation, etc., over a specified period. Such analysis would allow assessment of communication network
performance.
Latency calculations could also be performed on archived data, if the archive supports recording of the time of
arrival of the data that has been archived.
5.9 Reporting rate conversion
The reporting rate conversion is defined as changing the reporting rate of a data stream to be different from the input
data stream (e.g., 30 frames per second (fps) to 15 fps, or 30 fps to 60 fps). At the PMU the rate of sampling the
analog input signal is not changed, though the process is sometimes referred to as data resampling. Reporting rate
conversion functions are very useful for merging synchrophasor data arriving at different reporting rates from
different sources. Reporting rate conversion functions are also very useful for converting available data to a rate that
is most suitable for a specific application using synchrophasor data.
A PDC may provide a reporting rate conversion function. This should ideally include both down-conversion and up-
conversion functions. If this function is not provided, it should be clearly stated in the PDCs specification. Any
limitations in the conversion functions should also be specified by the manufacturer.
The PDC should support input rate conversion from all rates specified in IEEE Std C37.118.1-2011 to output
streams having any rate specified in IEEE Std C37.118.1-2011.
Reporting rate conversion should be user-configurable to accommodate the compatibility needs of all the devices
and applications in the synchrophasor system, as well as all the applications that might be using the data from the
PDC.
Proper filtering techniques should be applied when using up- and down-conversion function so that the resulting
data stream remains compliant, to the extent possible, with synchrophasor measurement standard
IEEE Std C37.118.1-2011. Reporting rate conversion impact on frequency, phasor values, and time quality should
be documented by the manufacturer.
In the case of IEEE Std C37.118.2-2011, STAT word bit 9 indicates that data was modified, but does not indicate
the nature of this modification since a great number of possibilities exist. This bit alerts the user to the fact that
modifications have been made and measurement characteristics of the PMU may not be exactly applicable. The
CFG-3 frame includes information on the nature of the modification of a data stream, but not on an individual data
frame basis. This should be sufficient to determine the nature of data modification in most cases. Future revisions of
the standard may include additional information that will provide details of the modification on individual data
frame basis.
If data interpolation or extrapolation are not supported and faster reporting rates are required, the data that was not
present due to lower reporting rate may be set to the absent data value (e.g., NaN, not a number, as specified in
IEEE Std C37.118.2-2011), or the previous data may be repeated. Some applications may need to be made aware of
such data absence.
5.10 Output data buffering
A PDC may buffer output data to reduce data losses in case communication to other PDCs or applications is
interrupted. PDC output buffer time is dependent on factors such as communication robustness, data path
redundancy needs, system architecture, applications, etc. These factors affect PDC memory requirements.
15

IEEE Std C37.244-2013

The data in the output buffer could be re-sent to the destination, if communications are restored within a pre-set time
(output buffer time). The PDC should also indicate unavailability of data in the output buffer if the pre-set time has
been exceeded. However, these data may be available from the local archive.
The PDC may support a procedure or a mechanism for the retrieval of such data.
5.11 Configuration
Configuration management is one of the important essential activities of a PDC. It is designed to assure availability
of appropriate data for the local functions of the PDC as well as other applications that receive data from the PDC.
Configuration information (in frames or files) is used to separate signal identities, data format, and other metadata
from synchrophasor data transmissions. This permits better use of communication bandwidth. Some examples of
such configuration information can be found in IEEE Std C37.118.1-2011 as configuration frames and
IEEE Std C37.111-1999 as files. The configuration data is available as a IEEE Std C37.118 CFG-2/CFG-3
(optional) message, an XML Substation Configuration Language (SCL) file, and through IEC 61850 online data
definition services.
Configuration information is sent by the data source to the data destination ahead of the actual data, to permit the
data destination to interpret the data as soon as it arrives. The configuration information may be sent unsolicited, or
on explicit requests. Unsolicited messages are used in network configurations that, for security purposes, do not
permit PMUs to receive messages. The configuration information may also be sent by destinations to the source,
requesting the source to modify/change the content of the data stream.
Several aspects of handling configuration information are described below.
5.11.1 Configuration information management
A PDC should have available up-to-date configuration information for all input and output streams. It is required to
request appropriate configuration files from PMUs or PDCs whenever it has been off-line for some time, e.g., for
more than one minute as specified by IEEE Std C37.118.2-2011. PMUs are required (by the same standard) to
indicate in their data frames that their configuration has changed, so that the PDC can request a new configuration
file (for example, using CFG-2 configuration frame as defined in IEEE Std C37.118.2-2011). The same mechanism
also applies when a PDC sends synchrophasor data to another PDC.
A PDC should have the ability to retrieve the data stream configuration from a data source (PMU or PDC) after an
incoming data stream interruption and restoration. It could also send the corresponding information to its data
destinations.
A PDC should also have the ability to request a device capability file (a list of all available signals) from data
sources (PMUs, PDCs), combine them, and send the combined list to its data destinations. An example of such a list
is the CFG-1 configuration frame as defined in IEEE Std C37.118.2-2011.
5.11.2 Configuration validation
The PDC should perform a sanity check on the received configuration. This may include checks on the CRC, the
number of bytes expected, and the actual number of bytes received, etc.
16

IEEE Std C37.244-2013

5.11.3 Configuration change management
5.11.3.1 Initiated by data source
The PDC should determine if the configuration has changed by comparing the newly received configuration with the
previously stored configuration.
If the configuration has changed, the PDC should take appropriate action based on user-defined rules to reconfigure
its outputs and communicate the change to all affected output destinations and applications, as far as permissible.
5.11.3.2 Initiated by data destination
This feature allows the control center PDC to configure the whole synchrophasor data network by a set of
configuration change commands to constituent PDCs (at substations). These, in turn, would decode/divide and send
corresponding configuration change commands to their constituent PMUs.
This function may include the following.
A PDC may have the ability to accept a configuration change request from a data destination and modify the
corresponding output stream accordingly.
A PDC may have the ability to split a received configuration change request into appropriate smaller
configuration change requests and send these to its data sources.
A PDC may support a mechanism to communicate acceptance/rejection of configuration change requests
(with reasons) to the requestor.
IEEE Std C37.118.1-2011 and IEEE Std C37.188.2-2011 do not support these functions, however, the IEC 61850-
90-5 profile has full access to dynamic re-configuration functions such as Delete Dataset, Create Dataset, and Set
Dataset Values as well as through the IEC 61850 Substation Configuration Language (SCL). Additionally, all data
values that can be mapped into an IEC 61850-90-5 frame are visible by the receiving device through the Get Data
Definition services.
5.12 Phase and magnitude adjustment
Generally, the PDC function requires the incoming data to be either copied straight into the output data stream, or
converted to a different format (e.g., rectangular/polar, floating/fixed point). The data are expected to be essentially
unchanged. However, at times, a PDC may be required to perform magnitude or phase adjustments on the incoming
signal. There could be two types of such adjustments: calibration type and bulk type. Each of these adjustments is
expected to be set manually, based on calibration factors, phase rotation sequence, transformer ratios, phase angles,
etc.
Calibration type adjustments are those that require small changes to the magnitude/phase of a signal, typically within
5% of the magnitude, or within 5 degrees of the phase. The purpose of calibration adjustments is to correct for
known Type B (systematic) errors in the measurement chain. These may be useful for a PDC, especially for a
substation PDC, but generally, this function is performed in a PMU.
Bulk type phase and magnitude adjustments are those that require large changes to the phase/magnitude of a
synchrophasor signal. These are useful, for example, when a signal needs to be referenced across a transformer (e.g.,
the PMU is connected to the 230 kV side of a transformer, but synchrophasor data are needed on the 500 kV side),
17

IEEE Std C37.244-2013

when the phase identification of the destination system is different (ABC versus ACB) from the source system, or
when the quantities are being referenced across a wye-delta (or star-delta) transformer.
A PDC could have the capability to adjust synchrophasor magnitudes and phases by user-settable parameters. While
it is possible to monitor or compute high-side voltage from the low-side value across a transformer, or vice versa,
magnitudes may be calculated with relative accuracy using the turns-ratio of the transformer. However, phase angles
vary considerably as a function of power transfer. Care should be taken when using this data to make appropriate
angle corrections based on the transformer characteristics.
5.13 Performance monitoring
The PDC is the best place to monitor the overall measurement system. Monitoring should include both real-time
reporting and recorded data for historical assessment. The real-time monitor should demonstrate that the PDC is
currently operating and what the state of operation is. State of operation includes the status of each input and output
and recent operating history.
A PDC may have performance monitoring functions to monitor quality of data and communication with other PMUs
and PDCs. Performance monitoring includes errors, events, and overall system operation. The first category of error
is that reported by the data source which can be a PMU or another PDC. These conditions include loss of time sync,
computation PMU error (as defined in IEEE Std C37.118.2-2011), timestamp error, and invalid data (missing or test
condition). The second error category is communications related issues, such as lost connections (when using a
connected state), buffer overflow, and related issues detectable by the PDC. The third category is internal PDC
problems such as system reset, program error, memory overflow, etc. These error problems may be recorded with a
timestamp and reported.
System monitoring may include logging of
Total number of measurements not received but expected
Measurements received with values out of range, per absolute range checks or model-based data validation
The quality of received synchrophasor data
Measurements received but corrupted
Good data received, but with a bad timestamp so it cannot be integrated as expected
Good data
This logging may be categorized by input device so the performance of each input can be assessed. Any periodic
totals and statistics could also be provided, as further described below.
Special monitoring functions may be required for special applications and requirements. Latency in data reporting
can be monitored for controls or communication performance statistics. The PDC can timestamp the arrival and exit
times of the various messages and compute various latencies based on these timestamps. In cases where PMU data is
sent from redundant sources, the PDC should select the best data based on the data quality as defined by the user. In
these systems, monitoring can provide statistics regarding the performance of each source or path. Other special
functions not yet planned will be implemented and appropriate monitoring will be required. Monitoring is required
for every function to assure performance and provide a means for assessing needs for further development.
The PDC may allow the user to designate a preferred source for data to be included in an output stream. The PDC
may also permit the user to designate alternate source(s) for the output stream if the preferred data fails to arrive.
The criteria for such alternate data source selection may include time quality bits, PMU status bits, first data to
18

IEEE Std C37.244-2013

arrive, preferred data source, lack of data from one device, etc. When possible the PDC should indicate in the output
stream that the alternate data source is used.
The PDC may have some kind of mechanism to prevent repeated errors from overfilling the buffer or causing other
problems.
Monitoring synchrophasor system conditions that affect performance may also be provided by the PDC, for
example, loss of communication links, resets, configuration changes, etc.
Since various errors or good data counts can be large, the logging may include total numbers as well as periodic
totals by minute or hour, rather than individual timestamps. Statistics could also be provided.
Indications and alarms could also be generated.
Information storage structure and data access mechanisms to the performance monitoring parameters are vendor
specific, and are not covered in this document. Traditional data storage has been in files. Newer systems store data
directly to a database or historian. These newer approaches are easier and faster to use but require more storage
space and software to operate.
5.14 Redundant data handling
To support redundancy the PDC may receive redundant data. Redundant data are clearly distinct, and the PDC may
deal with them as though they are separate data. The PDC should be able to handle redundant data sent either in
aggregated or time aligned PMU streams.
The PDC may allow the user to designate a preferred source for data to be included in an output stream. The PDC
may also permit the user to designate alternate source(s) for the output stream if the preferred data fails to arrive.
When possible the PDC should indicate in the output stream that the alternate data source is used.
5.15 Duplicate data handling
The PDC may receive duplicate data in time aligned and aggregated data streams or data sent by alternate
communication paths and may need to handle it so that duplicate data are not propagated.
The PDC should be capable of discarding all data duplicates. For example, a PDC may use the data that arrives first,
and discard the duplicate data that arrives later.
5.16 Data re-transmission request
During data transmission between a PMU and a substation PDC, or between a substation PDC and a control center
PDC, it is possible that the data never arrives at the destination. This could easily happen with UDP frames. It is also
known to happen with TCP frames, when the data connection is dropped after a reaching a timeout and has to
be re-established.
The data source (e.g., a PMU or a PDC) may support data storage to handle this situation. This storage need affects
PDC memory requirements.
The data source needs to be made aware that the data has not reached its destination. A PDC may implement a data
retrieval mechanism to request the data source to re-transmit the data that failed to arrive.
19

IEEE Std C37.244-2013

Such a mechanism is not supported by the synchrophasor protocols IEEE Std C37.118-2005, IEEE C37.118.2-2011,
and IEC 61850-90-5. However, there is a need for the implementation of such a function to recover data. While
presently there is no standard, proprietary mechanisms exist in the industry. Until standards are developed for this
function, the mechanism may be developed by an implementation agreement between different vendors.
5.17 Cyber security
Cyber security may be governed by the application, regulatory compliance, or best practices. At a high level, cyber
security for information technology (IT) focuses on three aspects of the electronic information communication
systems:
Availability
Integrity and authenticity
Confidentiality
Availability is typically addressed by redundancy and security measures to prevent denial of service attacks.
Integrity is the validity of the data and authenticity ensures the correct source. Integrity and authenticity are
accomplished through means such as digital signatures or various types of authentication codes (e.g., message
authentication code [MAC], or hash-based message authentication code [HMAC]).
Confidentiality is achieved by preventing inadvertent disclosure of information and is accomplished through the use
of encryption, access control, and the appropriate processes and procedures.
When applied to PDCs, cyber security should evaluate all PDC interfaces while maintaining the reliability of the
PDC. PDC cyber security likely goes beyond simply securing synchrophasor communications, but any
communications and access to the PDC. Security practices that are poorly applied to PDCs may degrade PDC
performance and/or functionality.
A PDC may be connected to untrusted networks as well as PMU(s). Securing those network connections is more
than just securing synchrophasors and is beyond the scope of this guide.
The PDC may need to implement access controls, firewalls, intrusion detection functions, and more. Several
standards help cyber security practices and programs. The following standards specify functions relevant to cyber
security beyond synchrophasors: IEEE Std 1686 [B9], IEEE PC37.240, D13.0, March, 2013 [B17] and IEEE Std
1711 [B10].
IEEE Std 1686 specifies:
Electronic access control (password defeat mechanisms, number of passwords supported, password
construction, role-based access control)
Audit trail/logging (capacity, information to be stored, events, alarms)
Supervisory monitoring and control (events, alarms, permissive control)
Configuration software (access, permission, version control)
Communications port access (port control, data transmission encryption)
Firmware quality assurance
20

IEEE Std C37.244-2013

PDCs may be required to support centralized access control protocols (such as Lightweight Directory Access
Protocol [LDAP]), and to implement firewall and intrusion detection functions. PDCs may be capable of
interrogation by security monitoring tools that identify the running state, firmware, configurations, and other
relevant information. Logging capabilities to track system states and changes for forensic examination will probably
be provided.
Proposed IEEE PC37.240 Draft D13.0, March, 2013, Draft Standard for Cyber Security Requirements for
Substation Automation, Protection, and Control Systems, is one standard presently under development which
specifically addresses technical requirements for substation cyber security and presents sound engineering practices.
IEEE PC37.240 Draft D13.0 presents the minimum requirements and best practices for a substation cyber security
program, keeping in perspective the technical, economic, and operational feasibility of deployment. A utility
deploying a cyber security program which meets the requirements of this standard will have developed a program
which considers all of the above elements, and represents the best practices as employed by the industry.
IEEE Std 1711-2010 defines a cryptographic protocol known as Substation Serial Protection Protocol (SSPP). SSPP
provides for the integrity and optional confidentiality of asynchronous serial communications. SSPP assures serial
message integrity, that messages are not modified, forged, spliced, reordered, or replayed. SSPP provides this
assurance by encapsulating each message in a cryptographic envelope. When an integrity problem arises in an
incoming SSPP message, whether due to communications errors or malicious actions of an adversary, SSPP simply
ignores the message. Detection and retry of ignored messages is left to the application. SSPP supports several cipher
suites that provide differing security properties. All cipher suites assure integrity. Some suites also provide
confidentiality, although this property is a secondary goal of the design. SSPP is largely independent of the
underlying communications and is suitable for implementation in end devices or bump-in-the-wire devices. Using
IEEE Std 1711-2010 comes with a price in bandwidth requirements, adding significant overhead depending upon
the existing channel bandwidth and IEEE Std 1711-2010 implementation.
IEC 61850-90-5 refers to IEC 62351-5 and IEC 62351-6 [B4] and specifies:
Information integrity and authenticity is required (authentication)
Confidentiality is optional (encryption)
IEC 61850-90-5 provides for application-layer protocol data unit (APDU) authentication by the use of a digital
signature code. Although it is desirable to provide end-to-end authentication and integrity protection, such protection
cannot be assured if the contents of multiple APDUs are repackaged into another APDU. Such repackaging may
occur within the PDC and the new packets should include the digital signature of the original packets.
IEEE Std C37.118.2-2011 is a data transfer standard covering messaging and message contents. It can be used with
any communication protocol and consequently does not include cyber security requirements. The most common
implementations use raw TCP and UDP without cyber security. For cyber security other security methods such as
virtual private networks (VPNs) and secure socket layer (SSL) should be followed.
As cyber security standards and practices evolve, care should be given to addressing synchrophasor latency that may
be introduced by applying security measures to a PDC.

21

IEEE Std C37.244-2013

6. PDC performance requirements
This clause specifies the performance requirements for some PDC functions, and follows the functional
requirements.
6.1 PDC latency
6.1.1 PDC latency overview
This subclause covers an overview of the factors that affect the synchrophasor data latency and loss of data (refer to
Figure 3). These factors include the latency of the data from the PMU, the latency caused by the network between
the PMUs and the PDC, the latency caused by the network between the PDC and higher level PDCs, the PDC
operation mode, and the PDC data processing completion time. This overview focuses on those factors that are
related to the PDCs. The latency issues related to the PMU are covered in the IEEE Std C37.118.1-2011,
IEEE Std C37.118.2-2011 and IEEE Std C37.242
TM
-2013 Guide for Synchronization, Calibration, Testing, and
Installation of Phasor Measurement Units (PMU) for Power System Protection and Control. The latency issues due
to the interconnecting networks are outside of the scope of this document.
At any point in the progress of data from a PMU through possible multiple levels of PDCs, the latency of the data is
defined as the difference in time interval between the timestamp on the data and the UTC time for the point in
question. For this overview the main points of interest are the PMU timestamp value, the UTC time of the data
arrival at the input of the PDC and the UTC time of the data departure at an output of the PDC. The latency through
the PDC depends on the operating mode of the PDC.
6.1.2 PDC latency dependency on PDC operation mode
As stated earlier, the PDC latency is dependent on the PDC operation mode. PDC operation modes are described in
5.1 and 5.2 of this guide and include
Data aggregation (with and without time alignment)
Data forwarding
Data aggregation with time alignment can be further divided into time alignment to absolute time reference and time
alignment to relative time reference.
Included below is a description of the PDC latency for the PDC operation modes described above. It also includes a
consideration of the tradeoff between latency and lost data, if applicable. The descriptions consider the possible
parameter settings and their effect on latency.
Since there is a tradeoff between latency and lost data for some of these modes, the following discussion includes
both of these factors.
The interaction of multiple input and output data streams; each receiving or generating asynchronous content, may
lead to unpredictable PDC performance. This document describes the PDC operation under nominal conditions.
6.1.2.1 Data aggregation with time alignment to absolute time
Consider the case of data aggregation with time alignment to absolute time. The applicable parameters are the
arrival time of the first complete message with a given timestamp, communications latency, data rate of the PDC
output, the absolute wait time, the timestamp time being aligned, and the PDC processing time.
22

IEEE Std C37.244-2013

The PDC latency starts when the first complete data message with a given timestamp arrives at the PDC. The worst
case PDC latency is the absolute wait time, plus the PDC processing completion time. Any data that arrives later
than its timestamp time plus the absolute wait time is lost for that output. PDC latency for data aggregation with
time alignment to absolute time is shown in Figure 3.

(a) no data is lost (b) data is lost
Figure 3 PDC latency for data aggregation with time alignment to absolute time
The absolute wait time starts at the timestamp time, shown as time 0 in Figure 3. If the last data arrives before
the absolute wait time has passed, the PDC begins processing immediately, and the PDC latency is as shown in
Figure 3 (a), about 5 time units. If the last data arrive after the absolute wait time, PDC processing will already have
begun (at time 8 in Figure 3 [b]). The PDC latency is a little longer (about 6 time units). However, the last data
(shown cross-hatched in the figure) will not be processed.
6.1.2.2 Data aggregation with time alignment to relative time
Consider the case of data aggregation with time alignment to relative time. The applicable parameters are the arrival
time of the first complete message with a given timestamp, communications latency, data rate of the PDC output, the
relative wait time, and the PDC processing time.
The PDC latency starts when the first complete data message with a given timestamp arrives at the PDC. The worst
case PDC latency is the time of egress of the output data minus the time of the first data arrival at the PDC. This
latency will be approximately the relative wait time, plus the PDC processing time. Any data that arrives later than
the end of the relative wait time is lost. PDC latency for data aggregation with time alignment to relative time is
shown in Figure 4.

23

IEEE Std C37.244-2013

(a) no data is lost (b) data is lost
Figure 4 PDC latency for data aggregation with time alignment to relative time
6.1.2.3 Data aggregation without time alignment
Consider the case of data aggregation without time alignment. The applicable parameters are the arrival time of the
first complete message, the PDC user-configurable data collection period (for IEC 61850 system, this is equal to
input buffer time), and the PDC processing time.
The PDC latency starts at the arrival time of the first complete message during PDC data collection period. The
worst case PDC latency will be approximately the PDC data collection period plus PDC processing time. Any data
that arrives at the PDC is forwarded by the PDC so no data is lost.
6.1.2.4 Data forwarding
Consider the case of data forwarding. The applicable parameters are the time of the arrival of the complete data
message, and the PDC processing time.
The PDC latency starts at the time of arrival of the complete data message. The worst case PDC latency is the time
of egress of the output data minus the time of arrival of this message at the PDC. This latency will be approximately
the PDC processing time. Any data that arrives at the PDC is forwarded by the PDC, so no data is lost.
6.1.3 PDC latency requirement
PDC latency is an important measurement and its value should be agreed to between the manufacturer and the user
for a given PDC operation mode employed by the user. Some of the factors affecting the latency are: number of
phasors, number of input data streams, number of data processing functions in operation, size, and number of output
data streams, etc. If a PDC is a part of network of multiple PDCs, then the latency of the entire network need to be
considered.
24

IEEE Std C37.244-2013

6.2 Robustness
A PDC should be robust and able to withstand off nominal conditions. Such conditions may include too much
incoming data, incorrect timestamps, unsupported protocols, etc.
6.3 Environmental
A PDC should be compliant to environmental standards, e.g., IEEE Std 1613
TM
-2009 and Amendment 1-2010 [B8],
IEC 61850-3 [B2], as applicable based on system design and PDC location.
6.4 Availability and reliability
A PDC should meet availability and reliability requirements consistent with the applications. Reliability is a
parameter that can be allocated. That is, reliability goals can be set for individual subsystems (of which the PDC
may be one) in order to reach a specific reliability goal for an overall system. Such a technique requires that the
development effort and risk be balanced among the subsystems. Such considerations are beyond the scope of this
guide.
6.5 PDC data processing
PDC manufacturers should specify the impact of PDC data processing as maximum magnitude difference,
maximum phase difference, and maximum phasor value difference between the input data and the output data. PDC
manufacturers should also specify the maximum PDC latency under any given configuration, as stated in 7.1.3. PDC
data processing may include filtering, reporting rate conversion, interpolation, extrapolation, phase and magnitude
adjustment, etc. For each of these cases a test method should be developed specifying well-defined inputs and
expected outputs.
7. Testing
This clause describes PDC testing and includes test outlines for some of the PDC functions. A few examples of
practical methods for testing many PDC functions are also described to help the users with identifying some of the
tools needed for the tests. As measurement systems and the deployment of applications are evolving, the functions
of the PDC have expanded to include more functions in data handling, processing, and storage. At the same time, the
rapid growth in technology is enabling the development of integrated PDC functions for power systems applications.
Since different PDCs may have different functions, some of the tests in this clause may be relevant to the PDC that
supports those specific functions. Refer to Clause 5 for the functional requirements for those functions that may be
included in a PDC.
Testing can be divided into several categories including certification tests, conformance test, performance tests,
application-specific tests, commissioning tests, and maintenance tests. For example, IEEE Std C37.233 [B14]
defines various types of tests for power system protection testing. In the following clause, specific PDC test types
are discussed.
7.1 Categories of PDC tests
Different categories of tests specific to PDCs are described below.
25

IEEE Std C37.244-2013

7.1.1 Conformance tests
Conformance tests are performed to verify that a specific PDC meets all the requirements of a given set of standards.
The standards need to be specified and the date of the standard included. If the actual tests are not clearly defined in
the standard, the description of the actual test along with explanation of how the test satisfies the requirement in the
standard needs to be included with the certificate of conformance.
7.1.2 Design tests
Design tests are vendor-specific verification of a specific PDC design. The functional specifications should be
provided by the vendor at the time of product delivery. The functional specification should include references to all
the standards that the PDC complies with. The design tests need not include a duplication of conformance tests.
7.1.3 Type tests
Type tests are typically a subset of design tests. Type tests should cover selected core PDC functions and verify
PDC performance for these functions. Such tests are performed during the PDC production cycle to verify that a
given product or product batch meets product functional requirements. In addition some of these tests may be
repeated as a part of the routine maintenance test procedures.
7.1.4 Interoperability tests
PDCs are expected to be a part of system solutions that may require a certain level of interoperability. The
interoperability relates to all the interfaces shown as arrows in Figure 1. Interoperability can be considered an
additional layer of performance requirements, and where deemed necessary, interoperability tests need to be
implemented and performed. The implementation of interoperability tests requires that the product has passed
standards conformance tests.
7.1.5 Commissioning tests
Commissioning tests are used to verify proper PDC installation and operation upon delivery. These may include all
or some of the following: type tests, application-specific tests, conformance tests, and interoperability tests. In
addition, the commissioning tests also include routine tests of consistency of basic installation properties, such as
wiring, startup, re-boot, communication port assignment, etc.
7.1.6 Field tests
Field tests are used to verify proper PDC operation after it has been commissioned. The tests themselves can include
some of the type, application-specific, conformance, or interoperability tests. Maintenance tests are a type of field
tests, and may be performed periodically. Various scenarios may require field testing at selected time intervals other
than regularly scheduled tests (e.g., evaluation after a major upgrade, troubleshooting, etc.).
7.1.7 Cyber security tests
Cyber security tests should be used to verify that a PDC conforms to cyber security requirements and policies that
are in place at the time the application is deployed.
26

IEEE Std C37.244-2013

7.1.8 Application-specific tests
Application-specific tests are aimed at verifying functionality and/or performance of PDCs when supporting
particular applications that use synchrophasor data. These tests require knowledge of the PDC connection
architecture, including its physical location in the context of the installation and its application. Application-specific
tests are not covering the PDC design, but its performance as it relates to the final outcome of the PDC function that
makes sure the application meets expected requirements. To perform such tests, an additional set of PDC
requirements that reflects the application performance may be defined.
7.2 Test interfaces
PDC interfaces that can be used in various PDC tests are shown in Figure 5, where solid arrows indicate interfaces
that usually exist, and dotted line arrows indicate other possible interfaces. These include
Communications interfaces for PDC input and output data streams
Time synchronization interface
User interface (UI)
Database interface
Application programming interface (API)

Figure 5 PDC test interfaces
7.2.1 Communications interfaces
Communications interfaces support PDC input and output streams. These interfaces are expected to be used in most
test setups.
27

IEEE Std C37.244-2013

7.2.2 Time source interface
A PDC under test may need to be connected to a time source, e.g., a GPS clock. Corresponding test setup
may include the interface between PDC and GPS, as well as between GPS and testing tools and equipment.
The PDC may be connected to GPS directly (using internal GPS receiver), or via IRIG-B or Ethernet (per
IEEE Std 1588
TM
-2008/IEEE Std C37.238-2011 [B15]).
7.2.3 User interface
Testing of a PDC is expected to include user interface functions allowing configuration and interaction with the
PDC under tests, as well as testing the user interface performance itself.
7.2.4 Database interface
In instances where a PDC is expected to send synchrophasor or other data into a local or centralized database for
further use, it is expected to have a set of test procedures to allow this feature to be tested. In this case, test setup
may include interfacing to the database as well.
7.2.5 Application programming interface
When the use of PDCs API is required, a test may be needed to verify the functionality. This is especially important
when PDCs are integrated in system solutions and integration tests are specified.
7.3 Test setups
Various setups may be required depending on test types and locations. Offline test setup can be used to test a PDC
independently and online test setup can be used to test an installed PDC. Figure 6 depicts a test setup where a PDC
is tested independently and is interfaced only with testing tools. In such a configuration, PDC input streams are
generated artificially using a PMU simulator, and the PDC output is captured or monitored using a PDC simulator
and/or PMU/PDC connection tools. In some cases, depending on test requirements, the PMU simulator and/or the
PDC may need a connection to a GPS clock. It is assumed that the PMU and PDC simulators are part of a test tools
suite that allows for implementation of tests based on a given test specification. This test setup is suitable for lab and
offline testing with steps described below.
28

IEEE Std C37.244-2013

Figure 6 Offline test setup for testing a PDC independently
The PDC under test is first configured based on the test plan. Then for each test case, the PDC input streams (i.e.,
PMU data) are sent to the PDC and the PDC output streams are captured. The entry time when the input data frames
arrive at the PDC (PDC latency start event) and the exit time when the output data frames leave the PDC (PDC data
egress time) are recorded; refer to Figure 11. The PDC input and output streams are compared based on the
timestamps, and are used for further evaluation. The recorded times can be analyzed to verify the PDCs
functionality that involves time, such as confirming the waiting time in the situation with missing data or late data.
Different scenarios are possible, including a varying number of input and output streams, data rates,
communications protocols, data formats, etc. Such a test setup can also be used to evaluate performance
characteristics (e.g., PDC latency, processing times, accuracy, etc.).
An online PDC test setup is shown in Figure 7. In this setup, it is assumed that a PDC under test is already installed.
In this scenario, test tools include PMU/PDC listeners that interface with the PDC communications (PDC input and
output streams). The synchrophasor data coming from several PMUs (or other PDCs) is listened to and captured
for later comparison with corresponding data captured from the PDC output stream. Monitoring of these tests uses
PMU/PDC listeners, captured data, and test logic to evaluate test results and create test reports.
29

IEEE Std C37.244-2013

Figure 7 Online test setup for testing an installed PDC
Implementing online testing is more challenging since the listeners have to capture all messages and data streams on
the PDCs input and output. The entry time when the input data frames arrive at the PDC (PDC latency start
event) and the exit time when the output data frames leave the PDC (PDC data egress time) are recorded; refer to
Figure 11. The input and output data frames are aligned based on the timestamps and are used for further evaluation.
The recorded times can be analyzed to verify the PDCs functionality that involves time, such as confirming the
waiting time in the situation with missing data or late data. In addition, the presence of the test tools in the system
should not interfere with the required performance of the PMU/PDC network. Test tools require additional
intelligence or configurability to be able to properly capture test data and evaluate this data according to the test
cases.
7.4 Tests outline
PDC functions described in Clause 5 should be properly tested to verify their functionality. The tests to be
performed on a particular PDC should be determined by the functions supported by the PDC to be tested.
The subclauses below provide an outline of the tests to be performed for a number of the functions described in
Clause 5. A comprehensive test plan should be developed based on the functions supported by the PDC to be tested.
7.4.1 Time tests
Timing and synchronization are critical elements for several functions described in Clause 5 (e.g., wait time,
synchrophasor data latency calculation, etc.). If a PDC is synchronized to an accurate UTC time source, verifying
the PDCs proper operation in response to problems that may occur due to clock drift and impaired timing signals is
30

IEEE Std C37.244-2013

essential to achieving a well-functioning system. It is also necessary to confirm the PDC applies time for internal
functions properly. The parameters and conditions that can be tested to determine the effect of clock and time
variances on the PDCs performance are described below.
7.4.1.1 Loss of timing signal
When required by application and supported by a PDC, a PDC should be tested in conditions relevant to the loss of
its input timing signal. This may include loss of GPS signal to the time source and checking the time quality
information generated by the source, loss of the physical timing input connection to the PDC, or, if using a time
distribution network, blocking, or delaying time synchronization signals by using network impairment devices.
7.4.1.2 UTC and local time
A PDC may have the ability to use UTC for calculating PDC latency and local time for event records and time
display. A PDC may be tested for configuration requirements and its ability to apply either UTC or local time. The
details of the testing depend on how the PDC determines the time reference. As a minimum, if the PDC provides
latency measurement functions based on PMU timestamps (which are in UTC), the PDC can be tested with UTC
time input.
7.4.1.3 Date and time change
When a PDC can accept (or provide) local time information for event records, time display, or deriving the UTC, the
PDCs timing functions should be tested to ensure it accommodates date and time changes, such as daylight savings
time, leap year, and leap second. The test may take place during an actual change event or by simulated conditions
where the clock signal represents the behavior and timing information of the change.
7.4.1.4 PDC timestamping accuracy
If a PDC is synchronized for the purpose of applying timestamps to internal processes, the accuracy of that time
needs to be checked. Internal PDC processes may delay time reading, event detection, or other assignment of a
timestamp. For each function that uses accurate time, there needs to be a reference test with known parameters that
can be used to determine that the time is being accurately assigned. For example, a time of arrival function can be
tested by sending data at a precise time and checking the measured time of arrival. These tests should be performed
at various PDC loading and configurations to assure operational issues will not cause further interference.
7.4.2 Data communications tests
Communications testing should be specific to the mechanism(s) supported by the PDC. These should include testing
the physical ports and channels, TCP/UDP, IPv4, IPv6, serial communications, etc.
The testing should include verification of PDC communications with its data sources (PMU and/or other PDCs) and
data destinations (other PDCs).
The testing should verify all command operations (such as data start, data stop, request for configuration
information, etc.), and responses to such commands.
It should include testing for unicast and multicast data streams.
31

IEEE Std C37.244-2013

Testing for abnormal situations should include communications recovery after a loss of a communication channel, a
reboot of an intermediate communications device, etc. Alternately, these tests may be conducted as a part of the
system robustness tests.
7.4.3 Configuration tests
Configuration function deals with the metadata associated with both PDC input and output data streams. Any tests
performed on the configuration function should be performed at both input and output ends. The following
paragraphs describe the tests that could be conducted.
Verification of data stream consistency with the configuration information may include the tests for the sequence of
signals included, the data format used, etc. These tests depend on the details of the synchrophasor data transfer
protocol being supported.
Testing the PDC when there is unsolicited configuration information should be performed by using a deliberate
communication interruption, or a restart of the data source.
A data source implementing a change in the data stream, and indicating such change to the data destination, should
be tested. This should include testing the receiving PDCs ability to implement the change. The details of the
changes that may be tested depend on the specific metadata attributes supported by the synchrophasor data transfer
protocol in use.
The data destinations ability to request device capability (for example, by using CFG-1 frame, if
IEEE Std C37.118.2-2011 is used) should be verified with the actual capability of the data source.
The PDCs ability to perform a sanity check on the received configuration information may be tested by using a
PMU simulator to insert deliberate errors (such as a wrong data size, etc.) in the configuration information and
assessing the PDCs response to such errors.
7.4.4 Data tests
These tests are used to verify the different functions of a PDC that handle the data passing through it. These tests
may be performed by supplying the PDC with predetermined data, using a PMU simulator, and comparing the PDC
output with the known data sent to it.
7.4.4.1 Input data validation
A PDCs ability to validate the received data may require inserting deliberate errors in the PDC input stream and
verifying the PDCs performance under such controlled error injection. This may require using PMU simulators
and/or network noise generators.
7.4.4.2 Data aggregation
The data aggregation function may be performed with or without time alignment, thus these cases should be tested
separately. Data aggregation can be tested by setting up multiple data streams as inputs to a PDC, and verifying the
contents of the output stream for the data content, based on the various test configurations. Input streams may be set
up using multiple PMUs (which could be expensive), or synchrophasor data stream simulators. The output stream
can be captured by another PDC or a synchrophasor data listener, and saved for data comparison
32

IEEE Std C37.244-2013

7.4.4.2.1 Data aggregation with time alignment
Data aggregation with time alignment can be tested by verifying that an aggregated data from output represents the
input data measured at the same timestamp and data aggregation function waits for data until the specified time
(wait time) before sending out the aggregated frame.
7.4.4.2.2 Data aggregation without time alignment
Data aggregation without time alignment can be tested with a similar setup. The rules for data acceptance in the
output stream are different, based on periodic data transmission, regardless of timestamps.
7.4.4.3 Data forwarding
The data forwarding function can be tested by methods similar to those used for testing data aggregation without
time alignment.
7.4.4.4 Data format and coordinate conversion
Data format/coordinate conversion testing aims to confirm the correct conversion from one data format to another or
from one coordinate to another by a PDC. For this test, a PDC should be configured to have different data formats in
its input and output streams. Depending on the synchrophasor data transfer protocols in use, there could be different
data formats supported, such as fixed and floating point for scalar magnitudes, and polar or rectangular for phasors.
7.4.4.5 Synchrophasor data transfer protocol support and conversion
Synchrophasor data transfer protocol conversion testing aims to confirm the correct conversion from one protocol to
another by a PDC. This test requires a prior, independent testing of each of the synchrophasor data transfer protocols
supported. It also requires a mapping of all the data points from one synchrophasor data transfer protocol to the
other, and a definition for the handling of unmapped quantities. These are specific to the synchrophasor data transfer
protocol(s) supported by the PDC, for example, IEEE Std C37.118.2 and IEC 61850-90-5.
7.4.4.6 Phase and magnitude adjustment
This function may be tested by comparing a PDC input stream with the output stream generated by the PDC, and
verifying that the data change is consistent with the magnitude and/or phase change settings of the PDC. The data
source for this test may be a PMU or a PMU emulator.
7.4.4.7 Reporting rate conversion
The tests for reporting rate conversion should include both up-conversion and down-conversion. The data/frequency
content of the output data should be consistent with the filter used (if any). The test criteria should be consistent with
the PDCs specification for the frequency response for a given case (for example, if the data after passing through
the PDCs down-conversion filter used is expected to meet the IEEE Std C37.118.1-2011).
The PDC may use an absent data tag (such as NaN, used in IEEE Std C37.118.2-2011) insertion in an up-converted
data stream. The test in this case could consist of verifying the existence of this tag, at the correct timestamps in the
PDC output stream.
If the synchrophasor data transfer protocol in use supports an indication of modified data in the PDC output stream,
the test should also check for such an indication.
33

IEEE Std C37.244-2013

7.4.5 Performance monitoring tests
A PDC may support various performance monitoring functions for parameters such as errors, events, data quality,
etc. It may also generate alarms when such parameters exceed preset limits.
The tests for performance monitoring functions depend on the specific details of the supported functions. These may
be tested by using a PMU emulator to supply data to the PDC, inserting deliberate, controlled errors or delays, and
assessing if the PDC performance monitoring functions correctly report errors and current conditions.
7.4.6 Application-specific tests
If a PDC supports any application functions, such as data storage, event detection, etc., it should be tested on such
functions, as may be required by the application.
7.5 Test reporting
7.5.1 One-time tests
For some tests, it may be sufficient to perform the test procedure only once. This is typically the case with PDC
functions that are not subject to frequent changes. For example, various data formats, data communications
protocols, and conversions may stay unchanged for the lifetime of a PDC.
7.5.2 Statistical tests
Some tests may require multiple repetition, and statistical evaluation of the outcome. This is typically the case with
any test that may include random errors such as noise in communications channels and communications failures.
7.5.3 Periodic tests
Periodic tests are common when a PDC is tested for time synchronization consistency, e.g., when time
synchronization uses a direct connection to GPS, a connection via IRIG-B or IEEE Std 1588-2008/
IEEE Std C37.238-2011 over Ethernet.
7.6 Testing tools
Testing tools consist of a combination of various hardware and software tools that allow manual and/or automated
testing based on PDC requirements. Figure 8 shows a very basic approach to analyze given PDC requirements and
creating acceptance tests. The acceptance tests are implemented using testing tools that allow interfacing with the
PDC under test and test reporting. Testing tools can be in a form of individual applications or software libraries.

Figure 8 Generic setup for PDC testing using testing tools
34

IEEE Std C37.244-2013

7.6.1 Tool classification
Testing tools could support offline and online testing, in the laboratory or in the field. For the offline testing, as
shown in Figure 6, the testing tools directly interface with the PDC under test and generate PMU/PDC streams, and
capture the PDC output stream. Testing tools use generated input streams and receive output streams for analysis of
data and test reporting. The offline tests can be performed either in laboratory or field environments.
For online testing, as shown in Figure 7 the testing tools are expected to interface to installed PMU/PDC by using
data stream listeners that should not affect the PMU/PDC operation. Testing tools for online testing should be able
to capture data within predefined or desired time periods so that data from the input streams can be compared with
corresponding data in the output data stream of the PDC under test.
7.6.2 PMU emulators
A PMU emulator is critical for performing offline testing of PDCs. PMU emulators should provide realistic PMU
data streams, desirably in various communication protocols (e.g., IEEE Std C37.118.2-2011), with various
parameters (e.g., data rate, TCP/UDP). In addition, a PMU emulator should have the ability to emulate multiple
PMU/PDC data streams.
7.6.3 Communication emulator
A communication emulator may be needed to model scenarios with network issues (e.g., noise in communication
channels, loss of incoming or outgoing communication, etc.).
7.6.4 PDC/PMU connection tool
The PDC/PMU connection tool is used for capturing and validating data coming from a PDC under test. This tool
may be connected to the output stream of the PDC under test, and will interact with the PDC with commands to
control the PDC output data and configuration information. PDC connection tools are expected to be used mainly in
offline and laboratory test setups.
7.6.5 Data sniffing tools
Data sniffing tools for both input and output streams are used in various test scenarios, for both online and offline
testing, as well as in the field and in laboratory test setups. Data sniffing tools are able to record input and output
data within predefined or desired time, and verify the captured data using input data, configuration, and given
requirements. These tools do not interrupt the data flow, nor do they interact with the PDC with commands to
control the PDC output data. However, they may capture and interpret commands normally flowing between the
connected devices.
7.6.6 PDC test reference library
PDC test reference library is a convenient tool for PDC testing. It is a library of PDC functions used as a reference
when evaluating the PDC under test. When testing a PDC, depending on the requirements and user needs, several tests
may be required, refer to Figure 10 for a typical model. The tests can be organized into a PDC test suite that may be
generic or customized. Figure 9 shows an example of how the test data can be collected prior to running the test cases
from the PDC test suite using reference library. In this case, the criterion to capture the test data is a time window
defined by the timestamps of interest. The test captures all data from PDC input stream(s) with timestamps between
35

IEEE Std C37.244-2013

T
start
and T
end
. The corresponding data from the PDC output stream that are timestamped between T
start
and T
end
are
captured as well. Both sets of collected data represent the test data that should be used with the PDC test suite.
It is important to note that test data collection in the presented approach works the same way for both online and
offline test setups, refer to Figure 6 and Figure 7. X1, X2, to Xn are sets of PMU data captured based on their
timestamps and predefined time windows start and end times. The aggregated PDC output stream correspond to the
same time window, and contains sets of data labeled as Y1, Y2, ..., Yn.
The transformation from the input data Xi into the output data Yi may include combinations of several PDC
functions such as data format and coordinate conversion, communication protocol conversion, phase and magnitude
adjustment, etc. When defining tests, the testers need to be familiar with the specifications of the PDC under test, as
well as the configuration and desired application requirements: those parameters help the user determine which tests
to perform and how to define test plans. The selected tests and their test plans constitute the PDC test suite.

Figure 9 Collecting test data for use with PDC test suite

When executing tests from the PDC test suite, the collected data sets Xi are passed to the PDC reference library
functions, and the results are matched against data sets labeled as Yi. The recorded times at the entry of Xi and at the
exit of Yi can be analyzed to verify the PDCs functionality that involves time, such as confirming the waiting time
in the situation with missing data or late data. In some tests such as detecting loss of data and verifying data
aggregation, all data sets will be used. Examples of functions from the PDC reference library are given in Table 1.
Functions used for testing a particular PDC should match the requirements for that PDC.

36

IEEE Std C37.244-2013

Table 1 PDC reference library function examples
Function Description
Data validation
As a minimum check the IEEE Std C37.118.2-2011, format to include status of the
time quality of all input streams, and perform CRC check on all received data.
Reporting rate conversion
Changing the reporting rate of the output stream to be different from the input stream
(e.g., 30 fps to 15 fps, or 30 fps to 60 fps). The test reference library may need to
include variants of down-conversion and up-conversion to enable a user to pick those
that match specifications of the PDC under test.
Data aggregation with time
alignment
Aggregate and align data from all input data streams according to their timestamp
(not their arriving order or time), to preserve time quality and UTC synchronization
indication.
Data aggregation without time
alignment
Combine multiple variants of input streams into a single output stream to verify that
the result matches specifications of the PDC under test.
Synchrophasor data latency
calculation
Calculate synchrophasor latency for different settings for maximum wait time for
input data streams, to compare results with specifications of the PDC under test.
Configuration validation
Validate configuration and capability to recognize configuration changes, capturing
relevant PMU-PDC messaging.
Data format conversion Provide conversion between integers and floating point data formats.
Data coordinate conversion Provide the coordinate conversion between polar and rectangular formats.
Communications protocol
conversion
Verify support for different communications protocols at the PDC input, and check
that communications protocol conversion is performed per specifications of the PDC
under test.
Phase and amplitude
adjustment
Provide configurable phase and amplitude adjustment processing to be checked
against the PDC under test.
Communications validation
Detect loss of communications and check configurable internal buffering to compare
results with specifications of the PDC under test.

7.6.7 Tests programming
PDC testing tools may include capabilities for scripting and programming of the tests based on given PDC
requirements (generic or custom) to allow automated test execution whenever possible. Automated testing can
significantly reduce test times where possible. The test automation should include PMU data generation
(simulation), PDC output data capturing, PMU/PDC listeners, data processing, and associated tests on the input and
output streams (generated or captured).
Each PMU (or PDC) that is feeding data into the PDC under test, as well as the PDC under test, may have various
configuration settings, and those settings need to be known when defining the PDC test suite. The PDC under test may
be configured for different rates, aggregation; data format and coordinate conversion, communications protocols, etc.
Scripting and programmable features are used to define individual tests that can be organized into a PDC test suite.
A PDC test suite example is shown on Figure 10. Tests definition assumes that collected test data are passed to the
PDC test reference library for comparison between outputs from the PDC reference library and outputs collected at
the tested PDCs output.
It is important to note that the PDC test suite is expected to be customized depending on the specifications of the
PDC under test, application requirements, and configuration settings.
37

IEEE Std C37.244-2013

Figure 10
Figure 11
PDC test suite example
7.6.8 Time reference
The time reference is difficult to emulate and in most cases, when required, an actual GPS time reference would be
used. The use of GPS simulators is also possible.
Depending on the desired accuracy and test targets, various test setups may take place. A diagram illustrating timing and
various synchrophasor data latency measurements is given in Figure 11. It is expected that PMUs have their internal
calculation and PMU reporting latency. The data is then sent over the network to the PDC under test, shown as PDC n in
Figure 11. One can easily extrapolate the scenario in which there might be additional PDCs in the data transfer sequence.
The PDC n processes the input data and sends it over the network to a higher level PDC, shown in Figure 11.

Example time sequence of synchrophasor data latency measurements
38

IEEE Std C37.244-2013

39

As described in 5.8, PDC latency can be calculated as a difference between the following parameters:
PDC entry time, which is the time when synchrophasor measurements data reaches the PDC under test, and
PDC exit time, which is the time when the output data containing the corresponding synchrophasor
measurements leaves the PDC under test
A time reference source should provide time for accurate measurement of PDC entry time and PDC exit time. These
two values, together with the timestamps from the input data stream, can be used for further evaluation.
7.6.9 Test reporting tool
Various reporting methods may be used, including manual or automated tools, which can output results in simple
text or spreadsheet formats. The best practice is to cross-reference requirements, test cases, and the outcome of the
comparison between actual and expected results. The complex behavior should be broken into simple sets that can
be illustrated with examples. These examples are further used for test specifications that are part of the PDC test
suite. The test report should follow the organization of the requirements and provide easy traceability between test
results and the desired test requirements.
IEEE Std C37.244-2013
40

Annex A
(informative)
Relevant standards
This annex provides a short overview of relevant current and legacy standards.
A.1 IEEE Std 1344-1995 (R 2001), IEEE Std C37.118-2005, IEEE Std C37.118.1-2011
and IEEE Std C37.118.2-2011
These standards contain detailed PMU performance requirements, and specify the data format used to
stream and collect multiple synchrophasor measurements. Note that some of these are legacy standards that
supersede each other with the latest edition being in power. Since the synchrophasor system functionality
evolved over time, all versions of the standard may be relevant in utility applications and are therefore
listed in this guide. This is typical of large power systems where legacy devices may have to interoperate or
be integrated with latest device technology.
A.2 IEC 61850
The IEC 61850 standard provides interoperable foundation for data exchange among various intelligent
devices. Of special interest to this guide is the Technical Report IEC 61850-90-5 specifying synchrophasor
data mapping and wide area transport using IEC 61850 generic object oriented substation event (GOOSE)
and sample values (SV) data services. This technical report also specifies UDP mapping for both message
types and security mechanisms necessary for reliable synchrophasor data transmission.
A.3 IEC 61970
PDC data may be stored in a common database that requires all data to be represented in the common
information model (CIM) format. In that case, the test may include a check of an ability of a PDC to store
data in the IEC 61970 (CIM) format.
A.4 IEEE Std C37.111-1999
A PDC may need to convert and export COMTRADE files. Where implemented; the PDC needs to be
tested for correct interpretation of COMTRADE files.
A.5 IEEE Std C37.232-2011
This standard applies if the synchrophasor data is to be stored by the PDC using IEEE Recommended
Practice for Naming Time Sequence Data Files.
IEEE Std C37.244-2013
A.6 IEEE Std C37.233-2009
This document provides information for system testing of protection systems. Various elements of this
document are relevant to PMU, PDC, and synchrophasor system testing.
A.7 IEEE Std C37.238-2011
This standard applies if the PDC has the capability to be synchronized over Ethernet using the IEEE Std
C37.238 timing solution based on IEEE Std 1588-2008.
A.8 IEEE Std C37.239-2010
This standard applies if the PMU is capable of collecting event data and storing it in the COMFEDE
format. If desired, the PDC may need to have the ability to retrieve files in the IEEE Common Format for
Event Data Exchange (COMFEDE) from the PMU. In the case this format is used, this ability needs to be
tested.
A.9 IEEE PC37.240, D13.0, March, 2013
IEEE PC37.240, D13.0, March, 2013, Draft Standard Cyber Security Requirements for Substation
Automation, Protection, and Control Systems defines cyber security requirements for substation
automation, protection, and control systems. It presents sound engineering practices that can be applied to
achieve high levels of cyber security of automation, protection, and control systems independent of voltage
level or criticality of cyber assets.
A.10 IEEE Std C37.242-2013
IEEE Std C37.242-2013 Guide for Synchronization, Calibration, Testing, and Installation of Phasor
Measurement Units (PMU) for Power System Protection and Control. This working group is focused on the
test requirements for PMUs. Since PMU requirements are well defined by the IEEE Std C37.118 series of
standards, the test requirements are defined to match those requirements.
A.11 IEEE Std 1613-2009 and Amendment 1 - 2010
This standard defines environmental and testing requirements for communications networking devices in
electric power substations. It has been compiled from the relevant clauses in IEEE Std C37.90
TM
-1989,
IEEE Std C37.90.1
TM
-2002, IEEE Std C37.90.2
TM
-1995, and IEEE Std C37.90.3
TM
-2001. In addition it
requires that the transmit/receive functions be activated during the application of the transients, and
establishes two Performance Classes. In Performance Class 1, the communication functions may be
disrupted during the application of the transients, but recover without human intervention when the
transient is removed. Performance Class 2 requires that the communication functions are not disrupted
during the application of the transients. Given the severity of these transients, Class 2 essentially mandates
the use of fiber-optic cable for all communications.

41

IEEE Std C37.244-2013
An nex B
(informative)
Reporting rate conversion and the associated filtering
This annex describes the details of reporting rate conversion for M class data and associated filtering.
One of the PDCs main functions is to align phasor measurements from multiple phasor data sources
(PMUs or other PDCs), and generate consolidated data packets that can be recognized and integrated into
user specified applications.
A PMU may measure and compute phasor data at different reporting rates such as 10, 20, 30, or 60 fps.
Phasor users may be using different technologies from PMU manufacturers or request phasor data to be
computed at different data rates. Therefore, PDCs need to be flexible with their input/output data rate
settings.
Consolidation of phasor data with various data rates to a specific output data rate involves data rate
conversion. This annex examines the issues associated with reporting rate conversion as it may cause
aliasing in the final phasor datasets. Both down-conversion and up-conversion are presented below
followed with a general definition of aliasing.
Filtering discussion is primarily applicable to the IEEE Std C37.118.1-2011 M class data intended for
power system stability monitoring. M class data needs to be adequately filtered for both up- and down-
conversion.
P class data is optimized for low latency, snapshot type measurements, and can be down-converted
(decimated) directly, without filtering. It will typically require filtering for up-conversion applications.
B.1 Aliasing
Numerical devices use signal processing to calculate secondary quantities used for a variety of power
system monitoring, recording, protection, and control applications. In signal processing, aliasing refers to
the effect of sampling a high-frequency signal at a low rate. A reconstructed signal with the low-rate
samples would make the original high-frequency signal appear to be a low-frequency signal. An example is
shown in Figure B.1. The original 0.9 Hz signal (high-frequency trace) appears to be of 0.1 Hz (low-
frequency trace) with 1 fps reporting rate.
In order to avoid the aliasing phenomenon, the NyquistShannon sampling theorem requires that the
sampling rate be higher than twice the highest frequency contained in the signal. If the sampling rate does
not meet the requirement, then higher frequencies will alias to lower frequencies. Additional aliasing
examples can be found in the digital signal processing literature.

42

IEEE Std C37.244-2013

Figure B.1Aliasing example
B.2 Down-conversion
A PDC may receive phasor data at various rates. According to IEEE Synchrophasor Standard, phasor data
rates can be 10, 20, 30, or 60 fps for 60 Hz fundamental frequency, or 12.5, 25, or 50 fps for 50 Hz
fundamental frequency. Down-conversion is needed when the PDC output rate is lower than the input
phasor rate. Aliasing may occur if the down-conversion is not properly done.
As an example, assume the input data rate is 30 fps and the output rate is 10 fps. If the input signal does not
contain any frequency components that are higher than 5 Hz, then simple decimation by 3 would be
adequate for down-converting the 30 fps signal to 10 fps as it meets the NyquistShannon sampling
theorem requirement. However, in reality, the 30 fps signal would very likely have frequency components
in the range of 5 to 15 Hz. The 15 Hz is the highest frequency a 30 fps signal can effectively capture
according to the NyquistShannon sampling theorem.
In a power system, generator torsional modes are well in this range, and many control devices can generate
oscillations in this range. For example, if there is a 9.75 Hz oscillation in the 30 fps signal, down-
converting to 10 fps would make it appear to be 0.25 Hz oscillation. This aliasing occurs as the 5 to 15 Hz
spectrum of the 30 fps signal is folded over into the 0 to 5 Hz spectrum of the 10 fps signal. The 0.25 Hz
oscillation can be mistakenly interpreted as inter-area oscillations. Therefore, prior to down-conversion, the
30 fps signal needs to be pre-filtered so that any frequency components of greater than 5 Hz will be
attenuated. This, of course, means that a real 9.75 Hz oscillation will not be captured in the 10 fps signal.
The appropriate reporting rate for this example would have been at least 20 fps.
In general, a PDC should have anti-aliasing filters to handle aliasing issues. The user should be able to
select the filter based on the frequency range desired.
B.3 Up-conversion
Up-conversion occurs when the input rate is lower than the output rate. Up-conversion can be supported
with or without data interpolation and extrapolation, for example, by setting the data that was not present
due to lower reporting rate to the absent data value, defined in IEEE Std C37.118.2-2011. When used,
interpolation may be implemented using sinusoidal, linear, or second/higher-order functions. Up-
conversion does not have problems with aliasing but can create new higher frequency components. High-
frequency components can be understood by visualizing a sine wave with a sparse number of dots and then
inserting a new dot between each old dot but alternatively slightly below and then slightly above the curve.
It is pretty easy to see that the process creates a new frequency component at about of the reporting rate.
That is an exaggerated example, but illustrates that up-conversion can create undesirable signal artifacts.
A better way to up-convert a signal is to apply a low-pass filter to the interpolated signal to remove all of
the higher frequency artifacts, and then re-sample the filtered signal at the required output rate. This
43

IEEE Std C37.244-2013
ensures the resulting signal will not contain any frequency components beyond those present in the original
signal.
Applying filters always cause delays. The benefit of the low-pass filter should be evaluated with respect to
the artifacts caused by the interpolation. A PDC should specify how much error would be introduced due to
its up-conversion mechanism. It should be noted that the up-converted signal, although reported at a higher
reporting rate, does not contain additional information beyond that which was present in the original input.
Once discarded, the high-frequency information cannot be restored by the up-conversion process.
44

IEEE Std C37.244-2013
An nex C
(informative)
IEEE Std C37.118.1-2011 latency discussion
This annex provides background information that may be of use while interpreting the IEEE Std C37.118.1-2011
latency specification. It is provided only as a clarification, and is not intended to modify or in any other
way supersede normative requirements specified in IEEE Std C37.118.1-2011.
IEEE Std C37.118.1-2011 defines performance requirements for measurements that can be collected into a
set with strictly defined measurement times and signal processing system specifications. In doing so, this
synchrophasor standard relies on several key concepts:
a) Each synchrophasor measurement is associated with a precise timestamp traceable to UTC.
b) Measurements (PMU output) are performed on a uniformly spaced time grid.
c) The time grid is precisely aligned with the integer second mark.
d) The time grid is determined by the PMU reporting rate.
e) PMU reporting rates are integer submultiples of the nominal system frequency (50 or 60 Hz),
resulting in an integer number of synchrophasor measurements in each UTC second.
f) Example measurement algorithms are well documented in informative Annex C of
IEEE Std C37.118.1-2011. Algorithms use low-pass filtering to determine signal average spanning
several power frequency cycles.
g) The PMU manufacturer is made responsible for compensating all internal signal processing delays,
so that the synchrophasor measurement associated with a UTC timestamp t directly corresponds to
the PMU input signal (windowed average) present at time t. Measurement accuracy is required to
give a total vector error of less than 1%.
The first five points above mean that a PMU compliant with IEEE Std C37.118.1-2011 is required to
furnish output values at discrete times that are tied to UTC. Suppose we are considering a PMU that is
reporting at a rate of ten reports per second. If we utilize the ISO 8601 standard (for date and time
representation), and omit the higher order terms in the time representation, we could say that the PMU must
report the phasor values measured at T09:51:28.00, 28.1, 28.2, 28.3, and so on, by the requirements of
IEEE Std C37.118.1-2011. It is easy to see that there are exactly 10 measurements made in each UTC
second, and that first of them falls exactly on the UTC second mark. In practical implementation, the term
exactly often means within 1 s of the actual UTC second mark.
The same principles are used to derive the alternate time grids associated with IEEE Std C37.118.1-2011
specified reporting rates of 60, 30, 20, 15, or 12 measurements per second for the 60 Hz, and 50 or 25
measurements per second for the 50 Hz systems. As stated in IEEE Std C37.118.1-2011, support for other
reporting rates is encouraged, including higher rates like 100/s or 120/s or rates lower than 10/s, such as 1/s.
The origin of the time grid for reporting measurements is required to be coincident with the UTC second
mark.
The reporting time requirement can be understood by referring to Figure C.1 which illustrates the fact that
each individual synchrophasor measurement represents a value that is averaged (or processed in some such
fashion) by observing the PMU input signal over a finite time interval, shown as a measurement window.
The length of the measurement window varies, and is determined by the PMU performance class (P or M),
and additionally in case of M class, the selected reporting rate. In the example of Figure C.1, the interval is
ten cycles.
45

IEEE Std C37.244-2013

Figure C.1Synchrophasor measurement model
Since IEEE Std C37.118.1-2011 is a performance-driven standard, the actual position of the window with
respect to the timestamp is not explicitly defined. It is contained within the definition of the total vector
error (TVE) concept, Subclause 5.3 Measurement evaluation and Annex C Reference signal processing
models. The intent of IEEE Std C37.118.1-2011 is that the performance requirements be met and the PMU
manufacturer should determine how the data are processed to achieve that result. In the examples described
in IEEE Std C37.118.1-2011, Annex C, the measurement window is shown centered on the timestamp.
That arrangement is also indicated in Figure C.1 of this guide, which shows two windows centered on the
reporting times 28.1 and 28.2.
Of course, the value being calculated from the input samples is not available until some short time after the
last sample within the time window. There is therefore a short delay before the number is transmitted. This
is shown in Figure C.2, which illustrates the PMU reporting latency.

Figure C.2Timeline for the example 28.1 time sample
46

IEEE Std C37.244-2013
There can be a problem with interpreting the IEEE Std C37.118.1-2011 latency definition, which defines
latency measurements in Subclause 5.3.4. The standard may be interpreted as describing two latencies
defined in the two paragraphs in this annex: Figure C.2 above illustrates a quantity described as PMU
reporting latency. This is a term that appears in the second paragraph of Subclause 5.3.4 with the following
text:
For purposes of this standard, PMU reporting latency is defined as the maximum time interval
between the data report time as indicated by the data timestamp, and the time when the data
becomes available at the PMU output (denoted by the first transition of the first bit of the output
message at the communication interface point).
We could call that latency LRP. Latency in measurement reporting (LMR) is a quantity discussed in the
first paragraph, as
Latency in measurement reporting is the time delay from when an event occurs on the power
system to the time that it is reported in data. This latency includes many factors, such as the
window over which data is gathered to make a measurement, the estimation method, measurement
filtering, the PMU processing time, and where the event occurs within the reporting interval. The
reporting rate and performance class are often the largest factors, since these will determine the
measurement window, filtering, and the length of the interval over which an event will be
reported.
The reader will note that this meaning of latency is not the same as PMU reporting latency, as this one
refers to the occurrence of an event on the power system.
These two interpretations are illustrated in Figure C.7. LRP depends on the time interval from the
timestamp to the last sample in the measurement window (generally the length of the window) and the
time to process and emit the measurement. LMR is the delay between an event and when it is reported.
The LMR value depends not only upon the time to make the measurement and send it, but also upon where
within the measurement window the event occurs. That makes it a variable quantity, dependent on timing
events outside the PMU.
Consider an event that happens in a brief time, such as the change in signal amplitude shown in Figure C.3.
The input signal is shown as a sine wave, with a step increase in amplitude at second 28.133. The time at
which this step occurs is not synchronized with anything in particular: it is a randomly timed event in the
input, that is, the power system.

Figure C.3Input signal with step change in magnitude
47

IEEE Std C37.244-2013
It is clear in this example that there is a delay, between the occurrence of the event (at 28.133) and the
availability of the output data. The output data is delayed from the timestamp time just as before, but since
the event took place after the timestamp time, this delay is smaller. Figure C.4 shows the situation.

Figure C.4Timeline for the event at 28.133
The filter chosen to illustrate this example causes the measurement widows to overlap as shown in Figure
C.1 and Figure C.3. It therefore happens that the event time shown in this particular example falls within
the measurement window for samples that contribute to the output that will be timestamped 28.1 and the
window for 28.2.
Since the event in the power system is near the end of the first window, its effect on the magnitude estimate
for that timestamp may not be very large. In fact, if we make the approximation that the response of the
PMU to the step Figure C.3 change is proportional to the fraction of the window length that occurs after the
change, we might estimate that the response to the step shown in will produce about a 30% response at the
28.1 timestamp, and a 90% response at 28.2. With the approximation that the output is proportional to the
remaining time-fraction, repeated measurements of steps at various times relative to the window would
produce a response as shown in Figure C.5.

Figure C.5Output of PMU in response to step change input at various times
with respect to the sampling window
48

IEEE Std C37.244-2013
Figure C.5 shows that, with this simplified response to a step, the output corresponds to half the step when
the step takes place half-way into (at the center of) the window. If the step is a little earlier than that,
the output will be a little greater, and so on. In a real PMU, the effect of filtering will be more evident.
Figure C.6, adapted from Figure 4 of IEEE Std C37.118.1-2011, shows seven estimated values from the
hypothetical output of a PMU responding to the signal in Figure C.3.

Figure C.6Real-time relation between the time of the step and the time that PMU reports
are available at the PMUs output

Time alignment of PMU reports with events on the power signals is assured by the requirements on the
results of step tests. These tests place a limit on the time difference between the absolute time of a step in
either magnitude or phase and the timestamp that reports a value of 50% of the step value. This time
difference is referred to as time delay. Time delay is measured by placing the times of the steps at various
positions within a reporting period on different time reporting periods. This test process is a form of
equivalent time sampling. The measurement results from this test process are used to determine the
difference in time between when a step occurs and when the results indicate a value of 50% of the step. The
PMU is considered to have a zero time delay if it reports a value of 50% of the step for a step test that
places the step on the timestamp time.
This maximum value of the delay corresponds to the delay associated with an input change that takes place
just after the timestamp. The calculated output does not reach a value equal to or greater than 50% of the
step change until the following timestamp. That figure of 50% is crucial: the event in the power system is
not deemed to have been reported until the output shows at least 50% of it.
In fact, the reported value may actually be close to 100%, but it is still the first value greater than 50%. The
latency is therefore approximately one timestamp interval plus half the width of the sampling window plus
the calculation time of the PMU. In other words, the maximum value of the LMR is one reporting interval
greater than the LRP.
49

IEEE Std C37.244-2013
Measurement reporting latency compliance specifications can be found in 5.5.9 of IEEE Std C37.118.1-2011.
In the first paragraph it states:
The latency in measurement reporting is a critical factor for measurements used in real-time
applications, particularly controls. In addition to measurement latency there are many factors
contributing to reporting delay, such as communication coding and transmission distance. The
application using the data shall take into account all delays to determine system performance. As
defined in 5.3.4, measurement latency includes not only the various computation delays, but the
effect of where an event occurs relative to the reporting time so that it will always be greater than
one reporting period (1/F
s
). These factors are included in this performance requirement.
In the second paragraph it states:
PMU real-time output reporting latency shall be determined for each reporting rate F
s
using at
least 1000 consecutive messages. The reporting latency is the maximum of these values. The
latency shall be determined to an accuracy of at least 0.0001 s. See Table 12.
The meaning of the two latency interpretations in above two paragraphs is different. However, there is only
one set of requirements, specified in IEEE Std C37.118.1-2011 Table C.1:
Table C.1Measurement reporting latency
Performance class
Maximum measurement
reporting latency (s)
P class 2/F
s

M class 5/F
s

There are significant differences in the difficulty in meeting the requirements of Table 12 from
IEEE Std C37.118.1-2011 depending on whether LMR or LRP is used in the measurement. As shown in
Figure C.7, LMR is greater than LRP; and, in fact, a detailed analysis reveals that the maximum value of
LMR is one reporting interval greater than LRP, that is, LMR = LRP + 1/F
s
(This appendix ignores the
delay described in Subclause 5.5.8 of IEEE Std C37.118.1-2011 and pictured therein in Figure 4. It may be
positive or negative and results from imprecise compensation of the timestamp for the step change signal. It
is fixed and generally small.) For the purpose of illustrating the differences, assume a P class PMU with a
two-cycle symmetrical analysis window at a reporting rate of 30 per second. The LRP is on the order of
half the analysis window. If LRP were used as the performance base, the latency is 1 cycle; well below the
4 cycles (2/F
s
) required by Table 12 (a compliance margin of 3 cycles). If the reporting rate is increased to
60 per second, the margin is reduced to 1 cycle. If, however, LMR is the performance criterion, 1 cycle will
be added to latency; still allowing a 2 cycle margin at 30 per second reporting rate, but 0 margin at a
60 per second reporting rate.
Larger analysis windows would exacerbate the problem; smaller windows would mitigate the problem.
However, at super-synchronous rates suggested in IEEE Std C37.118.1-2011, compliance is more
problematic. In the example above, at a 120 per second reporting rate, the LRP margin is 0 and LMR is
negative. Neither interpretation of latency in IEEE Std C37.118.1-2011 allows the requirement to be
successfully met. In fact, at 120 per second reporting rate, the analysis window must approach 1 cycle to
meet even the LRP interpretation.
PMUs with a reporting rate synchronous (50 Hz or 60 Hz) or higher may have difficulty in meeting
these requirements. While higher rates are described in the standard, sufficient details may not exist
therein to adequately determine compliance. The user of this guide is cautioned in applying the
synchrophasor standard at higher rates until proper test and acceptance criteria are developed. In the
50

IEEE Std C37.244-2013
event changes are made to clarify these issues, the user is further advised to use the most recent
revision of IEEE Std C37.118.1-2011.
The relationship between the delay in measurement reporting and the PMU reporting latency can be seen in
Figure C.7. The end of the LMR period for an event on the power system that follows the 28.1 timestamp
occurs at the time the 28.2 sample is emitted. Although the system produces at the time the 28.1 number is
sent out a response to the step change, that response is small, as indicated in Figure C.5 and Figure C.6. It is
not until the 28.2 number is ready that the step in the power system is beyond the 50% point. That defines
the end of the LMR, and it must be more than one reporting period later than the event in the power system.

Figure C.7LMR and LRP contrasted
For test purposes, the event on the power system (for example a step change) can be moved in time until
it occurs exactly at the timestamp time. There should then be an output at the end of the measurement
interval that corresponds to exactly the 50% value. That is, if the event in Figure C.7 were delayed until it
took place exactly at 28.2, the 50% value should appear in the report for that time.
In this condition, the two terms for latency are identical in value, even if they have different definitions. This
approach of adjusting the timing of the event allows direct measurement of the IEEE Std C37.118.1-2011
maximum delay time requirement defined in its Table 9. The standard requires determining the LRP using
at least 1000 consecutive messages and to an accuracy of at least 0.0001 seconds.
51

IEEE Std C37.244-2013
An

nex D
(informative)
Bibliography
Bibliographical references are resources that provide additional or helpful material but do not need to be
understood or used to implement this standard. Reference to these resources is made for informational use
only.
[B1] IEC 61850, Ed. 2.0, Communication networks and systems in substations.
1

[B2] IEC 61850-3, Communication networks and systems in substationsPart 3: General requirements.
[B3] IEC 61970, Common information model (CIM)/Energy management.
[B4] IEC 62351, Power systems management and associated information exchangeData and
communications security.
[B5] IEEE Std 802.1Q-2011, IEEE Standard for Local and Metropolitan Area NetworksMedia
Access Control (MAC) Bridges and Virtual Bridged Local Area Networks.
2,

3

[B6] IEEE Std 1344-1995 (R2001), IEEE Standard for Synchrophasors for Power Systems.
[B7] IEEE Std 1588-2008, IEEE Standard for a Precision Clock Synchronization Protocol for
Networked Measurement and Control Systems.
[B8] IEEE Std 1613-2009 and Amendment 1-2010, IEEE Standard Environmental and Testing
Requirements for Communications Networking Devices Installed in Electric Power Substations.
[B9] IEEE Std 1686-2007, IEEE Standard for Substation Intelligent Electronic Devices (IEDs) Cyber
Security Capabilities.
[B10] IEEE Std 1711-2010, IEEE Trial-Use Standard for a Cryptographic Protocol for Cyber Security
of Substation Serial Links.
[B11] IEEE Std C37.111-1999, IEEE Standard Common Format for Transient Data Exchange
(COMTRADE) for Power Systems.
[B12] IEEE Std C37.118-2005, IEEE Standard for Synchrophasors for Power Systems.
[B13] IEEE Std C37.232-2011, IEEE Standard for Common Format for Naming Time Sequence Data
Files (COMNAME).
[B14] IEEE Std C37.233-2009, IEEE Guide for Power System Protection Testing.
[B15] IEEE Std C37.238-2011, IEEE Standard Profile for Use of IEEE Std 1588 Precision Time
Protocol in Power System Applications.
[B16] IEEE Std C37.239-2010, IEEE Standard for Common Format for Event Data Exchange
(COMFEDE) for Power Systems.
[B17] IEEE PC37.240, D13.0, March, 2013, Draft Standard for Cyber Security Requirements for
Substation Automation, Protection, and Control Systems.
[B18] IEEE Std C37.242-2013, Guide for Synchronization, Calibration, Testing, and Installation of
Phasor Measurement Units (PMU) for Power System Protection and Control.

1
IEC publications are available from the International Electrotechnical Commission (http://www.iec.ch/). IEC publications are also
available in the United States from the American National Standards Institute (http://www.ansi.org/).
2
The IEEE standards or products referred to in this clause are trademarks of The Institute of Electrical and Electronics Engineers, Inc.
3
This publication is available from The Institute of Electrical and Electronics Engineers (http://standards.ieee.org/).
52

IEEE Std C37.244-2013
53

[B19] IEEE PES PSRC Working Group H8 Report, Schema for Phasor Data Using the COMTRADE File
Standard, May 13, 2010.
[B20] IETF RFC 768, User Datagram Protocol, August 1980.
4

[B21] IETF RFC 793, Transmission Control Protocol, DARPA Internet Program Protocol Specification,
September 1981.
[B22] IETF RFC 791, Internet Protocol, DARPA Internet Program Protocol Specification, September
1981.
[B23] IETF RFC 2474, Definition of the Differential Services Field (DS Field) in the IPv4 and IPv6
Headers, December 1998.
[B24] IETF RFC 3168, The Addition of Explicit Congestion Notification (ECN) to IP, September 2001.
[B25] IETF RFC 2460, Internet Protocol Version 6 (IPv6) Specification, December 1998.

4
IETF documents (i.e., RFCs) are available for download at http://www.rfc-archive.org/.

Ieee C37.244-2013

Uploaded by

Copyright:

Available Formats

Ieee C37.244-2013

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ieee C37.244-2013

Uploaded by

Copyright:

Available Formats

IEEE Guide for Phasor Data

Concentrator Requirements for Power

You might also like