CROSS-REFERENCE TO RELATED APPLICATIONS 
       [0001]    This application claims priority to U.S. Provisional Patent Application No. 61/726,023, filed Nov. 14, 2012, the disclosure of which is hereby incorporated by reference in its entirety. 
     
    
     FIELD OF THE INVENTION 
       [0002]    The present invention relates generally to demand response (DR) measurement and verification (M&amp;V) and demand response (DR) device operability analysis; and more particularly to statistical algorithms applied to automatic detection of mechanical failures in dispatchable demand response assets. 
       BACKGROUND OF THE INVENTION 
       [0003]    Demand response (DR) is a mechanism to manage customer&#39;s consumption of electricity in response to supply conditions, for example, having electricity customers reduce their consumption at critical times or in response to market prices. Demand response is generally used to encourage consumers to reduce demand, thereby reducing the peak demand for electricity. Demand response gives the consumers the ability to voluntarily trim or reduce their electricity usage at specific times of the day during high electricity prices, or during emergencies. 
         [0004]    In other words, demand response is a resource that allows end-use electricity customers to reduce their electricity usage in a given time period, or shift that usage to another time period, in response to a price signal, a financial incentive, an environmental condition, or a reliability signal. Demand response saves ratepayer&#39;s money by lowering peak time energy usage that is high-priced. This lowers the price of wholesale energy, and in turn, retail rates. Demand response may also prevent rolling blackouts by offsetting the need for more electricity generation and can mitigate generator market power. 
         [0005]    There are two general classes of DR program—dispatchable and non-dispatchable. Non-dispatchable DR is not dependent on explicit signaling from the load serving entity (LSE) to the participant. Examples of non-dispatchable DR include time-of-use (TOU) and real time pricing (RTP) programs. In contrast, dispatchable demand response entails the load serving entity sending explicit signals to participants to reduce energy consumption during a specified time window. The signals can either communicate economic incentives to participants or control participant devices directly. An example of the former is critical peak price (CPP) demand response programs, while the latter are referred to as direct load control (DLC) demand response. 
         [0006]    For both types of dispatchable demand response there are switches and signal receptors at the participant site that must function properly for the desired load curtailment to be realized. An important issue facing load serving entities is that as large numbers of these devices fail, the overall effectiveness of the demand response (DR) program is severely degraded. Load serving entities can perform physical on-site inspections to monitor and fix broken devices, but this approach is extremely expensive to scale up to many thousands of participants if the inspections are not well-targeted to those sites with a high probability of device failure. Alternatively, waiting for participants to self-report a failed device before visiting a site can result in consistently poor demand response performance over the course of the program. 
         [0007]    Given the above, there is a huge value in a system that can analyze real-time and historical data on demand response event performance and automatically identify those participants that have a high-probability of device failure. The demand response optimization and management system for real time system contains an operability analysis engine (OAE) that employs advanced, customized statistical methods to generate a probability that a given participant has a device failure based on historical interval meter data. 
       SUMMARY OF THE INVENTION 
       [0008]    The present invention describes a highly distributed demand response optimization and management system. The system utilizes a scalable, web-based software-as-a-service platform that provides all program designs, implementation and execution, event management, forecasting, optimal dispatch and post-event analytics functionality. The system uses advance machine learning and robust optimization techniques for real-time and “personalized” demand response-offer dispatch. The system&#39;s learning engine keeps track of available demand side resources and history of participation in different demand response events at individual customer locations. This data is used to build a virtual profile for each customer that is able to forecast the amount of load-shed, shed-duration, and rebound effects for that customer given the time-of-day, weather and price signal. The virtual profiles for the customers are generated in an online manner and are continuously updated in real-time as more usage data becomes available. 
         [0009]    The embodiment of the present invention provides a demand response optimization and management system for real-time that comprises a utility data feed, a resource modeler, a forecasting engine, an optimization engine comprising an optimizer and a dispatch engine, a baseline engine, a customer/utility interface and a customer data feed. The arrangement described herein is provided with a control and communications platform to allow highly dispatchable demand response (DR) services in timeframes suitable for providing ancillary services to the transmission grid. The services are substantially more efficient than other forms of ancillary services options currently available to manage the intermittency associated with large-scale renewable integration. 
         [0010]    The present invention identifies operability failures in demand response assets by employing a customized 2-stage statistical method as a mixture model stage and a Bayesian update stage. The two customized stages generate the probability of a device failure for each demand response participant based on historical meter data and participant baseline load (PBL) estimates produced by an operability analysis engine (OAE). Demand response optimization and management system for real-time leverage the low-cost, open, interoperable demand response signaling technology, open automated demand response (OpenADR), and internet-protocol based telemetry solutions to reduce the cost of hardware, allowing DROMS-RT to provide dynamic price signals to millions of open automated demand response clients. The present invention described herein has its implementation in the demand response system; however it does not limit the scope of the described invention. 
       ABBREVIATIONS AND DEFINITIONS 
       [0011]    Demand Response Optimization and Management System for Real-Time (DROMS-RT): DROMS-RT is a highly distributed demand response optimization and management system for real-time power flow control to support large scale integration of distributed generation into the grid. 
         [0012]    Demand Response (DR): Demand response is a mechanism to manage customer consumption of electricity in response to supply conditions. DR is generally used to encourage consumers to reduce demand, thereby reducing the peak demand for electricity. 
         [0013]    Forecasting Engine (FE): The forecasting engine generates short-term forecasts of participant-level baseline load (BL). 
         [0014]    Operability Analysis Engine (OAE): The operability analysis engine generates the probability that a given participant has a device failure, based on historical DR event results. 
         [0015]    Participant Baseline Load (PBL): The estimated non-curtailed load of a participant over a period of time; that is, the load that would have happened had a DR event not been called for the time interval in question. 
         [0016]    Load Serving Entities (LSE): A load-serving entity secures energy, transmission and related interconnected operations services, to serve the electrical demand and energy requirements of its end-use customers. 
         [0017]    Measurement and Verification (M&amp;V): Measurement and verification (M&amp;V) is the independent analysis and reporting of demand side management and energy efficiency (DSMEE) saving impacts. 
         [0018]    Real Time Pricing (RTP): Real time pricing means tarrifed retail charges for delivered electrical power and energy that vary hour-to-hour. 
         [0019]    Critical-Peak Pricing (CPP): Critical-peak pricing is a pricing technique that helps to reduce electricity bill and it can be used in periods of high electricity demand. 
         [0020]    Direct Load Control (DLC): Direct load control allows a utility to turn on and off specific appliances during peak demand periods. 
         [0021]    Time Of Use (TOU): Time of use means that the electricity prices are set for a particular time period on an advance basis. 
         [0022]    Cumulative Distribution Function (CDF): Cumulative distributive function gives the probability that a random variable is less than or equal to the independent variable of the function. 
         [0023]    Expectation-Maximization (EM) algorithm: EM algorithm is an iterative method for finding maximum likelihood estimates of parameters in statistical models, where the model depends on unobserved latent variables. 
         [0024]    Failure Detection Engine (FDE): Failure detection engine is used for automatic detection of mechanical failures in dispatchable DR assets. 
         [0025]    Baseline Load (BL): Baseline load is a key to accurately assess the load impacts from certain types of demand response programs, particularly those that pay directly for load reductions. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0026]    The preferred embodiment of the invention will hereinafter be described in conjunction with the appended drawings provided to illustrate and not to limit the scope of the invention, wherein like designation denote like element and in which: 
           [0027]      FIG. 1  is a schematic representation of the demand response optimization and management system for real-time, in accordance with an embodiment of the present invention. 
           [0028]      FIG. 2  is a block diagram illustrating the inputs and outputs of the operability analysis engine, in accordance with an embodiment of the present invention. 
       
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
       [0029]    In the following detailed description of the embodiments of the invention, numerous specific details are set forth in order to provide a thorough understanding of the embodiments of the invention. However, it will be obvious to a person skilled in the art that the embodiments of the invention may be practiced without these specific details. In other instances well known methods, procedures and components have not been described in details so as not to unnecessarily obscure aspects of the embodiments of the invention. 
         [0030]    Furthermore, it will be clear that the invention is not limited to these embodiments only. Numerous modifications, changes, variation, substitutions and equivalents will be apparent to those skilled in the art without parting from the spirit and scope of the invention. 
         [0031]    Referring to  FIG. 1 , a demand response optimization and management system for real-time comprises a utility data feed  101 , a resource modeler  102 , a forecasting engine  103 , an optimization engine  104 , a baseline engine  105 , a customer/utility interface  106  and a customer data feed  107 . The demand response optimization and management system for real-time connects to the utility&#39;s backend data system  101  on one side and customer end-points  108  on the other side. The demand response optimization and management system receives live data-feeds from either or both the customer data feed  107  and the utility data feed  101  to calibrate the forecasting and optimization functions of DROMS-RT, during the execution of a demand response event. However, some of the feeds may not be available all the time or in real-time; the forecasting engine  103  is able to run in an “off-line” manner or with partial data feeds in these cases. 
         [0032]    The demand response resource modeler  102  within demand response optimization and management system for real-time keeps track of all the available demand response resources, their types, their locations and other relevant characteristics such as response times, ramp-times etc. The resource modeler  102  continuously updates the availability of resources affected by commitment to or completion of an event and monitors the constraints associated with each resource such as the notification time requirements, number of events in a particular period of time, number of consecutive events and user preferences to determine a “loading order” as to which resources are more desirable for participation in demand response events from a customer&#39;s perspective and the contract terms the price at which a resource is willing to participate in an event. The resource modeler  102  gets data feed from the client to determine if the client is “online” (i.e. available as a resource) and whether the client has opted-out of the event. 
         [0033]    The forecasting engine  103  gets the list of available resources from the resource modelers  102 . The forecasting engine  103  performs short-term forecasts of aggregate load and available load-sheds for individual loads connected to the demand response optimization and management system for real-time. The forecasting engine  103  accounts for a number of explicit and implicit parameters and applies machine learning (ML) techniques to derive short-term load and shed forecasts as well as error distributions associated with these forecasts. The estimation of error distribution improves the overall robustness of optimization and helps to separate small load sheds during the events. The forecasting engine  103  gets continuous feedback from the client devices through the baseline engine  106  and increases its forecasting ability as more data becomes available to the system. 
         [0034]    The optimization engine  104  comprises an optimizer and a dispatch engine. The optimization engine  104  takes the available resources and all the constraints from the resource modeler  102  and the forecasts of individual loads and load-sheds and error distributions from the forecasting engine  103  to determine the optimal dispatch of demand response under a given cost function. The optimization engine  104  incorporates a variety of cost functions such as cost, reliability, loading order preference, GHG or their weighted sum and makes an optimal dispatch decision over a given time-horizon that could cover day-ahead and near real-time horizons simultaneously. The optimization engine  104  is able to automatically select the mix of demand response resources best suited to meet the needs of the grid such as peak load management, real-time balancing, regulation and other ancillary services. 
         [0035]    The baseline engine  105  verifies whether a set of customers have met their contractual obligation in terms of load-sheds. The baseline engine  105  uses signal processing techniques to identify even small systematic load sheds in the background of very large base signals. The forecasting engine  103  provides baseline samples and the error distribution to the baseline engine  105 . In addition, the baseline engine  105  gets the data feed from the meter which is the actual power consumption data. The baseline engine  105  uses ‘event detection’ algorithm to determine whether the load actually participated in the demand response event, and if so, what the demand reduction due to this event was. The baseline engine  105  feeds data back to the forecasting engine  103  so that it could be used to improve the baseline forecast. 
         [0036]    Referring to  FIG. 2 , the present invention  200  identifies likely operability failures in demand response assets by employing a customized 2-stage statistical method that generates the probability of a device failure  207  for each demand response participant based on historical meter data  203  and participant baseline load (PBL) estimates  204  produced by the operability analysis engine (OAE)  200 . 
         [0037]    As a pre-requisite for running the operability analysis engine (OAE), the demand response optimization and management system for real-time collects and stores meter interval data  203  from utility data feed  101  and customer data feed  107  through a large-scale data storage technology such as Hadoop/Hbase. In addition, the forecasting engine (FE)  103  generates participant baseline load values  204  from the data available in the baseline engine  105  for each historical time interval. These values are estimates of what the load would have been in the absence of any demand response event. For each (DR event, participant) combination in the historical data, the operability analysis engine  200  generates a dataset comprising the following quantities: 
         [0000]    
       
         
           
             
               
                 
                   
                     
                       x 
                       
                         i 
                         , 
                         j 
                       
                     
                     = 
                       
                      
                     
                       observed 
                        
                       
                           
                       
                        
                       percentage 
                        
                       
                         
                             
                         
                          
                         
                             
                         
                       
                        
                       load 
                        
                       
                           
                       
                        
                       reduction 
                        
                       
                           
                       
                        
                       for 
                        
                       
                           
                       
                        
                       event 
                        
                       
                           
                       
                        
                       i 
                     
                   
                   , 
                   
                     participant 
                      
                     
                         
                     
                      
                     j 
                   
                 
               
             
             
               
                 
                   = 
                     
                    
                   
                     load_shed 
                     / 
                     baseline 
                   
                 
               
             
             
               
                 
                   = 
                     
                    
                   
                     
                       ( 
                       
                         
                           b 
                           
                             i 
                             , 
                             j 
                           
                         
                         - 
                         
                           a 
                           
                             i 
                             , 
                             j 
                           
                         
                       
                       ) 
                     
                     / 
                     
                       b 
                       
                         i 
                         , 
                         j 
                       
                     
                   
                 
               
             
           
         
       
     
       Where, 
       [0038]    b i,j =estimate of baseline load produced by the forecasting engine
 
