gaps in synchrophasor systems with c37118-rev1_3mar10 - ken martin

8/7/2019 Gaps in Synchrophasor systems with C37118-Rev1_3mar10 - Ken Martin

http://slidepdf.com/reader/full/gaps-in-synchrophasor-systems-with-c37118-rev13mar10-ken-martin 1/4

Gaps in synchrophasor system implementation using C37.118-2005

This document is derived from the “Gaps” document drafted by Mark Adamiak. The firstsection suggests some approaches to resolve many of the gaps issue. Perhaps a group couldpropose some detailed solutions along these lines to be submitted to the 37.118 working group tospeed the development process. The second section is the original “Gaps” document with someanswering comments and proposals from Ken Martin to start a dialog to answering the concerns.K. Martin3 March 2010

Proposed solutions that could be drafted for the current C37.118 revisionThese solution proposals are keyed to the Gaps listing below.

A. Add new commands in the 37118 command set and message types as neededThe command set allows 65535 commands and 8 message types. Currently there are 6commands and 5 message types defined.

Add the following commands:Add a command to retrieve specific data. [Gap 2]

Add a command that starts a data stream to a specific address and port by UDP.This address and port can be multicast or unicast. The address and port aregiven as 6 2-byte words in the extended command frame. [Gap 3 & 4]

Add a command that will stop data to a specific address and port; companion tothe above command.

Add the following messages:Config3 message which would include the provision for an extensible frame (ie,break message frame into multiple sub-frames) to overcome the frame lengthlimit and the following new data items called out in the paragraphs below—

• PMU location (with provision for user to insert blank data) [gap 5]• Allow additional name space. Note that NASPI is far from convergence

on this, so this may be premature here. [gap 6]• Add fields for measurement window length and measurement timetag

position [gap 7,12,15]Data of a historical nature (stored disturbances or cached for data loss) [Gap 2] —

This data frame will be much the same as normal data frames, but withsome additional fields to identify their time stamp, request number, etc.This frame can also be used in system testing by utilizing the additional

B. Map TQ bits into status security bits [gap 11]C. More?



Original Gaps listingMark Adamiak Rev 31/4/2010 Comments by K. Martin

1. Security in C37.118 - What is required?a. Authentication?b. Integrity?c. Confidentiality?d. Addition of hash?Proposed solution: To address Authentication and Integrity, add a Hash code to theSynchrophasor message. If Confidentiality is required, add an external box and thesolution is then independent of the standard. The latency of the solution needs to bemeasured and reported (see latency proposal below)this a big issue that needs much consideration. 61850 apparently needs somesecurity treatment too, so maybe the same can be applied to both.

2. Lost data recovery is not addressed by C37.118Proposed solution: Recommend use of Off-the-Shelf database tools such as SQL

and/or OPC-HDA/ OPC-UA-HDA to retrieve missing or requested recordsOr use 61850. The problem is it requires significant added PMU functionality.3. Initiation of TCP vs. UDP data streams not addresses

Proposed solution: Add a bit in the PMU that, if set, streams the data via UDP,else, the data is streamed via TCP. Additionally, the address of the remote deviceshall be settable in the PMU.

This is a little simplistic. This and #4 can be solved with some simple commands.4. Support for UDP/IP Multicast

a. Configuration mechanismb. Setting of Multicast addressc. Port /IP address recommendations

Proposed Solution: Define that the Stream command shall always be issued to afixed address and that the Multicast IP address is to be a setting.

5. Inclusion of Latitude and Longitude dataProposed solution: Define new data areas in the CFG1 file and use theformat described in the 61850 document

I propose adding config frames to communicate all the added PMU and datacomminformation while leaving the existing files as they are. This solves backward compatibility.This can also be used to solve the frame size limit issue.6. Support for NASPI substation naming convention

Proposed solution: Define new data areas in the CFG1 file7. Transmission of Communication Latency information

Proposed solution: Assuming that latency doesn’t change too often, makethe latency measurement a data value in the CFG2 file. If changing latency

Formatted: Indent: Leftpt





is an issue, augment the synchrophasor stream to include the output time of the message

Latency is an issue that is mostly outside of the PMU. It is impractical to try to include it inthe PMU.8.Need for standard Indexing of data in Historians/Databases

Observation: This is not a C37.118 issues but it does affect interoperability. Proposed solution: Create an Implementation Agreement in NASPI that

