System and approach to integrate and manage diverse demand response specifications for multi-site enterprises

Abstract

A demand response system incorporating an enterprise demand manager (EDM), and a universal demand response gateway (UDG). The EDM may provide a single unified web interface. It may provide a cloud application that allows an operator of an enterprise to create and send load/energy reduction requests to buildings of one or more groups of buildings in the enterprise. The cloud application may provide controls to the buildings based on market conditions, dispatch demand response (DR) events to the buildings, and provide feedback to confirm that requested reductions are occurring in the buildings. The DR events may include the buildings in an energy market, a load/energy reduction intensity level, and a target load/energy reduction amount for each building. The UDG may perform as a gateway between various DR automation servers (DRAS's) and multiple supervisor controllers at the buildings.

Description

BACKGROUND

The present disclosure pertains to energy and load programs and particularly to demand response systems.

SUMMARY

The disclosure reveals a demand response system that may incorporate an enterprise demand manager (EDM), and a universal demand response gateway (UDG). The EDM may provide a single unified web interface. It may provide a cloud application that allows an operator of an enterprise to create and send load/energy reduction requests to buildings of one or more groups of buildings in the enterprise. The cloud application may provide controls to the buildings based on market conditions, dispatch demand response (DR) events to the buildings, and provide feedback to confirm that requested reductions are occurring in the buildings. The DR events may include the buildings in an energy market, a load/energy reduction intensity level, and a target load/energy reduction amount for each building. The UDG may perform as a gateway between various DR automation servers (DRAS's) and multiple supervisor controllers at the buildings.

BRIEF DESCRIPTION OF THE DRAWING

FIG. 1 is a diagram of an architecture of the present system and approach; and

FIG. 2 is a diagram of a more detailed architecture of the present system and approach.

DESCRIPTION

The present system and approach may incorporate one or more processors, computers, controllers, user interfaces, wireless and/or wire connections, and/or the like, in an implementation described and/or shown herein.

This description may provide one or more illustrative and specific examples or ways of implementing the present system and approach. There may be numerous other examples or ways of implementing the system and approach.

Aspects of the system or approach may be described in terms of symbols in the drawing. Symbols may have virtually any shape (e.g., a block) and may designate hardware, objects, components, activities, states, steps, procedures, and other items.

Grid transformation in the U.S. brought on by renewables and proliferation of connected building technologies may move the electricity marketplace to demand based pricing and also creating new demand response opportunities for grid operators and commercial customers fueled by faster response times. The result for commercial enterprises may be a strong incentive to use building automation technology to reduce electrical demand when electricity prices are high and to participate in the wider range of demand response program offerings becoming available.

Taking full advantage of emerging opportunities may require a good understanding of the market coupled with the ability to reduce an electrical load quickly in response to price fluctuations and short notification demand response requests (viz., fast demand response). Both appear difficult for large enterprises that have buildings in different electricity markets across the country. The national market appears highly fragmented making the task of identifying and acting on opportunities rather challenging. In addition, building automation technologies in the marketplace are not necessarily well equipped to provide centralized demand control for many remote buildings. The commercial enterprises need an ability to connect to aggregators supporting different protocols such as OpenADR, C Power, and so on. If a single demand response gateway/connector is not available to the enterprises, they will not necessarily be able to integrate so as to subscribe services from different aggregators in the market. This may lead to a point solution which either prevents customers or results in a very high cost and reduces flexibility.

There may be a growing need for a technology solution that will provide operators at the enterprise level with a means to easily and rapidly send electrical load reduction requests to remote buildings in response to dynamically changing conditions across many regional electricity markets; the recipient at the building may be a building automation system of some kind that can receive a load reduction request signal and take action to reduce an electrical load in the building.

The present system and approach may incorporate an enterprise demand manager (EDM) and a universal demand response gateway (UDG). The EDM may provide a single web accessible application in the cloud that will allow operators within a large enterprise to create and send load reduction requests to groups of remote buildings. The application may provide controls to allow load reduction request messages to be pre-defined and then sent as necessary based on market conditions. A load reduction request message (i.e., a demand response event) may include a group of target buildings within an electricity market, and may include a load reduction intensity level, and a target load reduction amount for each building within the group. The application may also provide controls that allow operators to easily send (i.e., dispatch) a demand response event to target buildings using a simple calendar interface, and provide feedback to confirm that requested load reductions are occurring in the buildings.

The universal demand response gateway (UDG) may be an independent cloud based on premise service which will act as a gateway between different public demand response automation servers (DRAS) and multiple supervisory controllers at remote building sites of a multi-site enterprise. The universal demand response gateway may allow the sites to be registered with a public DRAS server which will in turn allow the sites to be included in energy reduction programs. The universal demand response gateway may provide a mechanism to map supervisory controllers at the remote sites and the same resource identification (Id) may be used by DRAS while dispatching the events. The DRAS may generally be managed by third party aggregators or utilities that create and manage the energy reduction programs. When a program goes into effect, the DRAS server may signal an event message to all the site resources configured for that program. A building automation system (BAS) may receive the signal via the universal demand response gateway and may interpret the event signal and invoke energy reduction control strategies. This gateway appears unique as it may allow the integration of DRAS from different aggregators to the building sites of a multi-site enterprise.

There may be enterprise building automation solutions in the marketplace that allow operators to connect to many remote building automation systems from a central application, and can send control system parameter and schedule updates to groups of remote systems. This functionality may be used to send HVAC setpoint or schedule adjustments to remote buildings to produce electrical load reductions and facilitate participation in commercial demand response programs; however, it may be often difficult to configure and implement rapidly.

Many existing building automation technologies may also support an OpenADR automated demand response messaging scheme and may be configured to take load reduction actions upon receipt of an OpenADR load reduction request. The configuration may be often complicated, and OpenADR programs may be offered in a few regional markets making OpenADR one part of an overall enterprise demand response strategy.

EDM may take the complexity out of implementing demand control in the many regional electricity markets by providing a single unified web interface for configuration and performance feedback.

There may be a strategy which may incorporate a strong alignment to a vision of gaining a competitive advantage in the market and transforming the organization from an industrial to a digital software company, and an accelerated profitable growth. The present system and approach may fit well with corporate strategy of connected buildings, and fit well with competences and core business of a company's demand response management and meter business.

The primary high level features of the present system and approach may be noted. It may provide a set of controls to allow an operator to pre-define load reduction request groups (demand response events) that contain groups of remote buildings that will participate within specific electricity markets along with a target load reduction amount for each building.

The present system may provide a set of controls that allow an operator to dispatch a pre-defined demand response event at a scheduled time or immediately. Dispatching a demand response event may act to send load reduction requests and target load reduction amounts to the buildings included in the event. When an event is dispatched, a duration may be specified to determine how long the load reduction requests will persist at the buildings. It may provide an activity monitor that presents real-time feedback from buildings participating in demand response event dispatches. The feedback may incorporate a current building electrical load during a demand response event dispatch, and visual alerts when requested load reductions are not occurring, or the building is not communicating with the EDM.

The system may provide a load reduction history for demand response event dispatches that have occurred in the past showing the average load reductions. It may receive demand response event dispatches from the EDM web app or an OpenADR 2.0a/2.0b and/or C-Power demand response automation server. It may parse DR event dispatches from either the EDM web app or an OpenADR 2.0a/2.0b and/or C-Power DRAS and distribute to recipient remote building automation systems to initiate site demand response actions at the building. The system may communicate a dispatch receipt acknowledgement to the EDM web app or DRAS. The system may also communicate a site load and communication health status to the EDM. It may include, in the activity monitor, demand response event dispatches that have been dispatched from a third party OpenADR 2.0a/2.0b and/or C-Power demand response automation server.

The system may provide a mechanism to define remote sites that will participate in a demand response program. Participating sites may be recipients of the demand response program message when the program is dispatched to create a demand response event (i.e., broadcast to sites in the BAS enterprise). It may provide a way to organize sites that will participate in demand response programs into user defined groupings. Groupings may typically reflect the way sites will be grouped in demand response programs (e.g., energy provider/utility region), but may include other groupings like state, building prototype, and so on.

The system may provide a way to filter site lists by the groupings that they create when adding sites to a demand response program. It may provide a way to import a list of sites that will participate in demand response programs and include site groupings.

The system may provide a mechanism that will allow one to define in a demand response program the target kW levels that will be maintained at each participating site when the demand response program has been dispatched to create a demand response event. The target kW level may be maintained by the site BAS during the course of a demand response event.

The system may provide a mechanism to specify whether the program has a firm service level (FSL) kW target type, or a guaranteed load drop (GLD) kW target type. An FSL kW target may be a fixed kW value. A GLD target may be a calculated load reduction amount where the target is derived by subtracting the load reduction amount from a calculated peak kW value for each site.

The system may provide a mechanism to define the operation mode for a demand response program. The operating mode may be a part of the demand response program message sent to a site when the program is dispatched, and may be used by the site BAS to determine specific load reduction actions that will be taken to maintain the site's kW target during a demand response event. In accordance with the OpenADR 2.0 specifications, the operating mode may be normal, moderate, high or special.

The system may have a software component. A stack level may be a cloud that is a secure, scalable infrastructure for collecting, aggregating and storing data, allowing connected “things” to communicate, and making an offering/SaaS solution available, including IaaS/PaaS and data lakes.

A software type of the system may be connected or have a connectivity offering available through the cloud or a direct, or remote connection (e.g., Lyric TM thermostat, SaaS) or cover an infrastructure enabling connected services (e.g., Sentience). The system may have an IoT (Internet of Things) component.

FIG. 1 is a diagram of an architecture of the present system and approach. There may be an internet portion 11, a customer HQ portion 12 and a customer site portion 13. An enterprise demand manager (EDM) web application 14 in internet portion 11 may be operated by commercial enterprise demand managers. A demand response (DR) event dispatch 15 may be sent to an EDM universal virtual end node (VEN) service unit 16 in customer HQ portion 12.

There may be one or more commercial demand response automation servers (DRAS) 17 that are operated by grid managers. The one or more DRAS's 17 may provide open automatic demand response (ADR) event dispatches 18 to EDM universal VEN service unit 16. From dispatches 15 and 18, unit 16 may provide a DR dispatch 19 to an Opus site building automation system (BAS) 21 at customer site portion 13. BAS 21 may have a building electricity meter 22. BAS 21 may provide a site DR status reporting signal 23 to EDM universal VEN service unit 16.

FIG. 2 is a diagram of a more detailed architecture of the present system and approach. The architecture may support two deployment options. One is a cloud based deployment, and the other is an on-premise deployment without an EDM web application. An energy manager 31 may be sent an EDM event trigger signal 32 to a cloud hosted EDM 33, which may incorporate an EDM web application 34, an EDM services unit 35, an integrated activity monitor 36, and an EDM data storage 37.

A utility independent service operator (ISO) 41 may provide an open ADR signal 42 to an SGS DRAS 43 and a virtual watt link signal 44 to CNE DRAS 45. SGS DRAS 43 may provide an open ADR signal 46 to an Opus VEN service unit 51. Unit 51 may send an open ADR feedback signal 47 to SGS DRAS 43. CNE DRAS 45 may provide a virtual watt link signal 48 to VEN service unit 51. Unit 51 may send a feedback signal 49 to CNE DRAS 45.

Opus VEN service unit 51 may incorporate a registration service 52, an event service 53, a report service 54, an opt in/opt out service 55, and a persistence 56. Cloud hosted EDM 33 may provide a web API signal 57 to Opus VEN service unit 51. A web API is an application programming interface (API) for either a web server or a web browser.

Unit 51 may provide a Web API signal 58 to cloud hosted EDM 33. VEN service unit 51 may send a normalized event signal 62 to Opus XCM's 61. A feedback/acknowledgement signal 63 may be sent by Opus XCM's 61 to VEN service unit 51. An Opus Supervisor 65 may send a signal 66 with XCM details to VEN service unit 51.

An on-premise Opus VEN web application unit 71 may incorporate a configurator 72, resource mapping 73, and an activity monitor 74. VEN web application unit 71 may provide a web API signal 75 to VEN service unit 51. Unit 51 may send a Web API signal 76 to web application unit 71.

To recap, a demand response (DR) system may incorporate an enterprise demand manager (EDM), and a universal demand response gateway (UDG). The EDM may provide a single unified web interface. The EDM may provide a cloud application that allows an operator of an enterprise to create and send load/energy reduction requests to buildings of one or more groups of buildings in the enterprise. The cloud application may provide controls that are predefined and sent to the buildings based on market conditions, and controls to allow an operator to dispatch a demand response (DR) event to the buildings, and provide feedback to confirm that requested reductions are occurring in the buildings. The DR event may include the buildings in an electricity market, a load/energy reduction intensity level, and a target load/energy reduction amount for each of the buildings. The UDG may perform one or more items selected from a group incorporating acting as a gateway between various DR automation servers (DRAS's) and multiple supervisor controllers at the buildings, allowing the buildings to be registered with a DRAS which permits the buildings to be included in a load/energy reduction program, providing a mechanism to map supervisory controllers at the buildings, and integrating a DRAS from different aggregators to the buildings.

The DRAS may be managed by a third-party aggregator or utility that creates and manages the energy/energy reduction program. Upon effecting of the load/energy reduction program, the DRAS may send a DR event message to the buildings programmed for the load/energy reduction program. A building automation system (BAS) may receive the DR event message via the UDG and interpret the DR event message and invoke load/energy reduction control strategies of the load/energy reduction program.

An operator may pre-define load/energy reduction request groups (DR events) that contain buildings which participate within specific electricity markets along with a target load/energy reduction amount for each building.

The system may further incorporate a set of controls that allow the operator to dispatch a pre-defined DR event at a scheduled time.

Dispatching a DR event may be to send a load/energy reduction request and load/energy reduction amounts to buildings included in the DR event. When a DR event is dispatched, a duration may be specified to determine how long the load/energy reduction requests persist at the buildings.

The load/energy reduction request may provide an activity monitor that presents real-time feedback from a building participating in DR event dispatches. The feedback may incorporate a current building electrical load during a DR event dispatch, and incorporate visual alerts when a requested load reduction fails to occur or a building lacks communication with the EDM.

DR event dispatches may be from the EDM web app, open ADR (automated demand response) or C-power DR automation server (DRAS). DR event dispatches from the EDM web app, open ADR or C-power DRAS may be parsed and distributed to recipient building automation systems of the buildings to initiate site DR actions at the buildings. Dispatch receipt acknowledgements may be sent to the EDM web app or DRAS. A site load and communication health status of the buildings may be communicated to the EDM. The site load and communication health status may incorporate an activity monitor of DR event dispatches from a third party open ADR or C-power DR automation server.

The DR system may further incorporate a mechanism to define buildings that participate in a DR program. Buildings that participate may be recipients of a DR program message when the load/energy reduction program is dispatched to create a DR event like a broadcast to the buildings.

The DR system may further incorporate a way to organize the buildings that participate in the load/energy reduction program into user defined groupings. The user defined groupings may reflect a manner that the buildings are grouped in the load/energy reduction program, which can be according to one or more categories of a group incorporating energy provider/utility regions, states, and building proto types.

The DR system may further incorporate a way to filter lists of buildings that are created when added to the load/energy reduction program, a way to import a list of buildings that participate in the load/energy reduction program, and a mechanism that allows defining, in the load/energy reduction program, target kW levels that are maintained at each building that participates in the load/energy reduction program when the load/energy reduction program has been dispatched to create a DR event. A target kW level may be maintained by a BAS of the building during a DR event.

The DR system may further incorporate a mechanism that specifies whether a load/energy reduction program has a firm service level (FSL) kW target type, or a guaranteed load drop (GLD) kW target type. An FSL target may be a fixed kW value. A GLD target may be a calculated load/energy reduction amount where a target is derived by subtracting a load/energy reduction amount from a calculated peak kW value for each building.

The system may further incorporate a mechanism to define an operation mode for a load/energy reduction program. The operation mode may be part of a DR program message sent to a building when the DR load/energy reduction program is dispatched. The operation mode may be used by a BAS of the building to determine specific energy/load reduction actions that are taken to maintain a kW target of a site during a DR event. In accordance with open ADR specifications, the operation mode may be normal, moderate, high or special.

A demand response architecture system may incorporate a mechanism that sends an enterprise demand manager (EDM) event trigger to a cloud hosted enterprise demand manager, a utility/independent service operator (ISO) that sends an open automatic demand response (ADR) signal to a first demand response automation server (DRAS) and a virtual link signal to a second DRAS, a universal virtual end mode (VEN) service mechanism that receives the open ADR signal from the first DRAS, the virtual link signal from the second DRAS, and a web application programming interface (API) signal from the cloud hosted enterprise, and one or more site controllers (XCMs) that receive a normalized event signal from the VEN service.

The architecture system may further incorporate a supervisor that sends XCM detail signals to the VEN service mechanism, and an on-premise VEN web app that sends a web API signal to the VEN service mechanism.

The first DRAS may receive an open ADR feedback signal from the VEN service mechanism. The second DRAS may receive a feedback signal from the VEN service mechanism. The one or more site controllers (XCMs) may provide a feedback/acknowledge signal to the VEN service mechanism. The VEN service mechanism may provide a web API signal to the on-premise VEN web app. The VEN service may provide a web API signal to the cloud hosted enterprise demand manager.

The cloud hosted enterprise demand manager may incorporate an EDM web app, an EDM services set, an EDM data storage, and an integrated monitor.

The VEN service mechanism may provide registration service, event service, report service, in/opt out service, and persistence.

The on-premise VEN web may incorporate a DRAS configurator, a resource mapper, and an activity monitor.

A demand response (DR) solution architecture may incorporate an internet portion, a customer headquarter portion associated with the internet portion, and a customer site portion associated with the customer headquarter portion. An enterprise demand manager (EDM) web application of the internet position may be operated by one or more enterprise demand managers to output a demand response (DR) event dispatch to an EDM universal virtual end mode (VEN) service at the customer headquarter portion. One or more DR automation servers (DRAS) may be operated by grid managers, to output an open ADR event dispatch to an EDM universal virtual end node (VEN) service.

The EDM universal virtual end node service may send a DR dispatch to a site building automation system (BAS) at the customer site portion. A building electricity meter may be connected to the site BAS. The site BAS may provide a site DR status report to the EDM universal virtual end node (VEN) service.

Any publication or patent document noted herein is hereby incorporated by reference to the same extent as if each publication or patent document was specifically and individually indicated to be 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 related art to include all such variations and modifications.

Claims

1. A demand response (DR) system comprising: an enterprise demand manager (EDM); anda universal demand response gateway (UDG); andwherein: the EDM provides a single unified web interface;the EDM provides a cloud application that allows an operator of an enterprise to create and send load/energy reduction requests to buildings of one or more groups of buildings in the enterprise;the cloud application provides controls that are predefined and sent to the buildings based on market conditions, and controls to allow an operator to dispatch a demand response (DR) event to the buildings, and provide feedback to confirm that requested reductions are occurring in the buildings,upon dispatch of a load/energy reduction program, the DR automation server (DRAS) sends the DR event message to the buildings programmed for the load/energy reduction program; anda building automation system (BAS) receives the DR event message via the UDG and interprets the DR event message and invokes load/energy reduction control strategies of the load/energy reduction program;the DR event includes the buildings in an electricity market, a load/energy reduction intensity level, and a target load/energy reduction amount for each of the buildings; andthe UDG performs one or more items selected from a group comprising acting as a gateway between various DR automation servers (DRAS's) and multiple supervisor controllers at the buildings, allowing the buildings to be registered with a DRAS which permits the buildings to be included in the load/energy reduction program, providing a mechanism to map supervisory controllers at the buildings, and integrating a DRAS from different aggregators to the buildings,wherein an operator pre-defines load/energy reduction request groups (DR events) that contain buildings which participate within specific electricity markets along with a target load/energy reduction amount for each building.

2. The DR system of claim 1, wherein: the DRAS is managed by a third-party aggregator or utility that creates and manages the energy/energy reduction program.

3. The DR system of claim 1, further comprising a set of controls that allow the operator to dispatch a pre-defined DR event at a scheduled time.

4. The DR system of claim 1, wherein: dispatching a DR event is to send a load/energy reduction request and load/energy reduction amounts to buildings included in the DR event; andwhen a DR event is dispatched, a duration is specified to determine how long the load/energy reduction requests persist at the buildings.

5. The DR system of claim 4, wherein: the load/energy reduction request provides an activity monitor that presents real-time feedback from a building participating in DR event dispatches; andthe feedback incorporates a current building electrical load during a DR event dispatch, and incorporates visual alerts when a requested load reduction fails to occur or a building lacks communication with the EDM.

6. The DR system of claim 1, wherein: DR event dispatches are from the EDM web app, open ADR (automated demand response) or C-power DR automation server (DRAS);DR event dispatches from the EDM web app, open ADR or C-power DRAS are parsed and distributed to recipient building automation systems of the buildings to initiate site DR actions at the buildings;dispatch receipt acknowledgements are sent to the EDM web app or DRAS;a site load and communication health status of the buildings is communicated to the EDM; andthe site load and communication health status incorporates an activity monitor of DR event dispatches from a third party open ADR or C-power DR automation server.

7. The DR system of claim 1, further comprising: a mechanism to define buildings that participate in a DR program; andwherein buildings that participate are recipients of a DR program message when the load/energy reduction program is dispatched to create a DR event like a broadcast to the buildings.

8. The DR system of claim 1, further comprising: a way to organize the buildings that participate in the load/energy reduction program into user defined groupings; andwherein the user defined groupings reflect a manner that the buildings are grouped in the load/energy reduction program, which is according to one or more categories of a group comprising energy provider/utility regions, states, and building proto types.

9. The DR system of claim 1, further comprising: a way to filter lists of buildings that are created when added to the load/energy reduction program;a way to import a list of buildings that participate in the load/energy reduction program; anda mechanism that allows defining, in the load/energy reduction program, target kW levels that are maintained at each building that participates in the load/energy reduction program when the load/energy reduction program has been dispatched to create a DR event; andwherein a target kW level is maintained by a BAS of the building during a DR event.

10. The DR system of claim 1, further comprising: a mechanism that specifies whether a load/energy reduction program has a firm service level (FSL) kW target type, or a guaranteed load drop (GLD) kW target type; andwherein:an FSL target is a fixed kW value; anda GLD target is a calculated load/energy reduction amount where a target is derived by subtracting a load/energy reduction amount from a calculated peak kW value for each building.

11. The DR system of claim 1, further comprising: a mechanism to define an operation mode for a load/energy reduction program; andwherein:the operation mode is part of a DR program message sent to a building when the DR load/energy reduction program is dispatched;the operation mode is used by a BAS of the building to determine specific energy/load reduction actions that are taken to maintain a kW target of a site during a DR event; andin accordance with open ADR specifications, the operation mode is normal, moderate, high or special.