Control system with multi-factor carbon emissions optimization

A system includes a first subsystem configured to produce a resource by consuming electricity, a second subsystem configured to produce the resource by consuming a fuel, and a controller. The controller is configured to determine an allocation of a predicted demand for the resource over a future time period between the first subsystem and the second subsystem based on a first carbon emissions rate associated with off-site production of the electricity and a second carbon emissions rate associated with on-site consumption of the fuel. The controller is also configured to control the first subsystem and the second subsystem to produce the resource in accordance with the allocation during the future time period.

BACKGROUND

The present disclosure relates generally to the operation of a central plant for serving building thermal energy loads.

A central plant may include various types of equipment configured to serve the thermal energy loads (and, in some embodiments, electricity loads or other energy loads) of a building or campus. For example, a central plant may include heaters, chillers, heat recovery chillers, cooling towers, or other types of equipment configured to provide heating or cooling for the building. A central plant may consume resources from a utility (e.g., electricity, water, natural gas, etc.) or other source (e.g., an on-site green energy source such as a photovoltaic system) to heat or cool a working fluid (e.g., water, glycol, etc.) that is circulated to the building or stored for later use to provide heating or cooling for the building. Fluid conduits typically deliver the heated or chilled fluid to air handlers located on the rooftop of the building or to individual floors or zones of the building. The air handlers push air past heat exchangers (e.g., heating coils or cooling coils) through which the working fluid flows to provide heating or cooling to the air. The working fluid then returns to the central plant to receive further heating or cooling and the cycle continues.

High efficiency equipment can help reduce the amount of energy consumed by a central plant; however, the effectiveness of such equipment is highly dependent on the control technology that is used to distribute the load across the multiple subplants. For example, it may be more cost efficient to run heat pump chillers instead of conventional chillers and a water heater when energy prices are high. It is difficult and challenging to determine when and to what extent each of the multiple subplants should be used to minimize energy cost. It also is difficult and challenging to determine when and to what extent each of the multiple subplants should be used to reduce or minimize carbon emissions or other pollution associated with operation of the central plant. If various utility costs (e.g., including electrical demand charges), carbon emissions, and other penalties or incentives are all of interest, the technical control problem for operating the central plant can be very complicated.

SUMMARY

One implementation of the present disclosure is a system. The system includes a first subsystem configured to produce a resource by consuming electricity, a second subsystem configured to produce the resource by consuming a fuel, and a controller. The controller is configured to determine an allocation of a predicted demand for the resource over a future time period between the first subsystem and the second subsystem based on a first carbon emissions rate associated with off-site production of the electricity and a second carbon emissions rate associated with on-site consumption of the fuel. The controller is also configured to control the first subsystem and the second subsystem to produce the resource in accordance with the allocation during the future time period.

In some embodiments, the first subsystem includes a heat recovery chiller, the second subsystem includes a hot water generator, and the resource is hot water. The system may also include a thermal energy storage system configured to store the hot water produced by the heat recovery chiller and the hot water generator.

In some embodiments, the controller is configured to determine the allocation by optimizing an objective function. The objective function includes a utility cost term accounting for purchases of the electricity and the fuel for the future time period and an emissions term based on the first carbon emissions rate and the second carbon emissions rate. The first carbon emissions rate may be a marginal operating emissions rate.

Another implementation of the present disclosure is a method for operating a first subsystem configured to produce a resource by consuming electricity and a second subsystem configured to produce the resource by consuming a fuel. The method includes determining an allocation of a predicted demand for the resource over a future time period between the first subsystem and the second subsystem based on a first carbon emissions rate associated with off-site production of the electricity and a second carbon emissions rate associated with on-site consumption of the fuel. The method also includes controlling the first subsystem and the second subsystem during the future time period to produce the resource in accordance with the allocation.

In some embodiments, the first subsystem includes a heat recovery chiller, the second subsystem includes a hot water generator, and the resource is hot water. In some embodiments, the method also includes controlling a thermal energy storage system to store at least a portion of the hot water produced by the heat recovery chiller and the hot water generator.

In some embodiments, determining the allocation includes optimizing an objective function that includes a utility cost term accounting for purchases of the electricity and the fuel for the future time period and an emissions term based on the first carbon emissions rate and the second carbon emissions rate. The method may include weighting the emissions term relative to the utility cost term using a user-selected weight. The emissions term may include a price of carbon offsets.

The first emissions rate may be a marginal operating emissions rate of a utility grid. In some embodiments, the method includes predicting time-varying values of the marginal operating emissions rate for the future time period, and allocating the building loads is based on the time-varying values. In some embodiments, determining the allocation comprises performing an optimization subject to a constraint defined based on the first carbon emissions rate and the second carbon emissions rate.

Another implementation of the present disclosure is a system including one or more processors and computer-readable media storing program instructions, that, when executed by the one or more processors, cause the one or more processors to perform operations including allocating building loads for a future time period across a plurality of equipment subplants based on a plurality of emissions rates associated with the equipment subplants and controlling the equipment subplants during the future time period in accordance with the allocated building loads.

In some embodiments, the plurality of equipment subplants comprise a first subplant that consumes electricity to produce a resource and a second subplant that consumes a fuel to produce the resource. The resource may be hot water, the first subplant may include a heat recovery chiller, and the second subplant may include a hot water generator.

In some embodiments, the plurality of emissions rates include a first emissions rate associated with production of the electricity and a second emissions rate associated with consumption of the fuel by the second subplant. The first emissions rate may be a marginal operating emissions rate of a utility grid. The operations may also include predicting time-varying values of the marginal operating emissions rate for the future time period, and allocating the building loads may be based on the time-varying values.

Other aspects, features, and advantages of the devices and/or processes described herein will become apparent in the detailed description set forth herein and taken in conjunction with the accompanying drawings.

DETAILED DESCRIPTION

Overview

Referring generally to the FIGURES, a central plant and building management system with price-based and incentive-based demand response optimization are shown, according to various exemplary embodiments. The systems and methods described herein may be used to control the distribution, production, storage, and usage of resources in a central plant. In some embodiments, a central plant controller performs an optimization process determine an optimal allocation of resources (e.g., thermal energy resources, water, electricity, etc.) for each time step within an optimization period. The optimal allocation of resources may include, for example, an optimal amount of each resource to purchase from utilities, an optimal amount of each resource to produce or convert using generator subplants, an optimal amount of each resource to store or remove from storage subplants, an optimal amount of each resource to sell to energy purchasers, and/or an optimal amount of each resource to provide to a building or campus. As used herein, the term “subplant” can refer to a unit of equipment, a group of equipment units, a sub-portion of a central plant, one or more standalone devices that operate outside a central plant, etc.

The central plant controller may be configured to maximize the economic value of operating the central plant over the duration of the optimization period. The economic value may be defined by a value function that expresses economic value as a function of the control decisions made by the controller. The value function may account for the cost of resources purchased from utilities, revenue generated by selling resources to energy purchasers, and the cost of operating the central plant. In some embodiments, the cost of operating the central plant includes a cost for losses in battery capacity as a result of the charging and discharging electrical energy storage. The cost of operating the central plant may also include a cost of equipment degradation during the optimization period.

In some embodiments, the controller maximizes the life cycle economic value of the central plant equipment while participating in price-based demand response (PBDR) programs, incentive-based demand response (IBDR) programs, or simultaneously in both PBDR and IBDR programs. For IBDR programs, the controller may use statistical estimates of past clearing prices, mileage ratios, and event probabilities to determine the revenue generation potential of selling stored energy to energy purchasers. For PBDR programs, the controller may use predictions of ambient conditions, facility thermal loads, and thermodynamic models of installed equipment to estimate the resource consumption of the building and/or the subplants. The controller may use predictions of the resource consumption to monetize the costs of running the central plant equipment.

The controller may automatically determine (e.g., without human intervention) a combination of PBDR and/or IBDR programs in which to participate over the optimization period in order to maximize economic value. For example, the controller may consider the revenue generation potential of IBDR programs, the cost reduction potential of PBDR programs, and the equipment maintenance/replacement costs that would result from participating in various combinations of the IBDR programs and PBDR programs. The controller may weigh the benefits of participation against the costs of participation to determine an optimal combination of programs in which to participate. Advantageously, this allows the controller to determine an optimal set of control decisions (e.g., an optimal resource allocation) that maximizes the overall value of operating the central plant over the optimization period.

In some instances, the controller may determine that it would be beneficial to participate in an IBDR program when the revenue generation potential is high and/or the costs of participating are low. For example, the controller may receive notice of a synchronous reserve event from an IBDR program which requires the central plant to shed a predetermined amount of power. The controller may determine that it is optimal to participate in the IBDR program if a cold thermal energy storage subplant has enough capacity to provide cooling for the building while the load on a chiller subplant is reduced in order to shed the predetermined amount of power.

In other instances, the controller may determine that it would not be beneficial to participate in an IBDR program when the resources required to participate are better allocated elsewhere. For example, if the building is close to setting a new peak demand that would greatly increase the PBDR costs, the controller may determine that only a small portion of the electrical energy stored in the electrical energy storage will be sold to energy purchasers in order to participate in a frequency response market. The controller may determine that the remainder of the electrical energy will be used to power the chiller subplant to prevent a new peak demand from being set. These and other features of the central plant and/or building management system are described in greater detail below.

Building Management System and HVAC System

Referring now toFIG.2, a block diagram of a waterside system200is shown, according to an exemplary embodiment. In various embodiments, waterside system200may supplement or replace waterside system120in HVAC system100or may be implemented separate from HVAC system100. When implemented in HVAC system100, waterside system200may include a subset of the HVAC devices in HVAC system100(e.g., boiler104, chiller102, pumps, valves, etc.) and may operate to supply a heated or chilled fluid to AHU106. The HVAC devices of waterside system200may be located within building10(e.g., as components of waterside system120) or at an offsite location such as a central plant.

Waterside system200is shown inFIG.2as a central plant having a plurality of subplants202-212. Subplants202-212are shown to include a heater subplant202, a heat recovery chiller subplant204, a chiller subplant206, a cooling tower subplant208, a hot thermal energy storage (TES) subplant210, and a cold thermal energy storage (TES) subplant212. Subplants202-212consume resources (e.g., water, natural gas, electricity, etc.) from utilities to serve the thermal energy loads (e.g., hot water, cold water, heating, cooling, etc.) of a building or campus. For example, heater subplant202may be configured to heat water in a hot water loop214that circulates the hot water between heater subplant202and building10. Chiller subplant206may be configured to chill water in a cold water loop216that circulates the cold water between chiller subplant206building10. Heat recovery chiller subplant204may be configured to transfer heat from cold water loop216to hot water loop214to provide additional heating for the hot water and additional cooling for the cold water. Condenser water loop218may absorb heat from the cold water in chiller subplant206and reject the absorbed heat in cooling tower subplant208or transfer the absorbed heat to hot water loop214. Hot TES subplant210and cold TES subplant212may store hot and cold thermal energy, respectively, for subsequent use.

Although subplants202-212are shown and described as heating and cooling water for circulation to a building, it is understood that any other type of working fluid (e.g., glycol, CO2, etc.) may be used in place of or in addition to water to serve the thermal energy loads. In other embodiments, subplants202-212may provide heating and/or cooling directly to the building or campus without requiring an intermediate heat transfer fluid. These and other variations to waterside system200are within the teachings of the present invention.

Each of dampers316-320may be operated by an actuator. For example, exhaust air damper316may be operated by actuator324, mixing damper318may be operated by actuator326, and outside air damper320may be operated by actuator328. Actuators324-328may communicate with an AHU controller330via a communications link332. Actuators324-328may receive control signals from AHU controller330and may provide feedback signals to AHU controller330. Feedback signals may include, for example, an indication of a current actuator or damper position, an amount of torque or force exerted by the actuator, diagnostic information (e.g., results of diagnostic tests performed by actuators324-328), status information, commissioning information, configuration settings, calibration data, and/or other types of information or data that may be collected, stored, or used by actuators324-328. AHU controller330may be an economizer controller configured to use one or more control algorithms (e.g., state-based algorithms, extremum seeking control (ESC) algorithms, proportional-integral (PI) control algorithms, proportional-integral-derivative (PID) control algorithms, model predictive control (MPC) algorithms, feedback control algorithms, etc.) to control actuators324-328.

Cooling coil334may receive a chilled fluid from waterside system200(e.g., from cold water loop216) via piping342and may return the chilled fluid to waterside system200via piping344. Valve346may be positioned along piping342or piping344to control a flow rate of the chilled fluid through cooling coil334. In some embodiments, cooling coil334includes multiple stages of cooling coils that can be independently activated and deactivated (e.g., by AHU controller330, by BMS controller366, etc.) to modulate an amount of cooling applied to supply air310.

Each of valves346and352may be controlled by an actuator. For example, valve346may be controlled by actuator354and valve352may be controlled by actuator356. Actuators354-356may communicate with AHU controller330via communications links358-360. Actuators354-356may receive control signals from AHU controller330and may provide feedback signals to controller330. In some embodiments, AHU controller330receives a measurement of the supply air temperature from a temperature sensor362positioned in supply air duct312(e.g., downstream of cooling coil334and/or heating coil336). AHU controller330may also receive a measurement of the temperature of building zone306from a temperature sensor364located in building zone306.

Client device368may include one or more human-machine interfaces or client interfaces (e.g., graphical user interfaces, reporting interfaces, text-based computer interfaces, client-facing web services, web servers that provide pages to web clients, etc.) for controlling, viewing, or otherwise interacting with HVAC system100, its subsystems, and/or devices. Client device368may be a computer workstation, a client terminal, a remote or local interface, or any other type of user interface device. Client device368may be a stationary terminal or a mobile device. For example, client device368may be a desktop computer, a computer server with a user interface, a laptop computer, a tablet, a smartphone, a PDA, or any other type of mobile or non-mobile device. Client device368may communicate with BMS controller366and/or AHU controller330via communications link372.

Each of building subsystems428may include any number of devices, controllers, and connections for completing its individual functions and control activities. HVAC subsystem440may include many of the same components as HVAC system100, waterside system200, and/or airside system300, as described with reference toFIGS.1-3. For example, HVAC subsystem440may include one or more chillers, boilers, heat exchangers, air handling units, economizers, field controllers, supervisory controllers, actuators, temperature sensors, and other devices for controlling the temperature, humidity, airflow, or other variable conditions within building10. Lighting subsystem442may include any number of light fixtures, ballasts, lighting sensors, dimmers, or other devices configured to controllably adjust the amount of light provided to a building space. Security subsystem438may include occupancy sensors, video surveillance cameras, digital video recorders, video processing servers, intrusion detection devices, access control devices and servers, or other security-related devices.

Still referring toFIG.4, BMS controller366is shown to include a communications interface407and a BMS interface409. Interface407may facilitate communications between BMS controller366and external applications (e.g., monitoring and reporting applications422, enterprise control applications426, remote systems and applications444, applications residing on client devices448, etc.) for allowing user control, monitoring, and adjustment to BMS controller366and/or subsystems428. Interface407may also facilitate communications between BMS controller366and client devices448. BMS interface409may facilitate communications between BMS controller366and building subsystems428(e.g., HVAC, lighting security, lifts, power distribution, business, etc.).

Memory408(e.g., memory, memory unit, storage device, etc.) may include one or more devices (e.g., RAM, ROM, Flash memory, hard disk storage, etc.) for storing data and/or computer code for completing or facilitating the various processes, layers and modules described in the present application. Memory408may be or include volatile memory or non-volatile memory. Memory408may include database components, object code components, script components, or any other type of information structure for supporting the various activities and information structures described in the present application. According to an exemplary embodiment, memory408is communicably connected to processor406via processing circuit404and includes computer code for executing (e.g., by processing circuit404and/or processor406) one or more processes described herein.

In some embodiments, BMS controller366is implemented within a single computer (e.g., one server, one housing, etc.). In various other embodiments BMS controller366may be distributed across multiple servers or computers (e.g., that can exist in distributed locations). Further, whileFIG.4shows applications422and426as existing outside of BMS controller366, in some embodiments, applications422and426may be hosted within BMS controller366(e.g., within memory408).

Enterprise integration layer410may be configured to serve clients or local applications with information and services to support a variety of enterprise-level applications. For example, enterprise control applications426may be configured to provide subsystem-spanning control to a graphical user interface (GUI) or to any number of enterprise-level business applications (e.g., accounting systems, user identification systems, etc.). Enterprise control applications426may also or alternatively be configured to provide configuration GUIs for configuring BMS controller366. In yet other embodiments, enterprise control applications426can work with layers410-420to optimize building performance (e.g., efficiency, energy use, comfort, or safety) based on inputs received at interface407and/or BMS interface409.

Building subsystem integration layer420may be configured to manage communications between BMS controller366and building subsystems428. For example, building subsystem integration layer420may receive sensor data and input signals from building subsystems428and provide output data and control signals to building subsystems428. Building subsystem integration layer420may also be configured to manage communications between building subsystems428. Building subsystem integration layer420translate communications (e.g., sensor data, input signals, output signals, etc.) across a plurality of multi-vendor/multi-protocol systems.

Demand response layer414may further include or draw upon one or more demand response policy definitions (e.g., databases, XML, files, etc.). The policy definitions may be edited or adjusted by a user (e.g., via a graphical user interface) so that the control actions initiated in response to demand inputs may be tailored for the user's application, desired comfort level, particular building equipment, or based on other concerns. For example, the demand response policy definitions can specify which equipment may be turned on or off in response to particular demand inputs, how long a system or piece of equipment should be turned off, what setpoints can be changed, what the allowable set point adjustment range is, how long to hold a high demand setpoint before returning to a normally scheduled setpoint, how close to approach capacity limits, which equipment modes to utilize, the energy transfer rates (e.g., the maximum rate, an alarm rate, other rate boundary information, etc.) into and out of energy storage devices (e.g., thermal storage tanks, battery banks, etc.), and when to dispatch on-site generation of energy (e.g., via fuel cells, a motor generator set, etc.).

Central Plant System with Thermal and Electrical Energy Storage

Referring now toFIG.5, a block diagram of a central plant system500is shown, according to an exemplary embodiment. Central plant system500is shown to include a building502. Building502may be the same or similar to building10, as described with reference toFIG.1. For example, building502may be equipped with a HVAC system and/or a building management system (e.g., BMS400) that operates to control conditions within building502. In some embodiments, building502includes multiple buildings (i.e., a campus) served by central plant system500. Building502may demand various resources including, for example, hot thermal energy (e.g., hot water), cold thermal energy (e.g., cold water), and/or electrical energy. The resources may be demanded by equipment or subsystems within building502(e.g., building subsystems428) or by external systems that provide services for building502(e.g., heating, cooling, air circulation, lighting, electricity, etc.). Central plant system500operates to satisfy the resource demand associated with building502.

Central plant system500is shown to include a plurality of utilities510. Utilities510may provide central plant system500with resources such as electricity, water, natural gas, or any other resource that can be used by central plant system500to satisfy the demand of building502. For example, utilities510are shown to include an electric utility511, a water utility512, a natural gas utility513, and utility M514, where M is the total number of utilities510. In some embodiments, utilities510are commodity suppliers from which resources and other types of commodities can be purchased. Utilities510or suppliers to utilities510may be associated with off-site (i.e., outside of central plant system500) sources of carbon emissions, for example carbon emissions that result from power plants that burn fuels (e.g., fossil fuels, coal, oil, natural gas, gasoline, diesel, ethanol, biofuels, biomass, hydrocarbons, etc.) to generate electricity provided by the electric utility511to central plant system500. As a further example, carbon emissions may result from activities performed by utilities510or suppliers to utilities510to obtain, treat, pre-process, pump, deliver, etc. other resources which are provided to the central plant system500from utilities510. In some embodiments, an indication of the amount or rate of carbon emissions associated with each input resource to central plant system500(e.g., carbon emissions per unit of electricity, carbon emissions per unit of water, carbon emissions per unit of natural gas) is provided by utilities510. The amount or rate of carbon emissions per unit of any given resource may vary over time and can be provided as time series data. Resources purchased from utilities510can be used by generator subplants520to produce generated resources (e.g., hot water, cold water, electricity, steam, etc.), stored in storage subplants530for later use, or provided directly to building502. For example, utilities510are shown providing electricity directly to building502and storage subplants530.

