Patent Publication Number: US-11042178-B2

Title: Providing demand response

Description:
The present application is a continuation of U.S. patent application Ser. No. 15/254,856, filed Sep. 1, 2016, entitled, “Providing Demand Response” which is hereby incorporated by reference. 
    
    
     TECHNICAL FIELD 
     The present disclosure relates to devices, methods, and systems for providing demand response. 
     BACKGROUND 
     Demand response can include voluntary changes in electricity usage of an electric utility customer (e.g., facility) to better match the demand for power with the supply. Demand response can allow for the reduction of load on electrical grids based on signals that are sent to facilities. For example, a demand response request sent to a facility by an electricity supplier or other grid management entity can result in some number of loads in that facility being shut down and/or running at reduced capacity. 
     During demand response when equipment is shutdown or running at reduced capacity, it can be possible to adversely affect conditions in the facility. In addition, a demand response event can have different intensity levels. Previous approaches to demand response may not provide sufficient flexibility to accommodate different event intensity levels while maintaining for adequate control of facility equipment without impact to conditions. For instance, facility loads may be set to take one action only during demand response despite differing event severity levels. Additionally, there may be multiple settings for demand response located in different locations in user interfaces resulting in an over-complicated workflow. Previous user interfaces for demand response configuration in a facility may not provide a way for building managers to quickly configure a large number of loads while also being able to customize a demand response strategy. Further, previous interfaces may not provide a summary of the demand response strategy that has been configured for a given facility. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  illustrates a system for providing demand response in accordance with one or more embodiments of the present disclosure. 
         FIG. 2  illustrates a user interface associated with monitoring demand control in accordance with one or more embodiments of the present disclosure. 
         FIG. 3  illustrates an interface associated with configuring loads in accordance with one or more embodiments of the present disclosure. 
         FIG. 4  illustrates an interface associated with scheduling limiting events in accordance with one or more embodiments of the present disclosure. 
         FIG. 5  illustrates an interface associated with modifying peak targets in accordance with one or more embodiments of the present disclosure. 
         FIG. 6  illustrates an interface associated with modifying demand control settings in accordance with one or more embodiments of the present disclosure. 
     
    
    
     DETAILED DESCRIPTION 
     Devices, methods, and systems for providing demand response are described herein. For example, one or more embodiments include a device having instructions stored thereon executable to receive an indication of a demand response event, determine, based on a configuration made using a user interface, an action to be taken by a load of a facility in response to the demand response event, communicate the determined action to a controller associated with the load, and monitor a status of the action as the action is taken. 
     Demand response, as referred to herein, can include voluntary changes in electricity usage by an electric utility customer (e.g., facility) in response to a request by an electricity supplier or other grid management entity; this request typically occurs when there is heavy demand for electricity on the electrical grid, and is intended to prevent temporary electricity shortfalls. A demand response request is referred to as a demand response event, and can be sent to a customer via email or text message, or via an automated signal, wherein the latter may be referred to as automated demand response (ADR). When a demand response event is sent to a customer, it is the customer&#39;s responsibility to take actions to reduce electrical usage for some period of time specified in the event message—this typically means that some number of electrical loads in one or more customer facilities are shut down and/or run at reduced capacity. 
     During demand response when equipment is shutdown or running at reduced capacity, it can be possible to adversely affect conditions in the facility. In addition, a demand response event can have different intensity levels. Previous approaches to demand response may not provide sufficient flexibility to accommodate different event intensity levels while maintaining for adequate control of facility equipment without impact to conditions. For instance, facility loads may be set to take one action only during demand response despite differing event severity levels. Additionally, there may be multiple settings for demand response located in different locations in user interfaces resulting in an over-complicated workflow. Previous user interfaces for demand response configuration in a facility may not provide a way for building managers to quickly configure a large number of loads while also being able to customize a demand response strategy. Further, previous interfaces may not provide a summary of the demand response strategy that has been configured for a given facility. 
     Demand response (e.g., demand control) in accordance with one or more embodiments of the present disclosure can provide flexibility in controlling a facility. For instance, loads may be set to take different actions according to differing event seventies. Building managers using embodiments here can configure a large number of loads, visualize their demand response strategy, and customize that strategy, all at a glance. 
     Embodiments of the present disclosure can include a comprehensive ADR system provided to a user that allows for easier configuration compared to previous approaches. In some embodiments, for instance, ADR events from a demand response automation server (DRAS) can be parsed (e.g., by an executive control module) and passed along to a demand control service component (sometimes referred to herein simply as “computing device.”). The computing device can take information about operation mode (e.g., event severity), target (e.g., required electricity reduction), target type (e.g., electricity reduction or firm kW threshold), etc. to determine what actions the facility (e.g., devices and/or loads of the facility) should take. Those determined actions can be passed to equipment controllers, which can execute them. Embodiments herein include a user interface that allows monitoring of the whole facility, as well as quick configuration of loads and/or settings. 
     As discussed further below, the user interface can include monitoring screens that show information about all loads of the facility, configuration screens (e.g., tabs) that allow all facility settings to be configured at once, and load configuration screens (e.g., pop-ups) that allow bulk configuration of loads. 
     In addition, embodiments here can allow the selection of different strategies including, for example, load rolling and load staging. Different strategies can be assigned to each of the different operation modes for events. Moreover, embodiments herein can utilize virtual shed groups instead of fixed registers, wherein loads can be assigned a group number. Virtual shed groups can allow for a larger number of participating loads compared to previous approaches. 
     A demand limiting schedule in accordance with embodiments herein can allow for more scheduling flexibility in that each alternate schedule and/or special event can have a separate set of limiting targets for greater control. A demand settings component can provide a level of abstraction between the service (e.g., the computing device) and each load. As a result, new load types and/or load strategies can be added without modifying the service, and third party loads can be used by configuring a strategy (e.g., in wiresheet) and using the demand settings component&#39;s shed output to drive logic. 
     As referred to herein, an event can include a signal and/or a request to reduce load. An event can be a signal in response to which a number of loads are shut down or run at reduced capacity. In some embodiments, events can be sent (e.g., issued) from a utility. In some embodiments, events can be scheduled (e.g., manually scheduled) by facilities themselves. It is noted that where the singular “facility” is used herein, such reference can refer to any number of structures, buildings, plants, refineries, sites, etc. 
     Load, as referred to herein, includes electricity use by one or more devices and/or systems. For example, loads can refer to units and/or systems associated with heating, ventilation, and air conditioning (HVAC), refrigeration, lighting, and/or industrial equipment, among others. 
     In the following detailed description, reference is made to the accompanying drawings that form a part hereof. The drawings show by way of illustration how one or more embodiments of the disclosure may be practiced. 
     These embodiments are described in sufficient detail to enable those of ordinary skill in the art to practice one or more embodiments of this disclosure. It is to be understood that other embodiments may be utilized and that process changes may be made without departing from the scope of the present disclosure. 
     As will be appreciated, elements shown in the various embodiments herein can be added, exchanged, combined, and/or eliminated so as to provide a number of additional embodiments of the present disclosure. The proportion and the relative scale of the elements provided in the figures are intended to illustrate the embodiments of the present disclosure, and should not be taken in a limiting sense. 
     The figures herein follow a numbering convention in which the first digit or digits correspond to the drawing figure number and the remaining digits identify an element or component in the drawing. Similar elements or components between different figures may be identified by the use of similar digits. 
     As used herein, “a” or “a number of” something can refer to one or more such things. For example, “a number of loads” can refer to one or more loads. 
       FIG. 1  illustrates a system  100  for providing demand response in accordance with one or more embodiments of the present disclosure. As shown in  FIG. 1 , the system  100  can include a demand control service (DCS) component  102 . The DCS  102  can be a computing device, for instance. 
     DCS  102  can be, for example, a laptop computer, a desktop computer, or a mobile device (e.g., a mobile phone, a personal digital assistant, etc.), among other types of computing devices. 
     As shown in  FIG. 1 , DCS  102  includes a memory  103  and a processor  105  coupled to memory  103 . Memory  103  can be any type of storage medium that can be accessed by processor  105  to perform various examples of the present disclosure. For example, memory  103  can be a non-transitory computer readable medium having computer readable instructions (e.g., computer program instructions) stored thereon that are executable by processor  105  to provide demand response in accordance with one or more embodiments of the present disclosure. 
     Memory  103  can be volatile or nonvolatile memory. Memory  103  can also be removable (e.g., portable) memory, or non-removable (e.g., internal) memory. For example, memory  103  can be random access memory (RAM) (e.g., dynamic random access memory (DRAM) and/or phase change random access memory (PCRAM)), read-only memory (ROM) (e.g., electrically erasable programmable read-only memory (EEPROM) and/or compact-disc read-only memory (CD-ROM)), flash memory, a laser disc, a digital versatile disc (DVD) or other optical disk storage, and/or a magnetic medium such as magnetic cassettes, tapes, or disks, among other types of memory. 
     Further, although memory  103  is illustrated as being located in DCS  102 , embodiments of the present disclosure are not so limited. For example, memory  103  can also be located internal to another computing resource (e.g., enabling computer readable instructions to be downloaded over the Internet or another wired or wireless connection). 
     As shown in  FIG. 1 , DCS  102  can also include a user interface  106 . User interface  106  can include, for example, a display (e.g., a screen). The display can be, for instance, a touch-screen (e.g., the display can include touch-screen capabilities). 
     User interface  106  (e.g., the display of user interface  106 ) can provide (e.g., display and/or present) information to a user of DCS  102 . For example, user interface  106  can provide the user interfaces  210 ,  326 ,  432 ,  534 , and/or  636 , described herein in connection with  FIGS. 2-6  to the user. 
     Additionally, DCS  102  can receive information from the user of DCS  102  through an interaction with the user via user interface  106 . For example, DCS  102  (e.g., the display of user interface  106 ) can receive input from the user via user interface  106 . The user can enter the input into DCS  102  using, for instance, a mouse and/or keyboard associated with DCS  102 , or by touching the display of user interface  106  in embodiments in which the display includes touch-screen capabilities (e.g., embodiments in which the display is a touch screen). 
     The DCS can receive an indication of a demand response event (illustrated in  FIG. 1  as “demand response signal” and hereinafter referred to as “event  106 ”). As previously discussed, an event can include a signal and/or a request to adjust (e.g., reduce) load. An event can be a signal in response to which a number of loads are shut down or run at reduced capacity. In order to reduce loads, operations of one or more devices can be adjusted. Such adjustment may be made in order to meet a usage target (e.g., kilowatt hour target). In some embodiments, one or more devices can be deactivated (e.g., according to a schedule). In some embodiments, setpoints associated with one or more devices can be modified. 
     In some embodiments, events can be sent (e.g., issued) from a utility. In some embodiments, events can be passed from a virtual top node (VTN) and/or aggregator. For example, a demand response signal  106  can be received from a demand response automation server. In some embodiments, events can be scheduled (e.g., manually scheduled) by facilities themselves. Accordingly, an indication of an event can be received based on a manually-scheduled demand response event  104 . 
     The system  100  can include a plurality of loads (referred to collectively as “loads  108 ”). For instance, the system  100  can include a first load  108 - 1 , a second load  108 - 2  (e.g., “Rooftop Unit”), a third node  108 - 3  (e.g., “Third Party Device”), and a fourth load  108 - 4  (e.g., “BACnet device”). Though four loads  108  are shown in  FIG. 1 , embodiments of the present disclosure can include more or fewer loads. Additionally, the types of loads illustrated in  FIG. 1  (e.g., “Rooftop Unit,” “Third Party Device,” “BACnet device” are used as example types; embodiments of the present disclosure are not limited to the types illustrated in  FIG. 1 . 
     Each of the loads  108  can be in communication with the DCS  102  via a demand settings component. In some embodiments the demand settings component(s) can receive command(s) to shed load from the DCS  102  and can communicate status information back to the DCS  102 . The DCS  102  can receive events as described above and determine which loads are to be reduced and/or how the reduction is to take place. Such information can be communicated to the demand settings component(s) via the shed command(s). For the Rooftop Unit load  108 - 2  and the BACnet device load  108 - 4 , the corresponding demand settings components can direct modifications to control settings in order to reduce load. 
     For the load  108 - 1 , the shed command output of its demand settings component can be linked to a Boolean output point (e.g., an arbitrary Boolean output point). For the Third Party Device load  108 - 3 , a wiresheet logic setup can be configured. For instance, the demand settings component of the load  108 - 3  can be linked to an output point. In some embodiments, the wiresheet logic can use additional information from the demand settings component of the load  108 - 3 . 
       FIG. 2  illustrates a user interface  210  associated with monitoring demand control in accordance with one or more embodiments of the present disclosure. The interface  210  can be displayed when the selectable display element (e.g., tab)  212  is selected. As shown in  FIG. 2 , the interface  210  can include a current status portion  216 , a views portion, and a demand loads overview portion  218 . Selection of another tab  214  can cause the display of a demand control settings interface, discussed further below in connection with  FIG. 6 . 
     The current status portion  216  can include information associated with a current status of a demand response event associated with a facility. Such information, can include, for instance, current activity state (e.g., level) of the event, current operation mode, current power usage, current shed target, current baseline, etc. Such information may be general in nature in that it may not be particular to one or more specific loads but may refer to the loads of the facility of a whole, for instance. 
     The views portion can include selectable display elements which, when selected, can cause the display of other user interfaces. For instance, selection of the event level configuration button  220  can cause the display of an interface  326  discussed below in connection with  FIG. 3 . Selection of the limiting schedule button  224  can cause the display of an interface  432  discussed below in connection with  FIG. 4 . Selection of the limiting targets button  222  can cause the display of an interface  534  discussed below in connection with  FIG. 5 . 
     The demand loads overview portion  218  can include information associated with the demand response event particular to each of a plurality of loads associated with the facility. Such information can be specific to a current event. For instance, each row in the demand loads overview portion  218  can correspond to an individual load in the facility having a demand settings component (previously discussed). For each load, information can be provided in a dashboard-style at-a-glance format such as, for example, demand control enabled/disabled status, shed group identification, command status, actual status, time in shed, time in restore, zone temperature, active setpoint, load feedback, etc. Accordingly, a user can be made aware of the status of the event as it pertains to individual loads. At times in which an event is not occurring, information may be blanked out, for instance. 
     Once loads are added, they can be configured by selecting the event level configuration button  220 . The interface can then provide a pop-up window with a table displaying settings for each operation mode and allow for configuration. 
       FIG. 3  illustrates an interface  326  associated with configuring loads in accordance with one or more embodiments of the present disclosure. The interface  326  can be provided following the selection of the event level configuration button  220  on the interface  210 , previously described in connection with  FIG. 2 . The interface  326  can receive configuration modifications to each of the plurality of loads, for instance. The configuration modifications can include modifications to a plurality of settings for each of a plurality of operation modes associated with the plurality of loads 
     The interface  326  can include a number of portions (e.g., tabs) corresponding to different operation modes. In some embodiments, operation modes can include “limiting,” “normal,” “moderate,” “high,” and/or “special,” though embodiments of the present disclosure are not so limited. Selection of a particular operation mode can allow for configuration of loads in that mode. For instance, as shown in  FIG. 3 , the “normal” event settings tab is selected. 
     Embodiments of the present disclosure can allow for the configurations of multiple loads to be modified at once. For instance, the loads “RTU Sales Front” and “RTU Sales Middle” are both selected in the example illustrated in  FIG. 3 . Also as shown, selection of the “shed strategy” configuration column can cause the display of a pop-up window  328  allowing for the modification of that configuration for both loads simultaneously. 
     Selection of the demand response schedule button of the interface  210 , previously described in connection with  FIG. 1 , can cause the display of an interface associated with scheduling manual demand response events. In some embodiments, normal, moderate, high, and/or special events can be scheduled. In some embodiments, alternate and/or special events can be set up in addition to scheduled (e.g., weekly) events. 
       FIG. 4  illustrates an interface  432  associated with scheduling limiting events in accordance with one or more embodiments of the present disclosure. Selection of the limiting schedule button  224  (previously described in connection with  FIG. 2 ) can cause the display of the interface  432 , for instance. A limiting event can be scheduled for a particular period of time, at a particular time, on one or more days of a week. The limiting event(s) can be “peak,” “off-peak,” or “alt-peak” events according to some embodiments. Such differentiation can allow for flexibility in a limiting strategy by accounting for time of varying usage. For example, during the middle of a summer day, a peak limiting event may be scheduled instead of an off-peak event to prevent the facility from shedding a particular amount (e.g., too much for comfort). 
     In contrast with previous approaches, where users may be restricted to 12 alternate schedules representing different months, embodiments herein can allow for the creation and/or modification of customizable schedules. Each schedule can have its own set of peak values (e.g., 3 peak values). Such embodiments can provide the ability for an enterprise to batch push a limiting schedule to a number of different facilities while allowing each facility to maintain its own peak values, which may vary based on location, for instance. 
       FIG. 5  illustrates an interface  534  associated with modifying peak targets in accordance with one or more embodiments of the present disclosure. Selection of the limiting targets button  222  from the user interface  210 , previously described in connection with  FIG. 2 , can cause the display of interface  534 , for instance. In some embodiments, the interface  534  can be a pop-up window that allows for the editing of peak targets in bulk. The interface  534  can display the peak targets for a weekly schedule. The interface  534  can display the peak targets for each special event. The interface  534  can display the peak targets for one or more alternate schedules. Selection of one or more schedules (as shown in  FIG. 5 ) can allow the modification of one or more aspects of the peak target(s). 
       FIG. 6  illustrates an interface  636  associated with modifying demand control settings in accordance with one or more embodiments of the present disclosure. The settings modified using the interface  636  can be modifications nonspecific to any one particular load, for instance (e.g., settings that relate to the ADR system as a whole). Selection of the tab  214 , previously described in connection with  FIG. 2  and illustrated as tab  614  in  FIG. 6 , can cause the display of the interface  636 , for instance. 
     The interface  636  can include a control settings portion  638 , a recovery portion  640 , a stage start portion  642 , a load rolling/staging portion  644 , a limits portion  646 , a demand limiting portion  648 , a demand response configuration portion  650 , and a baseline portion  652 , though embodiments of the present disclosure are not so limited. 
     The control settings portion  638  can be configured to allow for enabling and/or disabling demand limiting. The control settings portion  638  can be configured to set a demand response type (e.g., none, manual, or ADR service). 
     The recovery portion  640  can be configured to set a recovery time taken after an event ends to gradually restore each of a plurality of loads, for instance. A baseline percentage can be set, which can specify a starting recovery target. A restore delay time can be set, which can specify a time in between the restoration of loads. 
     The stage start portion  642  can include portion configured to modify a startup duration, which can indicate how long it may take for all loads to be restored following a station startup. A restore per interval value can be set, which can designate how many loads are to be restored for each interval. 
     The load rolling/staging portion  644  can allow settings for shed delay and/or restore delay. Such delays may refer to a respective amount of delay between shedding and restoring loads individually. Rotation delay can allow the modification of an amount of time between in-group rotation. Group shed delay can allow the modification of a delay between shedding full groups (e.g., an initial behavior of a staging strategy until a target is met). “Restore from” can allow the selection of whether loads restored during staging are to be restored in an order they were shed or in an order of the most recently shed load being restored first. Rotation interval can refer to a load rolling strategy and can allow the modification of an interval between switching which group is shed. 
     The limits portion  646  can allow modification of shed and restore thresholds. The limits portion  646  can allow modification of an overlimit alert amount. For example, an overlimit alert can trigger an alarm if current demand surpasses a demand target for a particular period of time (e.g., a threshold-exceeding period of time). 
     The demand limiting portion  648  can allow modification of the shed delay for limiting. The demand limiting portion  648  can allow modification of the restore delay for limiting. 
     The demand response configuration portion  650  can allow a selection between a load rolling strategy and a load staging strategy. Demand limiting may use a load staging strategy by default, for instance. If, for example, a facility is using a manual demand response mode, a manual target for each operation mode can be configured and/or modified. 
     The baseline portion  652  can allow modification of information associated with a baseline. For example, the baseline portion  652  can allow configuration of baseline binning. 
     Load staging, as referred to herein, is a strategy in which loads can be divided into shed groups based on importance. Loads designated as more critical loads may tend to be placed in higher-numbered shed groups. Less important loads may be placed in lower-numbered shed groups. Other loads, such as lighting, for instance, may be placed in a continuous shed group. When an event begins, all continuous loads can be shed, in some embodiments. The first group can then be shed. If a group rotation delay elapses and the current usage remains above a threshold (e.g., a “shed above” usage), a second group can be shed. This process can continue until the current usage falls below a “shed above” range or all groups have been shed. If the current usage falls below a “restore below” range, a restore delay timer can be activated. Once the restore delay timer elapses, a load can be restored and the timer can be restarted. If the current usage rises above the “shed above” range again, one load can be shed at a time. If current usage remains within a deadband range, then a partially shed group can rotate which loads are shed. 
     Load rolling, as referred to herein, is a strategy in which loads can be placed in different groups with no preference of importance. In some embodiments, load rolling allows a single group to be shed at a time, but rotates one whole group every time the rotation interval timer elapses. If the facility&#39;s demand remains above a restore target, the rotation can continue spreading the effects of the demand curtailment among the configured shed groups by shedding another group and restoring the first group, one group at a time. If the demand drops below the restore target and remains below the restore target for at least one rotation interval, the load rolling strategy can terminate the periodic group rotation and loads can begin to be restored. The load rolling strategy can then return to group rotation if the demand rises above a shed target. If the demand remains between the shed target and the restore target, the current mode can be continued, either rotating the shed group or waiting for the demand to rise into the shed range. 
     In previous approaches, ADR may include a number of (e.g., 2) “shed registers” with a fixed number of slots to which loads are attached. Such loads may have a single response (e.g., setpoint adjust or load shed off) irrespective of what type of event was received. In contrast, embodiments of the present disclosure can utilize virtual shed groups which can be read at the time of an event. Each load can have a different shed group for each different operation mode, thereby allowing a greater deal of flexibility when configuring a strategy. When a demand response action is taken by the DCS (previously discussed in connection with  FIG. 1 ), the DCS can query demand settings component(s) in the facility to determine which loads can be acted upon based on their shed group for the current operation mode. Accordingly, each load can respond differently depending on the type of event. For a normal event, for instance, a load may undergo a setpoint adjustment of two degrees. For a moderate event, for instance, when demand reduction is more urgently needed, the load could be shut off entirely. Similarly, a normal event can utilize a higher number of (e.g., four) shed groups for gradual shedding to meet its target, while a high event may use a lower number of (e.g., 2) shed groups for a quicker response. 
     Embodiments of the present disclosure can allow for more logical configuration than previous approaches. A multitude of aspects of ADR control can be overseen and/or modified from one place (e.g., the computing device described above in connection with  FIG. 1 ). For instance, the computing device can configure aspects of the facility as a whole (e.g., strategy, timers, etc.), and individual loads themselves (e.g., shed strategies, shed groups, etc.). Additionally, the computing device can configure devices and allow for a user to check on a device that may not be operating as expected. 
     Although specific embodiments have been illustrated and described herein, those of ordinary skill in the art will appreciate that any arrangement calculated to achieve the same techniques can be substituted for the specific embodiments shown. This disclosure is intended to cover any and all adaptations or variations of various embodiments of the disclosure. 
     It is to be understood that the above description has been made in an illustrative fashion, and not a restrictive one. Combination of the above embodiments, and other embodiments not specifically described herein will be apparent to those of skill in the art upon reviewing the above description. 
     The scope of the various embodiments of the disclosure includes any other applications in which the above structures and methods are used. Therefore, the scope of various embodiments of the disclosure should be determined with reference to the appended claims, along with the full range of equivalents to which such claims are entitled. 
     In the foregoing Detailed Description, various features are grouped together in example embodiments illustrated in the figures for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the embodiments of the disclosure require more features than are expressly recited in each claim. 
     Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus, the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separate embodiment.