Test Procedure Working Groups » IEC 61850 TPWG » Test Procedure Issues » Server

I would recommend then to use SPC[ST], with an SPC that contains constructed DA origin.

I assume if a device does not support INS it also won't support SPC origin. Test procedure is not clear to use FCD or FCDA. Typically GOOSE should use FCDA. We should clarify FCDA/FCD. There is a copy/paste error in the expected result step 4 integer should be boolean.

Solution in "Solution to redmine sGos9 748.docx" is unacceptable because boolean is encoded exactly the same way for both "fixed" and "normal" GOOSE.
If the purpose of the test is to verify that a payload (AllData) encoded with fixed length is correctly processed then the proposed test will not verify this.
If the purpose is to verify that GOOSE header (non-payload) data can be encoded with fixed length then we do not need to specify the contents at all.
If a subscriber can only subscribe to "fixed" messages which contain the same payload encoding as "normal" GOOSE then it seems that this device cannot demonstrate the test requirement "Subscribe GOOSE message with “fixed length” GOOSE".

We can discuss within the TPWG whether a device which ONLY demonstrates tolerance to header data with fixed length should be deemed compliant to the standard.

I understand the concern. Some devices only subscribe to boolean values, such devices should/shall be able to ignore other types. That's why the SERVER SIMULATOR should send both boolean and integer. A device supporting integer does process the integer, if not the integer is ignored and device does process the boolean.

The proposed test procedure is not clear that if only boolean is supported then the publisher still sends both boolean and integer.
But if the subscriber merely ignores the integer then it really has not shown it can "subscribe" to a "fixed length" GOOSE.
I propose to make sGos9 conditional on PIXIT Gs8 declaring something that differs in "fixed GOOSE" compared to "normal GOOSE".
We can work out what would be in that "differs" list.

I do not undestand the answer from Richard:
"I assume if a device does not support INS it also won't support SPC origin. Test procedure is not clear to use FCD or FCDA. Typically GOOSE should use FCDA. We should clarify FCDA/FCD. There is a copy/paste error in the expected result step 4 integer should be boolean."

Subscription of FCD is mandated per standard / tes tprocedures. We can not make it conditional: subscribed only FCD when no integer present.
As mentioned later in the discussion: the key thing for a subscriber is to ignore what it does not support.
We can not certify a subscriber that is saying: Support SPC, but not as FCD when SPC contains DA origin. This is otherwise a nightmare for configuration - and will lead to major interop problems when such subscribers are certified compliant to the standard.

Agree with Thierry - we should not certify a device that does not support INS or integer.