Project

General

Profile

CIM Issues #6549

Switch Contention Issue

Added by David Haynes about 1 year ago. Updated 9 months ago.

Status:
New
Priority:
High
Author/Contact Info:
dhaynes@hubbell.com
Base Release:
Solution to be Applied To:
Solution Version:
Solution Applied By:
Completion Date:
CIM Keywords:
61968-LoadControl, 61968-Metering, 61968-Operations, 61970-SCADA
Breaking Change:
Breaking Change Description:
CIM Impacted Groups:
WG14
Requestor:
David Haynes
Standard(s):

61968-3, 61968-5, 61968-9

Version:
Part 9 ed 4
Clause:
Sub-Clause:
Paragraph:
Table:
Originally Closed in Version:
Origination Date:
10/24/2023
Origination ID:
Originally Assigned To:

Description

There are many relays controlling many loads. Sometimes these assets can be switched on or off for different reasons. While working on lines, it is a common practice to employ "lock out / tag out" procedures. In this scenario, the workman physically places a padlock on a switch to prevent its movement. Then, at the end of the job the workman physically removes his padlock to restore normal operation of the switch. While the safety issue is nicely handled by the physical locks, an operational issue still remains. What if a CIS declares that a particular RCD switch inside of a revenue meter is to be opened due to non-payment. Then what if this same switch is made available to the DERMS for load control purposes? A DR system might (even as part of a group) ask that the switch participate in a load shed, then upon completion, that the switch be closed in. What is the switch to do? How would it know to revert to an open position? What if that is obsolete information? What are the expectations for the AMI network / load control system? Should there be a "system of record" that is the official keeper of allowable switching activity? Should there be the means for a back office system to effectively place a "lock" on a switch position and prevent other back office systems from operating it? Can multiple systems place locks similar to the physical lockout/tagout mechanism described above? Or rather, should there be a "list"? Should there be a "do not open" list and a "do not close" list? (Someone might be on life support, someone may have moved out, etc.)
Meters con not only have a big 200A disconnect, they might have a number of small relays designed to control individual loads like irrigation pumps, or anything else the utility wires them to.
There are also specialized switches the AMI network might control -- usually installed beneath a given revenue meter -- to control smaller loads within a home. Should these be lockable too?
We can't have multiple systems fighting over the switch position. We need a switch management plan.

This issue is related to Issue #6542.

For discussion purposes, we think the scope of this issue is limited to switches that are not on the feeder that a lineman could interact with. These switches are covered by Part 3. But there are switches that are otherwise safe to operate that are in scope.


Proposed Solution

1) One approach is to modify Part 9 so that a "lock closed" command and "locked closed" statuses are available to the user. If the meter itself will lock a switch open or closed, the issue goes away. The meter will ignore DER commands to open the switch. If this alone is the solution, then every switch everywhere must have this capability.
2) A software solution can be built that uses the SwitchPlan, SwitchOperation, and TagOperation elements from Part 3 to model a switch manager for use by parts 5 and 9.
3.) Whatever is implemented should utilize WG15's IEC 62351-8 Role Based Access Control recommendations. A role should be created that has rights to open and close a switch. Another role should be created that has the rights to open, lock open, close, lock closed, unlock, and unlock close the switch. Only one application in the utility back office should have the switch owner role and have the right to lock the switch. All others are limited to open/close commands.


Related issues

Related to WG14 Part 9 Issues - CIM Issues #6542: Group ManagementNewActions

Also available in: Atom PDF