JP2014531658A - An extensible web-based DR platform that communicates DR signals using a network server - Google Patents

Abstract

An extensible web-based demand response platform for optimizing and managing demand response resources is provided. The optimization and management includes a server, a program design module, a customer portal module, a predictive optimization module, an event management module, an application programming interface, and an analysis module for performing data feed analysis. Is achieved by using The platform is provided to users in a software as a service model. [Selection] Figure 1

Description

  The present invention relates generally to demand response (DR) management, and more particularly to a communication channel for real-time demand response signaling between a server and a client. Furthermore, the system can be used as a software-as-a-service (SaaS) model.

CROSS REFERENCE TO RELATED APPLICATIONS This application is a US Provisional Patent Application No. 61/61 entitled “Software-as-a-Service (SaaS) for Optimization and Management of Demand Response and Distributed Energy Resources” filed on September 16, 2011. US Provisional Patent Application No. 61/535, entitled “System and Method for Optimization of Demand Response and Distributed Energy Resources and Management Thereof” filed on September 16, 2011, claiming priority benefit to 535,369. Priority to US Provisional Patent Application No. 61 / 535,371 entitled “Multi-Channel Communication of Demand Response Information between Server and Client” filed on September 16, 2011, claiming priority benefit to No. 365 The contents of each of which are hereby incorporated by reference in their entirety.

  Demand response (DR) is based on supply conditions, for example, so that customers can reduce their electricity consumption during critical times or depending on market prices. It is a mechanism to manage. Demand response is typically used to encourage customers to reduce demand, thereby reducing peak demand for electricity. Demand response gives customers the ability to voluntarily reduce or reduce their electricity usage during certain times of day when electricity charges are high or during emergencies.

  Demand response (DR) program automation is widely accepted as an effective solution in the industry to shift electrical loads and to limit electrical loads. Unfortunately, many of the industry solutions available today are not standardized, causing problems for utilities, aggregators and regulators. The OpenADR Alliance was established to accelerate the development, adoption and compliance of the OpenADR standard throughout the energy industry.

  Demand response (DR) is a series of actions taken to reduce the load when an unforeseen event in the distribution network threatens the supply-demand balance or when market conditions arise that increase the cost of power generation. Automatic demand response consists of fully automated signaling from the utility, ISO / RTO or other suitable entity that provides automatic connectivity to the customer end-use control system and strategy. OpenADR provides a platform for interoperable information exchange to facilitate automatic demand response.

  The OpenADR Alliance is interested in facilitating the deployment of low-cost, reliable demand-response communication protocols by facilitating and accelerating the development and adoption of OpenADR standards and compliance with standards Includes industry stakeholders. These standards include de facto standards based on specifications published by LBNL in April 2009, and smart grid related standards emerging from OASIS, UCA and NAESB.

  With existing technology, demand response platforms require extensive facilities at individual user sites. The installation and upgrade of hardware and software at individual user sites is very costly and difficult.

  Unlike traditional software, which will be upgraded once a year or once every six months (the merchant will come to the office with a CD), SaaS customers will be offered new mechanisms and functions by paying a distribution registration fee. Instant access. Software-as-a-service providers continuously deliver updates and modifications to the application, which customers can immediately access. This reduces the time and expense associated with software upgrades and maintenance.

  In the traditional model, the customer purchases a license for the software and obtains ownership for its maintenance and installation, whereas in the case of Software Asa Service (Saas), the ownership for maintenance and installation is Left to the contractor. It is a new model for distributing software. Software as a service refers to software that is accessed via a web browser through paying a monthly or yearly subscription.

  Today's demand response systems require significant direct investment in IT infrastructure and personnel to design and implement new programs. At the pilot scale, these investments are difficult to justify, and most pilots have not reached the scale necessary to repay their costs directly, so utilities are reluctant to make these investments. is there. Even in the case of using a conventional IT model, the program becomes unattractive because it needs to be passed on to the customer as the cost of implementing the program increases. Providing a software as a service (Saas) model removes this major barrier to the provision of new programs by DROMS-RT. The system can use new programs easily and cost-effectively. As more programs are introduced, the system will also serve customers in various fields and achieve high support and customer satisfaction.

  Accordingly, in one aspect of the present invention, an extensible web-based demand response platform is provided that optimizes and manages demand response resources. The system includes a server having a storage medium, a processor and a computer readable medium; a program design module for adding, viewing and editing constraints associated with demand response programs and demand response events; and utilities, participants And customer portal module to manage system operator information, predictive optimization module to calculate baseline volume and load limits and customer payments, event management module for manual and automatic event creation and schedule notification, and measurement confirmation And an application programming interface communicatively coupled to a server for two-way communication of utility feed back-end data systems and data feeds from customer endpoints, and data It is composed of a analysis module to perform an analysis of de, the platform, available to a user in the software Azua service model.

  In another aspect of the invention, a system implemented by a network server that facilitates communication of demand response signals is provided. The system includes a demand response server hosted in a cloud network, a network of utility operators and independent system operators connected to a plurality of electricity customers at various sites through the demand response server, and a demand response server. The demand response server can communicate with the utility operator, independent system operator, electricity customer, and load aggregator API through the application programming interface. This is done through simultaneous multi-channel communication protocols and physical media.

  In the following, preferred embodiments of the present invention will be described with reference to the accompanying drawings, which are given to illustrate the invention without limiting the scope of the invention. In the drawings, like numerals represent like elements.