a i,j =actual realized load
 
The goal of the operability analysis engine  200  is to infer from the dataset of x i,j &#39;s the probability of device failure for each participant. It does this in two steps: Firstly, fit a mixture model  205  to the dataset X comprising two populations, one corresponding to participants with fully operable devices (population A), the other corresponding to those with non-operable devices (population B). Outputs of this step are:
 
w A =proportion of all participants that are in A; w B =(1−w A )=proportion of all participants that are in B; F A (x)=cumulative distribution function (c.d.f.) for population A; and F B (x)=cumulative distribution function (c.d.f) for population B. Secondly, for each participant j, compute Bayesian updates  206  of the probability that j has a non-operable device, given a set of realized event outcomes x j .
 
         [0039]    This two-step approach allows for different choices of distribution in the mixture model step, as well as different definitions of realized event outcomes in the Bayesian update step. In one instance of the invention the dataset can be modeled as a mixture of two lognormal distributions. The lognormal distribution enables observed loads for population A (participants with operable devices) to be expressed as a multiplicative set of factors: 
         [0000]      observed_load i,j   =b   i,j   *e   i,j   *S*z   i,j    
       Where, 
       [0040]    b i,j =estimate of baseline load produced by the forecasting engine for event i, participant j
 
e i,j =log-normal noise term that captures baseline error, mean=1
 
