Rod Hughes Consulting General Web Site	Applications Home	Innovations and Solutions Home	A bit about Rod Hughes	Link to this page... The URL in the browser address bar is volatile and may be broken at any time. To obtain a link to this page, click the <<Share>> button top-right of the screen.

Note - if the navigation pane on the left of this window is not visible, click the 2-pane icon on the top bar

GOOSE opens up a fascinating world of easy deployment of complex functions. Naturally this should be considered in light of what happens if a GOOSE doesn’t arrive at a subscribing IED.
Now we are getting into the realm of Failure Mode Effects Analysis of a system, or, as the Standard refers to it, "graceful degradation".

Remembering that GOOSE is repeated as a 1-second heartbeat (or whatever we decide is the maximum “timeAllowedtoLive” value up to 4 294 967 295 ms!!) .... i.e. the subscribing IED is being told in every GOOSE it receives from each publishing IED that the next GOOSE from that publisher should be no more than 1000 ms later.

Lets consider a Reverse Blocking scheme – this is where all the “downstream” IEDs on each of the outgoing feeders of a busbar are sending GOOSE to an upstream IED on the incomer.
If there is a fault detected on the feeder, that feeder IED needs to block the instantaneous, or more precisely the fast definite time element of the upstream IED to allow the fault to be cleared by the feeder IED.
But if the upstream IED sees a fault but no blocking, the fast definite time element can operate to trip the breaker in the assurance that it is a bus bar fault.

Initially there is no fault anywhere on the power system so all the downstream IEDs are sending their individual GOOSE as their instantaneous element PTOC.Str = 0 as a 1-second heartbeat as nothing has changed on their feeder.

The upstream subscribing IED (or indeed any subscribing IED) knows that if it is receiving over the course of 1 second all the GOOSE from each publishing IED to which it is subscribing:

the upstream IED is healthy and receiving the GOOSE
the network is healthy.
the individual feeder relays are all working and connected to the network

Well, something may have changed in the last one second (yes, a lifetime for protection functions) but we are reasonably certain it is all OK - more so than for wire based systems by a long shot.

If the upstream IED does not receive its next anticipated GOOSE from one feeder, there is certainly a problem of the message coming from that one feeder IED or its connection to the network.
However the upstream IED has no reason to block its own operation if it sees a fault because of that – in fact you would not want it to block as basically it has to assume that no other IED is capable of seeing the fault so it is “the last line of defence”.
The upstream IED can certainly alarm that one particular GOOSE has failed to arrive – it is then a question of whether to alarm instantaneously or only after a certain number have failed to arrive.
Note any other subscribing IEDs would also identify that one downstream feeder IED is no longer communicating so there would be several confirmations of a failure of a single feeder IED.

A short time later(but still << 1 second), the upstream IED is expecting another GOOSE from a second feeder IED which also does not arrive, then there is a problem not just affecting one IED.

A short time later again, it is expecting another GOOSE from a third feeder IED it can start considering there is a serious failure of the network.

Perhaps the fourth IED message arrives OK, so perhaps only part of the network where the IEDs for Feeder 1, 2 and 3 are connected is not working. But if the fourth message does not arrive then it seems evident that a more catastrophic failure of the network or the subscribing IED itself has occurred.

If the upstream IED has stopped receiving ALL GOOSE from ALL the downstream feeders, then there is a problem either with the upstream IED comms port, or the connection to the switch for the upstream IED or a complete failure of the comms network (auxiliary supply failure to the switches?).

If other subscribing IEDs have also stopped receiving all the GOOSE, then there is a catastrophic failure of the network overall.

But suppose now the upstream IED is also a GOOSE publisher in its own right.
Now the other subscribing IEDs can also be monitoring the feeder IEDs and the upstream IED as well. This will provide much clearer indication of whether there is a general network failure or if the upstream IED itself has failed – also noting that the GOOSE data set can include the “.q” Attribute of the function or even the physical state of the IED overall as LPHD.PhyHealth.

Note all that is happening even before a fault has occurred on the power system. We may have had enough time to take manual intervention to fix the problem or decide what mode we want the system to operate in if not engineered in as an automatic process.

Now suppose one of the downstream IEDs has seen a fault and issued its PTOC.Str changing from a 0 to a 1 and that message is sent instantaneously.

The upstream IED will go into a BLOCK condition immediately based on that one GOOSE being received.
The upstream IED is also told to expect the next repeat message in 5 ms (or whatever the fast repetition cycle is set to start on).

5 ms the GOOSE is repeated as no 2 in the sequence and advising the subscribers then next will be in 10 ms.

10 ms later (i.e. 15 ms after the first message) repeated again as no 3 and advising the subscribers then next will be in 20 ms

Now, what if the no 4 GOOSE does not arrive when expected as 35 ms after the first PTOC.Str=1 message?

It could be that the downstream IED has infact failed itself, or it could be that that the network has failed suddenly, or the comms port/link of the upstream subscribing IED has failed.

Firstly the upstream IED would already be in a BLOCK mode based on the first PTOC.Str=1 GOOSE.

We know that this means the downstream IED should be expected to operate and clear the fault in say 60 - 80 ms after the first PTOC.Str=1 message.

So it would seem reasonable that if a BLOCK state has been set for say 100 ms without the fault resetting as far as the upstream IED is concerned, then the upstream IED should cancel its block and allow itself to operate regardless of further GOOSE arrival or not.

Here is a scenario of an IED subscribing to four GOOSE from four different IEDs, with IED 2 suddenly going into a fast repetition mode.

As can be seen the heartbeat on each includes the timeAllowedToLive as 1000, hence the Subscribing IED can be set accordingly for each GOOSE.
Then as the IED2 goes into fast repetition, each repetition includes a different timeAllowedToLive according to the message number in that sequence

(click images to enlarge)

Contact Me

Email Me

A phone call is nearly always welcome depending on the time of night wherever I am in the world.
Based in Adelaide UTC +9:30 hours e.g.

April-September	Noon UK = 2030 Adelaide
October-March:	Noon UK = 2230 Adelaide

Mobile + 61 419 845 253

Extra Notes:

Disclaimer

No Liability:
Rod Hughes Consulting Pty Ltd accepts no direct nor consequential liability in any manner whatsoever to any party whosoever who may rely on or reference the information contained in these pages. Information contained in these pages is provided as general reference only without any specific relevance to any particular intended or actual reference to or use of this information. Any person or organisation making reference to or use of this information is at their sole responsibility under their own skill and judgement.
No Waiver, No Licence:
This page is protected by Copyright ©
Beyond referring to the web link of the material and whilst the information herein is accessible "via the web", Rod Hughes Consulting Pty Ltd grants no waiver of Copyright nor grants any licence to any extent to any party in relation to this information for use, copy, storing or redistribution of this material in any form in whole or in part without written consent of Rod Hughes Consulting Pty Ltd.

Browser not supported