Issues #5326

sSBOes8 incorrectly requires addCause=blocked-by-mode

Added by Bruce Muschlitz over 1 year ago. Updated over 1 year ago.

Due date:
Discuss in Upcoming Meeting:
Clause Reference:
61850 Standard:
Triggering Tissue:
Final Decision:
See attachement
Initial Test Document:
Test Case ID:
Closed Reason:
--Not Set---
Triggering Tissue 2:
Triggering Tissue 3:


Resolution from TPWG meeting minutes 07-November-2017 was incorrectly transcribed to sSBOes8.
Meeting discussion was: “test” does not allow addcause “Blocked-by-mode”
Meeting resolution was: For “test” only, allow “Blocked-by-mode” add addcause
But this was transcribed as: for test only, require addCause=Blocked-by-mode

Background: sSBOes8 tests server response when there is a mismatch of parameters between the control select and control operate phases.
For most mismatches, it is obvious that the addCause should be Inconsistent-parameters
But one vendor argued that when control.test does not correspond with a correct Beh.stVal then the server could refuse because of for reason with the valid addCause=Blocked-by-mode.
The vendor further argued that nowhere does 61850 specify that mismatch of select/operate parameters check is performed before a mismatch of control.test/Beh.stVal.
The vendor then argued that if Beh.stVal == true and SelectWithValue.test=false and Operate.test=true then it is not incorrect for a server to use an addCause based upon Beh.stVal rather than the addCause based upon SelectWithValue.test.

This same issue appears in both Ed2.1 and Ed2.0 Server test procedures (sSBOes8 is identical in both procedures)

Attached new test shows additional words in BLUE text.


sSBOes8_20220321.docx sSBOes8_20220321.docx 15.1 KB Bruce Muschlitz, 03/21/2022 02:33 PM

Also available in: Atom PDF