Patent Publication Number: US-10762454-B2

Title: Demand response management system

Description:
This application is a continuation of U.S. patent application Ser. No. 14/931,746, filed Nov. 3, 2015, which is a continuation of U.S. patent application Ser. No. 14/327,460, filed Jul. 9, 2014, and entitled “Demand Response Management System”, which is a continuation of U.S. patent application Ser. No. 13/019,943, filed Feb. 2, 2011, and entitled “Demand Response Management System”, which claims the benefit of U.S. Provisional Patent Application No. 61/301,123, filed Feb. 3, 2010, and entitled “Demand Response Management System”. U.S. Provisional Patent Application No. 61/301,123, filed Feb. 3, 2010, is hereby incorporated by reference. U.S. patent application Ser. No. 13/019,943, filed Feb. 2, 2011, is hereby incorporated by reference. U.S. patent application Ser. No. 14/327,460, filed Jul. 9, 2014, is hereby incorporated by reference. U.S. patent application Ser. No. 14/931,746, filed Nov. 3, 2015, is hereby incorporated by reference. 
     This application is a continuation of U.S. patent application Ser. No. 14/931,746, filed Nov. 3, 2015, which is a continuation of U.S. patent application Ser. No. 14/327,460, filed Jul. 9, 2014, and entitled “Demand Response Management System”, which is a continuation of U.S. patent application Ser. No. 13/019,943, filed Feb. 2, 2011, and entitled “Demand Response Management System”, which is a continuation-in-part of U.S. patent application Ser. No. 12/834,841, filed Jul. 12, 2010, and entitled “A System for Providing Demand Response Services”, which claims the benefit of U.S. Provisional Patent Application No. 61/271,084, filed Jul. 17, 2009. U.S. patent application Ser. No. 12/834,841, filed Jul. 12, 2010, is hereby incorporated by reference. U.S. Provisional Patent Application No. 61/271,084, filed Jul. 17, 2009, is hereby incorporated by reference. 
    
    
     BACKGROUND 
     The present disclosure pertains to utility resources and particularly to assessment and distribution of the resources. More particularly, the invention pertains to beneficial management of resources and their loads. 
     SUMMARY 
     The disclosure reveals a demand response management system which may be implemented with demand response logic. The system may be used by utilities, independent system operators, intermediaries and others to manage operations of demand response programs relative to customers, clients, participants, and users of outputs from the utilities, independent system operators, and the like. Demand response logic of the demand response management system may provide demand signal propagation and generation from demand response events. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWING 
         FIG. 1  is a diagram of an interaction between a utility and/or independent system operator and a demand response resource; 
         FIG. 2  is a diagram of a classification hierarchy of the types of demand response interactions and signals that may be used relative to a demand response resource; 
         FIG. 3  is a diagram of how demand response logic may transform high level grid conditions into eventual load control commands; 
         FIGS. 4 a , 4 b  and 4 c    are diagrams illustrating cases where some or virtually all of demand response logic is implemented by a demand response management system which may reside within a utility and/or independent system operator or an intermediary entity; 
         FIG. 5  is a diagram showing a consolidated scenario in which demand response signals generated by a demand response management system may be delivered to either an energy management control system or directly to a load control mechanism within a customer&#39;s facility; 
         FIG. 6  is a diagram of where one or more demand response resources may be an entity that have a relationship with a utility and/or independent service operator or and intermediary relative to being a participant in a demand response event; 
         FIG. 7  is a diagram showing a demand response management system for generating a demand response signal, which may be adjusted, for a particular client, customer or participant, relative to a demand response event; and 
         FIG. 8  is a diagram of a table being a way of representing quantities and/or rules allowing them to be easily edited for adjusting a demand response signal for a particular customer, client or participant, relative to a demand response event. 
     
    
    
     DESCRIPTION 
     The present disclosure reveals an implementation of demand response (DR) logic within a demand response management system (DRMS). The system and associated software may be effected and operated with one or more computers/controllers (controllers) and connections. The DRMS is a system that may be used by utilities and independent system operators (ISO&#39;s) to manage the operation of DR programs. A focus of the DRMS may be on the operational aspects of managing the selection, signaling and monitoring of the DR resources that are participating in DR programs. The DRMS may be specifically designed to manage the operations of automated DR programs. The DR logic components of the DRMS are noted herein. 
     There may be various types of interactions that might occur between the utility/ISO and a DR resource as part of a DR program.  FIG. 1  is a diagram of an interaction between a utility/ISO  11  and a DR resource (customer)  12 . There may be DR signals  13  going from utility/ISO to DR resource  12 . There may be load measurement signals  14  going from DR resource  12  to utility/ISO  11 . 
     Customer, client, user, participant, and like terms, may be used, interchangeably or distinct from one another, depending on a context of a pertinent portion of a description or a claim. 
     A description of DR Signals  13  may be noted. At the highest level, there may virtually always be some sort of grid condition, be it economic or grid reliability in nature, which triggers a so called DR event that requires some sort of interaction between the utility/ISO and its customers. This interaction may eventually trigger some sort of load control taking place at a customer&#39;s facility. The interaction between the utility/ISO  11  and the customer  12  may be mediated by a so called DR signal  13  that represents a communication between the utility/ISO  11  and the customer  12 . It is the information contained within the DR signal  13  that may dictate where much of the decision making takes place in how the initial grid condition that triggered the DR event results in the eventual load control. 
     There may be a classification hierarchy of the types of DR interactions and signals that may be used as illustrated by a diagram in  FIG. 2 . Three classes of interactions that may occur incorporate a supply state  16 , DR resource instructions  17 , and load controller commands  18 . 
     A supply  16  state may refer to information about conditions concerning the supply of electricity that may affect DR resource&#39;s  12  load profile. The conditions may incorporate prices of electricity, sources of generation (e.g., hydro versus coal), carbon content, reliability of supply or grid conditions, and other conditions. 
     The nature of this information may be such that it does not necessarily include any specific instructions for how the load profile of the DR resource should change. Virtually all decisions as to what the desired load profile should be in response to the information within a DR signal  13  may be within the DR resource  12 . A very typical example of this type of DR signal  13  may be real-time or dynamic electricity prices that may be sent to a DR resource  17 . 
     DR resource instructions may refer to information that specifies what the load profile of a DR resource  12  should be as a result of receiving a DR signal  13 . Examples of this information may incorporate specific consumption levels (which can be either up or down), dispatch instructions, and load profile specifications. 
     This type of information may be more specific than information of the supply state  16  in that it indicates what the load profile of DR resource  12  should be. The information does not necessarily indicate how individual loads of DR resource  12  should be controlled and thus the intelligence for determining how to control individual loads may be virtually all within DR resource  12 . The information may be about load shifting or shedding, and the certainty or predictability of a load shape change. 
     Typical examples of such information may incorporate dispatch instructions that may be sent from an ISO  11  to an aggregator. Such dispatch instructions may often be in a form of an amount of load that DR resource  12  is expected to provide. 
     Load controller commands  18  may refer to specific load control commands sent to a controller of a load that specifies the state that the load should be in. Examples may incorporate existing DR programs such as AC cycling in which air conditioners within residences are turned on and off. This information may be used for DLC (direct load control). 
     DR logic  21  may support supply state  16  and the DR resource instructions  17 . DR logic  21  may be a part of or provided by a computer/controller (computer) at a place where the logic  21  is situated. The computer may incorporate one or more inputs, a processor, a user interface with a keyboard and display, a memory, external connections such as an internet, one or more outputs, and so forth. The computer may be utilized with virtually all items in and pertinent to  FIGS. 1-8 . 
     A specification for the DR logic  21  may be necessary to support load controller commands (direct load control). DR logic  21  may transform high level grid conditions  22  into eventual load control commands  23  as indicated a diagram of  FIG. 3 . DR logic  21 , associated with a computer, may be instantiated within a single entity or may be distributed across different systems as entities. While there may be “use cases” where no DR logic  21  is implemented within an entity that interacts with the customer facility  27  (i.e., utility/ISO  11  or intermediary  25 ), one may note the use cases where at least some of the DR logic  21  is implemented by a DRMS  24  which resides within the utility/ISO  11  or an intermediary entity  25  as shown in  FIGS. 4 a -4 c   . A last use case of  FIG. 4 c    in which virtually all of the DR logic  21  may be embedded within the utility/ISO  11  or intermediary entity  25  may be considered as providing direct load control (DLC) as indicated by commands  34  which go to load and DER  28  of customer facility  27  via gateway  35 . 
     In  FIG. 4 a   , a first use case shows a scenario wherein some of the DR logic  21  may reside within an energy management and control system (EMCS)  26  within a customer facility  27 . EMCS  26  may be an actual device or a software module running inside a larger system with a computer such as customer facility  27 . Upon receiving a DR signal  13 , EMCS  26  may be responsible for processing the information within the DR signal  13  into some sort of facility wide load profile objectives and/or load control commands. There may be an interaction between EMCS  26  and load and DER  28 . 
     In  FIG. 4 b   , the second use case shows a scenario wherein the load and DER  28  (e.g., an appliance, thermostat, or the like), having DR logic  21 , may interact directly with the DRMS  24  via gateway  35  to receive the DR signal  13 . In  FIG. 4 c   , as noted herein, the DRMS  24  may provide direct load commands  34  directly to load and DER  28 . It may be that virtually all of the DR logic  21  concerning how to respond to a DR signal is embedded directly in a load controller. 
     There may be scenarios which are a combination of the first and second use cases in which some of the DR logic  21  is embedded within an EMCS  26  and some of the DR logic  21  is embedded within the load controller. 
     The present approach may deal with DR logic  21  that is instantiated within the DRMS  24 . It may be assumed that the nature of the DR signals  13  which are being delivered by the DRMS  24  are of either a grid state or a DR resource instruction category. DR signals  13  may conform to an existing standard or specification such as the OpenADR. 
     In  FIG. 5 , a diagram shows a consolidated scenario in which DR signals  13  generated by the DRMS  24  may be delivered to either an EMCS  26  or directly to a load controller within the customer&#39;s facility  27 . 
     Main functions of DR logic  21  within the DRMS  24  of utility/ISO  11  or intermediary  25  may incorporate 1) DR signal  13  propagation and 2) DR signal  13  translation (generation). A notion of a DR event  31  ( FIG. 6 ) may be further defined. A DR event may be initiated by the utility/ISO  11  or intermediary  25  which is responsible for ultimately generating a DR signal  13  for the customer  12  or customer facility  27 . A main function of DR logic  21  may be to take a DR event  31  and generate an appropriate DR signal  13 . 
     A DR event  31  may have several attributes. One attribute may be a schedule for the various periods which is associated with the DR event. Two very significant periods may be 1) the so-called notification period before an event and 2) the period when the event itself is active. Another attribute may be a set of information or instructions which is associated with the DR event. This information may be particularly specific to a DR program and be a main instrument that the utility/ISO  11  uses to interact with the customer  12  during DR events. Examples of information or instructions may incorporate prices, shed levels and device commands. This information may fall into one of the three categories of supply state  16 , DR resource instructions  17  and load controller commands  18 , as indicated in  FIG. 2 . 
     DR Signal  13  propagation of DR logic  21  within DRMS  24 , may be noted. One of the functions of the DR logic  21  may be to take a DR event and a specification as to which DR resources (customers)  12  are to receive signals, and from that determine an appropriate set of customers and their devices that need to receive DR signals  13 . This may be referred to as propagating the DR signal  13 . 
     In a diagram of  FIG. 6 , a DR resource  12  may be an entity (typically a customer or participant) that has a relationship with the utility/ISO  11  or intermediary  25  and represents the entity that the utility/ISO  11  or intermediary  25  interacts with. This means that if the utility/ISO  11  wants to issue a DR event  31 , then the DR resources  12  may be the entities that utility/ISO  11  calls upon to participate in the event  31 . 
     DR resource  12  management and signal propagation may be noted. Each customer (i.e., DR resource  12 ) may manage a set of so-called clients  32  (EMCS or device) that it uses to manage its interactions with the DRMS  24 . It may be the clients  32  that receive DR signals  13  from the DRMS  24 . Thus, as shown in  FIG. 6 , each DR resource  12  may have associated with it multiple clients  32 . Each of the clients may receive its own version of a DR signal  13  corresponding to a DR event  31 . 
     Each DR resource  12  and set of associated clients  32  may have a set of attributes such as customer name, geographic location and grid location. Furthermore, DR resources  12  and clients  32  may be associated with groups that can be used for aggregation purposes. When a DR event  31  is issued by the utility/ISO  11 , there may be additional data that specify who is to receive the DR signals  13 . As recipients of DR signals  13 , the data may indicate specific customers, aggregated group identifiers, resource groups, geographic regions and/or locations, and/or grid locations. These data or specifications may be used by the DRMS  24  to determine which DR resources  12  and which clients  32  of the DR resources  12  are to receive the DR signals  13 . 
     Participation rules may be noted for DR signal  13  propagation. In addition to the attributes, each DR resource  12  may have associated with it a set of business rules that dictate the schedule constraints of when the DR resource  12  will participate in DR events  31 . Such rules may incorporate: 1) Blackout periods having specific date/time periods, time of day, days of week, and/or days of month; 2) A maximum number of events for a year, month, week, and/or consecutive days; 3) Maximum and minimum durations of events; and/or 4) Maximum and minimum notification times for upcoming events. 
     If an event is issued that violates any of the constraints or rules, then the DRMS  24  may be configured such that it will not propagate a DR signal  13  to the DR resource  12  or its clients  32 . Thus, the constraints or rules may also be a mechanism to control how DR signals  13  are propagated to the clients  32  of DR resources  12 . 
     DR signal  13  generation (translation) of DR logic  21  within DRMS  24  may be noted. One of the functions of DR logic  21  may be to translate whatever information is associated with a DR event  31  into an appropriate DR signal  13  that can be sent to the customer or resource  12 . In some cases, there may be very little, if any, translation or transformation necessary, but in some cases the DR event  31  information (e.g., prices, shed levels, and so forth) may be translated into a form that is specific for the customer  12 . 
     The following are general transformations (or translations) that may take place to generate a DR signal  13 . One may be to customize the DR event  31  schedule for the customer  12 . A second transformation may be to customize the DR event  31  information specifically for the customer  12 . For example, a particular DR program may use prices as the main instrument in a DR signal  13 , but each individual customer  12  may receive a different price based upon a bid that the customer has placed. Thus, the price within the DR signal  13  may be customized for each customer  12 . 
     A third transformation may be to translate the information in the DR event  31  to an alternate form which makes it easier for the customer&#39;s automation equipment to consume it. Examples of transformations of this type may include the simple DRAS (demand response automation server) client signal levels that are described in the OpenADR (open automated demand response (communications specification)). The simple levels in OpenADR may be specifically designed to allow more complex information such as prices and shed amounts to be translated into one of a finite set of simple levels such as NORMAL, MODERATE, and HIGH. These simple levels may then be more easily translated into specific load control commands using DR logic  21  within the customer&#39;s facility  27 . 
     A fourth transformation may be to use feedback from the customer  12  (e.g., real-time usage information) to modify the DR event  31  and associated signal information. A fifth transformation may be to translate the information in a DR event  31  into actual load control commands, e.g., direct load control commands  34  of  FIG. 4 c   . The fifth transformation may be described in U.S. patent application Ser. No. 12/834,841, filed Jul. 12, 2010, and entitled “A System for Providing Demand Response Services”, which is hereby incorporated by reference. 
     A diagram of  FIG. 7  shows the DR signal  13  generation (translation) process of a DR management system. DR logic  21  ( FIG. 5 ) and one of its main functions, DR signal generation, may be noted. The mechanism of the Figure described herein may allow for DR event  31  information to be translated, but it may also be possible to translate the timing parameters of the DR event  31  by using the participation rules indicated herein. If the rules defined for a particular customer  12  or participant, do not match the event  31  schedule, then it may be possible for the DRMS to be configured such that the DR signal  13  which is generated can be adjusted to match the business rules. 
     For example, one may assume that a participation rule has been defined for a particular participant, such as “Can participate in DR events from 3 pm to 6 pm.” Now one may assume that a DR event  31  is issued with a schedule, such as “Event active from 4 pm to 7 pm.” Since there is a period of the DR event  31  in which the participant has specified that it will not participate, it may be possible for the DRMS to be configured to generate a DR signal  13  that spans from 4 pm to 6 pm in order to match the participant&#39;s rule, by eliminating the 6 pm to 7 pm period in which the participant cannot participate. This way, the participant may be present for the whole schedule of event  31 . Likewise, the DRMS may also have been configured to reject the DR event  31  and generate no DR signal  13  for that participant in accordance with the signal propagation rules as described herein. 
     Implementation of DR logic  21  for signal generation, that of another main function of the DR logic  21  ( FIG. 5 ) may be noted. A portion or more of DR logic  21  being used to generate DR signals  13  may be described in several steps as shown  FIG. 7 . A first step  41  may entail customizing or modifying the schedule of the DR event  31  to match user participation rules  36  of the DR resource  12 . A second step  42  may entail customizing or modifying DR event  31  information in view of bids  37 . Bids may be just one example of information or variable. One or more of other items, such as shed levels, prices, demands, usage, and so forth, may be used apart from bids  37  or in combination with bids. A third step  43  may entail translating DR event  31  information in view of user preferences and translation rules  38 . 
     The second step  42  and the third step  43  may entail actually modifying the information that is encapsulated within DR signal  13 . Steps  41 ,  42  and  43  may be modeled as a set of Boolean equations which relate the following quantities: 1) Start time may be when the condition first becomes valid; 2) End time may be an end of when the condition is valid; 3) Variable may be either an input variable associated with the event  31  (e.g., price, shed level, bid, usage, and/or so forth), or it may be a telemetry variable that is fed back via real-time telemetry  45  to steps  42  and/or  43  from a client or customer&#39;s facility  27  synch as a usage or device state (for instance, the variables may typically be fixed and set by the definition of the DR program); 4) Condition may be logical Boolean operation that relates the one or more variables to some user defined value or values (for instance, this may be a typical sort of Boolean operations such as greater than, less than, equal, and so forth); and 5) Operations may be what is to be done if the rule is TRUE. 
     One way of representing these quantities or rules in a way that allows them to be easily edited by users may be in the form of an example table  40  as shown in  FIG. 8 . Table  40  may consist of a collection of rules. The top row may list headings indicating a rule, start time, end time, variable, condition, value, “operation 1: set simple level” and “operation 2: set price”. Table  40  shows just one instance of rules as these rules may be edited or there could be other rules which are different in type, kind, and/or number. Each rule number (for instance, 1, 2, 3 or 4) may represent a set of conditions, such as start time, end time, variable, condition, and value, in that when AND&#39;d together they result in a TRUE, which will execute the specified operation, such as an operation 1 of setting a simple level or an operation 2 of setting a price, as for instance in the example of table  40 . 
     In table  40 , there may be multiple types of operations other than those shown as examples, which can be executed, and rules, with conditions which are related to a particular operation, that may be logically grouped together so that the first rule, which relates to a particular operation, that is TRUE in terms of its conditions, is the rule which applies. In the example table, the conditions are “AND&#39;d”; however, there may be rules where the conditions are logically “OR&#39;d” in determining if rule is true for purpose of implementing a designated operation. The conditions may be connected in a combination of being logically “AND&#39;d” and “OR&#39;d” a truth determination of the respective rule and or the operation to be effected. 
     In rule one of table  40 , for example, the price level may be set to the “BID” level and thus this may be a representation of how a price level for a DR event  31  may be customized for a particular client  32 . In an actual deployment, this type of operation may probably be fixed by default by the business rules of the DR program and would not necessarily appear as an editable table to the user. 
     In rules 2-4 of table  40 , the operation may be set to the simple level of the DR signal  13 . This simplification may represent a type of signal translation in which the information associated with the DR event  31  (e.g., price) can be converted into a simpler representation. This does not necessarily imply that the price information is not also sent with the DR signals  13 , but it may mean that an alternate form (i.e., simple level) is also sent. This may give a great deal of flexibility to the client  32  in how it consumes the information and is supported by DR signal&#39;s specifications such as OpenADR. 
     There may be separate collections of rules for each client  32  and a DR program that client  32  is participating in. The nature of the DR program may define the variables that are associated with the program. For example, one program might use price while another might use shed level. Furthermore, feedback variables may be used in the rules as a way to modify the DR signals  13  in real time during the DR event  31  as could be shown as an instance in rule three. 
     The items in table  40  noted herein may be effected with a computer. Table  40  may be meant to allow for easy modification by end users and be just one representation of a set of rules that could be applied to converting a DR event  31  to a DR signal  13 . There may be other representations. There may be other ways of specifying the rules which relate the various variables and user specified conditions to values that appear in DR signal  13 . Sets of rules may be created using free form equations that are interpreted, or even some sort of programming language such as Java may be used. 
     An application which is relevant to the present application is U.S. patent application Ser. No. 12/834,841, filed Jul. 12, 2010, and entitled “A System for Providing Demand Response Services”, which claims the benefit of U.S. Provisional Patent Application No. 61/271,084, filed Jul. 17, 2009. U.S. patent application Ser. No. 12/834,841, filed Jul. 12, 2010, is hereby incorporated by reference. U.S. Provisional Patent Application No. 61/271,084, filed Jul. 17, 2009, is hereby incorporated by reference. 
     An application which is relevant to the present application is U.S. patent application Ser. No. 12/245,560, filed Oct. 3, 2008, and entitled “Critical Resource Notification System and Interface Device”, which claims the benefit of U.S. Provisional Patent Application No. 60/977,909, filed Oct. 5, 2007. U.S. patent application Ser. No. 12/245,560, filed Oct. 3, 2008, is hereby incorporated by reference. U.S. Provisional Patent Application No. 60/977,909, filed Oct. 5, 2007, is hereby incorporated by reference. 
     In the present specification, some of the matter may be of a hypothetical or prophetic nature although stated in another manner or tense. 
     Although the present system and/or approach has been described with respect to at least one illustrative example, many variations and modifications will become apparent to those skilled in the art upon reading the specification. It is therefore the intention that the appended claims be interpreted as broadly as possible in view of the prior art to include all such variations and modifications.