IEEE Synchrophasor Standard for Communications

Synchrophasor Measurement System Overview and Development
Synchrophasor measurement definitions and performance requirements are specified in IEEE C37.118.1. It defines steady-state and dynamic performance requirements for synchrophasors, frequency and ROCOF measurements. It also defines the requirements for synchronization and data rates, which are important for the transfer of the measurements. A simple synchrophasor network consists of several Phasor Measurement Units (PMU) and a Phasor Data Concentrator (PDC) as shown in Figure 1. Typically, many PMUs located at various key substations gather data and send it in real time to a PDC at a location where the data is aggregated and analyzed. If multiple intelligent electronic devices (IEDs) in a substation provide synchrophasor measurements, a PDC may be locally deployed at the substation. The data collected by PDCs may be used to support many applications, ranging from visualization of information and alarms for situational awareness, to ones 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 operation and planning functions. Some of the applications display measured voltages, currents and frequency, and derived quantities like real and reactive power flows. Several applications also perform analytics, like oscillation detection and modal damping and display this information for real-time operations. Many PDCs belonging to different utilities can be connected to a common central PDC to aggregate data across the utilities, to provide an interconnection-wide snapshot of the power grid measurements.

Synchrophasor Message Format
A. Message Framework:
The C37.118.2 Standard describes four message types related to the configuration and transfer of real-time data from a PMU or PDC. These are data, configuration, header, and command messages. Data, configuration, and header are sent from data source which can be a PMU or a PDC. Commands are sent from the data receiver to the PMU/PDC to control the data flow or request information. The first three convey PMU measurements, the configuration of the data (e.g. channel numbers, types, scaling) in machine-readable format, and, configuration or descriptive information in human-readable format, respectively. Command messages are machine-readable and sent to the PMU/PDC for control or to request configuration. The Standard defines the specific configuration and content of each message including frame synchronization and checksum. Examples and detailed descriptions are provided in the Standard and its Appendices.
B. Data Frame: The data frame contains the real-time data measured or calculated by the PMU/PDC. The message includes an identification header, message length, the source ID of the message, a time stamp, detailed status information regarding the data and its source and quality; and, the ‘data.’ The ‘data’ includes phasors (in rectangular or polar format), frequency, rate of change of frequency, and analog and digital quantities. All data except digital (Boolean) quantities may be in fixed or floating point format. The status word in the message indicates data validity, time source quality, specific data conditions (trigger types for example) and is meant to be interpreted by a receiving device or application that uses the data. The data frame may contain the data from a single PMU or several PMUs. The data from each PMU is organized as a block of data headed with the status of that block of data as shown in Figure 2. This allows data from many PMUs to be correlated to a particular time stamp and transmitted as an overall synchronized data frame.

C. Configuration Frame
Config1:
The configuration frame “CFG-1” denotes the PMU/PDC capability, indicating all the data that the PMU/PDC is capable of reporting. It is identical in the 2005 and 2011 Standards. CFG-1 is identified by bits 6-4 (value ‘010’) of the frame synchronization (SYNC) word. CFG-1 is fixed length frame with 19 fields (excluding data rate and CRC). Fields 8 thru 19 define the capability of each PMU and are repeated to include all PMUs in the data frame. Table 8 in 2011 version of the standard and table 9 in 2005 version of the standard define the organization of CFG-1 frame

Config2: The configuration frame “CFG-2” indicates the measurements currently being reported (transmitted) in the data frame. It is identical in 2005 and 2011 versions of the standard. CFG-2 is identified by bits 6-4 (value ‘011’) of the frame synchronization (SYNC) word. CFG-2 is a fixed length frame with 19 fields (excluding data rate and CRC). Fields 8 thru 19 define the included measurements from each PMU and are repeated to include all PMUs in the data frame. Table 8 in 2011 version of the standard and table 9 in 2005 version of the standard define the organization of CFG-2 frame

Config3: The configuration frame “CFG-3” is added in the 2011 revision of the standard and its use is optional (a device without this implemented is still considered compliant with the standard). CFG-3 has similar purpose as in CFG-2, as it indicates the measurements currently being reported in the data frame. CFG-3 differs from CFG-2 by being extensible, having variable length name fields (which are fixed at 16 bytes in CFG-2) and includes added PMU and signal information. CFG-3 is identified by bits 6-4 (value ‘101’) of the frame synchronization (SYNC) word.

