There is often much confusion about GOOSE messages being seen as a commands. Yes, they are interpreted by the subscriber as information which will be used to carry out a certain action - but they are really just a STATUS of an output of a Logical Node - "I have not operated" / "I have operated". One output status can be interpreted in multiple ways: click image to enlarge 
Hence it is not good to use GOOSE as the means for an HMI to send a command to an IED Consider an operator wanting to set Autoreclose on Feeder 3 of from On to Off
For "years" the HMI would have to be sending a message once per second as containing the "status" of the buttons on the HMI screen as - Operator A/R button Fdr1 Pressed On and latched
- Operator A/R button Fdr 2 Pressed On and latched
- Operator A/R button Fdr 3 Pressed On and latched
- Operator A/R button Fdr 4 Pressed On and latched
- ..... repeat all that every second
Then when the operator suddenly clicks Fdr3 to Off the message changes and stays repeating again as - Operator A/R button Fdr1 Pressed On and latched
- Operator A/R button Fdr 2 Pressed On and latched
- Operator A/R button Fdr 3 Pressed OFF and latched
- Operator A/R button Fdr 4 Pressed On and latched
- ..... repeat all that every second
It is of course "possible" for the HMI to have the capability and capacity do all that but totally unnecessary repetitive communication messages compared to MMS" - If Fdr 3 reported status is On
- and Operator button Fdr 3 is pressed to OFF
- Send command to Fdr 3 to change status
- Wait for report from Fdr 3 that status has changed to OFF
The question is how does the HMI know the A/R on Fdr 3 is On or Off?
Fdr 3 could be configured to use GOOSE repetitively sending the status GOOSE as If that status is specifically NEEDED to be published by the IED, then the HMI COULD subscribe to the same GOOSE, but that means it has to subscribe to a LOT of different GOOSE. However the IED A/R On/Off status is not likely to change status "randomly" at any point in time without operator intervention (compared to protection functions change "randomly" without operator intervention).
So we simply configure a Server REPORT triggered by a status change to tell the Client of the change.
That is a ONE TIME message - not repeated every second.
Using BUFFERED Reports means we can ensure the Client knows of any status change - or at least can catch up if the comms has been down for any reason. So what is a GOOSE? Imagine you have three "things" that can be either on or off, operated or not operated, closed or open. They are each represented by a 1 or a 0 bit accordingly. So put those 3 bits into a group and call it a dataset.
101 would indicate the 1st status is "on", the second is "not operated" and the third is "closed" You could have a dataset as a single bit or a large number of bits - depends on whether the vendor has preconfigured the datasets, whether the vendor has provided the ability for the System Integrator to decide at the engineering stage, or whether the vendor has provided the ability for datasets to be created dynamically during a say a special test sequence. Now just keep sending that 3-bit dataset repetitively on the network every , say, 1 second. You could choose a different continuous repeat cycle if you wish but in general lets assume a 1-second heartbeat. That heartbeat helps prove the whole system is working end to end. Note that in publishing that 101 dataset it is just sent out on the network without any knowledge of any device or function using any part of the dataset - the publisher role is to send the message without necessarily knowing if any other device is listening or using the message content. Any device could subscribe to that dataset and use that information for whatever function that device has inside. On the basis that the first bit is 1, the subscribing function might turn something else on or off or use that as one input to another complex function or algorithm in some way. Now suppose the first 'thing' changes from on to off, i.e. the bit changes from 1 to 0.
Instantly - regardless of the 1-second heartbeat timing, the publisher sends the revised dataset which is now 001. The publisher then repeats the 001 data set 1 millisecond later, then it repeats it again 2 ms after that, then 4 ms after that, then 8 ms after that until it gets back to a 1-second repeat cycle. That fast repetition rate is also settable. Hence on the basis of a protection function changing from "not operated" to "operated" you would expect the receiving circuit breaker interface to open the breaker whilst the autoreclose and circuit breaker fail functions to start their operation cycles. So you can see that the GOOSE is not a command. It is a status of a function being reported on the network. What the subscriber does on the basis of that is up to the subscriber. The E in GOOSE stands for "Event", not C for Command!! Its like a fire alarm - when its off (its status is repeatedly "not operating") you stay in the building but a fireman would stay out - when its on (ringing) you would leave the building but the fireman would enter the building. One final aspect is that I have used a 'binary status' as the "thing" in the dataset - it could also be an analog value - when it changes to another value that is also an "event" but obviously needs some hysteresis/deadband handling I hope that helps in understanding GOOSE. With that understanding the next question is whether GOOSE can suddenly flood the network: https://ideology.atlassian.net/wiki/x/bgFv |