I have a question regarding Output Stream generated by OpenPDC when using IEC 61850-90-5 Standards.
I was wondering if OpenPDC manipulate the Configuration frame (CFG-2/3) for output stream and adds/converts its own type/data or it just following the official standards regarding this matter?
The output stream for IEC 61850-90-5 is very similar to IEEE (based on wireshark network analysis that I have done on the frame) so I was wondering if OpenPDC is adding/converting something extra that needs to be considered or it is following the standards.
I’m asking this because I know previously the configuration and command frame was done through MMS protocol; Also the “Technical Report of the IEC 61850-90-5 Standards” its a bit unclear and confusing when it comes to how it transfers the configuration frame. And unfortunately at this stage I dont have a valid Network Dump of the IEC 61850-90-5 for comparison. Therefore, I am asking here for clarification.
In addition, I would really appreciate if someone could give me a valid network dump file (Wireshark dump) of IEC 61850-90-5 from any other PDCs so I can compare it to OpenPDCs output stream
To give you some background, GPA’s implementation of IEC TR 61850-90-5 was one of the first deployments of 90-5 that was used along with a hardware based GE PDC that also implemented the protocol. For background:
In 2009, the IEEE made a request to the IEC for an IEEE C37.118 dual logo but the request was declined by the IEC because of a preexisting protocol technology, i.e., IEC 61850 9 2, which could convey synchrophasor information. Following this, a joint task force was formed between the IEEE and IEC which worked on methodologies and agreements that led to changes in IEEE C37.118 and the ultimate creation of IEC TR 61850 90 5.
To facilitate harmonizing the IEEE and IEC work, IEEE C37.118 was split into two parts before further development. Part one focused on the metrology of synchrophasor measurements and added requirements for dynamic operating conditions, frequency, and rate of change of frequency. Part two focused on defining the protocol’s binary data format. Both revisions were completed in 2011. Although part two added new communication functionality, such as a new configuration frame format, its development was limited so that it would be backwards compatible with the original, then widely deployed, 2005 standard.
The IEC 61850 90 5 technical report was completed in 2012. Given what at the time was the ubiquitous use of IEEE C37.118, the IEC standard included technical documents to facilitate migration from IEEE C37.118 to 90-5. These documents addressed updates to the IEC 61850-6 standard so that the existing IEEE C37.118 configuration frame could be used to define measurements being published in 90-5. The documents also included information on the use of Generic Object-Oriented Substation Event (GOOSE) messages and Sampled Values for synchrophasor data as prescribed in the umbrella IEC 61850 standard. The first implementation of the IEC TR 61850 90 5 protocol was deployed at PG&E between GE Multilin N60 and openPDC systems.
As your question infers, the 90-5 protocol allows for native 61850 protocol options for defining the configuration, e.g., names and sequences of values defined in a data frame using Substation Control Language (SCL) as described in IEC 61850-6-1. However, to support transitional environments for synchrophasor implementations wanting to switch from IEEE C37.118 to IEC TR 61850 90 5, many 90-5 protocol implementations also support use of the IEEE C37.118.2-2011 configuration frame and a limited set of the IEEE C37.118.2-2011 command frame functionality. Use of IEEE configuration/command frames was established per an implementation agreement that was created during the initial development and deployment of 90-5.
GPA developed its .NET based 90-5 implementation inspired by an open source C version that was made available by SISCO. Since at the time of development none of the “native” 90-5 protocol options for configuration were available as part of the SISCO open source code, GPA leveraged the implementation agreement which allowed for transitional the use of standard IEEE C37.118 configuration frames and command frames.
Today the GPA implementation of 90-5 still operates in the “transitional support mode” with the hybrid C37.118 configuration and command frames. To date we have had no requests to update the 90-5 implementation to use the native configuration features - perhaps because in the U.S., IEEE C37.118 remains the dominant protocol for synchrophasor transport. However, if you would like to add native configuration options, the code is open source and we do accept community contributions