CFG-3 is a variable length frame with 27 fields (excluding data rate and CRC). Fields 9 thru 27 define the included measurements from each PMU. This data block is repeated to include all PMUs in the data frame. The variable length allows more efficient transfer of data. Table 10 in the standard defines the organization of CFG-3 frame.

D. Header Frame: Header Frame is sent from PMU/PDC to the host (PDC) system. It contains information about sender (PMU/PDC) in plain ASCII format. There is no change in the format of header frame as compare to C37.118-2005 standard.

E. Command Frame: The command frame is sent by the host to the PMU/PDC to start or stop transmission, or to request configuration data in the form of configuration or header frames. Command frames are always sent from the data collecting device to the data sending device. The IDCODE in the command frame identifies the particular data stream the command applies to rather than the data sending device itself. This is because a device may send several data streams, including more than one stream to the same destination device.

A new command “Send CFG-3 frame” has been added for requesting the configuration frame 3(CFG-3) from the data sending device. However, this command is optional like the CFG-3 frame.

Unused bits in these commands are reserved and may be used for further command information in future revisions of the standard. An extended frame command type is provided for user-defined functions such as PMU configuration or remote controls.

A part of the reserved command space has been set aside for user designation. The command length is two bytes i.e. 16 bits, designated 0 to 15. All commands where bits 8 to 11 are non-zero have been reserved for user designation. Users may use these bits for assigning their own customized commands. All other bits are reserved for future use.

F. Informative Annexes: Six annexes are included in the standard: Bibliography, Cyclic redundancy codes, System communications considerations, Message examples, Synchrophasor message mapping into communications, and Synchrophasor communication methods for Internet Protocol (IP). Annex B reviews cyclic redundancy codes in the context of the CRC-CCITT that is used in all the C37.118 messages.

Annex C provides an overview of bandwidth and delay. It reviews bandwidth required for the data message flow and gives a table of requirements when used with UDP implementation. It provides a table of typical delays in these systems, which is useful for real-time applications.
Annex D gives examples of all four message types: data, configuration, header, and command. This provides a reference for developers to check the details of their implementations. Annex E is the only normative annex; it requires that C37.118.2 messages must be mapped into an underlying protocol in their entirety.

This assures that the applications that send and receive the data can use the same message interpretation and commands for input and output regardless of the underlying communication protocol. The annex describes the mapping for both serial and a stacked network protocol, using IP as the typical example. Recent installations have predominantly used IP communications, but the serial option may be useful in situations where IP is unavailable.

The final Annex F describes synchrophasor communications using IP with standard Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and combined TCP/UDP options. IP over Ethernet is the most widely used communication choice. Even though not formally standardized, these implementations have proven to be highly interoperable.

Application of Data Transfer
C37.118.2-2011 describes a system of messaging and the message contents.
The messages can be carried over any communication system using any protocol that will support bandwidth, latency, and reliability requirements of the synchrophasor system it serves. Connection establishment and management, retransmission, security, and all other communication issues are left to the communication system protocol and the programs that support it. By describing the messages and message contents, the system can be adapted to available communications with little disruption to applications that use the data. The messaging can also easily be upgraded to newer communication systems and changes in requirements such as shorter latency, higher rates, or higher security. The 2011 update to the standard is backward compatible with the 2005 version to support the many existing and developing projects and still allow continued system growth.

IEEE, PES, PSRC Working Group H19

Chair: Ken Martin

Vice Chair: G. Brunello

Members: M.G. Adamiak, G. Antonova, M. Begovic, G. Benmouyal, P.D. Bui, H. Falk, V. Gharpure, A. Goldstein,
Y. Hu, C. Huntley,T. Kase, M. Kezunovic, A. Kulshrestha, Y. Lu, R. Midence, J. Murphy, M. Patel, F. Rahmatian,
V. Skendzic, B. Vandiver, A. Zahid

Power. Flexible. Easergy.
Let?s start with organization in protection testing