Issues #5961

sCtl16 shall specify LocSta/MltLev to match with table B.1

Added by Richard Schimmel over 1 year ago. Updated about 2 months ago.

Due date:
Discuss in Upcoming Meeting:
Clause Reference:
Table B.1
61850 Standard:
Triggering Tissue:
Final Decision:
Initial Test Document:
Updated Test Document:
Test Case ID:
Closed Reason:
--Not Set---
Triggering Tissue 2:
Triggering Tissue 3:


1) Table B.1 is very clear how a device shall respond in case for all combinations of XCBR.Loc + CSWI.Loc+ CSWI.LocSta + LLN0.MltLev and orCat=Bay/Station/Remote. sCtl16 does not specify LocSta and MltLev and as such the expected result can be wrong. For example SBOes step 3 expect response+ this requires LocSta=T! What if LocSta is not present?

2) What is the default value for LocSta when it's not present in the datamodel? I assume LocSta=False then the expected result for step 3 is wrong.

3) Because table B.1 is very specific, why do we have a PIXIT entry for SBOes step 6?

Let's discuss at TPWG



Updated by IEC 61850 TPWG over 1 year ago

  • Due date set to 10/18/2022
  • Status changed from New to In Progress
  • Assignee set to Richard Schimmel

Richard to propose changes


Updated by Thierry Dufaure over 1 year ago

1) If LocSta is not present then the device does not make a different between remote and station operation. LocSta has been introduced to enhance the switching hierarchy by differentiating operationa originated in the station from operations orignated in the control center.

2) There is no default value for LocSta - if it is not present, operation from station and remote are treated the same - with regard to the Loc switching hierarchy.

3) Ct29 is needed, because usage of 1 (bay-control), 4 (automatic-bay) can be verified and limited by the implementaton: Local HMI (1) is done locally not over communication, Automatic bay (4) - Logic is done locally not over communication.

When XCBR/XSWI.Loc is true, then even CSWI can not operate the switching equipment. Since sCtl16 is using CSWI for switcing operation, then sCtl16 can only be performed with XCBR/XSWI.Loc = false


Updated by Richard Schimmel over 1 year ago

Updated attachment based on feedback thierry; added precondition LocSta=F when supported and changed orCat from 2 to 3 for SBOes.


Updated by Thierry Dufaure over 1 year ago

Comments related to 5961 sCtl16 with LocSta (18oct).docx

What I don’t understand, is why are you expecting
- b3 to succeed while Xxxx.Loc = true? Select could also already fail
- d3, and d5 to succeed for orCat=remote while LocSta = false? SelectWithValue could also already fail

Actually, as soon as Xxxx.Loc = true, then Select can fail.

What happens if Xxxx.Loc = true is not achievable? The test is starting with Xxxx.Loc = true when supported, other wise with Xxxxx.Loc = false when supported.
How about starting the tests with Xxxx.Loc = false, and later: if supported set it to true.
I suppose Xxxx.Loc = false is always supported, while = true may not be.


Updated by IEC 61850 TPWG over 1 year ago

  • Due date changed from 10/18/2022 to 11/01/2022

Richard to update per TPWG discussion:

replace DUT by XCBR and CSWI

Move "if supported" from test description to requirement condition


Updated by Thierry Dufaure over 1 year ago

The test applies as soon as CSWI.Pos is availalbe AND the device implements a local remote switching hierachy.
-> CSWI.Loc is available and show the local status of the control switch.

Therefore, I recommend to remove any LLN0 cnosideratio from the test description, because CSWI.Loc vs Control(service parameter orCat) is what is currently being tested.


Updated by Richard Schimmel over 1 year ago

processed the comments: remove LLN0, move CSWI "if supported" to table A.4.2;


Updated by IEC 61850 TPWG over 1 year ago

  • Due date changed from 11/01/2022 to 11/29/2022
  • Assignee changed from Richard Schimmel to Thierry Dufaure

Richard concerned about focus on CSWI when the LocSta applies to any LN.

CSWI is common use case, perhaps state this is example use case and the test could be used in any LN.

Perhaps split to two test cases - CSWI/XCBR in separate devices and Local general test