proposes the use the SOC and FOS (to 1usec resolution) as the record index 8. 9. Remote PDC configuration not possible through 118

Proposed solution: Wait for IEC 61850Good solution, but requires dual-protocol communications10. Identification o f Bad or Missing data in a PDC stream

Proposed Solution: The Magnitude of the Phasor is set to “-1” and theangle is set to “-360” – both invalid values

Cannot be represented in the current integer format; there is already a data invalid bit.11. Mapping of Time Quality from multiple PMUs (only one time quality stamp per

aggregated packet presently exists)Proposed solution: Map the Time Quality bits as the first 4 bits in thebinary status word in each PMU. This would make the Binary status wordmandatory.

Another alternative is to map into the bits left for security 12. Data filter description should be part of the Configuration file

Proposed solution: Add descriptive text to the CFG2 file that describes thelatency resulting from any synchrophasor data filter. Other quantities suchas the cut-off frequency, type, and attenuation may be optionally added

Easy to add—see 5 above.13. Device Off-line / Out-of-Scan indication in the file (e.g. – when a line is out of

service)Proposed solution: Use one of the status bits to indicate a PMU “off-line”and set all data to Zero. How a PDC responds to a Device Off Line needs tobe defined. One suggestion is that it is taken out of scan and thenperiodically (e.g. once per minute) checked to see if the device is back online. Alternatively, the scan could be re-started by manual intervention.

This is confused: when a line or other input is out of service, the data is 0. When the PMU isout of service, the next device marks the data invalid. The receiving device has no way todetermine if the device is idled or the communication is broken. If more active managementof PMUs is the object here, this can be added into the protocol. This concern needs to beclarified.14. Identification of bad or missing data

Proposed solution: After a user-configurable time out in the receivingPDC, set the missing magnitudes to –1 and the angles to “-360” to indicatemissing data

This is a repeat of item #10


Formatted: Bullets andNumbering

Formatted: Indent: Leftpt, Hanging: 81 pt, Numbe+ Level: 4 + Numbering Sty1, 2, 3, … + Start at: 1 +

Alignment: Left + Aligned a126 pt + Tab after: 144 pt Indent at: 144 pt, Tabs: 63pt, List tab + Not at 144 pt





Formatted: Not Highlig






15. Support for “Front of Window” time stampingProposed solution: Add a field to the CFG2 file that identifies the time - inms – to identify the front of the window

More generally, we can add a field that identifies window length and time stamp relative tothe end of the window.16. Mapping of Synchrophasor datasets from multiple substation and multiple utilities

into a sub-super PDC stream

Proposed solution: Add fields to the CFG2 file – one for each aggregatedstream – to identify the source substation and util ity. The substation andutility names will be repeated for each source from the same substation.

The meta-data issue is taken care of by the PMU registry. One unique identifier for everysubstation in enough17. Historical data access (SQL vs. OPC-HDA)

Observation: not a C37.118 issue but it is an interoperability issue.Suggest making a choice

18. Multi-language support in the user-configurable CFG fileProposed solution: Use HTML with support for Unicode

It is not clear what this refers to. As currently defined, the 37118 CFG files are configuredand produced by the PMU. If this comment refers to the configuration of the PMU, these arehandled by the vendor and this is not in the scope of 37118.19. Need clear description of the PMU process during re-configuration as after a re-

configuration, the configuration may be different and the PDC needs to beable to detect such. Clearly, the stream needs to stop. There needs to be anindication to the client that a configuration change is in process .

This is already done with the configuration change bit. Anything else needed?20. Storage of data in Polar vs Rectangular format

Observation: Not a standard issue but an interoperability issueProposal : Store and re-transmit all data in Polar format

Agreed that polar is the better format; polar-FP is the best and we should migrate that way.There is considerable legacy equipment that needs to be considered.21. See other items from Herb Falk’s Deep Dive document

There are plenty of issues there, most dealing with communication system aspects. C37.118 isnot a communication system and it is not really a protocol. It is a format for packaging data withsome minimal commands to start/stop data and retrieve basic information. For a completeprotocol is would be better to use one that already exists and is designed to carry this type of traffic. 61850 may be a good approach for doing that.







gaps in synchrophasor systems with c37118-rev1_3mar10 - ken martin

Documents