FIG. 2 is a block diagram illustrating the operation of a real-time demand response optimization and management system for generating user profile specific algorithms and supporting large scale integration of distributed renewable generation into a distribution network, according to one embodiment of the invention. is there.

FIG. 4 is a schematic diagram of a dynamic demand response (DR) resource model input and a portfolio of dynamic demand response (DR) resources, according to one embodiment of the invention.

It is the schematic which shows the multichannel communication of the demand response information between a server and a client.

Schematic showing OpenADR, a communication data model, designed to facilitate transmission and reception of demand response signals between utilities or independent operators and electricity customers, according to one embodiment of the present invention. It is.

  The present invention demonstrates that off-the-shelf communication technology based on Internet protocols can be used for real-time DR applications by adapting. Furthermore, the present invention can provide a sufficient level of safety and reliability sufficient to operate a power distribution network, which is a core business, at a relatively low cost. A Software as a Service (SaaS) business model is provided that optimizes and manages demand response and distributed energy resources.

  In one embodiment of the present invention, the main objective is to build an extensible web-based software as-a-service platform that provides all of program design, program implementation, program execution, event management, prediction, optimal power supply, and post-event analysis functions It is to be. Make optimal power delivery decisions on the time scale required to provide incidental services while ensuring scalability, reliability, fault tolerance, and throughput requirements, and reliably communicate to myriad endpoints be able to. Software as a Service (SaaS) is a software application distribution model that allows utilities to host and operate web-based software applications used by their customers over the Internet. The software and associated data are centrally hosted and accessed by users through the Internet.

  Software as a service (SaaS) implementations are faster and more cost effective than existing software distribution models. There are no hardware costs and implementation or acquisition costs associated with running applications from the customer side. It is the responsibility of the software as a service provider to manage and execute the application while ensuring the highest safety, performance and reliability.

  The Software as a Service (SaaS) model can reduce deployment and equipment costs, and provides a platform that allows all small commercial and residential customers to participate in demand response.

  Furthermore, Software as a Service (SaaS) is on-demand software provided as a service to end users. It is a distribution model in which software and related data are centrally hosted and accessed by users over the Internet. The Software as a Service (SaaS) platform provides facilities that make the project scalable and reliable. In addition, SaaS provides a suitable platform for all program design, resource modeling, prediction, optimal power supply and measurement functions.

  The Software as a Service (SaaS) platform is designed for the implementation and management of demand response programs. The system architecture for developing the SaaS platform includes a server, a program design module, a customer portal module, a predictive optimization module, an event management module, and utility back-end data for measurement confirmation and verification. An application programming interface that is communicatively coupled to a server for two-way communication of data feeds from the system and customer endpoints, and an analysis module that performs analysis of the data feed.

  System architecture servers use the OpenADR standard for signaling, are hosted in a cloud network through a web interface, and are distributed across multiple geographic locations. The software as a service platform has a customer portal module operated through a web interface, and information managed by the customer portal module includes addition of a participant and registration of a participant for the program or cancellation of delivery.

  In another embodiment of the present invention, in order to provide or facilitate the exchange of data between different client nodes connected to a centralized server system via the Internet cloud, a DRROM-RT (Real Time Demand Response Optimization) Multi-channel communication between the server and the client in the network and management system) is required. A server is a computer or series of computers that link other computers or electronic devices together. The server provides basic services across the network to individual users in large organizations or public users over the Internet. A client is an application or system that accesses a service made available by a server.

  An activity record is sent by the client device, which is then received and processed at the other end in order to perform a robust and optimized error-free real-time event. In order to provide or facilitate the exchange of data between different client nodes connected to a centralized server system via the Internet cloud, multi-channel communication between the server and the client is required.

  FIG. 1 is a schematic diagram illustrating the operation of the system according to one embodiment of the invention. Referring to FIG. 1, there is provided an architecture for optimizing and managing a demand response system in real time that can be provided under a software as a service (SaaS) model. The system 100 includes a resource modeler 102, a prediction engine 104, an optimization engine 106, a dispatch engine 108, and a baseline calculation and confirmation engine 110. DROMS-RT is coupled to the utility back end data system 112 on the one hand and to the customer endpoint 114 on the other hand.

  A DR resource modeler (DRM) 102 in the system 100 tracks all available DR resources, their types, their locations, and other related characteristics such as response times, ramp times, and the like. The prediction engine (FE) 104 obtains a list of available resources from the resource modeler. Its focus is to perform a short-term prediction of the total load and available load limits for the individual loads connected to the system 100. In practice, some amount of feed may not be available at any time or in real time. In such cases, the prediction engine can operate “offline” or with a partial data feed. The optimization engine (OE) 106 captures the resources and all constraints available from the demand response resource modeler, and captures individual load and load limit predictions and error distributions from the prediction engine, for a given cost function. Determine the optimal dispatch of the original demand response. Baseline calculation and decision engine 110 uses signal processing techniques to identify even small systematic load limitations in the context of very large underlying signals. The system is coupled to a customer data feed 114 on one side to receive an occasional data feed from the customer end device. The system is coupled to the utility data feed 112 on the other side, and the data from the utility data feed 112 is provided to calibrate the prediction model and the optimization model and execute a demand response event. The system 100 includes a shipping engine 108 that helps customers make decisions and uses these resource-specific probabilistic models to generate customer bids from demand responses (International Organization for Standardization). Demand response signals are routed across a portfolio of customers or optimally routed to customers based on bids passed or other constraints of the distribution network. The system uses a customer / utility interface 116 that is connected to a baseline engine, which provides an interface between the system and the customer or utility. The goal of the system 100 is to provide generally real-time DR events and price signals to customer endpoints to optimally manage available demand response resources.

  The demand response resource modeler 102 monitors constraints associated with the demand response event, which event duration, notification window, power outage time, valid time, and the number of times a customer may be required to participate in the event. including. The demand response resource modeler 102 also monitors constraints associated with each resource, such as notification time requirements, number of events within a specific time period, number of consecutive events. The demand response resource modeler 102 also determines the user priority that determines the “load order” regarding which resources are more desirable to participate in the demand response event from the customer's perspective, and the contract period during which the resource accepts participation in the event. And price can also be monitored. The demand response resource modeler also obtains a data feed from the client and determines whether the client is “online” (ie, available as a resource) or has opted out of the event.

  The prediction engine 104 takes into account a plurality of explicit and implicit parameters and applies machine learning (ML) techniques to derive short-term load and limit predictions and error distributions associated with these predictions.

  The overall robustness of the optimization is improved by estimation of the error distribution, which further helps isolate small load limits during the event. The prediction engine obtains continuous feedback from the client device through the baseline engine and enhances its prediction capabilities as more data becomes available to the system. The prediction engine can also update the demand response resource modeler for load order priorities by implicitly learning the type of decision that the client device is making to the DR event proposal.

  The optimization engine (OE) (106) can incorporate various cost functions such as cost, reliability, load order priority, GHG or their weighted sum, one day prior and near real-time planning period. It is possible to make an optimum power supply decision over a given planning period that can cover all of them simultaneously. The system can automatically select a combination of DR resources that is best suited to meet the demands of the distribution network, such as peak load management, real-time balancing, regulation and other ancillary services.

  Using a mathematical formulation of the optimization problem, it can be seen how an approximate dynamic programming (ADP) algorithm can be used to solve the problem. The optimization can also take into account errors in the distribution itself and implement a robust ADP algorithm that avoids very sudden changes, irregular prices, and control policies that result in multiple demand curves. The optimization engine 106 can also be used to generate bids for the wholesale market based on the information from the demand response resource modeler 102 and the wholesale market price forecast that can be supplied externally.

  The Baseline Calculation and Confirmation Engine (BE) (110) verifies whether a set of customers all meet contractual obligations for load limiting. The baseline calculation and decision engine uses signal processing techniques to identify even small systematic load limits in the context of very large underlying signals.

  System 100 uses advanced machine learning and robust optimization techniques for real-time and “individual” DR-proposed powering. It keeps a unified view of demand-oriented resources available, with a history of participation in all available demand response programs and different demand response events at individual customer locations. The demand response resource model is dynamic because it changes based on current conditions and various advanced notification requirements.

  Build a self-calibration model for each customer, using historical time series data from past participations, which can predict the capacities, ramp times and rebound effects for that customer, given time, weather and price signals . By using machine learning algorithms, the prediction accuracy can be improved using many variables such as resident feedback.

  These profiles are necessarily probabilistic, and the predictions also quantify individual resource variability. The system 100 incorporates a decision engine that uses these resource-specific probabilistic models to route demand response signals across the customer's portfolio to generate ISO bids from demand response (International Organization for Standardization). Or optimally dispatching demand response signals to customers based on bids passed or other constraints of the distribution network. Various cost functions such as cost, reliability, load order priority or GHG are incorporated in the decision engine.

  FIG. 2 is a schematic diagram illustrating a dynamic DR resource model input and a portfolio of dynamic DR resources according to an embodiment of the present invention. Referring to FIG. 2, a unique dynamic DR resource model (204) is provided for each load. The model uses as input (202) facilities type and usage, connected load, historical daily profile, day of the week, time of day, to create a portfolio of DR resources (206). Historical demand response performance, ambient temperature, weather forecast, on-site power generation forecast, measured and scheduled occupancy and process data, customer demand response program selection, control and communication system normality, and location information And the portfolio is further used by the system 100 to generate simulated power for each utility ISO signal.

  The system 100 can manage a portfolio of demand response resources of various performance characteristics over a given planning period that will span both a day ago and near real-time situations. The system 100 is best suited to meet the demands of the distribution network (reducing excessive load in the target area, implementing peak reduction in unforeseen circumstances, providing regulation and other ancillary services, etc.) A combination of resources can be automatically selected.

  Demand proposals generated for individual customers have been optimized using robust optimization techniques that can effectively handle uncertainties in model parameters. DR is considered an online learning and optimization problem, and the decision maker learns the demand distribution and determines the demand adjustment. When reacting to the current maximum likelihood, the estimation of demand can result in control policies that result in very sudden changes, irregular prices, and multiple demand curves. The robust optimization technique stabilizes this variation and delays the change until the uncertainty in the distribution is fully resolved.

  The system 100 is based on a nationally recognized NIST accredited communication data model known as OpenADR (Open Automatic Demand Response). Demand response (DR) program automation is widely accepted as an effective solution in the industry to shift electrical loads and to limit electrical loads. Automatic demand response consists of fully automated signaling from the utility, ISO / RTO or other suitable entity that provides automatic connectivity to the customer end-use control system and strategy. OpenADR provides a platform for interoperable information exchange to facilitate automatic demand response. OpenADR is an open automatic demand response and is applied to a set of communication specifications. OpenADR allows system 100 to directly configure an interface with an increasing building energy management system. Several energy management systems already have OpenADR for the market one day ago, allow for capacities greater than 100 MW and are employed by more than 60 utilities and smart grid operators.

  The OpenADR specification is extended to handle the real-time requirements of providing incidental services. Through the adoption of the fully automatic OpenADR communication protocol, the ROMOS-RT minimizes or eliminates the need for “human-involved” control.

  FIG. 3 is a schematic diagram illustrating two-way communication using an OpenADR server according to an embodiment of the present invention. Referring to FIG. 3, there is bidirectional communication between the OpenADR server (304) and the participants (306) using electronic mail, AMI network, broadband, or CPN. Any device using web access, such as Wi-Fi PCT, such as RTCOA, can communicate with the server through a device portal in the server. The server communicates with a utility backend system (302) such as EMS, DMS, GIS, CIS and MDM / billing to receive signals indicating the type and duration of ancillary services required. To do.

  Demand response multi-channel communication is used to provide a number of web-based services such as program design, resource modeling, prediction, optimal dispatch and measurement functions, public internet connection, Wi-Fi, RDS (Radio Data System), Includes email, text and phone. Event schedule notification will support multi-channel communications such as Wi-Fi, RDS, email and telephone.

  Secure, low cost communication channels and protocols that allow the use of the OpenADR specification for real-time DR signaling have been tested.

  OpenADR is a communication data model designed to facilitate the transmission and reception of DR signals between utilities or independent operators and endpoint users. The data model is intended to interact with pre-programmed buildings and industrial control systems to take action based on DR signals, thereby fully automating demand response events without human intervention Is to make it possible. The open specification is intended to allow anyone to implement a signaling system, automatic server or automatic client. This system is being deployed around the world under the guidance of the National Institute of Standards and Technology (NIST).

  FIG. 4 illustrates an OpenADR, communication data model designed to facilitate transmission and reception of DR signals between utilities or independent operators and electricity customers, according to one embodiment of the present invention. It is the schematic which illustrates. Referring to FIG. 4, a demand response automatic server (402), a standardized application programming interface (API) (404), a load aggregator (408) and a plurality of sites A, Site B, Site C, Site D, and Site E. The site is shown. The demand response automatic server (402) uses a plurality of communication protocols and physical media through a network cloud to transmit and receive demand response signals between a utility or independent system operator (ISO) and a customer. Standardization of load aggregator (408) and utility sites or independent system operators (ISO) or customer sites such as site A and site B at multiple sites such as site C, site D, and site E It is configured to communicate via a programming interface (API) (404).

  The OpenADR server of system 100 is hosted in the cloud, distributed across multiple geographic regions, and accessible through the Internet. The demand response server uses the OpenADR standard for signaling. The utility operator and the independent operator are connected to the customer through the demand response server using the web API. Signal communication between the customer and the demand response server is bi-directional, and the demand response server transfers the demand response signal directly to the customer or through a load aggregator.

  The system 100 can use a load balancer to distribute the computational load across the cluster of servers and scale the cluster according to the load.

  In addition to monitoring and alerting the capabilities provided by the cloud infrastructure provider, the system 100 uses a 24 × 7 monitoring and alerting system, such as Nagios, Ganglia.

  SQL is a structured query language for accessing and manipulating databases. SQL is a programming language designed to manage data in a relational database management system (RDBMS). System 100 has full SQL database replication to “hot standby” in different zones for failover.

  The DROMS-RT architecture has a fault-tolerant capability (due to data block replication) inherent to NoSQL database / Hadoop file system (HDFS), which is designed for server / component failures during normal operation and system Expect the failure without affecting the overall behavior.

  Automatic deployment of DROMS-RT using Chef server recipes allows for rapid deployment to another geographic location or, at worst, another cloud infrastructure provider.

  In addition to using open standards such as OpenADR and EnergyInterOp, the system 100 server can communicate with any proprietary client API using a “proxy”. These proxies are loosely coupled software agents that operate within the DROMS-RT server to translate communications between the standards compliant server and the device specific API.

  The unique architecture of the system 100 allows any number of proxies to be created and can operate concurrently with other processes. DROMS-RT can handle a myriad of such proxies simultaneously to increase reliability and tolerate failures.

  System 100 server receives a signal from the ISO / RTO system indicating the type and duration of ancillary services required. In doing so, the system 100 server optimally powers demand-oriented resources that serve as a “pseudo-generator” to meet the grid operator's ramp rate and limit duration requirements.

  All previous implementations of servers based on OpenADR include OpenADR, Smart Energy Profile1. x / 2. Many communication protocols such as x and EnergyInterOp cannot be used to support simultaneous multi-channel communications such as email, text, RDS, broadband Internet and cellular links. This greatly limits the applicability of DR, and customers and utilities service providers must constantly worry about interoperability, and separate IT infrastructure to manage end devices using different protocols. This increases the management cost of the DR program.

  System 100 can provide bi-directional communication between a server and an end device using multiple channels. Endpoint devices are also multi-channel and participate in or “opt-out” any particular DR event using a “response confirmation” mechanism that can use email, the Internet or Advanced Metering Infrastructure (AMI). Can communicate the intentions.

