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

Since there are inconsistencies in the standard (It says both that control should react exactly as if output wire was disconnected AND it shall act as if Beh=Off.
In the first case we get a timeout (after a delay) and in the second case we get a “blocked-by-mode” immediately) I propose to modify sCtl28 to allow both addcauses "blocked by mode" and "time-limit-over".

Expected result
1. DUT send Operate respond+ and CommandTermination- with AddCause “blocked-by-mode” without waiting for the operate timeout. When available, DUT sends the following data change reports: DO.opRcvd=TRUE, DO.opRcvd=FALSE, DO.opOk=TRUE with updated DO.tOpOK, DO.opOK=FALSE with updated DO.tOpOK
2. DUT send SelectWithValue respond+
3. DUT send Operate respond+ and CommandTermination- with AddCause “blocked-by-mode” without waiting for the operate timeout [b]or with Addcause "time-limit-over" after operate timeout[/b]. When available, DUT sends the following data change reports: DO.opRcvd=TRUE, DO.opRcvd=FALSE, DO.opOk=TRUE with updated DO.tOpOK, DO.opOK=FALSE with updated DO.tOpOK
4. DUT send Operate respond+. When available, DUT sends the following data change reports: DO.opRcvd=TRUE, DO.opRcvd=FALSE, DO.opOk=TRUE with updated DO.tOpOK, DO.opOK=FALSE with updated DO.tOpOK
5. DUT send Select respond+
6. DUT send Operate respond+. When available, DUT sends the following data change reports: DO.opRcvd=TRUE, DO.opRcvd=FALSE, DO.opOk=TRUE with updated DO.tOpOK, DO.opOK=FALSE with updated DO.tOpOK
Test description
When the control object has [OR] attributes configure and enable a report control block with a dataset with DO.[OR]

b) DOes
Force LN.Beh = test-blocked (when supported)
1. Client request Operate with test=TRUE and a valid control value

d) SBOes
Force LN.Beh = test-blocked (when supported)
2. Client request valid SelectWithValue with test=TRUE and a valid control value
3. Client request Operate with test=TRUE

When the control object has [OR] attributes continue with:
a) DOns
Force LN.Beh = test-blocked (when supported)
4. Client request Operate with test=TRUE and a valid control value

c) SBOns
Force LN.Beh = test-blocked (when supported)
5. Client request valid Select
6. Client request Operate with test=TRUE and a valid control value
Comment
Note: TISSUE 1652 was not green when this documentt was published, so Mod=blocked is not tested

I don't understand the analysis from Gerhard.
The issue is (as mentioned by Gunnar): the Beh Blocked, Test-bLocked applies to wired output. Therefore it cannot apply to the DataObject CSWI.Pos - which is NOT wired-output: XCBR.Pos is wired-output.
When CSWI.Beh is Blocked, or Test-Blocked,
- there need to be a conisderation of the communication to XCBR, and of the XCBR.Beh.#
- if XCBR.Beh = Test, then the wired-output of XCBR will be activated.
- if XCBR.Beh = Test-BLocked, then the wired-output of XCBR will NOT be activated.
In both case, the XCBR returns XCBR.Pos.opRcvd, opOk to the CSWI so that the CSWI.Pos tate machines further transits.
This is the same issue as for sCtl29. As long as the XCBR.Pos returns channel is not exposed in the test procedures, the test can not be done.
This is a functional testing.
The state machine of 7-2 with regards to BEh= Blocked. Test-Blocked would apply to a CSWI.DataObject that is wired-output.

TPWG: sCtl28 should specify that the control object has an wired output. In case the control object is not wired, addcause 'time-limit-over" is. For example: CSWI.Pos and XCBR.Pos in another device. Here CSWI.Pos has no wired output.

Proposal is to focus sCtl28 on FC=OR and ignore/remove the expected result CmdTrm/Addcauses.

I don'T understand why there is a difference
1) and 3)
to
5) and 7)

I propose to have
1), 3), 5) and 7)
• Operate is accepted, DUT sends reports/GOOSE with OpRcvd=T and then OpRcvd=F and opOk=T with updated tOpOK
• DUT send report/GOOSE with opOk=F

To what extend is the order of the reports important in step 1), 3), 5) and 7)? (in Thierry's proposal):

• Operate is accepted, DUT sends reports/GOOSE with OpRcvd=T and then OpRcvd=F and opOk=T with updated tOpOK
• DUT send report/GOOSE with opOk=F

It is evidently that the report with opOk=T will come after OpRcvd=T. But how about the order of opOK=F and opRcvd=F?

A proposal for an expected result would be:

• Operate is accepted, DUT sends reports/GOOSE with OpRcvd=T , opRcvd=F, opOk=T and opOk=F with updated tOpOK.
The report with opOk=T is sent after opRcvd=T.

“I agree with Thierry’s proposal in #6 that the result should be the same in the different cases (1, 3, 5 and 7)

If all tests are OK the states “PerformTest” and WaitForExecution” are passed direct and the sequence will wait in the state “WaitForChange”.
This means that events
opRcvd = True
opRcvd = False
opOk = True
will come at the same time.
This can be a problem for opRcvd since it will only be a short pulse
E.g. in the case when these signals are transferred over GOOSE, one lost message will result in that the receiver is not aware of the pulse. Also if the GOOSE inputs are use in a cyclic application it is a big risk that the pulse is lost.
So we should allow for a pulse extension of the opRcvd, without delaying the command execution, this can lead to the following or sequences:
opRcvd = True
opOk = True
opRcvd = False
opOk = False
or
opRcvd = True
opOk = True
opOk = False
opRcvd = False

So I also agree with Gerard’s proposal in #8 #9 that the order of opRcvd=False and opOk is not important

One other aspect is that the opRcvd = False has no important time aspect.”

Richard Schimmel wrote in #note-11:

Processed the comments in a new attachment (copied the Bruce version)
- merged expected result 1+3 with 5+7
- be less strict on the order

The expected result is now:
1), 3), 5) and 7)
• Operate is accepted, DUT sends reports/GOOSE with OpRcvd=T, OpRcvd=F, opOk=T and opOk=F

I agree with the proposed solution.

Richard Schimmel wrote in #note-11:

Processed the comments in a new attachment (copied the Bruce version)
- merged expected result 1+3 with 5+7
- be less strict on the order

The expected result is now:
1), 3), 5) and 7)
• Operate is accepted, DUT sends reports/GOOSE with OpRcvd=T, OpRcvd=F, opOk=T and opOk=F

I agree with the proposed solution.

Proposed solution needs update:
1. Abstract test sCtl28 does not match proposed test. Need to propose new text for abstract text.
2. Conditon for sCtl28 seems wrong. It should be required if any fc=OR exist in the data model
3. 61850-7-3 is unclear if opRcvd needs to activate when control.test is opposite of the expected value. Maybe want to delete all even-numbered steps in all 4 sCtl28 tests

TPWG: we agree with Bruce that standard (tissue 1696) is not clear on control.test handling, better remove now and may add later when clarified
Richard will fix the attachment