Central plant system500is shown to include a plurality of generator subplants520. In some embodiments, generator subplants520include one or more of the subplants described with reference toFIG.2. For example, generator subplants520are shown to include a heater subplant521, a chiller subplant522, a heat recovery chiller subplant523, a steam subplant524, an electricity subplant525, and subplant N, where N is the total number of generator subplants520. Generator subplants520may be configured to convert one or more input resources into one or more output resources by operation of the equipment within generator subplants520. For example, heater subplant521may be configured to generate hot thermal energy (e.g., hot water) by heating water using electricity or natural gas. Chiller subplant522may be configured to generate cold thermal energy (e.g., cold water) by chilling water using electricity. Heat recovery chiller subplant523may be configured to generate hot thermal energy and cold thermal energy by removing heat from one water supply and adding the heat to another water supply. Steam subplant524may be configured to generate steam by boiling water using electricity or natural gas. Burning natural gas by heater subplant521, steam subplant524, electricity subplant525or any other of generator subplants520that consume natural gas can result in on-site carbon emissions from the central plant system500, for example at a rate of tons of carbon per unit natural gas consumed (e.g., per kW of natural gas). Electricity subplant525may be configured to generate electricity using mechanical generators (e.g., a steam turbine, a gas-powered generator, etc.) or other types of electricity-generating equipment (e.g., photovoltaic equipment, hydroelectric equipment, etc.) which may advantageously include non-carbon-emitting electricity generation (e.g., green energy sources, renewable energy generators, etc.).

The input resources used by generator subplants520may be provided by utilities510, retrieved from storage subplants530, and/or generated by other generator subplants520. For example, steam subplant524may produce steam as an output resource. Electricity subplant525may include a steam turbine that uses the steam generated by steam subplant524as an input resource to generate electricity. The output resources produced by generator subplants520may be stored in storage subplants530, provided to building502, sold to energy purchasers504, and/or used by other generator subplants520. For example, the electricity generated by electricity subplant525may be stored in electrical energy storage533, used by chiller subplant522to generate cold thermal energy, provided to building502, and/or sold to energy purchasers504.

Central plant system500is shown to include storage subplants530. Storage subplants530may be configured to store energy and other types of resources for later use. Each of storage subplants530may be configured to store a different type of resource. For example, storage subplants530are shown to include hot thermal energy storage531(e.g., one or more hot water storage tanks), cold thermal energy storage532(e.g., one or more cold thermal energy storage tanks), electrical energy storage533(e.g., one or more batteries), and resource type P storage534, where P is the total number of storage subplants530. The resources stored in subplants530may be purchased directly from utilities510or generated by generator subplants520.

In some embodiments, storage subplants530are used by central plant system500to take advantage of price-based demand response (PBDR) programs. PBDR programs encourage consumers to reduce consumption when generation, transmission, and distribution costs are high. PBDR programs are typically implemented (e.g., by utilities510) in the form of energy prices that vary as a function of time. For example, utilities510may increase the price per unit of electricity during peak usage hours to encourage customers to reduce electricity consumption during peak times. Some utilities also charge consumers a separate demand charge based on the maximum rate of electricity consumption at any time during a predetermined demand charge period.

Advantageously, storing energy and other types of resources in subplants530allows for the resources to be purchased at times when the resources are relatively less expensive (e.g., during non-peak electricity hours) and stored for use at times when the resources are relatively more expensive (e.g., during peak electricity hours). Storing resources in subplants530also allows the resource demand of building502to be shifted in time. For example, resources can be purchased from utilities510at times when the demand for heating or cooling is low and immediately converted into hot or cold thermal energy by generator subplants520. The thermal energy can be stored in storage subplants530and retrieved at times when the demand for heating or cooling is high. This allows central plant system500to smooth the resource demand of building502and reduces the maximum required capacity of generator subplants520. Smoothing the demand also allows central plant system500to reduce the peak electricity consumption, which results in a lower demand charge.

In some embodiments, storage subplants530are used by central plant system500to take advantage of incentive-based demand response (IBDR) programs. IBDR programs provide incentives to customers who have the capability to store energy, generate energy, or curtail energy usage upon request. Incentives are typically provided in the form of monetary revenue paid by utilities510or by an independent service operator (ISO). IBDR programs supplement traditional utility-owned generation, transmission, and distribution assets with additional options for modifying demand load curves. For example, stored energy can be sold to energy purchasers504(e.g., an energy grid) to supplement the energy generated by utilities510. In some instances, incentives for participating in an IBDR program vary based on how quickly a system can respond to a request to change power output/consumption. Faster responses may be compensated at a higher level. Advantageously, electrical energy storage533allows system500to quickly respond to a request for electric power by rapidly discharging stored electrical energy to energy purchasers504.

Still referring toFIG.5, central plant system500is shown to include a central plant controller506. Central plant controller506may be configured to control the distribution, production, storage, and usage of resources in central plant system500. In some embodiments, central plant controller506performs an optimization process determine an optimal set of control decisions for each time step within an optimization period. The control decisions may include, for example, an optimal amount of each resource to purchase from utilities510, an optimal amount of each resource to produce or convert using generator subplants520, an optimal amount of each resource to store or remove from storage subplants530, an optimal amount of each resource to sell to energy purchasers504, and/or an optimal amount of each resource to provide to building502. In some embodiments, the control decisions include an optimal amount of each input resource and output resource for each of generator subplants520.

Controller506may be configured to maximize the economic value of operating central plant system500over the duration of the optimization period. The economic value may be defined by a value function that expresses economic value as a function of the control decisions made by controller506. The value function may account for the cost of resources purchased from utilities510, revenue generated by selling resources to energy purchasers504, and the cost of operating central plant system500. In some embodiments, the cost of operating central plant system500includes a cost for losses in battery capacity as a result of the charging and discharging electrical energy storage533. The cost of operating central plant system500may also include a cost of excessive equipment start/stops during the optimization period.

Each of subplants520-530may include equipment that can be controlled by central plant controller506to optimize the performance of central plant system500. Subplant equipment may include, for example, heating devices, chillers, heat recovery heat exchangers, cooling towers, energy storage devices, pumps, valves, and/or other devices of subplants520-530. Individual devices of generator subplants520can be turned on or off to adjust the resource production of each generator subplant. In some embodiments, individual devices of generator subplants520can be operated at variable capacities (e.g., operating a chiller at 10% capacity or 60% capacity) according to an operating setpoint received from central plant controller506.

In some embodiments, one or more of subplants520-530includes a subplant level controller configured to control the equipment of the corresponding subplant. For example, central plant controller506may determine an on/off configuration and global operating setpoints for the subplant equipment. In response to the on/off configuration and received global operating setpoints, the subplant controllers may turn individual devices of their respective equipment on or off, and implement specific operating setpoints (e.g., damper position, vane position, fan speed, pump speed, etc.) to reach or maintain the global operating setpoints.

In some embodiments, controller506maximizes the life cycle economic value of central plant system500while participating in PBDR programs, IBDR programs, or simultaneously in both PBDR and IBDR programs. For the IBDR programs, controller506may use statistical estimates of past clearing prices, mileage ratios, and event probabilities to determine the revenue generation potential of selling stored energy to energy purchasers504. For the PBDR programs, controller506may use predictions of ambient conditions, facility thermal loads, and thermodynamic models of installed equipment to estimate the resource consumption of subplants520. Controller506may use predictions of the resource consumption to monetize the costs of running the equipment.

Controller506may automatically determine (e.g., without human intervention) a combination of PBDR and/or IBDR programs in which to participate over the optimization period in order to maximize economic value. For example, controller506may consider the revenue generation potential of IBDR programs, the cost reduction potential of PBDR programs, and the equipment maintenance/replacement costs that would result from participating in various combinations of the IBDR programs and PBDR programs. Controller506may weigh the benefits of participation against the costs of participation to determine an optimal combination of programs in which to participate. Advantageously, this allows controller506to determine an optimal set of control decisions that maximize the overall value of operating central plant system500.

In some instances, controller506may determine that it would be beneficial to participate in an IBDR program when the revenue generation potential is high and/or the costs of participating are low. For example, controller506may receive notice of a synchronous reserve event from an IBDR program which requires central plant system500to shed a predetermined amount of power. Controller506may determine that it is optimal to participate in the IBDR program if cold thermal energy storage532has enough capacity to provide cooling for building502while the load on chiller subplant522is reduced in order to shed the predetermined amount of power.

In other instances, controller506may determine that it would not be beneficial to participate in an IBDR program when the resources required to participate are better allocated elsewhere. For example, if building502is close to setting a new peak demand that would greatly increase the PBDR costs, controller506may determine that only a small portion of the electrical energy stored in electrical energy storage533will be sold to energy purchasers504in order to participate in a frequency response market. Controller506may determine that the remainder of the electrical energy will be used to power chiller subplant522to prevent a new peak demand from being set.

Central Plant Controller

Referring now toFIG.6, a block diagram illustrating a central plant controller506in greater detail is shown, according to an exemplary embodiment. Central plant controller506is shown providing control decisions to a building management system (BMS)606. In some embodiments, BMS606is the same or similar to BMS400, as described with reference toFIG.4. The control decisions provided to BMS606may include resource purchase amounts for utilities510, setpoints for generator subplants520, and/or charge/discharge rates for storage subplants530.

BMS606may be configured to monitor conditions within a controlled building or building zone. For example, BMS606may receive input from various sensors (e.g., temperature sensors, humidity sensors, airflow sensors, voltage sensors, etc.) distributed throughout the building and may report building conditions to central plant controller506. Building conditions may include, for example, a temperature of the building or a zone of the building, a power consumption (e.g., electric load) of the building, a state of one or more actuators configured to affect a controlled state within the building, or other types of information relating to the controlled building. BMS606may operate subplants520-530to affect the monitored conditions within the building and to serve the thermal energy loads of the building.

BMS606may receive control signals from central plant controller506specifying on/off states, charge/discharge rates, and/or setpoints for the subplant equipment. BMS606may control the equipment (e.g., via actuators, power relays, etc.) in accordance with the control signals provided by central plant controller506. For example, BMS606may operate the equipment using closed loop control to achieve the setpoints specified by central plant controller506. In various embodiments, BMS606may be combined with central plant controller506or may be part of a separate building management system. According to an exemplary embodiment, BMS606is a METASYS® brand building management system, as sold by Johnson Controls, Inc.

Central plant controller506may monitor the status of the controlled building using information received from BMS606. Central plant controller506may be configured to predict the thermal energy loads (e.g., heating loads, cooling loads, etc.) of the building for plurality of time steps in an optimization period (e.g., using weather forecasts from a weather service604). Central plant controller506may also predict the revenue generation potential of IBDR programs using an incentive event history (e.g., past clearing prices, mileage ratios, event probabilities, etc.) from incentive programs602. Central plant controller506may generate control decisions that optimize the economic value of operating central plant system500over the duration of the optimization period subject to constraints on the optimization process (e.g., energy balance constraints, load satisfaction constraints, etc.). The optimization process performed by central plant controller506is described in greater detail below.

According to an exemplary embodiment, central plant controller506is integrated within a single computer (e.g., one server, one housing, etc.). In various other exemplary embodiments, central plant controller506can be distributed across multiple servers or computers (e.g., that can exist in distributed locations). In another exemplary embodiment, central plant controller506may integrated with a smart building manager that manages multiple building systems and/or combined with BMS606.

Central plant controller506is shown to include a communications interface636and a processing circuit607. Communications interface636may include wired or wireless interfaces (e.g., jacks, antennas, transmitters, receivers, transceivers, wire terminals, etc.) for conducting data communications with various systems, devices, or networks. For example, communications interface636may include an Ethernet card and port for sending and receiving data via an Ethernet-based communications network and/or a WiFi transceiver for communicating via a wireless communications network. Communications interface636may be configured to communicate via local area networks or wide area networks (e.g., the Internet, a building WAN, etc.) and may use a variety of communications protocols (e.g., BACnet, IP, LON, etc.).

Communications interface636may be a network interface configured to facilitate electronic data communications between central plant controller506and various external systems or devices (e.g., BMS606, subplants520-530, utilities510, etc.). For example, central plant controller506may receive information from BMS606indicating one or more measured states of the controlled building (e.g., temperature, humidity, electric loads, etc.) and one or more states of subplants520-530(e.g., equipment status, power consumption, equipment availability, etc.). Communications interface636may receive inputs from BMS606and/or subplants520-530and may provide operating parameters (e.g., on/off decisions, setpoints, etc.) to subplants520-530via BMS606. The operating parameters may cause subplants520-530to activate, deactivate, or adjust a setpoint for various devices thereof.

Still referring toFIG.6, processing circuit607is shown to include a processor608and memory610. Processor608may be a general purpose or specific purpose processor, an application specific integrated circuit (ASIC), one or more field programmable gate arrays (FPGAs), a group of processing components, or other suitable processing components. Processor608may be configured to execute computer code or instructions stored in memory610or received from other computer readable media (e.g., CDROM, network storage, a remote server, etc.).

Memory610may include one or more devices (e.g., memory units, memory devices, storage devices, etc.) for storing data and/or computer code for completing and/or facilitating the various processes described in the present disclosure. Memory610may include random access memory (RAM), read-only memory (ROM), hard drive storage, temporary storage, non-volatile memory, flash memory, optical memory, or any other suitable memory for storing software objects and/or computer instructions. Memory610may include database components, object code components, script components, or any other type of information structure for supporting the various activities and information structures described in the present disclosure. Memory610may be communicably connected to processor608via processing circuit607and may include computer code for executing (e.g., by processor608) one or more processes described herein.

Memory610is shown to include a building status monitor624. Central plant controller506may receive data regarding the overall building or building space to be heated or cooled by the central plant via building status monitor624. In an exemplary embodiment, building status monitor624may include a graphical user interface component configured to provide graphical user interfaces to a user for selecting building requirements (e.g., overall temperature parameters, selecting schedules for the building, selecting different temperature levels for different building zones, etc.).

Central plant controller506may determine on/off configurations and operating setpoints to satisfy the building requirements received from building status monitor624. In some embodiments, building status monitor624receives, collects, stores, and/or transmits cooling load requirements, building temperature setpoints, occupancy data, weather data, energy data, schedule data, and other building parameters. In some embodiments, building status monitor624stores data regarding energy costs, such as pricing information available from utilities510(energy charge, demand charge, etc.), or other time-varying characteristics of energy, such as a marginal operating emissions rate for energy provided by utilities510.

Still referring toFIG.6, memory610is shown to include a load/rate predictor622. Load/rate predictor622may be configured to predict the thermal energy loads (k) of the building or campus for each time step k (e.g., k=1 n) of an optimization period. Load/rate predictor622is shown receiving weather forecasts from a weather service604. In some embodiments, load/rate predictor622predicts the thermal energy loadskas a function of the weather forecasts. In some embodiments, load/rate predictor622uses feedback from BMS606to predict loadsk. Feedback from BMS606may include various types of sensory inputs (e.g., temperature, flow, humidity, enthalpy, etc.) or other data relating to the controlled building (e.g., inputs from a HVAC system, a lighting control system, a security system, a water system, etc.).

In some embodiments, load/rate predictor622receives a measured electric load and/or previous measured load data from BMS606(e.g., via building status monitor624). Load/rate predictor622may predict loadskas a function of a given weather forecast ({circumflex over (ϕ)}w), a day type (day), the time of day (t), and previous measured load data (Yk-1). Such a relationship is expressed in the following equation:
k=f({circumflex over (ϕ)}w,day,t|Yk-1)

In some embodiments, load/rate predictor622uses a deterministic plus stochastic model trained from historical load data to predict loadsk. Load/rate predictor622may use any of a variety of prediction methods to predict loadsk(e.g., linear regression for the deterministic portion and an AR model for the stochastic portion). Load/rate predictor622may predict one or more different types of loads for the building or campus. For example, load/rate predictor622may predict a hot water loadHot,kand a cold water loadCold,kfor each time step k within the prediction window. In some embodiments, load/rate predictor622makes load/rate predictions using the techniques described in U.S. patent application Ser. No. 14/717,593, titled “Building Management System for Forecasting Time Series Values of Building Variables” and filed May 20, 2015, the entire disclosure of which is incorporated by reference herein.

Load/rate predictor622is shown receiving utility rates from utilities510. Utility rates may indicate a cost or price per unit of a resource (e.g., electricity, natural gas, water, etc.) provided by utilities510at each time step k in the prediction window. In some embodiments, the utility rates are time-variable rates. For example, the price of electricity may be higher at certain times of day or days of the week (e.g., during high demand periods) and lower at other times of day or days of the week (e.g., during low demand periods). The utility rates may define various time periods and a cost per unit of a resource during each time period. Utility rates may be actual rates received from utilities510or predicted utility rates estimated by load/rate predictor622.

In some embodiments, the utility rates include demand charges for one or more resources provided by utilities510. A demand charge may define a separate cost imposed by utilities510based on the maximum usage of a particular resource (e.g., maximum energy consumption) during a demand charge period. The utility rates may define various demand charge periods and one or more demand charges associated with each demand charge period. In some instances, demand charge periods may overlap partially or completely with each other and/or with the prediction window. Advantageously, demand response optimizer630may be configured to account for demand charges in the high level optimization process performed by high level optimizer632. Utilities510may be defined by time-variable (e.g., hourly) prices, a maximum service level (e.g., a maximum rate of consumption allowed by the physical infrastructure or by contract) and, in the case of electricity, a demand charge or a charge for the peak rate of consumption within a certain period. Load/rate predictor622may store the predicted loadskand the utility rates in memory610and/or provide the predicted loadskand the utility rates to demand response optimizer630.

Still referring toFIG.6, memory610is shown to include an incentive estimator620. Incentive estimator620may be configured to estimate the revenue generation potential of participating in various incentive-based demand response (IBDR) programs. In some embodiments, incentive estimator620receives an incentive event history from incentive programs602. The incentive event history may include a history of past IBDR events from incentive programs602. An IBDR event may include an invitation from incentive programs602to participate in an IBDR program in exchange for a monetary incentive. The incentive event history may indicate the times at which the past IBDR events occurred and attributes describing the IBDR events (e.g., clearing prices, mileage ratios, participation requirements, etc.). Incentive estimator620may use the incentive event history to estimate IBDR event probabilities during the optimization period.

Incentive estimator620is shown providing incentive predictions to demand response optimizer630. The incentive predictions may include the estimated IBDR probabilities, estimated participation requirements, an estimated amount of revenue from participating in the estimated IBDR events, and/or any other attributes of the predicted IBDR events. Demand response optimizer630may use the incentive predictions along with the predicted loadskand utility rates from load/rate predictor622to determine an optimal set of control decisions for each time step within the optimization period.

Still referring toFIG.6, memory610is shown to include an demand response optimizer630. Demand response optimizer630may perform a cascaded optimization process to optimize the performance of central plant system500. For example, demand response optimizer630is shown to include a high level optimizer632and a low level optimizer634. High level optimizer632may control an outer (e.g., subplant level) loop of the cascaded optimization. High level optimizer632may determine an optimal set of control decisions for each time step in the prediction window in order to optimize (e.g., maximize) the value of operating central plant system500. Control decisions made by high level optimizer may include, for example, load setpoints for each of generator subplants520, charge/discharge rates for each of storage subplants530, resource purchase amounts for each type of resource purchased from utilities510, and/or an amount of each resource sold to energy purchasers504. In other words, the control decisions may define resource allocation at each time step. The control decisions made by high level optimizer632are based on the statistical estimates of incentive event probabilities and revenue generation potential for various IBDR events as well as the load and rate predictions.

