Project

General

Profile

Issues #5326

sSBOes8 incorrectly requires addCause=blocked-by-mode

Added by Bruce Muschlitz about 2 years ago. Updated about 2 months ago.

Status:
Closed
Priority:
Normal
Assignee:
Richard Schimmel
Due date:
Discuss in Upcoming Meeting:
No
Clause Reference:
61850 Standard:
7-2
Triggering Tissue:
Final Decision:
See attachement
Initial Test Document:
Ed2Amd1 TP1.1 and Ed2 TP2.0.5
Updated Test Document:
Server Ed2.0 TP2.0.7 and Server Ed2.1...
Test Case ID:
Closed Reason:
--Not Set---
Triggering Tissue 2:
Triggering Tissue 3:

Description

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.

Files

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

Also available in: Atom PDF