Issues #659
sCtl7 allow that bypassing interlocking is "not-supported"
Description
The sCtl7 testcase requires that an IED allows to bypass the interlock check when the Operate.Check-Interlock bit is not set in the request. Several utilities consider this a safety issue and don't allow such bypass to be possible.
It's clearly defined in the standard to perform the Interlock check when Operate.Check.Interlock bit is set. It does not specify the device "shall" bypass the check when the check bit is not set. The proposal is to update sCtl7 to allow the bypass or not. When not the IED shall respond with AddCause "not-supported".
This proposal is agreed upon by Thierry, Joel, Gunnar and Richard.
Files
Updated by Bruce Muschlitz over 3 years ago
WG10 should review this to ensure that servers are allowed to ignore the check bypass.
In some systems, this might lead to big problems (for example, it might not allow a breaker to be closed even if the operator "knows" that the interlock indications are wrong.
Updated by Thierry Dufaure about 3 years ago
Bruce: this is not about ignoring the "do not check" flag.
The server is acknowledging that the bypass is not supported. Ignoring it would mean "don'T care what is inside".
Updated by Bruce Muschlitz about 3 years ago
- File Redmine sCtl7 proposal to allow bypass or not at step 2_20210504.docx Redmine sCtl7 proposal to allow bypass or not at step 2_20210504.docx added
- Status changed from In Progress to Resolved
Update solution per TPWG meeting 20210504
Updated by Bruce Muschlitz about 3 years ago
- Status changed from Resolved to Closed
- Updated Test Document set to ucatestproceduresserver61850-8-1ed2_rev2p0p5.pdf
- Closed Reason Test Procedure Update added
- Closed Reason deleted (
--Not Set---)