CIM Issues #6549
Switch Contention Issue
61968-3, 61968-5, 61968-9
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
Updated by David Haynes 6 months ago
David Haynes wrote:
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. Instead of a simple lockout, should there be a prioritization scheme for each relay? Should this be extended to other assets?This issue is related to Issue #6542 because a switch can be a member of multiple groups, DER Groups, metering groups, etc. Even if a CIS specifically called out a particular switch by name (mrID) one or more groups, invoked by various stakeholders, could also issue control commands to the switch, which commands should be followed, and should the switch be stateful or stateless?
Should this be a coordination between parts? Should a new part or TR be created just for this subject?