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

About the certificate I propose to add the SV publish and SV subscribe variants as part of the product details (below software/hardware version):
SV publish : F4000S1, F4800S1, F4800S2, F5760S1, F12800S8, F14400S6, F15360S8, F96000S1 (delete what is not supported)
SV subscribe: F4000S1, F4800S1, F4800S2, F5760S1, F12800S8, F14400S6, F15360S8, F96000S1 (delete what is not supported)
As such end-users can easily select/check a matching rate.

testing all combination is against the decision of the random configuration chosen by the lab, and is increasing the effort and costs for certification.
I understood that conclusions are: document tested configuration variant on the certificate and not to test all combination.
What come next? test entire range of multicast address?

Resolution of this issue does NOT require testing "all combinations" but only those declared by the DUT to be interoperable with other devices meeting the standard.
Typical 61869-9 devices are expected to declare exactly 1 or legacy and preferred variants so this resolution simply requires that both legacy and preferred variants be tested.
Which of these 2 variants do you NOT want to test but still provide users with confidence that both legacy and preferred are functional?
I suppose we could test only 9-2LE variants and ASSUME (without testing) that the device can also support 61869-9 communications. Is this what you want?

There never was discussion of testing multicast addressing by the TPWG.
If such tests were proposed then all of the TPWG has the ability to argue for denial of such a request.
But let us please concentrate on one issue at a time and not worry about "possible future tests" in every Redmine discussion.

Typical 61869-9 devices are expected to declare exactly 1 or legacy and preferred variants

-> we ahould not limit the discussion to typical 1 variant - because if olny one variant is supported, the random test will pick that variant.
Flexible devices are here on concern.

"Repeat the test for all unique combinations of declared “F” and “S” values".

Let's take the example of a deivce declaring:
F4000S1I0-24U0-24;F4800S1-2I0-24U0-24;F14400S6I0-24U0-24;F12800S8I0-24U0-24;F15360S8I0-24U0-24;

This means 6 different tests are required with the new publihsher test approac only during the sSvp18!!!!
With the current pagreed and published test procedures
1) one backward compatible configuration is used: e.g eith F4000S1 or F4800S1
2) 1 prefered is tested: e.g FF4800S2
3) 1 max is tested: FxSy
4) 1 random is tested
-> 4 different configurations over 15 tests!
This is a major different.

I disagree with the resolution conclusion. I ask to repoen the discussion, as the TPCL 1.2 has not been published.

Sorry, there was a typo in the previous comment:
"Typical 61869-9 devices are expected to declare exactly 1 OF legacy and preferred variants"
The intent of this phrase was to demonstrate that exactly 2 tests would be needed for sSvp4.

Concerning the list of declared variants: "F4000S1I0-24U0-24;F4800S1-2I0-24U0-24;F14400S6I0-24U0-24;F12800S8I0-24U0-24;F15360S8I0-24U0-24"
most of these are not allowed by 61869-9. For both F4000S1 and F4800S1 and F12800S8 and F15360S8 , only I4U4 is allowed.
The count of tests is exactly 6 with 4 of those 6 having exactly the same test setup (only the DUT configuration changes).
For the other 2 tests, assuming the PIXIT-specified maximum channel count=24, there would be an additional 2 test setups (one with 24 current channels and the other with 24 voltage channels)

I also do not understand why the previous comment assumes that that 15 tests would be altered each to test every FxxxxSy combination because that was never proposed.

Proposed sSvp18 is requiring for this NamVariant of a flexible device: 6 tests, while the testing of sSvp1 to sSvp17 is already testing 3 of the variants:

1) one backward compatible configuration is used: e.g with F4000S1 or F4800S1
2) 1 random IEC 61869-9 preferred is tested: for instance F4800S2
3) 1 max is tested: FxSyInUm

The configurations 1) 2) and 3) are already chosen to have 3 combinations tested.

Any reconfiguration is increasing the effort and the cost of the type conformance test.
Limiting the sSvp18 to test the FxSy variants that were not already covered with sSvp1, sSvp17 - restricted to one of the I<z>U<r> used in previous test, could be a compromise to not increase the testing effort and cost dramatically.