Project

General

Profile

Issues #5293

IEC 61850 Certificate

Added by Dustin Tessier about 2 years ago. Updated almost 2 years ago.

Status:
Closed
Priority:
Normal
Due date:
02/11/2022
Discuss in Upcoming Meeting:
No
Clause Reference:
61850 Standard:
Triggering Tissue:
Final Decision:
Initial Test Document:
Updated Test Document:
Test Case ID:
Closed Reason:
Test Procedure Update
Triggering Tissue 2:
Triggering Tissue 3:

Description

Propose adding the maximum number of CT/VT channels on the UCA certificate that was tested using the preferred variant for protection (F4800S2I#U#) and/or PQ variant (F14400S6I#U#). The certificate would then state the preferred variant(s) with the max number of CT/VT channels.


Related issues

Related to Server - Issues #5308: SV Publisher/subscriber maximum dataset size is untestedClosedActions
#1

Updated by Bruce Muschlitz about 2 years ago

Some questions:
1. Do we add this for every FxxxxSy variant declared in LPHD.NamVariant or just some of them?
2. What if the vendor declares I0-24U0-24? Does the tester test 48 channels or some combination of I and U channels summing to a max of < 24?
3. How do we ensure repeatability of information on the certificate? I.e. what algorithm is applied so that every tester tests the same dataset?

#2

Updated by Dustin Tessier about 2 years ago

Some answers:
1. Do we add this for every FxxxxSy variant declared in LPHD.NamVariant or just some of them? DT: Yes, preferably we add this for every variant, but it sounds like it would be too expensive for vendors/test labs to validate the max number of CT/VT channels for each variant. As a compromise, we propose to specify the max number of CT/VT channels for the preferred variants (F4800S2 and F14400S6)
2. What if the vendor declares I0-24U0-24? Does the tester test 48 channels or some combination of I and U channels summing to a max of < 24? DT: No, do not sum the two. Treat the max number of CT and VT channels separately, since the namVariant treat them separately and that is what is being validated by test labs
3. How do we ensure repeatability of information on the certificate? I.e. what algorithm is applied so that every tester tests the same dataset? DT: The allocation of the CT/VT channels to dataset(s) is outside the scope of this question. Agreed, it would be good for vendors to declare the number of dataset(s)/control block(s), which the maximum number of CT/VT channels can be allocated to. Propoose this be added to PIXIT

#3

Updated by Bruce Muschlitz about 2 years ago

Proposal is in https://redmine.ucaiug.org/issues/5308 , summary is:
1. Add PIXIT entry to indicate maximum number of channels for each supported preferred frequency/numOfASDU combinations
2. Change existing test for random dataset used by each rate to maximum dataset (include all possible current channels then fill with voltage channels up to PIXIT-specified maximum
3. Add conditional test to verify step 2 above except with maximum number of voltage channel and fill-in with current channels (conditional upon whether this dataset would differ from step 2 dataset)
4. Record in report and on certificate the tested variants.

For example, if the PIXIT indicates maximum of 26 channels in a dataset but declares in ICD/IID file:
<DOType id="NamVariant" cdc="VSD">
<DA name="val" bType="VisString255" fc="DC">
<Val>F4800S1I4U4;F14400S6I4U4;F4800S2I0-24U0-24;F14400S6I0-6U0-6</Val>

Then the certificate could state: F4800S1I4U4;F14400S6I4U4;F4800S2 I24 U2;F4800S2 I2 U24;F14400S6I6U6 (note that spaces added here for clarity)

Similar test would be added to sample-value-subscriber tests

#4

Updated by Herbert Falk about 2 years ago

  • Related to Issues #5308: SV Publisher/subscriber maximum dataset size is untested added
#5

Updated by Thierry Dufaure almost 2 years ago

the current certificate extensions related to sv publisher / subscriber in the certificate data base are not clear, and not corresponding to the tested variants.
Proposal:
1) Remove the new attributes/properties
2) clarify the required extension based on released 1.1 testing procedures
3) review content of impacted ceritficates with testing labs,
4) expose the extended values.

#6

Updated by Thierry Dufaure almost 2 years ago

Propose to change
"SV Nominal Frequencies" to "SV Nominal Frequencies Tested"
The field shall contain the nominal frequencies used during the 11a, 11b tests. Example F4800.

"SV Sampling Rate"
The field is not needed as the "Variant Tested" already includes the sampling rate Fx.

The field "SV 61869-9 Variant Tested:" shall contain the list of tested variants: Publisher FxSyIaUb(nominal frequency) Subscriber FxSyIaUb(nominal frequency)

#7

Updated by Bruce Muschlitz almost 2 years ago

1. Nominal frequencies: If you list every F&S then the nominal frequency field will be redundant and of no use.
2. other 2 fields: Each of the existing SV fields in the Redmine database contain a drop-down list which results in searchable content.
If you change "SV 61869-9 Variant Tested:" as suggested then it will not be searchable and the database will lose value.
That is why I previously suggested splitting the publisher and subscriber fields and also listing ONLY F&S in some fields (thus searchable) and then having a (new) free-form field to show F&S together with I&U which would NOT be searchable.

#8

Updated by Bruce Muschlitz almost 2 years ago

  • Project changed from Test Procedure Issues to Server
  • Status changed from New to Closed
  • Discuss in Upcoming Meeting set to No
  • Updated Test Document set to Server Ed2.1 TP1.2
  • Closed Reason Test Procedure Update added

Also available in: Atom PDF