Gaps in synchrophasor system implementation using C37.

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

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

A. Add new commands in the 37118 command set and message types as needed
The command set allows 65535 commands and 8 message types. Currently there are 6
commands 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 are
given 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 to
the 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 length
limit 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 with
some 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 listing
Mark Adamiak
Rev 3
1/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 the
Synchrophasor message. If Confidentiality is required, add an external box and the
solution is then independent of the standard. The latency of the solution needs to be
measured and reported (see latency proposal below)
this a big issue that needs much consideration. 61850 apparently needs some
security treatment too, so maybe the same can be applied to both.
2. Lost data recovery is not addressed by C37.118
Proposed solution: Recommend use of Off-the-Shelf database tools such as SQL
and/or OPC-HDA/OPC-UA-HDA to retrieve missing or requested records
Or use 61850. The problem is it requires significant added PMU functionality. Formatted: Indent: Left: 18
pt
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 device
shall be settable in the PMU.
This is a little simplistic. This and #4 can be solved with some simple commands. Formatted: Indent: Left: 18
pt
4. Support for UDP/IP Multicast
a. Configuration mechanism
b. Setting of Multicast address
c. Port /IP address recommendations

Proposed Solution: Define that the Stream command shall always be issued to a
fixed address and that the Multicast IP address is to be a setting.
5. Inclusion of Latitude and Longitude data
Proposed solution: Define new data areas in the CFG1 file and use the
format described in the 61850 document
I propose adding config frames to communicate all the added PMU and datacomm Formatted: Indent: Left: 18
pt
information 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 file
7. Transmission of Communication Latency information
Proposed solution: Assuming that latency doesn’t change too often, make
the latency measurement a data value in the CFG2 file. If changing latency
 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 in Formatted: Indent: Left: 18
pt
the PMU.
8.Need for standard Indexing of data in Historians/Databases Formatted: Bullets and
Numbering
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. Formatted: Indent: Left: 18
pt, Hanging: 81 pt, Numbered
9. Remote PDC configuration not possible through 118 + Level: 4 + Numbering Style:
Proposed solution: Wait for IEC 61850 1, 2, 3, … + Start at: 1 +
Good solution, but requires dual-protocol communications Alignment: Left + Aligned at:
126 pt + Tab after: 144 pt +
10. Identification of Bad or Missing data in a PDC stream Indent at: 144 pt, Tabs: 63
Proposed Solution: The Magnitude of the Phasor is set to “-1” and the pt, List tab + Not at 144 pt
angle is set to “-360” – both invalid values Formatted: Indent: Left: 18
pt
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 Formatted: Indent: Left: 18
pt
aggregated packet presently exists)
Proposed solution: Map the Time Quality bits as the first 4 bits in the
binary status word in each PMU. This would make the Binary status word
mandatory.
Another alternative is to map into the bits left for security Formatted: Indent: Left: 18
pt
12. Data filter description should be part of the Configuration file
Proposed solution: Add descriptive text to the CFG2 file that describes the
latency resulting from any synchrophasor data filter. Other quantities such
as the cut-off frequency, type, and attenuation may be optionally added
Easy to add—see 5 above. Formatted: Indent: Left: 18
pt
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 to
be defined. One suggestion is that it is taken out of scan and then
periodically (e.g. once per minute) checked to see if the device is back on
line. 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 is Formatted: Not Highlight
out of service, the next device marks the data invalid. The receiving device has no way to Formatted: Indent: Left: 18
determine if the device is idled or the communication is broken. If more active management pt

of PMUs is the object here, this can be added into the protocol. This concern needs to be
clarified. Formatted: Not Highlight
14. Identification of bad or missing data
Proposed solution: After a user-configurable time out in the receiving
PDC, set the missing magnitudes to –1 and the angles to “-360” to indicate
missing data
This is a repeat of item #10 Formatted: Indent: Left: 18
pt
 15. Support for “Front of Window” time stamping
Proposed solution: Add a field to the CFG2 file that identifies the time - in
ms – to identify the front of the window
More generally, we can add a field that identifies window length and time stamp relative to Formatted: Not Highlight
the end of the window. Formatted: Indent: Left: 18
16. Mapping of Synchrophasor datasets from multiple substation and multiple utilities pt

into a sub-super PDC stream

Proposed solution: Add fields to the CFG2 file – one for each aggregated
stream – to identify the source substation and utility. The substation and
utility 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 every Formatted: Indent: Left: 18
pt
substation in enough
17. 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 file
Proposed solution: Use HTML with support for Unicode
It is not clear what this refers to. As currently defined, the 37118 CFG files are configured Formatted: Indent: Left: 18
pt
and produced by the PMU. If this comment refers to the configuration of the PMU, these are
handled 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 be
able to detect such. Clearly, the stream needs to stop. There needs to be an
indication to the client that a configuration change is in process.
This is already done with the configuration change bit. Anything else needed? Formatted: Indent: Left: 18
pt
20. Storage of data in Polar vs Rectangular format
Observation: Not a standard issue but an interoperability issue
Proposal: 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. Formatted: Indent: Left: 18
pt
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 is
not a communication system and it is not really a protocol. It is a format for packaging data with
some minimal commands to start/stop data and retrieve basic information. For a complete
protocol 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.