project final technical report advanced synchrophasor ... · 10 seconds) to synchrophasor (60 or...

Project Final Technical Report

Advanced Synchrophasor Protocol (ASP) Development and Demonstration Project

Work Performed Under Agreement

DE-OE0000859 Award Period of Performance: May 1, 2017 to September 30, 2019

December 6, 2019

PRINCIPAL INVESTIGATOR F. Russell Robertson, GPA

Grid Protection Alliance, Inc. 1206 Broad Street Chattanooga, Tennessee 37402

SPONSORING PROGRAM OFFICE U. S. Department of Energy

Office of Electricity Delivery and Energy Reliability Via the National Energy Technology Laboratory

Final Technical Report

Page ii

This material is based upon work supported by the Department of Energy under Award Number DE-OE0000859. Neither the United States Government nor any agency thereof, nor any of their employees, makes any warranty, express or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, apparatus, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial product, process, or service by trade name, trademark, manufacturer, or otherwise does not necessarily constitute or imply its endorsement, recommendation, or favoring by the United States Government or any agency thereof. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government or any agency thereof.

December 6, 2019

DE-OE0000859 Page iii

ASP Final Technical Report – DE-OE0000859

Period of Performance: May 1, 2017 to September 30, 2019 Award Recipient: Grid Protection Alliance, Inc. (GPA) 1206 Broad Street Chattanooga, Tennessee 37402-2707 Project Team Members: Grid Protection Alliance, Inc. (GPA) Bonneville Power Administration (BPA) (withdrew September 2018)

Electric Power Group (EPG) Washington State University (WSU)

Schweitzer Engineering Laboratories (SEL) Tennessee Valley Authority (TVA) Oklahoma Gas & Electric (OG&E) San Diego Gas & Electric (SDG&E) Southwest Power Pool (SPP) Dominion Energy

Utilicast LLC

Principal Investigator: F. Russell Robertson, GPA Telephone: (423) 541-3956 Email: [email protected] Key Project Personnel: F. Russell Robertson, GPA (PI) J. Ritchie Carroll, GPA Scott Staples, Utilicast Dr. Simon Mo, EPG Dr. Vaithianathan Venkatasubramanian, WSU DOE Project Officer: Carol Painter U.S. Department of Energy National Energy Technology Laboratory Telephone: (304) 285-0945 E-mail: [email protected] DOE Program Manager: Dr. Ali Ghassemian U.S. Department of Energy Office of Electricity Delivery and Energy Reliability Telephone: (202) 586-3247 E-mail: [email protected]


Page iv

List of Tables

Table 1 - List of ASP Project Participants ......................................................................................... 1 Table 2 - Protocol Comparison Table ............................................................................................ 16

Table A 1 - STTP Command Message Fields .................................................................................. 26 Table A 2 – STTP Command Types................................................................................................. 28 Table A 3 – STTP Response Message Fields ................................................................................... 28 Table A 4 – STTP Response Types .................................................................................................. 29 Table A 5 – Comparison of STTP / VPN to STTP / TLS Security ...................................................... 31

Table E 1 - STTP Measurement Detail Metadata .......................................................................... 70 Table E 2 - STTP Device Detail Metadata ....................................................................................... 71 Table E 3 - STTP Phasor Detail Metadata ...................................................................................... 72

December 6, 2019

DE-OE0000859 Page v

List of Figures

Figure 1 - Existing Synchrophasor Protocols Do Not Scale .............................................................. 4 Figure 2 - Scalability Makes STTP Uniquely Different ...................................................................... 5 Figure 3 - ASP Project Work Plan ..................................................................................................... 6 Figure 4 - STTP Low Level Commands and Responses .................................................................... 7 Figure 5 -STTP Data Packet .............................................................................................................. 8 Figure 6 - Reverse Connections ....................................................................................................... 9 Figure 7 - The STTP Specification Suggests a Minimum Set of Required Metadata ..................... 10 Figure 8 -Test Setup for Evaluation of STTP over the EIDSN ......................................................... 19 Figure 9 - EIDSN Test Results. STTP vs. C37.118 ........................................................................... 20 Figure 10 - EIDSN Test Results. STTP has greater throughput ...................................................... 20 Figure 11 - Data Flow for EPG Evaluation of STTP ............................. Error! Bookmark not defined. Figure 12 - SEL SynchroWAVe Modified to Incorporate STTP ....................................................... 23

Figure C 1 - Mode estimation in 24-hour of a typical day ............................................................. 40 Figure C 2 - Mode frequency vs. damping ratio plot in 24-hour in a typical day .......................... 40 Figure C 3 - Estimation of 0.235Hz mode on a typical day ............................................................ 41 Figure C 4 - Mode shape of 0.235Hz mode ................................................................................... 41 Figure C 5 - Estimation of 0.40Hz mode ........................................................................................ 42 Figure C 6 - Mode shape of 0.40hz mode ...................................................................................... 42 Figure C 7 - Estimation of 0.60Hz mode ........................................................................................ 43 Figure C 8 - Mode shape of 0.60Hz mode ..................................................................................... 43 Figure C 9 - Estimation of 1.00hz mode ........................................................................................ 44 Figure C 10 - Mode shape 1.00Hz mode ....................................................................................... 44 Figure C 11 - Estimation of 1.10Hz mode ...................................................................................... 45 Figure C 12 - Mode shape of 1.10Hz mode ................................................................................... 45 Figure C 13 - Estimation of 1.60Hz mode ...................................................................................... 46 Figure C 14 - Mode shape of 1.60Hz mode ................................................................................... 46 Figure C 15 - Estimation of 2.00Hz mode ...................................................................................... 47 Figure C 16 - Mode shape of 2.00Hz mode ................................................................................... 47 Figure C 17 - Mode frequency in a typical data from FSSI engine................................................. 48 Figure C 18 - Mode frequency and damping ratio in a typical day from FSSI engine ................... 48 Figure C 19 - Estimation of 0.23hz mode ...................................................................................... 49 Figure C 20 - Mode shape of 0.23Hz mode ................................................................................... 49 Figure C 21 - Estimation of 0.40Hz mode ...................................................................................... 50 Figure C 22 - Mode shape of 0.40Hz mode ................................................................................... 50 Figure C 23 - Mode estimation of 0.60Hz mode ........................................................................... 51 Figure C 24 - Mode estimation of 0.60Hz mode ........................................................................... 51 Figure C 25 - Estimation of 1.00Hz mode ...................................................................................... 52 Figure C 26 - Mode shape of 1.00Hz mode ................................................................................... 52 Figure C 27 - Estimation of 1.10Hz mode ...................................................................................... 53 Figure C 28 - Mode shape of 1.10hz mode .................................................................................... 53


Page vi

Figure C 29 - Mode frequencies in a typical day ........................................................................... 55 Figure C 30 - Mode frequency vs. damping ratio in a typical day ................................................. 55 Figure C 31 - Estimation of 0.30Hz mode ...................................................................................... 56 Figure C 32 - Mode shape of 0.30Hz mode ................................................................................... 56 Figure C 33 - Estimation of 0.40Hz mode ...................................................................................... 57 Figure C 34 - Mode shape of 0.40Hz mode ................................................................................... 57 Figure C 35 - Estimation of 0.70Hz mode ...................................................................................... 58 Figure C 36 - Mode shape of 0.70Hz mode ................................................................................... 58 Figure C 37 - Estimation of 1.00Hz mode ...................................................................................... 59 Figure C 38 - Mode shape of 1.00Hz mode ................................................................................... 59 Figure C 39 - Number of signals processed by the FFDD engine ................................................... 60 Figure C 40 - Number of channels processed by the transient engine ......................................... 60 Figure C 41 - Number of Generator Groups .................................................................................. 61 Figure C 42 - Deltas of each Generator Group .............................................................................. 61

Figure D 1 – ePDC Input Configuration Using STTP ....................................................................... 62 Figure D 2 – ePDC Input Data Using STTP ...................................................................................... 63 Figure D 3 – ePDC Output Configuration Using STTP .................................................................... 63 Figure D 4 – ePDC Output Data Using STTP ................................................................................... 63 Figure D 5 – FAT Setup for Testing ePDC and RTDMS ................................................................... 64 Figure D 6 – FAT Setup for Testing RTDMS Server ........................................................................ 64 Figure D 7 – Original Demonstration Setup................................................................................... 65 Figure D 8 – Frequency Data ......................................................................................................... 66 Figure D 9 – Voltage Data .............................................................................................................. 67 Figure D 10 – ePDC Resource Utilization ....................................................................................... 68 Figure D 11 – RTDMS Service Resource Utilization ....................................................................... 68 Figure D 12 – ePDC with 283 PMUs Streamed from TVA through GPA openPDC ........................ 69

December 6, 2019

DE-OE0000859 Page vii

List of Acronyms and Abbreviations

ANTLR – ANother Tool for Language Recognition

API – Application Programming Interface ASP – Advanced Synchrophasor Protocol AWS – Amazon Web Services BPA – Bonneville Power Authority CIP – Critical Infrastructure Protection CPU – Central Processing Unit DOE – Department of Energy EMP – Electromagnetic Pulse EMS – Energy Management System EPG – Electric Power Group ERCOT – Electric Reliability Council of Texas GEP – Gateway Exchange Protocol GPA – Grid Protection Alliance, Inc. GDOI – Group Domain of Interpretation GUID – Globally Unique Identifier EIDSN – Eastern Interconnection Data Sharing

Network ICCP – Inter-Control Center Communications

Protocol IEC – International Electrotechnical

Commission IEEE – Institute of Electrical and Electronics

Engineers IETF – Internet Engineering Task Force IP – Internet Protocol ISO – Independent System Operator JSIS – Joint Synchronized Information

Subcommittee KDC – Key Distribution Center MIT – Massachusetts Institute of Technology MTU – Maximum Transmission Unit NASPI – North American Synchrophasor

Initiative

NERC – North American Electric Reliability Corporation

OGE – Oklahoma Gas & Electric PAR – Project Authorization Request PDC – Phasor Data Concentrator PNNL – Pacific Northwest National Laboratory PMU – Phasor Measurement Unit NaN – Not a Number RTO – Regional Transmission Operator SCADA – Supervisory Control and Data

Acquisition SDG&E – San Diego Gas & Electric SEL – Schweitzer Engineering Laboratory SIEGate – Secure Information Exchange Gateway SMS – NERC Synchronized Measurement

Subcommittee SPP – Southwest Power Pool SQL – Structured Query Language STTP – Streaming Telemetry Transport

Protocol TCP – Transmission Control Protocol TLS – Transport Layer Security TSSC – Time Series Special Compression TVA – Tennessee Valley Authority UDP – User Datagram Protocol UTC – Coordinated Universal Time UTF – Unicode Transformation Format VPN – Virtual Private Network WECC – Western Electricity Coordinating

Council WSU – Washington State University XSD – W3C XML Schema Definition Language

https://www.naspi.org/

https://www.naspi.org/


Page ii

(intentionally blank page)

December 6, 2019

DE-OE0000859 Page iii

Table of Contents Executive Summary .................................................................................................................... 1

Project Objectives ...................................................................................................................... 3

Technical Approach .................................................................................................................... 5

Accomplishments and Conclusions ........................................................................................... 17

Appendix A - STTP Protocol Specification ................................................................................. 25

Appendix B – Product Production and Technology Transfer ..................................................... 35

Appendix C – WSU Test Results ................................................................................................ 39

Appendix D – EPG Test Results ................................................................................................. 62

Appendix E – STTP Metadata ................................................................................................... 70

Appendix F – STTP Filter Expressions ........................................................................................ 76


Page iv

(intentionally blank page)

December 6, 2019

DE-OE0000859 Page 1

EXECUTIVE SUMMARY

The Streaming Telemetry Transport Protocol (STTP) was developed under the Department of Energy’s (DOE) Advanced Synchrophasor Protocol (ASP) Development and Demonstration Project DE-OE0000859. The project began on May 1, 2017 and concluded on September 30, 2019. It included 25 collaborators as shown in Table 1.

Table 1 - List of ASP Project Participants

The Advanced Synchrophasor Protocol Project had two main objectives:

• To develop, document, and demonstrate a new standard communications protocol (that became named the Streaming Telemetry Transport Protocol, or STTP) to overcome the issues being encountered in large-scale synchrophasor data system deployments using existing protocols – specifically with issues of scalability, data loss, bandwidth utilization, data access control, transport security options, and cost of configuration management, and

• To work with standards bodies to put STTP on a track for consideration as a standard protocol.

STTP was designed and developed as an improved way to share time series data. STTP can transport measurements at low latency at device speeds from ICCP and SCADA (1 update every 1 to 10 seconds) to Synchrophasor (60 or more updates per second) to point-on-wave data (at 60 kHz sampling rates or higher) using less bandwidth than any other current protocol. In addition to the real time data, STTP supports bidirectional sharing of metadata between the communicating applications.


Page 2

Specifically, STTP offers both short-term cost savings and strategic value in that it is:

• Intrinsically Robust – By design, STTP packet sizes are small and are optimized for network maximum transmission unit (MTU) size. This reduces network level fragmentation, which results in more efficient performance while using Transmission Control Protocol (TCP) and less overall data loss with User Datagram Protocol (UDP). STTP also puts significantly less stress on network routing equipment as well as facilitates mixing of streaming data traffic and other general network communications. With STTP, purpose-built networks are not required to reliably support large synchrophasor measurement data streams.

• Security Centric – STTP has been built using a "security first" design approach. Authentication to establish a connection with other parties requires a certificate. While public certificate providers can be used, it is recommended that symmetric certificates be exchanged out-of-band to avoid the risk and cost of management of public keys. Best-practice encryption is also natively available in STTP, but not required, to manage encryption at the network layer.

• Reduces First Cost – STTP has been measured to use less bandwidth as compared to IEEE C37.118 when used with TCP and simple methods for lossless compression. With compression, a single signal or measurement point (i.e., an identifier, timestamp, value, and quality code) requires only 2.5 bytes. By comparison, IEEE C37.118 requires 4.5 bytes per measurement on average. STTP is signal based, incorporating Publish/Subscribe (Pub/Sub) data exchange methods so that unnecessary data points need not be exchanged, thereby further reducing overall bandwidth requirements as compared to IEEE C37.118.

• Reduces Operating Cost – STTP automatically exchanges and synchronizes measurement level metadata using globally unique identifiers (GUID) as the key value to allow the self-initialization and integration of rich metadata with points from multiple connected synchrophasor networks. By including facilities to map and synchronize metadata, STTP eliminates the need to map measurements to a pre-defined set of identifiers and dispenses with the cost and difficulties associated with synchronization of individual utility configuration with a centralized registry. The protocol allows for permissions on data subscriptions to be grouped and filtered using expressions assuring that only the signals that are authorized are shared (for example, all phasor measurements from a specified substation) while the set of points available is dynamically adjusted as Phasor Measurement Units (PMUs) come and go without the need for point-by-point administrator approval.

• Built Upon A Proven Approach – STTP has enhanced the successful design elements of the Gateway Exchange Protocol (GEP) as a foundation and has improved upon it.

In April 2019, STTP was tested by SPP and TVA over the Eastern Interconnection Data Sharing Network (EIDSN). This test showed that using STTP with TCP there was no data loss and bandwidth utilization was about 40 percent less that using IEEE C37.118 resulting from STTP’s lossless compression techniques. CPU cycles used by the hosting hardware was low in both cases (~5% for IEEE C37.118 and ~8% for STTP) for about 5,000 streaming phasor data points (300 PMUs). Additional testing was conducted by Washington State University (WSU) and the Electric Power

December 6, 2019

DE-OE0000859 Page 3

Group (EGP) to validate that STTP had been successfully implemented in their products and that STTP qualitatively meet its functionality objectives.

In Fall 2018, the Institute of Electrical and Electronics Engineers (IEEE) standards board approved a Project Authorization Request (PAR) and assigned a number (IEEE 2664) for development of a new standard based on the STTP specification. The current version of the STTP specification is included as Appendix A.

The STTP protocol is now in production use in the full suite of open source synchrophasor products offered by GPA. Through use of the project-provided open source Application Programming Interfaces (APIs) for C# and C++, STTP is being used in production vendor products from WSU, EPG and SEL. In addition, PingThings has work currently in progress to incorporate STTP in its cloud-based platform in addition to its existing GEP-based implementation.

Going forward, GPA hopes to continue to advance the development of the IEEE 2664 standard as the preferred streaming protocol for time-series data exchange. GPA will also be working to add to the collection of target languages for the STTP API to include Go and Python.

PROJECT OBJECTIVES

The Advanced Synchrophasor Protocol (ASP) Development and Demonstration Project proposed to advance grid reliability by significantly improving the quality and robustness of the synchrophasor data exchange layer that is the foundation for reliability management tools that require wide-area information. The two main project objectives were:

(1) To develop, document, and demonstrate a new standard communications protocol to overcome the issues being encountered in large-scale synchrophasor data system deployments using existing protocols – specifically with issues of scalability, data loss, bandwidth utilization, data access control, transport security options, and cost of configuration management. This objective included the three components:

• To develop and specify a new publish/subscribe communications protocol for streaming measurements that is intrinsically more robust, particularly as these communications systems may become stressed by security events, equipment failure, or natural disasters.

• To develop an open source tool suite with APIs to allow vendors to easily integrate and test the STTP protocol within existing vendor products – specifically GPA, SEL, WSU, and EPG.

• To test and demonstrate the protocol and validate its ability to handle high-volume data flows while reducing data loss and consuming less bandwidth than current methods.

(2) To work with standards bodies such as the IEEE to put STTP on a track for consideration as a standard protocol.


Page 4

THE PROBLEM STATEMENT

Use of synchrophasors by U.S. utilities continues to grow following the jump start provided by the Smart Grid Investment Grants. Currently, the dominant method to exchange synchrophasor data remains the IEEE C37.118-2005 protocol which was designed for efficient substation-to-control center communications – i.e., sending a finite set of information between two locations.

When used at scale (e.g., for systems involving hundreds of PMUs) where multiple systems require access to phasor data in real-time, the frame-based nature of IEEE C37.118 often requires purpose-built, over-provisioned networks, for reliable data delivery. Even with purpose-built networks, large frame sizes result in an increased probability of overall frame-loss through the substantial number of network packet fragments required to send each frame or, in the case of TCP, increased communication latency. In addition, IEEE C37.118 offers no native security options, and its methods for management of metadata are prescriptive, making measurement selection and metadata extension complex and costly.

Through testing, research, and ongoing experience with production synchrophasor deployments, IEEE C37.118 has been proven to be effective so long as frame sizes are reasonably sized. However, as frame sizes approach 32K bytes, data losses and delivery latencies start to increase significantly.

Both IEEE C37.118.2-2011 and IEC TR 61850-90-5 have a data frame size ceiling of 65K bytes. This creates a limit for the information that can be exchanged between two parties in a single session. For example, with a synchrophasor stream that is publishing data at 30 samples per second, the maximum throughput is about 200,000 measurements per second. The 65K byte limit, as referenced in Zone 4 of Figure 1, means that no more than about 6,700 uniquely identifiable measurements can be published into a single stream.

Figure 1 - Existing Synchrophasor Protocols Do Not Scale

December 6, 2019

DE-OE0000859 Page 5

Implementations of large-scale synchrophasor deployments have already been reaching these thresholds creating real concerns for inter-system and inter-control center data exchanges, such as those between a Reliability Coordinator and its Transmission Operators.

As seen in Figure 2, the ASP Project objective was to create a protocol that did not require a fixed configuration nor specify a maximum limit on the number of identifiable measurements that could be exchanged – as such, STTP has been developed to scale to much higher volumes for data exchange, up to hardware limitations.

Figure 2 - Scalability Makes STTP Uniquely Different

TECHNICAL APPROACH

The ASP project successfully developed the new STTP through an open, collaborative process involving industry, university, and vendor experts. Work of the ASP Project was conducted in two major phases: (1) The Design-and Development Phase and (2) The Testing and Demonstration Phase.

DESIGN AND DEVELOPMENT PHASE

The Design and Development Phase included drafting and critical review of the STTP specification by the 26-member project team. This process including early vetting of STTP concepts by Internet Engineering Task Force (IETF) experts at the University of Southern California and other authorities in the field of synchrophasor technology, especially as it related to data exchange.

Following specification development, coding of the STTP APIs was completed by GPA. The STTP APIs were designed so that synchrophasor technology vendors could easily implement STTP, both for publication and subscription of data, within existing products. The APIs were developed to support both C++ and various .NET implementations. The low-level C++ implementation was designed such that it could be deployed on most any hardware environment and operating system. API testing was executed on both Linux and Windows operating systems running on various hardware platforms.


Page 6

Information on project product production and technology transfer activities is provided in Appendix B.

TESTING AND DEMONSTRATION PHASE

The Testing and Demonstration Phase included incorporation of STTP into multiple vendor’s products and the testing of the protocol by the project’s utility partners. While all testing provided valuable results, the highest visibility test of STTP was between TVA and SPP using the production Eastern Interconnect Data Sharing Network (EISDN) for transport. Information on testing by WSU and EPG is included in Appendices C and D.

The project was originally scheduled to conclude in April 2019. However, the project team requested and was granted a no-cost extension through September 2019 to enable completion of utility testing by WSU and EPG. The Project Work Plan and associated milestones and deliverables is shown in Figure 3 below.

Figure 3 - ASP Project Work Plan

STTP DESIGN OVERVIEW

The STTP is a measurement-centric, publish/subscribe transport protocol that can be used to securely exchange time-series style data and synchronize metadata among applications. The protocol supports sending real-time and historical data at full or down-sampled resolutions. When sending historical data, the replay speed can be controlled dynamically for use in visualizations to enable users to see data faster or slower than recorded in real-time.

December 6, 2019

DE-OE0000859 Page 7

Wire Protocol

The wire protocol defined by STTP is targeted for packet-based transport protocols, specifically Internet Protocol (IP). STTP implements the publish/subscribe data exchange model using a simple command and response architecture, see Figure 4 below.

Figure 4 - STTP Low-Level Commands and Responses

The “DataPacket” command is used to send measurement data through a compressed binary serialization of data points. The protocol does not require a predefined or fixed configuration, that is, the identifiable data point values arriving in one data packet can be different than those arriving in another, see Figure 5. Each packet of measurement data consists of a collection of data values where each value is defined by a compact structure containing an identifier; a timestamp or sequence index; a value; and any associated asset state or data quality flags.

Network packet size, called the Maximum Transmission Unit (MTU), defines the largest frame size that can be sent over an IP network. Any data to be sent that exceeds the configured MTU size gets fragmented before transmission over the network. Fragmentation is the root cause of data loss and retransmission latencies on an IP network. STTP was designed to use as few network fragments as possible and thus able to achieve an intrinsic reduction in data loss and transmission latency by making sure serialized measurements in a single data packet fit within a minimal number of network fragments, ideally one, thereby removing noted stresses of large frame sizes.


Page 8

Figure 5 - STTP Data Packet

Communication Channels

STTP was implemented using two different communication channels. STTP calls the first the “command channel” and the second the “data channel.” In IP-based communication, each of these channels is handled by one or more IP endpoints for sending and receiving data, called a “socket,” where the IP transport protocols for these channels can vary based on need. The two most common configurations are: (1) a single TCP transport for both the command and data channel, i.e., traffic for both channels share the same socket, and (2) a TCP-based command channel with a UDP-based data channel.

The command channel is used to reliably negotiate session-specific required communication, state, and protocol parameters. The command channel is also used to manage authentication with other STTP instances, exchange metadata on available data points, and request specific data points for subscription. The data channel is primarily used to send compact, binary encoded packets of data points.

Reverse Connections

The functions of a publisher and subscriber are not always causally related to the connection concepts of server and client. STTP is designed to allow a publisher to initiate a client-style socket connection to a subscriber that is listening with an established server-style socket. This type of connectivity model is called a reverse connection. Since a client-style connection is the only type of

December 6, 2019

DE-OE0000859 Page 9

socket that can initiate a connection, a reverse connection requires the publisher to be the initiator of a connection such that the target subscriber would be able to receive data.

Figure 6 - Reverse Connections

Reverse connections flip the normal responsibilities of a publish/subscribe messaging pattern by having parties that provision the data also the be the initiators of a connection. Data subscribers, which might otherwise come and go as needed, now become a persistent network resource that needs to be readily available for a connection from its publisher. Reverse connections can require more data flow planning and network engineering to ensure that connections are initiated from the proper locations while having the data reliably flow to the desired locations. Most often a reverse connection is used to ensure a connection is initiated from an environment of higher security to one of a lower security, as is cybersecurity and NERC CIP best practice.

Regardless of how a connection is established, forward or reverse, the functions, roles, and responsibilities of the participants will not change, i.e., a publisher shall still be the provider of data and the subscriber shall still be the consumer of data. Additionally, any required protocol negotiations by the parties continues as normal once the connection has been established.

This level of increased flexibility in the design of connectivity models for STTP was necessary so that security boundaries that have been enforced with firewall rules can be maintained. A common use case is that the publisher, and the data it has access to, exists in a secure network environment and the subscribers, which need access to the data, exist in less secure network environments. In these scenarios, security system rules will prohibit any connections to be initiated from an environment that is less secure. However, such environments normally allow connections to be initiated from inside the secure environment out to listening connections in less secure environments, as shown in Figure 6. Described more simply, nothing can reach into systems in the secure environment, but systems in the secure environment can reach out - this is much like how a computer in a home network can access the public Internet through a router, but the router’s built-in firewall prevents


Page 10

systems on the Internet from accessing the home computer. Although reverse connections may initially seem counter-intuitive, they exist as a firm STTP requirement to allow for successful data exchange from within secure environments.

Metadata

Measurements in STTP were designed to be described with rich and extensible metadata. Metadata is setup in a tabular format, similar to a database table. Metadata can be related and can span many tables.

There are two types of metadata used by STTP. The first is called “primary metadata” which describes the detailed information that is exchanged from publishers to subscribers to describe the available measurements with enough detail to be useful in a given environment. The second type of metadata is called “selection metadata” which normally represents a simple flattened view of the primary metadata whose purpose is to simplify the selection of measurements for subscription.

Primary Metadata

The STTP publisher maintains a set of primary metadata used to describe all measurements and related data to the extent desired by the publisher. Primary metadata is returned to an authorized subscriber in response to a “Metadata Refresh” command. Several tables of metadata are typically included in the primary metadata set, see Figure 7.

Figure 7 - The STTP Specification Suggests a Minimum Set of Required Metadata

The STTP publisher always exposes a primary metadata table named “MeasurementDetail.” The contents of the MeasurementDetail table, as well as any other metadata, are made available to authorized subscribers via the “Metadata Refresh” command.

The MeasurementDetail table is required to contain a field of type GUID named “SignalID.” The SignalID of each measurement made available by a publisher is unique. Additionally, the

December 6, 2019

DE-OE0000859 Page 11

MeasurementDetail table should contain a field or fields suggesting appropriate names and descriptions to interested subscribers. Without a point tag name or description, the measurement may be of little use unless other metadata is exchanged out-of-band with STTP.

The MeasurementDetail table is also expected to contain a field of type DateTime named “UpdatedOn.” Data publishers set the contents of the UpdatedOn field when the related metadata is updated.

The MeasurementDetail table may contain additional fields deemed appropriate by the publisher. Details of currently defined metadata tables and fields can be found in Appendix E.

Storage of primary metadata can be handled in any manner suitable for the publisher, but the design accommodates a common use case of storage within a database. Primary metadata is most commonly persistent.

Signal Selection Metadata

To make it easier on the subscriber when selecting a desired set of measurements, the publisher can provide “views” of available metadata that the subscriber can use to select measurement data. These views, commonly comprised of fields from the primary metadata tables, are called signal selection metadata. Signal selection metadata is most useful to the subscriber when it is presented as a single flattened representation of the primary metadata.

To accommodate signal selection, the STTP publisher implements an appropriate response to queries for a table named “ActiveMeasurements.” Although any number of signal selection metadata sets can be provided, at a minimum the “ActiveMeasurements” signal selection metadata table must exist.

Queries to select measurements can exist simply as a list of signals or as queries formatted as Filter Expressions, see Appendix F. The publisher maintains the responsibility of making sure all metadata, including the ActiveMeasurements table, only contains measurements the subscriber is authorized to receive.

The ActiveMeasurements table always contain a field of type GUID named “SignalID.” The SignalID of the ActiveMeasurements table and the SignalID of the MeasurementDetail primary metadata table both describe the same measurement. Additional fields will exist as deemed necessary or appropriate by the publisher to assist the subscriber in filtering subscription requests.

The STTP publisher may expose additional tables to assist subscribers in the task of signal selection when responding to a “Subscribe” command. Examples of additional signal selection metadata tables available for queries by Filter Expressions could be an “AllMeasurements” table describing all measurements associated with the publisher, whether active or otherwise, and a “LocalMeasurements” table describing measurements local to this publisher, i.e., exclusive of measurements originating from another STTP publisher. Signal selection metadata is often temporal.


Page 12

Metadata Serialization

All metadata defined by an STTP publisher is represented as an in-memory cache of records that is structured similarly to information defined in a database, called a “data set.” A data set object consists of a collection of “data table” objects.

Data tables define of collection of “data columns” where each data column defines a name and data type. Data columns can also be computed where their values would be derived from other columns and functions defined in an expression.

Data tables also define a set of “data rows” where each data row defines a record of information with a field value for each defined data column. Each field value can be null regardless of the defined data column type.

A data set schema and associated records are read from and written in XML format. The XML specification used for serialization is the standard for W3C XML Schema Definition Language (XSD): https://www.w3.org/TR/xmlschema/.

See Appendix E for an example of “primary metadata” that has been serialized into XML.

Security

The required TCP-based command channel used by STTP can also be configured to authenticate with other STTP instances using Transport Layer Security (TLS). The TLS overlay enables publisher/subscriber authentication using public-key cryptography and provides secure, encrypted communications. Using TLS, data publishers also validate subscribers using X.509 certificates for strong identity verification. Certificates used validate that the identity of a subscriber connection can operate with a mutually trusted certificate authority or be managed privately.

For UDP-based data exchanges, data is encrypted using symmetric encryption keys that are dynamically exchanged over the existing TLS-secured TCP-based command channel.

In addition to transport security, the STTP design also incorporates data access control at the measurement level. A data publisher is always in control of what data any subscriber is permitted to access.

SYNCHROPHASOR PROTOCOL COMPARISONS

Ongoing work during the ASP project allowed for detailed comparisons of STTP to the existing synchrophasor protocols, specifically IEEE C37.118.2-2011 and IEC TR 61850-90-5. These comparisons included examinations of structure, efficiency, susceptibility to data loss, scalability, security, and other operability functionality including flexibility for transporting non-synchrophasor data streams.

Structure

The IEEE C37.118.2-2011 and IEC TR 61850-90-5 protocols are both frame-based. While efficient at all data volumes and effective with small data volumes, when used at scale (e.g., for systems

December 6, 2019


involving hundreds of PMUs), the frame-based nature of these protocols present network design and operational challenges that the protocols were never designed to handle. Large frame sizes can also have adverse effects on data completeness: as more devices are concentrated into a single frame of data, the larger frame sizes contribute to higher overall data losses.

Conversely, STTP is measurement-based without a fixed configuration, i.e., the identifiable data arriving in one packet of STTP data will differ from the identifiable data arriving in the next packet, and timestamps of data included within a data packet are not necessarily time-aligned. With STTP, data is partitioned at the application layer to minimize network fragmentation at the communications layer. Ideally the number of values sent per partitioned data packet are the total that will conveniently fit into one network packet, i.e., MTU size minus required headers. By reducing network fragmentation, the loss of a single packet over UDP does not constitute the loss of an entire frame of data, and retransmission of the packet over TCP does not induce increased latency and equipment stress due to frame reconstruction.

Efficiency

Because of the extra information required to be transmitted per measurement, the natural (uncompressed) bandwidth requirements of STTP will be higher than a fixed format frame-based protocol such as IEEE C37.118; however, production STTP deployments are normally configured with lossless compression. When STTP is used over UDP, each group of measurements is compressed before transmission, making the bandwidth requirements more comparable to IEEE C37.118 and other synchrophasor frame-based protocols. Testing has shown that after packet-level compression, STTP/UDP is roughly 1.8 times larger than IEEE C37.118 for the same data. However, when using STTP over TCP, stateful compression is used which allows for better time-series-based compression. The stateful compression results in the total bandwidth requirement for STTP/TCP being less than IEEE C37.118. Test results show that STTP is at least 30 percent smaller than IEEE C37.118 for the same data.

Since STTP needs to apply compression to achieve desired bandwidth utilization, there are legitimate concerns about the impact the compression algorithms will have on both CPU loading and memory utilization. However, testing shows that since there is no concentration involved with STTP, the impacts of compression are significantly less than those associated with IEEE C37.118.2-2011 and IEC TR 61850-90-5, mainly because no frames are being constructed and held in memory.

Susceptibility to Data Loss

To address the challenges of data loss caused by large frame sizes inherent to the standard IEEE C37.118.2-2011 and IEC TR 61850-90-5 synchrophasor protocols, some utilities have opted to implement purpose-built, dedicated networks exclusively used for synchrophasor traffic. Companies that have not implemented purpose-based networks have also used non-critical network infrastructure, including the internet, to share synchrophasor data due to the fear of overusing bandwidth on their respective wide area networks. Although a dedicated network is ideal at reducing data loss (minimizing simultaneous network traffic results in fewer collisions), most networks are a shared resource for many kinds of heterogeneous traffic. In these networks, the continual streaming of large frames of synchrophasor data results in an increased probability of UDP


Page 14

frame loss, or in the case of TCP, increased communication latency due to the higher than normal data packet retransmission rates. For example, in tests conducted by PeakRC, measured overall data loss for the transmission of all of its synchrophasor data using IEEE C37.118 over UDP averaged over 2 percent when using a data rate of 30 frames per second and more than 3,100 data values per frame.

Testing has shown that using STTP results in less synchrophasor data loss as compared to other protocols; however, the loss is only significant at scale, i.e., for larger data sets. For one large data volume test with UDP, IEEE C37.118 was measured to have 2.1-percent data loss vs. 0.14 percent for STTP.

Although the data loss for STTP in smaller datasets is about 6 times less for each, 0.31-percent data loss vs. 0.04 percent for medium datasets and 0.12-percent data loss vs. 0.02 percent for small datasets, the losses are still fractional. Consequently, only when the number of measurements included in a frame start to create frame sizes that require 20 or more network fragments for IP transmission, do the losses become significant.

Scalability

Both IEEE C37.118.2-2011 and IEC TR 61850-90-5 have a data frame size ceiling of 65K bytes – this creates a limit for information that can be exchanged between two parties in a single session. For example, with a synchrophasor stream that is publishing data at 30 samples per second, the maximum throughput is about 200,000 measurements per second. The 65K byte limit, as referenced in Zone 4 of Figure 1, means that no more than about 6,700 uniquely identifiable measurements can be published in one stream when using floating-point values.

In contrast, STTP does not require a fixed configuration nor does it specify a maximum limit on the number of identifiable measurements that can be exchanged; as such, STTP will scale to much higher volumes for data exchange, up to hardware limitations, see Figure 2. Current STTP implementations are limited only by CPU processing power used to serialize data.

Security

Since the IEEE C37.118.2-2011 protocol has no native security options, this is often a cited reason for using IEC TR 61850-90-5 as an alternative protocol. Certainly in lieu of native security options, many implementations of IEEE C37.118 have instead opted to deploy a Virtual Private Network (VPN) between sources and sinks needing to exchange data.

The IEC TR 61850-90-5 standard works with the pre-existing IEC 61850 security options, specifically IEC 62351-9. These security options make use of digital signatures ensuring only authenticated users have access to the desired data using the Group Domain of Interpretation (GDOI) protocol. GDOI handles security with UDP multicast security using a shared group key. This security implementation works out well since IEC TR 61850-90-5 is normally deployed over UDP multicast. For GDOI to function properly, a centrally accessible Key Distribution Center (KDC) – i.e., a KDC accessible to both publishers and subscribers – must be available. One of the challenges here is the necessity of establishing a centrally accessible KDC, especially when synchrophasor data will be traversing Critical

December 6, 2019


Infrastructure Protection (CIP) security zones where each higher security zone will not allow the ingress of connections – ultimately this requires that the KDC be in the least secure zone.

Security in STTP uses standard TLS over TCP. When a UDP channel is enabled, symmetric keys are exchanged over the TLS secured channel to secure the UDP traffic where the keys are specific to each subscriber. If desired and allowed by the publisher, multicast scenarios can also be supported; in this case each subscriber to the multicast stream would each receive the same shared keys after successfully establishing a TLS connection to the publisher. The certificates used in the STTP TLS connections are also used to authenticate and strongly identify subscribers. STTP adds an additional level of security not offered by the other synchrophasor protocols being compared, i.e., measurement-level access control per subscriber as controlled by publisher configuration. In this way a specific subscriber will only have access to data as explicitly authorized by a publisher.

Finally, to accommodate traversal of CIP security zones, STTP supports reverse connection options. A reverse connection allows publishers in a higher security zone to be configured to connect out to subscribers in a lower security zone, see Figure 6, which is necessary because initiating a connection in the other direction is otherwise not allowed.

Non-Synchrophasor Data Transport

The IEEE C37.118.2-2011 and IEC TR 61850-90-5 both accommodate the transmission of other, non-synchrophasor data using “analog” values, such as calculated data. Transmission of analog values is always within an existing frame along with other synchrophasor data at a specific timestamp.

Publication of extra data at a predefined timestamp creates a caveat that the analog values, ideally, should be published at the same rate as other synchrophasor data. Otherwise, if the publication frequency, i.e., the rate of calculation or measurement, of an analog value is less than the configured publication frequency of the host frame, a sentinel value will need to occupy the space in the frame for publication periods with no measurement, e.g., a not-a-number (NaN) value.

Publishing a sentinel value means that bandwidth is being unnecessarily consumed in cases where there is no data. Also, using a sentinel value can create a dilemma for meaning as NaN may represent a valid result for a calculated analog value. If the publication frequency of an analog value is higher than the configured publication frequency of the host frame, then the measured values will need to be downsampled into the target frequency. In either case, when the publication frequencies differ, the situation for analog value transport in a frame-based protocol is not ideal.

By contrast, in STTP each individual measurement can have its own publication frequency. This is easily accommodated because each STTP data packet does not have a fixed configuration and every measured value has its own associated identification, timestamp, and quality flags, see Appendix A. The per-measurement quality flags allow for an unambiguous representation of a value’s meaning; that is, the value is always exactly what is measured or calculated with no sentinels required, and the flags convey known state information about the analog value, such as its quality or the accuracy of the timestamp.


Page 16

Other Operating Functionality

Existing frame-based synchrophasor protocols only have prescriptive methods for the management of measurement metadata. While this prescriptive method can be well-suited for substation-to-control-center use, it becomes difficult to manage for measurement metadata that spans multiple analytic solutions and control centers, for example, inter-company data exchange where it becomes difficult to describe data for measurements with shared configuration owners or in a wide-area context, due to merging complexities. To help with merging disparate data sources, STTP allows for extensible metadata sets so that industry specific information about the data being exchanged can be included, and all STTP metadata is identified with 128-bit statistically unique GUID values to support dataset conflation, see Appendix E.

Protocol Comparison Summary

A table summarizing features of the three compared protocols is provided below:

FEATURE IEEE C37.118 IEC 61850 90-5 STTP

STRUCTURE Frame Frame Dynamic

EFFICIENCY Good Fair Excellent - TCP Fair - UDP

DATA LOSS (LOW VOLUME) None - TCP None - TCP None

DATA LOSS (HIGH VOLUME) * Low - TCP Some - UDP

Low - TCP Some - UDP

None - TCP Minimal - UDP

SCALABILITY Fair Fair Excellent

ENCRYPTION No Yes Yes

EXTENSIBLE METADATA No No Yes

MULTICAST SUPPORTED Yes Yes Limited

Table 2 - Protocol Comparison Table

* Frame-based protocols, e.g., IEEE C37.118 and IEC 61850-90-5, require a configurable wait time to time-align data in a process called “concentration.” Because any defined wait time is required to be finite, when the timeout eventually expires and not all source data has been received, data loss occurs even when using the lossless TCP transport protocol. These types of artificially induced data losses do not occur when using STTP as data using STTP is published upon receipt with no delays.

December 6, 2019


ACCOMPLISHMENTS AND CONCLUSIONS

The ASP project has met its objectives through the creation of the Streaming Telemetry Transport Protocol (STTP). The original success factors for STTP were defined for providing both cost savings and strategic value, these have been met as follows:

• Intrinsically Robust – STTP has been designed to operate with small packet sizes that are optimized for network maximum transmission unit (MTU) size which reduces network level fragmentation resulting in less data loss and latency.

• Security Centric – STTP has been developed with built-in, natively available security to manage authentication, encryption, and strong identity validation.

• Reduces First Cost – Using lossless compression techniques, STTP uses less bandwidth than IEEE C37.118. Additionally, the pub/sub data exchange methods result in only desired data being exchanged, thereby further reducing overall bandwidth requirements.

• Reduces Operating Cost – STTP automatically exchanges and synchronizes measurement level metadata using GUID-based key values for integration of metadata from multiple sources eliminating the need for a centralized registry and allowing group-based signal authorizations.

• Built Upon A Proven Approach – STTP was designed on successful elements of GEP and includes many improvements over the original protocol.

Additional accomplishments for the ASP project have been realized through the successful development of STTP APIs and associated tools, detailed protocol testing, and kick-starting the standardization process for the protocol. Each of these successes are detailed in the following sections.

API DEVELOPMENT

To enable successful integration of STTP into vendor products, GPA invested considerable resources into the development of the STTP APIs. Several language implementations of the STTP API were published and made publicly available. These open source API implementations were provided using the permissive MIT license allowing the source code to be used in any vendor application without restriction. See http://sttp.stream to access API implementations.

The STTP APIs currently include both a low-level C++ STTP API and a .NET Standard STTP API that supports any .NET deployments. More language implementations are planned, including targets for both Python and Go.

Also included are tools to help with integration testing, e.g., the STTP Connection Tester, a graphical application used to validate subscription-based connections are working properly. For detailed information see Appendix B which covers product production and technology transfer.

The GitHub site also includes the latest documentation on the use of STTP: https://sttp.github.io/documentation/.


Page 18

During the ASP project, the STTP API has been used to incorporate STTP publisher and subscriber functionality into production products for Grid Protection Alliance (GPA), Schweitzer Engineering Laboratories (SEL), Washington State University (WSU), Electric Power Group (EPG) and PingThings. Other project participants and vendors having committed to supporting the protocol once it is published as a standard or earlier upon customer request.

All current versions of GPA time-series focused software now fully support STTP, this includes:

• openPDC v2.7

• SIEGate v1.7

• substationSBG v1.5

• PDQTracker v1.4

• ProjectAlpha v0.5.4

These updated software releases were used for testing STTP at Southwest Power Pool (SPP), Tennessee Valley Authority (TVA), Oklahoma Gas & Electric (OG&E), and San Diego Gas & Electric (SDG&E) per protocol testing performed for the ASP project.

STTP TESTING

The ASP project has shown, through testing by TVA, SPP, WSU, and EPG, to meet the major project objectives. Through this testing, STTP was found to significantly outperform existing protocols when exchanging data at scale. Improvements were made possible through use of optimized network packets designed for high-volume data throughput, eliminating the need for dedicated, purpose-built phasor networks. Using TCP and lossless compression techniques, STTP has eliminated losses experienced by operators of large phasor networks while simultaneously reducing bandwidth requirements by about 40 percent. When using UDP, STTP has significantly reduced data loss for large data feeds.

Eastern Interconnection Data Sharing Network (EIDSN) Testing

On April 2, 2019, a test of STTP was conducted over the EIDSN between TVA and SPP. The GPA SIEGate product was extended with STTP functionality to perform this test. Using SIEGate allowed for the safe co-mingling of phasor data with other operational data network traffic rather than having to isolate phasor data on purpose-provisioned networks.

For the test, the EIDSN was used as the transport mechanism for TVA to publish phasor data and SPP to subscribe to it, see Figure 8. The phasor data for testing was simulated for scaling consistency. A limit of 5 Mbps was allocated for the testing to minimize impact to the production EIDSN data feed. All testing was done using TCP/IP, and multiple cases were run using both the IEEE C37.118 protocol and the STTP protocol.

December 6, 2019


Figure 8 -Test Setup for Evaluation of STTP Over the EIDSN

The configuration steps for the STTP / EIDSN test were as follows:

1. SPP created an authentication request for TVA to initiate a new data subscription. For this test, TVA was the publisher of data and SPP was the subscriber. The request was privately and securely exchanged between SPP and TVA, out-of-band.

2. TVA imported the SPP authentication request to create a new validated SPP subscriber. The request included the SPP X.509 public certificate that TVA used to identify and secure the connection.

3. With a new SPP subscriber setup as a valid recipient of data, TVA authorized which data, i.e., specific measurements, SPP would be allowed to access.

4. Upon authorization, SPP automatically “saw” available points for authorization. SPP selected the desired signals it wanted to receive out of the available measurements that were authorized.

5. Upon selection of desired signals, STTP traffic began to flow over EIDSN.

Metrics being monitored during the test included monitoring of CPU, bandwidth, and memory as compared to the same data being exchanged using IEEE C37.118. Figure 9 shows that for comparable point ranges, i.e., data volumes, overall bandwidth requirements for STTP are reduced as compared to IEEE C37.118


Page 20

Figure 9 - EIDSN Test Results. STTP vs. C37.118

STTP had lower bandwidth requirements, as shown below in Figure 10, where IEEE C37.118 peaked at about 1,200 measurements (or signals) per Mbps of bandwidth consumed. STTP was able to move about 40 percent more points (1,700) for the same Mbps of bandwidth over the range of measurement volume tested.

Figure 10 - EIDSN Test Results. STTP Has Greater Throughput

December 6, 2019


WSU Product Testing

The objective of the WSU testing was to validate that the WSU online stability monitoring tools had been successfully modified to use the new STTP protocol. Four stability monitoring algorithms that were previously developed at WSU, namely, Damping Monitor Real-time using Fast Frequency Domain Decomposition (DMR-FFDD), Damping Monitor Real-time using Fast Stochastic Subspace Identification (DMR-FSSI), Event Analysis Real-time (EAR), and Angle Stability Monitor Real-time (ASMR), were tested in this project. Prior to this project, the four WSU tools normally consumed phasor data from the host utility’s PDC as an IEEE C37.118 stream.

The four stability monitoring algorithms mentioned above are all based on analyzing wide-area synchrophasor measurements in real-time to detect the presence or emergence of specific instability mechanisms. DMR-FFDD and DMR-FSSI analyze ambient synchrophasor data to estimate the oscillatory modal characteristics of power system small-signal stability phenomena. EAR waits for occurrence of switching events such as tripping of transmission lines or synchronous generators to estimate dominant modal features from wide-area power system responses. ASMR is aimed at automatic detection of emergence of asynchronous islands or loss of angle stability among the PMU phasor measurement signals.

The four engines together provide an excellent framework for verifying the fidelity and quality of synchrophasor measurements as received from the STTP protocol. For instance, if the data quality received in the DMR-FFDD and DMR-FSSI engines were poor, the engines would not be able to estimate any meaningful modal characteristics from the STTP based synchrophasor data. Similarly, bad data in EAR and ASMR would lead to the engines issuing many false alarms of instability events when there are no such events in the real system.

WSU installed their tools at TVA, SPP, OG&E, and SDG&E. All these utilities use GPA products to provide the concentrated phasor data stream to the WSU tools – either via anopenPDC or SIEGate platform

Test data was able to be collected by WSU at two utilities – OG&E and SDG&E. In both cases, the installed WSU tools have been modified under this project to consume streaming synchrophasor data in STTP.

The test data provided in Appendix C was used to verify operability and functionality of the WSU tools when using the new STTP protocol. This was a qualitative assessment that showed that the tools performed well while receiving PMU data in STTP protocol. No issues were found in the WSU tools as STTP was tested thereby validating the protocol had been successfully implemented by both the data provider (GPA tools) and the data consumer (WSU tools).

Specifically, the ambient modal analysis engines DMR-FFDD and DMR-FSSI consistently estimated the dominant modal characteristics of the well-known system modes in the eastern and western interconnections and the results matched well across he two engines as well. This proved that the PMU data received by DMR-FFDD and DMR-FSSI using the STTP protocols were of high quality and the protocol preserved all the essential dynamic features of the original PMU data during transmission. There were few instances of low damping alarms with high confidence that were reported to the utilities and these are likely related to local oscillatory modes associated with unknown generation and control equipment.


Page 22

The event engine EAR did not detect any major event during the test period in both OG&E and SDG&E implying that there were no false alarms issued. Similarly, ASMR did not detect any instance of islanding during the test period and indeed there were no such reported instances during the test period. In this regard, both EAR and ASMR worked as expected during the test period in SDG&E and OG&E which again points to the high fidelity of measurements received from the STTP protocol.

EPG Product Testing

The ASP project objective of the EPG testing was to validate integrated STTP functionality in their suite of products. As part of this testing, GPA participated with EPG in a collection of STTP-based data to verify STTP API functionality. Figure 11, below, shows the high-level data flow used for this evaluation.

Figure 11 - Data Flow for EPG Evaluation of STTP

The scope for EPG testing included testing the functionality, performance, latency, network efficiency and reliability of EPG products after implementing STTP functionality in EPG’s commercial synchrophasor products such as ePDC and RTDMS Server.

The EPG factory acceptance testing was conducted by a dedicated testing team using pre-defined test cases that were documented their plan.

The factory acceptance test was performed over multiple cycles of functional and reliability tests of the EPG products while using STTP. After successful factory acceptance testing, EPG’s products were used in the real-time demo evaluation of STTP as shown in Figure 11.

See Appendix D for details on EPG testing.

Additional Product Testing and Integrations

The STTP protocol is now in production use in the full suite of open source synchrophasor products offered by GPA. Through use of the project-provided open source APIs for C# and C++, STTP is being used in production vendor products from SEL, EPG, and PingThings.

STTP is currently deployed with the new SEL “SynchroWAVe” time-series data management and visualization platform to support external real-time streaming data feeds:

December 6, 2019


Figure 12 - SEL SynchroWAVe Modified to Incorporate STTP

As an ASP project deliverable, EPG has developed STTP integrations into two of its primary commercial synchrophasor products, the “ePDC” and the “RTDMS” visualization and analysis suite.

PingThings has work currently in progress to incorporate STTP into its cloud-based data management and analysis system, “The PredictiveGrid Platform.” This is in addition to its existing GEP-based implementation, which is actively used to send streaming, real-time synchrophasor data from Dominion to the Amazon Web Services (AWS) cloud.

STANDARDIZATION PROCESS

One of the primary objectives of the ASP project was to work with standards bodies to put STTP on a track for consideration as a standard protocol. Early presentations on the ASP project and the STTP design were made to various industry and standards organizations including the North American Synchrophasor Initiative (NASPI), the North American Electric Reliability Corporation (NERC), the Synchronized Measurement Subcommittee (SMS), the Western Electricity Coordinating Council (WECC), the Joint Synchronized Information Subcommittee (JSIS), the Institute of Electrical and Electronic Engineers (IEEE), and the Internet Engineering Task Force (IETF).

Meeting the objective for starting the standardization process for STTP, in the Fall of 2018, the IEEE standards board approved a Project Authorization Request (PAR) and assigned a standard number of 2664 for development of a new IEEE standard based on the STTP specification. See the associated IEEE project site for more details: https://standards-stg.ieee.org/project/2664.html.

The IEEE working group associated with the standard is currently being chaired by Ken Martin, the original project lead on the IEEE C37.118 synchrophasor standard protocol.

For more information, see the IEEE P2664 section in Appendix B which covers product production and technology transfer.


Page 24

ACCOMPLISHMENT SUMMARY

The ASP project successfully developed STTP which has been shown, through testing by TVA, SPP, WSU, and EPG, to meet the major project objectives. Through its use of optimized network packets designed for high-throughput, STTP eliminates the need for dedicated, purpose-built “phasor networks.” Using TCP and lossless compression techniques, STTP has eliminated losses experienced by operators of large phasor networks while simultaneously reducing bandwidth requirements by about 40 percent. When using UDP, STTP has significantly reduced data loss for large data feeds.

GPA has made over 14 presentations to technical audiences over the life of project and released a major document – the STTP Specification, see Appendix A.

In Fall 2018, the IEEE approved a PAR and assigned the number IEEE 2664 for development of a new standard based on the STTP specification.

GPA has released 4 significant open source software packages on GitHub to support the STTP Specification (see Appendix B for detail):

1. C++ STTP API

2. .NET Standard API

3. Grid Solutions Framework API

4. STTP Connection Tester

The STTP protocol is now in production use in the full suite of open source synchrophasor products offered by GPA. Through use of the project-provided open source APIs for C# and C++, STTP is being used in production vendor products for SEL, and EPG and is under active development with PingThings.

NEED FOR CONTINUED STTP ADVOCACY

GPA and the other project partners have been pleased with the support provided by the IEEE PES PE/PSCC - Power System Communications and Cybersecurity. We especially want to thank Ken Martin of the Electric Power Group for his leadership and guidance in his chairing this working group.

The process for development, review and approval of a new IEEE standard is purposely deliberate to assure that the standards created have been well reviewed, are of high quality and have lasting value. Even though work on standardizing the STTP protocol started in early 2018, about one year into the project, it is estimated that the goal of having a fully approved standard for the STTP protocol will take at least two more years -- to December 2021 or later.

Importantly, GPA believes that expert support and attention to the IEEE standards process will be required to assure that STTP ultimately becomes formalized as a standard protocol.

The estimated funding required to provide this expert support would include attending three working group meetings per year and participating in occasional working group calls as well as preparation for both. This translates into about 80 hours per year ($13,600) plus a travel estimate of $9,000 (estimated for three trips) per year. Total annual cost of approximately $25,000 per year.

December 6, 2019


APPENDIX A - STTP PROTOCOL SPECIFICATION

STTP leverages the successful design elements of the GEP that was developed under the DOE-funded Secure Information Exchange Gateway (SIEGate) Project (DE-OE0000536). GEP was developed for the secure exchange of data necessary to support real-time (i.e., current day) grid operations. The real-time data exchange requirement includes synchrophasor data, SCADA data, and file-based data. Although GEP is open source with a permissive MIT license and is widely used by utilities, multi-vendor adoption has been slow. Moreover, regardless of benefits, GEP is not a standard, just an open protocol. Through the ASP project, STTP built on GEP’s successful features and is on track to become a new standard, IEEE 2664.

PROTOCOL STRUCTURE

Since development of STTP is still ongoing, some of the details described here may differ from those published when the protocol specification is complete. More specifically, the process of STTP standardization, through the IEEE P10 working group for P2664, is certain to result in changes to the specification as the group of collaborators expand as part of the standardization process. However, the fundamental invariable tenets of STTP, based on the successful design elements of GEP, are well defined and production proven. These are:

• Simple command and response architecture

• Publisher capability to control both data and metadata accessibility for individual subscribers at the measurement level

• Subscribers limited to only the data and metadata they are authorized to receive

• High-volume, high-speed, compact transfer of time-series data from publisher to subscriber with minimal loss through controlled packet sizing

• Ability to encrypt data, specific to subscriber, and use rotating keys

All STTP traffic is composed of simple commands and responses that can each optionally carry a payload. Typically, a subscriber will issue commands, and a publisher will answer with responses. Commands from the subscriber include a command type, an optional payload length, and optional payload bytes. Responses from the publisher include a response type, an in-response-to command type, optional payload length, and optional payload bytes. Often the response type will simply indicate success or failure with an associated message, otherwise the response type will indicate that a specific payload format is in use, e.g., a data packet.

Payloads with Strings - Some of the payloads of command and response messages will be a string or will contain strings. In STTP, all strings are encoded in natural order from left to right, using the character encoding method established in the initial DEFINE OPERATIONAL MODES command, e.g., Unicode Transformation Format (UTF)-8 or UTF-16 (see Table A2).

STTP Commands - The subscriber command message consists of a command type, an optional payload length, and any payload bytes. The elements that make up the STTP command message are


Page 26

described in the table below:

FIELD BYTE SIZE DESCRIPTION

COMMAND TYPE

1 Command type (see Table A2)

PAYLOAD LENGTH

0 or 4 Number of bytes of payload, if specified command type includes payload (INT32)

PAYLOAD VARIABLE Actual bytes of payload, if any

Table A1 - STTP Command Message Fields

The STTP command message types that can be sent by a subscriber and received by a publisher are shown below in Table A2.

Note that after sending a solicited command message to the publisher, the subscriber will normally receive a SUCCEEDED or FAILED response message along with an associated message in the payload, i.e., a string of text, detailing the success or failure of the command operation. The payload type for other response successes will be based on the response type. For example, the publisher response for a successful METADATA REFRESH command will be a serialized dataset of the available publisher metadata specifically allowed for the subscriber. The payload content for failed responses will always be a string of text representing the error message. Many command types also require a payload which is specific to the requested command, these are described in the table below:

December 6, 2019


COMMAND TYPE DESCRIPTION PAYLOAD METADATA

REFRESH 0x01 Requests that the publisher send an updated set of

metadata so that the subscriber can update its dataset. The successful response message type is a dataset containing the server device and measurement metadata. Devices and measurements contain GUIDs that are used to uniquely identify metadata in local repository allowing datasets to be merged as received from multiple subscriptions.

Optional

SUBSCRIBE 0x02 Requests a subscription of streaming data from the publisher based on a provided connection string. The connection string contains parameters that specify the desired measurements and control if the subscription is for real-time or historical data, when supported. It is not necessary to stop an existing subscription before requesting a new one. The successful response is a message indicating the total number of allowed measurements. Upon successful subscription, the subscriber will also receive an UPDATE SIGNAL INDEX CACHE response that will allow parsing of newly subscribed measurement data.

Yes

UNSUBSCRIBE 0x03 Requests that the publisher stop sending streaming data to the subscriber. This command cancels the current subscription.

No

ROTATE CIPHER KEYS

0x04 Requests that the publisher send a new set of cipher keys for encryption of information transmitted on the data channel. The response will include two keys (an old one and a new one) to accommodate any time-slew with transitioning from one key to another. To protect symmetric key exchange, this command should only be used in conjunction with a Transport Layer Security (TLS)-based command channel.

No

UPDATE PROCESSING

INTERVAL

0x05 Requests that the publisher update its historical data replay processing interval with the specified value in milliseconds – this only applies for a subscription setup to replay historical data, not to a real-time stream. Except for the values of -1 and 0, this value specifies the desired processing interval for data, i.e., basically a delay, or timer interval, over which to process data. A value of -1 means to use the default processing interval while a value of 0 means to process data as fast as possible.

Yes

DEFINE OPERATIONAL

MODES

0x06 Defines the protocol version and operational modes for a subscriber connection. As soon as a connection with a publisher is established, this command defines the server operational modes used for subscriber and publisher communication (e.g., compression options or text encoding style). This command can be used only once per connection and must be the first command to be sent by the subscriber to the publisher.

Yes


Page 28

COMMAND TYPE DESCRIPTION PAYLOAD CONFIRM

NOTIFICATION 0x07 This command is sent to a publisher to confirm that a

NOTIFY response was received. This is used to verify delivery of critical messages from publisher to subscriber, e.g., a control operation.

Yes

CONFIRM BUFFER BLOCK

0x08 This command is sent to a publisher to confirm that a BUFFER BLOCK response was received. This is used to verify delivery of a data blocks that may require continuity and sequencing, e.g., a file data block.

Yes

Table A2 – STTP Command Types

STTP Responses – The publisher response message consists of a response type, an in-response-to command type, payload length, and actual payload bytes. The in-response-to command type is required even if the response is unsolicited. In Table A3 below, the elements that make up the response message are described.

FIELD BYTE SIZE DESCRIPTION

IN RESPONSE TO COMMAND TYPE 1 The in-response-to command type (see Table 10. STTP Command Types).

PAYLOAD LENGTH 0 or 4 Number of bytes of payload, if specified response type includes payload (INT32).

PAYLOAD Variable Actual bytes of payload, if any.

Table A3 – STTP Response Message Fields

The size of the payload, if any, is specific to the response type. For example, in the case of a data packet response, the payload will contain serialized measurements. Although the subscriber commands and publisher responses will be on two different paths, the value code used for response types are defined as distinct from those used for command types to make it easier to identify values from a wire analysis. Normally, response messages are issued in response to subscriber commands; however, they may also act like commands sent by the publisher to the subscriber that are not necessarily solicited – regardless, they are still referred to here as responses for clarity in communicating data flow direction. Many response types also require a payload which is specific to the specified response, these are described in the STTP Response Payloads Appendix.

December 6, 2019


RESPONSE TYPE DESCRIPTION PAYLOAD SUCCEEDED 0x80 Informs the client that its solicited server command

succeeded, a success message payload follows. Yes

FAILED 0x81 Informs the client that its solicited server command failed, a failure message payload follows.

Yes

DATA PACKET 0x82 Informs the client that a data packet follows. Yes

UPDATE SIGNAL INDEX CACHE

0x83 Requests that the client update its runtime signal index cache with the one that follows.

Yes

UPDATE BASE TIMES

0x84 Requests the client update its runtime base-timestamp offsets with those that follow.

Yes

UPDATE CIPHER KEYS

0x85 Requests the client update its runtime symmetric encryption keys with those that follow and use the keys to decrypt data. This is only applicable when the data channel is using a UDP socket. Keys should only be transferred and used in conjunction with a TLS-based command channel.

Yes

DATA START TIME 0x86 Provides the start time of data being processed from the first measurement.

Yes

PROCESSING COMPLETE

0x87 Provides notification that historical replay processing has completed, established with via temporal constraints parameters, i.e., StartTimeContraint and StopTimeConstraint connection string parameters.

No

BUFFER BLOCK 0x88 Informs the subscriber of a buffer block (included in payload). This works with a specially defined measurement, still requiring subscription, that allows a free form transfer of data that does not conform to a time-series value. Data in block must still be partitioned to fit within a minimal number of network packets. Subscriber will be required to acknowledge reception of BUFFER BLOCK with a CONFIRM BUFFER BLOCK command since blocks may exist as a sequence of packets and require retransmission when used over a lossy communications transport, e.g., UDP.

Yes

NOTIFY 0x89 Informs the subscriber of a critical notification (included in payload). This works with a specially defined measurement, still requiring subscription, that allows subscriber to receive messages with verified delivery. Since message is considered critical, subscriber must respond with a CONFIRM NOTIFICATION command since message may require retransmission when used over a lossy communications transport, e.g., UDP.

Yes

CONFIGURATION CHANGED

0x8A Provides a notification that the publisher's source configuration has changed, and that client should make a request to refresh metadata.

No

NO OP 0xFF Informs the subscriber that communications channel is still active. Since it is possible for the command channel to remain quiet for some time, this command allows a periodic test of continued connectivity.

No

Table A4 - STTP Response Types


Page 30

PROTOCOL TIMESTAMP FORMAT

Timestamps in STTP are encoded as a 64-bit integer representing the number of 100-nanosecond intervals since 0/0/0001, often referred to as a tick. This provides a very high-resolution timestamp, accurate to one ten-millionth of a second with a long year-range, specifically: 00:00:00.0000000 Coordinated Universal Time (UTC), January 1, 0001 to 23:59:59.9999999 UTC, December 31, 9999, exactly one 100-nanosecond tick before 00:00:00.0000000 UTC, January 1, 10,000 – Gregorian calendar. The 64-bit timestamp is rarely transmitted in its full form since most of the bits representing the time change slowly and STTP Data Compression.

PROTOCOL SECURITY

STTP requires the use of a TCP-based command channel for actions, such as a subscription. The TCP-based command channel is used to reliably negotiate session specific required communication, state, and protocol parameters. It is also used to authenticate with other STTP communications appliances, exchange metadata on points, and request points for subscription. This same channel is also used to apply transport layer security (TLS) for publisher/subscriber authentication using public-key cryptography and secure communications. TLS uses X.509 identity certificates for authentication, strong identity verification, and encryption. STTP publishers can use a locally accessible subscriber certificate to validate the identity of a subscriber connection; this can be done in conjunction with a mutually trusted certificate authority or managed privately.

STTP is configurable to allow use of private, i.e., self-signed, certificates in highly isolated environments. In the absence of key management infrastructure, such as deployments with no Internet access or mutually accessible certificate authority, STTP can use self-signed X.509 identity certificates that are securely exchanged between publisher and subscriber, out-of-band, i.e., not on the same communications channel used for data exchange.

When the data is optionally enabled over a UDP socket, the data transmitted on this channel can be encrypted using symmetric encryption keys that are dynamically exchanged over the existing TLS secured TCP-based command channel. When UDP is not used, the data channel information is transmitted over the existing command channel TCP socket.

STTP also incorporates access control at the measurement level. Subscriptions allow for dynamic data and metadata exchange with availability change notifications and the ability to automatically update streaming data values. However, all data and metadata available to a subscriber are subject to publisher discretion and can be changed even when a subscription is active. Although STTP can be configured without its security features enabled, the publisher can always decide if it will allow unsecured connections or data access to unrecognized subscribers. Applications implementing STTP publisher functionality will need to log changes to configuration and administrative actions, which includes data access control, to facilitate compliance with North American Electric Reliability Corporation (NERC) Critical Infrastructure Protection (CIP) standards.

Although STTP can be used over a Virtual Private Network (VPN) tunnel to provide security, there may be benefits in many deployments to directly using a TLS implementation instead. For one, in order for a publisher to strongly validate the identity of a subscriber, an X.509 certificate will be

December 6, 2019


required even if a VPN tunnel is used to exchange data. As seen in Table A5 below, STTP over TLS is an alternative to the use of VPN for securing the transfer of streaming utility operating data.

STTP / VPN APPROACH STTP / TLS APPROACH Security managed at the network interface level

Security managed at the application layer with flexible pairwise, i.e., per publisher / subscriber, security

Traffic protected only if it reaches the VPN tunnel – susceptible at previous levels

Traffic is encrypted from source minimizing internal exposure

VPN failure can result in (1) unencrypted data flows, or (2) failure of data flows

Connection failure results in automatic retries, renegotiating keys at each attempt

Network issues may require human intervention to restart data flows

Network issues cause data flows to be automatically reestablished

Table A5 - Comparison of STTP / VPN to STTP / TLS Security

Data Integrity - Unlike the IEEE C37.118.2-2011 and International Electrotechnical Commission (IEC) TR 61850-90-5 standards which employ the use of an additional checksum in their protocol implementation, STTP, which is only designed for IP-based transport, does not include checksums in its payload since, (1) checksums are already applied at the IP transport layer, and (2) payload sizes are targeted to fit within a minimal number of data packets, ideally just one. Since STTP is an IP-only protocol and existing data packet checksums are already validated by operating system IP implementations, no extra time or space is allocated to an additional application layer checksum value.

BANDWIDTH UTILIZATION

Compared to frame-based protocols, which include a single timestamp per frame of simultaneously measured data and define a fixed order to identify measurements, the raw binary format for an equivalent group of STTP measurements, where each serialized measurement has its own timestamp and identification, will be always larger. However, production deployments of STTP rarely send data in a raw binary form; instead, data is always compressed before transmission. Compression techniques result in TCP-based deployments being smaller than IEEE C37.118.2.2011, and UDP-based deployments being on-par with IEC TR 61850-90-5 deployments.

STTP DATA COMPRESSION

Synchrophasor data is comprised of periodic measurements that are recorded at a data sampling rate that is sufficiently high to infer the gradient of change of this data; as such, synchrophasor data is a suitable candidate for compression. Compression algorithms are typically classified into two categories, “lossless” and “lossy.”

As their names infer, lossless compression allows reconstruction, i.e., “inflation,” of the compressed data back to the original source data with full fidelity; whereas inflation of data compressed using a lossy compression algorithm will produce data that is only an approximation of the original data. In


Page 32

terms of computational costs, lossy compression is typically less expensive than lossless compression.

The field of computer science is replete with algorithms for data compression, lossless, and lossy, each of which offer tradeoffs in the needed time required to compute the greatest reduction in size. The more CPU time that can be invested in the computation, the better the size reduction; however, the results from increased time investment are non-linear and subject to diminishing returns. Since synchrophasor data is recorded at a high sampling rate and any additional computational activity, like compression, will subsequently increase delivery latency, the available time investment for compression is small and any selected algorithm must be fast and computationally inexpensive.

Although use-cases could be envisioned where a lossy compression algorithm could be tolerated, STTP instead always uses a lossless compression algorithm so that the original data is retained in its full fidelity. The choice of the best lossless compression algorithm to apply depends on the nature of the transmission protocol selected.

When a TCP socket is being used for data channel traffic, it can be assumed that there will be no data packets dropped over a given connection between a publisher and subscriber; as a result, a compression algorithm that works across a longer window of gradually changing waveform data can be selected. When a UDP socket is being used for data channel traffic, the lossless compression algorithm will have no choice but to focus on compression of the data for an individual packet, not across multiple packets – this is because with UDP, packets can be dropped and the process of lossless inflation of compressed data with common algorithms does not tolerate loss.

An additional compression issue exists with attempting to optimize data packet utilization. With the target compressed size being one network data packet, there can be complications with trying to estimate and balance the total amount of uncompressed source data that will to go into a single compressed data packet as compression ratios depend entirely on the compressibility of the source data with the selected compression algorithm. This is often less of a concern for TCP since compressed source data can be easily partitioned into the desired target data packets, but for UDP, the choice is to instead take a conservative approach and try to minimize the number of target frames based on typical compression ratios for the target data and given number of source measurements.

STTP TCP COMPRESSION

The current compression algorithm developed for STTP, when used over TCP, is called Time-Series Special Compression (TSSC). It is expected that new algorithms may be developed in the future with better applicability for given use cases; therefore, STTP requires the flexibility to accommodate new algorithms that can be specified and negotiated when a connection is established without requiring changes to the protocol.

Since STTP can transport most any kind of data, applying a compression algorithm that is used for general purpose data might seem ideal. However, most available lossless streaming compression algorithms, e.g., LZ4, tend to perform worse than simply applying the ubiquitous Gzip algorithm over a single data packet. However, with a little insight into the data being processed, it is possible to apply streaming compression rules to specific data elements longitudinally and, based on the nature of the data, produce exceptionally good compression ratios with minimal CPU impact.

December 6, 2019


TSSC takes each of the elements of a data packet and handles each data type with separate compression algorithms, creating parallel compression streams for each data element in the data packet. The nature of the data element being compressed then infers the necessary compression algorithm tuning to produce the best results. As an example, with a typical subscription, timestamps tend to be near each other, normally varying by no more than a few seconds. For the 64-bit timestamps in STTP, this means the data variation may only occur in the bottom 16 of the total 64 bits of the timestamp. With the bulk of the bits repeating invariably, the total bit set needs to be only transmitted once or on substantial change, then only the changing bits need to be sent. Additionally, if the timestamps vary less, the algorithm can automatically adjust and send even fewer bits. This same type of pattern works well for identification numbers, which are finite in number, and state flags, which vary little. Data values, however, need special attention.

Data value elements for a given data packet can seem to be quite random; however, many values change slowly over time, from packet to packet. For example, a measured frequency value tends to change only incrementally over several data packets; in fact, other frequencies in the same subscription may only differ by just a few bits. With this knowledge, a table of various base values can be maintained that represent the unvarying bits of many types of measurements. Now only the changed bit values need to be encoded into the stream with enough detail, such as which table entry to use, so that the stream can be losslessly reinflated upon reception.

The actual data going in the data packet payload will now be a chunk of the compressed data stream instead of individual serialized measurements. The STTP API will simply target chunk sizes to meet configured maximum packet size, still fragmenting at the application layer to eliminate the need for buffer reconstruction at the network layer thereby reducing latency.

In practice, for synchrophasor data, this algorithm has negligible impact on memory and CPU and produces data compression that reduces STTP bandwidth consumption to less than that required by IEEE C37.118 for the same data. However, since the algorithm depends on the evolving states of data over time, it can tolerate no intermediate data loss, so a TCP data transport channel is required to use this algorithm.

STTP UDP COMPRESSION

Using UDP for data transmission means the possibility exists for data packet loss and, at present, lossless compression algorithms operate with this caveat. Consequently, the current best option is to apply compression over an individual data packet, ignoring gains that might be acquired over several packets. However, since compressed data is expected to be smaller than the source data, some tuning can go into how much source data can be used to create the configured maximum packet size.

The current algorithm used for STTP over UDP is the common Gzip algorithm. Application of the compression takes the simple approach of serializing the data packets as normal, then applying Gzip compression over the payload. In practice for synchrophasor data, this algorithm has minimal impact on memory and CPU and produces data compression that reduces overall STTP bandwidth consumption; however, even after compression, the size is more than that required by IEEE C37.118 for the same data, although comparable to IEC TR 61850-90-5.


Page 34

The current simple Gzip compression operation does not produce the notable results seen with TSSC. However, since a TCP-based command channel is always available with STTP, it is likely that a variation of the TSSC algorithm, using a persistent compression table maintained reliably over the command channel, could be developed to produce much better compression ratios when using UDP, perhaps on par with those seen in a TCP only connection.

December 6, 2019


APPENDIX B – PRODUCT PRODUCTION AND TECHNOLOGY TRANSFER

One of the major objectives of the ASP Project was for STTP to become a widely accepted, standard protocol for use in the electric utility industry. The Project Team pursued a three-fold strategy to achieve this objective. First, the Project Team included major players from the electric utility industry, equipment manufacturers and software vendors (see Table 1). Second, STTP was developed through a public process in which input and comments were actively solicited and the protocol was developed utilizing GitHub (https://github.com/sttp/Specification). Thirdly, early and frequent presentations on the project and protocol were made to industry and standards organizations (NASPI, NERC, SMS, WECC, JSIS, IEEE, IETF) resulting in STTP being selected for inclusion in the IEEE standards development process.

Over the course of the ASP project, STTP has been incorporated into production products for GPA, SEL, WSU, EPG, and PingThings – with many other vendors committing to supporting the protocol once it is published as a standard or earlier per customer request.

An evaluation of STTP compared to IEEE C37.118 and IEC 61850 90-5 was conducted by Pacific Northwest National Laboratory (PNNL) and documented in the following report: https://www.osti.gov/biblio/1504742.

OPEN SOURCE SOFTWARE RELEASED ON GITHUB

Several language implementations of the STTP API have been officially published and made available. Each API implementation is available, including all source code and build documentation, using the highly permissive MIT license which makes the code suitable for use in any vendor application without restriction.

All source code and documentation can be found from the following URL: http://sttp.stream, which redirects to the primary GitHub site (https://github.com/sttp/) that hosts each of the software repositories. Below is a summary of a few of these repositories:

1) C++ API (https://github.com/sttp/cppapi):

The C++ STTP API is a low- level implementation of the STTP API that includes both publisher and subscriber implementations that work in a variety of environments, e.g., Linux and Windows, and is suitable for deployment on custom hardware solutions.

The current released version is v1.0.17 (https://github.com/sttp/cppapi/releases).

2) .NET Standard API (https://github.com/sttp/net-cppapi):

The .NET Standard STTP API is a .NET-based implementation that supports any .NET Core and .NET Framework deployments. This implementation wraps the existing C++ API as a dependency, meaning the speed of the C++ API is made available to any .NET implementations.

The current released version is v1.0.8 (https://github.com/sttp/net-cppapi/releases).

This API can also be referenced via NuGet: (https://www.nuget.org/packages/sttp.net/).


Page 36

3) Grid Solutions Framework (GSF) API (https://github.com/sttp/gsfapi):

The GSF STTP API is an implementation of STTP used by any application that implements the Time-Series Library of GSF, e.g., openPDC, openHistorian, Project Alpha implementations, etc.

This highly performant implementation is implemented as adapters of the Time-Series Library and is already widely deployed.

The current released version is v1.0.79 (https://gridprotectionalliance.org/NightlyBuilds/sttp-gsfapi/).

4) STTP Connection Tester (https://github.com/sttp/connection-tester):

The STTP Connection Tester is graphical application that is used to validate that a subscription-based connection is working as expected. It can also be used to validate filter expressions that can be used to select a set of points in hosted STTP publishers.

Vendors can use this tool to validate that publishing implementations of STTP are working as expected.

The current released version is v1.0.4 (https://github.com/sttp/connection-tester/releases).

5) STTP Specification (https://github.com/sttp/Specification):

The open process of the original STTP specification was developed on this site. The content of this site, as well as other published documents, has been used as the basis for current content in the IEEE standard. This repository and all its material will remain for posterity and reference, but any future specifications and requirements now belong to the IEEE standard with the responsibility of any arbitration of differences being deferred to IEEE as the correct implementation, albeit with a new version number to distinguish any differences from the current STTP deployments.

6) STTP Documentation (https://sttp.github.io/documentation/):

Documentation on use of STTP is actively growing. As new documentation continues to be added, it will be posted to the URL above.

IEEE P2664

The IEEE Standards Committee approved a Project Authorization Request (PAR) for the standardization of STTP on September 27, 2018, with the “PE/PSCC - Power System Communications and Cybersecurity,” part of the “PE - IEEE Power and Energy Society,” as the sponsor committee.

The draft standard working group is currently being chaired by Ken Martin, a technology leader in synchrophasors and the project lead on the original synchrophasor standard protocol, IEEE C37.118.

December 6, 2019


The IEEE proposed standard number for STTP is 2664. The official IEEE project web site can be found here: https://standards-stg.ieee.org/project/2664.html.

As described by IEEE, STTP is “a protocol with built-in security and lossless data compression options for efficient transport of streaming power system data over Internet protocol (IP) communication systems. It specifies data and control channels and uses a publish-subscribe architecture for controlled signal-level data access.”

Specific documents published to support the creation of IEEE 2664 included:

• STTP Draft Specification, Published to GitHub on July 6, 2017.

• STTP Draft Specification, Published to GitHub on September 28, 2017.

A Comparison of Phasor Communications Protocol, published by the U.S. Department of Energy, Office of Scientific and Technical Information on March 29, 2019: https://www.osti.gov/biblio/1504742.

A challenge with the STTP standardization process will be the ability for GPA to support ongoing participation in IEEE meetings to make sure the standards process does not get stalled within IEEE.

PRESENTATIONS

• “Developing New High-Volume Time-Series Data Exchange Protocols for the Power Industry,” presented as part of an ISI Seminar Series at USC for IETF members on October 28, 2016

• “Overview – DOE Project 859 Advanced Synchrophasor Protocol,” presented to January 2017 IEEE Power Engineering Society.

• “Advanced Synchrophasor Protocol – DE-OE-859 Project Overview,” presented at NASPI Meeting March 22, 2017.

• “Project Overview – Advanced Synchrophasor Protocol – DE-OE-859,” presented to TVA on May 10, 2017.

• “A Deep Dive – Advanced Synchrophasor Protocol – DE– OE-859,” presented to the NERC Synchronized Measurement Subcommittee (SMS) Meeting May 16, 2017.

• “Project Overview – Advanced Synchrophasor Protocol – DE-OE-859,” presented to the Joint Synchronized Information Subcommittee (JSIS) Meeting, May 25, 2017.

• “Advanced Synchrophasor Protocol,” presented at DOE Transmission Reliability Program Peer Review Meeting, June 13, 2017.

• “Advanced Synchrophasor Protocol,” presented at DOE Project Kickoff Meeting, June 15, 2017.

• “Advanced Synchrophasor Protocol,” presented to NASPI Fall Meeting, Springfield, MA, September 26, 2017.


Page 38

• “Advanced Synchrophasor Protocol,” presented to the NERC SMS, September 27, 2017.

• Presentation to the Eastern Interconnect Data Sharing Network’s (EIDSN) October 2017 Data Systems Technology Working Group.

• Presentation to the Western Electricity Coordinating Council’s (WECC) Fall 2017 Joint Synchronized Information Subcommittee.

• Presentation to the IEEE Power Engineering Society on January 8, 2018, on the status of the specification.

• Presentation on ASP status at DOE Peer Review on June 6, 2018.

• Oral presentation on the STTP specification to the IEEE Synchrophasor Standards Working Group on September 11, 2018 in Minneapolis.

• Presentation on the ASP project to at the NASPI meeting on October 23, 2018.

• Discussion of ASP STTP development at the January 2019 IEEE PES meeting in Los Angeles.

• Presentation on STTP test results at NASPI meeting on April 15, 2019.

• SPP presentation on STTP vs C37.118 testing over the EISDN at the April 2019 WECC JSIS meeting.

• ASP overview and status update presented at the DOE/OE Transmission Reliability Program Peer Review in Washington, D.C., on June 12.

December 6, 2019


APPENDIX C – WSU TEST RESULTS

Yuan Zhi, Maddipour Farrokhifard, and Mani V. Venkatasubramanian

This appendix details the results of analysis based on data collected from the WSU tools installed at San Diego Gas & Electric (SDG&E) and Oklahoma Gas & Electric (OG&E) using the newly implemented STTP protocol.

Prior to the STTP protocol being developed and deployed, the WSU tools were initially configured at these utilities using IEEE C37.118 to validate that the tools were functioning normally. The installed WSU tools have since been modified, under the ASP project, to consume streaming synchrophasor data in STTP. These STTP data streams were created from instances of GPA tools at OG&E using openPDC and at SDG&E using SIEGate.

The results that follow verify the successful operability and functionality of the WSU tools when using the new STTP protocol. This qualitative assessment showed that no issues were found in the WSU tools as STTP was tested, thereby validating the protocol had been successfully implemented by both the data provider (the GPA tools) and the data consumer (the WSU tools).

SAN DIEGO GAS AND ELECTRIC RESULTS

The following sections detail the results from both the WSU Fast Frequency Domain Decomposition Engine and the Fast Stochastic Subspace Identification Engine based on from testing done at SDG&E using STTP as a data source.

Fast Frequency Domain Decomposition (FFDD) Engine Results

This section provides a brief analysis and visualization of the results from FFDD engine. The data we have includes days from July 09 to 11 and July 20 to September 2, 2019. A typical plot for modes detected in a day are shown in Figure C1 below, and the modes frequency and damping ratio in a typical day are shown in Figure C2.

The data shows there are several critical modes in the system in the frequency range 0.2Hz ~ 2.0Hz. The following sections go through each mode showing their estimation during a day along with the mode shape.

These plots showed that the data received in STTP protocol preserved all the essential system features of the oscillatory modes and the results are along expected lines. While no instances of low damping were found during the test period, that is consistent with the fact that there were no known instances of oscillatory problems faced by the utility during this period.


Page 40

Figure C1 - Mode Estimation in 24-Hour of a Typical Day

Figure C2 - Mode Frequency vs. Damping Ratio Plot in 24-hour in a Typical Day

December 6, 2019


0.235Hz Mode

The estimation of frequency, damping ratio, energy and confidence level of the mode is shown in figure C3 and C4, respectively. Figure C3 shows that the 0.235 Hz mode was mostly well-damped during this day while figure C4 shows the average mode shape for this mode.

Figure C 3 - Estimation of 0.235Hz mode on a typical day

Figure C 4 - Mode shape of 0.235Hz mode


Page 42

0.4Hz Mode

The estimation of frequency, damping ratio, energy and confidence level of the mode is shown in figure C5 and C6, respectively. These figures show that the 0.4 Hz mode was better damped than the 0.235 Hz mode in figure C3 and was less excited during the day.

Figure C 5 - Estimation of 0.40Hz mode

Figure C 6 - Mode shape of 0.40hz mode

December 6, 2019


0.6Hz Mode The estimation of frequency, damping ratio, energy and confidence level of the mode is shown in figure C7 and C8, respectively. The 0.6 Hz mode appears to have lower damping than the 0.235 Hz mode in figure C7 and was observed throughout the day.




Page 44

1.0Hz Mode

The estimation of frequency, damping ratio, energy and confidence level of the mode is shown in figure C9 and C10, respectively. The 1.0 Hz mode or oscillation has low damping though the estimation occurred only for short time periods in the day. The presence of low damping estimates at 1.0 Hz has been reported to the utility which is looking into the potential causes of the issue.

Figure C 9 - Estimation of 1.00hz mode

Figure C 10 - Mode shape 1.00Hz mode

December 6, 2019


1.1Hz Mode

The estimation of frequency, damping ratio, energy and confidence level of the mode is shown in figure C11 and C12, respectively. The 1.1 Hz mode is seen in Figure C11 to show low damping for sustained time periods and has been reported to the utility.




Page 46

1.6Hz Mode

The estimation of frequency, damping ratio, energy and confidence level of the mode is shown in figure C14 and C15, respectively. The 1.6 Hz mode also has low damping and may be a local mode of some synchronous generator in the system. This has been reported to the utility.



December 6, 2019


2.0Hz Mode

The estimation of frequency, damping ratio, energy and confidence level of the mode is shown in figure C15 and C16, respectively. The 2.0 Hz mode may also be a local mode with low damping levels that has been reported to the utility.




Page 48

Fast Stochastic Subspace Identification (FSSI) Engine Results

In this section, a brief analysis and visualization is provided on the results from FSSI engine for SDG&E data. FSSI is an alternate engine to FFDD for oscillatory modal analysis from PMU data. The data includes the days from July 9 to August 16 and August 21 to September 3, 2019. A typical plot for modes detected in a day is shown in figure C17, and the modes frequency and damping ratio in a typical day is shown in figure C18.

The data shows there are several critical modes in the system in the frequency range 0.2Hz ~ 2.0Hz. The following sections go through each mode showing their estimation during a day along with the mode shape. Note that the critical modes and damping properties identified by FSSI match the results of FFDD well.

Figure C 17 - Mode frequency in a typical data from FSSI engine

Figure C 18 - Mode frequency and damping ratio in a typical day from FSSI engine

December 6, 2019


0.235Hz Mode

Figures C19 and C20 show that the 0.23 Hz mode was observed throughout the test day and the damping varied from being mostly well-damped to instances of low damping. The low damping periods match with FFDD results and the utility is looking into reasons.

Figure C 19 - Estimation of 0.23hz mode



Page 50

0.4Hz Mode

The 0.4 Hz mode was well-damped according to FSSI in figures C21 and C22.



December 6, 2019


0.6Hz Mode

The 0.6 Hz mode, as shown in figures C23 and C24, had some periods of low damping as was seen in FFDD results. The causes are currently unknown.

Figure C 23 - Mode estimation of 0.60Hz mode

Figure C 24 - Mode estimation of 0.60Hz mode


Page 52

1.0Hz Mode

The 1.0 Hz mode had periods of low damping as seen in Figures C25 and C26. This has been reported to the utility.



December 6, 2019


1.1Hz Mode

The 1.1 Hz mode, as shown in Figures C27 and C28, had extended periods of low damping in FSSI results and has been reported to the utility.


Figure C 28 - Mode shape of 1.10hz mode


Page 54

Event and Transient Engine Results

The event engine was running at SDG&E during this testing but unfortunately no events were detected in the log file during the test period. The transient engine was running as well, but the log information was not sufficient to provide a detailed analysis and summary.

OKLAHOMA GAS AND ELECTRIC RESULTS

The following sections detail the results from both the WSU Fast Frequency Domain Decomposition Engine and the Transient Engine based on from testing done at OG&E using STTP as a data source.

Fast Frequency Domain Decomposition (FFDD) Engine Results

This section provides a brief analysis and visualization of the results from FFDD engine. The data includes days from August 27 to September 2, 2019. A typical plot for modes detected in a day are shown in Figure C29 below, and the modes frequency and damping ratio in a typical day are shown in Figure C30.

The data shows there are several critical modes in the system in the frequency range 0.2Hz ~ 1.0Hz. The following sections go through each mode showing their estimation during a day along with the mode shape.

These plots showed that the data received in STTP protocol preserved all the essential system features of the oscillatory modes and the results are along expected lines.

December 6, 2019


Figure C 29 - Mode frequencies in a typical day

Figure C 30 - Mode frequency vs. damping ratio in a typical day


Page 56

0.3Hz Mode

The estimation of frequency, damping ratio, energy and confidence level of the mode is shown in Figures C31 and C32, respectively. The 0.3 Hz mode was very well-damped throughout the test day according to FFDD.



December 6, 2019


0.4Hz Mode

The estimation of frequency, damping ratio, energy and confidence level of the mode is shown in Figures C33 and C34, respectively. The figures show that the 0.4 Hz mode was also well-damped during the test period.




Page 58

0.7Hz Mode

The estimation of frequency, damping ratio, energy and confidence level of the mode is shown in Figures C35 and C36, respectively. The 0.7 Hz mode shown, was well-damped during the test day according to the FFDD results.



December 6, 2019


1.0Hz Mode

The estimation of frequency, damping ratio, energy and confidence level of the mode is shown in Figures C37 and C38, respectively. The 1.0 Hz mode shown had lower damping compared to the other modes. However, the damping levels were still reasonable for what was likely a local mode at a generator.




Page 60

FFDD Number of Signals Plot

Figure C39 shows the number of signals processed by FFDD engine from August 27 to September 2, 2019. The mean value number of signals is 39.54 out of the maximum 40 signals that were selected for analysis. This validates that STTP was effective in bringing in the desired signals for FDDD engine processing throughout the test period.

Figure C 39 - Number of signals processed by the FFDD engine

Transient Engine Results

In this section, the results from the WSU Transient Engine for OG&E data are shown. The number of channels processed by the Transient Engine is shown in Figure C40. The number of generator groups used by the transient tool for calculation of deltas is shown in Figure C41, followed a graph of the deltas in C42. A graph of the AAEs of generated groups is not shown since all values were zero.

As with the FFDD Number of Signals Plot, Figure C40 showing the number of channels processed validate that STTP is effective in delivery of needed signals.

Figure C 40 - Number of channels processed by the transient engine

0

10

20

30

40

50

2019

0827

…20

1908

27…

2019

0827

…20

1908

28…

2019

0828

…20

1908

28…

2019

0828

…20

1908

29…

2019

0829

…20

1908

29…

2019

0829

…20

1908

29…

2019

0830

…20

1908

30…

2019

0830

…20

1908

30…

2019

0831

…20

1908

31…

2019

0831

…20

1908

31…

2019

0901

…20

1909

01…

2019

0901

…20

1909

01…

2019

0902

…20

1909

02…

2019

0902

…20

1909

02…

Number of Signals Mean:

0

50

100

150

200

2019

0827

…20

1908

27…

2019

0827

…20

1908

28…

2019

0828

…20

1908

28…

2019

0828

…20

1908

28…

2019

0829

…20

1908

29…

2019

0829

…20

1908

29…

2019

0830

…20

1908

30…

2019

0830

…20

1908

30…

2019

0831

…20

1908

31…

2019

0831

…20

1908

31…

2019

0831

…20

1909

01…

2019

0901

…20

1909

01…

2019

0901

…20

1909

02…

2019

0902

…20

1909

02…

2019

0902

…

Number of Channels M 180 58

December 6, 2019


Figures C41 and C42 show that all the observed signals stayed in synchronism and no islanding was detected during the test period which indeed matched the actual system behavior.

Figure C 41 - Number of Generator Groups

Figure C 42 - Deltas of each Generator Group


Page 62

APPENDIX D – EPG TEST RESULTS

EPG worked closely with GPA to integrate STTP protocol with commercial EPG applications. The EPG applications enhanced to use STTP protocol are ePDC and RTDMS Server:

1. ePDC (enhanced Phasor Data Concentrator) – Both the input and output data adapters for ePDC were enhanced to receive data in STTP format. The input data adapter can receive data in both IEEE C37.118 and STTP from other PDCs including openPDC. The output data adapter can send data in both IEEE C37.118 and STTP to other PDCs and EPG’s RTDMS Server application.

2. RTDMS Server – RTDMS Server application is at the heart of the EPG’s RTDMS platform. It receives data from PDC and sends it to database after processing it. The input data adapter for RTDMS Server application was enhanced to receive data from Phasor Data Concentrators including ePDC and openPDC in STTP format.

STTP INTEGRATION SCREENSHOTS Below are some screen captures, Figures D1 to D4, showing the STTP input and output integration within ePDC for both configuration and operational functions.

Figure D 1 – ePDC Input Configuration Using STTP

December 6, 2019


Figure D 2 – ePDC Input Data Using STTP

Figure D 3 – ePDC Output Configuration Using STTP

Figure D 4 – ePDC Output Data Using STTP


Page 64

TESTING ACTIVITIES

Electric Power Group (EPG) partnered with GPA to demonstrate and test the use STTP protocol at the Utilities site of Dominion Energy and PJM Interconnection through integration with EPG products. The testing and demonstration covered evaluation of areas including functionality, performance, latency, network efficiency and reliability of EPG products after implementing STTP functionality in EPG’s commercial synchrophasor products such as ePDC and RTDMS Server.

Factory Acceptance Test (FAT) Setup

To verify the functionalities and performance of STTP before the Demo, EPG performed a Factory Acceptance Test after integrating the protocol into EPG Synchrophasor applications (ePDC and RTDMS Server). The PMUs were simulated using EPG’s Error Injection and Data Simulation Utility. This utility is able to simulate PMU data at user defined data rate, streaming in IEEE C37.118 format. The utility also allows injection of error data for testing the reliability and resilience of STTP to data dropouts and other PMU data errors. The following diagrams, figures D5 and D6, describe the test setup for STTP Factory Acceptance Testing at EPG.

Figure D 5 – FAT Setup for Testing ePDC and RTDMS

Figure D 6 – FAT Setup for Testing RTDMS Server

December 6, 2019


DEMONSTRATION ACTIVITIES

Demonstation of EPG’s STTP implementation was originally planned between Dominion and PJM. Scheduling and resource constraints at the utility partners led to an additional demo plan involving EPG, GPA and TVA using several VPN connections to allow completion of demonstration activities.

Original Demo Plan

The original STTP demo plan was to perform STTP demonstration and field test in collaboration with Dominion and PJM. The objective was to demo and test the transfer of large data streams (for example, 500 PMUs and more) over external and internal networks. Figure D7 shows the planned demo setup which included the following tests:

1) External Testing (WAN) Demo

For external testing, openPDC at Dominion would send data to PJM ePDC using STTP. This transfer would be done through PhasorNET WAN.

2) Internal Testing (LAN) Demo

For internal testing, PJM’s ePDC would use STTP to send Dominion and other entities’ PMU data to EPG Real-time Dynamic Monitoring System (RTDMS) application installed in PJM. Also, Dominion’s openPDC would send its PMU data to RTDMS through STTP.

Figure D 7 – Original Demonstration Setup

PhasorNET

openPDCSTTP Interface

Dominion

PJM

RTDMSSTTP Interface

ePDCSTTP Interface

RTDMSSTTP Interface


Page 66

EPG Activities for Original Demo

For conducting the demo, EPG integrated ASP/STTP API into its ePDC and RTDMS applications. These applications first were factory tested and then provided the enhanced applications to Dominion and PJM for installation and demo.

EPG followed up with PJM and Dominion for allocating time and resources for demo setup. Due to scheduling and resource constraints at the utility partners, the demo plan could not be completed as planned. This led to setup of alternate demo plan involving GPA and TVA.

Final Demo with GPA and EPG using TVA data

The final demo was performed using live PMU data streamed from TVA to openPDC at GPA in Chattanooga, TN. This data stream was then forwarded using STTP to ePDC in EPG in Pasadena, CA. At EPG, the data was sent to RTDMS Server using STTP which then stored the data in an RTDMS Database. Finally, the live data stream was visualized using RTDMS Client application.

Following are screenshots, Figures D8 and D9, from RTDMS Client displaying live data from TVA:

Figure D 8 – Frequency Data

December 6, 2019


Figure D 9 – Voltage Data

Resource Monitoring for Final Demo

Following are screenshots, Figures D10 to D12, showing bandwidth, CPU and memory usage of ePDC and RTDMS Server followed by a final operation screen shot of the full data stream in operation:


Page 68

Figure D 10 – ePDC Resource Utilization

Figure D 11 – RTDMS Service Resource Utilization

December 6, 2019


Figure D 12 – ePDC with 283 PMUs Streamed from TVA through GPA openPDC


Page 70

APPENDIX E – STTP METADATA

Metadata in STTP is XML data that is represented in a tabular format much like that of data that can be found in a spreadsheet or table of data in a database, see Example Metadata XML below.

Additionally, STTP allows for the transport of multiple tables of data in a single dataset, such as, a table of devices and measurements. This flexibility allows for the transport of any number of tables of metadata that may be required to describe measurements in enough detail to accommodate a given use case. Regardless, a minimum set of metadata is required for STTP to function, specifically all measurements need a unique GUID-based identifier along with its data type, an alphanumeric tag name, description, and last update timestamp.

MEASUREMENT DETAIL TABLE

At a minimum, STTP will require a table of measurements in order to function. Of the fields in this table, only four fields are required, that is: SignalID, PointTag, Description and UpdatedOn. All other fields are optional from the perspective of STTP but may be required for an industry specific use case.

Field Type Description Required

SignalID Guid Unique UUID of this individual measurement Yes

PointTag String Well formatted tag name for historians Yes

Description String Detailed measurement description (free form) Yes

ID String Measurement key string, format: "source:index" No

SignalReference String Frame-based protocol mapping field (type / index) No

PhasorSourceIndex Integer Phasor ordered index, uses 1-based indexing No

DeviceAcronym String Name of associated parent device (if any) No

UpdatedOn DateTime Time of last metadata update Yes

Table E 1 - STTP Measurement Detail Metadata

December 6, 2019


DEVICE DETAIL TABLE

The device table as shown below defines the devices, such as PMUs, that are the sources of measurements. This table is useful for mapping STTP to and from IEEE C37.118.

Field Type Description

Acronym String Alphanumeric device, e.g., PMU/station name (all-caps)

Name String User-defined device name / description (free-form)

UniqueID Guid Device unique UUID (used for IEEE C37.118 CFG-3 frame)

AccessID Integer ID code used for device connection / reference

ParentAcronym String Original PDC name (none for direct connected devices)

ProtocolName String Original protocol name

FramesPerSecond Integer Device reporting rate, e.g., 30 fps

CompanyAcronym String Original device company name

VendorAcronym String Original device vendor name (if provided)

VendorDeviceAcronym String Original vendor device name, e.g., PMU brand

Longitude Float Device longitude (if reported)

Latitude Float Device latitude (if reported)

UpdatedOn DateTime Time of last metadata update

Table E 2 - STTP Device Detail Metadata


Page 72

PHASOR DETAIL TABLE

The phasor table defines phasors, as described in IEEE C37.118, that are associated with devices. This table is required to construct a frame of data in IEEE C37.118 format using input measurements received from STTP.

Field Type Description

DeviceAcronym String Name of associated parent device (required)

Label String Phasor label (16-characters) for CHNAM

Type String Current (I) or Voltage (V)

Phase String Phase, e.g., A, B, C, +, -, 0

SourceIndex Integer Phasor ordered index, uses 1-based indexing

UpdatedOn DateTime Time of last metadata update

Table E 3 - STTP Phasor Detail Metadata

EXAMPLE METADATA XML

<?xml version="1.0" standalone="yes"?> <Metadata> <xs:schema id="Metadata" xmlns="" xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="Metadata"> <xs:complexType> <xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:element name="DeviceDetail"> <xs:complexType> <xs:sequence> <xs:element name="NodeID" type="xs:string" minOccurs="0" /> <xs:element name="UniqueID" type="xs:string" minOccurs="0" /> <xs:element name="OriginalSource" type="xs:string" minOccurs="0" /> <xs:element name="IsConcentrator" type="xs:boolean" minOccurs="0" /> <xs:element name="Acronym" type="xs:string" minOccurs="0" /> <xs:element name="Name" type="xs:string" minOccurs="0" /> <xs:element name="AccessID" type="xs:long" minOccurs="0" /> <xs:element name="ParentAcronym" type="xs:string" minOccurs="0" /> <xs:element name="ProtocolName" type="xs:string" minOccurs="0" /> <xs:element name="FramesPerSecond" type="xs:long" minOccurs="0" /> <xs:element name="CompanyAcronym" type="xs:string" minOccurs="0" /> <xs:element name="VendorAcronym" type="xs:string" minOccurs="0" /> <xs:element name="VendorDeviceName" type="xs:string" minOccurs="0" /> <xs:element name="Longitude" type="xs:decimal" minOccurs="0" /> <xs:element name="Latitude" type="xs:decimal" minOccurs="0" /> <xs:element name="InterconnectionName" type="xs:string" minOccurs="0" /> <xs:element name="ContactList" type="xs:string" minOccurs="0" /> <xs:element name="Enabled" type="xs:boolean" minOccurs="0" /> <xs:element name="UpdatedOn" type="xs:dateTime" minOccurs="0" />

December 6, 2019


</xs:sequence> </xs:complexType> </xs:element> <xs:element name="MeasurementDetail"> <xs:complexType> <xs:sequence> <xs:element name="DeviceAcronym" type="xs:string" minOccurs="0" /> <xs:element name="ID" type="xs:string" minOccurs="0" /> <xs:element name="SignalID" type="xs:string" minOccurs="0" /> <xs:element name="PointTag" type="xs:string" minOccurs="0" /> <xs:element name="SignalReference" type="xs:string" minOccurs="0" /> <xs:element name="SignalAcronym" type="xs:string" minOccurs="0" /> <xs:element name="PhasorSourceIndex" type="xs:long" minOccurs="0" /> <xs:element name="Description" type="xs:string" minOccurs="0" /> <xs:element name="Internal" type="xs:boolean" minOccurs="0" /> <xs:element name="Enabled" type="xs:boolean" minOccurs="0" /> <xs:element name="UpdatedOn" type="xs:dateTime" minOccurs="0" /> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="PhasorDetail"> <xs:complexType> <xs:sequence> <xs:element name="ID" type="xs:long" minOccurs="0" /> <xs:element name="DeviceAcronym" type="xs:string" minOccurs="0" /> <xs:element name="Label" type="xs:string" minOccurs="0" /> <xs:element name="Type" type="xs:string" minOccurs="0" /> <xs:element name="Phase" type="xs:string" minOccurs="0" /> <xs:element name="DestinationPhasorID" type="xs:long" minOccurs="0" /> <xs:element name="SourceIndex" type="xs:long" minOccurs="0" /> <xs:element name="UpdatedOn" type="xs:dateTime" minOccurs="0" /> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="SchemaVersion"> <xs:complexType> <xs:sequence> <xs:element name="VersionNumber" type="xs:long" minOccurs="0" /> </xs:sequence> </xs:complexType> </xs:element> </xs:choice> </xs:complexType> </xs:element> </xs:schema> <DeviceDetail> <NodeID>8736f6c7-ad41-4b43-b4f6-e684e0d4ad20</NodeID> <UniqueID>c8283c22-8aed-4a0d-bf9d-76111932afd9</UniqueID> <IsConcentrator>false</IsConcentrator> <Acronym>TESTDEVICE</Acronym> <Name>Test Device</Name>


Page 74

<AccessID>2</AccessID> <ParentAcronym /> <ProtocolName>IEEE 1344-1995</ProtocolName> <FramesPerSecond>30</FramesPerSecond> <CompanyAcronym>TVA</CompanyAcronym> <VendorAcronym>ABB</VendorAcronym> <VendorDeviceName>ABB-521</VendorDeviceName> <Longitude>-89.8038</Longitude> <Latitude>35.3871</Latitude> <InterconnectionName>Eastern Interconnection</InterconnectionName> <ContactList /> <Enabled>true</Enabled> <UpdatedOn>2018-03-14T19:23:10.321-04:00</UpdatedOn> </DeviceDetail> <MeasurementDetail> <DeviceAcronym>TESTDEVICE</DeviceAcronym> <ID>PPA:1</ID> <SignalID>29b80c23-b76e-4f3d-a0bd-855b0f8ef08d</SignalID> <PointTag>TVA_TESTDEVICE:ABBS</PointTag> <SignalReference>TESTDEVICE-SF</SignalReference> <SignalAcronym>FLAG</SignalAcronym> <Description>Test Device ABB-521 Status Flags</Description> <Internal>true</Internal> <Enabled>true</Enabled> <UpdatedOn>2018-03-14T19:23:11.477-04:00</UpdatedOn> </MeasurementDetail> <MeasurementDetail> <DeviceAcronym>TESTDEVICE</DeviceAcronym> <ID>PPA:2</ID> <SignalID>285dfa57-7b51-47b5-919b-b1dc7140d01a</SignalID> <PointTag>TVA_TESTDEVICE:ABBF</PointTag> <SignalReference>TESTDEVICE-FQ</SignalReference> <SignalAcronym>FREQ</SignalAcronym> <Description>Test Device ABB-521 Frequency</Description> <Internal>true</Internal> <Enabled>true</Enabled> <UpdatedOn>2018-03-14T19:23:11.665-04:00</UpdatedOn> </MeasurementDetail> <MeasurementDetail> <DeviceAcronym>TESTDEVICE</DeviceAcronym> <ID>PPA:5</ID> <SignalID>977747f8-056f-4fc6-88b2-f0cfb51ec139</SignalID> <PointTag>TVA_TESTDEVICE-BUS1:ABBV</PointTag> <SignalReference>TESTDEVICE-PM1</SignalReference> <SignalAcronym>VPHM</SignalAcronym> <PhasorSourceIndex>1</PhasorSourceIndex> <Description>Test Device Bus 1 Positive Sequence Voltage Magnitude</Description> <Internal>true</Internal> <Enabled>true</Enabled> <UpdatedOn>2018-03-14T19:23:12.227-04:00</UpdatedOn> </MeasurementDetail>

December 6, 2019


<MeasurementDetail> <DeviceAcronym>TESTDEVICE</DeviceAcronym> <ID>PPA:6</ID> <SignalID>952ed494-377f-4be3-9151-86c78ead9231</SignalID> <PointTag>TVA_TESTDEVICE-BUS1:ABBVH</PointTag> <SignalReference>TESTDEVICE-PA1</SignalReference> <SignalAcronym>VPHA</SignalAcronym> <PhasorSourceIndex>1</PhasorSourceIndex> <Description>Test Device Bus 1 Positive Sequence Voltage Phase Angle</Description> <Internal>true</Internal> <Enabled>true</Enabled> <UpdatedOn>2018-03-14T19:23:12.415-04:00</UpdatedOn> </MeasurementDetail> <MeasurementDetail> <DeviceAcronym>TESTDEVICE</DeviceAcronym> <ID>PPA:4</ID> <SignalID>98c93a54-9435-48cf-987d-e897b793441a</SignalID> <PointTag>TVA_TESTDEVICE:ABBDF</PointTag> <SignalReference>TESTDEVICE-DF</SignalReference> <SignalAcronym>DFDT</SignalAcronym> <Description>Test Device ABB-521 Frequency Delta (dF/dt)</Description> <Internal>true</Internal> <Enabled>true</Enabled> <UpdatedOn>2018-03-14T19:23:12.04-04:00</UpdatedOn> </MeasurementDetail> <MeasurementDetail> <DeviceAcronym>TESTDEVICE</DeviceAcronym> <ID>STAT:35</ID> <SignalID>13f86d22-bf54-4ceb-b345-6a423118a1bc</SignalID> <PointTag>TVA_TESTDEVICE!IS:ST1</PointTag> <SignalReference>TESTDEVICE!IS-ST1</SignalReference> <SignalAcronym>STAT</SignalAcronym> <Description>Total frames received during last reporting interval.</Description> <Internal>true</Internal> <Enabled>true</Enabled> <UpdatedOn>2018-03-20T22:12:26.933-04:00</UpdatedOn> </MeasurementDetail> <PhasorDetail> <ID>12</ID> <DeviceAcronym>TESTDEVICE</DeviceAcronym> <Label>500 kV Bus 1</Label> <Type>V</Type> <Phase>+</Phase> <SourceIndex>1</SourceIndex> <UpdatedOn>2018-03-14T19:23:10.509-04:00</UpdatedOn> </PhasorDetail> <SchemaVersion> <VersionNumber>8</VersionNumber> </SchemaVersion> </Metadata>


Page 76

APPENDIX F – STTP FILTER EXPRESSIONS

Filter expressions in STTP are used to select desired signals for subscription or to reduce available metadata down to a desired subset. Filtering syntax is similar to Structured Query Language (SQL), but does not implement the full SQL language.

Filter expressions operate against an in-memory data set, not a backend database. The filtering syntax used in conjunction with a data set is designed for read-only operations and exposes no update functionality. Because of this, filter operations are not subject to SQL injection attacks or other security concerns typically associated with SQL implementations.

STTP data publishers need to define a data set consisting of a collection of data tables representing the primary metadata from locally defined configurations that contain information about the time-series style data to be published. At a minimum this metadata should define a GUID-based identifier for each measurement to be published as well as an associated source, i.e., a device, that produces the measurement.

FILTERING SYNTAX

FILTER <TableName> [TOP n] WHERE <Expression> [ORDER BY <SortField> [ASC|DESC]]

AVAILABLE OPTIONS AND CLAUSES

Keyword Example Description Required?

FILTER See examples below Keyword that signifies a filter expression follows* Yes

TOP n TOP 100 Selects only the first n number of items No

WHERE <Expression> WHERE SignalType=’FREQ’

Criteria-based expression, in SQL syntax, used to filter rows Yes

ORDER BY <ColumnName> ORDER BY SignalType Expression specifying column names and

sort directions No

* The keyword FILTER is used instead of the standard SQL SELECT keyword to reinforce the notion that the expression that follows is special purposed and not standard SQL.

December 6, 2019


DIRECT SIGNAL IDENTIFICATION

Filtering syntax also supports the direct specification of desired signals as semi-colon separated measurement references in a variety of forms, e.g., measurement key identifiers: PPA:4; PPA:2 - formatted as {instance}:{id}, unique Guid-based signal identifiers: 538A47B0-F10B-4143-9A0A-0DBC4FFEF1E8; ‘06d039f6-e5e9-4e37-85fc-52a125c67a06’; {E4BBFE6A-35BD-4E5B-92C9-11FF913E7877} optionally surrounded by single quotes or braces, or point tag name identifiers: “GPA_TESTDEVICE:FREQ”; “GPA_TESTDEVICE:FLAG” where each point tag name is in double quotes.

Examples

Example filter expression to select measurements with the company of GPA and type of Frequency (FREQ) or Voltage Magnitude (VPHM):

FILTER ActiveMeasurements WHERE Company='GPA' AND SignalType IN ('FREQ', 'VPHM') ORDER BY Device DESC

Example filter expression to select first 20 measurements of type Statistic (STAT):

FILTER TOP 20 ActiveMeasurements WHERE SignalType = 'STAT'

Example filter to only select Current Angle (IPHA) and Voltage Angle (VPHA) for Positive Sequence (+) measurements.

FILTER ActiveMeasurements WHERE SignalType LILE '%PHA' AND Phase='+' ORDER BY PhasorID

Example filter combining both filter expressions and directly specified tags:

PPA:15; STAT:20; PPA:8; {eecbda2f-fe76-4504-b031-7f5518c7046c}; FILTER ActiveMeasurements WHERE SignalType IN ('IPHA', 'VPHA'); 9d0423c0-2349-4a38-85d5-b6e81735eb48; FILTER TOP 3 ActiveMeasurements WHERE SignalType = 'FREQ' ORDER BY Device; "GPA_TESTDEVICE:FREQ"

FILTER EXPRESSION OPERATORS

Any operators that consist of letters, e.g., OR, are not case sensitive, so OR, or and Or are all equivalent.

Unary Operators

Type Symbol

Negative -

Positive +

Not NOT or ! or ~


Page 78

Comparison Operators

Type Symbol

Less Than <

Less Than or Equal <=

Greater Than >

Greater Than or Equal >=

Equal = or == or ===

Not Equal != or <> or !==

Logical Operators

Type Symbol

And AND or &&

Or OR or ||

Bitwise Operators

Type Symbol

Bit Shift Left <<

Bit Shift Right >>

Bitwise And &

Bitwise Or |

Exclusive Or XOR or ^

December 6, 2019


Math Operators

Type Symbol

Multiply *

Divide /

Add +

Subtract -

Modulus %

CASE SENSITIVE STRING COMPARISONS

Unless otherwise specified, comparison of string values in filter expressions is not case sensitive. To specify a case sensitive comparison, use one of the following expression options:

Case Sensitive LIKE Expression

FILTER <TableName> WHERE <ColumnName> [NOT] LIKE [===|BINARY] 'expression'

Example:

FILTER ActiveMeasurements WHERE Device LIKE BINARY 'SHELBY%'

Case Sensitive IN Expression

FILTER <TableName> WHERE expression [NOT] <ColumnName> IN [===|BINARY] (expression1, ..., expression_n )

Example:

FILTER ActiveMeasurements WHERE NOT SignalType IN ===('IPHM', 'VPHM')

Case Sensitive ORDER BY Expression

FILTER <TableName> WHERE expression ORDER BY [===|BINARY] <ColumnName> [ASC|DESC]

Example:

FILTER TOP 5 ActiveMeasurements ORDER BY Device, === PointTag DESC


Page 80

Case Sensitive Comparison Operators

When expressions are strings, or evaluated as strings, the following operators perform a case sensitive compare:

expression1 === expression2 // Case sensitive equals comparison

expression1 !== expression2 // Case sensitive not equals comparison

Example:

FILTER ActiveMeasurements WHERE Device === 'SHELBY'

FILTER EXPRESSION FUNCTIONS

Function names are not case sensitive, so ABS, abs and Abs are all equivalent.

Function Arguments Description

ABS expression Returns the absolute value of the specified numeric expression.

CEILING expression Returns the smallest integer that is greater than, or equal to, the specified numeric expression.

COALESCE expression1,

..., expression_n

Returns the first non-null value in expression list.

CONVERT expression, type

Converts expression to the specified type. type is one of boolean (or bool), int32, uint, int64 (or int), decimal, single (or float), double, string, guid, or datetime. type is not case sensitive.

CONTAINS source, test, [ignoreCase]

Returns flag that determines if source string contains test string. ignoreCase is a optional boolean flag, defaults to false, to determine if string comparison is case sensitive.

DATEADD source, value, interval

Adds value at specified interval to source date and then returns the date. interval is one of Year, Month, DayOfYear, Day, Week, WeekDay, Hour, Minute, Second, or Millisecond. interval is not case sensitive.

December 6, 2019



DATEDIFF left, right, interval

Returns the difference between left and right value at specified interval. interval is one of Year, Month, DayOfYear, Day, Week, WeekDay, Hour, Minute, Second, or Millisecond. interval is not case sensitive.

DATEPART source, interval

Returns specified interval of source. interval is one of Year, Month, DayOfYear, Day, Week, WeekDay, Hour, Minute, Second, or Millisecond. interval is not case sensitive.

ENDSWITHS source, test, [ignoreCase]

Returns flag that determines if source string ends with test string. ignoreCase is a optional boolean flag, defaults to false, to determine if string comparison is case sensitive.

FLOOR expression Returns the largest integer value that is smaller than, or equal to, the specified numeric expression.

IIF expression, leftValue, rightValue

Returns leftValue if result of expression is true, else returns rightValue.

INDEXOF source, test, [ignoreCase]

Returns zero-based index of first occurrence of test in source, or -1 if not found. ignoreCase is a optional boolean flag, defaults to false, to determine if string comparison is case sensitive.

ISDATE expression Returns flag that determines if expression is a dateTime or can be parsed as one.

ISINTEGER expression Returns flag that determines if expression is an integer value or can be parsed as one.

ISGUID expression Returns flag that determines if expression is a Guid value or can be parsed as one.


Page 82


ISNULL expression Returns flag that determines if expression is null.

ISNUMERIC expression Returns flag that determines if expression is a numeric value or can be parsed as one.

LASTINDEXOF source, test, [ignoreCase]

Returns zero-based index of last occurrence of test in source, or -1 if not found. ignoreCase is a optional boolean flag, defaults to false, to determine if string comparison is case sensitive.

LEN expression Returns length of expression interpreted as a string.

LOWER expression Returns lower-case representation of expression interpreted as a string.

MAXOF expression1,

..., expression_n

Returns value in expression list with maximum value.

MINOF expression1,

..., expression_n

Returns value in expression list with minimum value.

NOW Returns a dateTime value representing the current local system time.

NTHINDEXOF source, test,

index, [ignoreCase]

Returns zero-based index of the Nth, represented by index value, occurrence of test in source, or -1 if not found. ignoreCase is a optional boolean flag, defaults to false, to determine if string comparison is case sensitive.

December 6, 2019



POWER expression, exponent

Returns the value of specified numeric expression raised to the power of specified numeric exponent.

REGEXMATCH regex, test Returns flag that determines if test, interpreted as a string, is a match for specified regex string-based regular expression.

REGEXVAL regex, test Returns value from test, interpreted as a string, that is matched by specified regex string-based regular expression.

REPLACE source, test,

replace, [ignoreCase]

Returns a string where all instances of test found in source are replaced with replace value - all parameters interpreted as strings. ignoreCase is a optional boolean flag, defaults to false, to determine if string comparison is case sensitive.

REVERSE expression Returns string where all characters in expression interpreted as a string are reversed.

ROUND expression Returns the nearest integer value to the specified numeric expression

SPLIT

source, delimiter,

index, [ignoreCase]

Returns zero-based Nth, represented by index, value in source split by delimiter, or null if out of range. ignoreCase is a optional boolean flag, defaults to false, to determine if string comparison is case sensitive.

SQRT expression Returns the square root of the specified numeric expression

STARTSWITH source, test, [ignoreCase]

Returns flag that determines if source string starts with test string. ignoreCase is a optional boolean flag, defaults to false, to determine if string comparison is case sensitive.


Page 84


STRCOUNT source, test, [ignoreCase]

Returns count of occurrences of test in source. ignoreCase is a optional boolean flag, defaults to false, to determine if string comparison is case sensitive.

STRCMP left, right, [ignoreCase]

Returns -1 if left is less-than right, 1 if left is greater-than right, or 0 if left equals right. ignoreCase is a optional boolean flag, defaults to false, to determine if string comparison is case sensitive.

SUBSTR source, index, [length]

Returns portion of source interpreted as a string starting at index. If length is specified, this will be the maximum number of characters returned; otherwise, remaining characters in string will be returned.

TRIM expression Removes white-space from the beginning and end of expression interpreted as a string.

TRIMLEFT expression Removes white-space from the beginning of expression interpreted as a string.

TRIMRIGHT expression Removes white-space from the end of expression interpreted as a string.

UPPER expression Returns upper-case representation of expression interpreted as a string.

UTCNOW Returns a dateTime value representing the current UTC system time.

SIGNAL SELECTION METADATA TABLE DEFINITIONS

Data publishers can define multiple tables that represent sets of measurements available for filtering desired signals, e.g., AllMeasurements or LocalMeasurements. At a minimum a signal selection table must define a SignalD field of type Guid - all other fields are considered optional.

December 6, 2019


However, without a point tag name or description the measurement may be of little use unless other metadata is exchanged out-of-band with STTP.

Signal selection tables should represent a simple flattened “view” of available metadata with as many fields as needed to be useful for measurement selection operations. See usage of ActiveMeasurements in examples.

ActiveMeasurements

The ActiveMeasurements table is always expected to be defined. This table represents all measurements considered active and available for subscription. If a data publisher is controlling access to measurements on a per-subscriber basis, this table should only include the measurements the subscriber is allowed to request for subscription.

Typically the data in the ActiveMeasurements table is derived from the conflation of information already defined in other available metadata condensed to a single table to make filter expressions more productive.

Common fields for the ActiveMeasurements table are defined below. Note that some of the fields are specific to the electric power industry and may not be applicable for other industry implementations and consequently unavailable.

Column Name Data Type Description

ID string A measurement key identifier formatted as {instance}:{id}

SignalID Guid Unique identifier for the measured value

PointTag string Unique alphanumeric identifier for the measured value

AlternateTag string Secondary alphanumeric identifier for the measured value

SignalReference string Alphanumeric reference to original signal source, e.g., location in source protocol

Device string Alphanumeric device acronym that is the source of the measurement

FramesPerSecond int Expected data rate, in received samples per second, of measurement

Protocol string Source protocol that generated measurement

SignalType string Signal type acronym of measurement


Page 86


EngineeringUnits string Engineering units of measurement

PhasorID int ID of associated phasor metadata record

PhasorType string When measurement is a phasor, type of phasor: voltage (V) or current (I)

Phase string When measurement is a phasor, phase e.g.: (A), (B), (C), (+), (-), etc.

Adder double Recommended additive linear adjustment of value to be applied

Multiplier double Recommended multiplicative linear adjustment of value to be applied

Company string Acronym of company that is publishing the measurement

Longitude decimal Longitude of device location publishing the measurement

Latitude decimal Latitude of the device location publishing the measurement

Description string Description of the measurement

UpdatedOn dateTime Timestamp of last update of measurement metadata

PRIMARY METADATA TABLE DEFINITIONS

STTP metadata is designed around the notion of a data set. Metadata represented by a data set allows for rich and extensible information description.

Outside the expected ActiveMeasurements signal selection metadata table definition, no other metadata tables are required to be defined. However, to make data exchange useful for industry specific STTP implementations, a common set of metadata should be defined.

The STTP data publisher API currently defines three primary data tables to define enough useful metadata to allow a measurement data subscription to be converted into another protocol, e.g., IEEE C37.118. When these tables are defined, the data publisher API will auto-generate the ActiveMeasurements table from the provided data.

December 6, 2019


DeviceDetail

This metadata table contains details about the devices that are the sources of available measurements. By convention, measurements that are not associated with a device are not sent in metadata exchanges.


UniqueID Guid Unique identifier for the device

OriginalSource string If device was proxied through another protocol, original source

IsConcentrator boolean Flag that determines if device is a container for other devices

Acronym string alphanumeric device acronym

Name string Free form device name

AccessID int ID code associated with device, if any

ParentAcronym string If device is a child of another device, acronym of parent device

FramesPerSecond int Expected data rate, in received samples per second, for device measurements

CompanyAcronym string Company that owns device

VendorAcronym string Vendor that manufactures device

VendorDeviceName string Vendor device name and/or model information

Longitude decimal Longitude of device location

Latitude decimal Latitude of the device location

InterconnectionName string Eastern, Western, etc.

ContactList string Names / e-mail addresses of parties responsible for device

Enabled boolean Flag that determines if device is currently enabled

UpdatedOn dateTime Timestamp of last update of device metadata


Page 88

MeasurementDetail

This metadata table contains details about the measurements available for subscription.


DeviceAcronym string Alphanumeric device acronym that is the source of the measurement

ID string A measurement key identifier formatted as {instance}:{id}

SignalID Guid Unique identifier for the measured value

PointTag string Unique alphanumeric identifier for the measured value

SignalReference string Alphanumeric reference to original signal source, e.g., location in source protocol

SignalAcronym string Type of signal, e.g., FREQ for frequency

PhasorSourceIndex int Index of phasor source if measurement type is a phasor

Description string Description of the measurement

Enabled boolean Flag that determines if measurement is currently enabled

UpdatedOn dateTime Timestamp of last update of measurement metadata

PhasorDetail

This metadata table, specific to data exchanges containing electrical measurements with phasor values, contains details about the phasors whose vector magnitude and angle component measurements are available for subscription.


ID int Numeric auto-incrementing identifier

DeviceAcronym string Alphanumeric device acronym that is the source of the phasor

Label string Free form phasor label

Type string Type of phasor, i.e.: voltage (V) or current (I)

December 6, 2019



Phase string Phase of phasor, e.g.: (A), (B), (C), (+), (-), etc.

DestinationPhasorID int Associated phasor, e.g., typical voltage for current

SourceIndex int Index of phasor as defined in source protocol

UpdatedOn dateTime Timestamp of last update of DestinationPhasorID metadata

FILTER EXPRESSION PARSING

Filter expressions in STTP are parsed using ANTLR (ANother Tool for Language Recognition). ANTLR is an open source parser/generator tool for reading, processing, executing, or translating structured text. Since ANTLR is available for a wide set of programming targets, a single grammar file can be used to build multiple language targets, making it ideal for the STTP API and associated tools. From the following grammar, ANTLR generates a source code parser that can build and walk parse trees that is then used to execute a filter expression against a dataset provided by a data publisher.

Syntax Parsing Grammar

grammar FilterExpressionSyntax; parse : ( filterExpressionStatementList | error ) EOF ; error : UNEXPECTED_CHAR { throw RuntimeException("Unexpected character: " + $UNEXPECTED_CHAR.text); } ; filterExpressionStatementList : ';'* filterExpressionStatement ( ';'+ filterExpressionStatement )* ';'* ; filterExpressionStatement : identifierStatement | filterStatement | expression ; identifierStatement : GUID_LITERAL | MEASUREMENT_KEY_LITERAL


Page 90

| POINT_TAG_LITERAL ; filterStatement : K_FILTER ( K_TOP topLimit )? tableName K_WHERE expression ( K_ORDER K_BY

orderingTerm ( ',' orderingTerm )* )? ; topLimit : ( '-' | '+' )? INTEGER_LITERAL ; orderingTerm : exactMatchModifier? orderByColumnName ( K_ASC | K_DESC )? ; expressionList : expression ( ',' expression )* ; /* Expressions understand the following binary operators, in order from highest to lowest precedence: * / % + - << >> & | < <= > >= = == === != !== <> IS NULL IN LIKE AND && OR || */ expression : notOperator expression | expression logicalOperator expression | predicateExpression ; predicateExpression : predicateExpression notOperator? K_IN exactMatchModifier? '(' expressionList ')' | predicateExpression K_IS notOperator? K_NULL | predicateExpression comparisonOperator predicateExpression | predicateExpression notOperator? K_LIKE exactMatchModifier? predicateExpression | valueExpression ; valueExpression : literalValue | columnName | functionExpression | unaryOperator valueExpression | '(' expression ')' | valueExpression mathOperator valueExpression | valueExpression bitwiseOperator valueExpression

December 6, 2019


; notOperator : K_NOT | '!' ; unaryOperator : '-' | '+' | '~' | '!' | K_NOT ; exactMatchModifier : K_BINARY | '===' ; // === and !== are for case sensitive string match comparisonOperator : '<' | '<=' | '>' | '>=' | '=' | '==' | '===' | '!='| '!==' | '<>' ; logicalOperator : K_AND | '&&' | K_OR | '||' ; bitwiseOperator : '<<' | '>>' | '&' | '|' | K_XOR | '^' ; mathOperator : '*' | '/' | '%' | '+' | '-' ; functionName : K_ABS | K_CEILING | K_COALESCE | K_CONVERT | K_CONTAINS | K_DATEADD | K_DATEDIFF | K_DATEPART | K_ENDSWITH | K_FLOOR | K_IIF | K_INDEXOF | K_ISDATE | K_ISINTEGER

December 6, 2019


// Terminals for keywords should come before terminals with pattern expressions // Keywords K_ABS: A B S; K_AND : A N D; K_ASC : A S C; K_BINARY : B I N A R Y; K_BY : B Y; K_CEILING : C E I L I N G; K_COALESCE : C O A L E S C E; K_CONVERT : C O N V E R T; K_CONTAINS : C O N T A I N S; K_DATEADD : D A T E A D D; K_DATEDIFF : D A T E D I F F; K_DATEPART : D A T E P A R T; K_DESC : D E S C; K_ENDSWITH : E N D S W I T H; K_FILTER : F I L T E R; K_FLOOR : F L O O R; K_IIF : I I F; K_IN : I N; K_INDEXOF : I N D E X O F; K_IS : I S; K_ISDATE : I S D A T E; K_ISINTEGER : I S I N T E G E R; K_ISGUID : I S G U I D; K_ISNULL : I S N U L L; K_ISNUMERIC : I S N U M E R I C; K_LASTINDEXOF : L A S T I N D E X O F; K_LEN : L E N; K_LIKE : L I K E; K_LOWER : L O W E R; K_MAXOF : M A X O F; K_MINOF : M I N O F; K_NOT : N O T; K_NOW : N O W; K_NTHINDEXOF : N T H I N D E X O F; K_NULL : N U L L; K_OR : O R; K_ORDER : O R D E R; K_POWER : P O W E R; K_REGEXMATCH : R E G E X M A T C H; K_REGEXVAL : R E G E X V A L; K_REPLACE : R E P L A C E; K_REVERSE : R E V E R S E; K_ROUND : R O U N D; K_SQRT : S Q R T; K_SPLIT : S P L I T; K_STARTSWITH : S T A R T S W I T H; K_STRCOUNT : S T R C O U N T; K_STRCMP: S T R C M P; K_SUBSTR: S U B S T R; K_TOP : T O P; K_TRIM : T R I M; K_TRIMLEFT : T R I M L E F T;


Page 94

K_TRIMRIGHT : T R I M R I G H T; K_UPPER : U P P E R; K_UTCNOW : U T C N O W; K_WHERE : W H E R E; K_XOR : X O R; BOOLEAN_LITERAL : T R U E | F A L S E ; IDENTIFIER : '`' ( ~'`' )+ '`' | '[' ( ~']' )+ ']' | [a-zA-Z_] [a-zA-Z_0-9]* // TODO check: needs more chars in set ; INTEGER_LITERAL : DIGIT+ | '0' X HEX_DIGIT+ ; NUMERIC_LITERAL : DIGIT+ ( '.' DIGIT* )? ( E [-+]? DIGIT+ )? | '.' DIGIT+ ( E [-+]? DIGIT+ )? ; GUID_LITERAL : '\'' GUID_VALUE '\'' | '{' GUID_VALUE '}' | GUID_VALUE ; MEASUREMENT_KEY_LITERAL : ACRONYM_DIGIT+ ':' DIGIT+ ; POINT_TAG_LITERAL : '"' ACRONYM_DIGIT+ '"' ; STRING_LITERAL : '\'' ( ~'\'' | '\'\'' )* '\'' ; DATETIME_LITERAL : '#' ( ~'#' )+ '#' ; SINGLE_LINE_COMMENT : '--' ~[\r\n]* -> channel(HIDDEN) ; MULTILINE_COMMENT : '/*' .*? ( '*/' | EOF ) -> channel(HIDDEN)

December 6, 2019


; SPACES : [ \u000B\t\r\n] -> channel(HIDDEN) ; UNEXPECTED_CHAR : . ; fragment DIGIT : [0-9]; fragment HEX_DIGIT : [0-9a-fA-F]; fragment ACRONYM_DIGIT : ( [a-zA-Z0-9] | '-' | '!' | '_' | '.' | '@' | '#' | '$' ); fragment GUID_VALUE : HEX_DIGIT HEX_DIGIT HEX_DIGIT HEX_DIGIT HEX_DIGIT HEX_DIGIT HEX_DIGIT HEX_DIGIT '-'? HEX_DIGIT HEX_DIGIT HEX_DIGIT HEX_DIGIT '-'? HEX_DIGIT HEX_DIGIT HEX_DIGIT HEX_DIGIT '-'? HEX_DIGIT HEX_DIGIT HEX_DIGIT HEX_DIGIT '-'? HEX_DIGIT HEX_DIGIT HEX_DIGIT HEX_DIGIT HEX_DIGIT HEX_DIGIT HEX_DIGIT HEX_DIGIT

HEX_DIGIT HEX_DIGIT HEX_DIGIT HEX_DIGIT ; fragment A : [aA]; fragment B : [bB]; fragment C : [cC]; fragment D : [dD]; fragment E : [eE]; fragment F : [fF]; fragment G : [gG]; fragment H : [hH]; fragment I : [iI]; fragment J : [jJ]; fragment K : [kK]; fragment L : [lL]; fragment M : [mM]; fragment N : [nN]; fragment O : [oO]; fragment P : [pP]; fragment Q : [qQ]; fragment R : [rR]; fragment S : [sS]; fragment T : [tT]; fragment U : [uU]; fragment V : [vV]; fragment W : [wW]; fragment X : [xX]; fragment Y : [yY]; fragment Z : [zZ];

project final technical report advanced synchrophasor ... · 10 seconds) to synchrophasor (60 or...

Documents