S=average load shed multiplier for the population
 
z i,j =log-normal noise term that captures variance in load shed, mean=1
 
The observed percentage load shed is therefore:
 
         [0000]    
       
         
           
             
               
                 
                   
                     x 
                     
                       i 
                       , 
                       j 
                     
                   
                   = 
                     
                    
                   
                     
                       observed_load 
                       
                         i 
                         , 
                         j 
                       
                     
                     / 
                     
                       b 
                       
                         i 
                         , 
                         j 
                       
                     
                   
                 
               
             
             
               
                 
                   = 
                     
                    
                   
                     
                       e 
                       
                         i 
                         , 
                         j 
                       
                     
                     * 
                     S 
                     * 
                     
                       z 
                       
                         i 
                         , 
                         j 
                       
                     
                      
                     s 
                   
                 
               
             
           
         
       
     
         [0000]    Taking logs produces: 
         [0000]      log( x   i,j )= e′   i,j   +S′+z′   i,j    
         [0041]    In this expression, e′ and z′ are noise terms with mean 0 and var e  and var z , respectively, and S′ is the natural log of the average load shed multiplier S. Under this model, the log of the observed load sheds for participants with operable devices is normally distributed with mean S′, and variance var e +var z . 
         [0042]    For participants in population B (i.e. those with non-operable devices), there is no demand response induced load shed by definition, so the model reduces to: 
         [0000]      observed_load i,j   =b   i,j   *e   i,j    
       Where, 
       [0043]        x   i,j =observed_load i,j   /b   i,j    
         [0000]    x i,j =e i,j    
         [0000]      log( x   i,j )= e′   i,j    
         [0000]    The log of the observed load sheds for population B participants is normally distributed with mean 0 and variance var e . Note that the population A participants have two sources of variance—baseline error and load shed variability—while population B participants only have the first source of variance. With the log-normal assumption, the logged data can therefore be modeled as a mixture of two normal distributions:
 
