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
Accepted
17 Jun 25
Solution Accepted
Test procedures approved
13 May 25
Ballot Period
Test procedure available at https://redmine.ucaiug.org/issues/7100
07 Apr 25
Conformance Test Verification
This requirement was not explicitly stated previously and so may not be compatible with existing implementations. There is no backwards compatibility issue found with the standards.
There may be system interoperability problems during system testing if this TISSUE is not implemented.
21 Jan 25
Conformance Test Preparation
Proposed change:
Figure 42 (7.8.4) - change "incoming signal" to "input data".
Add to clause 7.8.4:
When transitioning Beh, all input data to the LN function must be re-evaluated (in terms of q.test).
LN shall consider the incoming signals that were received according to IEC 61850-7-4 Table A.2.
NOTE: changing the Beh may cause unintended operation! Verify inputs before changing Mod.
03 Dec 24
Verify Draft Implementation
Justification for the change, based on the application:
A function must be aware of relevant information, regardless of the time at which the information was created.
Once the mode of a function changes, the parameters determining the relevance will change, too.
The fact that there is a feature based on stNum to filter out repeated information shall have no impact here.
01 Nov 24
Drafting Implementation
The term data path should be avoided since it is used in a variety of other contexts and could be misleading. The wording should clearly indicate that the issue is specific to the LN.
Proposed change:
Add to clause 7.8.4
When LN.Beh transitions, the LN function must re-evaluate its inputs based on q.test and the new LN.Beh.
22 Oct 24
Drafting Implementation
The term "datapath" is used in this discussion.
I searched part 7-1 for it, but it does not seem to be used there.
Is this self-explanatory or elsewhere defined in a glossary?
15 Oct 24
Drafting Implementation
Proposed change:
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.
Add to clause 7.8.4:
When transitioning Mod, all incoming signal to the function must be re-evaluated (in terms of q.test) before Beh transitions.
15 Oct 24
Drafting Implementation
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.