10.3 Demand Response and Load Control function set
10.3.1 Overview
This function set provides an interface for demand response and load control (DRLC). Client devices of this function set include thermostats and devices that support load control. Server devices of this function set include ESIs, premises energy management systems that may be acting as a proxy for upstream demand response/load control management systems, and subsequent data stores.
Servers expose load control events to client devices through resources called “EndDeviceControls” (EDC). EDC instances can expose attributes that allow devices to respond to events that are explicitly targeted at
specific kinds of devices. For example, an EDC may contain an Offset object indicating a degree offset to be applied by a smart thermostat. The EDC will also expose necessary attributes that load control client devices will need in order to process an event. These include Start Time and Duration, as well as an indication on the need for randomization of the start time or duration of the event.
10.3.2 List ordering
Table 38 —Demand Response and Load Control list ordering
Resource name | Primary key | Secondary key | Tertiary key |
DemandResponseProgram | Primacy (ascending) | mRID (descending) | N/A |
EndDeviceControl and ActiveEndDeviceControl | interval.start (ascending) | creationTime (descending) | mRID (descending) |
LoadShedAvailability | href (ascending) | N/A | N/A |
10.3.3 Application guidelines/behavior
10.3.3.1 DemandResponseProgram
Multiple programs can be created to target different types of devices or to offer different types of incentives. DemandResponseProgram SHALL use mRID as a unique identifier for each instance of a program.
DemandResponseProgram server devices SHALL be capable of internally storing and supporting at least 1 DemandResponseProgram instance. DemandResponseProgram server devices SHOULD be capable of internally sorting and supporting 3 unique DemandResponseProgram instances.
DemandResponseProgram client devices SHALL be capable of internally storing and supporting at least 1 DemandResponseProgram instance. DemandResponseProgram client devices SHOULD be capable of internally storing and supporting 3 unique DemandResponseProgram instances.
10.3.3.2 EndDeviceControl
An EndDeviceControl is used to provide control parameters to a DRLC client. An EndDeviceControl can always be overridden by the user.
Demand Response/Load Control server devices SHALL be capable of internally storing and supporting at least 5 unique EndDeviceControl instances that MAY be distributed between multiple programs. Demand Response/Load Control server devices SHOULD be capable of internally storing and supporting at least of 10 unique EndDeviceControl instances.
Demand Response/Load Control client devices SHALL be capable of internally storing and supporting at least three unique EndDeviceControl instances. Demand Response/Load Control client devices SHOULD be capable of internally storing and supporting at least five unique EndDeviceControl instances. As a highly RECOMMENDED recovery mechanism, when a maximum of storage of events has been reached and additional EndDeviceControl instances are available on the server(s), clients SHOULD prioritize local storage and give preference to EndDeviceControls with start times in the near future and to events that have been flagged as mandatory.
10.3.3.3 Rules and guidelines
10.3.3.3.1 Introduction
Note that the rules and guidelines detailed below apply to DRLC client devices that change their consumption behavior based on the demand response signals received. Display only DRLC client devices are not required to comply with the normative statements presented below.
If an EndDeviceControl includes more than one control parameter, the DRLC client is free to utilize applicable parameters of its choice. If the DRLC client is capable of supporting multiple parameters from the ones that have been included in the event, it SHOULD select the parameter that best fits its functionality.
10.3.3.3.2 availabilityUpdateChangePercentThreshold/availabilityUpdateChangePowerThreshold
When Demand Response/Load Control servers support the LoadShedAvailability resource, they SHALL use either the availabilityUpdateChangePercentThreshold or availabilityUpdateChangePowerThreshold to indicate the threshold for which a client is required to update its current load shed ability. The availabilityUpdateChangePercentThreshold is used to indicate a percent change in load shed availability that SHALL trigger an update from the client. The availabilityUpdateChangePowerThreshold is used to indicate an absolute change in available load shed capability that SHALL trigger an update from the client. If no availabilityUpdateChangePercentThreshold or availabilityUpdateChangePowerThreshold is specified, then clients SHALL NOT provide their LoadShedAvailability for that program. If the server provides both, the client SHALL update its current load shed availability when either threshold is crossed.
10.3.3.3.3 drProgramMandatory
Events flagged as drProgramMandatory are strongly RECOMMENDED to be acted upon.
If a user attempts to opt-out of an EndDeviceControl with the drProgramMandatory flag set, clients SHALL require an extra acknowledgment from the user confirming the desire to opt-out. Client devices MAY allow the user to opt out of EndDeviceControls even if the drProgramMandatory flag is true for the given event. Clients SHOULD present a warning to indicate that this event has been flagged as mandatory by their service provider. For example, the client can present a screen stating that “Utility X has marked this event as mandatory and an opt-out can lead to financial penalties as agreed upon in the contract with Utility X.”
10.3.3.3.4 overrideDuration
After the overrideDuration time of an EndDeviceControl has elapsed, the client device SHALL return to execution of the EndDeviceControl for the remaining Effective Scheduled Period.
Client devices MAY allow users to override an EndDeviceControl for a longer duration than event overrideDuration, in which case they SHOULD provide a warning for non-compliance if the drProgramMandatory flag is set to true.
10.3.3.3.5 DateTimeInterval
The duration of the EndDeviceControl is provided in seconds using the duration attribute. Events SHALL NOT be longer than 86 400 seconds (1 day).
10.3.3.3.6 SetPoint
When both a Temperature Offset and a Temperature Set Point are provided, the device MAY use either as defined by the device manufacturer.
In some cases an EDC MAY include an Offset or Set Point that will cause the device to increase its energy consumption. This may be done as a form of pre-heating or pre-cooling before an event that reduces consumption is dispatched. This type of EDC SHALL set the loadShiftForward flag to “True.”
10.3.3.4 Response
The properties of the various control values in a DrResponse with a status of “Event received” SHALL be those existing at the time the event was received but not yet started.
The properties of the various control values in a DrResponse with a status of “Event started” SHALL be those existing at the time the event has started (i.e., the values to which the client adjusted).
The properties of the various control values in a DrResponse with a status indicating event termination (e.g., “Event completed,” “User has chosen to opt-out,” “The event has been superseded”) SHALL be those existing after the event’s completion. For example, if an event completes and no other event has started, the properties of the various control values will likely be identical to those that existed prior to the event.
When overriding an event, client devices SHOULD provide a duration for the override using the drOverrideDuration attribute found in the DrResponse object. This is useful for service providers and energy management systems (EMSs) in understanding for how long the client device will override the event and when it can expect the client device to return to shedding load.
Additional guidelines on how the Response resource operates are provided in the Response function set in 8.8.
10.3.3.5 LoadShedAvailability
When clients support the LoadShedAvailability resource they SHALL POST their ability to shed load when first connected to a server that supports the resource under the appropriate EndDevice resource or SHALL provide their ability to shed load locally under their SelfDevice resource. If the commitment is related to a program, the client SHALL provide a link to the specific DemandResponseProgram. Clients SHALL update their availability based on the update thresholds provided by the program where the load shed is being committed. If no thresholds are specified by the server, then clients SHALL NOT provide updates to their LoadShedAvailability for the provider of that program.
Clients reporting their LoadShedAvailability to multiple DemandResposePrograms SHALL be capable of individually providing the committed power or percentage to each program for a reported duration. For example, a client capable of shedding 2 kW load SHALL NOT report 2 kW of availability to two separate programs, instead it SHALL divide its availability between the two. Client devices already shedding load and reporting on additional availability SHALL be aware of their current state of consumption, as any new event requiring energy reduction SHALL be applied to the device’s current baseline of consumption.
10.3.4 LogEvents
There are no LogEvents generated by this function set.