Project

General

Profile

CIM Issues #6549

The need for relay management

Added by David Haynes 4 months ago. Updated 4 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.


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.


Related issues

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

Updated by David Haynes 4 months ago

#2

Updated by David Haynes 4 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?

#3

Updated by David Haynes 4 months ago

  • Proposed Solution updated (diff)

Also available in: Atom PDF