I have a GOOSE subscriber and the entire device has Beh=On.
My subscriber is receiving a GOOSE message that has q.test on a data item set to true. Per 61850-7-4 Table A.2, my subscriber would process that data item as invalid.
I then change the Mode of a function in my subscriber to test, so Beh = test in the subscriber function. But because the message I’m subscribing to has not changed state (it was in test before I changed my mode) I am not going to process it, because I’ve already seen this state number and discarded it because I had Beh=on at the time. So, now I’m in test, but I have not processed the incoming test data because the GOOSE message has an already seen state number.
What is the expected behavior of a subscriber device upon changing the mode. Is it expected that the subscriber will process all GOOSE following its change in Mode? Or is it expected the subscriber will not process the data until there is a state change in the GOOSE?
Proposal
There needs to be clarity on whether the subscriber would continue to discard the GOOSE message because the state has not changed, or whether it should reprocess the data in the GOOSE message when the subscriber transitions to beh=test.
Discussion
Created
Status
First, this is a matter of when/how the function evaluates data and is independent of the communications layer.
When transitioning Mod, all incoming signal to the function must be re-evaluated (in terms of q.test) before Beh transitions.
Figure 42 (7.8.4) - change "incoming signal" to "input signal", with a note to explain that this is not referring to an event but to the datapath.
This is expected to cause significant implementation pain, so please review carefully!
27 Aug 24
Discussion (red)
GOOSE messages are used to transmit signals from a publisher to a subscriber.
The GOOSE stack in the subscriber delivers the received signals to the destination LN: i.e. the LN that has been configured using ExtRef to indicate that it has a biding from an external signal to an internal signal (internal signal represented by inAddr).
The GOOSE stack is agnostic of the Beh of the device and of the receiver LN; it does not need to know it. The same external signal can be subscribed per ExtRef to different LNs in the Subscribers. Each LN has an independent Beh, i.e. one can be in test, while the other is on.
Therefore this is not a responsibility of the GOOSE stack to "process as invalid" the received signals, but the individual LN.
The LN must maintain a copy of the received raw values and qualities in order to process the incoming signals properly later, for instance when the LN will transition from Off, to On: it will not retrigger the GOOSE stack to get actual values, it needs to have them available.
Therefore this is the same while transitioning from Off to Test, or from On to Test or especially from Test to On.
At a transition of an LN.Beh from Test to On, the LN shall consider the incoming signals that were received and shall proceed the q.test=true signals as invalid according to IEC 61850-7-4 Table A.2, and cannot continue to accept the value that was considered as valid while the LN was still in Test.
At a transition of an LN.Beh from On to Test, the LN shall consider the incoming signals that were received and shall proceed the q.test=true signals as if there were valid according to IEC 61850-7-4 Table A.2.
The same principles would apply also to signals received using Report. There will be no GI to get the actual values from the Server, but the local copy of the last received raw data + quality shall allow the receiver LN to consider the value again after a transition from the receiver LN from On to Test.