It is a reasonable question to ask: Should Subscribing IEDs send a return “confirmation GOOSE” that they received the intended GOOSE? Beware GOOSE ping-pong! The first thing to remember is GOOSE is not guaranteed reception: IEC 61850-2 Ed1 cl 2.44 "A GOOSE report enables high speed trip signals to be issued with a high probability of delivery".
It is essential that the Systems Integrator anticipates scenarios where a particular function fails to receive either a heartbeat message or indeed any of the Fast Repetition following a trigger in the source IED - this is part of Failure Mode Effects Analysis and building in "graceful degradation". The following scenario demonstrates why “confirmation GOOSE” is of no benefit and potentially undermines good network/IED performance Imagine "IED1" is the Publisher of a GOOSE on the network
There are 100 other IEDs on the network (101 in total) - ignoring VLAN/Multicast filtering, lets assume all 100 receive this message.
"Today", 40 of these IEDs actually subscribe to this GOOSE and use its dataset somehow.
Should all 100 IEDs ping back that they have indeed received the GOOSE message, or should only the 40 Subscribing IEDs respond? Now consider the original Publisher. It does not know how many (if any) IEDs are supposed to receive IED1’s GOOSE.
IED1 should now receive 100 (or 40) return "confirmation GOOSE". IED1 must now be configured to Subscribe to each of these 100 (or 40) "confirmation GOOSE”.
Even if it does know how many IEDs are supposed to ping back, what if “Tomorrow” another IED is connected on the system, or perhaps just an extra 10 of the 60 are now changed to also Subscribe? There should be no hassles associated with another IED Subscribing to the GOOSE, but you would have to go back to IED1 and add to its Subscriptions. In the meantime there are really important “operational GOOSE” arriving at IED1 for which IED1 should respond with say a CB trip etc. However it is now busy dealing with receiving and analysing the Dataset of each of these other 100 (or 40) GOOSE before it notices an "operational GOOSE" has arrived.
How does IED1 sort through the GOOSE to see what is really important for its own operational duties? IED1 now has a whole bunch of “confirmation GOOSE”. It is already repeating its own original GOOSE with the steady state status as its “heartbeat” or a changed status is being repeated more frequently.
What do you expect the original IED1 as the original Publisher to do if it only gets 99 (or 39) positive confirmations back – what device should it send a message to? Yes, it could send a message to the SCADA system, but equally the SCADA system could have been subscribing to all these “confirmation GOOSE” directly. Now consider IED1 is sending its heartbeat or fast repetition GOOSE. The 100 (or 40) have an expectation of when to receive the next GOOSE. Successful arrival would yield a return “confirmation GOOSE” with status = 1. Obviously this Subscriber would never send a repeat heartbeat of the first status as it is simply continuously returning a message as “got that one”, “got that one”, “got that one” …. i.e. they are new status every time. Now suppose the expected GOOSE does not arrive including an appropriate waiting time. The Recipient IED – possibly all 100 (or 40) must now send a return GOOSE on Fast Repetition cycle with “GOOSE received” status bit = 0 with the meaning “I didn’t get that one”. That message gets repeated in relation to the “first missing GOOSE”. One second later it has not received (at least) two 2 GOOSE - does i tnow send back two GOOSE sayign I didn't receive #1 and #2, then 1 second later a different message that it didn't receive #1, #2, #3 .... Now consider “IED2” (or indeed all other 100 IEDs). It is Subscribing to “operational GOOSE” from all other 100 IEDs. It would need to send back either 100 individual GOOSE, or at least a GOOSE with 100 elements, representing successful receipt of all the other IEDs GOOSE. The final issue is of course should IED1 send back confirmation GOOSE that it has indeed received all 100 (or 40) confirmation GOOSE associated with its first GOOSE? We now have a babble of communications - a gaggle of GOOSE .... maybe the acronym is then "GEESE" as "General Extraneous Event Subscription Explosion" ....  Ping-pong is really not a good game to play with GOOSE. Perhaps the subscribing IED has itself failed. This is a bit different to the IED failing to receive a specific GOOSE and can be generally alarmed as an IED healthy GOOSE. | Tip |
|---|
| A better approach is therefore for the Subscribing IEDs to act as a Server IED to issue an MMS Report to a specific Client in the (rare) situation where it has not received an expected GOOSE (perhaps a certain number of expected GOOSE over a certain time frame given Fast Repetition cycles). This IED can then go into a pre-engineered graceful degradation mode until the GOOSE is restored. |
Download this 30-second 2.72 MB MOV file to see a demonstration: GOOSE ping-pong confirmation.mov | Multimedia |
|---|
| width | 100% |
|---|
| name | GOOSE ping-pong confirmation.mov |
|---|
| autostart | true |
|---|
|
|