System 100 can provide bi-directional communication between a server and an end device using multiple channels. Endpoint devices are also multi-channel and participate in or “opt-out” any particular DR event using a “response confirmation” mechanism that can use email, the Internet or Advanced Metering Infrastructure (AMI). Can communicate the intentions.
[Item 1]
A software as a service platform that optimizes and manages demand response resources,
A server having a storage medium, a processor and a computer readable medium, and communicatively coupled to a utility operator system and a customer endpoint;
A first module in the server for designing a demand response event, the first module allowing a user to add, view and edit a demand response event;
An application programming interface communicatively coupled to the server and enabling two-way communication of the utility operator's system and a data feed from the customer endpoint for measurement confirmation and verification;
A second module for analyzing the data feed provided by the application programming interface, wherein the second module is a baseline of electricity usage associated with the demand response event designed in the first module; A second module for calculating quantities, load limits and payments; and
A software-as-a-service platform that optimizes and manages demand response resources.
[Item 2]
Item 2. The platform of item 1, wherein the server uses the OpenADR standard for signaling.
[Item 3]
Item 2. The platform of item 1, wherein the server is hosted in a network through a web interface and distributed across multiple geographic locations.
[Item 4]
The platform of claim 1, wherein the demand response event includes an event duration, a notification window, a power outage time, a valid time, and a number of times a customer may be required to participate in the event.
[Item 5]
Item 2. The platform of item 1, wherein the second module uses a baseline calculation method to calculate a baseline and load limit.
[Item 6]
Item 2. The platform of item 1, wherein the data feed from a utility operator includes EMS, DMS, GIS, CIS, MDM and a billing system.
[Item 7]
A system realized by a network server that facilitates communication of demand response signals,
A demand response server hosted in the cloud network;
A network of utility operators in a network that distributes electricity to a group of customers, wherein the utility operator uses a utility back-end data system for power distribution, and a network of utilities operators ,
A first application programming interface that enables the demand response server to communicate with the utility operator's network;
A second application programming interface that enables the demand response server to communicate with the customer;
With
A system implemented by a network server that facilitates communication of demand response signals, wherein the communication is performed through a simultaneous multi-channel communication protocol.
[Item 8]
8. The system of item 7, wherein the demand response server hosted in the cloud network is distributed over a plurality of geographical locations and accessible through the Internet.
[Item 9]
8. The system of item 7, wherein the demand response server uses the OpenADR standard for signaling.
[Item 10]
Item 8. The system according to Item 7, wherein the utility operator and the independent operator are connected to the customer through the demand response server using a web API.
[Item 11]
Item 8. The system of item 7, wherein communication of the signal between the customer and the demand response server is bidirectional.
[Item 12]
8. The system of item 7, wherein the demand response server forwards the demand response signal directly to the customer or through a load aggregator.
[Item 13]
Item 8. The system of item 7, wherein the communication with the demand response server communicates with a customer API through a proxy that converts communication between a server compliant with a standard and a device specific API.
[Item 14]
8. The system of item 7, wherein the system is adapted for simultaneous multi-channel communication and protocol operation.
[Item 15]
8. The system of item 7, wherein the multi-channel communication includes electronic mail, text, RDS, broadband, internet and cellular link.
[Item 16]
The communication protocol is OpenADR, Smart Energy Profile1. x / 2. 8. The system of item 7, comprising x and Energy InterOp.

