In accordance with Ed.2.0 Tissue #1377, Ed.2.1 states on 'Check':
In case that the addressed function respective data object does not support these checks, the appropriate check bits shall be ignored and the command be handled.
The statement "does not support these checks" requires refinement.
The statement rules how to behave in the case of a non-alignment between a control command asking for checking and a device not supporting the check. The defined behaviour is very valid in the case of not matching configuration or misssing device capability. A control command would never be executed.
This Tissue is to ask for a confirmation that the statement is to be understood as mentioned, and not:
If a function is configured in an IED, matching with the check bit configuration in the client, but for a root cause out of the process the function does not support the check (example: VT fuse blown - no synchrocheck possible).
In such cases a control command should be rejected.
Proposal
Propose to change the statement "does not support these checks" to
"does not support these checks due to missing device capability or configuration"
Discussion
Created
Status
Move to solution accepted.
See draft implementation in attached document.
Analysis of the compatibility:
Certified Servers were always allowed to correlate the CheckConditions service parameters with the known current operative configuration. See sCtl7 + PIXIT Ct8.
Certified Clients were allowed (per PIXIT Ctl5) to never set the CheckConditions service parameters. This operation needs to change in future, as the tissue resolution requests that "Clients shall provide a means so that the check conditions are appropriately set". There is no new compatibility issue than there was in the past with the described server behavior (client that could not set the CheckConditions bits were not interoperable with servers that were checking them against the current operative configuration). The proposed draft is increasing the interoperability.
Note: The visibility of the current operative configuration is a local issue. Future standardization activities will define a standardized model.
24 Jan 23
Solution Accepted
no changes to verify
29 Nov 22
Ballot Period
No test plan changes.
29 Nov 22
Conformance Test Verification
https://redmine.ucaiug.org/issues/5319
TP supports the resolution of this tissue as written for interlock but may need editorial update to reference synchrocheck. TP server PIXIT ct8
01 Nov 22
Conformance Test Preparation
Ready for conformance test preparation.
11 Oct 22
Conformance Test Preparation
See draft implementation in attached document.
Analysis of the compatibility:
Certified Servers were always allowed to correlate the CheckConditions service parameters with the known current operative configuration. See sCtl7 + PIXIT Ct8.
Certified Clients were allowed (per PIXIT Ctl5) to never set the CheckConditions service parameters. This operation needs to change in future, as the tissue resolution requests that "Clients shall provide a means so that the check conditions are appropriately set". There is no new compatibility issue than there was in the past with the described server behavior (client that could not set the CheckConditions bits were not interoperable with servers that were checking them against the current operative configuration). The proposed draft is increasing the interoperability.
Note: The visibility of the current operative configuration is a local issue. Future standardization activities will define a standardized model.