Population A˜N(S′, var e +var z )
 
Population B˜N(0, var e )
 
         [0044]    Note that in this formulation there are only 3 unknowns that need to be estimated—S′, var e  and var z . The operability analysis engine estimates these 3 quantities, plus the weighting proportion w A , using the well-known expectation-maximization (EM) algorithm. Once S′, var e  and var z  are estimated, the log-normal c.d.f.&#39;s F A (x) and F B (x) are derived. 
         [0045]    In a specific instance of the invention, the Bayesian update step of the method is implemented using parameters (both prior and conditional probabilities) derived from the mixture model:
       Use F A (0) and F B (0) to calculate the probabilities p A  and p B , the probability of negative load shed for population A and B, respectively.   Calculate the probability of observing x negative load sheds out of N events using the binomial distribution with probability p and sample size N.   Given a participant&#39;s observed number of positive load sheds after N events, calculate the probability of being in population B (i.e. having a non-operable device) using Bayes&#39; Rule:       
 
         [0000]        p ( B|x )= p ( x|B )* p ( B )/[ p ( A )* p ( x|A )+ p ( B )* p ( x|B )] 
       Where, 
       [0049]    P(x|B)=binom(p B , N)
 
p(x|A)=binom(p A , N)
 
         [0000]    
       
         
           
             
               
                 
                   
                     p 
                      
                     
                       ( 
                       A 
                       ) 
                     
                   
                   = 
                     
                    
                   
                     the 
                      
                     
                         
                     
                      
                     weighting 
                      
                     
                         
                     
                      
                     factor 
                      
                     
                         
                     
                      
                     from 
                      
                     
                         
                     
                      
                     the 
                      
                     
                         
                     
                      
                     mixture 
                      
                     
                         
                     
                      
                     model 
                   
                 
               
             
             
               
                 
                   = 
                     
                    
                   
                     w 
                     A 
                   
                 
               
             
           
         
       
       
         
           
             
               p 
                
               
                 ( 
                 B 
                 ) 
               
             
             = 
             
               ( 
               
                 1 
                 - 
                 
                   w 
                   A 
                 
               
               ) 
             
           
         
       
     
         [0050]    Demand response optimization and management system for real-time generates a report of the updated probabilities p(B) associated with each participant after each demand response event. Users can then take appropriate remedial action for those participants with high probability of device failure, thereby greatly increasing the efficacy of dispatchable demand response programs. 
         [0051]    The advantages of the present invention are implementation of a system for automatic detection of mechanical failures in dispatchable demand response assets that results in reduced cost and increase in demand response performance during the course of the program.
The present invention demonstrates a highly distributed demand response optimization and management system for real-time (DROMS-RT) power flow control to support large scale integration of distributed renewable generation into the grid. The system is a cloud-based platform that reduces critical peak power safely and securely. The arrangement is provided with a control and communications platform to allow highly dispatchable demand response (DR) services in timeframes suitable for providing ancillary services to the transmission grid. The services are substantially more efficient than other forms of ancillary service options currently available to manage the intermittency associated with large-scale renewable integration.