Low level optimizer634may control an inner (e.g., equipment level) loop of the cascaded optimization. Low level optimizer634may determine how to best run each subplant at the load setpoint determined by high level optimizer632. For example, low level optimizer634may determine on/off states and/or operating setpoints for various devices of the subplant equipment in order to optimize (e.g., minimize) the energy consumption of each subplant while meeting the resource allocation setpoint for the subplant. In some embodiments, low level optimizer634receives actual incentive events from incentive programs602. Low level optimizer634may determine whether to participate in the incentive events based on the resource allocation set by high level optimizer632. For example, if insufficient resources have been allocated to a particular IBDR program by high level optimizer632or if the allocated resources have already been used, low level optimizer634may determine that central plant system500will not participate in the IBDR program and may ignore the IBDR event. However, if the required resources have been allocated to the IBDR program and are available in storage subplants530, low level optimizer634may determine that system500will participate in the IBDR program in response to the IBDR event. The cascaded optimization process is described in greater detail with reference toFIG.7.

Still referring toFIG.6, memory610is shown to include a subplant control module628. Subplant control module628may store historical data regarding past operating statuses, past operating setpoints, and instructions for calculating and/or implementing control parameters for subplants520-530. Subplant control module628may also receive, store, and/or transmit data regarding the conditions of individual devices of the subplant equipment, such as operating efficiency, equipment degradation, a date since last service, a lifespan parameter, a condition grade, or other device-specific data. Subplant control module628may receive data from subplants520-530and/or BMS606via communications interface636. Subplant control module628may also receive and store on/off statuses and operating setpoints from low level optimizer634.

Data and processing results from demand response optimizer630, subplant control module628, or other modules of central plant controller506may be accessed by (or pushed to) monitoring and reporting applications626. Monitoring and reporting applications626may be configured to generate real time “system health” dashboards that can be viewed and navigated by a user (e.g., a central plant engineer). For example, monitoring and reporting applications626may include a web-based monitoring application with several graphical user interface (GUI) elements (e.g., widgets, dashboard controls, windows, etc.) for displaying key performance indicators (KPI) or other information to users of a GUI. In addition, the GUI elements may summarize relative energy use and intensity across central plants in different buildings (real or modeled), different campuses, or the like. Other GUI elements or reports may be generated and shown based on available data that allow users to assess performance across one or more central plants from one screen. The user interface or report (or underlying data engine) may be configured to aggregate and categorize operating conditions by building, building type, equipment type, and the like. The GUI elements may include charts or histograms that allow the user to visually analyze the operating parameters and power consumption for the devices of the central plant.

Still referring toFIG.6, central plant controller506may include one or more GUI servers, web services612, or GUI engines614to support monitoring and reporting applications626. In various embodiments, applications626, web services612, and GUI engine614may be provided as separate components outside of central plant controller506(e.g., as part of a smart building manager). Central plant controller506may be configured to maintain detailed historical databases (e.g., relational databases, XML databases, etc.) of relevant data and includes computer code modules that continuously, frequently, or infrequently query, aggregate, transform, search, or otherwise process the data maintained in the detailed databases. Central plant controller506may be configured to provide the results of any such processing to other databases, tables, XML files, or other data structures for further querying, calculation, or access by, for example, external monitoring and reporting applications.

Central plant controller506is shown to include configuration tools616. Configuration tools616can allow a user to define (e.g., via graphical user interfaces, via prompt-driven “wizards,” etc.) how central plant controller506should react to changing conditions in the central plant subsystems. In an exemplary embodiment, configuration tools616allow a user to build and store condition-response scenarios that can cross multiple central plant devices, multiple building systems, and multiple enterprise control applications (e.g., work order management system applications, entity resource planning applications, etc.). For example, configuration tools616can provide the user with the ability to combine data (e.g., from subsystems, from event histories) using a variety of conditional logic. In varying exemplary embodiments, the conditional logic can range from simple logical operators between conditions (e.g., AND, OR, XOR, etc.) to pseudo-code constructs or complex programming language functions (allowing for more complex interactions, conditional statements, loops, etc.). Configuration tools616can present user interfaces for building such conditional logic. The user interfaces may allow users to define policies and responses graphically. In some embodiments, the user interfaces may allow a user to select a pre-stored or pre-constructed policy and adapt it or enable it for use with their system.

Cascaded Central Plant Optimization

Referring now toFIG.7, a block diagram illustrating a portion of central plant system500in greater detail is shown, according to an exemplary embodiment.FIG.7illustrates the cascaded optimization process performed by demand response optimizer630to optimize the performance of central plant system500. In the cascaded optimization process, high level optimizer632performs a subplant level optimization that determines an optimal allocation of resources for each time step in the optimization period in order to optimize the value of operating central plant system500. Low level optimizer634performs an equipment level optimization that determines how to best run each subplant based on the resource allocations determined by high level optimizer632. For example, low level optimizer634may determine on/off states and/or operating setpoints for various devices of the subplant equipment in order to optimize the energy consumption of each subplant while meeting the thermal energy load setpoint for the subplant.

One advantage of the cascaded optimization process performed by demand response optimizer630is the optimal use of computational time. For example, the subplant level optimization performed by high level optimizer632may use a relatively long time horizon due to the operation of the thermal energy storage. However, the equipment level optimization performed by low level optimizer634may use a much shorter time horizon or no time horizon at all since the low level system dynamics are relatively fast (compared to the dynamics of the thermal energy storage) and the low level control of the subplant equipment may be handled by BMS606. Such an optimal use of computational time makes it possible for demand response optimizer630to perform the central plant optimization in a short amount of time, allowing for real-time predictive control. For example, the short computational time enables demand response optimizer630to be implemented in a real-time planning tool with interactive feedback.

Another advantage of the cascaded optimization performed by demand response optimizer630is that the central plant optimization problem can be split into two cascaded subproblems. The cascaded configuration provides a layer of abstraction that allows high level optimizer632to distribute and allocate resources without requiring high level optimizer632to know or use any details regarding the particular equipment configuration within each subplant. The interconnections between the subplant equipment within each subplant may be hidden from high level optimizer632and handled by low level optimizer634. For purposes of the subplant level optimization performed by high level optimizer632, each subplant may be completely defined by one or more subplant curves.

Still referring toFIG.7, low level optimizer634may generate and provide subplant curves to high level optimizer632. Subplant curves may indicate the rate of resource consumption by each of subplants520-530(e.g., electricity use measured in kW, water use measured in L/s, etc.) as a function of the subplant's resource production (i.e., the subplant load). Exemplary subplant curves are shown and described in greater detail with reference toFIGS.9A-12. In some embodiments, low level optimizer634generates subplant curves based on equipment models618(e.g., by combining equipment models618for individual devices into an aggregate curve for the subplant). Low level optimizer634may generate subplant curves by running the low level optimization process for several different loads and weather conditions to generate multiple data points. Low level optimizer634may fit a curve to the data points to generate a subplant curves. In other embodiments, low level optimizer634provides the data points to high level optimizer632and high level optimizer632generates the subplant curves using the data points. In some embodiments, the equipment models618include information used by the low level optimizer634to assess carbon emissions of various equipment and subplants and provide emissions rates to the high level optimizer632. The emissions rates may be included with the subplant curves and can indicate, for example, rates of carbon emissions per unit of natural gas (or other fuel) consumed by various subplants. The emissions rates provided by the equipment models618and/or the low level optimizer634can be data-driven functions depending on various factors (e.g., weather, capacity, etc.). In some embodiments, the subplant curves model carbon emissions as an output resource of the subplants which incurs a penalty in an objective function optimized by the low level optimizer634and/or the high level optimizer632.

High level optimizer632may receive the load and rate predictions from load/rate predictor622, the incentive predictions from incentive estimator620, and the subplant curves and emissions rates from low level optimizer634. The load predictions may be based on weather forecasts from weather service604and/or information from BMS606(e.g., a current electric load of the building, measurements from the building, a history of previous loads, a setpoint trajectory, etc.). The utility rate predictions may be based on utility rates received from utilities510and/or utility prices from another data source. The incentive predictions may be estimates of IBDR event probabilities and their potential for revenue generation and may be based on a history IBDR events received from incentive programs602.

High level optimizer632may determine an optimal resource allocation for subplants520-530(e.g., a subplant load for each subplant) for each time step the optimization period and may provide the allocation of resources as setpoints to low level optimizer634. Resource allocations may include an amount of each input resource and each output resource consumed or produced by each of generator subplants520at each time step. Resource allocations may also include an amount of each resource charged or discharged from storage subplants530, an amount of each resource purchased from utilities510, and an amount of each resource sold to energy purchasers504for each time step in the optimization period. In some embodiments, high level optimizer632determines the resource allocation by maximizing the total operating value of central plant system500over the optimization period. For example, high level optimizer632may determine a set of control decisions that maximizes a value function. The value function may include IBDR revenue, resource purchase costs, and costs of equipment degradation resulting from the control decisions.

In some instances, the optimal resource allocation may include using storage subplants530to store resources during a first time step for use during a later time step. Resource storage may advantageously allow energy and other types of resources to be produced and stored during a first time period when energy prices are relatively low and subsequently retrieved and used during a second time period when energy proves are relatively high. The high level optimization may be different from the low level optimization in that the high level optimization has a longer time constant due to the storage provided by subplants530.

The high level optimization may be described by the following equation:

θHL*=argmaxθHLJHL(θHL)
where θ*HLcontains the optimal high level decisions (e.g., the optimal resource allocation) for the entire optimization period and JHLis the high level value function. To find the optimal high level decisions θ*HL, high level optimizer632may maximize the high level cost function JHL. The high level cost function JHLmay include the revenue generated by participating in IBDR programs, the cost of resources purchased from utilities510, and the cost of equipment degradation over the duration of the optimization period. In some embodiments, the high level cost function JHLis described using the following equation:
JHL=∫tt+h($IBDR−$PBDR−$BL−$Penalties)dt
where $IBDR is the revenue generated from participating in IBDR programs, $PBDR is the cost of resources purchased from utilities510, $BL is the cost of losses in battery capacity, and $Penalties is the cost of operating the subplant equipment (e.g., equipment degradation due to start/stop commands). Each of these terms is described in greater detail with reference toFIG.8.

The decision vector θHLmay be subject to several constraints. For example, the constraints may require that each of generator subplants520not operate at more than its total capacity and that the input resources and output resources of each generator subplant520are related as defined by the subplant curves. The constraints may require that storage subplants530not charge or discharge too quickly and may constrain the amount of a resource stored in each of subplants530between zero and the maximum storage capacity of the subplant. The constraints may also require that resource demand for the building or campus is met. These restrictions lead to both equality and inequality constraints on the high level optimization problem, as described in greater detail with reference toFIG.8.

Still referring toFIG.7, low level optimizer634may use the resource allocations determined by high level optimizer632to determine optimal low level decisions61L (e.g. binary on/off decisions, flow setpoints, temperature setpoints, etc.) for the subplant equipment. The low level optimization process may be performed for each of subplants520-530. Low level optimizer634may be responsible for determining which devices of each subplant to use and/or the operating setpoints for such devices that will achieve the resource allocation setpoint while minimizing energy consumption.

The low level optimization may be described using the following equation:

θLL*=argminθLLJLL(θLL)
where θ*LLcontains the optimal low level decisions and JLLis the low level cost function. To find the optimal low level decisions θ*LL, low level optimizer634may minimize the low level cost function JLL. The low level cost function JLLmay represent the total energy consumption for all of the equipment in the applicable subplant. The low level cost function JLLmay be described using the following equation:

JLL(θLL)=∑j=1Nts·bj·uj(θLL)
where N is the number of devices in the subplant, tsis the duration of a time step, bjis a binary on/off decision (e.g., 0=off, 1=on), and ujis the energy used by device j as a function of the setpoint θLL. Each device may have continuous variables which can be changed to determine the lowest possible energy consumption for the overall input conditions.

Low level optimizer634may minimize the low level cost function JLLsubject to inequality constraints based on the capacities of subplant equipment and equality constraints based on energy and mass balances. In some embodiments, the optimal low level decisions ° LL are constrained by switching constraints defining a short horizon for maintaining a device in an on or off state after a binary on/off switch. The switching constraints may prevent devices from being rapidly cycled on and off. In some embodiments, low level optimizer634performs the equipment level optimization without considering system dynamics. The optimization process may be slow enough to safely assume that the equipment control has reached its steady-state. Thus, low level optimizer634may determine the optimal low level decisions θ*LLat an instance of time rather than over a long horizon.

Low level optimizer634may determine optimum operating statuses (e.g., on or off) for a plurality of devices of the subplant equipment. According to an exemplary embodiment, the on/off combinations may be determined using binary optimization and quadratic compensation. Binary optimization may minimize a cost function representing the power consumption of devices in the applicable subplant. In some embodiments, non-exhaustive (i.e., not all potential combinations of devices are considered) binary optimization is used. Quadratic compensation may be used in considering devices whose power consumption is quadratic (and not linear). Low level optimizer634may also determine optimum operating setpoints for equipment using nonlinear optimization. Nonlinear optimization may identify operating setpoints that further minimize the low level cost function JLL. Low level optimizer634may provide the on/off decisions and setpoints to building management system606for use in controlling the central plant equipment.

In some embodiments, the low level optimization performed by low level optimizer634is the same or similar to the low level optimization process described in U.S. patent application Ser. No. 14/634,615 titled “Low Level Central Plant Optimization” and filed Feb. 27, 2015. The entire disclosure of U.S. patent application Ser. No. 14/634,615 is incorporated by reference herein.

High Level Optimization

Referring now toFIG.8, a block diagram illustrating high level optimizer632in greater detail is shown, according to an exemplary embodiment. High level optimizer632may receive load and rate predictions from load/rate predictor622, incentive predictions from incentive estimator620, and subplant curves from low level optimizer634. High level optimizer632may determine an optimal resource allocation across central plant system500as a function of the load and rate predictions, the incentive predictions, and the subplant curves. The optimal resource allocation may include an amount of each resource purchased from utilities510, an amount of each input and output resource of generator subplants520, an amount of each resource stored or withdrawn from storage subplants530, and/or an amount of each resource sold to energy purchasers504. In some embodiments, the optimal resource allocation maximizes the economic value of operating central plant system500while satisfying the predicted loads for the building or campus. High level optimizer632may output the optimal resource allocation to low level optimizer634.

Optimization Framework

High level optimizer632is shown to include an optimization framework module802. Optimization framework module802may be configured to select and/or establish an optimization framework for use in determining the optimal resource allocation. In some embodiments, optimization framework module802uses linear programming as the optimization framework. A linear programming problem has the following form:

arg⁢minx⁢cT⁢x;subject⁢to⁢Ax≤b,Hx=g
where c is a cost vector, x is a decision matrix, A and b are a matrix and vector (respectively) which describe inequality constraints on the optimization problem, and H and g are a matrix and vector (respectively) which describe equality constraints on the optimization problem. Revenue generated by IBDR programs may be expressed as negative costs in the cost vector c.

The following paragraphs describe an exemplary linear optimization framework that may be used by high level optimizer632to determine the optimal resource allocation. Advantageously, the linear programming framework described herein allows high level optimizer632to determine the resource allocation for a long optimization period in a very short timeframe complete with IBDR incentives, PBDR costs, and equipment degradation costs/penalties. However, the linear optimization framework is merely one example of an optimization framework that can be used by high level optimizer632and should not be regarded as limiting. It should be understood that in other embodiments, high level optimizer632may use any of a variety of other optimization frameworks and/or optimization techniques (e.g., quadratic programming, linear-fractional programming, nonlinear programming, combinatorial algorithms, etc.) to calculate the optimal resource allocation.

Linear Program

Still referring toFIG.8, high level optimizer632is shown to include a linear program module804. Linear program module804may be configured to formulate and solve a linear optimization problem to calculate the optimal resource allocation. For example, linear program module804may determine and set values for the cost vector c, the A matrix and the b vector which describe the inequality constraints, and the H matrix and the g vector which describe the equality constraints. Linear program module804may determine an optimal decision matrix x* that minimizes the cost function cTx. The optimal decision matrix x* may correspond to the optimal decisions θ*HL(for each time step k within an optimization period) that maximize the high level cost function JHL, as described with reference toFIG.7.

Linear program module804may be configured to generate decision variables (i.e. variables in the decision matrix x) for each of the plant assets across which resources are allocated. For a central plant that includes chillers, heat recovery chillers, hot water generators, thermal energy storage, and electrical energy storage, the plant assets across which the resources are to be allocated may include a chiller subplant522, a heat recovery chiller subplant523, a heater subplant521a hot thermal energy storage subplant531, a cold thermal energy storage subplant532, and an electrical energy storage subplant533. For other central plants, the plant assets across which the resources are to be allocated may include fewer or additional subplants, depending on the particular configuration and components of the central plant.

For each subplant across which resources are allocated, linear program module804may generate decision variables representing an amount of each input resource to the subplant and each output resource from the subplant for each time step k in the optimization period. For example, a chiller subplant may consume two different types of input resources (e.g., electricity and water) and may produce one output resource (e.g., chilled water). For a generator subplant with two input resources and one output resource, linear program module804may add the following variables to the decision matrix x:
x=[ . . . xspn,in1,1 . . . hxspn,in2,1 . . . hxspn,out1,1 . . . h. . . ]T
where xspn,in1,1 . . . h, xspn,in2,1 . . . h, and xspn,out1,1 . . . hare h-dimensional vectors representing amounts of the first input resource in1, the second input resource in2, and the first output resource out1allocated to the nth subplant spnfor each of the h time steps within the optimization period. Linear program module804may repeat this process for each of generator subplants520, adding one or more input resource decision variables and one or more output resource decision variables for each generator subplant.

Decision variables representing the input resources and output resources of a subplant may have no direct costs associated with them. Therefore, linear program module804may add a zero cost element to the cost vector c for each decision variable representing an input resource or output resource. For example, for a generator subplant with two input resources and one output resource, linear program module804may add the following elements to the cost vector c:
c=[ . . .0 0 0 . . . ]T

For each type of resource allocated, linear program module804may generate a decision variable representing an amount of the resource stored or discharged from storage subplants530for each time step k in the optimization period. In some embodiments, each storage subplant stores and/or discharges a different type of resource. For example, cold TES subplant532may store and discharge cold thermal energy (e.g., cold water), whereas electrical storage subplant533may store and discharge electrical energy. In other embodiments, multiple storage subplants530may store/discharge the same type of resource. In various embodiments, linear program module804may generate a single storage/discharge variable for each type of resource or a storage/discharge variable for each of subplants530, even if multiple subplants530store/discharge the same type of resource.

Linear program module804may also generate a decision variable representing an amount of overproduction (if any) and a decision variable representing an amount of underproduction (if any) for each type of resource. Underproduction may occur when the amount of a resource provided to the building or campus is less than the demand for the resource. Conversely, overproduction may occur when the amount of a resource provided to the building or campus exceeds the demand for the resource. For each type of resource, linear program module804may add the following variables to the decision matrix x:
x=[ . . . xresourcep,under,1 . . . hxresourcep,over,1 . . . hxresourcep,storage,1 . . . h. . . ]T
where xresourcep,under,1 . . . hand xresourcep,over,1 . . . hare h-dimensional vectors representing amounts of underproduction and overproduction of the pth resource for each of the h time steps within the optimization period. xresourcep,storage,1 . . . his a h-dimensional vector representing an amount of the pth resource drawn from storage subplants530for each of the h time steps. The storage draw may be positive if the resource is being withdrawn from storage subplants530or negative if the resource is being stored in storage subplants530.

Decision variables representing the storage draw from subplants530may have no direct costs associated with them. Therefore, linear program module804may add a zero cost element to the cost vector c for each decision variable representing a storage draw. However, linear program module804may assign a high cost to decision variables representing overproduction and/or underproduction. For example, for a particular resource p, linear program module804may add the following elements to the cost vector c:
c=[ . . . M M0 . . . ]T
where M is the cost assigned to overproduction and underproduction of resource p and 0 is the cost assigned to the storage draw of resource p. Advantageously, assigning a high cost to overproduction and underproduction ensures that high level optimizer632does not select a set of decision variables that results in overproduction and/or underproduction unless the central plant is running at full capacity.