Discuss further with Thierry.


Updated by Thierry Dufaure over 1 year ago

ad discussed during last call, XCBR/XSWI.Loc = false will always be supported, as soon as the X node is implemented. when X.Loc = false, then control be possible. Potentialy orCat 1.4 can be refused, if the DUT knows that 1,4 cannot occur over communication.
Being able to set X.Loc to true, is the case that may not be possible. Neverthess, when X.Loc is true, then there is NO control operation possible at all. Regardless of the orCat value.
I recommend to rewrite the procedure, starting with X.Loc = false. The last step in the procedure should be: set X.Loc to true when supported, and control. Verify that no control is possible.

The test case 16 is independant of LocSta and MtlLel - because the test is verify that as soon as CSWI.Loc is set, then no control is possible from any level. However, additional step could be added : redo the test with LocSta = false.


Updated by IEC 61850 TPWG over 1 year ago

  • Due date changed from 11/29/2022 to 12/13/2022

From M.Haecker:

In step 1 the IED is set to <LN>.Loc=False and <LN>.LocSta=True , to allow operation from station level, not from control center level.
The control in step 2 “orCat=station” matches the operational configuration and therefore the response is positive.
The control in step 3 “orCat=remote” does not match the operational configuration and therefore the response is rejected.

No issue.

In the test description we state “changes the DUT to “Local”; (LLN0.Loc=True or CSWI.Loc=True) and XCBR/XSWI.Loc=True” which is unlucky.
We should have left away the last “XCBR/XSWI.Loc=True” for we execute our tests on controller level, not on process level.
If XCBR/XSWI.Loc=True , then the switchgear proxy will not accept any control via protocol. The switchgear is on manual control then.

I propose to change the test description to “Test engineer changes the DUT to “Local”; (LLN0.Loc=True or CSWI.Loc=True)”
This is a general statement, nothing to do with the discussion at hand.

a) DOns
Upon all the controls on step1 the controller will accept only orCat=1 or orCat=4, but the XCBR/XSWI proxy will reject all.
Step2 sets XCBR/XSWI proxy to “remote” i.e. acceptance of controls from CSWI basically. CSWI will accept orCat 1 and 4.
Remote controls as per step3 are to be refused, if the L/R concept is supported.
b) SBOns
As above, once XCBR/XSWI.Loc are “true”, all controls will be rejected by the proxy.
Step2 sets DUT to “remote”.
Step3 will reject local controls (MltLev is not mentioned). The stated test result is wrong for orCat 1 and 4.
Step4 sets DUT to “local” (assume XCBR/XSWI are not affected – otherwise it makes no sense).
In Step5 the DUT will not be selected for orCat 1 and 4, all other orCat will be rejected.
The local controls of step6 will be accepted.
The remote controls of step7 will be rejected.

Thierry to rewrite testcase, with significant reorganization.


Updated by Thierry Dufaure over 1 year ago

Please find the test procedures, 1) split according to the control model, and 2) having additional steps for the select control model, changing CSWI.Loc from False to True after the Select succeeds.
Additionally, the test considers PIXIT entry Ct29 - i.e. are orCat 1, 4 allowed over communication or not.


Updated by Richard Schimmel over 1 year ago

I agree with the proposed changes in general. LocSta/Mltlev is tested in sCtl17. For sCtl16 we should only verify "LocSta=F or missing" and "MltLev=F or missing". According to table B.1 orCat=Station:NA and orCat=Remote:A. For orCat=Bay:PIXIT Ct29!

About SBOes expected result 9/11 it differentiate between LocSta/MltLev supported or not supported to send AddCause at SelectWithValue and Operate stage. Not sure if this is specified in the standard.

I only updated SBOes part in the 9dec


Updated by Thierry Dufaure over 1 year ago

I agree with Richard changes to sCtl16 SBOes of Dec 9.


Updated by Herbert Falk over 1 year ago

  • Status changed from In Progress to Resolved

Reviewed 12/13 and decided to mark resolved.


Updated by Richard Schimmel about 2 months ago

  • Status changed from Resolved to Closed
  • Updated Test Document set to TP1.3

Also available in: Atom PDF