why are there GOOSE and GSSE in IEC 61850

[出处]

http://sharepoint.ucausersgroup.org/helpdesk/Lists/Help%20Desk%20Issues/DispForm.aspx?ID=37

[Q]

Name: Zhiliang YinCompany: North China Electric Power UniversityEmail : yinzhiliang@21cn.com

[A]

Mr. Yin,
My name is Herbert Falk. I am an editor of IEC 61850 and I have been asked to respond to your question regarding the SendGOOSEMessage and SendGSSEMessage. I have broken this response into a statement of philosophy and a detailed response to your questions.
Philosphy (why are there GOOSE and GSSE in IEC 61850):
First, both GOOSE and GSSE are high speed multicast messages (in IEC 61850-8-1). Both are designed to be able to be transmitted and received in under 4msec. The preference for 61850 implementations is to provide GOOSE with GSSE being optional. There is a historical reason for this.
The IEC GSSE is mapped to the same message and profile structure as the EPRI UCA GOOSE. It was designed to transmit status bit-pairs only. IEC 61850 took the concepts of the UCA GOOSE and generalized it to be able to send more than just double bits status points (e.g. IEC GOOSE can send analogs, quality, timestamps, and structured information).
IEC GSSE is in IEC 61850 to provide a migration and interoperability point with UCA devices. IEC GOOSE, although maybe less efficient for sending only double bit status points, is much more flexible and represents the future direction of implementations.
Detailed response to your email:
The SendGOOSEMessage service, of IEC 61850-7-2, is mapped directly onto a standardardized Ethertype ID that allows VLAN technology usage. Thus it is possible to prioritize traffic and create virutal LAN segments with this mapping. This was found to be a very important capability in order to increase overall network and node efficiencies.
The SendGSSEMessage service is mapped to the same message format and profile as the UCA 2.0 GOOSE. This combination makes use of an MMS InformationReport message that is conveyed via a connectionless OSI stack. Thus it does not make use of VLAN or Ethertype, nor TCP/IP as was stated in you inquiry. Intead it makes use of ISO connectionless transport, Connectionless Network Layer Protocol (CLNP), Logical Link Control (LLC), and 802.3 multicast addressing.
However, during deployment of the UCA GOOSE, several issues with the message payload (e.g. PhsID and DNA in particular) needed to be clarified. I will attempt to explain the issue with PhsID.
PhsID was originally intended to convey the phase which caused the change of state(s) that were conveyed in the UCA GOOSE message. Upon implementation and field deployment, it became obvious that attributing a state change of over 96 bit pairs to a single phase was not a correct assumption. It was further found that most field deployments filled in the field with a value representing NONE. Thus I would not be concerned with the IEC GOOSE not having this information explicitly exposed, as it was not very useful in the UCA realm. The parameter was kept in 7-2 and 8-1 to allow compatibility with UCA, not neccesarily to endorse its use.
In regard to choosing SendGOOSEMessage or SendGSSEMessage, the future directions of IEC 61850 implementations is to support SendGOOSEMessage. Some vendors, who are concerned with backwards compatibility to UCA, will also support the SendGSSEMessage.

I hope this helps.