For each source from which resources can be purchased (e.g., utilities510), linear program module804may generate a decision variable representing an amount of each resource purchased for each time step k in the optimization period. In some embodiments, each resource source provides a different type of resource. For example, electric utility511may provide electricity, whereas natural gas utility513may provide natural gas. For each resource source, linear program module804may add the following decision variable to the decision matrix x:
x=[xresourcep,sourcem,1 . . . h. . . ]T
where xresourcep,sourcemis the amount of resource p purchased from source m for each of the h time steps in the optimization period. Linear program module804may repeat this process for each of resource source, adding a resource purchase variable for each type of resource purchased.

Decision variables representing resource purchases may have a direct cost associated with them. Therefore, linear program module804may add a non-zero cost to the cost vector c for each decision variable representing a resource purchase. For example, linear program module804may add the following element to the cost vector c:
c=[ . . . cresourcep,sourcem,1 . . . h. . . ]T
where cresourcep,sourcem,1 . . . his the cost of purchasing resource p from source m at each of the h time steps in the optimization period.

In some embodiments, linear program module804uses the load and rate predictions to formulate the linear program. For example, linear program module804may use the load predictions to determine a demand for each type of resource. The demand for each resource may be used to determine the amount of overproduction and/or underproduction. Linear program module804may use the rate predictions to determine values for the elements in cost vector c associated with resource purchases.

In some embodiments, linear program module804formulates the linear program for the simple case in which only resource purchase costs and over/underproduction are considered. Linear program module804may use inputs from inequality constraints module806, equality constraints module808, unmet loads module810, ground loop module812, heat exchanger module814, demand charge module816, tank forced full module818, penalty function module820, incentive program module822, battery capacity loss module824, and/or subplant curves module830to determine and set values for the various matrices and vectors in the linear program. Modules806-830may modify the cost vector c, the A matrix, the b vector, the H matrix, and/or the g vector to provide additional enhancements and/or functionality to the linear program. The inputs provided by modules806-830are described in greater detail below.

Linear program module804may use any of a variety of linear optimization techniques to solve the linear optimization problem. For example, linear program module804may use basis exchange algorithms (e.g., simplex, crisscross, etc.), interior point algorithms (e.g., ellipsoid, projective, path-following, etc.), covering and packing algorithms, integer programming algorithms (e.g., cutting-plant, branch and bound, branch and cut, branch and price, etc.), or any other type of linear optimization algorithm or technique to solve the linear program subject to the optimization constraints. For embodiments in which nonlinear optimization is used, linear program module804may use any of a variety of nonlinear optimization techniques to solve the nonlinear optimization problem.

Inequality Constraints

Still referring toFIG.8, high level optimizer632is shown to include an inequality constraints module806. Inequality constraints module806may formulate or define one or more inequality constraints on the optimization problem solved by linear program module804. In some instances, inequality constraints module806defines inequality constraints on the decision variables corresponding to the loads on generator subplants520for each time step k within optimization period. For example, each of subplants520may have two capacity constraints given by the following equations:
xspn≤xspn,max1∀k∈horizon
xspn≥0 ∀k∈horizon
where xspnis the output of the nth subplant during time step k and xspn,max1is the maximum capacity of the nth subplant with respect to a first output resource. The first capacity constraint requires the output xspnof the subplant to be less than or equal to the maximum capacity xspn,max1of the subplant for each time step k within the optimization period. The second capacity constraint requires the output xspnof the subplant to be greater than or equal to zero for each time step k within the optimization period.

As previously described, the input and output resources for each generator subplant520may be defined by the decision variables:
x=[xspn,in1,1 . . . hxspn,in2,1 . . . hxspn,out1,1 . . . h. . . ]T
The inequality constraints for each subplant520can be placed in the form Ax≤b by defining the A matrix and the b vector as follows:

A=[…00Ih……00-Ih…],b=[⋮xspn,max10h⋮]
where Ihrepresents either an h by h identity matrix or an h by 1 ones vector, 0hrepresents either an h by h zero matrix or an h by 1 zero vector, and xspn,max1is the maximum capacity of subplant n. Inequality constraints module806may formulate similar inequality constraints for each of generator subplants520.

Inequality constraints module806may formulate or define inequality constraints on the decision variables representing the draw from storage subplants530for each time step k within the optimization period. For example, each of subplants530may have two capacity constraints given by the following equations:
xstoragep≤xdischargep,max∀k∈horizon
−xstoragep≤xchargep,max∀k∈horizon
where xstoragepis the rate at which the pth storage subplant is being discharged at time step k, xdischargep,maxis the maximum discharge rate of the pth storage subplant, and xchargep,maxis the maximum charge rate of the pth storage subplant. Positive values for xstoragepindicate that the storage subplant is discharging and negative load values for xstoragepindicate that the storage subplant is charging. The first capacity constraint requires the discharge rate xstoragepfor each of storage subplants530to be less than or equal to the maximum discharge rate xdischargep,maxof the subplant for each time step k within the optimization period. The second capacity constraint requires the negative discharge rate −xstoragep(i.e., the charge rate) for each of subplants530to be less than or equal to the maximum charge rate xchargep,maxof the subplant for each time step k within the optimization period. Each of storage subplants530may also have capacity constraints that require the amount of the stored resource to be no less than zero and no greater than the maximum capacity of the storage.

The inequality constraints for storage subplants530can be placed in the form Ax≤b by defining the A matrix and the b vector as follows:

Inequality constraints module806may generate inequality constraints that limit the maximum rate at which resources can be purchased from utilities510. As previously described, the decision matrix x may include variables representing the amount of each resource purchased from utilities510:
x=[ . . . xresourcep,sourcem,1 . . . h. . . ]T
where xresourcep,sourcemis the amount of resource p purchased from source m for each of the h time steps in the optimization period. Inequality constraints module806may generate the following inequality constraints to limit the purchase amount of resource p to no greater than the maximum allowable purchase during each time step:

A=[…⁢Ih⁢…],b=[⋮xsourcem,max⋮]
where xsourcem,maxis the maximum allowable purchase from source m.

Inequality constraints module806may implement an electrical demand constraint for the electric power purchased from utilities510. Inequality constraints module806may require that the electric power purchased be less than or equal to a maximum electrical demand Pelec,maxby defining the A matrix and the b vector as follows:

A=[…⁢xelec⁢Ih⁢…],b=[⋮Pelec,max⁢Ih⋮]
where xelecrepresents the electricity purchased from utilities510and Pelec,maxis the maximum electrical demand for the central plant system.
Equality Constraints

Still referring toFIG.8, high level optimizer632is shown to include an equality constraints module808. Equality constraints module808may formulate or define one or more equality constraints on the optimization problem solved by linear program module804. The equality constraints may ensure that the predicted resource demand of the building or campus are satisfied for each time step k in the optimization period. Equality constraints module808may formulate an equality constraint for each type of resource (e.g., hot water, cold water, electricity etc.) to ensure that the demand for the resource is satisfied. The equality constraints may be given by the following equation:

∑i=1nsxp,i,k=ℓ^p,k⁢∀k∈horizon
where xp,i,kis the resource output of type p (e.g., hot water, cold water, etc.) by the ith subplant during time step k, nsis the total number of subplants capable of outputting resource p, andp,kis the predicted demand for resource type p at time step k. The predicted resource demand may be received as load predictions from load/rate predictor622.

In some embodiments, the predicted resource demands include a predicted hot water thermal energy loadHot,k, a predicted cold water thermal energy loadCold,k, and a predicted electricity loadElec,kfor each time step k. The predicted hot water thermal energy loadHot,kmay be satisfied by the combination of heater subplant521, heat recovery chiller subplant523, and hot TES subplant532. The predicted cold water thermal energy loadCold,kmay be satisfied by the combination of chiller subplant522, heat recovery chiller subplant523, and cold TES subplant532. The predicted electricity loadElec,kmay include the electric demand of the building and may be satisfied by the combination of electricity subplant525, electric utility511, and electrical energy storage subplant533. Electricity sold to energy purchasers504and electricity consumed by generator subplants520may add to the predicted electricity loadElec,k.

The equality constraints can be placed in the form Hx=g by defining the H matrix and the g vector as follows:

H=[Ih-Ih0h0hIh-Ih0h0hIh-IhIh-Ih],g=[ℓ^Cold,1⁢…⁢hℓ^Hot,1⁢…⁢hℓ^Elec,1⁢…⁢h]
whereCold,1 . . . h,Hot,1 . . . h, andElec,1 . . . hare h-dimensional vectors of predicted cold water loads, predicted hot water loads, and predicted electricity loads for the building or campus at each of the h time steps. The first column of the H matrix applies to any output of the corresponding resource (i.e., resource production) from subplants520-530. The second column of the H matrix applies to any input of the corresponding resource (i.e., consumption consumption) by subplants520-530. The third column of the H matrix applies to any purchase of the corresponding resource from utilities510. The fourth column of the H matrix applies to any sale of the corresponding resource to energy purchasers504. For central plants that provide one or more additional types of resource, an additional row may be added to the H matrix and the g vector to define the equality constraints for each additional resource provided by the central plant.

In some embodiments, equality constraints module808augments the H matrix and the g vector to define relationships between the input resources and output resources of various subplants. The relationships between input and output resources may be defined by subplant curves. For example, the subplant curve for chiller subplant522may specify that each unit of cold thermal energy (e.g., kW) produced as an output resource requires 0.15 kW of electricity and 0.5 gal/hr of water as input resources. In this example, equality constraints module808may augment the H matrix and the g vector as follows:

H=[…6.67Ih0h-Ih…0h2⁢Ih-Ih],g=[0h0h]
The first row indicates that the amount of the output resource (e.g., cold water) produced is 6.67 times greater than the amount of the first input resource (e.g., electricity). In other words, 6.67 times the amount of the first input resource equals the output resource (e.g., 0.15*6.67˜1.0). The second row indicates that the amount of the output resource (e.g., cold water) produced is 2 times greater than the amount of the second input resource (e.g., water). In other words, 2 times the amount of the second input resource equals the output resource (e.g., 0.5*2 ˜1.0). Equality constraints based on subplant curves are described in greater detail below with reference to subplant curves module830.
Unmet Load Incorporation

Still referring toFIG.8, high level optimizer632is shown to include an unmet loads module810. In some instances, the central plant equipment may not have enough capacity or reserve storage to satisfy the predicted resource demand, regardless of how the resources are allocated. In other words, the high level optimization problem may have no solution that satisfies all of the inequality and equality constraints, even if the applicable subplants are operated at maximum capacity. Unmet loads module810may be configured to modify the high level optimization problem to account for this possibility and to allow the high level optimization to find the solution that results in the minimal amount of unmet loads.

In some embodiments, unmet loads module810modifies the decision variable matrix x by introducing a slack variable for each type of resource. The slack variables represent an unsatisfied (e.g., unmet, deferred, etc.) amount of each type of resource. For example, unmet loads module810may modify the decision variable matrix x as follows:
x=[ . . . xColdUnmet,1 . . . hxHotUnmet,1 . . . hxElecUnmet,1 . . . h. . . ]T
where xColdUnmet,1 . . . h, xHotUnmet,1 . . . h, and xElecUnmet,1 . . . hare h-dimensional vectors representing a total deferred cold thermal energy load, a total deferred hot thermal energy load, and a total deferred electrical load respectively, at each time step k within the optimization period. In some embodiments, the decision variables xColdUnmet,1 . . . h, xHotUnmet,1 . . . h, and xElecUnmet,1 . . . hrepresent total deferred loads that have accumulated up to each time step k rather than the incremental deferred load at each time step. The total deferred load may be used because any deferred load is likely to increase the required load during subsequent time steps.

Unmet loads module810may modify the equality constraints to account for any deferred thermal energy loads. The modified equality constraints may require that the predicted thermal energy loads are equal to the total loads satisfied by subplants520-530plus any unsatisfied thermal energy loads. The modified equality constraints can be placed in the form Hx=g by defining the H matrix and the g vector as follows:

Unmet loads module810may modify the cost vector c to associate cost values with any unmet loads. In some embodiments, unmet loads module810assigns unmet loads a relatively higher cost compared to the costs associated with other types of loads in the decision variable matrix x. Assigning a large cost to unmet loads ensures that the optimal solution to the high level optimization problem uses unmet loads only as a last resort (i.e., when the optimization has no solution without using unmet loads). Accordingly, linear program module804may avoid using unmet loads if any feasible combination of equipment is capable of satisfying the predicted thermal energy loads. In some embodiments, unmet loads module810assigns a cost value to unmet loads that allows linear program module804to use unmet loads in the optimal solution even if the central plant is capable of satisfying the predicted thermal energy loads. For example, unmet loads module810may assign a cost value that allows linear program module804to use unmet loads if the solution without unmet loads would be prohibitively expensive and/or highly inefficient.

Still referring toFIG.8, high level optimizer632is shown to include a subplant curves module830. In the simplest case described with reference to linear program module804, it was assumed that the resource consumption of each subplant is a linear function of the thermal energy load produced by the subplant. However, this assumption may not be true for some subplant equipment, much less for an entire subplant. Subplant curves module830may be configured to modify the high level optimization problem to account for subplants that have a nonlinear relationship between resource consumption and load production.

Subplant curves module830is shown to include a subplant curve updater832, a subplant curves database834, a subplant curve linearizer836, and a subplant curves incorporator838. Subplant curve updater832may be configured to request subplant curves for each of subplants520-530from low level optimizer634. Each subplant curve may indicate an amount of resource consumption by a particular subplant (e.g., electricity use measured in kW, water use measured in L/s, etc.) as a function of the subplant load. Exemplary subplant curves are shown and described in greater detail with reference toFIGS.9A-12.

In some embodiments, low level optimizer634generates the subplant curves by running the low level optimization process for various combinations of subplant loads and weather conditions to generate multiple data points. Low level optimizer634may fit a curve to the data points to generate the subplant curves and provide the subplant curves to subplant curve updater832. In other embodiments, low level optimizer634provides the data points to subplant curve updater832and subplant curve updater832generates the subplant curves using the data points. Subplant curve updater832may store the subplant curves in subplant curves database834for use in the high level optimization process.

In some embodiments, the subplant curves are generated by combining efficiency curves for individual devices of a subplant. A device efficiency curve may indicate the amount of resource consumption by the device as a function of load. The device efficiency curves may be provided by a device manufacturer or generated using experimental data. In some embodiments, the device efficiency curves are based on an initial efficiency curve provided by a device manufacturer and updated using experimental data. The device efficiency curves may be stored in equipment models618. For some devices, the device efficiency curves may indicate that resource consumption is a U-shaped function of load. Accordingly, when multiple device efficiency curves are combined into a subplant curve for the entire subplant, the resultant subplant curve may be a wavy curve as shown inFIG.10. The waves are caused by a single device loading up before it is more efficient to turn on another device to satisfy the subplant load.

Subplant curve linearizer836may be configured to convert the subplant curves into convex curves. A convex curve is a curve for which a line connecting any two points on the curve is always above or along the curve (i.e., not below the curve). Convex curves may be advantageous for use in the high level optimization because they allow for an optimization process that is less computationally expensive relative to an optimization process that uses non-convex functions. Subplant curve linearizer836may be configured to break the subplant curves into piecewise linear segments that combine to form a piecewise-defined convex curve. An unmodified subplant curve1000and a linearized subplant curve1100generated by subplant curve linearizer836are shown inFIGS.10and11, respectively. Subplant curve linearizer836may store the linearized subplant curves in subplant curves database834.

In some embodiments, the subplant curves model carbon emissions as an output resource from the corresponding subplant. For example, the subplant curves may define a relationship between (1) the amount or rate of on-site carbon emissions by a subplant and (2) the production and/or consumption of other resources by that subplant. In such embodiments, the carbon emissions could be modeled as a type of resource that is related to the other resources in the subplant curve, such that the subplant curve represents a relationship carbon emissions and any other represented resource production or consumption by a subplant. For example, if a given type of device (e.g., boiler) has three resources in its subplant curve (e.g., water, natural gas, and hot water) in some embodiments, in the example here the subplant curve also models carbon emissions as a fourth resource that is related to the other three resources. In such an embodiments, carbon emissions can be considered as being modeled as a function of water usage, natural gas consumption, and/or hot water production.

Still referring toFIG.8, subplant curves module830is shown to include a subplant curve incorporator838. Subplant curve incorporator838may be configured to modify the high level optimization problem to incorporate the subplant curves into the optimization. In some embodiments, subplant curve incorporator838modifies the decision matrix x to include one or more decision vectors representing the resource consumption of each subplant. In other embodiments, the decision matrix x is formulated by linear program module804to include the input resources and the output resources of each subplant, as shown in the following equation:
x=[ . . . xspn,in1,1 . . . hxspn,in2,1 . . . hxspn,out1,1 . . . h. . . ]T

Subplant curve incorporator838may modify the inequality constraints to ensure that the proper amount of each resource is consumed to serve the predicted thermal energy loads. In some embodiments, subplant curve incorporator838formulates inequality constraints that force the resource usage for each resource in the epigraph of the corresponding linearized subplant curve. For example, chiller subplant522may have a linearized subplant curve that indicates the electricity use of chiller subplant522(i.e., input resource in1) as a function of the cold water production of chiller subplant522(i.e., output resource out1). Such a linearized subplant curve1100is shown inFIG.11. The linearized subplant curve may include a first line segment connecting point [u1, Q1] to point [u2, Q2], a second line segment connecting point [u2, Q2] to point [u3, Q3], and a third line segment connecting point [u3, Q3] to point [u4, Q4].

Subplant curve incorporator838may formulate an inequality constraint for each piecewise segment of the subplant curve that constrains the value of the decision variable representing chiller electricity use to be greater than or equal to the amount of electricity use defined by the line segment for the corresponding value of the cold water production. The subplant curve constraints for the electricity use of chiller subplant522can be placed in the form Ax≤b by defining the A matrix and the b vector as follows:

