CIM Issues #6529
Load Control Capabilities
61968-9
Description
The support for Demand Response is spread across numerous IEC standards and parts. Part 9 plays a role in supporting the RCD switch inside the meter, and exposing "meter controls" to load control systems. However, the precise ability to control a load, and the features offered by the meter (or relay) should really be in a publication somewhere. The device, upon installation, should be able to publish the controls the AMI system is willing to support and expose to other systems.
There are multiple issues to be addressed here:
1.)There is much to be said about the relay. How is it addressed? Specifically, which formulas are supported for autonomous operation. What happens when the switch opens autonomously? Will it reclose, can it be programmed to prompt the user to press a button to confirm closure? Is a duty cycle tolerated, or does the relay only participate in remote controlled curtailments? Knowing the name of the manufacturer and the model of device is not enough. Many products have firmware upgrades and firmware options. Not every feature is supported by the AMI system even when it is supported by the EndDevice itself. The AMI system, acting as load control provider, should be able to publish a description of each supported device that details the load under control, and the formulas it is willing to expose as inputs to another system. Each function (such as remote disconnect, direct load control, demand limiting period, emergency conservation period, prepayment, Under Frequency Load Shed, etc.) must not only have a name, but control parameters. The description should indicate the default value, the allowed min and max values of each parameter, and if the parameter is required. This type of control interface schema could have uses beyond load control. Many things need to be managed.
2.) The device might not be a revenue meter, but a relay that is part of a PAN. The installer should be able to provide notes that indicate the type of device being controlled, the voltage and current interrupted by the relay, and the wattage rating of the device under control.
3.) There should be a policy statement that certifies to the system throwing the switch, that it is certified safe to disconnect power. (There are no medical reasons present that would make it unsafe to terminate power.)
Proposed Solution
In order for an external system to issue proper "End Device Control" messages, it seems that the end device control system needs to publish more detail regarding what it is willing to expose for external control. We need more usecase capture (the CIS may want to impose one formula, and the EMS another). New schemas need to be developed that list each supported function in the device, and defines the operation of each parameter. It should perhaps also specify any relationship to an "endDeviceControl" operation, and the allowed range of each parameter.
Decision
The topic was discussed in the Part 9 team meeting on Sept 21, 2023.
Updated by David Haynes about 1 year ago
As an action item, if Part 9 is to serve as an interface for load control, some policy or legal statement should be crafted which will place the responsibility to throw the switch on the one who commanded it to open (or close).
We may also want to consider formal adoption of an electronic "lockout/tagout" mechanism. There should be a "list" of devices which are on a "do not open" list, and another on a "do not close" list. The Load Control System, or in some cases metering system, will not violate these lists.
The "lockout" mechanism can be implemented by the AMI network by checking these lists prior to any switching operation.
The "tagout" mechanism can be implemented by the AMI network by reporting any refusal to the requestor as well as publishing the event to any subscribers.