Claims (16)

A software as a service platform that optimizes and manages demand response resources,
A server having a storage medium, a processor and a computer readable medium, and communicatively coupled to a utility operator system and a customer endpoint;
A first module in the server for designing a demand response event, the first module allowing a user to add, view and edit a demand response event;
An application programming interface communicatively coupled to the server and enabling two-way communication of the utility operator's system and a data feed from the customer endpoint for measurement confirmation and verification;
A second module for analyzing the data feed provided by the application programming interface, wherein the second module is a baseline of electricity usage associated with the demand response event designed in the first module; A software-as-a-service platform for optimizing and managing demand response resources comprising a second module for calculating quantities, load limits and payments.   The platform of claim 1, wherein the server uses the OpenADR standard for signaling.   The platform of claim 1, wherein the server is hosted in a network through a web interface and distributed across multiple geographic locations.   The platform of claim 1, wherein the demand response event includes an event duration, a notification window, a power outage time, a valid time, and a number of times a customer may be required to participate in the event.   The platform of claim 1, wherein the second module uses a baseline calculation method to calculate a baseline and load limit.   The platform of claim 1, wherein the data feed from a utility operator includes EMS, DMS, GIS, CIS, MDM and billing systems. A system realized by a network server that facilitates communication of demand response signals,
A demand response server hosted in the cloud network;
A network of utility operators in a network that distributes electricity to a group of customers, wherein the utility operator uses a utility back-end data system for power distribution, and a network of utilities operators ,
A first application programming interface that enables the demand response server to communicate with the utility operator's network;
A second application programming interface that enables the demand response server to communicate with the customer;
With
A system implemented by a network server that facilitates communication of demand response signals, wherein the communication is performed through a simultaneous multi-channel communication protocol.   The system of claim 7, wherein the demand response server hosted in the cloud network is distributed across multiple geographical locations and accessible through the Internet.   The system of claim 7, wherein the demand response server uses the OpenADR standard for signaling.   8. The system of claim 7, wherein the utility operator and the independent operator are connected to the customer through the demand response server using a web API.   The system of claim 7, wherein communication of the signal between the customer and the demand response server is bidirectional.   The system of claim 7, wherein the demand response server forwards the demand response signal to the customer directly or through a load aggregator.   The system of claim 7, wherein the communication with the demand response server communicates with a customer API through a proxy that translates communication between a standard compliant server and a device specific API.   8. The system of claim 7, wherein the system is adapted for simultaneous multi-channel communication and protocol operation.   The system of claim 7, wherein the multi-channel communication includes email, text, RDS, broadband, internet and cellular links.   The communication protocol is OpenADR, Smart Energy Profile1. x / 2. 8. The system of claim 7, comprising x and Energy InterOp.

Images