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

First proposal for changing the introduction text - for both publisher and subscriber.
is drafted in the attached document.

Thierry proposes that test labs perform the test on "one random configuration". This is not possible because some test cases only apply to a backwards config and others only to a preferred config.
I propose that test labs perform "each applicable SV test case on a random configuration". Test labs shall at least use one backward and one preferred config.
I agree that for sSvp1 (delay) shall be performed on the maximum config (in order of priority): maximum size of the dataset, maximum number of samples, maximum size of svID.

As it may be easier first to expose my proposal in a table way before going to the text modification, I attach the table as well.
I am not advocating to "execute 2 tests (1 legacy and 1 preferred)."
I am advocating that the supported NamVariant shall expose at least: 1 legacy and 1 preferred
For the publisher test: only sSvp3, sSvp5 is about ramdon and legacy.
sSvp10 and sSvp13 about legacy; the other random.
We do not need to verify all combination, as we do not do it either for other transport mechanism:report, goose.

As it may be easier first to expose my proposal in a table way before going to the text modification, I attach the table as well.
I am not advocating to "execute 2 tests (1 legacy and 1 preferred)."
I am advocating that the supported NamVariant shall expose at least: 1 legacy and 1 preferred
For the publisher test: only sSvp3, sSvp5 is about ramdon and legacy.
sSvp10 and sSvp13 about legacy; the other random.
We do not need to verify all combination, as we do not do it either for other transport mechanism:report, goose.

Thierry and Bruce reviewed the proposed solution and had a few comments that have no impact on the solution

I (Richard) used the word “configuration” to indicate “one MSVCB”. So a random or maximum configuration is still one MSVCB.
That a DUT does support multiple MSVCB’s is really nice but not relevant for the SV test procedures. A DUT that supports only one MSVCB can still pass the test, requiring a lot of device reconfigurations. So yes I agree with: The test sSvp3 can be performed with 1 device configuration that includes 1) a MSVCB with backward config AND 2) a MSVCB with preferred config

About:
1. Text does NOT explain which tests to run (It says only that 2 configurations need to be supported) ThD: yes it does in the test itself.

Agree with ThD, no change

2. I (bruce) do not understand what you mean by “default configuration” ThD: The configuration exposed by the ICT when nothing has been re-configured

Richard: OK in the beginning I specified the test lab shall change the values

3. I think if SmvSettings is “fix” then even the ICT cannot change it. Maybe you mean “conf” and valImport=false (or missing?) ThD: Richard is correct. There is no valImport at services

Richard: no change required (when “fix” the SCT can’t change it, that’s it)

4. Why test a random configuration and not just the “maximum configuration”. Specifically, if the “random configuration” is the minimum then test for delay time is meaningless. ThD: I think we need to differentiate between device configuration and control block configuration. The maximum device configuration when it includes a backward and a preferred configuration is sufficient for the test.

Richard: see above the maximum (MSVCB) configuration is also a random (MSVCB) configuration. It’s up to the test lab and vendor to optimize the DEVICE configuration. No change

5. sSvp13 needs to run with a “less than maximum configuration”. It is clear to me that at least 2x preferred and 2x legacy rates will be needed for this test suite (1 each for sSvp13 and 1 each for sSvp1. Maybe preferred variant testing can assume all channels are used, but I do not see anywhere that this is a 61869-9 requirement. ThD: sending none existing samples is only for devices that needs to send a 9-2LE formatted frame but have missing measurements – for instance no I or no U connected. Therefore, it is trying to send a 4I, 4U, without having them all available. This is a modern device that could send 4I but was configured to send 4U as well. I agreed with Richard.

Richard: no change, indeed it’s an 9-2LE specific testcase. For preferred you simply remove the “invalid” datasetelements

I agree with Richard proposal from 19. Mai.
I am not sure it is necessary to perform sSvp14 for both random and preferred. A test with a configuration and different MsvID is sufficient – with either preferred or random.

TPWG: Stephan/Gunnar/Richard/Bruce/Herb agree to both the max and min MsvID in sSvp14. We disagree with Thierry's proposal to remove a part from sSvp14. We changed the minimum length Msvid from 4 to 1 char