Similar inequality constraints can be formulated for other subplant curves. For example, subplant curve incorporator838may generate a set of inequality constraints for the water consumption of chiller subplant522using the points defining the linearized subplant curve for the water consumption of chiller subplant522as a function of cold water production. In some embodiments, the water consumption of chiller subplant522is equal to the cold water production and the linearized subplant curve for water consumption includes a single line segment connecting point [u5, Q5] to point [u6, Q6] (as shown inFIG.9B). The subplant curve constraints for the cold water consumption of chiller subplant522can be placed in the form Ax≤b by defining the A matrix and the b vector as follows:
A=[ . . . [−(u6−u5)]In. . . 0n[(Q6−Q5)]In. . . ],b=[(Q5u6−Q6u5]
Subplant curve incorporator838may repeat this process for each subplant curve for chiller subplant522and for the other subplants of the central plant to define a set of inequality constraints for each subplant curve.

The inequality constraints generated by subplant curve incorporator838ensure that high level optimizer632keeps the resource consumption above all of the line segments of the corresponding subplant curve. In most situations, there is no reason for high level optimizer632to choose a resource consumption value that lies above the corresponding subplant curve due to the economic cost associated with resource consumption. High level optimizer632can therefore be expected to select resource consumption values that lie on the corresponding subplant curve rather than above it.

The exception to this general rule is heat recovery chiller subplant523. The equality constraints for heat recovery chiller subplant523provide that heat recovery chiller subplant523produces hot water at a rate equal to the subplant's cold water production plus the subplant's electricity use. The inequality constraints generated by subplant curve incorporator838for heat recovery chiller subplant523allow high level optimizer632to overuse electricity to make more hot water without increasing the amount of cold water production. This behavior is extremely inefficient and only becomes a realistic possibility when the demand for hot water is high and cannot be met using more efficient techniques. However, this is not how heat recovery chiller subplant523actually operates.

To prevent high level optimizer632from overusing electricity, subplant curve incorporator838may check whether the calculated amount of electricity use (determined by the optimization algorithm) for heat recovery chiller subplant523is above the corresponding subplant curve. In some embodiments, the check is performed after each iteration of the optimization algorithm. If the calculated amount of electricity use for heat recovery chiller subplant523is above the subplant curve, subplant curve incorporator838may determine that high level optimizer632is overusing electricity. In response to a determination that high level optimizer632is overusing electricity, subplant curve incorporator838may constrain the production of heat recovery chiller subplant523at its current value and constrain the electricity use of subplant523to the corresponding value on the subplant curve. High level optimizer632may then rerun the optimization with the new equality constraints.

Ground Loop and Heat Exchanger Incorporation

Still referring toFIG.8, high level optimizer632is shown to include a ground loop module812and a heat exchanger module814. In some embodiments, the central plant includes a heat exchanger configured to transfer heat between a hot water loop and a condenser water loop. In some embodiments, the central plant includes a ground loop that serves as heat rejection for chiller subplant522and/or heat extraction for heat recovery chiller subplant523. Ground loop module812and heat exchanger module814may be configured to modify the optimization problem to account for heat transfer resulting from operation of the heat exchanger and/or the ground loop.

Ground loop module812may incorporate heat rejection to the ground loop into the optimization problem by changing the amount of electricity and water usage by chiller subplant522. For example, for loadings up to the heat rejection capacity of the ground loop, chiller subplant522may use an additional amount of electricity to run the ground loop pumps. The additional electricity usage may be constant or may vary per unit of flow through the ground loop. The amount of water production of chiller subplant522may be constant regardless of whether the ground loop is used.

Ground loop module812and heat exchanger module814may incorporate heat extraction from the ground loop and heat transfer between the hot water loop and the condenser water loop into the optimization problem in a similar manner. For example, ground loop module812and heat exchanger module814may use heat extraction from the ground loop and heat transfer between the water loops to modify the load seen by the central plant equipment. Ground loop module812may use the ground loop to create what appears as a false building load to the equipment, thereby allowing heat recovery chiller subplant523to operate as heat pumps when the building load does not add enough heat to the system. This outcome may be optimal when the ratio between electricity prices and gas prices is low such that it is less expensive to operate the ground loop and the heat exchanger using electricity than it would be to use natural gas to generate heat in heater subplant521.

Heat exchanger module814may use the heat exchanger to create what appears to be a false hot water building load, thereby allowing heat recovery chiller subplant523to operate as conventional chillers. The excess heat from heat recovery chiller subplant523may be transferred through the heat exchanger to the condenser loop and ultimately into the atmosphere or into the ground. In some embodiments, heat exchanger module814operates the heat exchanger to prevent condenser loop from becoming overloaded. For example, heat exchanger module814may limit the total heat rejected to the capacity of the condenser loop minus the heat produced by the conventional chillers.

Ground loop module812and heat exchanger module814may modify the decision matrix x by adding a new decision vector for each type of thermal energy load. The new decision vectors may represent the overproduction of each thermal energy load for each time step k within the optimization period. Ground loop module812and heat exchanger module814may modify the equality constraints to account for any overproduced thermal energy loads. The overproduced thermal energy loads may be added to the equality constraints as slack variables that operate in the opposite direction of the unmet loads. The modified equality constraints may require that the predicted thermal energy loads plus any overproduction are equal to the total loads satisfied by subplants520-530plus any unsatisfied thermal energy loads. Ground loop module812and heat exchanger module814may modify the cost vector c with the additional cost of the pumping power per unit of overproduction required to run the ground loop and/or the heat exchanger.

Demand Charge Incorporation

Still referring toFIG.8, high level optimizer632is shown to include a demand charge module816. As discussed above, optimization framework module802may formulate the optimization problem as:

The demand charge is an additional charge imposed by some utility providers based on the maximum rate of energy consumption during an applicable demand charge period. For example, the demand charge may be provided in terms of dollars per unit of power (e.g., $/kW) and may be multiplied by the peak power usage (e.g., kW) during a demand charge period to calculate the demand charge. In some instances, the demand charge can account for more than 15% of the electrical bill. Failure to include the demand charge in the optimization scheme can cause all of the equipment to turn on at the same time (e.g., the most efficient or lowest cost time). This would be optimal from a consumption cost standpoint. However, shifting some of the load in time may save thousands of dollars on demand while only costing a few dollars in consumption cost.

Demand charge module816may be configured to modify the optimization problem to account for the demand charge. Incorporating the demand charge into the optimization framework may greatly improve the performance of the high level optimization. For example, including the demand charge in the optimization framework may reduce the total operating costs of the central plant by an additional 5% on top of the 8-10% cost reduction provided by other modules of central plant controller506. In various implementations, the savings provided by demand charge module816and/or central plant controller506as a whole may be greater than or less than the exemplary amounts defined herein due to differences in plant configuration and/or energy costs.

Demand charge module816may account for the demand charge by modifying the cost function used by high level optimizer632. The modified cost function may be defined as:

arg⁢minx[cT⁢x+cd⁢e⁢m⁢a⁢n⁢d⁢max⁡(Pelec,k)];subject⁢to⁢Ax≤b,H⁢x=g
where cdemandis the demand charge (e.g., $/kW) for the applicable demand charge period and Pelec,kis the total electrical power purchased from utilities510at time step k. The term max(Pelec,k) selects the peak electrical power at any time during the demand charge period. The demand charge cdemandand the demand charge period may be defined by the utility rate information received from utilities510and may be provided to high level optimizer632by load/rate predictor622.

Incorporating the demand charge into the optimization framework complicates the optimization problem in two primary ways. First, the cost function is no longer linear due to the inclusion of the max( ) function. Second, the consumption term cTx calculates cost over a consumption period defined by a time horizon, whereas the demand charge term cdemandmax(Pelec,k) calculates cost over the demand charge period. For example, the consumption period may be defined as the time period beginning at the current time step k and ending at a future time step k+h, where h represents the time horizon. The demand charge period may be defined by utilities510and provided to high level optimizer632along with the utility rate information. In some instances, the consumption period and the demand charge period may not be the same. This complicates the optimization problem by obfuscating potential trade-offs between control decisions that reduce the consumption term at the expense of the demand charge term or vice versa.

Demand charge module816may modify the optimization problem to incorporate the demand charge term into the linear optimization framework. For example, demand charge module816may modify the decision matrix x by adding a new decision variable xpeakas follows:
xnew=[ . . . xelec,1 . . . h. . . xpeak]T
where xpeakis the peak electricity within the demand charge period and xelec,1 . . . his the electricity purchase at each of the h time steps. Demand charge module816may modify the cost vector c as follows:
cnew=[ . . . celec,1 . . . h. . . cdemand]T
such that the demand charge cdemandis multiplied by the peak power consumption xpeak.

Demand charge module816may formulate and/or apply inequality constraints to ensure that the peak power consumption xpeakis greater than or equal to the maximum electric demand over the demand charge period. I.e.:
xpeak≥max(xelec,k) ∀k∈horizon
This inequality constraint may be represented in the linear optimization framework by defining the A matrix and the b vector as follows:
A=[ . . . Ih. . . −1],b=0

During the high level optimization process, high level optimizer632may choose a xpeakthat is equal to the maximum electrical demand over the demand charge period to minimize the cost associated with xpeak.

Demand charge module816may apply an inequality constraint to ensure that the peak power consumption decision variable xpeakis greater than or equal to its previous value xpeak,previousduring the demand charge period. This inequality constraint may be represented in the linear optimization framework by defining the A matrix and the b vector as follows:
A=[ . . . −1],b=−xpeak,previous

Advantageously, the modifications to the decision variable matrix x, the cost vector c, and the inequality constraints provided by demand charge module816allow the cost function to be written in a linear form as follows:

The cost function as written in the previous equation has components that are over different time periods. For example, the consumption term cTx is over the consumption period whereas the demand charge term cdemandxpeakis over the demand charge period. To properly make the trade-off between increasing the demand charge versus increasing the cost of energy consumption, demand charge module816may apply a weighting factor to the demand charge term and/or the consumption term. For example, demand charge module816may divide the consumption term cTx by the duration h of the consumption period (i.e., the time period between the current time and the time horizon) and multiply by the amount of time ddemandremaining in the current demand charge period so that the entire cost function is over the demand charge period. The new optimization function may be given by:

arg⁢minx[dd⁢e⁢m⁢a⁢n⁢dh⁢cT⁢x+cd⁢e⁢m⁢a⁢n⁢d⁢xp⁢e⁢a⁢k];subject⁢to⁢Ax≤b,H⁢x=g
which is equivalent to:

arg⁢minx[cT⁢x+hdd⁢e⁢m⁢a⁢n⁢d⁢cd⁢e⁢m⁢a⁢n⁢d⁢xp⁢e⁢a⁢k];subject⁢to⁢Ax≤b,H⁢x=g
The latter form of the new optimization function has the advantage of adjusting only one term of the function rather than several.
Carbon Emissions Incorporation

Still referring toFIG.8, high level optimizer632is shown to include a carbon emissions module817. The carbon emissions module817may operate to cause the high level optimizer632to account for (e.g., penalize) carbon emissions resulting from decisions of the high level optimizer632. To account for carbon emissions, a term accounting for carbon emissions as a function of load allocations indicated by decision matrix x can be generated by the carbon emissions module817. For example, the carbon emissions module817may provide a term λ*M(x) where the function M(x) estimates an amount of carbon emissions resulting from a set of decisions x and λ is a scaling factor or weight (e.g., a cost per unit of carbon emissions). The estimated carbon emissions can include both on-site and off-site emissions. The carbon emissions module817can cause the optimization problem to be expressed as:

By incorporating an emissions term (e.g., λM(x)) in to the objective function used by the high level optimizer632, the high level optimizer632will prefer solutions which result in lower carbon emissions, including on-site and/or off-site emissions. For example, the emissions term in the objective function may cause the high level optimizer632to allocate a higher proportion of the heating demand to the heat recovery chiller subplant523which operates on electricity and a correspondingly lower proportion of the heating demand to the steam subplant524which may include boilers that burn natural gas, in order to achieve carbon emissions savings (even when such a decision may increase utility costs). The emission term may also drive increased usage of thermal energy storage (e.g., hot thermal energy storage531and cold thermal energy storage532) which enables time-shifting of thermal energy production to time periods associated with lower emissions, for example to time periods where the energy grid has lower marginal operating emissions rate and/or to time periods where non-emitting or low-emitting subplants have available capacity. For example, the emissions term in the objective function may cause the high level optimizer632to maximize utility of the heat recovery chiller subplant523and hot thermal energy storage531while minimizing use of fossil-fuel burning boilers to create hot water.

The function M(x) mapping decision variables to carbon emissions may have various forms in various embodiments. In some embodiments, the function M(x) uses information from subplant curves, for example subplant curves which model on-site carbon emissions as an output resource of a subplant. In some embodiments, the function M(x) uses a marginal operating emissions rate of electricity received from a utility grid to calculate an amount of emissions associated with an amount of electricity consumed as a result of a set of decision variables. Various approaches can be used to define, identify, fit, etc. a function M(x) that calculated carbon emissions as a function of decision variables of the optimization problem.

In examples where the demand charge module816and the carbon emissions module both operate, the optimization function may be given by:

arg⁢minx[dd⁢e⁢m⁢a⁢n⁢dh⁢cT⁢x+cd⁢e⁢m⁢a⁢n⁢d⁢xp⁢e⁢a⁢k+λ⁢M⁡(x)];subject⁢to⁢Ax≤b,Hx=g
which is equivalent to:

In other embodiments, the carbon emissions module817adds an emissions-related cost to the optimization problem by increasing the size of the c and x vectors, for example as in the approach used by the penalty function module820described below. In such an example, the carbon emissions module817may assign additional elements in c which provide a penalty rate associated with carbon emissions and additional decision variables in x which indicate amounts of carbon emissions (e.g., amounts from different subplants, on-site amounts, off-site amounts). Such penalty rates and emissions amounts can be determined using the various approaches described below with reference toFIGS.15-26.

Tank Forced Full Incorporation

Still referring toFIG.8, high level optimizer632is shown to include a tank forced full module818. Tank forced full module818may modify the optimization problem such that the thermal energy storage (TES) tanks are forced to full at the end of the optimization period. This feature provides increased robustness in the event of a subplant failure and/or controller failure by ensuring that the TES tanks have sufficient stored thermal energy to satisfy building loads while the failure is being repaired. For example, plant operators can use the stored thermal energy to meet the building loads while central plant controller506is brought back online.

Tank forced full module818may force the TES tanks to full by increasing the cost of discharging the TES tanks. In some embodiments, tank forced full module818modifies the cost of discharging the TES tanks such that the discharge cost is higher than other costs in the cost function, but less than the cost of unmet loads. This forces high level optimizer632to take the benefit (i.e., negative cost) of charging the TES tanks to their maximum values.

Penalty Incorporation

Still referring toFIG.8, high level optimizer632is shown to include a penalty function module820. In some instances, high level optimizer632determines a solution to the optimization problem that includes significantly changing the load on one or more of subplants520-530within a relatively short timeframe. For example, the lowest cost solution from a resource consumption standpoint may involve taking a subplant from off to full load and back to off again within only a few time steps. This behavior may result from high level optimizer632identifying small fluctuations in the economic cost of resources and operating the central plant accordingly to achieve the minimal economic cost. However, operating the central plant in such a way may be undesirable due to various negative effects of rapidly changing the subplant loads (e.g., increased equipment degradation), especially if the cost saved is relatively minimal (e.g., a few cents or dollars).

Penalty function module820may modify the optimization problem to introduce a penalty for excessive equipment start/stops (e.g., in excess of a threshold). The penalty may subtract from the overall value which high level optimizer632seeks to optimize and may be represented in the value function as the $Penalty term. In some embodiments, the penalty is defined according to a penalty function. The penalty function may be a function of the control decisions made by high level optimizer. For example, the penalty function may be defined as follows:
$Penalty=f(Ncommands)
where Ncommandsis the total number of on/off commands provided to the equipment over the duration of the optimization period. In some embodiments, the value of the penalty is proportional to the number of on/off commands or otherwise dependent upon the number of on/off commands.

In some embodiments, penalty function module820modifies the optimization problem to introduce a penalty for rapidly changing the subplant loads. For example, penalty function module820may modify the decision matrix x by adding a new decision vector for each subplant. The new decision vectors represent the change in subplant load for each subplant from one time step to the next. For example, penalty function module820may modify the decision matrix x as follows:
x=[ . . . δsp1,1 . . . hδsp2,1 . . . h. . . δspn,1 . . . h]T
where δsp1,1 . . . h, δsp2,1 . . . h, and δspn,1 . . . hare h-dimensional vectors representing the changes in outputs of each subplant at each time step k relative to the previous time step k−1. For example, the variable δsp1,kmay be defined as the difference between the decision variable xsp1,out1,krepresenting the first output out1from subplant sp1at time k and the decision variable xsp1,out1,k-1representing the first output out1from subplant sp1at time k−1.

Penalty function module820may add constraints such that each of the variables δ cannot be less than the change in the corresponding subplant load. For example, the added constraints for chiller subplant522may have the following form:

A=[…Ih-D-1…-Ih0h0h…D1-Ih…-Ih0h0h⋮⋮⋮⋮⋮⋮],b=[[xsp1,out1,k-10h-1][-xsp1,out1,k-10h-1]⋮]
where xsp1,out1,k-1is the value of the decision variable representing the output of subplant sp1at time k−1. Similar constraints may be added for each of subplants520-530.

The constraints added by penalty function module820require the change variables δ to be greater than or equal to the magnitude of the difference between the current value of the corresponding subplant output and the previous value of the subplant output. In operation, high level optimizer632may select values for the change variables δ that are equal to the magnitude of the difference due to the costs associated with the change variables. In other words, high level optimizer632may not choose to make the change variables δ greater than the actual change in the corresponding subplant output because making the change variables δ greater than necessary would be suboptimal.

Incentive Program Incorporation

Still referring toFIG.8, high level optimizer632is shown to include an incentive program module822. Incentive program module822may modify the optimization problem to account for revenue from participating in an incentive-based demand response (IBDR) program. IBDR programs may include any type of incentive-based program that provides revenue in exchange for resources (e.g., electric power) or a reduction in a demand for such resources. For example, central plant system500may provide electric power to an energy grid or an independent service operator as part of a frequency response program (e.g., PJM frequency response) or a synchronized reserve market. In a frequency response program, a participant contracts with an electrical supplier to maintain reserve power capacity that can be supplied or removed from an energy grid by tracking a supplied signal. The participant is paid by the amount of power capacity required to maintain in reserve. In other types of IBDR programs, central plant system500may reduce its demand for resources from a utility as part of a load shedding program. It is contemplated that central plant system500may participate in any number and/or type of IBDR programs.

Advantageously, incentive program module822may be configured to modify the optimization problem to account for participation in any number of IBDR programs. For example, incentive program module822may incorporate IBDR revenue into the value function which high level optimizer632seeks to optimize (e.g., the $IBDR term of the value function). Incentive program module822may also add a decision variable xresourcep,progs,1 . . . hto the decision matrix x for each IBDR program in which central plant system500can potentially participate, as shown in the following equation:
x=[ . . . xresourcep,under,1 . . . hxresourcep,over,1 . . . hxresourcep,storage,1 . . . hxresourcep,progs,1 . . . h]T
where the decision variable xresourcep,progs,1 . . . hrepresents the amount of resource p allocated to IBDR program s at each of the h time steps. Incentive program module822may add similar decision variables for each IBDR program.

Incentive program module822may modify the cost vector c to include the revenue offered for participating in each IBDR program. For example, incentive program module822may modify the cost vector c as shown in the following equation:
c=[ . . . M M0 −rresourcep,progs,1 . . . h]T
where the variable rresourcep,progs,1 . . . hrepresents the revenue offered for participating in IBDR program s at each of the h time steps. The revenue variables may be based on statistical estimates of IBDR event characteristics (e.g., event times, revenue potential, reserve capacity required, etc.) as described with reference to incentive estimator620.

Incentive program module822may generate and impose constraints that allow for participation in various IBDR programs. For example, incentive program module822may modify the A matrix and the b vector as shown in the following equation:

A=[…00Ihpcharge…00-Ihpd⁢ischarge…00Ts⁢Δhpc⁢a⁢p…00-Ts⁢Δhpc⁢a⁢p],b=[⋮xdischargep,maxxchargep,maxCstoragep,0Cstoragep·max-Cstoragep,0]
where pcharge, pdischarge, and pcapare the marginal amounts of reserve charging rate, discharging rate, and storage capacity (per unit of participation) that must be maintained in order to participate in the IBDR program. Advantageously, these constraints allow high level optimizer632to weigh the benefits of participating in various IBDR programs (e.g., expected revenue) against the costs of participation (e.g., less resources available for satisfying building loads). If the expected revenue for participation outweighs the costs, high level optimizer632may allocate resources to the IBDR program. However, if the expected revenue does not outweigh the costs, high level optimizer632may allocate the resources to satisfying building loads.
Battery Capacity Loss Incorporation

Still referring toFIG.8, high level optimizer632is shown to include a battery capacity loss module824. Battery capacity loss module824may be configured to adjust the optimization problem to account for a loss in battery capacity (e.g., electrical energy storage533) as a result of the control decisions made by high level optimizer632. For example, battery capacity loss module824may use a battery capacity loss model to determine an expected loss in battery capacity as a result of the control decisions. The battery capacity loss model may monetize the loss in battery capacity based on the lost revenue of not being able to participate in IBDR programs due to premature battery capacity loss attributed to certain control actions. The monetized loss in battery capacity may be provided as a term in the value function (e.g., the $BL term) which high level optimizer632seeks to optimize.

In some embodiments, battery capacity loss module824estimates battery capacity loss as a function of the decision variables. For example, the loss in battery capacity may be defined by the following battery capacity loss model:

$⁢B⁢L=f⁡(D⁢O⁢D,T,S⁢O⁢C,∑k⁢Wb⁢a⁢t⁢t,∑d⁢k⁢Wb⁢a⁢t⁢td⁢t,R⁢M⁢C⁢C⁢P_,R⁢M⁢P⁢C⁢P_,M⁢R_,in,n)
where $BL is the monetized cost of battery capacity loss, DOD represents the depth of discharge of the battery, SOC represents the state of charge of the battery, kWbattrepresents the battery power draw,

d⁢k⁢Wb⁢a⁢t⁢td⁢t
represents the change in battery power draw,RMCCPrepresents the average regulation market capability clearing price (RMCCP),RMPCPrepresents the average regulation market performance clearing price (RMCCP) andMRrepresents the average mileage ratio (MR). The loss in battery capacity may be a function of several inputs which can be modified by high level optimizer632such as the state of charge, the depth of discharge, the amount of energy moved (e.g., average power ratio), and the change in power draw (e.g., average effort ratio). For example, high level optimizer632can increase or decrease many of these inputs by adjusting the amount of power allocated to the battery (i.e., electrical energy storage subplant533) at each time step.

In some embodiments, battery capacity loss module824determines an expected loss in battery capacity as a function of the control decisions made by high level optimizer632. Battery capacity loss module824may monetize the expected loss in battery capacity and/or provide the expected loss in battery capacity to high level optimizer632. High level optimizer632may use the expected loss in battery capacity over time to determine the consequences of certain control decisions. For example, some control decisions may result in a relatively faster loss in battery capacity than other control decisions. Therefore, some control decisions may limit the ability of central plant system500to participate in IBDR programs in the future due to the battery capacity failing to meet IBDR requirements. Advantageously, high level optimizer632can predict the expected loss in revenue resulting from certain control decisions and weigh the predicted loss in revenue against the benefits of the control decisions. High level optimizer632may select a set of optimal control decisions that maximizes the overall value over the duration of the prediction window, while accounting for the cost of certain control decisions in terms of losses in battery capacity and the lost IBDR revenue associated therewith.

Referring now toFIGS.9A-B, two subplant curves900and910are shown, according to an exemplary embodiment. Subplant curves900and910define the resource usage of a subplant (e.g., one of subplants520-530) as a function of the subplant load. Each subplant curve may be specific to a particular subplant and a particular type of resource used by the subplant. For example, subplant curve900may define the electricity use902of chiller subplant522as a function of the load904on chiller subplant522, whereas subplant curve910may define the water use906of chiller subplant522as a function of the load904on chiller subplant522. Each of subplants520-530may have one or more subplant curves (e.g., one for each type of resource consumed by the subplant).

In some embodiments, low level optimizer634generates subplant curves900and910based on equipment models618(e.g., by combining equipment models618for individual devices into an aggregate curve for the subplant). Low level optimizer634may generate subplant curves900and910by running the low level optimization process for several different loads and weather conditions to generate multiple data points. Low level optimizer634may fit a curve to the data points to generate the subplant curves. In other embodiments, low level optimizer634provides the data points to high level optimizer632and high level optimizer632generates the subplant curves using the data points.

Referring now toFIG.10, another subplant curve1000is shown, according to an exemplary embodiment. Subplant curve1000defines the electricity use of chiller subplant522as a function of the cold water production of chiller subplant522. In some embodiments, subplant curve1000is generated by combining efficiency curves for individual devices of chiller subplant522(e.g., individual chillers, pumps, etc.). For example, each of the chillers in subplant522may have a device-specific efficiency curve that defines the amount of electricity use by the chiller as a function of the load on the chiller. Many devices operate less efficiently at higher loads and have device efficiency curves that are U-shaped functions of load. Accordingly, combining multiple device efficiency curves to form subplant curve1000may result in subplant curve1000having one or more waves1002, as shown inFIG.10. Waves1002may be caused by a single device loading up before it is more efficient to turn on another device to satisfy the subplant load.

Referring now toFIG.11, a linearized subplant curve1100is shown, according to an exemplary embodiment. Subplant curve1100defines the electricity use of chiller subplant522as a function of the cold water production of chiller subplant522. Subplant curve1100may be generated by converting subplant curve1000into a linearized convex curve. A convex curve is a curve for which a line connecting any two points on the curve is always above or along the curve (i.e., not below the curve). Convex curves may be advantageous for use in the high level optimization because they allow for an optimization process that is less computationally expensive relative to an optimization process that uses non-convex functions.

In some embodiments, subplant curve1100is generated by subplant curve linearizer836, as described with reference toFIG.8. Subplant curve1100may be created by generating a plurality of linear segments (i.e., segments1102,1104, and1106) that approximate subplant curve1000and combining the linear segments into a piecewise-defined linearized convex curve1100. Linearized subplant curve1100is shown to include a first linear segment1102connecting point [u1, Q1] to point [u2, Q2], a second linear segment1104connecting point [u2, Q2] to point [u3, Q3], and a third linear segment1106connecting point [u3, Q3] to point [u4, Q4]. The endpoints of line segments1102-1106may be used to form constraints that force the electricity use of chiller subplant522in the epigraph of the linearized subplant curve1100.

Referring now toFIG.12, another subplant curve1200is shown, according to an exemplary embodiment. Subplant curve1200defines the energy use of one of subplants520-530as a function of the load on the subplant for several different weather conditions. In some embodiments, subplant curve1200is generated by subplant curves module830using experimental data obtained from the low level optimizer634. For example, subplant curve updater832may request resource usage data from low level optimizer634for various combinations of load conditions and environmental conditions. In the embodiment shown inFIG.12, subplant curve updater832requests energy use data for each combination of temperature (e.g., 40° F., 50° F., 60° F., and 70° F.) and load (e.g., 170 tons, 330 tons, 500 tons, 830 tons, and 1000 tons). Low level optimizer634may perform the low level optimization process for the requested load and temperature combinations and return an energy use value for each combination.

Subplant curve updater832may use the data points provided by low level optimizer634to find the best piecewise linear convex function that fits the data. For example, subplant curve updater832may fit a first subplant curve1202to the data points at 70° F., a second subplant curve1204to the data points at 60° F., a third subplant curve1206to the data points at 50° F., and a fourth subplant curve1208to the data points at 40° F. Subplant curve updater832may store the generated subplant curves1202-1208in subplant curves database834for use in the high level optimization algorithm.

In some implementations, central plant controller506uses high level optimizer632as part of an operational tool to exercise real-time control over the central plant. In the operational tool, high level optimizer632may receive load and rate predictions from load/rate predictor622and subplant curves (or data that can be used to generate subplant curves) from low level optimizer634. When implemented in the operational tool, high level optimizer632may determine an optimal load distribution for heater subplant521, heat recovery chiller subplant523, chiller subplant522, hot TES subplant531, cold TES subplant532, electrical energy storage subplant533, and/or energy purchasers504, as described with reference toFIGS.5-8. In some embodiments, high level optimizer632determines ground loop and heat exchanger transfer rates in addition to the subplant loads. When implemented in the operational tool, high level optimizer632may provide the determined resource allocation to low level optimizer634for use in determining optimal on/off decisions and/or operating setpoints for the equipment of each subplant.

Planning Tool

Referring now toFIG.13, a block diagram of a planning system1300is shown, according to an exemplary embodiment. Planning system1300may be configured to use demand response optimizer630as part of a planning tool1302to simulate the operation of a central plant over a predetermined time period (e.g., a day, a month, a week, a year, etc.) for planning, budgeting, and/or design considerations. When implemented in planning tool1302, demand response optimizer630may operate in a similar manner as described with reference toFIGS.6-8. For example, demand response optimizer630may use building loads and utility rates to determine an optimal resource allocation to minimize cost over a simulation period. However, planning tool1302may not be responsible for real-time control of a building management system or central plant.

In planning tool1302, high level optimizer632may receive planned loads and utility rates for the entire simulation period. The planned loads and utility rates may be defined by input received from a user via a client device1322(e.g., user-defined, user selected, etc.) and/or retrieved from a plan information database1326. High level optimizer632uses the planned loads and utility rates in conjunction with subplant curves from low level optimizer634to determine an optimal resource allocation (i.e., an optimal dispatch schedule) for a portion of the simulation period.

The portion of the simulation period over which high level optimizer632optimizes the resource allocation may be defined by a prediction window ending at a time horizon. With each iteration of the optimization, the prediction window is shifted forward and the portion of the dispatch schedule no longer in the prediction window is accepted (e.g., stored or output as results of the simulation). Load and rate predictions may be predefined for the entire simulation and may not be subject to adjustments in each iteration. However, shifting the prediction window forward in time may introduce additional plan information (e.g., planned loads and/or utility rates) for the newly-added time slice at the end of the prediction window. The new plan information may not have a significant effect on the optimal dispatch schedule since only a small portion of the prediction window changes with each iteration.

In some embodiments, high level optimizer632requests all of the subplant curves used in the simulation from low level optimizer634at the beginning of the simulation. Since the planned loads and environmental conditions are known for the entire simulation period, high level optimizer632may retrieve all of the relevant subplant curves at the beginning of the simulation. In some embodiments, low level optimizer634generates functions that map subplant production to equipment level production and resource use when the subplant curves are provided to high level optimizer632. These subplant to equipment functions may be used to calculate the individual equipment production and resource use (e.g., in a post-processing module) based on the results of the simulation.

Still referring toFIG.13, planning tool1302is shown to include a communications interface1304and a processing circuit1306. Communications interface1304may include wired or wireless interfaces (e.g., jacks, antennas, transmitters, receivers, transceivers, wire terminals, etc.) for conducting data communications with various systems, devices, or networks. For example, communications interface1304may include an Ethernet card and port for sending and receiving data via an Ethernet-based communications network and/or a WiFi transceiver for communicating via a wireless communications network. Communications interface1304may be configured to communicate via local area networks or wide area networks (e.g., the Internet, a building WAN, etc.) and may use a variety of communications protocols (e.g., BACnet, IP, LON, etc.).

Communications interface1304may be a network interface configured to facilitate electronic data communications between planning tool1302and various external systems or devices (e.g., client device1322, results database1328, plan information database1326, etc.). For example, planning tool1302may receive planned loads and utility rates from client device1322and/or plan information database1326via communications interface1304. Planning tool1302may use communications interface1304to output results of the simulation to client device1322and/or to store the results in results database1328.

Still referring toFIG.13, processing circuit1306is shown to include a processor1310and memory1312. Processor1310may be a general purpose or specific purpose processor, an application specific integrated circuit (ASIC), one or more field programmable gate arrays (FPGAs), a group of processing components, or other suitable processing components. Processor1310may be configured to execute computer code or instructions stored in memory1312or received from other computer readable media (e.g., CDROM, network storage, a remote server, etc.).

Memory1312may include one or more devices (e.g., memory units, memory devices, storage devices, etc.) for storing data and/or computer code for completing and/or facilitating the various processes described in the present disclosure. Memory1312may include random access memory (RAM), read-only memory (ROM), hard drive storage, temporary storage, non-volatile memory, flash memory, optical memory, or any other suitable memory for storing software objects and/or computer instructions. Memory1312may include database components, object code components, script components, or any other type of information structure for supporting the various activities and information structures described in the present disclosure. Memory1312may be communicably connected to processor1310via processing circuit1306and may include computer code for executing (e.g., by processor1310) one or more processes described herein.

Still referring toFIG.13, memory1312is shown to include a GUI engine1316, web services1314, and configuration tools1318. In an exemplary embodiment, GUI engine1316includes a graphical user interface component configured to provide graphical user interfaces to a user for selecting or defining plan information for the simulation (e.g., planned loads, utility rates, environmental conditions, etc.). Web services1314may allow a user to interact with planning tool1302via a web portal and/or from a remote system or device (e.g., an enterprise control application).

Configuration tools1318can allow a user to define (e.g., via graphical user interfaces, via prompt-driven “wizards,” etc.) various parameters of the simulation such as the number and type of subplants, the devices within each subplant, the subplant curves, device-specific efficiency curves, the duration of the simulation, the duration of the prediction window, the duration of each time step, and/or various other types of plan information related to the simulation. Configuration tools1318can present user interfaces for building the simulation. The user interfaces may allow users to define simulation parameters graphically. In some embodiments, the user interfaces allow a user to select a pre-stored or pre-constructed simulated plant and/or plan information (e.g., from plan information database1326) and adapt it or enable it for use in the simulation.

Still referring toFIG.13, memory1312is shown to include demand response optimizer630. Demand response optimizer630may use the planned loads and utility rates to determine an optimal resource allocation over a prediction window. The operation of demand response optimizer630may be the same or similar as previously described with reference toFIGS.6-8. With each iteration of the optimization process, demand response optimizer630may shift the prediction window forward and apply the optimal resource allocation for the portion of the simulation period no longer in the prediction window. Demand response optimizer630may use the new plan information at the end of the prediction window to perform the next iteration of the optimization process. Demand response optimizer630may output the applied resource allocation to reporting applications1330for presentation to a client device1322(e.g., via user interface1324) or storage in results database1328.

Still referring toFIG.13, memory1312is shown to include reporting applications1330. Reporting applications1330may receive the optimized resource allocations from demand response optimizer630and, in some embodiments, costs associated with the optimized resource allocations. Reporting applications1330may include a web-based reporting application with several graphical user interface (GUI) elements (e.g., widgets, dashboard controls, windows, etc.) for displaying key performance indicators (KPI) or other information to users of a GUI. In addition, the GUI elements may summarize relative energy use and intensity across various plants, subplants, or the like. Other GUI elements or reports may be generated and shown based on available data that allow users to assess the results of the simulation. The user interface or report (or underlying data engine) may be configured to aggregate and categorize resource allocation and the costs associated therewith and provide the results to a user via a GUI. The GUI elements may include charts or histograms that allow the user to visually analyze the results of the simulation. An exemplary output that may be generated by reporting applications1330is shown inFIG.14.

Referring now toFIG.14, several graphs1400illustrating the operation of planning tool1302are shown, according to an exemplary embodiment. With each iteration of the optimization process, planning tool1302selects an optimization period (i.e., a portion of the simulation period) over which the optimization is performed. For example, planning tool1302may select optimization period1402for use in the first iteration. Once the optimal resource allocation1410has been determined, planning tool1302may select a portion1418of resource allocation1410to send to plant dispatch1430. Portion1418may be the first b time steps of resource allocation1410. Planning tool1302may shift the optimization period1402forward in time, resulting in optimization period1404. The amount by which the prediction window is shifted may correspond to the duration of time steps b.

Planning tool1302may repeat the optimization process for optimization period1404to determine the optimal resource allocation1412. Planning tool1302may select a portion1420of resource allocation1412to send to plant dispatch1430. Portion1420may be the first b time steps of resource allocation1412. Planning tool1302may then shift the prediction window forward in time, resulting in optimization period1406. This process may be repeated for each subsequent optimization period (e.g., optimization periods1406,1408, etc.) to generate updated resource allocations (e.g., resource allocations1414,1416, etc.) and to select portions of each resource allocation (e.g., portions1422,1424) to send to plant dispatch1430. Plant dispatch1430includes the first b time steps1418-1424from each of optimization periods1402-1408. Once the optimal resource allocation is compiled for the entire simulation period, the results may be sent to reporting applications1330, results database1328, and/or client device1322, as described with reference toFIG.13.

Predictive Control with Carbon Emissions Optimization

Referring now toFIG.15, a flowchart of a process3100for predictive control with carbon emissions optimization is shown, according to an exemplary embodiment. Process3100can be executed by the BMS controller366, for example. Process3100can be executed by or for a smart thermostat, for example as described in U.S. patent application Ser. No. 16/598,539, filed Oct. 10, 2019, incorporated by reference herein. Process3100can also be executed by a building management system or controllers for building equipment, for example as described in U.S. application Ser. No. 15/199,909, filed Jun. 30, 2016, U.S. application Ser. No. 13/802,154, filed Mar. 13, 2013 or U.S. application Ser. No. 16/687,122, filed Nov. 18, 2019, the entire disclosures of which are incorporated by reference herein.

At step3101a rate (or other function) of carbon emissions per unit energy of local fuel consumption is obtained. Step3101can include using tests, measurements, historical data, etc. in order to measure and model (e.g., via regression modeling) the amount of carbon emissions from different subplants as functions of the amount of fuel consumption of such subplants, which, as described elsewhere herein, can also be predicted as a function of resource output of such subplants. In some embodiments, the rate is a static scalar multiple, such that carbon emissions are proportional to energy consumption. In other embodiments, the rate is dynamic, for example varying with a function of the operating capacity of a subplant (e.g., where carbon capture is more efficient at higher or lower fractions of operating capacity depending equipment design and characteristics) or other dynamic conditions and factors that can influence the amount of carbon emissions, the effectiveness of filters or carbon capture systems, etc. In some embodiments, step3101includes obtaining one or more rates as user inputs, based manufacturer data sheets, or based on various digitized information describing the particular equipment types and model numbers used in a particular central plant.

Because different subplants consume fuel in different ways and can include different filters, carbon capture systems, etc., the rate of carbon emissions per unit fuel consumed can be different for different subplants, such that step3101includes obtaining multiple rates for multiple subplants. In some examples, step3101outputs a vector including a different rate for each subplant, or for each particular unit of equipment in a subplant. In such embodiments, values of zero can be provided for elements corresponding to subplants that do not emit carbon (e.g., consume electricity rather than fuel), while non-zero positive values are provided for elements corresponding to subplants that consume natural gas or other fuel (and thus emit carbon). Such a vector formulation would be suitable for use with the example expressions shown with reference toFIGS.6-8above, for example.

At step3102, a time-varying indicator of carbon emissions per unit energy or power is received from the utility grid, for example a power:carbon ratio (i.e., average carbon per unit power provided by the grid) or a marginal operating emissions rate (MOER) (i.e., carbon per marginal unit power as described below). The MOER may also be characterized as a time-varying indication of the availability of green energy. That is, in the scenario of step3102, the operator of the utility grid provides an estimate of the amount of carbon emitted in order to produce each unit of energy or power provided to a customer of the utility grid. Because renewable energy may contribute different percentages of total grid energy under different environmental conditions, different times of day, etc. a carbon:power or carbon:energy ratio can be time-varying. Additionally, because different renewable sources and fossil-fuel consuming plants may come online at different times or under different total demands on the grid, the source of power that generates a marginal unit of energy also changes over time such that the carbon emissions associated with marginal energy consumption (i.e., consuming vs. not consuming the next unit of energy) also changes over time.

The rate of emissions associated with marginal energy consumption is referred to herein as the marginal operating emissions rate (MOER) and can be broadcast by a utility grid operator to its customers in some embodiments, for example at a frequency of once every five minutes. To illustrate some examples,FIG.16shows graphs of MOER over time in different seasons. A first graph3150shows MOER over time for a week in February. In the example shown, the MOER can fluctuate between about 1000 lbs/MWh and 0 lbs/MWh. In the first graph3150, the MOER is zero during parts of some days, for example during a middle portion of the day when photovoltaic energy production is sufficient to meet the demands of the grid. At night, in cloudy conditions, or in high-demand periods, the grid relies on fossil-fuel-based energy (coal, natural gas, etc.) to meet demand, such that the MOER jumps to a higher value when such plants are brought online to serve the marginal demand on the utility grid. In the second graph3152, which shows MOER for a week in July, it can be seen that higher MOER can occur even during daytime (when solar power is available) under high-demand periods, showing that MOER can deviate from a standard pattern or oscillation. The first graph3150and the second graph3152show that there are opportunities to reduce marginal emissions by time-shifting consumption to periods with lower MOER, which can be achieved by process3100as described herein. In the third graph3154, which shows MOER for a week in August, it can be seen that in high, constant demand periods (e.g., during a heat wave when air conditioners are constantly run to put a high demand on the utility grid), carbon-emitting sources will always remain online to serve the marginal energy demand, such that MOER stays substantially constant throughout such periods.

In step3102, assuming such data is available from the utility grid, the time-varying indicator of carbon emissions (e.g., MOER) is received from the utility grid. In some scenarios, the utility grid may also provide predicted or expected MOER or carbon:power or carbon:energy ratios for future time periods. In some embodiments, a time-varying indicator of carbon emission associated with non-electricity resources is also received, for example indicating an amount of emissions linked to energy used to obtain, treat, pump, provide, etc. a non-electricity resources such as water, gas, etc.

In a scenario where such information is not directly available from the utility grid (or other third part), a predictive controller can be configured to generate estimates of the MOER or carbon:energy or carbon:power ratio itself, as illustrated steps3104-3108of process3100. At step3104, data relating to available power sources on the energy grid is collected, i.e., identifying the different energy sources and general information on production of the energy sources serving the energy grid. This information is typically available, even where detailed estimates of carbon emissions or real-time MOER are not shared by utility companies. Step3104can include collect this data and building a model of the various sources of energy on the utility gird. Step3106include obtaining weather and time-of-day data (e.g., what will the weather by a different times of day over a prediction horizon). At step3108, the data from steps3104and3106are used to estimate a time-varying value of carbon emissions per unit energy or power (e.g., average, MOER) received from the energy grid. Step3106can include executing a modeling approach which simulates the energy grid based on the best available information to generate an estimate of the carbon:power or carbon:energy ratio or MOER and predictions thereof over a prediction horizon. In some embodiments, a stochastic optimization process is implemented where a plurality of scenarios comprising different time-series values of the MOER are generated and then used to optimize a total objective across all of the plurality of scenarios, for example as described for utility rates in U.S. patent application Ser. No. 16/115,290, filed Mar. 14, 2019, the entire disclosure of which is incorporated by reference here.

At step3110, an objective function is generated that calculates total carbon emissions, total marginal carbon emissions, or an effective carbon-to-consumed-power ratio over a prediction horizon based on predicted building loads. The predictive building loads can be modeled as a function of building setpoints, for example building temperature setpoints, and other building-related variables (indoor air temperature, outdoor air temperature, etc.), for example using a system identification and grey-box modeling approach as described in U.S. patent application Ser. No. 16/418,715, file May 21, 2019, the entire disclosure of which is incorporated by reference herein. As another example, step3110can include adapting the objective functions used in U.S. application Ser. No. 14/717,593, filed May 20, 2015, U.S. application Ser. No. 16/115,290, filed Aug. 28, 2018, or Ser. No. 15/199,910, filed Jun. 30, 2016, all incorporated by reference herein, by replacing variables indicating utility rates with the time-varying MOER, time-varying value of the carbon:energy or carbon:power ratio. The objective function can include multiplying the carbon:energy ratio by a predicted energy consumption or target energy consumption of building equipment to calculate a total emissions value. The objective function may include a term accounting for off-site emissions, for example ∫t=1t=TMOER(t)*p(t) where MOER(t) is the marginal operating emissions rate at time t and p(t) is energy obtained from the grid at time t. The objective function may also include a term accounting for on-site emissions, for example Σk∫t=1t=Trk(t)*Fk(t) where the index k indicates different subplants, rk(t) is the rate of carbon emissions per unit fuel consumption for subplant k at time t and Fk(t) is the amount of fuel consumed by subplant k at time t.

At step3112, time-varying setpoints for the building are generate which optimize the objective function subject to one or more constraints. For example, a temperature setpoint for each time step over an optimization horizon may be generated at step3112. As another example, energy consumption targets for building equipment may be generated at step3112. Various details of such embodiments are provided in the applications cited above and incorporated by reference herein. Optimizing the objective function can include executing a gradient descent or other minimization process that seeks to achieve the minimum possible total carbon emissions while satisfy the one or more constraints (e.g., constraints ensuring occupant comfort, etc.).

At step3114, the building equipment is operated in accordance with the optimized setpoints. Because step3112uses the time-varying MOER or carbon:power or carbon:energy ratio as an input, step3114may include time-shifting building equipment to low-carbon periods and away from high-carbon-emissions periods. For example, a building can be pre-cooled or pre-heated during a low-carbon period (e.g., cooled below a preferred temperature setpoint, heated above a preferred temperature setpoint) to reduce or eliminate operating of cooling equipment (chillers, etc.) during high-carbon periods. Process3100can thereby reduce carbon emissions associated with energy consumption of a building. In other embodiments, process3100is implemented as a planning tool and used to generate reports, analytics, projected carbon savings, projected costs savings, recommendations, etc. resulting from implementing the optimization strategy of process3100, as an alternative to or in addition to controlling the building equipment as shown in the example ofFIG.15.

Referring now toFIG.17, a flowchart of a process3200for optimizing operation of building equipment while internalizing costs of carbon emissions is shown, according to some embodiments. Process3200can be executed by the same variety of controllers/processors/etc. as process3100described above, in various embodiments.

At step3202, pricing for carbon offsets or carbon credits is obtained. Carbon offsets refers to markets for carbon sequestration and carbon capture services, for example reforestation or non-deforestation services, whereby a polluter can pay a third party to conduct activities which remove carbon from the atmospheres. Technologies or entities are said to be carbon neutral or net-zero carbon emitters when carbon offsets fully cover the technology's or entity's emissions (e.g., tons of CO2emitted=tons of CO2equivalent sequestered). Carbon credits refer to regulatory markets, active in some jurisdictions, in which companies cannot generate emissions beyond an amount defined by freely-transferable carbon credits which are traded in a marketplace. In both cases, a unit of carbon emissions (e.g., ton of CO2) can be associated with an economic cost of offsetting or obtaining regulator permission for that emission.

Step3202can include providing interoperability between digital marketplaces for carbon offsets or credits and a predictive controller for building equipment, for example via one or more APIs and connection over the internet. Step3202may include monitoring pricing for carbon offsets or credits and building one or more models to predict future prices. In other embodiments, step3202includes obtaining data indicating a price that a building owner pre-paid or contracted to pay for carbon offsets or credits.

At step3204, one or more time-varying indicators of carbon emissions per unit energy or power consumed by a building (e.g., MOER, rate of emissions for local fuel consumption) are obtained, for example as described with reference to steps3101-3108ofFIG.15. For example, an effective MOER can be calculated which can account for MOER of energy obtained from a utility grid and contributions of green energy available locally.

At step3206, time-varying utility rates for energy or power from a utility grid is obtained. For example, utilities typically broadcast a real-time energy rate to customers, and sometimes provide the utility rate for an amount of time ahead (e.g., a few hours into the future). Step3206can also include predicting utility rates, for example as described in U.S. patent application Ser. No. 14/717,593, filed May 20, 2015, incorporated by reference herein.

At step3208, an objective function that calculates a total cost of purchasing energy and purchasing carbon offsets or carbon credits to match carbon emissions associated with generation of the energy is generated. The objective function can include a first term representing the total cost of purchasing energy, for example Σi=1i=Hri*pi, where riis a utility rate at time step i, piis energy (or power) consumption at time step i and H indicates the duration of an optimization horizon. The objective function can also include a second term representing the cost of carbon offsets or credits, for example, Σi=1i=HOi*βi*pi, where βirepresents carbon-emissions-per-unit-energy (e.g., MOER, average emissions per unit energy) at time step i and Oirepresents the price of either offsetting and/or purchasing a credit for a unit of carbon emission at time step i. The objective function can sum or otherwise combine the first term and the second term to obtain a total cost of energy for operation of a building including internalized costs of carbon emissions.

In other embodiments, instead of using an actual price Oiof offsetting emissions, a user-selectable weighting factor λiis used to allow a user to tune how process3200balances trade-offs between energy costs and carbon emissions. The weighting factor can be constant or time-varying (as indicated by the subscript i), for example so that a user can set a low preference for reducing carbon emissions during some times of day and a higher preference for reducing emissions during other times of day, for example. In such examples, the objective function can be formulated as J=Σi=1i=Hpi*(ri+λiβi). User selection of a preferred trade-off between cost reductions and emissions reductions is discussed further with reference toFIGS.20-21below.

At step3210, the objective function is optimized to generate setpoints for building equipment (e.g., indoor air temperature setpoints, battery charge/discharge setpoints, various other setpoints/controls decisions described herein) that minimize the total value represented by the objective function subject to one or more constraints (e.g., min J). The constraints and optimization process can be implemented in various ways as described elsewhere herein with reference to other examples. To provide another example, the optimization process may be an adapted version of the processes described in U.S. patent application Ser. No. 17/208,869, filed Mar. 22, 2021, the entire disclosure of which is incorporated by reference herein. At step3214, the building equipment is operated in accordance with the generated setpoints in order to actualize the goal of minimizing the cost of operating the building equipment while internalizing the costs associated with carbon emissions.

At step3216, carbon offsets or credits equaling emissions resulting from the operation of the building equipment can be automatically obtained, for example by a building management system. The entire process of achieving carbon neutrality and/or obtaining regulatory permission to emit a certain level of carbon dioxide is thus provided as an integrated solution. Process3200can thereby dynamically adjust for trade-offs between costs of purchasing energy and internalized costs of carbon emissions while minimizing overall costs and serving the needs of a building or campus.

Referring now toFIG.18, a flowchart of another process (shown as process3300) for predictive control that accounts for carbon emissions is shown, according to an example embodiment. In particular, process3300accounts for carbon emissions by defining a carbon emissions constraint that prevents or penalizes carbon emissions exceeding a predefined level. Process3300can be executed by the various controllers, mentioned above with reference to process3200and process3100or in the references incorporated by reference herein according to various embodiments.

At step3302, an objective function that calculates a cost of operating building equipment over a time horizon based on predicted building loads in generated. The objective function may be formulated as discussed with reference toFIG.17, or as used in U.S. application Ser. No. 14/717,593, filed May 20, 2015, U.S. application Ser. No. 16/115,290, filed Aug. 28, 2018, or Ser. No. 15/199,910, filed Jun. 30, 2016, for example.

At step3304, one or more time-varying indicators of carbon emissions per unit energy or power consumed is obtained, for example a marginal operating emissions rate and/or a rate of carbon emissions per unit fuel (e.g., per kW of natural gas) consumed locally at a facility. For example, step3304may be executed according to the examples of steps3101-3108of process3100.

At step3306, a carbon emissions constraint is defined. The carbon emissions constraint may be defined as an inequality constraints that requires predicted carbon emissions to be less than a predefined level. The predefined level can be defined based on a government regulation, a level defined by an amount of carbon offsets purchased by a company, a level defined by an amount of carbon credits purchased, and amount input by a user, etc. The carbon emissions constraint can be defined as a hard constraints which prevents all solutions to the optimization problem where emissions exceed the predefined level, or as a soft constraint that adds a penalty to the objective function for any excess emissions. In one example, the carbon emissions constraint is formulated as Mgrid+Mlocal≤Mthreshold, where Mgridis an estimated amount of carbon emissions associated with energy obtained from a utility grid (e.g., formulated as Mgrid=∫t=1t=TMOER(t)*p(t) where MOER(t) is the marginal operating emissions rate at time t and p(t) is energy obtained from the grid at time t), Mlocalis an estimated amount of carbon emitted locally from a facility (e.g., formulated as Σk∫t=1t=Tρk(t)*Fk(t) where the index k indicates different subplants, ρk(t) is the rate of carbon emissions per unit fuel consumption for subplant k at time t and Fk(t) is the amount of fuel consumption by subplant k at time t, and Mthresholdis a target maximum amount of carbon emissions. The fuel consumption Fk(t) may include an amount of consumption at time t of natural gas, gasoline, propane, butane, oil products, or other fuels that produce carbon emissions when consumed.

At step3308, the objective function is optimized subject to the carbon emissions constraint. The carbon emissions constraint can ensure that the solution to the optimization problem (e.g., a result of minimizing a value of the objective function) achieves less than the predefined (maximum allowable) level of carbon emissions, in embodiments where the constraint is a hard constraint, or disincentives exceeding the predefined level in embodiments where the constraint is a soft constraint. At step3310, the building equipment is operated using results of the optimization.

Referring now toFIG.19, yet another process for predictive control incorporating carbon emissions considerations is shown, according to some embodiments. In particular,FIG.19shows a flowchart of a process3400which allows a user to adjust weights to indicate relative preferences for reducing emissions, saving costs, and improving occupant comfort. Process3400can be executed by the processors, controllers, etc. mentioned elsewhere herein, in various embodiments.

At step3402, one or more indications of time-varying carbon emissions per unit energy or power (e.g., MOER, emissions rate per unit of locally-consumed fuels) are obtained, for example as described above with reference to steps3101-3108. At step3404, time-varying utility rates for energy obtained from a utility grid are obtained, for example as described with reference to step3206.

At step3406, a model predicting occupant comfort based on building conditions is obtained, for example as described in in U.S. patent application Ser. No. 16/943,955, filed Jul. 30, 2020 and incorporated by reference herein, where occupant comfort is quantified based on predicted occupant overrides of temperature setpoints. As another example, occupant comfort may be based on predicted mean vote calculations. Various models for quantifying occupant comfort are possible.

At step3408, an objective function is generated using the inputs from steps3402,3404, and3406. The objective function can include a weighted sum of a carbon emissions term, a utility costs term, a revenue term (e.g., accounting for revenue associated with participating in an incentive program such as frequency response or demand response as described elsewhere herein) and an occupant cost term, reflecting a sum or integral over a prediction horizon. The carbon emissions term may include a sum of on-site and off-site carbon emissions. For example, the objective function can be formulated as J=∫t=0Tλ*M(t)+α*UtilityCosts(t)+μ*Revenue(t)+ξ*Discomfort(t) dt, for example, where α, μ, λ, ξ are weighting and scaling factors, for example where M(t)=Mgrid(t)+Mlocal(t)=MOER(t)*p(t)+ρ(t)*F(t). As another example, the objective function can be formulated as J=Σt=0T(λ*MOERt+α *re,t)*p(t)+*(λ*ρt+α *rf,t)*F(t)+ξ*Discomfortt, where MOERtis the marginal operating emissions rate at time t, re,tis the price per unit electricity purchased from the grid at time t (e.g., $/kWh), and p (t) is the amount of electricity obtained from the energy grid at time t, ρtis the rate of local carbon emissions per unit fuel consumption (e.g., lb/kWh), rf,tis the price per unit of fuel consumed from a utility at time t (e.g., $/kWh), and F(t) is the amount of fuel (e.g., expressed in kWh) obtained from a utility and consumed at time t.

At step3410, user input is received, for example via a graphical user interface presented on user computing device (e.g., smartphone, tablet, laptop, desktop computer, etc.). The user input indicates an adjustment to the weights of the weighted sum (e.g., α, β, γ) to indicate a user relative preference for reduction emissions, saving costs, and/or improving comfort. For example, increasing α while decrease β in the example above will cause the process3400to prefer reducing emissions over saving costs, and vice versa. As another example, increase γ while decreasing α will cause process3400to prefer improving occupant comfort over reducing emissions, and vice versa. A user interface can be provided with slider bars, numerical inputs, etc. to allow a user to visualize the relative selection and to understand the adjustments. In some embodiments, a graphical interface showing predicted outcomes for give adjustments is shown to allow a user to compare options and effects of changing the weights.

At step3412, the objective function (with the user-selected weights of step3410) is optimized to generate setpoints for building equipment that minimize a value of the objective function (e.g., of the weighted sum) subject to one or more constraints. The minimization approach and constraints can be implemented as described elsewhere herein, and can provide for active setpoint management of a building or buildings. Any of the various settings, setpoints, load values, control decisions, resource allocations, charge/discharge rates, etc. described herein can be optimized by minimization of the objective function in various embodiments. At step3414, the building equipment is operated in accordance with the generated setpoints to achieve the user's desired balance of emissions, cost, and occupant comfort.

Referring now toFIG.20, a flowchart of a process3500for controlling building equipment to achieve a target point on a cost-vs-carbon curve is shown, according to some embodiments. The process3500can be executed by the processors, controllers, etc. mentioned elsewhere herein, in various embodiments.FIG.21is also referred to here to facilitate explanation of process3500, and shows example cost-vs-carbon curves, according to some embodiments.

At step3502, data relating to carbon emissions of consumed power at a plurality of times in a training period is collected, while at step3504data is collected relating to costs of consuming the power at the times in the training period. For example, steps3502and3504can combine to amount to collecting a dataset of carbon emissions and cost pairs, with each pair corresponding to a historical point in time (or small segment in time). The carbon emissions data can capture both off-site emissions (e.g., associated grid power plants) and on-site emissions (e.g., associated with on-site burning of fuels for heat or electricity generation). In some embodiments, steps3502and3504can include performing an experiment to generate suitable data, for example by controlling building equipment across the selectable range of user preferences in order to generate data reflecting the options available to a user.

At step3506, a cost-vs-carbon curve is generated based on the collected data from steps3502and3504. For example, a curve can be fit to the data using regression modeling or some suitable fitting approach. The curve take on various shapes in various scenarios dependent on the collected data, for example as shown inFIG.21.

FIG.21shows cost-vs-carbon curves for different building sizes and different equipment availability, in particular different battery sizes, in particular a first graph3550, a second graph3552, and a third graph3554. The first graph3550, second graph3552, and third graph3554each has cost savings on the y-axis (with greater values indicating more savings/less cost) and carbon savings on the x-axis (with greater values indicating more savings/less emissions). For example, the first graph3550and the third graph3554show data for the same sized space but supplied with a much larger battery in the scenario of third graph3554, which is shown as unlocking substantially more cost savings and emissions savings. The points shown on the graphs3550,3552,3554are coded to show that the points correspond to values of a user-selectable weighting factor (e.g., values of λ in an objective function J=Σi=1i=Hpi*(ri+λβi)).

As shown in the first graph3550, the second graph3552, and the third graph3554, cost savings and carbon savings may have an exponential relationship, such that cost savings are relative constant up to a certain amount of carbon savings, and then decrease quickly (exponentially) beyond that point. A graph such as the first graph3550, second graph3552, and third graph3554, for a particular building, group of buildings, etc. can be automatically generated at step3508and displayed via a graphical user interface to allow a user to directly view and assess the relationship between cost savings and carbon savings for the particular building or group of buildings managed by the user.

At step3508, a user interface is generated that allows a user to select a preferred point along the cost-vs-carbon curve generated in step3506. For example, a graphical user interface may show the cost-vs-carbon curve (e.g., a graph as inFIG.21) and allow the user to select a point on the curve by touching or clicking on the preferred point. Selecting a point on the cost-vs-carbon curve can amount to or result in selection of a value of a weighting factor used in an objective function, for example a value of λ in an objective function J=Σi=1i=Hpi*(ri+λβi)). The user can thus directly select a desired tradeoff between cost and carbon emissions while seeing the actual relationship between the variables for a particular building, plant, or campus, and without needing to understand or manipulate the objective function itself, other optimization logic, software code, etc.

At step3510, setpoints for building equipment are generated which are predicted to achieve the preferred, selected point along the cost-vs-carbon curve. Step3510can be executed by optimizing an objective function with a weighting factor determined based on step3508. In other embodiments, the selected point on the cost-vs-carbon curve can be treated as a target for an optimization, such that an error function is minimized to reduce or eliminate predicted deviations from the target (e.g., deviations of an actual or predict cost and emissions from the selected target cost and emissions). Decision variables of the optimization may include temperature setpoints for the building, equipment on/off decisions, variables relating to components of local energy systems (e.g., batteries, generators, storages, renewable sources, etc.), and various other variables in various implementations. The optimization can be performed subject to one or more constraints, for example temperature constraints on predicted indoor air temperature for the building.

At step3512, building equipment is controlled using the setpoints, for example a time-series of temperature setpoints output from step3510. The building equipment is thereby operated to achieve the user-selected predicted point on the cost-vs-carbon curve.

Referring now toFIG.22, a flowchart of a process3600for controlling building equipment to achieve a target point on a comfort-vs-carbon curve is shown, according to some embodiments. The process3600can be executed by the processors, controllers, etc. mentioned elsewhere herein, in various embodiments.

At step3602, data relating to carbon emissions of consumed power (e.g., including on-site and off-site emissions) at a plurality of times in a training period is collected, while at step3604data is collected relating to occupant comfort at the times in the training period. Occupant comfort data can be sourced from surveys, polling, occupant overrides of building setpoints, estimates based on measured building conditions (e.g., temperature, humidity, etc.). For example, steps3602and3604can combine to amount to collecting a dataset of carbon emissions and comfort pairs, with each pair corresponding to a historical point in time (or small segment in time).

At step3606, a comfort-vs-carbon curve is generated based on the collected data from steps3502and3504. For example, a curve can be fit to the data using regression modeling or some suitable fitting approach. The curve take on various shapes in various scenarios dependent on the collected data.

At step3608, a user interface is generate that allows a user to select a preferred point along the comfort-vs-carbon curve generated in step3506. For example, a graphical user interface may show the comfort-vs-carbon curve and allow the user to select a point on the curve by touching or clicking on the preferred point. The user can thus directly select a desired tradeoff between occupant comfort and carbon emissions while seeing the actual relationship between the variables for a particular building, plant, or campus.

At step3510, setpoints for building equipment are generated which are predicted to achieve the preferred, selected point along the comfort-vs-carbon curve. The selected point can be treated as a target for an optimization, such that an error function is minimized to reduce or eliminate predicted deviations from the target. Decision variables of the optimization may include temperature setpoints for the building, equipment on/off decisions, variables relating to components of a local energy system (e.g., batteries, storages, generators, renewable sources, etc.), and various other variables in various implementations. The optimization can be performed subject to one or more constraints, for example cost constraints on total cost of operating the building equipment.

At step3512, building equipment is controlled using the setpoints. The building equipment is thereby operated to achieve the user-selected predicted point on the comfort-vs-carbon curve.

Automated Asset Recommendations for Carbon Emissions Reductions

Various passages above describe various assets (e.g., units of equipment) that can be added to a building system to reduce operational costs and carbon emissions, and, in some scenarios achieve carbon neutrality for a building. However, a technical challenge exists relating to selecting the appropriate assets or appropriate size of an asset needed to optimally operational goals and meet carbon reduction targets. For example, adding oversized equipment may actually increase a carbon footprint, whereas adding insufficient assets will not allow goals to be met. Accordingly, a technical solution for assessing and predicting building assets needs is a highly desirable technology.

Referring now toFIG.23, a process3700for automatically recommending one or more building assets to add to a building to optimally achieve operational goals and carbon reduction targets is shown, according to some embodiments. The process3700can be executed by one or more computing elements of the building energy optimization system described in U.S. patent application Ser. No. 16/518,314, filed Jul. 22, 2019, the entire disclosure of which is incorporated by reference herein, for example.

At step3702, building data indicating energy loads of a building (e.g., electrical demand) is collected. At step3704, data indicating carbon emission levels of grid energy (e.g., time-varying carbon:power ratio as described above) and carbon emissions of on-site fuel consumption (e.g., emission rates for different equipment models and/or subplants) is collected. At step3706, climate data indicating available renewable power is collected (e.g., average number of sunny days, length of days, solar intensity, average wind speed, average number of windy days, etc.) is collected for the location of the building. At step3708, data relating to available space for new energy assets is collected, i.e., physical limits on where a new asset could be positioned (indoor or outdoor, rooftop or ground level, etc.) or how big a new asset could be (roof size, volume of available space, area of available space, etc. in order to fit with an existing building and pre-existing building equipment.

At step3710, an objective function is generated that characterizes a cost of operating the building over a future time period and has one or more decision variables relating to one or more new energy assets that could be added to the building system. For example, the objective function can include binary variables indicating whether or not a particular type of new asset will be added (e.g., add or do not add a chiller700having an integrated battery and/or fuel cell, add or do not add a renewable energy source such as a photovoltaic system, add or do not add a heat recovery chiller, add or do not add thermal energy storage, add or do not add a heat pump, add or do not add a geothermal ground loop, etc.) and variables that can indicate available sizes of such assets that are available from an equipment supplier (e.g., different chillers indicated by capacity) or different numbers of such assets (e.g., two, three, four, etc. units of a particular equipment model). The objective function can also account for initial investment and start-up costs relating to purchase and installation of new assets. The objective function may also include terms relating to carbon emissions, carbon offsets, carbon credits, occupant comfort, etc. as described in the various examples above.

At step3712, one or more constraints are defined, for example based on the data collected in any of steps3702-3708. For example, a physical size constraint can be defined based on the data relating to available space for new energy assets and stored information relating to the size and space requirements of the potential new energy assets, to ensure that only assets that will fit at the building will be considered. As another example, a carbon emissions constraint can be defined as in process3300. As another example, constraints can be used to characterize the expected power outputs of renewable energy assets (e.g., photovoltaic cells of a renewable energy system) based on the collected climate data and the data relating to available space/positioning for new assets. Various such considerations can be defined as constraints on an optimization process.

At step3714, the objective function is optimized subject to the constraints to generate optimal values for the decisions variables (e.g., values that minimize the objective function subject to the constraints). The decision variables indicated recommended assets to add and recommended sizes or quantities of those assets. The optimization may include any of the various considerations, approaches, processes, etc. described in U.S. patent application Ser. No. 16/518,314, filed Jul. 22, 2019, the entire disclosure of which is incorporated by reference herein.

At step3715, a display is generated that shows the recommendation output from step3714, the required initial investment, a time-to-breakeven for the investment, predicted resulting carbon emissions savings, predicted resulting carbon-to-power ratio, and any other metrics that may be relevant to a decision maker. In some embodiments, the recommended assets are automatically ordered and installation technicians are automatically scheduled to complete the installation. The process can then continue by controlling the building equipment include the new assets to optimally serve the building according to various strategies described herein.

Enterprise-Wide Carbon Emissions Tracking and Mitigation

Referring now toFIG.24, a flowchart of a process3800for enterprise-wide carbon emissions tracking and mitigation is shown, according to an example embodiment. Process3800can be executed by processing and memory circuitry in communication with various data sources, according to some embodiments. For example, process3800can be executed by processing circuitry executing a software platform that supports a building management system.

At step3802, data from an enterprise-wide building management system is collected. The data may indicate energy consumption of the enterprise's buildings and the source of the consumed energy. At step3804, carbon emissions associated with the building energy consumption is tracked, for example at the building level and at the enterprise level. Calculating carbon emissions can be performed using the concepts described with reference to steps3101-3108of process3100, for example, and can include on-site emissions from the enterprise's buildings and off-site emissions associated with grid energy or other resources used by the enterprise.

At step3806, data from vehicle-based data collectors is obtained. The vehicle-based data collectors can harvest data relating to operation, mileage, fuel consumption, etc. of an enterprise's vehicle fleet, including company cars, delivery trucks, etc. At step3808, carbon emissions associated with operating of the enterprise's vehicle fleet is tracked, for example on an overall enterprise level and to see carbon emissions for different regions, business units, individual employees, etc.

At step3810, data is collected from an expense reporting system or other enterprise software platform that collects data relating to employee travel and/or company orders and purchases. For example, a travel agency portal used to book employee travel could be used in some embodiments. The data collected in step3810indicates carbon emissions generated by employee travel (e.g., airplane flights, travel in third-party vehicles such as taxis, etc.) and other activities (e.g., delivery of ordered goods, etc.). The data can also include carbon emissions associated with manufacturing of goods purchase by the enterprise (e.g., production of steel or other raw materials) or services provided to the enterprise (e.g., emission tied to energy consumption of data center services provided to the enterprise). At step3812, the carbon footprint associated with business travel and other operations reflected in the data collected in step3810is calculated ant tracked.

At step3814, a unified dashboard showing the enterprise-wide carbon footprint is generated. The dashboard can display overall carbon emissions data, identify the contributing sources, and identify high-emitting buildings, business units, departments, regions, employees, for example. The unified dashboard can be provided via a graphical user interface.

At step3816, recommendations are automatically generated for carbon footprint reduction. In some embodiments, step3816includes executed process3700. In some embodiments, step3816comprises automatically adjusting building setpoints according to one of the control processes described above. In some embodiments, the recommendations include reducing business travel, purchasing electric vehicles for the company fleet, and investigating significant emissions by a particular employees. Various outcomes at step3816are possible.

At step3818, a carbon sequestration process is automatically initiated to match the enterprise-wide carbon footprint, thereby achieving enterprise-wide net-zero emissions. The carbon sequestration process can include planting trees or other plants, for example. As another example, the carbon sequestration process includes operating a sequestration device configured to extract carbon from the atmosphere and store the carbon in a solid form. As another example, the carbon sequestration process includes purchasing carbon offsets from a third-party provider. Process3800thereby facilitates identification of carbon emission levels, management of carbon emissions, and helps facilitate achieving carbon neutrality.

Battery Control Using Marginal Operating Emissions Rate

Referring now toFIG.25, a flowchart of a process4200for controlling a battery using a marginal operating emissions rate is shown, according to some embodiments. The process4200can be executed by various controllers, systems, etc. described herein in various embodiments. Although the embodiment of process4200shown inFIG.25refers to a battery, it should be understood that the battery may include multiple battery cells and that the process4200could be adapted for use with other types of energy storage.

At step4202, a current marginal operating emissions rate (MOER) is obtained. In some embodiments, steps4202includes receiving the MOER from the utility grid or from a third-party service provider (e.g., via the Internet). In some embodiments, step4202includes calculating or estimating the MOER based on weather data, historical MOER values, etc.

At step4204, a determination is made as to whether the current MOER is above a deadband (i.e., greater than a value defining an upper limit of the deadband), below the deadband (i.e., less than a value defining a lower limit of the deadband), or inside the deadband (i.e., greater than the lower limit and less than the upper limit). The deadband can be defined based on historical values of the MOER in particular scenario, for example such at the lower limit of the deadband is at 20% of the maximum historical MOER and the upper limit of the deadband is at 80% of the maximum historical MOER (assuming a scenario where the MOER drops below 20% of its maximum value). The deadband can be defined based on frequency, such that the MOER is below the deadband 20% (or some other percentage) of the time on average and above the deadband 20% (or some other percentage) of the time on average. Thus, the deadband can be appropriately defined based on actual MOER values. The determination at step4204can be executed by comparing the numerical value of the MOER with the numerical values that define the deadband.

If a determination is made in step4204that the current MOER is less than the deadband, the process4200proceeds to step4206where the battery is charged. Because a low MOER indicates that low marginal carbon emissions will be associated with energy obtained and charged into the battery, step4206corresponds to a low-carbon charging of the battery. Step4206can continue until the battery is fully charged or until the MOER changes and process4200is re-run.

If a determination is made in step4204that the current MOER is greater than the deadband, the process4200proceeds to step4208where the battery is discharged. Because a high MOER indicates that relative-high marginal carbon emissions will be associated with any energy obtained from a grid at that time, discharging the battery during such periods reduces the need to obtain power during such periods, thereby reducing emissions. Low-carbon energy can thus be time-shifted by storing it in step4206when the MOER is below the deadband and discharging it in step4208when the MOER is above the deadband. Step4208can continue until the battery is fully discharged or until the MOER changes and process4200is re-run.

If a determination is made in step4204that the current MOER is inside the deadband, the process4200proceeds to step4210. In the embodiment shown, the battery is neither charged nor discharged in step4210, and a substantially constant amount of energy is maintained in the battery. The amount of energy stored for discharge in higher-MOER periods, while any extra capacity is kept open for charging during lower-MOER periods. In other embodiments, when the current MOER is inside the deadband, a hysteresis-type control is provided where the previous charge or discharge state of the battery is continued for a least a threshold amount of time, for example in order to prevent high-frequency switching between charging/discharging/neither states that can otherwise contributed to battery degradation.

Process4200can thereby provide an efficient, easy-to-implement control solution that achieved emissions savings by controlling a battery based on marginal operating emissions rates.

Demand Allocation Based on Multiple Emissions Rates

Referring now toFIG.26, a block diagram of a system2600is shown, according to some embodiments. The system2600includes a first subsystem2602, a second subsystem2604, and a controller2606. The system2600can be a portion of or implemented in conjunction with the various other system and methods described herein. The first subsystem2602and the second subsystem2604can be separate units of equipment, separate groups of equipment (e.g., subplants), elements of the same unit of equipment, etc.

As shown inFIG.26, the first subsystem2602receives electricity from grid2610, which includes electricity sources (e.g., power plants, etc.) and electricity transmission equipment. The first subsystem2602is configured to produce a resource (shown as “generated resource”) by consuming electricity. That is, the first subsystem2602uses electrical power to produce the resource. The resource may include, for example, any of the resources previously described (e.g., hot thermal energy, cold thermal energy, etc.). In one example, the first subsystem2602is a heat recovery chiller configured to provide heating and cooling (e.g., in the form of hot water and cold water) by consuming electricity. In another example, the first subsystem2602is or includes a resistive heater configured to transform electrical power into heat (e.g., an electric boiler that generates hot water, an electric furnace that generates hot air, a resistive space heater that directly heats a building zone, etc.). The generated resource is hot thermal energy (e.g., hot water, steam, hot air, etc.) in these examples, but could be any other resource depending on the particular type of equipment within the first subsystem2602.

As shown inFIG.26, the system2600is also shown as receiving a fuel. The fuel may be or include any type of substance or material that creates carbon emissions when consumed or combusted. For example, the fuel may be a fossil fuel, natural gas, oil or any oil-based product, gasoline, diesel, coal, ethanol, biofuel, biomass, wood, or any other substance or material which creates carbon emissions when consumed or combusted, or any combination thereof (e.g., mixtures of gasoline and ethanol, natural gas with additives, mixtures of various oil products, etc.). In particular, the second subsystem2604is configured to produce the same generated resource as the first subsystem2602by consuming the fuel received by the second subsystem2604. For example, the second subsystem2604may burn, combust, etc. the fuel and use the released energy as heat to produce hot water, steam, hot air, etc. In some embodiments, the second subsystem2604uses the fuel to generate mechanical or electrical power and uses the mechanical or electrical power to produce the generated resource. Consumption of the fuel by the second subsystem2604results in carbon emissions from the second subsystem2604.

In some examples, the second subsystem2604is a boiler configured to produce hot water. As another example, the second subsystem2604is a furnace configured to produce hot air. As another example, the second subsystem2604is a gas-fired fireplace or other element configured produce heat transferred directly to a building space. In some embodiments, the second subsystem2604includes any type of equipment that consumes the fuel on site (e.g., locally within the building or facility being heated, within a central plant or central energy facility that provides hot thermal energy to one or more buildings, etc.) and produces carbon emissions as a result.

As shownFIG.26, the first subsystem2602and the second subsystem2604are configured to produce the same resource, shown as the generated resource. Production of the generated resource by the combination of the first subsystem2602and the second subsystem2604serves a demand for the generated resource, for example a demand from a building for the generated resource, a demand from a subplant of a central plant for the generated resource, or some other demand for the generated resource. The generated resource can directly serve an end goal (e.g., can be provided to a building to satisfy the building's demand for the generated resource) or can be further processed and used by downstream equipment (e.g., can serve as an intermediate resource produced and consumed within a central energy facility or central plant).

The system2600thereby provides an option to satisfy demand for the generated resource by operating the first subsystem (and thus consuming electricity from the grid2610), by operating the second subsystem2604(and thus consuming the fuel), or some combination thereof. The controller2606is configured to allocate predicted demand for the generated resource between the first subsystem2602and the second subsystem2604, for example by determining, for each time step over an optimization period, a first amount of the generated resource to be produced by the first subsystem2602and a second amount of the generated resource to be produced by the second subsystem2604.

The controller2606is configured to allocate demand between the first subsystem2602and the second subsystem2604based on multiple carbon emissions rates, in particular based on different rates of carbon emissions associated with operating of the first subsystem2602and the second subsystem2604. The first subsystem2602received electricity from grid2610which receives at least a portion of the electricity from carbon-emitting electricity sources (e.g., fuel burning power plants). As detailed above, the rate of carbon emissions associated with the electricity consumed from the grid2610may be characterized based on a marginal operating emissions rate. The controller2606may obtain the marginal operating emissions rate for the electricity received from the grid2610and use the marginal operating emissions rate in allocating demand across the first subsystem and the second subsystem. For example, the controller2606may use the marginal operating emission rate in combination with a model (subplant curve, efficiency factor, etc.) that indicates amounts of electricity required by the first subsystem2602to produce amounts of the generated resource. The controller2606can thereby assign an amount of carbon emissions to a decision variable indicating an amount of the generated resource to be produced by the first subsystem2602.

The controller2606is also configured to account for carbon emissions emitted locally from the second subsystem2604. The second subsystem2604is configure to emit an amount of carbon emissions that can be modeled by the controller2606as a function of the amount of fuel consumed by the second subsystem2604and/or as a function of an amount of the generated resource produced by the second subsystem2604. For example, the amount of carbon emissions by the second subsystem2604can be modelled as a fixed rate multiplied by an amount of the generated resourced produced by the second subsystem. The controller2606can thereby assign an amount of carbon emissions to a decision variable indicating an amount of the generated resource to be produced by the first subsystem2602.

The controller2606can execute an optimization process subject to a constraint that requires a predicted demand for the generated resource to be equal to a portion of the predicted demand allocated to the first subsystem plus a portion of the predicted demand allocated to the second subsystem. The portions allocated to the first subsystem2602and the second subsystem2604may be the decision variables of the optimization process. The optimization process operates to select the allocation that minimizes an objective function that accounts for (1) a cost of purchasing the electricity to be used to produce the portion of the predicted demand for the generated resource allocated to the first subsystem, (2) a penalty for carbon emissions associated with the electricity used to produce the portion of the predicted demand for the generated resource allocated to the first subsystem, (3) a cost of purchasing the fuel to be used to produce the portion of the predicted demand for the generated resource allocated to the second subsystem, and (4) a penalty for carbon emissions resulting from consuming the fuel to produce the portion of the predicted demand for the generated resource allocated to the first subsystem.

While this is one example of an objective function that can be used in the optimization process, it is contemplated that the objective function is not limited to cost optimization and can account for any of a variety of control objectives in addition to cost (e.g., by adding additional terms in the objective function) or in place of cost (e.g., by substituting cost terms with other terms that account for other control objectives). Some examples of other control objectives include carbon emissions as the primary control objective, disease transmission, occupant comfort, equipment maintenance cost, equipment reliability, or any other control objective which may be desirable to optimize in a building. These and other examples of additional control objectives and corresponding objective functions are described in detail in U.S. patent application Ser. No. 17/576,615 filed Jan. 14, 2022, the entire disclosure of which is incorporated by reference herein.

In the embodiments involving predicted demand, the optimization process plans allocations over a future time period. In other examples, the controller2606makes real-time decisions to operate the first subsystem2602and the second subsystem2604based at least in part on real-time emission rates associated with the first subsystem2602and the second subsystem2604.

In one example scenario, the first subsystem2602is an electric water heater that uses electricity to produce hot water and the second subsystem2604is a natural gas water heater that burns natural gas to produce hot water (e.g., integrated into a unified equipment unit, separate subplants). The controller2606operates to allocate demand for hot water between the electric water heater and the natural gas water heater. In many locations and scenarios, the utility costs associated with purchasing natural gas per are lower than the costs of purchasing electricity (e.g., per unit of hot water production). However, in scenarios where the grid includes at least some renewable energy sources or carbon capture technologies, the emissions rate associated with operation of the electric water heater can often be lower than the emissions rate associated with burning natural gas at the second subsystem2604. In such scenarios, the controller2606can operate to determine how and when to use the first subsystem2602and the second subsystem2604to make trade-offs between utility costs and carbon emissions. For example, the controller2606may allocate a higher portion to the first subsystem2602when the grid's marginal operating emissions rate is low (e.g., midday when solar energy is highly available) as compared to when the grid's marginal operating emissions rate is high (e.g., at night), in order to achieve the greatest carbon savings for each increase in electricity costs. Various such examples are possible.

Although the examples above reference carbon emissions, the teachings herein can be adapted for any type of pollution including acid gas, mercury, toxic metals, nickel, arsenic, chromium, sulfur dioxide, NOR, particulate matter, hydrofluorocarbons, etc. for example with rates of carbon emissions discussed above replaced or enhanced by rates of emissions of such other pollutant(s).

Configuration of Exemplary Embodiments