Building management system with electrical energy storage optimization based on benefits and costs of participating in PBDR and IBDR programs

CROSS-REFERENCE TO RELATED PATENT APPLICATIONS

This application claims the benefit of and priority to U.S. Provisional Patent Application No. 62/239,131, U.S. Provisional Patent Application No. 62/239,231, U.S. Provisional Patent Application No. 62/239,233, U.S. Provisional Patent Application No. 62/239,245, U.S. Provisional Patent Application No. 62/239,246, and U.S. Provisional Patent Application No. 62/239,249, each of which has a filing date of Oct. 8, 2015. The entire disclosure of each of these patent applications is incorporated by reference herein.

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 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.) 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. If electrical demand charges are considered, the optimization is even more complicated.

SUMMARY

One implementation of the present disclosure is a building management system. The system includes building equipment configured to consume electrical energy and generate thermal energy for use in satisfying a thermal energy load of a building, thermal energy storage configured to store at least a portion of the thermal energy generated by the building equipment and to discharge the stored thermal energy, electrical energy storage configured to store electrical energy purchased from a utility and to discharge the stored electrical energy, and a controller. The controller is configured to determine, for each time step within a time horizon, an optimal amount of electrical energy stored or discharged by the electrical energy storage by optimizing a value function. The value function includes expected revenue from participating in an incentive-based demand response (IBDR) program and an expected cost of the electrical energy consumed by the building equipment in order to participate in the IBDR program.

In some embodiments, the expected revenue from participating in the IBDR program may include an amount of revenue gained by selling a portion of the stored electrical energy to an energy grid.

In some embodiments, the expected cost of the electrical energy consumed by the building equipment in order to participate in the IBDR program may include a monetary cost of the electrical energy purchased from the utility.

In some embodiments, he value function may include a monetized cost of capacity loss for the electrical energy storage in order to participate in the IBDR program.

In some embodiments, the controller may be configured to estimate the monetized cost of capacity loss for the electrical energy storage as a function of an estimated amount of the electrical energy stored or discharged by the electrical energy storage in order to participate in the IBDR program.

In some embodiments controller may be configured to estimate the monetized cost of capacity loss for the electrical energy storage using a battery capacity loss model.

In some embodiments, the value function may include a penalty cost of equipment degradation in order to participate in the IBDR program.

In some embodiments, the controller may be configured to estimate the penalty cost of equipment degradation as a function of an estimated number of on/off commands provided to the building equipment within the time horizon in order to participate in the IBDR program.

In some embodiments, the value function may include a penalty cost based on an amount by which a predicted output of the building equipment changes between consecutive time steps within the time horizon in order to participate in the IBDR program.

Another implementation of the present disclosure is a method for controlling a building management system. The method includes using building equipment configured to consume electrical energy and generate thermal energy for use in satisfying a thermal energy load of a building. The method further includes storing at least a portion of the thermal energy generated by the building equipment in thermal energy storage and discharging the stored thermal energy from the thermal energy storage. The method further includes storing electrical energy purchased from a utility in electrical energy storage and discharging the stored electrical energy from the electrical energy storage. The method further includes determining, for each time step within a time horizon, an optimal amount of electrical energy stored or discharged by the electrical energy storage by optimizing a value function. The value function includes an expected revenue from participating in an incentive-based demand response (IBDR) program and an expected cost of the electrical energy consumed by the building equipment in order to participate in the IBDR program.

In some embodiments, the expected revenue from participating in the IBDR program may include an amount of revenue gained by selling a portion of the stored electrical energy to an energy grid.

In some embodiments, the expected cost of the electrical energy consumed by the building equipment in order to participate in the IBDR program may include a monetary cost of the electrical energy purchased from the utility.

In some embodiments, the value function may include a monetized cost of capacity loss for the electrical energy storage in order to participate in the IBDR program.

In some embodiments, the method may include estimating the monetized cost of capacity loss for the electrical energy storage as a function of an estimated amount of the electrical energy stored or discharged by the electrical energy storage in order to participate in the IBDR program.

In some embodiments, the method may include estimating the monetized cost of capacity loss for the electrical energy storage using a battery capacity loss model.

In some embodiments, the value function further comprises a penalty cost of equipment degradation in order to participate in the IBDR program.

In some embodiments, the method includes estimating the penalty cost of equipment degradation as a function of an estimated number of on/off commands provided to the building equipment within the time horizon in order to participate in the IBDR program.

In some embodiments, the value function further includes a penalty cost based on an amount by which a predicted output of the building equipment changes between consecutive time steps within the time horizon in order to participate in the IBDR program.

Another implementation of the present disclosure is a controller. The controller includes a processing circuit configured to estimate an expected revenue from participating in an incentive based demand response (IBDR) program, estimate an expected cost of participating in the IBDR program, weigh the expected revenue against the expected cost to determine whether to participate in the IBDR program, generate optimal control signals for electrical energy storage based on a result of the weighing, and operate the electrical energy storage using the optimal control signals.

In some embodiments, the expected revenue from participating in the IBDR program may include an expected amount of revenue gained by selling a portion of electrical energy stored in the electrical energy storage. In some embodiments, the expected cost of participating in the IBDR program includes at least one of an expected cost of electrical energy consumed by building equipment, a penalty cost of equipment degradation, and a monetized cost of capacity loss for the electrical energy storage.

Those skilled in the art will appreciate that the summary is illustrative only and is not intended to be in any way limiting. Other aspects, inventive features, and advantages of the devices and/or processes described herein, as defined solely by the claims, will become apparent in the detailed description set forth herein and taken in conjunction with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

<figref idref="DRAWINGS">FIG. 1</figref> is a drawing of a building equipped with a building management system (BMS) and a HVAC system

<figref idref="DRAWINGS">FIG. 2</figref> is a schematic diagram of a waterside system, shown as a central plant, which may be used to provide resources to the building of <figref idref="DRAWINGS">FIG. 1</figref>, according to an exemplary embodiment.

<figref idref="DRAWINGS">FIG. 3</figref> is a schematic diagram of an airside system which may be used to provide resources to the building of <figref idref="DRAWINGS">FIG. 1</figref>, according to an exemplary embodiment.

<figref idref="DRAWINGS">FIG. 4</figref> is a block diagram illustrating the BMS of <figref idref="DRAWINGS">FIG. 1</figref> in greater detail, according to an exemplary embodiment.

<figref idref="DRAWINGS">FIG. 5</figref> is a block diagram illustrating a central plant system including a central plant controller that may be used to control the central plant of <figref idref="DRAWINGS">FIG. 2</figref>, according to an exemplary embodiment.

<figref idref="DRAWINGS">FIG. 6</figref> is block diagram illustrating the central plant controller of <figref idref="DRAWINGS">FIG. 5</figref> in greater detail, according to an exemplary embodiment.

<figref idref="DRAWINGS">FIG. 7</figref>, a block diagram illustrating a portion of the central plant system of <figref idref="DRAWINGS">FIG. 5</figref> in greater detail, according to an exemplary embodiment.

<figref idref="DRAWINGS">FIG. 8</figref> is a block diagram illustrating a high level optimizer of the central plant controller of <figref idref="DRAWINGS">FIG. 5</figref> in greater detail, according to an exemplary embodiment.

<figref idref="DRAWINGS">FIGS. 9A-9B</figref> are subplant curves illustrating a relationship between the resource consumption of a subplant and the subplant load and which may be used by the high level optimizer of <figref idref="DRAWINGS">FIG. 8</figref> to optimize the performance of the central plant, according to an exemplary embodiment.

<figref idref="DRAWINGS">FIG. 10</figref> is a non-convex and nonlinear subplant curve that may be generated from experimental data or by combining equipment curves for individual devices of the central plant, according to an exemplary embodiment.

<figref idref="DRAWINGS">FIG. 11</figref> is a linearized subplant curve that may be generated from the subplant curve of <figref idref="DRAWINGS">FIG. 10</figref> by converting the non-convex and nonlinear subplant curve into piecewise linear segments, according to an exemplary embodiment.

<figref idref="DRAWINGS">FIG. 12</figref> is a graph illustrating a set of subplant curves that may be generated by the high level optimizer of <figref idref="DRAWINGS">FIG. 8</figref> based on experimental data from a low level optimizer for multiple different environmental conditions, according to an exemplary embodiment.

<figref idref="DRAWINGS">FIG. 13</figref> is a block diagram of a planning system that incorporates the high level optimizer of <figref idref="DRAWINGS">FIG. 8</figref>, according to an exemplary embodiment.

<figref idref="DRAWINGS">FIG. 14</figref> is a drawing illustrating the operation of the planning system of <figref idref="DRAWINGS">FIG. 13</figref>, according to an exemplary embodiment.

<figref idref="DRAWINGS">FIG. 15</figref> is a block diagram of an electrical energy storage system that uses battery storage to perform both ramp rate control and frequency regulation, according to an exemplary embodiment.

<figref idref="DRAWINGS">FIG. 16</figref> is a drawing of the electrical energy storage system of <figref idref="DRAWINGS">FIG. 15</figref>, according to an exemplary embodiment.

<figref idref="DRAWINGS">FIG. 17</figref> is a graph illustrating a reactive ramp rate control technique which can be used by the electrical energy storage system of <figref idref="DRAWINGS">FIG. 15</figref>, according to an exemplary embodiment.

<figref idref="DRAWINGS">FIG. 18</figref> is a graph illustrating a preemptive ramp rate control technique which can be used by the electrical energy storage system of <figref idref="DRAWINGS">FIG. 15</figref>, according to an exemplary embodiment.

<figref idref="DRAWINGS">FIG. 19</figref> is a block diagram of a frequency regulation and ramp rate controller which can be used to monitor and control the electrical energy storage system of <figref idref="DRAWINGS">FIG. 15</figref>, according to an exemplary embodiment.

<figref idref="DRAWINGS">FIG. 20</figref> is a block diagram of a frequency response optimization system, according to an exemplary embodiment.

<figref idref="DRAWINGS">FIG. 21</figref> is a graph of a regulation signal which may be provided to the frequency response optimization system of <figref idref="DRAWINGS">FIG. 20</figref> and a frequency response signal which may be generated by frequency response optimization system of <figref idref="DRAWINGS">FIG. 20</figref>, according to an exemplary embodiment.

<figref idref="DRAWINGS">FIG. 22</figref> is a block diagram of a frequency response controller which can be used to monitor and control the frequency response optimization system of <figref idref="DRAWINGS">FIG. 20</figref>, according to an exemplary embodiment.

<figref idref="DRAWINGS">FIG. 23</figref> is a block diagram of a high level controller which can be used in the frequency response optimization system of <figref idref="DRAWINGS">FIG. 20</figref>, according to an exemplary embodiment.

<figref idref="DRAWINGS">FIG. 24</figref> is a block diagram of a low level controller which can be used in the frequency response optimization system of <figref idref="DRAWINGS">FIG. 20</figref>, according to an exemplary embodiment.

<figref idref="DRAWINGS">FIG. 25</figref> is a block diagram of a frequency response control system, according to an exemplary embodiment.

<figref idref="DRAWINGS">FIG. 26</figref> is a block diagram illustrating data flow into a data fusion module of the frequency response control system of <figref idref="DRAWINGS">FIG. 25</figref>, according to an exemplary embodiment.

<figref idref="DRAWINGS">FIG. 27</figref> is a block diagram illustrating a database schema which can be used in the frequency response control system of <figref idref="DRAWINGS">FIG. 25</figref>, according to an exemplary embodiment.

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.

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 to <figref idref="DRAWINGS">FIGS. 1-4</figref>, an exemplary building management system (BMS) and HVAC system in which the systems and methods of the present invention may be implemented are shown, according to an exemplary embodiment. Referring particularly to <figref idref="DRAWINGS">FIG. 1</figref>, a perspective view of a building <b>10</b> is shown. Building <b>10</b> is served by a BMS. A BMS is, in general, a system of devices configured to control, monitor, and manage equipment in or around a building or building area. A BMS can include, for example, a HVAC system, a security system, a lighting system, a fire alerting system, any other system that is capable of managing building functions or devices, or any combination thereof.

The BMS that serves building <b>10</b> includes a HVAC system <b>100</b>. HVAC system <b>100</b> may include a plurality of HVAC devices (e.g., heaters, chillers, air handling units, pumps, fans, thermal energy storage, etc.) configured to provide heating, cooling, ventilation, or other services for building <b>10</b>. For example, HVAC system <b>100</b> is shown to include a waterside system <b>120</b> and an airside system <b>130</b>. Waterside system <b>120</b> may provide a heated or chilled fluid to an air handling unit of airside system <b>130</b>. Airside system <b>130</b> may use the heated or chilled fluid to heat or cool an airflow provided to building <b>10</b>. An exemplary waterside system and airside system which may be used in HVAC system <b>100</b> are described in greater detail with reference to <figref idref="DRAWINGS">FIGS. 2-3</figref>.

HVAC system <b>100</b> is shown to include a chiller <b>102</b>, a boiler <b>104</b>, and a rooftop air handling unit (AHU) <b>106</b>. Waterside system <b>120</b> may use boiler <b>104</b> and chiller <b>102</b> to heat or cool a working fluid (e.g., water, glycol, etc.) and may circulate the working fluid to AHU <b>106</b>. In various embodiments, the HVAC devices of waterside system <b>120</b> may be located in or around building <b>10</b> (as shown in <figref idref="DRAWINGS">FIG. 1</figref>) or at an offsite location such as a central plant (e.g., a chiller plant, a steam plant, a heat plant, etc.). The working fluid may be heated in boiler <b>104</b> or cooled in chiller <b>102</b>, depending on whether heating or cooling is required in building <b>10</b>. Boiler <b>104</b> may add heat to the circulated fluid, for example, by burning a combustible material (e.g., natural gas) or using an electric heating element. Chiller <b>102</b> may place the circulated fluid in a heat exchange relationship with another fluid (e.g., a refrigerant) in a heat exchanger (e.g., an evaporator) to absorb heat from the circulated fluid. The working fluid from chiller <b>102</b> and/or boiler <b>104</b> may be transported to AHU <b>106</b> via piping <b>108</b>.

AHU <b>106</b> may place the working fluid in a heat exchange relationship with an airflow passing through AHU <b>106</b> (e.g., via one or more stages of cooling coils and/or heating coils). The airflow may be, for example, outside air, return air from within building <b>10</b>, or a combination of both. AHU <b>106</b> may transfer heat between the airflow and the working fluid to provide heating or cooling for the airflow. For example, AHU <b>106</b> may include one or more fans or blowers configured to pass the airflow over or through a heat exchanger containing the working fluid. The working fluid may then return to chiller <b>102</b> or boiler <b>104</b> via piping <b>110</b>.

Airside system <b>130</b> may deliver the airflow supplied by AHU <b>106</b> (i.e., the supply airflow) to building <b>10</b> via air supply ducts <b>112</b> and may provide return air from building <b>10</b> to AHU <b>106</b> via air return ducts <b>114</b>. In some embodiments, airside system <b>130</b> includes multiple variable air volume (VAV) units <b>116</b>. For example, airside system <b>130</b> is shown to include a separate VAV unit <b>116</b> on each floor or zone of building <b>10</b>. VAV units <b>116</b> may include dampers or other flow control elements that can be operated to control an amount of the supply airflow provided to individual zones of building <b>10</b>. In other embodiments, airside system <b>130</b> delivers the supply airflow into one or more zones of building <b>10</b> (e.g., via supply ducts <b>112</b>) without using intermediate VAV units <b>116</b> or other flow control elements. AHU <b>106</b> may include various sensors (e.g., temperature sensors, pressure sensors, etc.) configured to measure attributes of the supply airflow. AHU <b>106</b> may receive input from sensors located within AHU <b>106</b> and/or within the building zone and may adjust the flow rate, temperature, or other attributes of the supply airflow through AHU <b>106</b> to achieve setpoint conditions for the building zone.

Referring now to <figref idref="DRAWINGS">FIG. 2</figref>, a block diagram of a waterside system <b>200</b> is shown, according to an exemplary embodiment. In various embodiments, waterside system <b>200</b> may supplement or replace waterside system <b>120</b> in HVAC system <b>100</b> or may be implemented separate from HVAC system <b>100</b>. When implemented in HVAC system <b>100</b>, waterside system <b>200</b> may include a subset of the HVAC devices in HVAC system <b>100</b> (e.g., boiler <b>104</b>, chiller <b>102</b>, pumps, valves, etc.) and may operate to supply a heated or chilled fluid to AHU <b>106</b>. The HVAC devices of waterside system <b>200</b> may be located within building <b>10</b> (e.g., as components of waterside system <b>120</b>) or at an offsite location such as a central plant.

Waterside system <b>200</b> is shown in <figref idref="DRAWINGS">FIG. 2</figref> as a central plant having a plurality of subplants <b>202</b>-<b>212</b>. Subplants <b>202</b>-<b>212</b> are shown to include a heater subplant <b>202</b>, a heat recovery chiller subplant <b>204</b>, a chiller subplant <b>206</b>, a cooling tower subplant <b>208</b>, a hot thermal energy storage (TES) subplant <b>210</b>, and a cold thermal energy storage (TES) subplant <b>212</b>. Subplants <b>202</b>-<b>212</b> consume 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 subplant <b>202</b> may be configured to heat water in a hot water loop <b>214</b> that circulates the hot water between heater subplant <b>202</b> and building <b>10</b>. Chiller subplant <b>206</b> may be configured to chill water in a cold water loop <b>216</b> that circulates the cold water between chiller subplant <b>206</b> building <b>10</b>. Heat recovery chiller subplant <b>204</b> may be configured to transfer heat from cold water loop <b>216</b> to hot water loop <b>214</b> to provide additional heating for the hot water and additional cooling for the cold water. Condenser water loop <b>218</b> may absorb heat from the cold water in chiller subplant <b>206</b> and reject the absorbed heat in cooling tower subplant <b>208</b> or transfer the absorbed heat to hot water loop <b>214</b>. Hot TES subplant <b>210</b> and cold TES subplant <b>212</b> may store hot and cold thermal energy, respectively, for subsequent use.

Hot water loop <b>214</b> and cold water loop <b>216</b> may deliver the heated and/or chilled water to air handlers located on the rooftop of building <b>10</b> (e.g., AHU <b>106</b>) or to individual floors or zones of building <b>10</b> (e.g., VAV units <b>116</b>). The air handlers push air past heat exchangers (e.g., heating coils or cooling coils) through which the water flows to provide heating or cooling for the air. The heated or cooled air may be delivered to individual zones of building <b>10</b> to serve the thermal energy loads of building <b>10</b>. The water then returns to subplants <b>202</b>-<b>212</b> to receive further heating or cooling.

Although subplants <b>202</b>-<b>212</b> are 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, subplants <b>202</b>-<b>212</b> may provide heating and/or cooling directly to the building or campus without requiring an intermediate heat transfer fluid. These and other variations to waterside system <b>200</b> are within the teachings of the present invention.

Each of subplants <b>202</b>-<b>212</b> may include a variety of equipment configured to facilitate the functions of the subplant. For example, heater subplant <b>202</b> is shown to include a plurality of heating elements <b>220</b> (e.g., boilers, electric heaters, etc.) configured to add heat to the hot water in hot water loop <b>214</b>. Heater subplant <b>202</b> is also shown to include several pumps <b>222</b> and <b>224</b> configured to circulate the hot water in hot water loop <b>214</b> and to control the flow rate of the hot water through individual heating elements <b>220</b>. Chiller subplant <b>206</b> is shown to include a plurality of chillers <b>232</b> configured to remove heat from the cold water in cold water loop <b>216</b>. Chiller subplant <b>206</b> is also shown to include several pumps <b>234</b> and <b>236</b> configured to circulate the cold water in cold water loop <b>216</b> and to control the flow rate of the cold water through individual chillers <b>232</b>.

Heat recovery chiller subplant <b>204</b> is shown to include a plurality of heat recovery heat exchangers <b>226</b> (e.g., refrigeration circuits) configured to transfer heat from cold water loop <b>216</b> to hot water loop <b>214</b>. Heat recovery chiller subplant <b>204</b> is also shown to include several pumps <b>228</b> and <b>230</b> configured to circulate the hot water and/or cold water through heat recovery heat exchangers <b>226</b> and to control the flow rate of the water through individual heat recovery heat exchangers <b>226</b>. Cooling tower subplant <b>208</b> is shown to include a plurality of cooling towers <b>238</b> configured to remove heat from the condenser water in condenser water loop <b>218</b>. Cooling tower subplant <b>208</b> is also shown to include several pumps <b>240</b> configured to circulate the condenser water in condenser water loop <b>218</b> and to control the flow rate of the condenser water through individual cooling towers <b>238</b>.

Hot TES subplant <b>210</b> is shown to include a hot TES tank <b>242</b> configured to store the hot water for later use. Hot TES subplant <b>210</b> may also include one or more pumps or valves configured to control the flow rate of the hot water into or out of hot TES tank <b>242</b>. Cold TES subplant <b>212</b> is shown to include cold TES tanks <b>244</b> configured to store the cold water for later use. Cold TES subplant <b>212</b> may also include one or more pumps or valves configured to control the flow rate of the cold water into or out of cold TES tanks <b>244</b>.

In some embodiments, one or more of the pumps in waterside system <b>200</b> (e.g., pumps <b>222</b>, <b>224</b>, <b>228</b>, <b>230</b>, <b>234</b>, <b>236</b>, and/or <b>240</b>) or pipelines in waterside system <b>200</b> include an isolation valve associated therewith. Isolation valves may be integrated with the pumps or positioned upstream or downstream of the pumps to control the fluid flows in waterside system <b>200</b>. In various embodiments, waterside system <b>200</b> may include more, fewer, or different types of devices and/or subplants based on the particular configuration of waterside system <b>200</b> and the types of loads served by waterside system <b>200</b>.

Referring now to <figref idref="DRAWINGS">FIG. 3</figref>, a block diagram of an airside system <b>300</b> is shown, according to an exemplary embodiment. In various embodiments, airside system <b>300</b> may supplement or replace airside system <b>130</b> in HVAC system <b>100</b> or may be implemented separate from HVAC system <b>100</b>. When implemented in HVAC system <b>100</b>, airside system <b>300</b> may include a subset of the HVAC devices in HVAC system <b>100</b> (e.g., AHU <b>106</b>, VAV units <b>116</b>, ducts <b>112</b>-<b>114</b>, fans, dampers, etc.) and may be located in or around building <b>10</b>. Airside system <b>300</b> may operate to heat or cool an airflow provided to building <b>10</b> using a heated or chilled fluid provided by waterside system <b>200</b>.

Airside system <b>300</b> is shown in <figref idref="DRAWINGS">FIG. 3</figref> as an economizer-type air handling unit (AHU) <b>302</b>. Economizer-type AHUs vary the amount of outside air and return air used by the air handling unit for heating or cooling. For example, AHU <b>302</b> may receive return air <b>304</b> from building zone <b>306</b> via return air duct <b>308</b> and may deliver supply air <b>310</b> to building zone <b>306</b> via supply air duct <b>312</b>. In some embodiments, AHU <b>302</b> is a rooftop unit located on the roof of building <b>10</b> (e.g., AHU <b>106</b> as shown in <figref idref="DRAWINGS">FIG. 1</figref>) or otherwise positioned to receive both return air <b>304</b> and outside air <b>314</b>. AHU <b>302</b> may be configured to operate exhaust air damper <b>316</b>, mixing damper <b>318</b>, and outside air damper <b>320</b> to control an amount of outside air <b>314</b> and return air <b>304</b> that combine to form supply air <b>310</b>. Any return air <b>304</b> that does not pass through mixing damper <b>318</b> may be exhausted from AHU <b>302</b> through exhaust damper <b>316</b> as exhaust air <b>322</b>.

Each of dampers <b>316</b>-<b>320</b> may be operated by an actuator. For example, exhaust air damper <b>316</b> may be operated by actuator <b>324</b>, mixing damper <b>318</b> may be operated by actuator <b>326</b>, and outside air damper <b>320</b> may be operated by actuator <b>328</b>. Actuators <b>324</b>-<b>328</b> may communicate with an AHU controller <b>330</b> via a communications link <b>332</b>. Actuators <b>324</b>-<b>328</b> may receive control signals from AHU controller <b>330</b> and may provide feedback signals to AHU controller <b>330</b>. 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 actuators <b>324</b>-<b>328</b>), status information, commissioning information, configuration settings, calibration data, and/or other types of information or data that may be collected, stored, or used by actuators <b>324</b>-<b>328</b>. AHU controller <b>330</b> may 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 actuators <b>324</b>-<b>328</b>.

Still referring to <figref idref="DRAWINGS">FIG. 3</figref>, AHU <b>302</b> is shown to include a cooling coil <b>334</b>, a heating coil <b>336</b>, and a fan <b>338</b> positioned within supply air duct <b>312</b>. Fan <b>338</b> may be configured to force supply air <b>310</b> through cooling coil <b>334</b> and/or heating coil <b>336</b> and provide supply air <b>310</b> to building zone <b>306</b>. AHU controller <b>330</b> may communicate with fan <b>338</b> via communications link <b>340</b> to control a flow rate of supply air <b>310</b>. In some embodiments, AHU controller <b>330</b> controls an amount of heating or cooling applied to supply air <b>310</b> by modulating a speed of fan <b>338</b>.

Cooling coil <b>334</b> may receive a chilled fluid from waterside system <b>200</b> (e.g., from cold water loop <b>216</b>) via piping <b>342</b> and may return the chilled fluid to waterside system <b>200</b> via piping <b>344</b>. Valve <b>346</b> may be positioned along piping <b>342</b> or piping <b>344</b> to control a flow rate of the chilled fluid through cooling coil <b>334</b>. In some embodiments, cooling coil <b>334</b> includes multiple stages of cooling coils that can be independently activated and deactivated (e.g., by AHU controller <b>330</b>, by BMS controller <b>366</b>, etc.) to modulate an amount of cooling applied to supply air <b>310</b>.

Heating coil <b>336</b> may receive a heated fluid from waterside system <b>200</b> (e.g., from hot water loop <b>214</b>) via piping <b>348</b> and may return the heated fluid to waterside system <b>200</b> via piping <b>350</b>. Valve <b>352</b> may be positioned along piping <b>348</b> or piping <b>350</b> to control a flow rate of the heated fluid through heating coil <b>336</b>. In some embodiments, heating coil <b>336</b> includes multiple stages of heating coils that can be independently activated and deactivated (e.g., by AHU controller <b>330</b>, by BMS controller <b>366</b>, etc.) to modulate an amount of heating applied to supply air <b>310</b>.

Each of valves <b>346</b> and <b>352</b> may be controlled by an actuator. For example, valve <b>346</b> may be controlled by actuator <b>354</b> and valve <b>352</b> may be controlled by actuator <b>356</b>. Actuators <b>354</b>-<b>356</b> may communicate with AHU controller <b>330</b> via communications links <b>358</b>-<b>360</b>. Actuators <b>354</b>-<b>356</b> may receive control signals from AHU controller <b>330</b> and may provide feedback signals to controller <b>330</b>. In some embodiments, AHU controller <b>330</b> receives a measurement of the supply air temperature from a temperature sensor <b>362</b> positioned in supply air duct <b>312</b> (e.g., downstream of cooling coil <b>334</b> and/or heating coil <b>336</b>). AHU controller <b>330</b> may also receive a measurement of the temperature of building zone <b>306</b> from a temperature sensor <b>364</b> located in building zone <b>306</b>.

In some embodiments, AHU controller <b>330</b> operates valves <b>346</b> and <b>352</b> via actuators <b>354</b>-<b>356</b> to modulate an amount of heating or cooling provided to supply air <b>310</b> (e.g., to achieve a setpoint temperature for supply air <b>310</b> or to maintain the temperature of supply air <b>310</b> within a setpoint temperature range). The positions of valves <b>346</b> and <b>352</b> affect the amount of heating or cooling provided to supply air <b>310</b> by cooling coil <b>334</b> or heating coil <b>336</b> and may correlate with the amount of energy consumed to achieve a desired supply air temperature. AHU controller <b>330</b> may control the temperature of supply air <b>310</b> and/or building zone <b>306</b> by activating or deactivating coils <b>334</b>-<b>336</b>, adjusting a speed of fan <b>338</b>, or a combination of both.

Still referring to <figref idref="DRAWINGS">FIG. 3</figref>, airside system <b>300</b> is shown to include a building management system (BMS) controller <b>366</b> and a client device <b>368</b>. BMS controller <b>366</b> may include one or more computer systems (e.g., servers, supervisory controllers, subsystem controllers, etc.) that serve as system level controllers, application or data servers, head nodes, or master controllers for airside system <b>300</b>, waterside system <b>200</b>, HVAC system <b>100</b>, and/or other controllable systems that serve building <b>10</b>. BMS controller <b>366</b> may communicate with multiple downstream building systems or subsystems (e.g., HVAC system <b>100</b>, a security system, a lighting system, waterside system <b>200</b>, etc.) via a communications link <b>370</b> according to like or disparate protocols (e.g., LON, BACnet, etc.). In various embodiments, AHU controller <b>330</b> and BMS controller <b>366</b> may be separate (as shown in <figref idref="DRAWINGS">FIG. 3</figref>) or integrated. In an integrated implementation, AHU controller <b>330</b> may be a software module configured for execution by a processor of BMS controller <b>366</b>.

In some embodiments, AHU controller <b>330</b> receives information from BMS controller <b>366</b> (e.g., commands, setpoints, operating boundaries, etc.) and provides information to BMS controller <b>366</b> (e.g., temperature measurements, valve or actuator positions, operating statuses, diagnostics, etc.). For example, AHU controller <b>330</b> may provide BMS controller <b>366</b> with temperature measurements from temperature sensors <b>362</b>-<b>364</b>, equipment on/off states, equipment operating capacities, and/or any other information that can be used by BMS controller <b>366</b> to monitor or control a variable state or condition within building zone <b>306</b>.

Client device <b>368</b> may 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 system <b>100</b>, its subsystems, and/or devices. Client device <b>368</b> may be a computer workstation, a client terminal, a remote or local interface, or any other type of user interface device. Client device <b>368</b> may be a stationary terminal or a mobile device. For example, client device <b>368</b> may 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 device <b>368</b> may communicate with BMS controller <b>366</b> and/or AHU controller <b>330</b> via communications link <b>372</b>.

Referring now to <figref idref="DRAWINGS">FIG. 4</figref>, a block diagram of a building management system (BMS) <b>400</b> is shown, according to an exemplary embodiment. BMS <b>400</b> may be implemented in building <b>10</b> to automatically monitor and control various building functions. BMS <b>400</b> is shown to include BMS controller <b>366</b> and a plurality of building subsystems <b>428</b>. Building subsystems <b>428</b> are shown to include a building electrical subsystem <b>434</b>, an information communication technology (ICT) subsystem <b>436</b>, a security subsystem <b>438</b>, a HVAC subsystem <b>440</b>, a lighting subsystem <b>442</b>, a lift/escalators subsystem <b>432</b>, and a fire safety subsystem <b>430</b>. In various embodiments, building subsystems <b>428</b> can include fewer, additional, or alternative subsystems. For example, building subsystems <b>428</b> may also or alternatively include a refrigeration subsystem, an advertising or signage subsystem, a cooking subsystem, a vending subsystem, a printer or copy service subsystem, or any other type of building subsystem that uses controllable equipment and/or sensors to monitor or control building <b>10</b>. In some embodiments, building subsystems <b>428</b> include waterside system <b>200</b> and/or airside system <b>300</b>, as described with reference to <figref idref="DRAWINGS">FIGS. 2-3</figref>.

Each of building subsystems <b>428</b> may include any number of devices, controllers, and connections for completing its individual functions and control activities. HVAC subsystem <b>440</b> may include many of the same components as HVAC system <b>100</b>, waterside system <b>200</b>, and/or airside system <b>300</b>, as described with reference to <figref idref="DRAWINGS">FIGS. 1-3</figref>. For example, HVAC subsystem <b>440</b> may 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 building <b>10</b>. Lighting subsystem <b>442</b> may 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 subsystem <b>438</b> may 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 to <figref idref="DRAWINGS">FIG. 4</figref>, BMS controller <b>366</b> is shown to include a communications interface <b>407</b> and a BMS interface <b>409</b>. Interface <b>407</b> may facilitate communications between BMS controller <b>366</b> and external applications (e.g., monitoring and reporting applications <b>422</b>, enterprise control applications <b>426</b>, remote systems and applications <b>444</b>, applications residing on client devices <b>448</b>, etc.) for allowing user control, monitoring, and adjustment to BMS controller <b>366</b> and/or subsystems <b>428</b>. Interface <b>407</b> may also facilitate communications between BMS controller <b>366</b> and client devices <b>448</b>. BMS interface <b>409</b> may facilitate communications between BMS controller <b>366</b> and building subsystems <b>428</b> (e.g., HVAC, lighting security, lifts, power distribution, business, etc.).

Interfaces <b>407</b>, <b>409</b> can be or include wired or wireless communications interfaces (e.g., jacks, antennas, transmitters, receivers, transceivers, wire terminals, etc.) for conducting data communications with building subsystems <b>428</b> or other external systems or devices. In various embodiments, communications via interfaces <b>407</b>, <b>409</b> may be direct (e.g., local wired or wireless communications) or via a communications network <b>446</b> (e.g., a WAN, the Internet, a cellular network, etc.). For example, interfaces <b>407</b>, <b>409</b> can include an Ethernet card and port for sending and receiving data via an Ethernet-based communications link or network. In another example, interfaces <b>407</b>, <b>409</b> can include a WiFi transceiver for communicating via a wireless communications network. In another example, one or both of interfaces <b>407</b>, <b>409</b> may include cellular or mobile phone communications transceivers. In one embodiment, communications interface <b>407</b> is a power line communications interface and BMS interface <b>409</b> is an Ethernet interface. In other embodiments, both communications interface <b>407</b> and BMS interface <b>409</b> are Ethernet interfaces or are the same Ethernet interface.

Still referring to <figref idref="DRAWINGS">FIG. 4</figref>, BMS controller <b>366</b> is shown to include a processing circuit <b>404</b> including a processor <b>406</b> and memory <b>408</b>. Processing circuit <b>404</b> may be communicably connected to BMS interface <b>409</b> and/or communications interface <b>407</b> such that processing circuit <b>404</b> and the various components thereof can send and receive data via interfaces <b>407</b>, <b>409</b>. Processor <b>406</b> can be implemented as a general purpose processor, an application specific integrated circuit (ASIC), one or more field programmable gate arrays (FPGAs), a group of processing components, or other suitable electronic processing components.

Memory <b>408</b> (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. Memory <b>408</b> may be or include volatile memory or non-volatile memory. Memory <b>408</b> may 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, memory <b>408</b> is communicably connected to processor <b>406</b> via processing circuit <b>404</b> and includes computer code for executing (e.g., by processing circuit <b>404</b> and/or processor <b>406</b>) one or more processes described herein.

In some embodiments, BMS controller <b>366</b> is implemented within a single computer (e.g., one server, one housing, etc.). In various other embodiments BMS controller <b>366</b> may be distributed across multiple servers or computers (e.g., that can exist in distributed locations). Further, while <figref idref="DRAWINGS">FIG. 4</figref> shows applications <b>422</b> and <b>426</b> as existing outside of BMS controller <b>366</b>, in some embodiments, applications <b>422</b> and <b>426</b> may be hosted within BMS controller <b>366</b> (e.g., within memory <b>408</b>).

Still referring to <figref idref="DRAWINGS">FIG. 4</figref>, memory <b>408</b> is shown to include an enterprise integration layer <b>410</b>, an automated measurement and validation (AM&amp;V) layer <b>412</b>, a demand response (DR) layer <b>414</b>, a fault detection and diagnostics (FDD) layer <b>416</b>, an integrated control layer <b>418</b>, and a building subsystem integration layer <b>420</b>. Layers <b>410</b>-<b>420</b> may be configured to receive inputs from building subsystems <b>428</b> and other data sources, determine optimal control actions for building subsystems <b>428</b> based on the inputs, generate control signals based on the optimal control actions, and provide the generated control signals to building subsystems <b>428</b>. The following paragraphs describe some of the general functions performed by each of layers <b>410</b>-<b>420</b> in BMS <b>400</b>.

Enterprise integration layer <b>410</b> may be configured to serve clients or local applications with information and services to support a variety of enterprise-level applications. For example, enterprise control applications <b>426</b> may 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 applications <b>426</b> may also or alternatively be configured to provide configuration GUIs for configuring BMS controller <b>366</b>. In yet other embodiments, enterprise control applications <b>426</b> can work with layers <b>410</b>-<b>420</b> to optimize building performance (e.g., efficiency, energy use, comfort, or safety) based on inputs received at interface <b>407</b> and/or BMS interface <b>409</b>.

Building subsystem integration layer <b>420</b> may be configured to manage communications between BMS controller <b>366</b> and building subsystems <b>428</b>. For example, building subsystem integration layer <b>420</b> may receive sensor data and input signals from building subsystems <b>428</b> and provide output data and control signals to building subsystems <b>428</b>. Building subsystem integration layer <b>420</b> may also be configured to manage communications between building subsystems <b>428</b>. Building subsystem integration layer <b>420</b> translate communications (e.g., sensor data, input signals, output signals, etc.) across a plurality of multi-vendor/multi-protocol systems.

Demand response layer <b>414</b> may be configured to optimize resource usage (e.g., electricity use, natural gas use, water use, etc.) and/or the monetary cost of such resource usage in response to satisfy the demand of building <b>10</b>. The optimization may be based on time-of-use prices, curtailment signals, energy availability, or other data received from utility providers, distributed energy generation systems <b>424</b>, energy storage <b>427</b> (e.g., hot TES <b>242</b>, cold TES <b>244</b>, electrical energy storage, etc.), or from other sources. Demand response layer <b>414</b> may receive inputs from other layers of BMS controller <b>366</b> (e.g., building subsystem integration layer <b>420</b>, integrated control layer <b>418</b>, etc.). The inputs received from other layers may include environmental or sensor inputs such as temperature, carbon dioxide levels, relative humidity levels, air quality sensor outputs, occupancy sensor outputs, room schedules, and the like. The inputs may also include inputs such as electrical use (e.g., expressed in kWh), thermal load measurements, pricing information, projected pricing, smoothed pricing, curtailment signals from utilities, and the like.

According to an exemplary embodiment, demand response layer <b>414</b> includes control logic for responding to the data and signals it receives. These responses can include communicating with the control algorithms in integrated control layer <b>418</b>, changing control strategies, changing setpoints, or activating/deactivating building equipment or subsystems in a controlled manner. Demand response layer <b>414</b> may also include control logic configured to determine when to utilize stored energy. For example, demand response layer <b>414</b> may determine to begin using energy from energy storage <b>427</b> just prior to the beginning of a peak use hour.

In some embodiments, demand response layer <b>414</b> includes a control module configured to actively initiate control actions (e.g., automatically changing setpoints) which minimize energy costs based on one or more inputs representative of or based on demand (e.g., price, a curtailment signal, a demand level, etc.). In some embodiments, demand response layer <b>414</b> uses equipment models to determine an optimal set of control actions. The equipment models may include, for example, thermodynamic models describing the inputs, outputs, and/or functions performed by various sets of building equipment. Equipment models may represent collections of building equipment (e.g., subplants, chiller arrays, etc.) or individual devices (e.g., individual chillers, heaters, pumps, etc.).

Demand response layer <b>414</b> may 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.).

Integrated control layer <b>418</b> may be configured to use the data input or output of building subsystem integration layer <b>420</b> and/or demand response layer <b>414</b> to make control decisions. Due to the subsystem integration provided by building subsystem integration layer <b>420</b>, integrated control layer <b>418</b> can integrate control activities of the subsystems <b>428</b> such that the subsystems <b>428</b> behave as a single integrated supersystem. In an exemplary embodiment, integrated control layer <b>418</b> includes control logic that uses inputs and outputs from a plurality of building subsystems to provide greater comfort and energy savings relative to the comfort and energy savings that separate subsystems could provide alone. For example, integrated control layer <b>418</b> may be configured to use an input from a first subsystem to make an energy-saving control decision for a second subsystem. Results of these decisions can be communicated back to building subsystem integration layer <b>420</b>.

Integrated control layer <b>418</b> is shown to be logically below demand response layer <b>414</b>. Integrated control layer <b>418</b> may be configured to enhance the effectiveness of demand response layer <b>414</b> by enabling building subsystems <b>428</b> and their respective control loops to be controlled in coordination with demand response layer <b>414</b>. This configuration may advantageously reduce disruptive demand response behavior relative to conventional systems. For example, integrated control layer <b>418</b> may be configured to assure that a demand response-driven upward adjustment to the setpoint for chilled water temperature (or another component that directly or indirectly affects temperature) does not result in an increase in fan energy (or other energy used to cool a space) that would result in greater total building energy use than was saved at the chiller.

Integrated control layer <b>418</b> may be configured to provide feedback to demand response layer <b>414</b> so that demand response layer <b>414</b> checks that constraints (e.g., temperature, lighting levels, etc.) are properly maintained even while demanded load shedding is in progress. The constraints may also include setpoint or sensed boundaries relating to safety, equipment operating limits and performance, comfort, fire codes, electrical codes, energy codes, and the like. Integrated control layer <b>418</b> is also logically below fault detection and diagnostics layer <b>416</b> and automated measurement and validation layer <b>412</b>. Integrated control layer <b>418</b> may be configured to provide calculated inputs (e.g., aggregations) to these higher levels based on outputs from more than one building subsystem.

Automated measurement and validation (AM&amp;V) layer <b>412</b> may be configured to verify that control strategies commanded by integrated control layer <b>418</b> or demand response layer <b>414</b> are working properly (e.g., using data aggregated by AM&amp;V layer <b>412</b>, integrated control layer <b>418</b>, building subsystem integration layer <b>420</b>, FDD layer <b>416</b>, or otherwise). The calculations made by AM&amp;V layer <b>412</b> may be based on building system energy models and/or equipment models for individual BMS devices or subsystems. For example, AM&amp;V layer <b>412</b> may compare a model-predicted output with an actual output from building subsystems <b>428</b> to determine an accuracy of the model.

Fault detection and diagnostics (FDD) layer <b>416</b> may be configured to provide on-going fault detection for building subsystems <b>428</b>, building subsystem devices (i.e., building equipment), and control algorithms used by demand response layer <b>414</b> and integrated control layer <b>418</b>. FDD layer <b>416</b> may receive data inputs from integrated control layer <b>418</b>, directly from one or more building subsystems or devices, or from another data source. FDD layer <b>416</b> may automatically diagnose and respond to detected faults. The responses to detected or diagnosed faults may include providing an alert message to a user, a maintenance scheduling system, or a control algorithm configured to attempt to repair the fault or to work-around the fault.

FDD layer <b>416</b> may be configured to output a specific identification of the faulty component or cause of the fault (e.g., loose damper linkage) using detailed subsystem inputs available at building subsystem integration layer <b>420</b>. In other exemplary embodiments, FDD layer <b>416</b> is configured to provide “fault” events to integrated control layer <b>418</b> which executes control strategies and policies in response to the received fault events. According to an exemplary embodiment, FDD layer <b>416</b> (or a policy executed by an integrated control engine or business rules engine) may shut-down systems or direct control activities around faulty devices or systems to reduce energy waste, extend equipment life, or assure proper control response.

FDD layer <b>416</b> may be configured to store or access a variety of different system data stores (or data points for live data). FDD layer <b>416</b> may use some content of the data stores to identify faults at the equipment level (e.g., specific chiller, specific AHU, specific terminal unit, etc.) and other content to identify faults at component or subsystem levels. For example, building subsystems <b>428</b> may generate temporal (i.e., time-series) data indicating the performance of BMS <b>400</b> and the various components thereof. The data generated by building subsystems <b>428</b> may include measured or calculated values that exhibit statistical characteristics and provide information about how the corresponding system or process (e.g., a temperature control process, a flow control process, etc.) is performing in terms of error from its setpoint. These processes can be examined by FDD layer <b>416</b> to expose when the system begins to degrade in performance and alert a user to repair the fault before it becomes more severe.

Central Plant System with Thermal and Electrical Energy Storage

Referring now to <figref idref="DRAWINGS">FIG. 5</figref>, a block diagram of a central plant system <b>500</b> is shown, according to an exemplary embodiment. Central plant system <b>500</b> is shown to include a building <b>502</b>. Building <b>502</b> may be the same or similar to building <b>10</b>, as described with reference to <figref idref="DRAWINGS">FIG. 1</figref>. For example, building <b>502</b> may be equipped with a HVAC system and/or a building management system (e.g., BMS <b>400</b>) that operates to control conditions within building <b>502</b>. In some embodiments, building <b>502</b> includes multiple buildings (i.e., a campus) served by central plant system <b>500</b>. Building <b>502</b> may 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 building <b>502</b> (e.g., building subsystems <b>428</b>) or by external systems that provide services for building <b>502</b> (e.g., heating, cooling, air circulation, lighting, electricity, etc.). Central plant system <b>500</b> operates to satisfy the resource demand associated with building <b>502</b>.

Central plant system <b>500</b> is shown to include a plurality of utilities <b>510</b>. Utilities <b>510</b> may provide central plant system <b>500</b> with resources such as electricity, water, natural gas, or any other resource that can be used by central plant system <b>500</b> to satisfy the demand of building <b>502</b>. For example, utilities <b>510</b> are shown to include an electric utility <b>511</b>, a water utility <b>512</b>, a natural gas utility <b>513</b>, and utility M <b>514</b>, where M is the total number of utilities <b>510</b>. In some embodiments, utilities <b>510</b> are commodity suppliers from which resources and other types of commodities can be purchased. Resources purchased from utilities <b>510</b> can be used by generator subplants <b>520</b> to produce generated resources (e.g., hot water, cold water, electricity, steam, etc.), stored in storage subplants <b>530</b> for later use, or provided directly to building <b>502</b>. For example, utilities <b>510</b> are shown providing electricity directly to building <b>502</b> and storage subplants <b>530</b>.

Central plant system <b>500</b> is shown to include a plurality of generator subplants <b>520</b>. In some embodiments, generator subplants <b>520</b> include one or more of the subplants described with reference to <figref idref="DRAWINGS">FIG. 2</figref>. For example, generator subplants <b>520</b> are shown to include a heater subplant <b>521</b>, a chiller subplant <b>522</b>, a heat recovery chiller subplant <b>523</b>, a steam subplant <b>524</b>, an electricity subplant <b>525</b>, and subplant N, where N is the total number of generator subplants <b>520</b>. Generator subplants <b>520</b> may be configured to convert one or more input resources into one or more output resources by operation of the equipment within generator subplants <b>520</b>. For example, heater subplant <b>521</b> may be configured to generate hot thermal energy (e.g., hot water) by heating water using electricity or natural gas. Chiller subplant <b>522</b> may be configured to generate cold thermal energy (e.g., cold water) by chilling water using electricity. Heat recovery chiller subplant <b>523</b> may 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 subplant <b>524</b> may be configured to generate steam by boiling water using electricity or natural gas. Electricity subplant <b>525</b> may 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.).

The input resources used by generator subplants <b>520</b> may be provided by utilities <b>510</b>, retrieved from storage subplants <b>530</b>, and/or generated by other generator subplants <b>520</b>. For example, steam subplant <b>524</b> may produce steam as an output resource. Electricity subplant <b>525</b> may include a steam turbine that uses the steam generated by steam subplant <b>524</b> as an input resource to generate electricity. The output resources produced by generator subplants <b>520</b> may be stored in storage subplants <b>530</b>, provided to building <b>502</b>, sold to energy purchasers <b>504</b>, and/or used by other generator subplants <b>520</b>. For example, the electricity generated by electricity subplant <b>525</b> may be stored in electrical energy storage <b>533</b>, used by chiller subplant <b>522</b> to generate cold thermal energy, provided to building <b>502</b>, and/or sold to energy purchasers <b>504</b>.

Central plant system <b>500</b> is shown to include storage subplants <b>530</b>. Storage subplants <b>530</b> may be configured to store energy and other types of resources for later use. Each of storage subplants <b>530</b> may be configured to store a different type of resource. For example, storage subplants <b>530</b> are shown to include hot thermal energy storage <b>531</b> (e.g., one or more hot water storage tanks), cold thermal energy storage <b>532</b> (e.g., one or more cold thermal energy storage tanks), electrical energy storage <b>533</b> (e.g., one or more batteries), and resource type P storage <b>534</b>, where P is the total number of storage subplants <b>530</b>. The resources stored in subplants <b>530</b> may be purchased directly from utilities <b>510</b> or generated by generator subplants <b>520</b>.

In some embodiments, storage subplants <b>530</b> are used by central plant system <b>500</b> to 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 utilities <b>510</b>) in the form of energy prices that vary as a function of time. For example, utilities <b>510</b> may 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 subplants <b>530</b> allows 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 subplants <b>530</b> also allows the resource demand of building <b>502</b> to be shifted in time. For example, resources can be purchased from utilities <b>510</b> at times when the demand for heating or cooling is low and immediately converted into hot or cold thermal energy by generator subplants <b>520</b>. The thermal energy can be stored in storage subplants <b>530</b> and retrieved at times when the demand for heating or cooling is high. This allows central plant system <b>500</b> to smooth the resource demand of building <b>502</b> and reduces the maximum required capacity of generator subplants <b>520</b>. Smoothing the demand also allows central plant system <b>500</b> to reduce the peak electricity consumption, which results in a lower demand charge.

In some embodiments, storage subplants <b>530</b> are used by central plant system <b>500</b> to 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 utilities <b>510</b> or 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 purchasers <b>504</b> (e.g., an energy grid) to supplement the energy generated by utilities <b>510</b>. 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 storage <b>533</b> allows system <b>500</b> to quickly respond to a request for electric power by rapidly discharging stored electrical energy to energy purchasers <b>504</b>.

Still referring to <figref idref="DRAWINGS">FIG. 5</figref>, central plant system <b>500</b> is shown to include a central plant controller <b>506</b>. Central plant controller <b>506</b> may be configured to control the distribution, production, storage, and usage of resources in central plant system <b>500</b>. In some embodiments, central plant controller <b>506</b> performs 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 utilities <b>510</b>, an optimal amount of each resource to produce or convert using generator subplants <b>520</b>, an optimal amount of each resource to store or remove from storage subplants <b>530</b>, an optimal amount of each resource to sell to energy purchasers <b>504</b>, and/or an optimal amount of each resource to provide to building <b>502</b>. In some embodiments, the control decisions include an optimal amount of each input resource and output resource for each of generator subplants <b>520</b>.

Controller <b>506</b> may be configured to maximize the economic value of operating central plant system <b>500</b> 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 controller <b>506</b>. The value function may account for the cost of resources purchased from utilities <b>510</b>, revenue generated by selling resources to energy purchasers <b>504</b>, and the cost of operating central plant system <b>500</b>. In some embodiments, the cost of operating central plant system <b>500</b> includes a cost for losses in battery capacity as a result of the charging and discharging electrical energy storage <b>533</b>. The cost of operating central plant system <b>500</b> may also include a cost of excessive equipment start/stops during the optimization period.

Each of subplants <b>520</b>-<b>530</b> may include equipment that can be controlled by central plant controller <b>506</b> to optimize the performance of central plant system <b>500</b>. 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 subplants <b>520</b>-<b>530</b>. Individual devices of generator subplants <b>520</b> can be turned on or off to adjust the resource production of each generator subplant. In some embodiments, individual devices of generator subplants <b>520</b> can 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 controller <b>506</b>.

In some embodiments, one or more of subplants <b>520</b>-<b>530</b> includes a subplant level controller configured to control the equipment of the corresponding subplant. For example, central plant controller <b>506</b> may 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, controller <b>506</b> maximizes the life cycle economic value of central plant system <b>500</b> while participating in PBDR programs, IBDR programs, or simultaneously in both PBDR and IBDR programs. For the IBDR programs, controller <b>506</b> 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 <b>504</b>. For the PBDR programs, controller <b>506</b> may use predictions of ambient conditions, facility thermal loads, and thermodynamic models of installed equipment to estimate the resource consumption of subplants <b>520</b>. Controller <b>506</b> may use predictions of the resource consumption to monetize the costs of running the equipment.

Controller <b>506</b> 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, controller <b>506</b> 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. Controller <b>506</b> 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 controller <b>506</b> to determine an optimal set of control decisions that maximize the overall value of operating central plant system <b>500</b>.

In some instances, controller <b>506</b> 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, controller <b>506</b> may receive notice of a synchronous reserve event from an IBDR program which requires central plant system <b>500</b> to shed a predetermined amount of power. Controller <b>506</b> may determine that it is optimal to participate in the IBDR program if cold thermal energy storage <b>532</b> has enough capacity to provide cooling for building <b>502</b> while the load on chiller subplant <b>522</b> is reduced in order to shed the predetermined amount of power.

In other instances, controller <b>506</b> 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 building <b>502</b> is close to setting a new peak demand that would greatly increase the PBDR costs, controller <b>506</b> may determine that only a small portion of the electrical energy stored in electrical energy storage <b>533</b> will be sold to energy purchasers <b>504</b> in order to participate in a frequency response market. Controller <b>506</b> may determine that the remainder of the electrical energy will be used to power chiller subplant <b>522</b> to prevent a new peak demand from being set.

Central Plant Controller

Referring now to <figref idref="DRAWINGS">FIG. 6</figref>, a block diagram illustrating a central plant controller <b>506</b> in greater detail is shown, according to an exemplary embodiment. Central plant controller <b>506</b> is shown providing control decisions to a building management system (BMS) <b>606</b>. In some embodiments, BMS <b>606</b> is the same or similar to BMS <b>400</b>, as described with reference to <figref idref="DRAWINGS">FIG. 4</figref>. The control decisions provided to BMS <b>606</b> may include resource purchase amounts for utilities <b>510</b>, setpoints for generator subplants <b>520</b>, and/or charge/discharge rates for storage subplants <b>530</b>.

BMS <b>606</b> may be configured to monitor conditions within a controlled building or building zone. For example, BMS <b>606</b> may 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 controller <b>506</b>. 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. BMS <b>606</b> may operate subplants <b>520</b>-<b>530</b> to affect the monitored conditions within the building and to serve the thermal energy loads of the building.

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

Central plant controller <b>506</b> may monitor the status of the controlled building using information received from BMS <b>606</b>. Central plant controller <b>506</b> may 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 service <b>604</b>). Central plant controller <b>506</b> may 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 programs <b>602</b>. Central plant controller <b>506</b> may generate control decisions that optimize the economic value of operating central plant system <b>500</b> over 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 controller <b>506</b> is described in greater detail below.

According to an exemplary embodiment, central plant controller <b>506</b> is integrated within a single computer (e.g., one server, one housing, etc.). In various other exemplary embodiments, central plant controller <b>506</b> can be distributed across multiple servers or computers (e.g., that can exist in distributed locations). In another exemplary embodiment, central plant controller <b>506</b> may integrated with a smart building manager that manages multiple building systems and/or combined with BMS <b>606</b>.

Central plant controller <b>506</b> is shown to include a communications interface <b>636</b> and a processing circuit <b>607</b>. Communications interface <b>636</b> may 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 interface <b>636</b> may 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 interface <b>636</b> may 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 interface <b>636</b> may be a network interface configured to facilitate electronic data communications between central plant controller <b>506</b> and various external systems or devices (e.g., BMS <b>606</b>, subplants <b>520</b>-<b>530</b>, utilities <b>510</b>, etc.). For example, central plant controller <b>506</b> may receive information from BMS <b>606</b> indicating one or more measured states of the controlled building (e.g., temperature, humidity, electric loads, etc.) and one or more states of subplants <b>520</b>-<b>530</b> (e.g., equipment status, power consumption, equipment availability, etc.). Communications interface <b>636</b> may receive inputs from BMS <b>606</b> and/or subplants <b>520</b>-<b>530</b> and may provide operating parameters (e.g., on/off decisions, setpoints, etc.) to subplants <b>520</b>-<b>530</b> via BMS <b>606</b>. The operating parameters may cause subplants <b>520</b>-<b>530</b> to activate, deactivate, or adjust a setpoint for various devices thereof.

Still referring to <figref idref="DRAWINGS">FIG. 6</figref>, processing circuit <b>607</b> is shown to include a processor <b>608</b> and memory <b>610</b>. Processor <b>608</b> may 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. Processor <b>608</b> may be configured to execute computer code or instructions stored in memory <b>610</b> or received from other computer readable media (e.g., CDROM, network storage, a remote server, etc.).

Memory <b>610</b> may 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. Memory <b>610</b> may 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. Memory <b>610</b> may 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. Memory <b>610</b> may be communicably connected to processor <b>608</b> via processing circuit <b>607</b> and may include computer code for executing (e.g., by processor <b>608</b>) one or more processes described herein.

Memory <b>610</b> is shown to include a building status monitor <b>624</b>. Central plant controller <b>506</b> may receive data regarding the overall building or building space to be heated or cooled by the central plant via building status monitor <b>624</b>. In an exemplary embodiment, building status monitor <b>624</b> may 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 controller <b>506</b> may determine on/off configurations and operating setpoints to satisfy the building requirements received from building status monitor <b>624</b>. In some embodiments, building status monitor <b>624</b> receives, 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 monitor <b>624</b> stores data regarding energy costs, such as pricing information available from utilities <b>510</b> (energy charge, demand charge, etc.).

Still referring to <figref idref="DRAWINGS">FIG. 6</figref>, memory <b>610</b> is shown to include a load/rate predictor <b>622</b>. Load/rate predictor <b>622</b> may be configured to predict the thermal energy loads ({circumflex over (l)}_k) of the building or campus for each time step k (e.g., k=1 . . . n) of an optimization period. Load/rate predictor <b>622</b> is shown receiving weather forecasts from a weather service <b>604</b>. In some embodiments, load/rate predictor <b>622</b> predicts the thermal energy loads {circumflex over (l)}_kas a function of the weather forecasts. In some embodiments, load/rate predictor <b>622</b> uses feedback from BMS <b>606</b> to predict loads {circumflex over (l)}_k. Feedback from BMS <b>606</b> may 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 predictor <b>622</b> receives a measured electric load and/or previous measured load data from BMS <b>606</b> (e.g., via building status monitor <b>624</b>). Load/rate predictor <b>622</b> may predict loads {circumflex over (l)}_kas a function of a given weather forecast ({circumflex over (φ)}_w), a day type (clay), the time of day (t), and previous measured load data (Y_k−1). Such a relationship is expressed in the following equation:

&lt;br /&gt;<i>{circumflex over (l)}</i>_k<i>=f</i>({circumflex over (φ)}_w,day,<i>t|Y</i>_k−1)

In some embodiments, load/rate predictor <b>622</b> uses a deterministic plus stochastic model trained from historical load data to predict loads {circumflex over (l)}_k. Load/rate predictor <b>622</b> may use any of a variety of prediction methods to predict loads {circumflex over (l)}_k(e.g., linear regression for the deterministic portion and an AR model for the stochastic portion). Load/rate predictor <b>622</b> may predict one or more different types of loads for the building or campus. For example, load/rate predictor <b>622</b> may predict a hot water load {circumflex over (l)}_Hot,kand a cold water load {circumflex over (l)}_Cold,kfor each time step k within the prediction window. In some embodiments, load/rate predictor <b>622</b> makes 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 predictor <b>622</b> is shown receiving utility rates from utilities <b>510</b>. Utility rates may indicate a cost or price per unit of a resource (e.g., electricity, natural gas, water, etc.) provided by utilities <b>510</b> at 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 utilities <b>510</b> or predicted utility rates estimated by load/rate predictor <b>622</b>.

In some embodiments, the utility rates include demand charges for one or more resources provided by utilities <b>510</b>. A demand charge may define a separate cost imposed by utilities <b>510</b> based 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 optimizer <b>630</b> may be configured to account for demand charges in the high level optimization process performed by high level optimizer <b>632</b>. Utilities <b>510</b> may 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 predictor <b>622</b> may store the predicted loads {circumflex over (l)}_kand the utility rates in memory <b>610</b> and/or provide the predicted loads {circumflex over (l)}_kand the utility rates to demand response optimizer <b>630</b>.

Still referring to <figref idref="DRAWINGS">FIG. 6</figref>, memory <b>610</b> is shown to include an incentive estimator <b>620</b>. Incentive estimator <b>620</b> may be configured to estimate the revenue generation potential of participating in various incentive-based demand response (IBDR) programs. In some embodiments, incentive estimator <b>620</b> receives an incentive event history from incentive programs <b>602</b>. The incentive event history may include a history of past IBDR events from incentive programs <b>602</b>. An IBDR event may include an invitation from incentive programs <b>602</b> to 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 estimator <b>620</b> may use the incentive event history to estimate IBDR event probabilities during the optimization period.

Incentive estimator <b>620</b> is shown providing incentive predictions to demand response optimizer <b>630</b>. 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 optimizer <b>630</b> may use the incentive predictions along with the predicted loads {circumflex over (l)}_kand utility rates from load/rate predictor <b>622</b> to determine an optimal set of control decisions for each time step within the optimization period.

Still referring to <figref idref="DRAWINGS">FIG. 6</figref>, memory <b>610</b> is shown to include an demand response optimizer <b>630</b>. Demand response optimizer <b>630</b> may perform a cascaded optimization process to optimize the performance of central plant system <b>500</b>. For example, demand response optimizer <b>630</b> is shown to include a high level optimizer <b>632</b> and a low level optimizer <b>634</b>. High level optimizer <b>632</b> may control an outer (e.g., subplant level) loop of the cascaded optimization. High level optimizer <b>632</b> may 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 system <b>500</b>. Control decisions made by high level optimizer may include, for example, load setpoints for each of generator subplants <b>520</b>, charge/discharge rates for each of storage subplants <b>530</b>, resource purchase amounts for each type of resource purchased from utilities <b>510</b>, and/or an amount of each resource sold to energy purchasers <b>504</b>. In other words, the control decisions may define resource allocation at each time step. The control decisions made by high level optimizer <b>632</b> are 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 optimizer <b>634</b> may control an inner (e.g., equipment level) loop of the cascaded optimization. Low level optimizer <b>634</b> may determine how to best run each subplant at the load setpoint determined by high level optimizer <b>632</b>. For example, low level optimizer <b>634</b> may 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 optimizer <b>634</b> receives actual incentive events from incentive programs <b>602</b>. Low level optimizer <b>634</b> may determine whether to participate in the incentive events based on the resource allocation set by high level optimizer <b>632</b>. For example, if insufficient resources have been allocated to a particular IBDR program by high level optimizer <b>632</b> or if the allocated resources have already been used, low level optimizer <b>634</b> may determine that central plant system <b>500</b> will 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 subplants <b>530</b>, low level optimizer <b>634</b> may determine that system <b>500</b> will participate in the IBDR program in response to the IBDR event. The cascaded optimization process is described in greater detail with reference to <figref idref="DRAWINGS">FIG. 7</figref>.

Still referring to <figref idref="DRAWINGS">FIG. 6</figref>, memory <b>610</b> is shown to include a subplant control module <b>628</b>. Subplant control module <b>628</b> may store historical data regarding past operating statuses, past operating setpoints, and instructions for calculating and/or implementing control parameters for subplants <b>520</b>-<b>530</b>. Subplant control module <b>628</b> may 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 module <b>628</b> may receive data from subplants <b>520</b>-<b>530</b> and/or BMS <b>606</b> via communications interface <b>636</b>. Subplant control module <b>628</b> may also receive and store on/off statuses and operating setpoints from low level optimizer <b>634</b>.

Data and processing results from demand response optimizer <b>630</b>, subplant control module <b>628</b>, or other modules of central plant controller <b>506</b> may be accessed by (or pushed to) monitoring and reporting applications <b>626</b>. Monitoring and reporting applications <b>626</b> may 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 applications <b>626</b> may 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 to <figref idref="DRAWINGS">FIG. 6</figref>, central plant controller <b>506</b> may include one or more GUI servers, web services <b>612</b>, or GUI engines <b>614</b> to support monitoring and reporting applications <b>626</b>. In various embodiments, applications <b>626</b>, web services <b>612</b>, and GUI engine <b>614</b> may be provided as separate components outside of central plant controller <b>506</b> (e.g., as part of a smart building manager). Central plant controller <b>506</b> may 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 controller <b>506</b> may 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 controller <b>506</b> is shown to include configuration tools <b>616</b>. Configuration tools <b>616</b> can allow a user to define (e.g., via graphical user interfaces, via prompt-driven “wizards,” etc.) how central plant controller <b>506</b> should react to changing conditions in the central plant subsystems. In an exemplary embodiment, configuration tools <b>616</b> allow 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 tools <b>616</b> can 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 tools <b>616</b> can 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 to <figref idref="DRAWINGS">FIG. 7</figref>, a block diagram illustrating a portion of central plant system <b>500</b> in greater detail is shown, according to an exemplary embodiment. <figref idref="DRAWINGS">FIG. 7</figref> illustrates the cascaded optimization process performed by demand response optimizer <b>630</b> to optimize the performance of central plant system <b>500</b>. In the cascaded optimization process, high level optimizer <b>632</b> performs 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 system <b>500</b>. Low level optimizer <b>634</b> performs an equipment level optimization that determines how to best run each subplant based on the resource allocations determined by high level optimizer <b>632</b>. For example, low level optimizer <b>634</b> may 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 optimizer <b>630</b> is the optimal use of computational time. For example, the subplant level optimization performed by high level optimizer <b>632</b> may use a relatively long time horizon due to the operation of the thermal energy storage. However, the equipment level optimization performed by low level optimizer <b>634</b> may 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 BMS <b>606</b>. Such an optimal use of computational time makes it possible for demand response optimizer <b>630</b> to 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 optimizer <b>630</b> to be implemented in a real-time planning tool with interactive feedback.

Another advantage of the cascaded optimization performed by demand response optimizer <b>630</b> is 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 optimizer <b>632</b> to distribute and allocate resources without requiring high level optimizer <b>632</b> to 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 optimizer <b>632</b> and handled by low level optimizer <b>634</b>. For purposes of the subplant level optimization performed by high level optimizer <b>632</b>, each subplant may be completely defined by one or more subplant curves.

Still referring to <figref idref="DRAWINGS">FIG. 7</figref>, low level optimizer <b>634</b> may generate and provide subplant curves to high level optimizer <b>632</b>. Subplant curves may indicate the rate of resource consumption by each of subplants <b>520</b>-<b>530</b> (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 to <figref idref="DRAWINGS">FIGS. 9A-12</figref>. In some embodiments, low level optimizer <b>634</b> generates subplant curves based on equipment models <b>618</b> (e.g., by combining equipment models <b>618</b> for individual devices into an aggregate curve for the subplant). Low level optimizer <b>634</b> may generate subplant curves by running the low level optimization process for several different loads and weather conditions to generate multiple data points. Low level optimizer <b>634</b> may fit a curve to the data points to generate a subplant curves. In other embodiments, low level optimizer <b>634</b> provides the data points to high level optimizer <b>632</b> and high level optimizer <b>632</b> generates the subplant curves using the data points.

High level optimizer <b>632</b> may receive the load and rate predictions from load/rate predictor <b>622</b>, the incentive predictions from incentive estimator <b>620</b>, and the subplant curves from low level optimizer <b>634</b>. The load predictions may be based on weather forecasts from weather service <b>604</b> and/or information from BMS <b>606</b> (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 utilities <b>510</b> and/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 programs <b>602</b>.

High level optimizer <b>632</b> may determine an optimal resource allocation for subplants <b>520</b>-<b>530</b> (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 optimizer <b>634</b>. Resource allocations may include an amount of each input resource and each output resource consumed or produced by each of generator subplants <b>520</b> at each time step. Resource allocations may also include an amount of each resource charged or discharged from storage subplants <b>530</b>, an amount of each resource purchased from utilities <b>510</b>, and an amount of each resource sold to energy purchasers <b>504</b> for each time step in the optimization period. In some embodiments, high level optimizer <b>632</b> determines the resource allocation by maximizing the total operating value of central plant system <b>500</b> over the optimization period. For example, high level optimizer <b>632</b> may 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 subplants <b>530</b> to 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 subplants <b>530</b>.

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

<maths id="MATH-US-00001" num="00001"><math overflow="scroll"><mrow><msubsup><mi>θ</mi><mi>HL</mi><mo>*</mo></msubsup><mo>=</mo><mrow><mi>arg</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mrow><munder><mi>max</mi><msub><mi>θ</mi><mi>HL</mi></msub></munder><mo></mo><mrow><msub><mi>J</mi><mi>HL</mi></msub><mo></mo><mrow><mo>(</mo><msub><mi>θ</mi><mi>HL</mi></msub><mo>)</mo></mrow></mrow></mrow></mrow></mrow></math></maths>

where θ_HL* contains the optimal high level decisions (e.g., the optimal resource allocation) for the entire optimization period and J_HLis the high level value function. To find the optimal high level decisions θ_HL*, high level optimizer <b>632</b> may maximize the high level cost function J_HL. The high level cost function J_HLmay include the revenue generated by participating in IBDR programs, the cost of resources purchased from utilities <b>510</b>, and the cost of equipment degradation over the duration of the optimization period. In some embodiments, the high level cost function J_HLis described using the following equation:

&lt;br /&gt;<i>J</i>_HL=∫_t^t+h($<i>IBDR</i>−$<i>PBDR</i>−$<i>BL</i>−$Penalties)<i>dt </i>

where $IBDR is the revenue generated from participating in IBDR programs, $PBDR is the cost of resources purchased from utilities <b>510</b>, $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 to <figref idref="DRAWINGS">FIG. 8</figref>.

The decision vector θ_HLmay be subject to several constraints. For example, the constraints may require that each of generator subplants <b>520</b> not operate at more than its total capacity and that the input resources and output resources of each generator subplant <b>520</b> are related as defined by the subplant curves. The constraints may require that storage subplants <b>530</b> not charge or discharge too quickly and may constrain the amount of a resource stored in each of subplants <b>530</b> between 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 to <figref idref="DRAWINGS">FIG. 8</figref>.

Still referring to <figref idref="DRAWINGS">FIG. 7</figref>, low level optimizer <b>634</b> may use the resource allocations determined by high level optimizer <b>632</b> to determine optimal low level decisions θ_LL* (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 subplants <b>520</b>-<b>530</b>. Low level optimizer <b>634</b> may 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:

<maths id="MATH-US-00002" num="00002"><math overflow="scroll"><mrow><msubsup><mi>θ</mi><mi>LL</mi><mo>*</mo></msubsup><mo>=</mo><mrow><mi>arg</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mrow><munder><mi>max</mi><msub><mi>θ</mi><mi>LL</mi></msub></munder><mo></mo><mrow><msub><mi>J</mi><mi>LL</mi></msub><mo></mo><mrow><mo>(</mo><msub><mi>θ</mi><mi>LL</mi></msub><mo>)</mo></mrow></mrow></mrow></mrow></mrow></math></maths>

where θ_LL* contains the optimal low level decisions and J_LLis the low level cost function. To find the optimal low level decisions θ_LL*, low level optimizer <b>634</b> may minimize the low level cost function J_LL. The low level cost function J_LLmay represent the total energy consumption for all of the equipment in the applicable subplant. The low level cost function J_LLmay be described using the following equation:

<maths id="MATH-US-00003" num="00003"><math overflow="scroll"><mrow><mrow><msub><mi>J</mi><mi>LL</mi></msub><mo></mo><mrow><mo>(</mo><msub><mi>θ</mi><mi>LL</mi></msub><mo>)</mo></mrow></mrow><mo>=</mo><mrow><munderover><mo>∑</mo><mrow><mi>j</mi><mo>=</mo><mn>1</mn></mrow><mi>N</mi></munderover><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mrow><msub><mi>t</mi><mi>s</mi></msub><mo>·</mo><msub><mi>b</mi><mi>j</mi></msub><mo>·</mo><mrow><msub><mi>u</mi><mi>j</mi></msub><mo></mo><mrow><mo>(</mo><msub><mi>θ</mi><mi>LL</mi></msub><mo>)</mo></mrow></mrow></mrow></mrow></mrow></math></maths>

where N is the number of devices in the subplant, t_sis the duration of a time step, b_jis a binary on/off decision (e.g., 0=off, 1=on), and u_jis 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 optimizer <b>634</b> may minimize the low level cost function J_LLsubject 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 optimizer <b>634</b> performs 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 optimizer <b>634</b> may determine the optimal low level decisions θ_LL* at an instance of time rather than over a long horizon.

Low level optimizer <b>634</b> may 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 optimizer <b>634</b> may also determine optimum operating setpoints for equipment using nonlinear optimization. Nonlinear optimization may identify operating setpoints that further minimize the low level cost function J_LL. Low level optimizer <b>634</b> may provide the on/off decisions and setpoints to building management system <b>606</b> for use in controlling the central plant equipment.

In some embodiments, the low level optimization performed by low level optimizer <b>634</b> is 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 to <figref idref="DRAWINGS">FIG. 8</figref>, a block diagram illustrating high level optimizer <b>632</b> in greater detail is shown, according to an exemplary embodiment. High level optimizer <b>632</b> may receive load and rate predictions from load/rate predictor <b>622</b>, incentive predictions from incentive estimator <b>620</b>, and subplant curves from low level optimizer <b>634</b>. High level optimizer <b>632</b> may determine an optimal resource allocation across central plant system <b>500</b> as 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 utilities <b>510</b>, an amount of each input and output resource of generator subplants <b>520</b>, an amount of each resource stored or withdrawn from storage subplants <b>530</b>, and/or an amount of each resource sold to energy purchasers <b>504</b>. In some embodiments, the optimal resource allocation maximizes the economic value of operating central plant system <b>500</b> while satisfying the predicted loads for the building or campus. High level optimizer <b>632</b> may output the optimal resource allocation to low level optimizer <b>634</b>.

Optimization Framework

High level optimizer <b>632</b> is shown to include an optimization framework module <b>802</b>. Optimization framework module <b>802</b> may be configured to select and/or establish an optimization framework for use in determining the optimal resource allocation. In some embodiments, optimization framework module <b>802</b> uses linear programming as the optimization framework. A linear programming problem has the following form:

<maths id="MATH-US-00004" num="00004"><math overflow="scroll"><mrow><mrow><mrow><munder><mrow><mi>arg</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>min</mi></mrow><mi>x</mi></munder><mo></mo><msup><mi>c</mi><mi>T</mi></msup><mo></mo><mi>x</mi></mrow><mo>;</mo><mrow><mrow><mi>subject</mi><mo></mo><mstyle><mspace width="0.8em" height="0.8ex" /></mstyle><mo></mo><mi>to</mi><mo></mo><mstyle><mspace width="0.8em" height="0.8ex" /></mstyle><mo></mo><mi>Ax</mi></mrow><mo>≤</mo><mi>b</mi></mrow></mrow><mo>,</mo><mrow><mi>Hx</mi><mo>=</mo><mi>g</mi></mrow></mrow></math></maths>

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 optimizer <b>632</b> to determine the optimal resource allocation. Advantageously, the linear programming framework described herein allows high level optimizer <b>632</b> to 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 optimizer <b>632</b> and should not be regarded as limiting. It should be understood that in other embodiments, high level optimizer <b>632</b> may 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 to <figref idref="DRAWINGS">FIG. 8</figref>, high level optimizer <b>632</b> is shown to include a linear program module <b>804</b>. Linear program module <b>804</b> may be configured to formulate and solve a linear optimization problem to calculate the optimal resource allocation. For example, linear program module <b>804</b> may 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 module <b>804</b> may determine an optimal decision matrix x* that minimizes the cost function c^Tx. 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 J_HL, as described with reference to <figref idref="DRAWINGS">FIG. 7</figref>.

Linear program module <b>804</b> may 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 subplant <b>522</b>, a heat recovery chiller subplant <b>523</b>, a heater subplant <b>521</b> a hot thermal energy storage subplant <b>531</b>, a cold thermal energy storage subplant <b>532</b>, and an electrical energy storage subplant <b>533</b>. 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 module <b>804</b> may 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 module <b>804</b> may add the following variables to the decision matrix x:

&lt;br /&gt;<i>x=[ . . . x</i>_sp_{<sub2>n</sub2>}_,in_{<sub2>1</sub2>}_{,1 . . . h}<i>x</i>_sp_{<sub2>n</sub2>}_,in_{<sub2>2</sub2>}_{,1 . . . h}<i>x</i>_sp_{<sub2>n</sub2>}_,out_{<sub2>1</sub2>}_{,1 . . . h}. . . ]^T

where x_sp_{<sub2>n</sub2>}_,in_{<sub2>1</sub2>}_{,1 . . . h}, x_sp_{<sub2>n</sub2>}_,in_{<sub2>2</sub2>}_{,1 . . . h}, and x_sp_{<sub2>n</sub2>}_,out_{<sub2>1</sub2>}_{,1 . . . h}are h-dimensional vectors representing amounts of the first input resource in₁, the second input resource in₂, and the first output resource out₁allocated to the nth subplant sp_nfor each of the h time steps within the optimization period. Linear program module <b>804</b> may repeat this process for each of generator subplants <b>520</b>, 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 module <b>804</b> may 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 module <b>804</b> may add the following elements to the cost vector c:

&lt;br /&gt;<i>c=[ . . . </i>000 . . . ]^T

For each type of resource allocated, linear program module <b>804</b> may generate a decision variable representing an amount of the resource stored or discharged from storage subplants <b>530</b> for 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 subplant <b>532</b> may store and discharge cold thermal energy (e.g., cold water), whereas electrical storage subplant <b>533</b> may store and discharge electrical energy. In other embodiments, multiple storage subplants <b>530</b> may store/discharge the same type of resource. In various embodiments, linear program module <b>804</b> may generate a single storage/discharge variable for each type of resource or a storage/discharge variable for each of subplants <b>530</b>, even if multiple subplants <b>530</b> store/discharge the same type of resource.

Linear program module <b>804</b> may 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 module <b>804</b> may add the following variables to the decision matrix x:

&lt;br /&gt;<i>x=[ . . . x</i>_resource_{<sub2>p</sub2>}_{,under,1 . . . h}<i>x</i>_resource_{<sub2>p</sub2>}_{,over,1 . . . h}<i>x</i>_resource_{<sub2>p</sub2>}_{,storage,1 . . . h}. . . ]^T

where x_resource_{<sub2>p</sub2>}_{,under,1 . . . h}and x_resource_{<sub2>p</sub2>}_{,over 1 . . . h}are h-dimensional vectors representing amounts of underproduction and overproduction of the pth resource for each of the h time steps within the optimization period. x_resource_{<sub2>p</sub2>}_{,storage,1 . . . h}is a h-dimensional vector representing an amount of the pth resource drawn from storage subplants <b>530</b> for each of the h time steps. The storage draw may be positive if the resource is being withdrawn from storage subplants <b>530</b> or negative if the resource is being stored in storage subplants <b>530</b>.

Decision variables representing the storage draw from subplants <b>530</b> may have no direct costs associated with them. Therefore, linear program module <b>804</b> may add a zero cost element to the cost vector c for each decision variable representing a storage draw. However, linear program module <b>804</b> may assign a high cost to decision variables representing overproduction and/or underproduction. For example, for a particular resource p, linear program module <b>804</b> may add the following elements to the cost vector c:

&lt;br /&gt;<i>c=[ . . . MM</i>0 . . . ]^T

where M is the cost assigned to overproduction and underproduction of resource p and <b>0</b> is the cost assigned to the storage draw of resource p. Advantageously, assigning a high cost to overproduction and underproduction ensures that high level optimizer <b>632</b> does 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., utilities <b>510</b>), linear program module <b>804</b> may 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 utility <b>511</b> may provide electricity, whereas natural gas utility <b>513</b> may provide natural gas. For each resource source, linear program module <b>804</b> may add the following decision variable to the decision matrix x:

&lt;br /&gt;<i>x=[ . . . x</i>_resource_{<sub2>p</sub2>}_,source_{<sub2>m</sub2>}_{,1 . . . h}. . . ]^T

where x_resource_{<sub2>p</sub2>}_,source_{<sub2>m </sub2>}is the amount of resource p purchased from source m for each of the h time steps in the optimization period. Linear program module <b>804</b> may 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 module <b>804</b> may add a non-zero cost to the cost vector c for each decision variable representing a resource purchase. For example, linear program module <b>804</b> may add the following element to the cost vector c:

&lt;br /&gt;<i>c=[ . . . c</i>_resource_{<sub2>p</sub2>}_,source_{<sub2>m</sub2>}_{,1 . . . h}. . . ]^T

where c_resource_{<sub2>p</sub2>}_,source_{<sub2>m</sub2>}_{,1 . . . h}is 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 module <b>804</b> uses the load and rate predictions to formulate the linear program. For example, linear program module <b>804</b> may 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 module <b>804</b> may use the rate predictions to determine values for the elements in cost vector c associated with resource purchases.

In some embodiments, linear program module <b>804</b> formulates the linear program for the simple case in which only resource purchase costs and over/underproduction are considered. Linear program module <b>804</b> may use inputs from inequality constraints module <b>806</b>, equality constraints module <b>808</b>, unmet loads module <b>810</b>, ground loop module <b>812</b>, heat exchanger module <b>814</b>, demand charge module <b>816</b>, tank forced full module <b>818</b>, penalty function module <b>820</b>, incentive program module <b>822</b>, battery capacity loss module <b>824</b>, and/or subplant curves module <b>830</b> to determine and set values for the various matrices and vectors in the linear program. Modules <b>806</b>-<b>830</b> may 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 modules <b>806</b>-<b>830</b> are described in greater detail below.

Linear program module <b>804</b> may use any of a variety of linear optimization techniques to solve the linear optimization problem. For example, linear program module <b>804</b> may 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 module <b>804</b> may use any of a variety of nonlinear optimization techniques to solve the nonlinear optimization problem.

Inequality Constraints

Still referring to <figref idref="DRAWINGS">FIG. 8</figref>, high level optimizer <b>632</b> is shown to include an inequality constraints module <b>806</b>. Inequality constraints module <b>806</b> may formulate or define one or more inequality constraints on the optimization problem solved by linear program module <b>804</b>. In some instances, inequality constraints module <b>806</b> defines inequality constraints on the decision variables corresponding to the loads on generator subplants <b>520</b> for each time step k within optimization period. For example, each of subplants <b>520</b> may have two capacity constraints given by the following equations:

&lt;br /&gt;<i>x</i>_sp_{<sub2>n</sub2>}<i>≦x</i>_sp_{<sub2>n</sub2>}_,max_{<sub2>1</sub2>}<i>∀k</i>εhorizon

&lt;br /&gt;<i>x</i>_sp_{<sub2>n</sub2>}≧0∀<i>k</i>εhorizon

where x_sp_{<sub2>n </sub2>}is the output of the nth subplant during time step k and x_sp_{<sub2>n</sub2>}_,max_{<sub2>1 </sub2>}is the maximum capacity of the nth subplant with respect to a first output resource. The first capacity constraint requires the output x_sp_{<sub2>n </sub2>}of the subplant to be less than or equal to the maximum capacity x_sp_{<sub2>n</sub2>}_,max_{<sub2>1 </sub2>}of the subplant for each time step k within the optimization period. The second capacity constraint requires the output x_sp_{<sub2>n </sub2>}of 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 subplant <b>520</b> may be defined by the decision variables:

&lt;br /&gt;<i>x=[ . . . x</i>_sp_{<sub2>n</sub2>}_,in_{<sub2>1</sub2>}_{,1 . . . h}<i>x</i>_sp_{<sub2>n</sub2>}_,in_{<sub2>2</sub2>}_{,1 . . . h}<i>x</i>_sp_{<sub2>n</sub2>}_,out_{<sub2>1</sub2>}_{,1 . . . h}. . . ]^T

The inequality constraints for each subplant <b>520</b> can be placed in the form Ax≦b by defining the A matrix and the b vector as follows:

<maths id="MATH-US-00005" num="00005"><math overflow="scroll"><mrow><mrow><mi>A</mi><mo>=</mo><mrow><mo>[</mo><mtable><mtr><mtd><mi>…</mi></mtd><mtd><mn>0</mn></mtd><mtd><mn>0</mn></mtd><mtd><msub><mi>I</mi><mi>h</mi></msub></mtd><mtd><mi>…</mi></mtd></mtr><mtr><mtd><mi>…</mi></mtd><mtd><mn>0</mn></mtd><mtd><mn>0</mn></mtd><mtd><mrow><mo>-</mo><msub><mi>I</mi><mi>h</mi></msub></mrow></mtd><mtd><mi>…</mi></mtd></mtr></mtable><mo>]</mo></mrow></mrow><mo>,</mo><mrow><mi>b</mi><mo>=</mo><mrow><mo>[</mo><mtable><mtr><mtd><mi>⋮</mi></mtd></mtr><mtr><mtd><msub><mi>x</mi><mrow><msub><mi>sp</mi><mi>n</mi></msub><mo>,</mo><msub><mi>max</mi><mn>1</mn></msub></mrow></msub></mtd></mtr><mtr><mtd><msub><mn>0</mn><mi>h</mi></msub></mtd></mtr><mtr><mtd><mi>⋮</mi></mtd></mtr></mtable><mo>]</mo></mrow></mrow></mrow></math></maths>

where I_hrepresents either an h by h identity matrix or an h by 1 ones vector, 0_hrepresents either an h by h zero matrix or an h by 1 zero vector, and x_sp_{<sub2>n</sub2>}_,max_{<sub2>1 </sub2>}is the maximum capacity of subplant n. Inequality constraints module <b>806</b> may formulate similar inequality constraints for each of generator subplants <b>520</b>.

Inequality constraints module <b>806</b> may formulate or define inequality constraints on the decision variables representing the draw from storage subplants <b>530</b> for each time step k within the optimization period. For example, each of subplants <b>530</b> may have two capacity constraints given by the following equations:

&lt;br /&gt;<i>x</i>_storage_{<sub2>p</sub2>}<i>≦x</i>_discharge_{<sub2>p,max</sub2>}<i>∀k</i>εhorizon

&lt;br /&gt;−<i>x</i>_storage_{<sub2>p</sub2>}<i>≦x</i>_charge_{<sub2>p,max</sub2>}<i>∀k</i>εhorizon

where x_storage_{<sub2>p </sub2>}is the rate at which the pth storage subplant is being discharged at time step k, x_discharge_{<sub2>p,max </sub2>}is the maximum discharge rate of the pth storage subplant, and x_charge_{<sub2>p,max </sub2>}is the maximum charge rate of the pth storage subplant. Positive values for x_storage_{<sub2>p </sub2>}indicate that the storage subplant is discharging and negative load values for x_storage_{<sub2>p </sub2>}indicate that the storage subplant is charging. The first capacity constraint requires the discharge rate x_storage_{<sub2>p </sub2>}for each of storage subplants <b>530</b> to be less than or equal to the maximum discharge rate x_discharge_{<sub2>p,max </sub2>}of the subplant for each time step k within the optimization period. The second capacity constraint requires the negative discharge rate −x_storage_{<sub2>p </sub2>}(i.e., the charge rate) for each of subplants <b>530</b> to be less than or equal to the maximum charge rate x_chargee_{<sub2>p,max </sub2>}of the subplant for each time step k within the optimization period. Each of storage subplants <b>530</b> may 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 subplants <b>530</b> can be placed in the form Ax≦b by defining the A matrix and the b vector as follows:

<maths id="MATH-US-00006" num="00006"><math overflow="scroll"><mrow><mrow><mi>A</mi><mo>=</mo><mrow><mo>[</mo><mtable><mtr><mtd><mi>…</mi></mtd><mtd><mn>0</mn></mtd><mtd><mn>0</mn></mtd><mtd><msub><mi>I</mi><mi>h</mi></msub></mtd><mtd><mi>…</mi></mtd></mtr><mtr><mtd><mi>…</mi></mtd><mtd><mn>0</mn></mtd><mtd><mn>0</mn></mtd><mtd><mrow><mo>-</mo><msub><mi>I</mi><mi>h</mi></msub></mrow></mtd><mtd><mi>…</mi></mtd></mtr><mtr><mtd><mi>…</mi></mtd><mtd><mn>0</mn></mtd><mtd><mn>0</mn></mtd><mtd><mrow><msub><mi>T</mi><mi>s</mi></msub><mo></mo><msub><mi>Δ</mi><mi>h</mi></msub></mrow></mtd><mtd><mi>…</mi></mtd></mtr><mtr><mtd><mi>…</mi></mtd><mtd><mn>0</mn></mtd><mtd><mn>0</mn></mtd><mtd><mrow><mrow><mo>-</mo><msub><mi>T</mi><mi>s</mi></msub></mrow><mo></mo><msub><mi>Δ</mi><mi>h</mi></msub></mrow></mtd><mtd><mi>…</mi></mtd></mtr></mtable><mo>]</mo></mrow></mrow><mo>,</mo><mrow><mi>b</mi><mo>=</mo><mrow><mo>[</mo><mtable><mtr><mtd><mi>⋮</mi></mtd></mtr><mtr><mtd><msub><mi>x</mi><msub><mi>discharge</mi><mrow><mi>p</mi><mo>,</mo><mi>max</mi></mrow></msub></msub></mtd></mtr><mtr><mtd><msub><mi>x</mi><msub><mi>charge</mi><mrow><mi>p</mi><mo>,</mo><mi>max</mi></mrow></msub></msub></mtd></mtr><mtr><mtd><msub><mi>C</mi><msub><mi>storage</mi><mrow><mi>p</mi><mo>,</mo><mn>0</mn></mrow></msub></msub></mtd></mtr><mtr><mtd><mrow><msub><mi>C</mi><msub><mi>storage</mi><mrow><mi>p</mi><mo>,</mo><mi>max</mi></mrow></msub></msub><mo>-</mo><msub><mi>C</mi><msub><mi>storage</mi><mrow><mi>p</mi><mo>,</mo><mn>0</mn></mrow></msub></msub></mrow></mtd></mtr><mtr><mtd><mi>⋮</mi></mtd></mtr></mtable><mo>]</mo></mrow></mrow></mrow></math></maths>

where C_storage_{<sub2>p,0 </sub2>}is the current state of charge of storage subplant p (e.g., at time step k=0), C_storage_{<sub2>p,max </sub2>}is the maximum storage capacity of storage subplant p, T_sis the duration of one time step, and Δ_his a lower diagonal matrix of ones. Inequality constraints module <b>806</b> may generate similar inequality constraints for each of storage subplants <b>530</b>.

Inequality constraints module <b>806</b> may generate inequality constraints that limit the maximum rate at which resources can be purchased from utilities <b>510</b>. As previously described, the decision matrix x may include variables representing the amount of each resource purchased from utilities <b>510</b>:

&lt;br /&gt;<i>x=[ . . . x</i>_resource_{<sub2>p</sub2>}_,source_{<sub2>m</sub2>}_{,1 . . . h}. . . ]^T

where x_resource_{<sub2>p</sub2>}_,source_{<sub2>m </sub2>}is the amount of resource p purchased from source m for each of the h time steps in the optimization period. Inequality constraints module <b>806</b> may 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:

<maths id="MATH-US-00007" num="00007"><math overflow="scroll"><mrow><mrow><mi>A</mi><mo>=</mo><mrow><mo>[</mo><mrow><mi>…</mi><mo></mo><mstyle><mspace width="0.8em" height="0.8ex" /></mstyle><mo></mo><msub><mi>I</mi><mi>h</mi></msub><mo></mo><mstyle><mspace width="1.1em" height="1.1ex" /></mstyle><mo></mo><mi>…</mi></mrow><mo>]</mo></mrow></mrow><mo>,</mo><mrow><mi>b</mi><mo>=</mo><mrow><mo>[</mo><mtable><mtr><mtd><mi>⋮</mi></mtd></mtr><mtr><mtd><msub><mi>x</mi><msub><mi>source</mi><mrow><mi>m</mi><mo>,</mo><mi>max</mi></mrow></msub></msub></mtd></mtr><mtr><mtd><mi>⋮</mi></mtd></mtr></mtable><mo>]</mo></mrow></mrow></mrow></math></maths>

where x_source_{<sub2>m,max </sub2>}is the maximum allowable purchase from source m.

Inequality constraints module <b>806</b> may implement an electrical demand constraint for the electric power purchased from utilities <b>510</b>. Inequality constraints module <b>806</b> may require that the electric power purchased be less than or equal to a maximum electrical demand P_elec,maxby defining the A matrix and the b vector as follows:

<maths id="MATH-US-00008" num="00008"><math overflow="scroll"><mrow><mrow><mi>A</mi><mo>=</mo><mrow><mo>[</mo><mrow><mi>…</mi><mo></mo><mstyle><mspace width="0.8em" height="0.8ex" /></mstyle><mo></mo><msub><mi>x</mi><mi>elec</mi></msub><mo></mo><msub><mi>I</mi><mi>h</mi></msub><mo></mo><mstyle><mspace width="1.1em" height="1.1ex" /></mstyle><mo></mo><mi>…</mi></mrow><mo>]</mo></mrow></mrow><mo>,</mo><mrow><mi>b</mi><mo>=</mo><mrow><mo>[</mo><mtable><mtr><mtd><mi>⋮</mi></mtd></mtr><mtr><mtd><mrow><msub><mi>P</mi><mrow><mi>elec</mi><mo>,</mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>max</mi></mrow></msub><mo></mo><msub><mi>I</mi><mi>h</mi></msub></mrow></mtd></mtr><mtr><mtd><mi>⋮</mi></mtd></mtr></mtable><mo>]</mo></mrow></mrow></mrow></math></maths>

where x_elecrepresents the electricity purchased from utilities <b>510</b> and P_elec,maxis the maximum electrical demand for the central plant system.

Equality Constraints

Still referring to <figref idref="DRAWINGS">FIG. 8</figref>, high level optimizer <b>632</b> is shown to include an equality constraints module <b>808</b>. Equality constraints module <b>808</b> may formulate or define one or more equality constraints on the optimization problem solved by linear program module <b>804</b>. 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 module <b>808</b> may 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:

<maths id="MATH-US-00009" num="00009"><math overflow="scroll"><mrow><mrow><munderover><mo>∑</mo><mrow><mi>i</mi><mo>=</mo><mn>1</mn></mrow><msub><mi>n</mi><mi>s</mi></msub></munderover><mo></mo><msub><mi>x</mi><mrow><mi>p</mi><mo>,</mo><mi>i</mi><mo>,</mo><mi>k</mi></mrow></msub></mrow><mo>=</mo><mrow><msub><mover><mi></mi><mo>^</mo></mover><mrow><mi>p</mi><mo>,</mo><mi>k</mi></mrow></msub><mo></mo><mrow><mo>∀</mo><mrow><mi>k</mi><mo>∈</mo><mi>horizon</mi></mrow></mrow></mrow></mrow></math></maths>

where x_p,i,kis the resource output of type p (e.g., hot water, cold water, etc.) by the ith subplant during time step k, n_sis the total number of subplants capable of outputting resource p, and {circumflex over (l)}_p,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 predictor <b>622</b>.

In some embodiments, the predicted resource demands include a predicted hot water thermal energy load {circumflex over (l)}_Hot,k, a predicted cold water thermal energy load {circumflex over (l)}_Cold,k,and a predicted electricity load {circumflex over (l)}_Elec,kfor each time step k. The predicted hot water thermal energy load {circumflex over (l)}_Hot,kmay be satisfied by the combination of heater subplant <b>521</b>, heat recovery chiller subplant <b>523</b>, and hot TES subplant <b>532</b>. The predicted cold water thermal energy load {circumflex over (l)}_Cold,kmay be satisfied by the combination of chiller subplant <b>522</b>, heat recovery chiller subplant <b>523</b>, and cold TES subplant <b>532</b>. The predicted electricity load {circumflex over (l)}_Elec,kmay include the electric demand of the building and may be satisfied by the combination of electricity subplant <b>525</b>, electric utility <b>511</b>, and electrical energy storage subplant <b>533</b>. Electricity sold to energy purchasers <b>504</b> and electricity consumed by generator subplants <b>520</b> may add to the predicted electricity load {circumflex over (l)}_Elec,k.

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

<maths id="MATH-US-00010" num="00010"><math overflow="scroll"><mrow><mrow><mi>H</mi><mo>=</mo><mrow><mo>[</mo><mtable><mtr><mtd><msub><mi>I</mi><mi>h</mi></msub></mtd><mtd><mrow><mo>-</mo><msub><mi>I</mi><mi>h</mi></msub></mrow></mtd><mtd><msub><mn>0</mn><mi>h</mi></msub></mtd><mtd><msub><mn>0</mn><mi>h</mi></msub></mtd></mtr><mtr><mtd><msub><mi>I</mi><mi>h</mi></msub></mtd><mtd><mrow><mo>-</mo><msub><mi>I</mi><mi>h</mi></msub></mrow></mtd><mtd><msub><mn>0</mn><mi>h</mi></msub></mtd><mtd><msub><mn>0</mn><mi>h</mi></msub></mtd></mtr><mtr><mtd><msub><mi>I</mi><mi>h</mi></msub></mtd><mtd><mrow><mo>-</mo><msub><mi>I</mi><mi>h</mi></msub></mrow></mtd><mtd><msub><mi>I</mi><mi>h</mi></msub></mtd><mtd><mrow><mo>-</mo><msub><mi>I</mi><mi>h</mi></msub></mrow></mtd></mtr></mtable><mo>]</mo></mrow></mrow><mo>,</mo><mrow><mi>g</mi><mo>=</mo><mrow><mo>[</mo><mtable><mtr><mtd><msub><mover><mi></mi><mo>^</mo></mover><mrow><mi>Cold</mi><mo>,</mo><mrow><mn>1</mn><mo></mo><mi>…</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>h</mi></mrow></mrow></msub></mtd></mtr><mtr><mtd><msub><mover><mi></mi><mo>^</mo></mover><mrow><mi>Hot</mi><mo>,</mo><mrow><mn>1</mn><mo></mo><mi>…</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>h</mi></mrow></mrow></msub></mtd></mtr><mtr><mtd><msub><mover><mi></mi><mo>^</mo></mover><mrow><mi>Elec</mi><mo>,</mo><mrow><mn>1</mn><mo></mo><mi>…</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>h</mi></mrow></mrow></msub></mtd></mtr></mtable><mo>]</mo></mrow></mrow></mrow></math></maths>

where {circumflex over (l)}_{Cold,1 . . . h}, {circumflex over (l)}_{Hot,1 . . . h}, and {circumflex over (l)}_{Elec,1 . . . h}are 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 subplants <b>520</b>-<b>530</b>. The second column of the H matrix applies to any input of the corresponding resource (i.e., consumption consumption) by subplants <b>520</b>-<b>530</b>. The third column of the H matrix applies to any purchase of the corresponding resource from utilities <b>510</b>. The fourth column of the H matrix applies to any sale of the corresponding resource to energy purchasers <b>504</b>. 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 module <b>808</b> augments 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 subplant <b>522</b> may 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 module <b>808</b> may augment the H matrix and the g vector as follows:

<maths id="MATH-US-00011" num="00011"><math overflow="scroll"><mrow><mrow><mi>H</mi><mo>=</mo><mrow><mo>[</mo><mtable><mtr><mtd><mi>…</mi></mtd><mtd><mrow><mn>6.67</mn><mo></mo><msub><mi>I</mi><mi>h</mi></msub></mrow></mtd><mtd><msub><mn>0</mn><mi>h</mi></msub></mtd><mtd><mrow><mo>-</mo><msub><mi>I</mi><mi>h</mi></msub></mrow></mtd></mtr><mtr><mtd><mi>…</mi></mtd><mtd><msub><mn>0</mn><mi>h</mi></msub></mtd><mtd><mrow><mn>2</mn><mo></mo><msub><mi>I</mi><mi>h</mi></msub></mrow></mtd><mtd><mrow><mo>-</mo><msub><mi>I</mi><mi>h</mi></msub></mrow></mtd></mtr></mtable><mo>]</mo></mrow></mrow><mo>,</mo><mrow><mi>g</mi><mo>=</mo><mrow><mo>[</mo><mtable><mtr><mtd><msub><mn>0</mn><mi>h</mi></msub></mtd></mtr><mtr><mtd><msub><mn>0</mn><mi>h</mi></msub></mtd></mtr></mtable><mo>]</mo></mrow></mrow></mrow></math></maths>

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 module <b>830</b>.

Unmet Load Incorporation

Still referring to <figref idref="DRAWINGS">FIG. 8</figref>, high level optimizer <b>632</b> is shown to include an unmet loads module <b>810</b>. 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 module <b>810</b> may 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 module <b>810</b> modifies 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 module <b>810</b> may modify the decision variable matrix x as follows:

&lt;br /&gt;<i>x=[ . . . x</i>_{ColdUnmet,1 . . . h}<i>x</i>_{HotUnmet,1 . . . h}<i>x</i>_{ElecUnmet,1 . . . h}]^T

where x_{ColdUnmet,1 . . . h}, x_{HotUnmet1 . . . h}, and x_{ElecUnmet,1 . . . h}are 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 x_{ColdUnmet,1 . . . h}, x_{HotUnmet1 . . . h}, and x_{ElecUnmet,1 . . . n}represent 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 module <b>810</b> may 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 subplants <b>520</b>-<b>530</b> plus 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:

<maths id="MATH-US-00012" num="00012"><math overflow="scroll"><mrow><mrow><mi>H</mi><mo>=</mo><mrow><mo>[</mo><mtable><mtr><mtd><msub><mi>I</mi><mi>h</mi></msub></mtd><mtd><mrow><mo>-</mo><msub><mi>I</mi><mi>h</mi></msub></mrow></mtd><mtd><msub><mn>0</mn><mi>h</mi></msub></mtd><mtd><msub><mn>0</mn><mi>h</mi></msub></mtd><mtd><mrow><msub><mi>I</mi><mi>h</mi></msub><mo>-</mo><msub><mi>D</mi><mrow><mo>-</mo><mn>1</mn></mrow></msub></mrow></mtd><mtd><msub><mn>0</mn><mi>h</mi></msub></mtd><mtd><msub><mn>0</mn><mi>h</mi></msub></mtd></mtr><mtr><mtd><msub><mi>I</mi><mi>h</mi></msub></mtd><mtd><mrow><mo>-</mo><msub><mi>I</mi><mi>h</mi></msub></mrow></mtd><mtd><msub><mn>0</mn><mi>h</mi></msub></mtd><mtd><msub><mn>0</mn><mi>h</mi></msub></mtd><mtd><msub><mn>0</mn><mi>h</mi></msub></mtd><mtd><mrow><msub><mi>I</mi><mi>h</mi></msub><mo>-</mo><msub><mi>D</mi><mrow><mo>-</mo><mn>1</mn></mrow></msub></mrow></mtd><mtd><msub><mn>0</mn><mi>h</mi></msub></mtd></mtr><mtr><mtd><msub><mi>I</mi><mi>h</mi></msub></mtd><mtd><mrow><mo>-</mo><msub><mi>I</mi><mi>h</mi></msub></mrow></mtd><mtd><msub><mi>I</mi><mi>h</mi></msub></mtd><mtd><mrow><mo>-</mo><msub><mi>I</mi><mi>h</mi></msub></mrow></mtd><mtd><msub><mn>0</mn><mi>h</mi></msub></mtd><mtd><msub><mn>0</mn><mi>h</mi></msub></mtd><mtd><mrow><msub><mi>I</mi><mi>h</mi></msub><mo>-</mo><msub><mi>D</mi><mrow><mo>-</mo><mn>1</mn></mrow></msub></mrow></mtd></mtr></mtable><mo>]</mo></mrow></mrow><mo>,</mo><mstyle><mtext></mtext></mstyle><mo></mo><mrow><mi>g</mi><mo>=</mo><mrow><mo>[</mo><mtable><mtr><mtd><msub><mover><mi></mi><mo>^</mo></mover><mrow><mi>Cold</mi><mo>,</mo><mrow><mn>1</mn><mo></mo><mi>…</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>h</mi></mrow></mrow></msub></mtd></mtr><mtr><mtd><msub><mover><mi></mi><mo>^</mo></mover><mrow><mi>Hot</mi><mo>,</mo><mrow><mn>1</mn><mo></mo><mi>…</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>h</mi></mrow></mrow></msub></mtd></mtr><mtr><mtd><msub><mover><mi></mi><mo>^</mo></mover><mrow><mi>Elec</mi><mo>,</mo><mrow><mn>1</mn><mo></mo><mi>…</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>h</mi></mrow></mrow></msub></mtd></mtr></mtable><mo>]</mo></mrow></mrow></mrow></math></maths>

where D₋₁is a lower diagonal matrix of ones.

Unmet loads module <b>810</b> may modify the cost vector c to associate cost values with any unmet loads. In some embodiments, unmet loads module <b>810</b> assigns 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 module <b>804</b> may avoid using unmet loads if any feasible combination of equipment is capable of satisfying the predicted thermal energy loads. In some embodiments, unmet loads module <b>810</b> assigns a cost value to unmet loads that allows linear program module <b>804</b> to 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 module <b>810</b> may assign a cost value that allows linear program module <b>804</b> to use unmet loads if the solution without unmet loads would be prohibitively expensive and/or highly inefficient.

Subplant Curve Incorporation

Still referring to <figref idref="DRAWINGS">FIG. 8</figref>, high level optimizer <b>632</b> is shown to include a subplant curves module <b>830</b>. In the simplest case described with reference to linear program module <b>804</b>, 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 module <b>830</b> may 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 module <b>830</b> is shown to include a subplant curve updater <b>832</b>, a subplant curves database <b>834</b>, a subplant curve linearizer <b>836</b>, and a subplant curves incorporator <b>838</b>. Subplant curve updater <b>832</b> may be configured to request subplant curves for each of subplants <b>520</b>-<b>530</b> from low level optimizer <b>634</b>. 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 to <figref idref="DRAWINGS">FIGS. 9A-12</figref>.

In some embodiments, low level optimizer <b>634</b> generates 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 optimizer <b>634</b> may fit a curve to the data points to generate the subplant curves and provide the subplant curves to subplant curve updater <b>832</b>. In other embodiments, low level optimizer <b>634</b> provides the data points to subplant curve updater <b>832</b> and subplant curve updater <b>832</b> generates the subplant curves using the data points. Subplant curve updater <b>832</b> may store the subplant curves in subplant curves database <b>834</b> for 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 models <b>618</b>. 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 in <figref idref="DRAWINGS">FIG. 10</figref>. 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 linearizer <b>836</b> may 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 linearizer <b>836</b> may be configured to break the subplant curves into piecewise linear segments that combine to form a piecewise-defined convex curve. An unmodified subplant curve <b>1000</b> and a linearized subplant curve <b>1100</b> generated by subplant curve linearizer <b>836</b> are shown in <figref idref="DRAWINGS">FIGS. 10 and 11</figref>, respectively. Subplant curve linearizer <b>836</b> may store the linearized subplant curves in subplant curves database <b>834</b>.

Still referring to <figref idref="DRAWINGS">FIG. 8</figref>, subplant curves module <b>830</b> is shown to include a subplant curve incorporator <b>838</b>. Subplant curve incorporator <b>838</b> may be configured to modify the high level optimization problem to incorporate the subplant curves into the optimization. In some embodiments, subplant curve incorporator <b>838</b> modifies 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 module <b>804</b> to include the input resources and the output resources of each subplant, as shown in the following equation:

&lt;br /&gt;<i>x=[ . . . x</i>_sp_{<sub2>n</sub2>}_,in_{<sub2>1</sub2>}_{,1 . . . h}<i>x</i>_sp_{<sub2>n</sub2>}_,in_{<sub2>2</sub2>}_{,1 . . . h}<i>x</i>_sp_{<sub2>n</sub2>}_,out_{<sub2>1</sub2>}_{,1 . . . h}. . . ]^T

Subplant curve incorporator <b>838</b> may 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 incorporator <b>838</b> formulates inequality constraints that force the resource usage for each resource in the epigraph of the corresponding linearized subplant curve. For example, chiller subplant <b>522</b> may have a linearized subplant curve that indicates the electricity use of chiller subplant <b>522</b> (i.e., input resource in₁) as a function of the cold water production of chiller subplant <b>522</b> (i.e., output resource out₁). Such a linearized subplant curve <b>1100</b> is shown in <figref idref="DRAWINGS">FIG. 11</figref>. The linearized subplant curve may include a first line segment connecting point [u₁, Q₁] to point [u₂, Q₂], a second line segment connecting point [u₂, Q₂] to point [u₃, Q₃], and a third line segment connecting point [u₃, Q₃] to point [u₄, Q₄].

Subplant curve incorporator <b>838</b> may 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 subplant <b>522</b> can be placed in the form Ax≦b by defining the A matrix and the b vector as follows:

<maths id="MATH-US-00013" num="00013"><math overflow="scroll"><mrow><mrow><mi>A</mi><mo>=</mo><mrow><mo>[</mo><mtable><mtr><mtd><mi>…</mi></mtd><mtd><mrow><mrow><mo>[</mo><mrow><mo>-</mo><mrow><mo>(</mo><mrow><msub><mi>u</mi><mn>2</mn></msub><mo>-</mo><msub><mi>u</mi><mn>1</mn></msub></mrow><mo>)</mo></mrow></mrow><mo>]</mo></mrow><mo></mo><msub><mi>I</mi><mi>n</mi></msub></mrow></mtd><mtd><mi>…</mi></mtd><mtd><mrow><mrow><mo>[</mo><mrow><mo>(</mo><mrow><msub><mi>Q</mi><mn>2</mn></msub><mo>-</mo><msub><mi>Q</mi><mn>1</mn></msub></mrow><mo>)</mo></mrow><mo>]</mo></mrow><mo></mo><msub><mi>I</mi><mi>n</mi></msub></mrow></mtd><mtd><msub><mn>0</mn><mi>n</mi></msub></mtd><mtd><mi>…</mi></mtd></mtr><mtr><mtd><mi>…</mi></mtd><mtd><mrow><mrow><mo>[</mo><mrow><mo>-</mo><mrow><mo>(</mo><mrow><msub><mi>u</mi><mn>3</mn></msub><mo>-</mo><msub><mi>u</mi><mn>2</mn></msub></mrow><mo>)</mo></mrow></mrow><mo>]</mo></mrow><mo></mo><msub><mi>I</mi><mi>n</mi></msub></mrow></mtd><mtd><mi>…</mi></mtd><mtd><mrow><mrow><mo>[</mo><mrow><mo>(</mo><mrow><msub><mi>Q</mi><mn>3</mn></msub><mo>-</mo><msub><mi>Q</mi><mn>2</mn></msub></mrow><mo>)</mo></mrow><mo>]</mo></mrow><mo></mo><msub><mi>I</mi><mi>n</mi></msub></mrow></mtd><mtd><msub><mn>0</mn><mi>n</mi></msub></mtd><mtd><mi>…</mi></mtd></mtr><mtr><mtd><mi>…</mi></mtd><mtd><mrow><mrow><mo>[</mo><mrow><mo>-</mo><mrow><mo>(</mo><mrow><msub><mi>u</mi><mn>4</mn></msub><mo>-</mo><msub><mi>u</mi><mn>3</mn></msub></mrow><mo>)</mo></mrow></mrow><mo>]</mo></mrow><mo></mo><msub><mi>I</mi><mi>n</mi></msub></mrow></mtd><mtd><mi>…</mi></mtd><mtd><mrow><mrow><mo>[</mo><mrow><mo>(</mo><mrow><msub><mi>Q</mi><mn>4</mn></msub><mo>-</mo><msub><mi>Q</mi><mn>3</mn></msub></mrow><mo>)</mo></mrow><mo>]</mo></mrow><mo></mo><msub><mi>I</mi><mi>n</mi></msub></mrow></mtd><mtd><msub><mn>0</mn><mi>n</mi></msub></mtd><mtd><mi>…</mi></mtd></mtr></mtable><mo>]</mo></mrow></mrow><mo>,</mo><mstyle><mtext></mtext></mstyle><mo></mo><mrow><mi>b</mi><mo>=</mo><mrow><mo>[</mo><mtable><mtr><mtd><mrow><mrow><msub><mi>Q</mi><mn>1</mn></msub><mo></mo><msub><mi>u</mi><mn>2</mn></msub></mrow><mo>-</mo><mrow><msub><mi>Q</mi><mn>2</mn></msub><mo></mo><msub><mi>u</mi><mn>1</mn></msub></mrow></mrow></mtd></mtr><mtr><mtd><mrow><mrow><msub><mi>Q</mi><mn>2</mn></msub><mo></mo><msub><mi>u</mi><mn>3</mn></msub></mrow><mo>-</mo><mrow><msub><mi>Q</mi><mn>3</mn></msub><mo></mo><msub><mi>u</mi><mn>2</mn></msub></mrow></mrow></mtd></mtr><mtr><mtd><mrow><mrow><msub><mi>Q</mi><mn>3</mn></msub><mo></mo><msub><mi>u</mi><mn>4</mn></msub></mrow><mo>-</mo><mrow><msub><mi>Q</mi><mn>4</mn></msub><mo></mo><msub><mi>u</mi><mn>3</mn></msub></mrow></mrow></mtd></mtr></mtable><mo>]</mo></mrow></mrow></mrow></math></maths>

Similar inequality constraints can be formulated for other subplant curves. For example, subplant curve incorporator <b>838</b> may generate a set of inequality constraints for the water consumption of chiller subplant <b>522</b> using the points defining the linearized subplant curve for the water consumption of chiller subplant <b>522</b> as a function of cold water production. In some embodiments, the water consumption of chiller subplant <b>522</b> is equal to the cold water production and the linearized subplant curve for water consumption includes a single line segment connecting point [u₅, Q₅] to point [u₆, Q₆] (as shown in <figref idref="DRAWINGS">FIG. 9B</figref>). The subplant curve constraints for the cold water consumption of chiller subplant <b>522</b> can be placed in the form Ax≦b by defining the A matrix and the b vector as follows:

&lt;br /&gt;<i>A</i>=[ . . . [−(<i>u</i>₆<i>−u</i>₅)]<i>I</i>_n. . . 0_n[(<i>Q</i>₆<i>−Q</i>₅)]<i>I</i>_n<i>. . . ],b=[Q</i>₅<i>u</i>₆<i>−Q</i>₆<i>u</i>₅]

Subplant curve incorporator <b>838</b> may repeat this process for each subplant curve for chiller subplant <b>522</b> and 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 incorporator <b>838</b> ensure that high level optimizer <b>632</b> keeps the resource consumption above all of the line segments of the corresponding subplant curve. In most situations, there is no reason for high level optimizer <b>632</b> to choose a resource consumption value that lies above the corresponding subplant curve due to the economic cost associated with resource consumption. High level optimizer <b>632</b> can 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 subplant <b>523</b>. The equality constraints for heat recovery chiller subplant <b>523</b> provide that heat recovery chiller subplant <b>523</b> produces 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 incorporator <b>838</b> for heat recovery chiller subplant <b>523</b> allow high level optimizer <b>632</b> to 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 subplant <b>523</b> actually operates.

To prevent high level optimizer <b>632</b> from overusing electricity, subplant curve incorporator <b>838</b> may check whether the calculated amount of electricity use (determined by the optimization algorithm) for heat recovery chiller subplant <b>523</b> is 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 subplant <b>523</b> is above the subplant curve, subplant curve incorporator <b>838</b> may determine that high level optimizer <b>632</b> is overusing electricity. In response to a determination that high level optimizer <b>632</b> is overusing electricity, subplant curve incorporator <b>838</b> may constrain the production of heat recovery chiller subplant <b>523</b> at its current value and constrain the electricity use of subplant <b>523</b> to the corresponding value on the subplant curve. High level optimizer <b>632</b> may then rerun the optimization with the new equality constraints.

Ground Loop and Heat Exchanger Incorporation

Still referring to <figref idref="DRAWINGS">FIG. 8</figref>, high level optimizer <b>632</b> is shown to include a ground loop module <b>812</b> and a heat exchanger module <b>814</b>. 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 subplant <b>522</b> and/or heat extraction for heat recovery chiller subplant <b>523</b>. Ground loop module <b>812</b> and heat exchanger module <b>814</b> may 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 module <b>812</b> may incorporate heat rejection to the ground loop into the optimization problem by changing the amount of electricity and water usage by chiller subplant <b>522</b>. For example, for loadings up to the heat rejection capacity of the ground loop, chiller subplant <b>522</b> may 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 subplant <b>522</b> may be constant regardless of whether the ground loop is used.

Ground loop module <b>812</b> and heat exchanger module <b>814</b> may 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 module <b>812</b> and heat exchanger module <b>814</b> may 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 module <b>812</b> may use the ground loop to create what appears as a false building load to the equipment, thereby allowing heat recovery chiller subplant <b>523</b> to 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 subplant <b>521</b>.

Heat exchanger module <b>814</b> may use the heat exchanger to create what appears to be a false hot water building load, thereby allowing heat recovery chiller subplant <b>523</b> to operate as conventional chillers. The excess heat from heat recovery chiller subplant <b>523</b> may be transferred through the heat exchanger to the condenser loop and ultimately into the atmosphere or into the ground. In some embodiments, heat exchanger module <b>814</b> operates the heat exchanger to prevent condenser loop from becoming overloaded. For example, heat exchanger module <b>814</b> may limit the total heat rejected to the capacity of the condenser loop minus the heat produced by the conventional chillers.

Ground loop module <b>812</b> and heat exchanger module <b>814</b> may 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 module <b>812</b> and heat exchanger module <b>814</b> may 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 subplants <b>520</b>-<b>530</b> plus any unsatisfied thermal energy loads. Ground loop module <b>812</b> and heat exchanger module <b>814</b> may 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 to <figref idref="DRAWINGS">FIG. 8</figref>, high level optimizer <b>632</b> is shown to include a demand charge module <b>816</b>. As discussed above, optimization framework module <b>802</b> may formulate the optimization problem as:

<maths id="MATH-US-00014" num="00014"><math overflow="scroll"><mrow><mrow><mrow><munder><mrow><mi>arg</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>min</mi></mrow><mi>x</mi></munder><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><msup><mi>c</mi><mi>T</mi></msup><mo></mo><mi>x</mi></mrow><mo>;</mo><mrow><mrow><mi>subject</mi><mo></mo><mstyle><mspace width="0.8em" height="0.8ex" /></mstyle><mo></mo><mi>to</mi><mo></mo><mstyle><mspace width="0.8em" height="0.8ex" /></mstyle><mo></mo><mi>Ax</mi></mrow><mo>≤</mo><mi>b</mi></mrow></mrow><mo>,</mo><mrow><mi>Hx</mi><mo>=</mo><mi>g</mi></mrow></mrow></math></maths>

However, such a formulation may not account for the demand charge.

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 module <b>816</b> may 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 controller <b>506</b>. In various implementations, the savings provided by demand charge module <b>816</b> and/or central plant controller <b>506</b> as 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 module <b>816</b> may account for the demand charge by modifying the cost function used by high level optimizer <b>632</b>. The modified cost function may be defined as:

<maths id="MATH-US-00015" num="00015"><math overflow="scroll"><mrow><mrow><munder><mi>argmin</mi><mi>x</mi></munder><mo></mo><mrow><mo>[</mo><mrow><mrow><msup><mi>c</mi><mi>T</mi></msup><mo></mo><mi>x</mi></mrow><mo>+</mo><mrow><msub><mi>c</mi><mi>demand</mi></msub><mo></mo><mrow><mi>max</mi><mo></mo><mrow><mo>(</mo><msub><mi>P</mi><mrow><mi>elec</mi><mo>,</mo><mi>k</mi></mrow></msub><mo>)</mo></mrow></mrow></mrow></mrow><mo>]</mo></mrow></mrow><mo>;</mo><mrow><mi>subject</mi><mo></mo><mstyle><mspace width="0.8em" height="0.8ex" /></mstyle><mo></mo><mi>to</mi></mrow></mrow></math></maths><maths id="MATH-US-00015-2" num="00015.2"><math overflow="scroll"><mrow><mrow><mi>Ax</mi><mo>≤</mo><mi>b</mi></mrow><mo>,</mo><mrow><mi>Hx</mi><mo>=</mo><mi>g</mi></mrow></mrow></math></maths>

where c_demandis the demand charge (e.g., $/kW) for the applicable demand charge period and P_elec,kis the total electrical power purchased from utilities <b>510</b> at time step k. The term max(P_elec,k) selects the peak electrical power at any time during the demand charge period. The demand charge c_demandand the demand charge period may be defined by the utility rate information received from utilities <b>510</b> and may be provided to high level optimizer <b>632</b> by load/rate predictor <b>622</b>.

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 c^Tx calculates cost over a consumption period defined by a time horizon, whereas the demand charge term c_demandmax(P_elec,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 utilities <b>510</b> and provided to high level optimizer <b>632</b> along 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 module <b>816</b> may modify the optimization problem to incorporate the demand charge term into the linear optimization framework. For example, demand charge module <b>816</b> may modify the decision matrix x by adding a new decision variable x_peakas follows:

&lt;br /&gt;<i>x</i>_new<i>=[ . . . x</i>_{elec,1 . . . h}<i>. . . x</i>_peak]^T

where x_peakis the peak electricity within the demand charge period and x_{elec,1 . . . h}is the electricity purchase at each of the h time steps. Demand charge module <b>816</b> may modify the cost vector c as follows:

&lt;br /&gt;<i>c</i>_new<i>=[ . . . c</i>_{elec,1 . . . h}<i>. . . c</i>_demand]^T

such that the demand charge c_demandis multiplied by the peak power consumption x_peak.

Demand charge module <b>816</b> may formulate and/or apply inequality constraints to ensure that the peak power consumption x_peakis greater than or equal to the maximum electric demand over the demand charge period. I.e.:

&lt;br /&gt;<i>x</i>_peak≧max(<i>x</i>_elec,k)∀<i>k</i>εhorizon

This inequality constraint may be represented in the linear optimization framework by defining the A matrix and the b vector as follows:

&lt;br /&gt;<i>A=[ . . . I</i>_n. . . −1],<i>b=</i>0

During the high level optimization process, high level optimizer <b>632</b> may choose a x_peakthat is equal to the maximum electrical demand over the demand charge period to minimize the cost associated with x_peak.

Demand charge module <b>816</b> may apply an inequality constraint to ensure that the peak power consumption decision variable x_peakis greater than or equal to its previous value x_{peak,previous}during 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:

&lt;br /&gt;<i>A=[ . . . −</i>1],<i>b=−x</i>_{peak,previous}

Advantageously, the modifications to the decision variable matrix x, the cost vector c, and the inequality constraints provided by demand charge module <b>816</b> allow the cost function to be written in a linear form as follows:

<maths id="MATH-US-00016" num="00016"><math overflow="scroll"><mrow><mrow><mrow><munder><mrow><mi>arg</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>min</mi></mrow><mi>x</mi></munder><mo></mo><mrow><mo>[</mo><mrow><msubsup><mi>c</mi><mi>new</mi><mi>T</mi></msubsup><mo></mo><msub><mi>x</mi><mi>new</mi></msub></mrow><mo>]</mo></mrow></mrow><mo>=</mo><mrow><munder><mrow><mi>arg</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>min</mi></mrow><mi>x</mi></munder><mo></mo><mrow><mo>[</mo><mrow><mrow><msup><mi>c</mi><mi>T</mi></msup><mo></mo><mi>x</mi></mrow><mo>+</mo><mrow><msub><mi>c</mi><mi>demand</mi></msub><mo></mo><msub><mi>x</mi><mi>peak</mi></msub></mrow></mrow><mo>]</mo></mrow></mrow></mrow><mo>;</mo></mrow></math></maths><maths id="MATH-US-00016-2" num="00016.2"><math overflow="scroll"><mrow><mrow><mrow><mi>subject</mi><mo></mo><mstyle><mspace width="0.8em" height="0.8ex" /></mstyle><mo></mo><mi>to</mi><mo></mo><mstyle><mspace width="0.8em" height="0.8ex" /></mstyle><mo></mo><mi>Ax</mi></mrow><mo>≤</mo><mi>b</mi></mrow><mo>,</mo><mrow><mi>Hx</mi><mo>=</mo><mi>g</mi></mrow></mrow></math></maths>

This linear form of the cost function can be used in the linear optimization framework.

The cost function as written in the previous equation has components that are over different time periods. For example, the consumption term c^Tx is over the consumption period whereas the demand charge term c_demandx_peakis 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 module <b>816</b> may apply a weighting factor to the demand charge term and/or the consumption term. For example, demand charge module <b>816</b> may divide the consumption term c^Tx 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 d_demandremaining 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:

<maths id="MATH-US-00017" num="00017"><math overflow="scroll"><mrow><mrow><munder><mrow><mi>arg</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>min</mi></mrow><mi>x</mi></munder><mo></mo><mrow><mo>[</mo><mrow><mrow><mfrac><msub><mi>d</mi><mi>demand</mi></msub><mi>h</mi></mfrac><mo></mo><msup><mi>c</mi><mi>T</mi></msup><mo></mo><mi>x</mi></mrow><mo>+</mo><mrow><msub><mi>c</mi><mi>demand</mi></msub><mo></mo><msub><mi>x</mi><mi>peak</mi></msub></mrow></mrow><mo>]</mo></mrow></mrow><mo>;</mo></mrow></math></maths><maths id="MATH-US-00017-2" num="00017.2"><math overflow="scroll"><mrow><mrow><mrow><mi>subject</mi><mo></mo><mstyle><mspace width="0.8em" height="0.8ex" /></mstyle><mo></mo><mi>to</mi><mo></mo><mstyle><mspace width="0.8em" height="0.8ex" /></mstyle><mo></mo><mi>Ax</mi></mrow><mo>≤</mo><mi>b</mi></mrow><mo>,</mo><mrow><mi>Hx</mi><mo>=</mo><mi>g</mi></mrow></mrow></math></maths>

which is equivalent to:

<maths id="MATH-US-00018" num="00018"><math overflow="scroll"><mrow><mrow><munder><mrow><mi>arg</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>min</mi></mrow><mi>x</mi></munder><mo></mo><mrow><mo>[</mo><mrow><mrow><msup><mi>c</mi><mi>T</mi></msup><mo></mo><mi>x</mi></mrow><mo>+</mo><mrow><mfrac><mi>h</mi><msub><mi>d</mi><mi>demand</mi></msub></mfrac><mo></mo><msub><mi>c</mi><mi>demand</mi></msub><mo></mo><msub><mi>x</mi><mi>peak</mi></msub></mrow></mrow><mo>]</mo></mrow></mrow><mo>;</mo></mrow></math></maths><maths id="MATH-US-00018-2" num="00018.2"><math overflow="scroll"><mrow><mrow><mrow><mi>subject</mi><mo></mo><mstyle><mspace width="0.8em" height="0.8ex" /></mstyle><mo></mo><mi>to</mi><mo></mo><mstyle><mspace width="0.8em" height="0.8ex" /></mstyle><mo></mo><mi>Ax</mi></mrow><mo>≤</mo><mi>b</mi></mrow><mo>,</mo><mrow><mi>Hx</mi><mo>=</mo><mi>g</mi></mrow></mrow></math></maths>

The latter form of the new optimization function has the advantage of adjusting only one term of the function rather than several.

Tank Forced Full Incorporation

Still referring to <figref idref="DRAWINGS">FIG. 8</figref>, high level optimizer <b>632</b> is shown to include a tank forced full module <b>818</b>. Tank forced full module <b>818</b> may 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 controller <b>506</b> is brought back online.

Tank forced full module <b>818</b> may force the TES tanks to full by increasing the cost of discharging the TES tanks. In some embodiments, tank forced full module <b>818</b> modifies 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 optimizer <b>632</b> to take the benefit (i.e., negative cost) of charging the TES tanks to their maximum values.

Penalty Incorporation

Still referring to <figref idref="DRAWINGS">FIG. 8</figref>, high level optimizer <b>632</b> is shown to include a penalty function module <b>820</b>. In some instances, high level optimizer <b>632</b> determines a solution to the optimization problem that includes significantly changing the load on one or more of subplants <b>520</b>-<b>530</b> within 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 optimizer <b>632</b> identifying 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 module <b>820</b> may 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 optimizer <b>632</b> seeks 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:

&lt;br /&gt;$Penalty=<i>f</i>(<i>N</i>_commands)

where N_commandsis 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 module <b>820</b> modifies the optimization problem to introduce a penalty for rapidly changing the subplant loads. For example, penalty function module <b>820</b> may 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 module <b>820</b> may modify the decision matrix x as follows:

&lt;br /&gt;<i>x=[ . . . δ</i>_sp_{<sub2>1</sub2>}_{,1 . . . h}δ_sp_{<sub2>2</sub2>}_{,1 . . . h}. . . δ_sp_{<sub2>n</sub2>}_{,1 . . . h}]^T

where δ_sp_{<sub2>1</sub2>}_{,1 . . . h}, δ_sp_{<sub2>2</sub2>}_{,1 . . . h}, and δ_sp_{<sub2>n</sub2>}_{,1 . . . h}are 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 δ_sp_{<sub2>1</sub2>}_,kmay be defined as the difference between the decision variable x_sp_{<sub2>1</sub2>}_,out_{<sub2>1</sub2>}_,krepresenting the first output out₁from subplant sp₁at time k and the decision variable x_sp_{<sub2>1</sub2>}_,out_{<sub2>1</sub2>}_,k−1representing the first output out₁from subplant sp₁at time k−1.

Penalty function module <b>820</b> may modify the cost vector c to add a cost associated with changing the subplant outputs. For example, penalty function module <b>820</b> may modify the cost vector c as follows:

&lt;br /&gt;<i>c=[ . . . c</i>_sp_{<sub2>1</sub2>}_{,1 . . . h}<i>c</i>_sp_{<sub2>2</sub2>}_{,1 . . . h}<i>. . . c</i>_sp_{<sub2>n</sub2>}_{,1 . . . h}]^T

where c_sp_{<sub2>1</sub2>}_{,1 . . . h}, c_sp_{<sub2>2</sub2>}_{,1 . . . h}, and c_sp_{<sub2>n</sub2>}_{,1 . . . h}are costs penalties associated with the changes in subplant outputs.

Penalty function module <b>820</b> may 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 subplant <b>522</b> may have the following form:

<maths id="MATH-US-00019" num="00019"><math overflow="scroll"><mrow><mrow><mi>A</mi><mo>=</mo><mrow><mo>[</mo><mtable><mtr><mtd><mi>…</mi></mtd><mtd><mrow><msub><mi>I</mi><mi>h</mi></msub><mo>-</mo><msub><mi>D</mi><mrow><mo>-</mo><mn>1</mn></mrow></msub></mrow></mtd><mtd><mi>…</mi></mtd><mtd><mrow><mo>-</mo><msub><mi>I</mi><mi>h</mi></msub></mrow></mtd><mtd><msub><mn>0</mn><mi>h</mi></msub></mtd><mtd><msub><mn>0</mn><mi>h</mi></msub></mtd></mtr><mtr><mtd><mi>…</mi></mtd><mtd><mrow><msub><mi>D</mi><mrow><mo>-</mo><mn>1</mn></mrow></msub><mo>-</mo><msub><mi>I</mi><mi>h</mi></msub></mrow></mtd><mtd><mi>…</mi></mtd><mtd><mrow><mo>-</mo><msub><mi>I</mi><mi>h</mi></msub></mrow></mtd><mtd><msub><mn>0</mn><mi>h</mi></msub></mtd><mtd><msub><mn>0</mn><mi>h</mi></msub></mtd></mtr><mtr><mtd><mi>⋮</mi></mtd><mtd><mi>⋮</mi></mtd><mtd><mi>⋮</mi></mtd><mtd><mi>⋮</mi></mtd><mtd><mi>⋮</mi></mtd><mtd><mi>⋮</mi></mtd></mtr></mtable><mo>]</mo></mrow></mrow><mo>,</mo><mstyle><mtext></mtext></mstyle><mo></mo><mrow><mi>b</mi><mo>=</mo><mrow><mo>[</mo><mtable><mtr><mtd><mrow><mo>[</mo><mtable><mtr><mtd><msub><mi>x</mi><mrow><msub><mi>sp</mi><mn>1</mn></msub><mo>,</mo><mrow><mrow><msub><mi>out</mi><mn>1</mn></msub><mo></mo><mi>k</mi></mrow><mo>-</mo><mn>1</mn></mrow></mrow></msub></mtd></mtr><mtr><mtd><msub><mn>0</mn><mrow><mi>h</mi><mo>-</mo><mn>1</mn></mrow></msub></mtd></mtr></mtable><mo>]</mo></mrow></mtd></mtr><mtr><mtd><mrow><mo>[</mo><mtable><mtr><mtd><mrow><mo>-</mo><msub><mi>x</mi><mrow><msub><mi>sp</mi><mn>1</mn></msub><mo>,</mo><mrow><mrow><msub><mi>out</mi><mn>1</mn></msub><mo></mo><mi>k</mi></mrow><mo>-</mo><mn>1</mn></mrow></mrow></msub></mrow></mtd></mtr><mtr><mtd><msub><mn>0</mn><mrow><mi>h</mi><mo>-</mo><mn>1</mn></mrow></msub></mtd></mtr></mtable><mo>]</mo></mrow></mtd></mtr><mtr><mtd><mi>⋮</mi></mtd></mtr></mtable><mo>]</mo></mrow></mrow></mrow></math></maths>

where x_sp_{<sub2>1</sub2>}_,out_{<sub2>1</sub2>}_,k−1is the value of the decision variable representing the output of subplant sp₁at time k−1. Similar constraints may be added for each of subplants <b>520</b>-<b>530</b>.

The constraints added by penalty function module <b>820</b> require 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 optimizer <b>632</b> may 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 optimizer <b>632</b> may 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 to <figref idref="DRAWINGS">FIG. 8</figref>, high level optimizer <b>632</b> is shown to include an incentive program module <b>822</b>. Incentive program module <b>822</b> may 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 system <b>500</b> may 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 system <b>500</b> may reduce its demand for resources from a utility as part of a load shedding program. It is contemplated that central plant system <b>500</b> may participate in any number and/or type of IBDR programs.

Advantageously, incentive program module <b>822</b> may be configured to modify the optimization problem to account for participation in any number of IBDR programs. For example, incentive program module <b>822</b> may incorporate IBDR revenue into the value function which high level optimizer <b>632</b> seeks to optimize (e.g., the $IBDR term of the value function). Incentive program module <b>822</b> may also add a decision variable x_resource_{<sub2>p</sub2>}_,prog_{<sub2>s</sub2>}_{,1 . . . h}to the decision matrix x for each IBDR program in which central plant system <b>500</b> can potentially participate, as shown in the following equation:

&lt;br /&gt;<i>x=[ . . . x</i>_resource_{<sub2>p</sub2>}_{,under,1 . . . h}<i>x</i>_resource_{<sub2>p</sub2>}_{,over,1 . . . h}<i>x</i>_resource_{<sub2>p</sub2>}_{,storage,1 . . . h}<i>x</i>_resource_{<sub2>p</sub2>}_,prog_{<sub2>s</sub2>}_{,1 . . . h}]^T

where the decision variable x_resource_{<sub2>p</sub2>}_,prog_{<sub2>s</sub2>}_{,1 . . . h}represents the amount of resource p allocated to IBDR program s at each of the h time steps. Incentive program module <b>822</b> may add similar decision variables for each IBDR program.

Incentive program module <b>822</b> may modify the cost vector c to include the revenue offered for participating in each IBDR program. For example, incentive program module <b>822</b> may modify the cost vector c as shown in the following equation:

&lt;br /&gt;<i>c=[ . . . MM</i>0−<i>r</i>_resource_{<sub2>p</sub2>}_,prog_{<sub2>s</sub2>}_{,1 . . . h}]^T

where the variable r_resource_{<sub2>p</sub2>}_,prog_{<sub2>s</sub2>}_{,1 . . . h}represents 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 estimator <b>620</b>.

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

<maths id="MATH-US-00020" num="00020"><math overflow="scroll"><mrow><mrow><mi>A</mi><mo>=</mo><mrow><mo>[</mo><mtable><mtr><mtd><mi>…</mi></mtd><mtd><mn>0</mn></mtd><mtd><mn>0</mn></mtd><mtd><msub><mi>I</mi><mi>h</mi></msub></mtd><mtd><msub><mi>p</mi><mi>charge</mi></msub></mtd></mtr><mtr><mtd><mi>…</mi></mtd><mtd><mn>0</mn></mtd><mtd><mn>0</mn></mtd><mtd><mrow><mo>-</mo><msub><mi>I</mi><mi>h</mi></msub></mrow></mtd><mtd><msub><mi>p</mi><mi>discharge</mi></msub></mtd></mtr><mtr><mtd><mi>…</mi></mtd><mtd><mn>0</mn></mtd><mtd><mn>0</mn></mtd><mtd><mrow><msub><mi>T</mi><mi>s</mi></msub><mo></mo><msub><mi>Δ</mi><mi>h</mi></msub></mrow></mtd><mtd><msub><mi>p</mi><mi>cap</mi></msub></mtd></mtr><mtr><mtd><mi>…</mi></mtd><mtd><mn>0</mn></mtd><mtd><mn>0</mn></mtd><mtd><mrow><mrow><mo>-</mo><msub><mi>T</mi><mi>s</mi></msub></mrow><mo></mo><msub><mi>Δ</mi><mi>h</mi></msub></mrow></mtd><mtd><msub><mi>p</mi><mi>cap</mi></msub></mtd></mtr></mtable><mo>]</mo></mrow></mrow><mo>,</mo><mrow><mi>b</mi><mo>=</mo><mrow><mo>[</mo><mtable><mtr><mtd><mi>⋮</mi></mtd></mtr><mtr><mtd><msub><mi>x</mi><msub><mi>discharge</mi><mrow><mi>p</mi><mo>,</mo><mi>max</mi></mrow></msub></msub></mtd></mtr><mtr><mtd><msub><mi>x</mi><msub><mi>charge</mi><mrow><mi>p</mi><mo>,</mo><mi>max</mi></mrow></msub></msub></mtd></mtr><mtr><mtd><msub><mi>C</mi><msub><mi>storage</mi><mrow><mi>p</mi><mo>,</mo><mn>0</mn></mrow></msub></msub></mtd></mtr><mtr><mtd><mrow><msub><mi>C</mi><msub><mi>storage</mi><mrow><mi>p</mi><mo>,</mo><mi>max</mi></mrow></msub></msub><mo>-</mo><msub><mi>C</mi><msub><mi>storage</mi><mrow><mi>p</mi><mo>,</mo><mn>0</mn></mrow></msub></msub></mrow></mtd></mtr></mtable><mo>]</mo></mrow></mrow></mrow></math></maths>

where p_charge, p_discharge, and p_capare 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 optimizer <b>632</b> to 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 optimizer <b>632</b> may allocate resources to the IBDR program. However, if the expected revenue does not outweigh the costs, high level optimizer <b>632</b> may allocate the resources to satisfying building loads.

Battery Capacity Loss Incorporation

Still referring to <figref idref="DRAWINGS">FIG. 8</figref>, high level optimizer <b>632</b> is shown to include a battery capacity loss module <b>824</b>. Battery capacity loss module <b>824</b> may be configured to adjust the optimization problem to account for a loss in battery capacity (e.g., electrical energy storage <b>533</b>) as a result of the control decisions made by high level optimizer <b>632</b>. For example, battery capacity loss module <b>824</b> may 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 optimizer <b>632</b> seeks to optimize.

In some embodiments, battery capacity loss module <b>824</b> estimates 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:

<maths id="MATH-US-00021" num="00021"><math overflow="scroll"><mrow><mrow><mi>$</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>BL</mi></mrow><mo>=</mo><mrow><mi>f</mi><mo></mo><mrow><mo>(</mo><mrow><mi>DOD</mi><mo>,</mo><mi>T</mi><mo>,</mo><mi>SOC</mi><mo>,</mo><mrow><mo>∑</mo><msub><mi>kW</mi><mi>batt</mi></msub></mrow><mo>,</mo><mrow><mo>∑</mo><mfrac><mrow><mo></mo><msub><mi>kW</mi><mi>batt</mi></msub></mrow><mrow><mo></mo><mi>t</mi></mrow></mfrac></mrow><mo>,</mo><mover><mi>RMCCP</mi><mi>_</mi></mover><mo>,</mo><mover><mi>RMPCP</mi><mi>_</mi></mover><mo>,</mo><mover><mi>MR</mi><mi>_</mi></mover><mo>,</mo><msub><mi>i</mi><mi>n</mi></msub><mo>,</mo><mi>n</mi></mrow><mo>)</mo></mrow></mrow></mrow></math></maths>

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, kW_battrepresents the battery power draw,

<maths id="MATH-US-00022" num="00022"><math overflow="scroll"><mfrac><mrow><mo></mo><msub><mi>kW</mi><mi>batt</mi></msub></mrow><mrow><mo></mo><mi>t</mi></mrow></mfrac></math></maths>

represents the change in battery power draw, <o ostyle="single">RMCCP</o> represents the average regulation market capability clearing price (RMCCP), <o ostyle="single">RMPCP</o> represents the average regulation market performance clearing price (RMCCP) and <o ostyle="single">MR</o> represents the average mileage ratio (MR). The loss in battery capacity may be a function of several inputs which can be modified by high level optimizer <b>632</b> such 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 optimizer <b>632</b> can increase or decrease many of these inputs by adjusting the amount of power allocated to the battery (i.e., electrical energy storage subplant <b>533</b>) at each time step.

In some embodiments, battery capacity loss module <b>824</b> determines an expected loss in battery capacity as a function of the control decisions made by high level optimizer <b>632</b>. Battery capacity loss module <b>824</b> may monetize the expected loss in battery capacity and/or provide the expected loss in battery capacity to high level optimizer <b>632</b>. High level optimizer <b>632</b> may 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 system <b>500</b> to participate in IBDR programs in the future due to the battery capacity failing to meet IBDR requirements. Advantageously, high level optimizer <b>632</b> can 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 optimizer <b>632</b> may 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.

Subplant Curves

Referring now to <figref idref="DRAWINGS">FIGS. 9A-B</figref>, two subplant curves <b>900</b> and <b>910</b> are shown, according to an exemplary embodiment. Subplant curves <b>900</b> and <b>910</b> define the resource usage of a subplant (e.g., one of subplants <b>520</b>-<b>530</b>) 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 curve <b>900</b> may define the electricity use <b>902</b> of chiller subplant <b>522</b> as a function of the load <b>904</b> on chiller subplant <b>522</b>, whereas subplant curve <b>910</b> may define the water use <b>906</b> of chiller subplant <b>522</b> as a function of the load <b>904</b> on chiller subplant <b>522</b>. Each of subplants <b>520</b>-<b>530</b> may have one or more subplant curves (e.g., one for each type of resource consumed by the subplant).

In some embodiments, low level optimizer <b>634</b> generates subplant curves <b>900</b> and <b>910</b> based on equipment models <b>618</b> (e.g., by combining equipment models <b>618</b> for individual devices into an aggregate curve for the subplant). Low level optimizer <b>634</b> may generate subplant curves <b>900</b> and <b>910</b> by running the low level optimization process for several different loads and weather conditions to generate multiple data points. Low level optimizer <b>634</b> may fit a curve to the data points to generate the subplant curves. In other embodiments, low level optimizer <b>634</b> provides the data points to high level optimizer <b>632</b> and high level optimizer <b>632</b> generates the subplant curves using the data points.

Referring now to <figref idref="DRAWINGS">FIG. 10</figref>, another subplant curve <b>1000</b> is shown, according to an exemplary embodiment. Subplant curve <b>1000</b> defines the electricity use of chiller subplant <b>522</b> as a function of the cold water production of chiller subplant <b>522</b>. In some embodiments, subplant curve <b>1000</b> is generated by combining efficiency curves for individual devices of chiller subplant <b>522</b> (e.g., individual chillers, pumps, etc.). For example, each of the chillers in subplant <b>522</b> may 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 curve <b>1000</b> may result in subplant curve <b>1000</b> having one or more waves <b>1002</b>, as shown in <figref idref="DRAWINGS">FIG. 10</figref>. Waves <b>1002</b> may 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 to <figref idref="DRAWINGS">FIG. 11</figref>, a linearized subplant curve <b>1100</b> is shown, according to an exemplary embodiment. Subplant curve <b>1100</b> defines the electricity use of chiller subplant <b>522</b> as a function of the cold water production of chiller subplant <b>522</b>. Subplant curve <b>1100</b> may be generated by converting subplant curve <b>1000</b> into 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 curve <b>1100</b> is generated by subplant curve linearizer <b>836</b>, as described with reference to <figref idref="DRAWINGS">FIG. 8</figref>. Subplant curve <b>1100</b> may be created by generating a plurality of linear segments (i.e., segments <b>1102</b>, <b>1104</b>, and <b>1106</b>) that approximate subplant curve <b>1000</b> and combining the linear segments into a piecewise-defined linearized convex curve <b>1100</b>. Linearized subplant curve <b>1100</b> is shown to include a first linear segment <b>1102</b> connecting point [u₁, Q₁] to point [u₂, Q₂], a second linear segment <b>1104</b> connecting point [u₂, Q₂] to point [u₃, Q₃], and a third linear segment <b>1106</b> connecting point [u₃, Q₃] to point [u₄, Q₄]. The endpoints of line segments <b>1102</b>-<b>1106</b> may be used to form constraints that force the electricity use of chiller subplant <b>522</b> in the epigraph of the linearized subplant curve <b>1100</b>.

Referring now to <figref idref="DRAWINGS">FIG. 12</figref>, another subplant curve <b>1200</b> is shown, according to an exemplary embodiment. Subplant curve <b>1200</b> defines the energy use of one of subplants <b>520</b>-<b>530</b> as a function of the load on the subplant for several different weather conditions. In some embodiments, subplant curve <b>1200</b> is generated by subplant curves module <b>830</b> using experimental data obtained from the low level optimizer <b>634</b>. For example, subplant curve updater <b>832</b> may request resource usage data from low level optimizer <b>634</b> for various combinations of load conditions and environmental conditions. In the embodiment shown in <figref idref="DRAWINGS">FIG. 12</figref>, subplant curve updater <b>832</b> requests 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 optimizer <b>634</b> may perform the low level optimization process for the requested load and temperature combinations and return an energy use value for each combination.

Subplant curve updater <b>832</b> may use the data points provided by low level optimizer <b>634</b> to find the best piecewise linear convex function that fits the data. For example, subplant curve updater <b>832</b> may fit a first subplant curve <b>1202</b> to the data points at 70° F., a second subplant curve <b>1204</b> to the data points at 60° F., a third subplant curve <b>1206</b> to the data points at 50° F., and a fourth subplant curve <b>1208</b> to the data points at 40° F. Subplant curve updater <b>832</b> may store the generated subplant curves <b>1202</b>-<b>1208</b> in subplant curves database <b>834</b> for use in the high level optimization algorithm.

In some implementations, central plant controller <b>506</b> uses high level optimizer <b>632</b> as part of an operational tool to exercise real-time control over the central plant. In the operational tool, high level optimizer <b>632</b> may receive load and rate predictions from load/rate predictor <b>622</b> and subplant curves (or data that can be used to generate subplant curves) from low level optimizer <b>634</b>. When implemented in the operational tool, high level optimizer <b>632</b> may determine an optimal load distribution for heater subplant <b>521</b>, heat recovery chiller subplant <b>523</b>, chiller subplant <b>522</b>, hot TES subplant <b>531</b>, cold TES subplant <b>532</b>, electrical energy storage subplant <b>533</b>, and/or energy purchasers <b>504</b>, as described with reference to <figref idref="DRAWINGS">FIGS. 5-8</figref>. In some embodiments, high level optimizer <b>632</b> determines ground loop and heat exchanger transfer rates in addition to the subplant loads. When implemented in the operational tool, high level optimizer <b>632</b> may provide the determined resource allocation to low level optimizer <b>634</b> for use in determining optimal on/off decisions and/or operating setpoints for the equipment of each subplant.

Planning Tool

Referring now to <figref idref="DRAWINGS">FIG. 13</figref>, a block diagram of a planning system <b>1300</b> is shown, according to an exemplary embodiment. Planning system <b>1300</b> may be configured to use demand response optimizer <b>630</b> as part of a planning tool <b>1302</b> to 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 tool <b>1302</b>, demand response optimizer <b>630</b> may operate in a similar manner as described with reference to <figref idref="DRAWINGS">FIGS. 6-8</figref>. For example, demand response optimizer <b>630</b> may use building loads and utility rates to determine an optimal resource allocation to minimize cost over a simulation period. However, planning tool <b>1302</b> may not be responsible for real-time control of a building management system or central plant.

In planning tool <b>1302</b>, high level optimizer <b>632</b> may 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 device <b>1322</b> (e.g., user-defined, user selected, etc.) and/or retrieved from a plan information database <b>1326</b>. High level optimizer <b>632</b> uses the planned loads and utility rates in conjunction with subplant curves from low level optimizer <b>634</b> to 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 optimizer <b>632</b> optimizes 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 optimizer <b>632</b> requests all of the subplant curves used in the simulation from low level optimizer <b>634</b> at the beginning of the simulation. Since the planned loads and environmental conditions are known for the entire simulation period, high level optimizer <b>632</b> may retrieve all of the relevant subplant curves at the beginning of the simulation. In some embodiments, low level optimizer <b>634</b> generates functions that map subplant production to equipment level production and resource use when the subplant curves are provided to high level optimizer <b>632</b>. 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 to <figref idref="DRAWINGS">FIG. 13</figref>, planning tool <b>1302</b> is shown to include a communications interface <b>1304</b> and a processing circuit <b>1306</b>. Communications interface <b>1304</b> may 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 interface <b>1304</b> may 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 interface <b>1304</b> may 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 interface <b>1304</b> may be a network interface configured to facilitate electronic data communications between planning tool <b>1302</b> and various external systems or devices (e.g., client device <b>1322</b>, results database <b>1328</b>, plan information database <b>1326</b>, etc.). For example, planning tool <b>1302</b> may receive planned loads and utility rates from client device <b>1322</b> and/or plan information database <b>1326</b> via communications interface <b>1304</b>. Planning tool <b>1302</b> may use communications interface <b>1304</b> to output results of the simulation to client device <b>1322</b> and/or to store the results in results database <b>1328</b>.

Still referring to <figref idref="DRAWINGS">FIG. 13</figref>, processing circuit <b>1306</b> is shown to include a processor <b>1310</b> and memory <b>1312</b>. Processor <b>1310</b> may 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. Processor <b>1310</b> may be configured to execute computer code or instructions stored in memory <b>1312</b> or received from other computer readable media (e.g., CDROM, network storage, a remote server, etc.).

Memory <b>1312</b> may 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. Memory <b>1312</b> may 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. Memory <b>1312</b> may 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. Memory <b>1312</b> may be communicably connected to processor <b>1310</b> via processing circuit <b>1306</b> and may include computer code for executing (e.g., by processor <b>1310</b>) one or more processes described herein.

Still referring to <figref idref="DRAWINGS">FIG. 13</figref>, memory <b>1312</b> is shown to include a GUI engine <b>1316</b>, web services <b>1314</b>, and configuration tools <b>1318</b>. In an exemplary embodiment, GUI engine <b>1316</b> includes 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 services <b>1314</b> may allow a user to interact with planning tool <b>1302</b> via a web portal and/or from a remote system or device (e.g., an enterprise control application).

Configuration tools <b>1318</b> can 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 tools <b>1318</b> can 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 database <b>1326</b>) and adapt it or enable it for use in the simulation.

Still referring to <figref idref="DRAWINGS">FIG. 13</figref>, memory <b>1312</b> is shown to include demand response optimizer <b>630</b>. Demand response optimizer <b>630</b> may use the planned loads and utility rates to determine an optimal resource allocation over a prediction window. The operation of demand response optimizer <b>630</b> may be the same or similar as previously described with reference to <figref idref="DRAWINGS">FIGS. 6-8</figref>. With each iteration of the optimization process, demand response optimizer <b>630</b> may 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 optimizer <b>630</b> may use the new plan information at the end of the prediction window to perform the next iteration of the optimization process. Demand response optimizer <b>630</b> may output the applied resource allocation to reporting applications <b>1330</b> for presentation to a client device <b>1322</b> (e.g., via user interface <b>1324</b>) or storage in results database <b>1328</b>.

Still referring to <figref idref="DRAWINGS">FIG. 13</figref>, memory <b>1312</b> is shown to include reporting applications <b>1330</b>. Reporting applications <b>1330</b> may receive the optimized resource allocations from demand response optimizer <b>630</b> and, in some embodiments, costs associated with the optimized resource allocations. Reporting applications <b>1330</b> may 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 applications <b>1330</b> is shown in <figref idref="DRAWINGS">FIG. 14</figref>.

Referring now to <figref idref="DRAWINGS">FIG. 14</figref>, several graphs <b>1400</b> illustrating the operation of planning tool <b>1302</b> are shown, according to an exemplary embodiment. With each iteration of the optimization process, planning tool <b>1302</b> selects an optimization period (i.e., a portion of the simulation period) over which the optimization is performed. For example, planning tool <b>1302</b> may select optimization period <b>1402</b> for use in the first iteration. Once the optimal resource allocation <b>1410</b> has been determined, planning tool <b>1302</b> may select a portion <b>1418</b> of resource allocation <b>1410</b> to send to plant dispatch <b>1430</b>. Portion <b>1418</b> may be the first b time steps of resource allocation <b>1410</b>. Planning tool <b>1302</b> may shift the optimization period <b>1402</b> forward in time, resulting in optimization period <b>1404</b>. The amount by which the prediction window is shifted may correspond to the duration of time steps b.

Planning tool <b>1302</b> may repeat the optimization process for optimization period <b>1404</b> to determine the optimal resource allocation <b>1412</b>. Planning tool <b>1302</b> may select a portion <b>1420</b> of resource allocation <b>1412</b> to send to plant dispatch <b>1430</b>. Portion <b>1420</b> may be the first b time steps of resource allocation <b>1412</b>. Planning tool <b>1302</b> may then shift the prediction window forward in time, resulting in optimization period <b>1406</b>. This process may be repeated for each subsequent optimization period (e.g., optimization periods <b>1406</b>, <b>1408</b>, etc.) to generate updated resource allocations (e.g., resource allocations <b>1414</b>, <b>1416</b>, etc.) and to select portions of each resource allocation (e.g., portions <b>1422</b>, <b>1424</b>) to send to plant dispatch <b>1430</b>. Plant dispatch <b>1430</b> includes the first b time steps <b>1418</b>-<b>1424</b> from each of optimization periods <b>1402</b>-<b>1408</b>. Once the optimal resource allocation is compiled for the entire simulation period, the results may be sent to reporting applications <b>1330</b>, results database <b>1328</b>, and/or client device <b>1322</b>, as described with reference to <figref idref="DRAWINGS">FIG. 13</figref>.

Electrical Energy Storage System with Frequency Regulation and Ramp Rate Control

Referring now to <figref idref="DRAWINGS">FIGS. 15-16</figref>, an electrical energy storage system <b>1500</b> is shown, according to an exemplary embodiment. System <b>1500</b> can use battery storage to perform both ramp rate control and frequency regulation. Ramp rate control is the process of offsetting ramp rates (i.e., increases or decreases in the power output of an energy system such as a photovoltaic energy system) that fall outside of compliance limits determined by the electric power authority overseeing the energy grid. Ramp rate control typically requires the use of an energy source that allows for offsetting ramp rates by either supplying additional power to the grid or consuming more power from the grid. In some instances, a facility is penalized for failing to comply with ramp rate requirements.

Frequency regulation is the process of maintaining the stability of the grid frequency (e.g., 60 Hz in the United States). The grid frequency may remain balanced as long as there is a balance between the demand from the energy grid and the supply to the energy grid. An increase in demand yields a decrease in grid frequency, whereas an increase in supply yields an increase in grid frequency. During a fluctuation of the grid frequency, system <b>1500</b> may offset the fluctuation by either drawing more energy from the energy grid (e.g., if the grid frequency is too high) or by providing energy to the energy grid (e.g., if the grid frequency is too low). Advantageously, system <b>1500</b> may use battery storage in combination with photovoltaic power to perform frequency regulation while simultaneously complying with ramp rate requirements and maintaining the state-of-charge of the battery storage within a predetermined desirable range.

System <b>1500</b> is shown to include a photovoltaic (PV) field <b>1502</b>, a PV field power inverter <b>1504</b>, a battery <b>1506</b>, a battery power inverter <b>1508</b>, a point of interconnection (POI) <b>1510</b>, and an energy grid <b>1512</b>. In some embodiments, system <b>1500</b> also includes a controller <b>1514</b> (shown in <figref idref="DRAWINGS">FIG. 15</figref>) and/or a building <b>1518</b> (shown in <figref idref="DRAWINGS">FIG. 16</figref>). In brief overview, PV field power inverter <b>1504</b> can be operated by controller <b>1514</b> to control the power output of PV field <b>1502</b>. Similarly, battery power inverter <b>1508</b> can be operated by controller <b>1514</b> to control the power input and/or power output of battery <b>1506</b>. The power outputs of PV field power inverter <b>1504</b> and battery power inverter <b>1508</b> combine at POI <b>1510</b> to form the power provided to energy grid <b>1512</b>. In some embodiments, building <b>1518</b> is also connected to POI <b>1510</b>. Building <b>1518</b> can consume a portion of the combined power at POI <b>1510</b> to satisfy the energy requirements of building <b>1518</b>.

PV field <b>1502</b> may include a collection of photovoltaic cells. The photovoltaic cells are configured to convert solar energy (i.e., sunlight) into electricity using a photovoltaic material such as monocrystalline silicon, polycrystalline silicon, amorphous silicon, cadmium telluride, copper indium gallium selenide/sulfide, or other materials that exhibit the photovoltaic effect. In some embodiments, the photovoltaic cells are contained within packaged assemblies that form solar panels. Each solar panel may include a plurality of linked photovoltaic cells. The solar panels may combine to form a photovoltaic array.

PV field <b>1502</b> may have any of a variety of sizes and/or locations. In some embodiments, PV field <b>1502</b> is part of a large-scale photovoltaic power station (e.g., a solar park or farm) capable of providing an energy supply to a large number of consumers. When implemented as part of a large-scale system, PV field <b>1502</b> may cover multiple hectares and may have power outputs of tens or hundreds of megawatts. In other embodiments, PV field <b>1502</b> may cover a smaller area and may have a relatively lesser power output (e.g., between one and ten megawatts, less than one megawatt, etc.). For example, PV field <b>1502</b> may be part of a rooftop-mounted system capable of providing enough electricity to power a single home or building. It is contemplated that PV field <b>1502</b> may have any size, scale, and/or power output, as may be desirable in different implementations.

PV field <b>1502</b> may generate a direct current (DC) output that depends on the intensity and/or directness of the sunlight to which the solar panels are exposed. The directness of the sunlight may depend on the angle of incidence of the sunlight relative to the surfaces of the solar panels. The intensity of the sunlight may be affected by a variety of environmental factors such as the time of day (e.g., sunrises and sunsets) and weather variables such as clouds that cast shadows upon PV field <b>1502</b>. When PV field <b>1502</b> is partially or completely covered by shadow, the power output of PV field <b>1502</b> (i.e., PV field power P_PV) may drop as a result of the decrease in solar intensity.

In some embodiments, PV field <b>1502</b> is configured to maximize solar energy collection. For example, PV field <b>1502</b> may include a solar tracker (e.g., a GPS tracker, a sunlight sensor, etc.) that adjusts the angle of the solar panels so that the solar panels are aimed directly at the sun throughout the day. The solar tracker may allow the solar panels to receive direct sunlight for a greater portion of the day and may increase the total amount of power produced by PV field <b>1502</b>. In some embodiments, PV field <b>1502</b> includes a collection of mirrors, lenses, or solar concentrators configured to direct and/or concentrate sunlight on the solar panels. The energy generated by PV field <b>1502</b> may be stored in battery <b>1506</b> or provided to energy grid <b>1512</b>.

Still referring to <figref idref="DRAWINGS">FIG. 15</figref>, system <b>1500</b> is shown to include a PV field power inverter <b>1504</b>. Power inverter <b>1504</b> may be configured to convert the DC output of PV field <b>1502</b> P_PVinto an alternating current (AC) output that can be fed into energy grid <b>1512</b> or used by a local (e.g., off-grid) electrical network and/or by building <b>1518</b>. For example, power inverter <b>1504</b> may be a solar inverter or grid-tie inverter configured to convert the DC output from PV field <b>1502</b> into a sinusoidal AC output synchronized to the grid frequency of energy grid <b>1512</b>. In some embodiments, power inverter <b>1504</b> receives a cumulative DC output from PV field <b>1502</b>. For example, power inverter <b>1504</b> may be a string inverter or a central inverter. In other embodiments, power inverter <b>1504</b> may include a collection of micro-inverters connected to each solar panel or solar cell. PV field power inverter <b>1504</b> may convert the DC power output P_PVinto an AC power output u_PVand provide the AC power output u_PVto POI <b>1510</b>.

Power inverter <b>1504</b> may receive the DC power output P_PVfrom PV field <b>1502</b> and convert the DC power output to an AC power output that can be fed into energy grid <b>1512</b>. Power inverter <b>1504</b> may synchronize the frequency of the AC power output with that of energy grid <b>1512</b> (e.g., 50 Hz or 60 Hz) using a local oscillator and may limit the voltage of the AC power output to no higher than the grid voltage. In some embodiments, power inverter <b>1504</b> is a resonant inverter that includes or uses LC circuits to remove the harmonics from a simple square wave in order to achieve a sine wave matching the frequency of energy grid <b>1512</b>. In various embodiments, power inverter <b>1504</b> may operate using high-frequency transformers, low-frequency transformers, or without transformers. Low-frequency transformers may convert the DC output from PV field <b>1502</b> directly to the AC output provided to energy grid <b>1512</b>. High-frequency transformers may employ a multi-step process that involves converting the DC output to high-frequency AC, then back to DC, and then finally to the AC output provided to energy grid <b>1512</b>.

Power inverter <b>1504</b> may be configured to perform maximum power point tracking and/or anti-islanding. Maximum power point tracking may allow power inverter <b>1504</b> to produce the maximum possible AC power from PV field <b>1502</b>. For example, power inverter <b>1504</b> may sample the DC power output from PV field <b>1502</b> and apply a variable resistance to find the optimum maximum power point. Anti-islanding is a protection mechanism that immediately shuts down power inverter <b>1504</b> (i.e., preventing power inverter <b>1504</b> from generating AC power) when the connection to an electricity-consuming load no longer exists. In some embodiments, PV field power inverter <b>1504</b> performs ramp rate control by limiting the power generated by PV field <b>1502</b>.

PV field power inverter <b>1504</b> can include any of a variety of circuit components (e.g., resistors, capacitors, indictors, transformers, transistors, switches, diodes, etc.) configured to perform the functions described herein. In some embodiments DC power from PV field <b>1502</b> is connected to a transformer of PV field power inverter <b>1504</b> through a center tap of a primary winding. A switch can be rapidly switched back and forth to allow current to flow back to PV field <b>1502</b> following two alternate paths through one end of the primary winding and then the other. The alternation of the direction of current in the primary winding of the transformer can produce alternating current (AC) in a secondary circuit.

In some embodiments, PV field power inverter <b>1504</b> uses an electromechanical switching device to convert DC power from PV field <b>1502</b> into AC power. The electromechanical switching device can include two stationary contacts and a spring supported moving contact. The spring can hold the movable contact against one of the stationary contacts, whereas an electromagnet can pull the movable contact to the opposite stationary contact. Electric current in the electromagnet can be interrupted by the action of the switch so that the switch continually switches rapidly back and forth. In some embodiments, PV field power inverter <b>1504</b> uses transistors, thyristors (SCRs), and/or various other types of semiconductor switches to convert DC power from PV field <b>1502</b> into AC power. SCRs provide large power handling capability in a semiconductor device and can readily be controlled over a variable firing range.

In some embodiments, PV field power inverter <b>1504</b> produces a square voltage waveform (e.g., when not coupled to an output transformer). In other embodiments, PV field power inverter <b>1504</b> produces a sinusoidal waveform that matches the sinusoidal frequency and voltage of energy grid <b>1512</b>. For example, PV field power inverter <b>1504</b> can use Fourier analysis to produce periodic waveforms as the sum of an infinite series of sine waves. The sine wave that has the same frequency as the original waveform is called the fundamental component. The other sine waves, called harmonics, that are included in the series have frequencies that are integral multiples of the fundamental frequency.

In some embodiments, PV field power inverter <b>1504</b> uses inductors and/or capacitors to filter the output voltage waveform. If PV field power inverter <b>1504</b> includes a transformer, filtering can be applied to the primary or the secondary side of the transformer or to both sides. Low-pass filters can be applied to allow the fundamental component of the waveform to pass to the output while limiting the passage of the harmonic components. If PV field power inverter <b>1504</b> is designed to provide power at a fixed frequency, a resonant filter can be used. If PV field power inverter <b>1504</b> is an adjustable frequency inverter, the filter can be tuned to a frequency that is above the maximum fundamental frequency. In some embodiments, PV field power inverter <b>1504</b> includes feedback rectifiers or antiparallel diodes connected across semiconductor switches to provide a path for a peak inductive load current when the switch is turned off. The antiparallel diodes can be similar to freewheeling diodes commonly used in AC/DC converter circuits.

Still referring to <figref idref="DRAWINGS">FIG. 15</figref>, system <b>1500</b> is shown to include a battery power inverter <b>1508</b>. Battery power inverter <b>1508</b> may be configured to draw a DC power P_batfrom battery <b>1506</b>, convert the DC power P_batinto an AC power u_bat, and provide the AC power u_batto POI <b>1510</b>. Battery power inverter <b>1508</b> may also be configured to draw the AC power u_batfrom POI <b>1510</b>, convert the AC power u_batinto a DC battery power P_bat, and store the DC battery power P_batin battery <b>1506</b>. As such, battery power inverter <b>1508</b> can function as both a power inverter and a rectifier to convert between DC and AC in either direction. The DC battery power P_batmay be positive if battery <b>1506</b> is providing power to battery power inverter <b>1508</b> (i.e., if battery <b>1506</b> is discharging) or negative if battery <b>1506</b> is receiving power from battery power inverter <b>1508</b> (i.e., if battery <b>1506</b> is charging). Similarly, the AC battery power u_batmay be positive if battery power inverter <b>1508</b> is providing power to POI <b>1510</b> or negative if battery power inverter <b>1508</b> is receiving power from POI <b>1510</b>.

The AC battery power u_batis shown to include an amount of power used for frequency regulation (i.e., u_FR) and an amount of power used for ramp rate control (i.e., u_RR) which together form the AC battery power (i.e., u_bat=u_FR+u+_RR). The DC battery power P_batis shown to include both u_FRand u_RRas well as an additional term P_lossrepresenting power losses in battery <b>1506</b> and/or battery power inverter <b>1508</b> (i.e., P_bat=u_FR+u_RR+P_loss). The PV field power u_PVand the battery power u_batcombine at POI <b>1510</b> to form P_POI(i.e., P_POI=u_PV+u_bat), which represents the amount of power provided to energy grid <b>1512</b>. P_POImay be positive if POI <b>1510</b> is providing power to energy grid <b>1512</b> or negative if POI <b>1510</b> is receiving power from energy grid <b>1512</b>.

Like PV field power inverter <b>1504</b>, battery power inverter <b>1508</b> can include any of a variety of circuit components (e.g., resistors, capacitors, indictors, transformers, transistors, switches, diodes, etc.) configured to perform the functions described herein. Battery power inverter <b>1508</b> can include many of the same components as PV field power inverter <b>1504</b> and can operate using similar principles. For example, battery power inverter <b>1508</b> can use electromechanical switching devices, transistors, thyristors (SCRs), and/or various other types of semiconductor switches to convert between AC and DC power. Battery power inverter <b>1508</b> can operate the circuit components to adjust the amount of power stored in battery <b>1506</b> and/or discharged from battery <b>1506</b> (i.e., power throughput) based on a power control signal or power setpoint from controller <b>1514</b>.

Still referring to <figref idref="DRAWINGS">FIG. 15</figref>, system <b>1500</b> is shown to include a controller <b>1514</b>. Controller <b>1514</b> may be configured to generate a PV power setpoint u_PVfor PV field power inverter <b>1504</b> and a battery power setpoint u_batfor battery power inverter <b>1508</b>. Throughout this disclosure, the variable u_PVis used to refer to both the PV power setpoint generated by controller <b>1514</b> and the AC power output of PV field power inverter <b>1504</b> since both quantities have the same value. Similarly, the variable u_batis used to refer to both the battery power setpoint generated by controller <b>1514</b> and the AC power output/input of battery power inverter <b>1508</b> since both quantities have the same value.

PV field power inverter <b>1504</b> uses the PV power setpoint u_PVto control an amount of the PV field power P_PVto provide to POI <b>1510</b>. The magnitude of u_PVmay be the same as the magnitude of P_PVor less than the magnitude of P_PV. For example, u_PVmay be the same as P_PVif controller <b>1514</b> determines that PV field power inverter <b>1504</b> is to provide all of the photovoltaic power P_PVto POI <b>1510</b>. However, u_PVmay be less than P_PVif controller <b>1514</b> determines that PV field power inverter <b>1504</b> is to provide less than all of the photovoltaic power P_PVto POI <b>1510</b>. For example, controller <b>1514</b> may determine that it is desirable for PV field power inverter <b>1504</b> to provide less than all of the photovoltaic power P_PVto POI <b>1510</b> to prevent the ramp rate from being exceeded and/or to prevent the power at POI <b>1510</b> from exceeding a power limit.

Battery power inverter <b>1508</b> uses the battery power setpoint u_batto control an amount of power charged or discharged by battery <b>1506</b>. The battery power setpoint u_batmay be positive if controller <b>1514</b> determines that battery power inverter <b>1508</b> is to draw power from battery <b>1506</b> or negative if controller <b>1514</b> determines that battery power inverter <b>1508</b> is to store power in battery <b>1506</b>. The magnitude of u_batcontrols the rate at which energy is charged or discharged by battery <b>1506</b>.

Controller <b>1514</b> may generate u_PVand u_batbased on a variety of different variables including, for example, a power signal from PV field <b>1502</b> (e.g., current and previous values for P_PV), the current state-of-charge (SOC) of battery <b>1506</b>, a maximum battery power limit, a maximum power limit at POI <b>1510</b>, the ramp rate limit, the grid frequency of energy grid <b>1512</b>, and/or other variables that can be used by controller <b>1514</b> to perform ramp rate control and/or frequency regulation. Advantageously, controller <b>1514</b> generates values for u_PVand u_batthat maintain the ramp rate of the PV power within the ramp rate compliance limit while participating in the regulation of grid frequency and maintaining the SOC of battery <b>1506</b> within a predetermined desirable range. An exemplary controller which can be used as controller <b>1514</b> and exemplary processes which may be performed by controller <b>1514</b> to generate the PV power setpoint u_PVand the battery power setpoint u_batare described in detail in U.S. Provisional Patent Application No. 62/239,245 filed Oct. 8, 2015, the entire disclosure of which is incorporated by reference herein.

Reactive Ramp Rate Control

Controller <b>1514</b> may be configured to control a ramp rate of the power output <b>1516</b> provided to energy grid <b>1512</b>. Ramp rate may be defined as the time rate of change of power output <b>1516</b>. Power output <b>1516</b> may vary depending on the magnitude of the DC output provided by PV field <b>1502</b>. For example, if a cloud passes over PV field <b>1502</b>, power output <b>1516</b> may rapidly and temporarily drop while PV field <b>1502</b> is within the cloud's shadow. Controller <b>1514</b> may be configured to calculate the ramp rate by sampling power output <b>1516</b> and determining a change in power output <b>1516</b> over time. For example, controller <b>1514</b> may calculate the ramp rate as the derivative or slope of power output <b>1516</b> as a function of time, as shown in the following equations:

<maths id="MATH-US-00023" num="00023"><math overflow="scroll"><mrow><mrow><mi>Ramp</mi><mo></mo><mstyle><mspace width="0.8em" height="0.8ex" /></mstyle><mo></mo><mi>Rate</mi></mrow><mo>=</mo><mrow><mrow><mfrac><mrow><mo></mo><mi>P</mi></mrow><mrow><mo></mo><mi>t</mi></mrow></mfrac><mo></mo><mstyle><mspace width="0.8em" height="0.8ex" /></mstyle><mo></mo><mi>or</mi><mo></mo><mstyle><mspace width="0.8em" height="0.8ex" /></mstyle><mo></mo><mi>Ramp</mi><mo></mo><mstyle><mspace width="0.8em" height="0.8ex" /></mstyle><mo></mo><mi>Rate</mi></mrow><mo>=</mo><mfrac><mrow><mi>Δ</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>P</mi></mrow><mrow><mi>Δ</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>t</mi></mrow></mfrac></mrow></mrow></math></maths>

where P represents power output <b>1516</b> and t represents time.

In some embodiments, controller <b>1514</b> controls the ramp rate to comply with regulatory requirements or contractual requirements imposed by energy grid <b>1512</b>. For example, system <b>1500</b> may be required to maintain the ramp rate within a predetermined range in order to deliver power to energy grid <b>1512</b>. In some embodiments, system <b>1500</b> is required to maintain the absolute value of the ramp rate at less than a threshold value (e.g., less than 10% of the rated power capacity per minute). In other words, system <b>1500</b> may be required to prevent power output <b>1516</b> from increasing or decreasing too rapidly. If this requirement is not met, system <b>1500</b> may be deemed to be in non-compliance and its capacity may be de-rated, which directly impacts the revenue generation potential of system <b>1500</b>.

Controller <b>1514</b> may use battery <b>1506</b> to perform ramp rate control. For example, controller <b>1514</b> may use energy from battery <b>1506</b> to smooth a sudden drop in power output <b>1516</b> so that the absolute value of the ramp rate is less than a threshold value. As previously mentioned, a sudden drop in power output <b>1516</b> may occur when a solar intensity disturbance occurs, such as a passing cloud blocking the sunlight to PV field <b>1502</b>. Controller <b>1514</b> may use the energy from battery <b>1506</b> to make up the difference between the power provided by PV field <b>1502</b> (which has suddenly dropped) and the minimum required power output <b>1516</b> to maintain the required ramp rate. The energy from battery <b>1506</b> allows controller <b>1514</b> to gradually decrease power output <b>1516</b> so that the absolute value of the ramp rate does not exceed the threshold value.

Once the cloud has passed, the power output from PV field <b>1502</b> may suddenly increase as the solar intensity returns to its previous value. Controller <b>1514</b> may perform ramp rate control by gradually ramping up power output <b>1516</b>. Ramping up power output <b>1516</b> may not require energy from battery <b>1506</b>. For example, power inverter <b>1504</b> may use only a portion of the energy generated by PV field <b>1502</b> (which has suddenly increased) to generate power output <b>1516</b> (i.e., limiting the power output) so that the ramp rate of power output <b>1516</b> does not exceed the threshold value. The remainder of the energy generated by PV field <b>1502</b> (i.e., the excess energy) may be stored in battery <b>1506</b> and/or dissipated. Limiting the energy generated by PV field <b>1502</b> may include diverting or dissipating a portion of the energy generated by PV field <b>1502</b> (e.g., using variable resistors or other circuit elements) so that only a portion of the energy generated by PV field <b>1502</b> is provided to energy grid <b>1512</b>. This allows power inverter <b>1504</b> to ramp up power output <b>1516</b> gradually without exceeding the ramp rate. The excess energy may be stored in battery <b>1506</b>, used to power other components of system <b>1500</b>, or dissipated.

Referring now to <figref idref="DRAWINGS">FIG. 17</figref>, a graph <b>1700</b> illustrating a reactive ramp rate control technique which can be used by system <b>1500</b> is shown, according to an exemplary embodiment. Graph <b>1700</b> plots the power output P provided to energy grid <b>1512</b> as a function of time t. The solid line <b>1702</b> illustrates power output P without any ramp rate control, whereas the broken line <b>1704</b> illustrates power output P with ramp rate control.

Between times t₀and t₁, power output P is at a high value P_high. At time t₁, a cloud begins to cast its shadow on PV field <b>1502</b>, causing the power output of PV field <b>1502</b> to suddenly decrease, until PV field <b>1502</b> is completely in shadow at time t₂. Without any ramp rate control, the sudden drop in power output from PV field <b>1502</b> causes the power output P to rapidly drop to a low value P_lowat time t₂. However, with ramp rate control, system <b>1500</b> uses energy from battery <b>1506</b> to gradually decrease power output P to P_lowat time t₃. Triangular region <b>1706</b> represents the energy from battery <b>1506</b> used to gradually decrease power output P.

Between times t₂and t₄, PV field <b>1502</b> is completely in shadow. At time t₄, the shadow cast by the cloud begins to move off PV field <b>1502</b>, causing the power output of PV field <b>1502</b> to suddenly increase, until PV field <b>1502</b> is entirely in sunlight at time t₅. Without any ramp rate control, the sudden increase in power output from PV field <b>1502</b> causes the power output P to rapidly increase to the high value P_highat time t₅. However, with ramp rate control, power inverter <b>1504</b> limits the energy from PV field <b>1502</b> to gradually increase power output P to P_highat time t₆. Triangular region <b>1708</b> represents the energy generated by PV field <b>1502</b> in excess of the ramp rate limit. The excess energy may be stored in battery <b>1506</b> and/or dissipated in order to gradually increase power output P at a rate no greater than the maximum allowable ramp rate.

Notably, both triangular regions <b>1706</b> and <b>1708</b> begin after a change in the power output of PV field <b>1502</b> occurs. As such, both the decreasing ramp rate control and the increasing ramp rate control provided by system <b>1500</b> are reactionary processes triggered by a detected change in the power output. In some embodiments, a feedback control technique is used to perform ramp rate control in system <b>1500</b>. For example, controller <b>1514</b> may monitor power output <b>1516</b> and determine the absolute value of the time rate of change of power output <b>1516</b> (e.g., dP/dt or ΔP/Δt). Controller <b>1514</b> may initiate ramp rate control when the absolute value of the time rate of change of power output <b>1516</b> exceeds a threshold value.

Preemptive Ramp Rate Control

In some embodiments, controller <b>1514</b> is configured to predict when solar intensity disturbances will occur and may cause power inverter <b>1504</b> to ramp down the power output <b>1516</b> provided to energy grid <b>1512</b> preemptively. Instead of reacting to solar intensity disturbances after they occur, controller <b>1514</b> can actively predict solar intensity disturbances and preemptively ramp down power output <b>1516</b> before the disturbances affect PV field <b>1502</b>. Advantageously, this allows system controller <b>1514</b> to perform both ramp down control and ramp up control by using only a portion of the energy provided by PV field <b>1502</b> to generate power output <b>1516</b> while the power output of PV field <b>1502</b> is still high, rather than relying on energy from a battery. The remainder of the energy generated by PV field <b>1502</b> (i.e., the excess energy) may be stored in battery <b>1506</b> and/or dissipated.

In some embodiments, controller <b>1514</b> predicts solar intensity disturbances using input from one or more cloud detectors. The cloud detectors may include an array of solar intensity sensors. The solar intensity sensors may be positioned outside PV field <b>1502</b> or within PV field <b>1502</b>. Each solar intensity sensor may have a known location. In some embodiments, the locations of the solar intensity sensors are based on the geometry and orientation of PV field <b>1502</b>. For example, if PV field <b>1502</b> is rectangular, more sensors may be placed along its long side than along its short side. A cloud formation moving perpendicular to the long side may cover more area of PV field <b>1502</b> per unit time than a cloud formation moving perpendicular to the short side. Therefore, it may be desirable to include more sensors along the long side to more precisely detect cloud movement perpendicular to the long side. As another example, more sensors may be placed along the west side of PV field <b>1502</b> than along the east side of PV field <b>1502</b> since cloud movement from west to east is more common than cloud movement from east to west. The placement of sensors may be selected to detect approaching cloud formations without requiring unnecessary or redundant sensors.

The solar intensity sensors may be configured to measure solar intensity at various locations outside PV field <b>1502</b>. When the solar intensity measured by a particular solar intensity sensor drops below a threshold value, controller <b>1514</b> may determine that a cloud is currently casting a shadow on the solar intensity sensor. Controller <b>1514</b> may use input from multiple solar intensity sensors to determine various attributes of clouds approaching PV field <b>1502</b> and/or the shadows produced by such clouds. For example, if a shadow is cast upon two or more of the solar intensity sensors sequentially, controller <b>1514</b> may use the known positions of the solar intensity sensors and the time interval between each solar intensity sensor detecting the shadow to determine how fast the cloud/shadow is moving. If two or more of the solar intensity sensors are within the shadow simultaneously, controller <b>1514</b> may use the known positions of the solar intensity sensors to determine a position, size, and/or shape of the cloud/shadow.

Although the cloud detectors are described primarily as solar intensity sensors, it is contemplated that the cloud detectors may include any type of device configured to detect the presence of clouds or shadows cast by clouds. For example, the cloud detectors may include one or more cameras that capture visual images of cloud movement. The cameras may be upward-oriented cameras located below the clouds (e.g., attached to a structure on the Earth) or downward-oriented cameras located above the clouds (e.g., satellite cameras). Images from the cameras may be used to determine cloud size, position, velocity, and/or other cloud attributes. In some embodiments, the cloud detectors include radar or other meteorological devices configured to detect the presence of clouds, cloud density, cloud velocity, and/or other cloud attributes. In some embodiments, controller <b>1514</b> receives data from a weather service that indicates various cloud attributes.

Advantageously, controller <b>1514</b> may use the attributes of the clouds/shadows to determine when a solar intensity disturbance (e.g., a shadow) is approaching PV field <b>1502</b>. For example, controller <b>1514</b> may use the attributes of the clouds/shadows to determine whether any of the clouds are expected to cast a shadow upon PV field <b>1502</b>. If a cloud is expected to cast a shadow upon PV field <b>1502</b>, controller <b>1514</b> may use the size, position, and/or velocity of the cloud/shadow to determine a portion of PV field <b>1502</b> that will be affected. The affected portion of PV field <b>1502</b> may include some or all of PV field <b>1502</b>. Controller <b>1514</b> may use the attributes of the clouds/shadows to quantify a magnitude of the expected solar intensity disturbance (e.g., an expected decrease in power output from PV field <b>1502</b>) and to determine a time at which the disturbance is expected to occur (e.g., a start time, an end time, a duration, etc.).

In some embodiments, controller <b>1514</b> predicts a magnitude of the disturbance for each of a plurality of time steps. Controller <b>1514</b> may use the predicted magnitudes of the disturbance at each of the time steps to generate a predicted disturbance profile. The predicted disturbance profile may indicate how fast power output <b>1516</b> is expected to change as a result of the disturbance. Controller <b>1514</b> may compare the expected rate of change to a ramp rate threshold to determine whether ramp rate control is required. For example, if power output <b>1516</b> is predicted to decrease at a rate in excess of the maximum compliant ramp rate, controller <b>1514</b> may preemptively implement ramp rate control to gradually decrease power output <b>1516</b>.

In some embodiments, controller <b>1514</b> identifies the minimum expected value of power output <b>1516</b> and determines when the predicted power output is expected to reach the minimum value. Controller <b>1514</b> may subtract the minimum expected power output <b>1516</b> from the current power output <b>1516</b> to determine an amount by which power output <b>1516</b> is expected to decrease. Controller <b>1514</b> may apply the maximum allowable ramp rate to the amount by which power output <b>1516</b> is expected to decrease to determine a minimum time required to ramp down power output <b>1516</b> in order to comply with the maximum allowable ramp rate. For example, controller <b>1514</b> may divide the amount by which power output <b>1516</b> is expected to decrease (e.g., measured in units of power) by the maximum allowable ramp rate (e.g., measured in units of power per unit time) to identify the minimum time required to ramp down power output <b>1516</b>. Controller <b>1514</b> may subtract the minimum required time from the time at which the predicted power output is expected to reach the minimum value to determine when to start preemptively ramping down power output <b>1516</b>.

Advantageously, controller <b>1514</b> may preemptively act upon predicted disturbances by causing power inverter <b>1504</b> to ramp down power output <b>1516</b> before the disturbances affect PV field <b>1502</b>. This allows power inverter <b>1504</b> to ramp down power output <b>1516</b> by using only a portion of the energy generated by PV field <b>1502</b> to generate power output <b>1516</b> (i.e., performing the ramp down while the power output is still high), rather than requiring additional energy from a battery (i.e., performing the ramp down after the power output has decreased). The remainder of the energy generated by PV field <b>1502</b> (i.e., the excess energy) may be stored in battery <b>1506</b> and/or dissipated.

Referring now to <figref idref="DRAWINGS">FIG. 18</figref>, a graph <b>1800</b> illustrating a preemptive ramp rate control technique which can be used by controller <b>1514</b> is shown, according to an exemplary embodiment. Graph <b>1800</b> plots the power output P provided to energy grid <b>1512</b> as a function of time t. The solid line <b>1802</b> illustrates power output P without any ramp rate control, whereas the broken line <b>1804</b> illustrates power output P with preemptive ramp rate control.

Between times t₀and t₂, power output P is at a high value P_high. At time t₂, a cloud begins to cast its shadow on PV field <b>1502</b>, causing the power output of PV field <b>1502</b> to suddenly decrease, until PV field <b>1502</b> is completely in shadow at time t₃. Without any ramp rate control, the sudden drop in power output from PV field <b>1502</b> causes the power output P to rapidly drop from P_highto a low value P_lowbetween times t₂and t₃. However, with preemptive ramp rate control, controller <b>1514</b> preemptively causes power inverter <b>1504</b> to begin ramping down power output P at time t₁, prior to the cloud casting a shadow on PV field <b>1502</b>. The preemptive ramp down occurs between times t₁and t₃, resulting in a ramp rate that is relatively more gradual. Triangular region <b>1806</b> represents the energy generated by PV field <b>1502</b> in excess of the ramp rate limit. The excess energy may be limited by power inverter <b>1504</b> and/or stored in battery <b>1506</b> to gradually decrease power output P at a rate no greater than the ramp rate limit.

Between times t₃and t₄, PV field <b>1502</b> is completely in shadow. At time t₄, the shadow cast by the cloud begins to move off PV field <b>1502</b>, causing the power output of PV field <b>1502</b> to suddenly increase, until PV field <b>1502</b> is entirely in sunlight at time t₅. Without any ramp rate control, the sudden increase in power output from PV field <b>1502</b> causes the power output P to rapidly increase to the high value P_highat time t₅. However, with ramp rate control, power inverter <b>1504</b> uses only a portion of the energy from PV field <b>1502</b> to gradually increase power output P to P_highat time t₆. Triangular region <b>1808</b> represents the energy generated by PV field <b>1502</b> in excess of the ramp rate limit. The excess energy may be limited by power inverter <b>1504</b> and/or stored in battery <b>1506</b> to gradually increase power output P at a rate no greater than the ramp rate limit.

Notably, a significant portion of triangular region <b>1806</b> occurs between times t₁and t₂, before the disturbance affects PV field <b>1502</b>. As such, the decreasing ramp rate control provided by system <b>1500</b> is a preemptive process triggered by detecting an approaching cloud, prior to the cloud casting a shadow upon PV field <b>1502</b>. In some embodiments, controller <b>1514</b> uses a predictive control technique (e.g., feedforward control, model predictive control, etc.) to perform ramp down control in system <b>1500</b>. For example, controller <b>1514</b> may actively monitor the positions, sizes, velocities, and/or other attributes of clouds/shadows that could potentially cause a solar intensity disturbance affecting PV field <b>1502</b>. When an approaching cloud is detected at time t₁, controller <b>1514</b> may preemptively cause power inverter <b>1504</b> to begin ramping down power output <b>1516</b>. This allows power inverter <b>1504</b> to ramp down power output <b>1516</b> by limiting the energy generated by PV field <b>1502</b> while the power output is still high, rather than requiring additional energy from a battery to perform the ramp down once the power output has dropped.

Frequency Regulation and Ramp Rate Controller

Referring now to <figref idref="DRAWINGS">FIG. 19</figref>, a block diagram illustrating controller <b>1514</b> in greater detail is shown, according to an exemplary embodiment. Controller <b>1514</b> is shown to include a communications interface <b>1902</b> and a processing circuit <b>1904</b>. Communications interface <b>1902</b> may 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 interface <b>1502</b> may 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 interface <b>1902</b> may 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 interface <b>1902</b> may be a network interface configured to facilitate electronic data communications between controller <b>1514</b> and various external systems or devices (e.g., PV field <b>1502</b>, energy grid <b>1512</b>, PV field power inverter <b>1504</b>, battery power inverter <b>1508</b>, etc.). For example, controller <b>1514</b> may receive a PV power signal from PV field <b>1502</b> indicating the current value of the PV power P_PVgenerated by PV field <b>1502</b>. Controller <b>1514</b> may use the PV power signal to predict one or more future values for the PV power P_PVand generate a ramp rate setpoint u_RR. Controller <b>1514</b> may receive a grid frequency signal from energy grid <b>1512</b> indicating the current value of the grid frequency. Controller <b>1514</b> may use the grid frequency to generate a frequency regulation setpoint u_RR. Controller <b>1514</b> may use the ramp rate setpoint u_RRand the frequency regulation setpoint u_RRto generate a battery power setpoint u_batand may provide the battery power setpoint u_batto battery power inverter <b>1508</b>. Controller <b>1514</b> may use the battery power setpoint u_batto generate a PV power setpoint u_PVand may provide the PV power setpoint u_PVto PV field power inverter <b>1504</b>.

Still referring to <figref idref="DRAWINGS">FIG. 19</figref>, processing circuit <b>1904</b> is shown to include a processor <b>1906</b> and memory <b>1908</b>. Processor <b>1906</b> may 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. Processor <b>1906</b> may be configured to execute computer code or instructions stored in memory <b>1908</b> or received from other computer readable media (e.g., CDROM, network storage, a remote server, etc.).

Memory <b>1908</b> may 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. Memory <b>1908</b> may 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. Memory <b>1908</b> may 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. Memory <b>1908</b> may be communicably connected to processor <b>1906</b> via processing circuit <b>1904</b> and may include computer code for executing (e.g., by processor <b>1906</b>) one or more processes described herein.

Predicting PV Power Output

Still referring to <figref idref="DRAWINGS">FIG. 19</figref>, controller <b>1514</b> is shown to include a PV power predictor <b>1912</b>. PV power predictor <b>1912</b> may receive the PV power signal from PV field <b>1502</b> and use the PV power signal to make a short term prediction of the photovoltaic power output P_PV. In some embodiments, PV power predictor <b>1912</b> predicts the value of P_PVfor the next time step (i.e., a one step ahead prediction). For example, at each time step k, PV power predictor <b>1912</b> may predict the value of the PV power output P_PVfor the next time step k+1 (i.e., {circumflex over (P)}_PV(k+1)). Advantageously, predicting the next value for the PV power output P_PVallows controller <b>1514</b> to predict the ramp rate and perform an appropriate control action to prevent the ramp rate from exceeding the ramp rate compliance limit.

In some embodiments, PV power predictor <b>1912</b> performs a time series analysis to predict P_PV(k+1). A time series may be defined by an ordered sequence of values of a variable at equally spaced intervals. PV power predictor <b>1912</b> may model changes between values of P_PVover time using an autoregressive moving average (ARMA) model or an autoregressive integrated moving average (ARIMA) model. PV power predictor <b>1912</b> may use the model to predict the next value of the PV power output P_PVand correct the prediction using a Kalman filter each time a new measurement is acquired. The time series analysis technique is described in greater detail in the following paragraphs.

In some embodiments, PV power predictor <b>1912</b> uses a technique in the Box-Jenkins family of techniques to perform the time series analysis. These techniques are statistical tools that use past data (e.g., lags) to predict or correct new data, and other techniques to find the parameters or coefficients of the time series. A general representation of a time series from the Box-Jenkins approach is:

<maths id="MATH-US-00024" num="00024"><math overflow="scroll"><mrow><mrow><msub><mi>X</mi><mi>k</mi></msub><mo>-</mo><mrow><munderover><mo>∑</mo><mrow><mi>r</mi><mo>=</mo><mn>1</mn></mrow><mi>p</mi></munderover><mo></mo><mrow><msub><mi>ϕ</mi><mi>r</mi></msub><mo></mo><msub><mi>X</mi><mrow><mi>k</mi><mo>-</mo><mi>r</mi></mrow></msub></mrow></mrow></mrow><mo>=</mo><mrow><munderover><mo>∑</mo><mrow><mi>s</mi><mo>=</mo><mn>0</mn></mrow><mi>q</mi></munderover><mo></mo><mrow><msub><mi>θ</mi><mi>s</mi></msub><mo></mo><msub><mi>ε</mi><mrow><mi>k</mi><mo>-</mo><mi>s</mi></mrow></msub></mrow></mrow></mrow></math></maths>

which is known as an ARMA process. In this representation, the parameters p and q define the order and number of lags of the time series, φ is an autoregressive parameter, and θ is a moving average parameter. This representation is desirable for a stationary process which has a mean, variance, and autocorrelation structure that does not change over time. However, if the original process {Y_k} representing the time series values of P_PVis not stationary, x_kcan represent the first difference (or higher order difference) of the process {Y_k−Y_k−1}. If the difference is stationary, PV power predictor <b>1912</b> may model the process as an ARIMA process.

PV power predictor <b>1912</b> may be configured to determine whether to use an ARMA model or an ARIMA model to model the time series of the PV power output P_PV. Determining whether to use an ARMA model or an ARIMA model may include identifying whether the process is stationary. In some embodiments, the power output P_PVis not stationary. However, the first difference Y_k−Y_k−1may be stationary. Accordingly, PV power predictor <b>1912</b> may select an ARIMA model to represent the time series of P_PV.

PV power predictor <b>1912</b> may find values for the parameters p and q that define the order and the number of lags of the time series. In some embodiments, PV power predictor <b>1912</b> finds values for p and q by checking the partial autocorrelation function (PACF) and selecting a number where the PACF approaches zero (e.g., p=q). For some time series data, PV power predictor <b>1912</b> may determine that a 4^thor 5^thorder model is appropriate. However, it is contemplated that PV power predictor <b>1912</b> may select a different model order to represent different time series processes.

PV power predictor <b>1912</b> may find values for the autoregressive parameter φ_{1 . . . p}and the moving average parameter δ_{1 . . . 4}. In some embodiments, PV power predictor <b>1912</b> uses an optimization algorithm to find values for φ_{1 . . . p}and θ_{1 . . . q}given the time series data {Y_k}. For example, PV power predictor <b>1912</b> may generate a discrete-time ARIMA model of the form:

<maths id="MATH-US-00025" num="00025"><math overflow="scroll"><mrow><mrow><mrow><mi>A</mi><mo></mo><mrow><mo>(</mo><mi>z</mi><mo>)</mo></mrow></mrow><mo></mo><mrow><mi>y</mi><mo></mo><mrow><mo>(</mo><mi>k</mi><mo>)</mo></mrow></mrow></mrow><mo>=</mo><mrow><mrow><mo>[</mo><mfrac><mrow><mi>C</mi><mo></mo><mrow><mo>(</mo><mi>z</mi><mo>)</mo></mrow></mrow><mrow><mn>1</mn><mo>-</mo><msup><mi>z</mi><mrow><mo>-</mo><mn>1</mn></mrow></msup></mrow></mfrac><mo>]</mo></mrow><mo></mo><mrow><mi>e</mi><mo></mo><mrow><mo>(</mo><mi>t</mi><mo>)</mo></mrow></mrow></mrow></mrow></math></maths>

where A(z) and C(z) are defined as follows:

&lt;br /&gt;<i>A</i>(<i>z</i>)=1+φ₁<i>z</i>⁻¹+φ₂<i>z</i>⁻²φ₃<i>z</i>⁻³φ₄<i>z</i>⁻⁴

&lt;br /&gt;<i>C</i>(<i>z</i>)=1+θ₁<i>z</i>⁻¹+θ₂<i>z</i>⁻²+θ₃<i>z</i>⁻³+θ₄<i>z</i>⁻⁴

where the values for φ_{1 . . . p}and θ_{1 . . . q}are determined by fitting the model to the time series values of P_PV.

In some embodiments, PV power predictor <b>1912</b> uses the ARIMA model as an element of a Kalman filter. The Kalman filter may be used by PV power predictor <b>1912</b> to correct the estimated state and provide tighter predictions based on actual values of the PV power output P_PV. In order to use the ARIMA model with the Kalman filter, PV power predictor <b>1912</b> may generate a discrete-time state-space representation of the ARIMA model of the form:

&lt;br /&gt;<i>x</i>(<i>k+</i>1)=<i>Ax</i>(<i>k</i>)+<i>Ke</i>(<i>k</i>)

&lt;br /&gt;<i>y</i>(<i>k</i>)=<i>Cx</i>(<i>k</i>)+<i>e</i>(<i>k</i>)

where y(k) represents the values of the PV power output P_PVand e(k) is a disturbance considered to be normal with zero mean and a variance derived from the fitted model. It is contemplated that the state-space model can be represented in a variety of different forms. For example, the ARIMA model can be rewritten as a difference equation and used to generate a different state-space model using state-space modeling techniques. In various embodiments, PV power predictor <b>1912</b> may use any of a variety of different forms of the state-space model.

The discrete Kalman filter consists of an iterative process that takes a state-space model and forwards it in time until there are available data to correct the predicted state and obtain a better estimate. The correction may be based on the evolution of the mean and covariance of an assumed white noise system. For example, PV power predictor <b>1912</b> may use a state-space model of the following form:

&lt;br /&gt;<i>x</i>(<i>k+</i>1)=<i>Ax</i>(<i>k</i>)+<i>Bu</i>(<i>k</i>)+<i>w</i>(<i>k</i>)<i>w</i>(<i>k</i>)˜<i>N</i>(0,<i>Q</i>)

&lt;br /&gt;<i>y</i>(<i>k</i>)=<i>Cx</i>(<i>k</i>)+<i>Du</i>(<i>k</i>)+<i>v</i>(<i>k</i>)<i>v</i>(<i>k</i>)˜<i>N</i>(0,<i>R</i>)

where N( ) represents a normal distribution, v(k) is the measurement error having zero mean and variance R, and w(k) is the process error having zero mean and variance Q. The values of R and Q are design choices. The variable x(k) is a state of the process and the variable y(k) represents the PV power output P_PV(k). This representation is referred to as a stochastic state-space representation.

PV power predictor <b>1912</b> may use the Kalman filter to perform an iterative process to predict {circumflex over (P)}_PV(k+1) based on the current and previous values of P_PV(e.g., P_PV(k), P_PV(k−1), etc.). The iterative process may include a prediction step and an update step. The prediction step moves the state estimate forward in time using the following equations:

&lt;br /&gt;<i>{circumflex over (x)}</i>⁻(<i>k+</i>1)=<i>A*{circumflex over (x)}</i>(<i>k</i>)

&lt;br /&gt;<i>P</i>⁻(<i>k+</i>1)=<i>A*P</i>(<i>k</i>)*<i>A</i>^T<i>+Q </i>

where {circumflex over (x)}(k) is the mean of the process or estimated state at time step k and P(k) is the covariance of the process at time step k. The super index “−” indicates that the estimated state {circumflex over (x)}⁻(k+1) is based on the information known prior to time step k+1 (i.e., information up to time step k). In other words, the measurements at time step k+1 have not yet been incorporated to generate the state estimate {circumflex over (x)}⁻(k+1). This is known as an a priori state estimate.

PV power predictor <b>1912</b> may predict the PV power output {circumflex over (P)}_PV(k+1) by determining the value of the predicted measurement ŷ⁻(k+1). As previously described, the measurement y(k) and the state x(k) are related by the following equation:

&lt;br /&gt;<i>y</i>(<i>k</i>)=<i>Cx</i>(<i>k</i>)+<i>e</i>(<i>k</i>)

which allows PV power predictor <b>1912</b> to predict the measurement ŷ⁻(k+1) as a function of the predicted state {circumflex over (x)}⁻(k+1). PV power predictor <b>1912</b> may use the measurement estimate ŷ⁻(k+1) as the value for the predicted PV power output {circumflex over (P)}_PV(k+1) (i.e., {circumflex over (P)}_PV(k+1)=ŷ⁻(k+1)).

The update step uses the following equations to correct the a priori state estimate {circumflex over (x)}⁻(k+1) based on the actual (measured) value of y(k+1):

&lt;br /&gt;<i>K=P</i>⁻(<i>k+</i>1)*<i>C</i>^T<i>*[R+C*P</i>⁻(<i>k+</i>1)*<i>C</i>^T]⁻¹

&lt;br /&gt;{circumflex over (<i>x</i>)}(<i>k+</i>1)=<i>{circumflex over (x)}</i>⁻(<i>k+</i>1)+<i>K*[y</i>(<i>k+</i>1)−<i>C*{circumflex over (x)}</i>⁻(<i>k+</i>1)]

&lt;br /&gt;<i>P</i>(<i>k+</i>1)=<i>P</i>⁻(<i>k+</i>1)−<i>K*[R+C*P</i>⁻(<i>k+</i>1)*<i>C</i>^T<i>]*K</i>^T

where y(k+1) corresponds to the actual measured value of P_PV(k+1). The variable {circumflex over (x)}(k+1) represents the a posteriori estimate of the state x at time k+1 given the information known up to time step k+1. The update step allows PV power predictor <b>1912</b> to prepare the Kalman filter for the next iteration of the prediction step.

Although PV power predictor <b>1912</b> is primarily described as using a time series analysis to predict {circumflex over (P)}_PV(k+1), it is contemplated that PV power predictor <b>1912</b> may use any of a variety of techniques to predict the next value of the PV power output P_PV. For example, PV power predictor <b>1912</b> may use a deterministic plus stochastic model trained from historical PV power output values (e.g., linear regression for the deterministic portion and an AR model for the stochastic portion). This technique is described in greater detail 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 entirety of which is incorporated by reference herein.

In other embodiments, PV power predictor <b>1912</b> uses input from cloud detectors (e.g., cameras, light intensity sensors, radar, etc.) to predict when an approaching cloud will cast a shadow upon PV field <b>1502</b>. When an approaching cloud is detected, PV power predictor <b>1912</b> may estimate an amount by which the solar intensity will decrease as a result of the shadow and/or increase once the shadow has passed PV field <b>1502</b>. PV power predictor <b>1912</b> may use the predicted change in solar intensity to predict a corresponding change in the PV power output P_PV. This technique is described in greater detail in U.S. Provisional Patent Application No. 62/239,131 titled “Systems and Methods for Controlling Ramp Rate in a Photovoltaic Energy System” and filed Oct. 8, 2015, the entirety of which is incorporated by reference herein. PV power predictor <b>1912</b> may provide the predicted PV power output P_PV(k+1) to ramp rate controller <b>1914</b>.

Controlling Ramp Rate

Still referring to <figref idref="DRAWINGS">FIG. 19</figref>, controller <b>1514</b> is shown to include a ramp rate controller <b>1914</b>. Ramp rate controller <b>1914</b> may be configured to determine an amount of power to charge or discharge from battery <b>1506</b> for ramp rate control (i.e., u_RR). Advantageously, ramp rate controller <b>1914</b> may determine a value for the ramp rate power u_RRthat simultaneously maintains the ramp rate of the PV power (i.e., u_RR+P_PV) within compliance limits while allowing controller <b>1514</b> to regulate the frequency of energy grid <b>1512</b> and while maintaining the state-of-charge of battery <b>1506</b> within a predetermined desirable range.

In some embodiments, the ramp rate of the PV power is within compliance limits as long as the actual ramp rate evaluated over a one minute interval does not exceed ten percent of the rated capacity of PV field <b>1502</b>. The actual ramp rate may be evaluated over shorter intervals (e.g., two seconds) and scaled up to a one minute interval. Therefore, a ramp rate may be within compliance limits if the ramp rate satisfies one or more of the following inequalities:

<maths id="MATH-US-00026" num="00026"><math overflow="scroll"><mrow><mrow><mo></mo><mi>rr</mi><mo></mo></mrow><mo>&lt;</mo><mrow><mfrac><mrow><mn>0.1</mn><mo></mo><msub><mi>P</mi><mi>cap</mi></msub></mrow><mn>30</mn></mfrac><mo></mo><mrow><mo>(</mo><mrow><mn>1</mn><mo>+</mo><mi>tolerance</mi></mrow><mo>)</mo></mrow></mrow></mrow></math></maths><maths id="MATH-US-00026-2" num="00026.2"><math overflow="scroll"><mrow><mrow><mo></mo><mi>RR</mi><mo></mo></mrow><mo>&lt;</mo><mrow><mn>0.1</mn><mo></mo><mrow><msub><mi>P</mi><mi>cap</mi></msub><mo></mo><mrow><mo>(</mo><mrow><mn>1</mn><mo>+</mo><mi>tolerance</mi></mrow><mo>)</mo></mrow></mrow></mrow></mrow></math></maths>

where rr is the ramp rate calculated over a two second interval, RR is the ramp rate calculated over a one minute interval, P_capis the rated capacity of PV field <b>1502</b>, and tolerance is an amount by which the actual ramp rate can exceed the compliance limit without resulting in a non-compliance violation (e.g., tolerance=10%). In this formulation, the ramp rates rr and RR represent a difference in the PV power (e.g., measured in kW) at the beginning and end of the ramp rate evaluation interval.

Simultaneous implementation of ramp rate control and frequency regulation can be challenging (e.g., can result in non-compliance), especially if the ramp rate is calculated as the difference in the power P_POIat POI <b>1510</b>. In some embodiments, the ramp rate over a two second interval is defined as follows:

&lt;br /&gt;<i>rr=[P</i>_POI(<i>k</i>)−<i>P</i>_POI(<i>k−</i>1)]−[<i>u</i>_FR(<i>k</i>)−<i>u</i>_FR(<i>k−</i>1)]

where P_POI(k−1) and P_POI(k) are the total powers at POI <b>1510</b> measured at the beginning and end, respectively, of a two second interval, and u_FR(k−1) and u_FR(k) are the powers used for frequency regulation measured at the beginning and end, respectively, of the two second interval.

The total power at POI <b>1510</b> (i.e., P_POI) is the sum of the power output of PV field power inverter <b>1504</b> (i.e., u_PV) and the power output of battery power inverter <b>1508</b> (i.e., u_bat=u_FR+u_RR). Assuming that PV field power inverter <b>1504</b> is not limiting the power P_PVgenerated by PV field <b>1502</b>, the output of PV field power inverter <b>1504</b> u_PVmay be equal to the PV power output P_PV(i.e., P_PV=u_PV) and the total power P_POIat POI <b>1510</b> can be calculated using the following equation:

&lt;br /&gt;<i>P</i>_POI<i>=P</i>_PV<i>+u</i>_FR<i>+u</i>_RR

Therefore, the ramp rate rr can be rewritten as:

&lt;br /&gt;<i>rr=P</i>_PV(<i>k</i>)−<i>P</i>_PV(<i>k+</i>1)+<i>u</i>_RR(<i>k</i>)−<i>u</i>_RR(<i>k+</i>1)

and the inequality which must be satisfied to comply with the ramp rate limit can be rewritten as:

<maths id="MATH-US-00027" num="00027"><math overflow="scroll"><mrow><mrow><mo></mo><mrow><mrow><msub><mi>P</mi><mi>PV</mi></msub><mo></mo><mrow><mo>(</mo><mi>k</mi><mo>)</mo></mrow></mrow><mo>-</mo><mrow><msub><mi>P</mi><mi>PV</mi></msub><mo></mo><mrow><mo>(</mo><mrow><mi>k</mi><mo>-</mo><mn>1</mn></mrow><mo>)</mo></mrow></mrow><mo>+</mo><mrow><msub><mi>u</mi><mi>RR</mi></msub><mo></mo><mrow><mo>(</mo><mi>k</mi><mo>)</mo></mrow></mrow><mo>-</mo><mrow><msub><mi>u</mi><mi>RR</mi></msub><mo></mo><mrow><mo>(</mo><mrow><mi>k</mi><mo>-</mo><mn>1</mn></mrow><mo>)</mo></mrow></mrow></mrow><mo></mo></mrow><mo>&lt;</mo><mrow><mfrac><mrow><mn>0.1</mn><mo></mo><msub><mi>P</mi><mi>cap</mi></msub></mrow><mn>30</mn></mfrac><mo></mo><mrow><mo>(</mo><mrow><mn>1</mn><mo>+</mo><mi>tolerance</mi></mrow><mo>)</mo></mrow></mrow></mrow></math></maths>

where P_PV(k−1) and P_PV(k) are the power outputs of PV field <b>1502</b> measured at the beginning and end, respectively, of the two second interval, and u_RR(k−1) and u_RR(k) are the powers used for ramp rate control measured at the beginning and end, respectively, of the two second interval.

In some embodiments, ramp rate controller <b>1914</b> determines the ramp rate compliance of a facility based on the number of scans (i.e., monitored intervals) in violation that occur within a predetermined time period (e.g., one week) and the total number of scans that occur during the predetermined time period. For example, the ramp rate compliance RRC may be defined as a percentage and calculated as follows:

<maths id="MATH-US-00028" num="00028"><math overflow="scroll"><mrow><mi>RRC</mi><mo>=</mo><mrow><mn>100</mn><mo></mo><mrow><mo>(</mo><mrow><mn>1</mn><mo>-</mo><mfrac><msub><mi>n</mi><mi>vscan</mi></msub><msub><mi>n</mi><mi>tscan</mi></msub></mfrac></mrow><mo>)</mo></mrow></mrow></mrow></math></maths>

where n_vscanis the number of scans over the predetermined time period where rr is in violation and n_tscanis the total number of scans during which the facility is performing ramp rate control during the predetermined time period.

In some embodiments, the intervals that are monitored or scanned to determine ramp rate compliance are selected arbitrarily or randomly (e.g., by a power utility). Therefore, it may be impossible to predict which intervals will be monitored. Additionally, the start times and end times of the intervals may be unknown. In order to guarantee ramp rate compliance and minimize the number of scans where the ramp rate is in violation, ramp rate controller <b>1914</b> may determine the amount of power u_RRused for ramp rate control ahead of time. In other words, ramp rate controller <b>1914</b> may determine, at each instant, the amount of power u_RRto be used for ramp rate control at the next instant. Since the start and end times of the intervals may be unknown, ramp rate controller <b>1914</b> may perform ramp rate control at smaller time intervals (e.g., on the order of milliseconds).

Ramp rate controller <b>1914</b> may use the predicted PV power {circumflex over (P)}_PV(k+1) at instant k+1 and the current PV power P_PV(k) at instant k to determine the ramp rate control power û_RR_{<sub2>T</sub2>}(k) at instant k. Advantageously, this allows ramp rate controller <b>1914</b> to determine whether the PV power P_PVis in an up-ramp, a down-ramp, or no-ramp at instant k. Assuming a T seconds time resolution, ramp rate controller <b>1914</b> may determine the value of the power for ramp rate control û_RR_{<sub2>T</sub2>}(k) at instant k based on the predicted value of the PV power {circumflex over (P)}_PV(k+1), the current value of the PV power P_PV(k), and the previous power used for ramp rate control û_RR_{<sub2>T</sub2>}(k−1). Scaling to T seconds and assuming a tolerance of zero, ramp rate compliance is guaranteed if û_RR_{<sub2>T</sub2>}(k) satisfies the following inequality:

&lt;br /&gt;<i>lb</i>_RR_{<sub2>T</sub2>}<i>≦û</i>_RR_{<sub2>T</sub2>}<i>≦ub</i>_RR_{<sub2>T </sub2>}

where T is the sampling time in seconds, lb_RR_{<sub2>T </sub2>}is the lower bound on û_RR_{<sub2>T</sub2>}(k), and ub_RR_{<sub2>T </sub2>}is the upper bound on û_RR_{<sub2>T</sub2>}(k).

In some embodiments, the lower bound lb_RR_{<sub2>T </sub2>}and the upper bound ub_RR_{<sub2>T </sub2>}are defined as follows:

<maths id="MATH-US-00029" num="00029"><math overflow="scroll"><mrow><mrow><mi>l</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><msub><mi>b</mi><msub><mi>RR</mi><mi>T</mi></msub></msub></mrow><mo>=</mo><mrow><mrow><mo>-</mo><mrow><mo>(</mo><mrow><mrow><msub><mover><mi>P</mi><mo>^</mo></mover><mi>PV</mi></msub><mo></mo><mrow><mo>(</mo><mrow><mi>k</mi><mo>+</mo><mn>1</mn></mrow><mo>)</mo></mrow></mrow><mo>-</mo><mrow><msub><mi>P</mi><mi>PV</mi></msub><mo></mo><mrow><mo>(</mo><mi>k</mi><mo>)</mo></mrow></mrow></mrow><mo>)</mo></mrow></mrow><mo>+</mo><mrow><msub><mover><mi>u</mi><mo>^</mo></mover><msub><mi>RR</mi><mi>T</mi></msub></msub><mo></mo><mrow><mo>(</mo><mrow><mi>k</mi><mo>-</mo><mn>1</mn></mrow><mo>)</mo></mrow></mrow><mo>-</mo><mfrac><mrow><mn>0.1</mn><mo></mo><msub><mi>P</mi><mi>cap</mi></msub></mrow><mrow><mn>60</mn><mo>/</mo><mi>T</mi></mrow></mfrac><mo>+</mo><mrow><mi>λ</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>σ</mi></mrow></mrow></mrow></math></maths><maths id="MATH-US-00029-2" num="00029.2"><math overflow="scroll"><mrow><msub><mi>ub</mi><msub><mi>RR</mi><mi>T</mi></msub></msub><mo>=</mo><mrow><mrow><mo>-</mo><mrow><mo>(</mo><mrow><mrow><msub><mover><mi>P</mi><mo>^</mo></mover><mi>PV</mi></msub><mo></mo><mrow><mo>(</mo><mrow><mi>k</mi><mo>+</mo><mn>1</mn></mrow><mo>)</mo></mrow></mrow><mo>-</mo><mrow><msub><mi>P</mi><mi>PV</mi></msub><mo></mo><mrow><mo>(</mo><mi>k</mi><mo>)</mo></mrow></mrow></mrow><mo>)</mo></mrow></mrow><mo>+</mo><mrow><msub><mover><mi>u</mi><mo>^</mo></mover><msub><mi>RR</mi><mi>T</mi></msub></msub><mo></mo><mrow><mo>(</mo><mrow><mi>k</mi><mo>-</mo><mn>1</mn></mrow><mo>)</mo></mrow></mrow><mo>+</mo><mfrac><mrow><mn>0.1</mn><mo></mo><msub><mi>P</mi><mi>cap</mi></msub></mrow><mrow><mn>60</mn><mo>/</mo><mi>T</mi></mrow></mfrac><mo>-</mo><mrow><mi>λ</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>σ</mi></mrow></mrow></mrow></math></maths>

where σ is the uncertainty on the PV power prediction and λ is a scaling factor of the uncertainty in the PV power prediction. Advantageously, the lower bound lb_RR_{<sub2>T </sub2>}and the upper bound ub_RR_{<sub2>T </sub2>}provide a range of ramp rate power û_RR_{<sub2>T</sub2>}(k) that guarantees compliance of the rate of change in the PV power.

In some embodiments, ramp rate controller <b>1914</b> determines the ramp rate power û_RR_{<sub2>T</sub2>}(k) based on whether the PV power P_PVis in an up-ramp, a down-ramp, or no-ramp (e.g., the PV power is not changing or changing at a compliant rate) at instant k. Ramp rate controller <b>1914</b> may also consider the state-of-charge (SOC) of battery <b>1506</b> when determining û_RR_{<sub2>T</sub2>}(k). Exemplary processes which may be performed by ramp rate controller <b>1914</b> to generate values for the ramp rate power û_RR_{<sub2>T</sub2>}(k) are described in detail in U.S. Patent Application No. 62/239,245. Ramp rate controller <b>1914</b> may provide the ramp rate power setpoint û_RR_{<sub2>T</sub2>}(k) to battery power setpoint generator <b>1918</b> for use in determining the battery power setpoint u_bat.

Controlling Frequency Regulation

Referring again to <figref idref="DRAWINGS">FIG. 19</figref>, controller <b>1514</b> is shown to include a frequency regulation controller <b>1916</b>. Frequency regulation controller <b>1916</b> may be configured to determine an amount of power to charge or discharge from battery <b>1506</b> for frequency regulation (i.e., u_FR). Frequency regulation controller <b>1916</b> is shown receiving a grid frequency signal from energy grid <b>1512</b>. The grid frequency signal may specify the current grid frequency f_gridof energy grid <b>1512</b>. In some embodiments, the grid frequency signal also includes a scheduled or desired grid frequency f_sto be achieved by performing frequency regulation. Frequency regulation controller <b>1916</b> may determine the frequency regulation setpoint u_FRbased on the difference between the current grid frequency f_gridand the scheduled frequency f_s.

In some embodiments, the range within which the grid frequency f_gridis allowed to fluctuate is determined by an electric utility. Any frequencies falling outside the permissible range may be corrected by performing frequency regulation. Facilities participating in frequency regulation may be required to supply or consume a contracted power for purposes of regulating grid frequency f_grid(e.g., up to 10% of the rated capacity of PV field <b>1502</b> per frequency regulation event).

In some embodiments, frequency regulation controller <b>1916</b> performs frequency regulation using a dead-band control technique with a gain that is dependent upon the difference f_ebetween the scheduled grid frequency f_sand the actual grid frequency f_grid(i.e., f_e=f_s−f_grid) and an amount of power required for regulating a given deviation amount of frequency error f_e. Such a control technique is expressed mathematically by the following equation:

&lt;br /&gt;<i>u</i>_FR(<i>k</i>)=min(max(<i>lb</i>_FR,α),<i>ub</i>_FR)

where lb_FRand ub_FRare the contracted amounts of power up to which power is to be consumed or supplied by a facility. lb_FRand ub_FRmay be based on the rated capacity P_capof PV field <b>1502</b> as shown in the following equations:

&lt;br /&gt;<i>lb</i>_FR=−0.1×<i>P</i>_cap

&lt;br /&gt;<i>ub</i>_FR=0.1×<i>P</i>_cap

The variable α represents the required amount of power to be supplied or consumed from energy grid <b>1512</b> to offset the frequency error f_e. In some embodiments, frequency regulation controller <b>1916</b> calculates a using the following equation:

&lt;br /&gt;α=<i>K</i>_FR×sign(<i>f</i>_e)×max(|<i>f</i>_e<i>|−d</i>_band,0)

where d_bandis the threshold beyond which a deviation in grid frequency must be regulated and K_FRis the control gain. In some embodiments, frequency regulation controller <b>1916</b> calculates the control gain K_FRas follows:

<maths id="MATH-US-00030" num="00030"><math overflow="scroll"><mrow><msub><mi>K</mi><mi>FR</mi></msub><mo>=</mo><mfrac><msub><mi>P</mi><mi>cap</mi></msub><mrow><mn>0.01</mn><mo>×</mo><mi>droop</mi><mo>×</mo><msub><mi>f</mi><mi>s</mi></msub></mrow></mfrac></mrow></math></maths>

where droop is a parameter specifying a percentage that defines how much power must be supplied or consumed to offset a 1 Hz deviation in the grid frequency. Frequency regulation controller <b>1916</b> may calculate the frequency regulation setpoint u_FRusing these equations and may provide the frequency regulation setpoint to battery power setpoint generator <b>1918</b>.

Generating Battery Power Setpoints

Still referring to <figref idref="DRAWINGS">FIG. 19</figref>, controller <b>1514</b> is shown to include a battery power setpoint generator <b>1918</b>. Battery power setpoint generator <b>1918</b> may be configured to generate the battery power setpoint u_batfor battery power inverter <b>1508</b>. The battery power setpoint u_batis used by battery power inverter <b>1508</b> to control an amount of power drawn from battery <b>1506</b> or stored in battery <b>1506</b>. For example, battery power inverter <b>1508</b> may draw power from battery <b>1506</b> in response to receiving a positive battery power setpoint u_batfrom battery power setpoint generator <b>1918</b> and may store power in battery <b>1506</b> in response to receiving a negative battery power setpoint u_batfrom battery power setpoint generator <b>1918</b>.

Battery power setpoint generator <b>1918</b> is shown receiving the ramp rate power setpoint u_RRfrom ramp rate controller <b>1914</b> and the frequency regulation power setpoint u_FRfrom frequency regulation controller <b>1916</b>. In some embodiments, battery power setpoint generator <b>1918</b> calculates a value for the battery power setpoint u_batby adding the ramp rate power setpoint u_RRand the frequency response power setpoint u_FR. For example, battery power setpoint generator <b>1918</b> may calculate the battery power setpoint u_batusing the following equation:

&lt;br /&gt;<i>u</i>_bat<i>=u</i>_RR<i>+u</i>_FR

In some embodiments, battery power setpoint generator <b>1918</b> adjusts the battery power setpoint u_batbased on a battery power limit for battery <b>1506</b>. For example, battery power setpoint generator <b>1918</b> may compare the battery power setpoint u_batwith the battery power limit battPowerLimit. If the battery power setpoint is greater than the battery power limit (i.e., u_bat&gt;battPowerLimit), battery power setpoint generator <b>1918</b> may replace the battery power setpoint u_batwith the battery power limit. Similarly, if the battery power setpoint is less than the negative of the battery power limit (i.e., u_bat&lt;−battPowerLimit), battery power setpoint generator <b>1918</b> may replace the battery power setpoint u_batwith the negative of the battery power limit.

In some embodiments, battery power setpoint generator <b>1918</b> causes frequency regulation controller <b>1916</b> to update the frequency regulation setpoint u_FRin response to replacing the battery power setpoint u_batwith the battery power limit battPowerLimit or the negative of the battery power limit −battPowerLimit. For example, if the battery power setpoint u_batis replaced with the positive battery power limit battPowerLimit, frequency regulation controller <b>1916</b> may update the frequency regulation setpoint u_FRusing the following equation:

&lt;br /&gt;<i>u</i>_FR(<i>k</i>)=<i>battPowerLimit−û</i>_RR_{<sub2>T</sub2>}(<i>k</i>)

Similarly, if the battery power setpoint u_batis replaced with the negative battery power limit −battPowerLimit, frequency regulation controller <b>1916</b> may update the frequency regulation setpoint u_FRusing the following equation:

&lt;br /&gt;<i>u</i>_FR(<i>k</i>)=−<i>battPowerLimit−û</i>_RR_{<sub2>T</sub2>}(<i>k</i>)

These updates ensure that the amount of power used for ramp rate control û_RR_{<sub2>T</sub2>}(k) and the amount of power used for frequency regulation u_FR(k) can be added together to calculate the battery power setpoint u_bat. Battery power setpoint generator <b>1918</b> may provide the battery power setpoint u_batto battery power inverter <b>1508</b> and to PV power setpoint generator <b>1920</b>.

Generating PV Power Setpoints

Still referring to <figref idref="DRAWINGS">FIG. 19</figref>, controller <b>1514</b> is shown to include a PV power setpoint generator <b>1920</b>. PV power setpoint generator <b>1920</b> may be configured to generate the PV power setpoint u_PVfor PV field power inverter <b>1504</b>. The PV power setpoint u_PVis used by PV field power inverter <b>1504</b> to control an amount of power from PV field <b>1502</b> to provide to POI <b>1510</b>.

In some embodiments, PV power setpoint generator <b>1920</b> sets a default PV power setpoint u_PV(k) for instant k based on the previous value of the PV power P_PV(k−1) at instant k−1. For example, PV power setpoint generator <b>1920</b> may increment the previous PV power P_PV(k−1) with the compliance limit as shown in the following equation:

<maths id="MATH-US-00031" num="00031"><math overflow="scroll"><mrow><mrow><msub><mi>u</mi><mi>PV</mi></msub><mo></mo><mrow><mo>(</mo><mi>k</mi><mo>)</mo></mrow></mrow><mo>=</mo><mrow><mrow><msub><mi>P</mi><mi>PV</mi></msub><mo></mo><mrow><mo>(</mo><mrow><mi>k</mi><mo>-</mo><mn>1</mn></mrow><mo>)</mo></mrow></mrow><mo>+</mo><mfrac><mrow><mn>0.1</mn><mo></mo><msub><mi>P</mi><mi>cap</mi></msub></mrow><mrow><mn>60</mn><mo>/</mo><mi>T</mi></mrow></mfrac><mo>-</mo><mrow><mi>λ</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>σ</mi></mrow></mrow></mrow></math></maths>

This guarantees compliance with the ramp rate compliance limit and gradual ramping of the PV power output to energy grid <b>1512</b>. The default PV power setpoint may be useful to guarantee ramp rate compliance when the system is turned on, for example, in the middle of a sunny day or when an up-ramp in the PV power output P_PVis to be handled by limiting the PV power at PV power inverter <b>1504</b> instead of charging battery <b>1506</b>.

In some embodiments, PV power setpoint generator <b>1920</b> updates the PV power setpoint u_PV(k) based on the value of the battery power setpoint u_bat(k) so that the total power provided to POI <b>1510</b> does not exceed a POI power limit. For example, PV power setpoint generator <b>1920</b> may use the PV power setpoint u_PV(k) and the battery power setpoint u_bat(k) to calculate the total power P_POI(k) at point of intersection <b>1510</b> using the following equation:

&lt;br /&gt;<i>P</i>_POI(<i>k</i>)=<i>u</i>_bat(<i>k</i>)+<i>u</i>_PV(<i>k</i>)

PV power setpoint generator <b>1920</b> may compare the calculated power P_POI(k) with a power limit for POI <b>1510</b> (i.e., POIPowerLimit). If the calculated power P_POI(k) exceeds the POI power limit (i.e., P_POI(k)&gt;POIPower Limit), PV power setpoint generator <b>1920</b> may replace the calculated power P_POI(k) with the POI power limit. PV power setpoint generator <b>1920</b> may update the PV power setpoint u_PV(k) using the following equation:

&lt;br /&gt;<i>u</i>_PV(<i>k</i>)=POIPowerLimit−<i>u</i>_bat(<i>k</i>)

This ensures that the total power provided to POI <b>1510</b> does not exceed the POI power limit by causing PV field power inverter <b>1504</b> to limit the PV power. PV power setpoint generator <b>1920</b> may provide the PV power setpoint u_PVto PV field power inverter <b>1504</b>. &lt;br /&gt; Electrical Energy Storage System with Frequency Response Optimization

Referring now to <figref idref="DRAWINGS">FIG. 20</figref>, a frequency response optimization system <b>2000</b> is shown, according to an exemplary embodiment. System <b>2000</b> is shown to include a campus <b>2002</b> and an energy grid <b>2004</b>. Campus <b>2002</b> may include one or more buildings <b>2016</b> that receive power from energy grid <b>2004</b>. Buildings <b>2016</b> may include equipment or devices that consume electricity during operation. For example, buildings <b>2016</b> may include HVAC equipment, lighting equipment, security equipment, communications equipment, vending machines, computers, electronics, elevators, or other types of building equipment. In some embodiments, buildings <b>2016</b> are served by a building management system (BMS). A BMS is, in general, a system of devices configured to control, monitor, and manage equipment in or around a building or building area. A BMS can include, for example, a HVAC system, a security system, a lighting system, a fire alerting system, and/or any other system that is capable of managing building functions or devices. An exemplary building management system which may be used to monitor and control buildings <b>2016</b> is described in U.S. patent application Ser. No. 14/717,593.

In some embodiments, campus <b>2002</b> includes a central plant <b>2018</b>. Central plant <b>2018</b> may include one or more subplants that consume resources from utilities (e.g., water, natural gas, electricity, etc.) to satisfy the loads of buildings <b>2016</b>. For example, central plant <b>2018</b> may include a heater subplant, a heat recovery chiller subplant, a chiller subplant, a cooling tower subplant, a hot thermal energy storage (TES) subplant, and a cold thermal energy storage (TES) subplant, a steam subplant, and/or any other type of subplant configured to serve buildings <b>2016</b>. The subplants may be configured to convert input resources (e.g., electricity, water, natural gas, etc.) into output resources (e.g., cold water, hot water, chilled air, heated air, etc.) that are provided to buildings <b>2016</b>. An exemplary central plant which may be used to satisfy the loads of buildings <b>2016</b> is described U.S. patent application Ser. No. 14/634,609, titled “High Level Central Plant Optimization” and filed Feb. 27, 2015, the entire disclosure of which is incorporated by reference herein.

In some embodiments, campus <b>2002</b> includes energy generation <b>2020</b>. Energy generation <b>2020</b> may be configured to generate energy that can be used by buildings <b>2016</b>, used by central plant <b>2018</b>, and/or provided to energy grid <b>2004</b>. In some embodiments, energy generation <b>2020</b> generates electricity. For example, energy generation <b>2020</b> may include an electric power plant, a photovoltaic energy field, or other types of systems or devices that generate electricity. The electricity generated by energy generation <b>2020</b> can be used internally by campus <b>2002</b> (e.g., by buildings <b>2016</b> and/or campus <b>2018</b>) to decrease the amount of electric power that campus <b>2002</b> receives from outside sources such as energy grid <b>2004</b> or battery <b>2008</b>. If the amount of electricity generated by energy generation <b>2020</b> exceeds the electric power demand of campus <b>2002</b>, the excess electric power can be provided to energy grid <b>2004</b> or stored in battery <b>2008</b>. The power output of campus <b>2002</b> is shown in <figref idref="DRAWINGS">FIG. 20</figref> as P_campus. P_campusmay be positive if campus <b>2002</b> is outputting electric power or negative if campus <b>2002</b> is receiving electric power.

Still referring to <figref idref="DRAWINGS">FIG. 20</figref>, system <b>2000</b> is shown to include a power inverter <b>2006</b> and a battery <b>2008</b>. Power inverter <b>2006</b> may be configured to convert electric power between direct current (DC) and alternating current (AC). For example, battery <b>2008</b> may be configured to store and output DC power, whereas energy grid <b>2004</b> and campus <b>2002</b> may be configured to consume and generate AC power. Power inverter <b>2006</b> may be used to convert DC power from battery <b>2008</b> into a sinusoidal AC output synchronized to the grid frequency of energy grid <b>2004</b>. Power inverter <b>2006</b> may also be used to convert AC power from campus <b>2002</b> or energy grid <b>2004</b> into DC power that can be stored in battery <b>2008</b>. The power output of battery <b>2008</b> is shown as P_bat. P_batmay be positive if battery <b>2008</b> is providing power to power inverter <b>2006</b> or negative if battery <b>2008</b> is receiving power from power inverter <b>2006</b>.

In some instances, power inverter <b>2006</b> receives a DC power output from battery <b>2008</b> and converts the DC power output to an AC power output that can be fed into energy grid <b>2004</b>. Power inverter <b>2006</b> may synchronize the frequency of the AC power output with that of energy grid <b>2004</b> (e.g., 50 Hz or 60 Hz) using a local oscillator and may limit the voltage of the AC power output to no higher than the grid voltage. In some embodiments, power inverter <b>2006</b> is a resonant inverter that includes or uses LC circuits to remove the harmonics from a simple square wave in order to achieve a sine wave matching the frequency of energy grid <b>2004</b>. In various embodiments, power inverter <b>2006</b> may operate using high-frequency transformers, low-frequency transformers, or without transformers. Low-frequency transformers may convert the DC output from battery <b>2008</b> directly to the AC output provided to energy grid <b>2004</b>. High-frequency transformers may employ a multi-step process that involves converting the DC output to high-frequency AC, then back to DC, and then finally to the AC output provided to energy grid <b>2004</b>.

System <b>2000</b> is shown to include a point of interconnection (POI) <b>2010</b>. POI <b>2010</b> is the point at which campus <b>2002</b>, energy grid <b>2004</b>, and power inverter <b>2006</b> are electrically connected. The power supplied to POI <b>2010</b> from power inverter <b>2006</b> is shown as P_sup. P_supmay be defined as P_bat+P_loss, where P_battis the battery power and P_lossis the power loss in the battery system (e.g., losses in power inverter <b>2006</b> and/or battery <b>2008</b>). P_supmay be positive is power inverter <b>2006</b> is providing power to POI <b>2010</b> or negative if power inverter <b>2006</b> is receiving power from POI <b>2010</b>. P_campusand P_supcombine at POI <b>2010</b> to form P_POI. P_POImay be defined as the power provided to energy grid <b>2004</b> from POI <b>2010</b>. P_POImay be positive if POI <b>2010</b> is providing power to energy grid <b>2004</b> or negative if POI <b>2010</b> is receiving power from energy grid <b>2004</b>.

Still referring to <figref idref="DRAWINGS">FIG. 20</figref>, system <b>2000</b> is shown to include a frequency response controller <b>2012</b>. Controller <b>2012</b> may be configured to generate and provide power setpoints to power inverter <b>2006</b>. Power inverter <b>2006</b> may use the power setpoints to control the amount of power P_supprovided to POI <b>2010</b> or drawn from POI <b>2010</b>. For example, power inverter <b>2006</b> may be configured to draw power from POI <b>2010</b> and store the power in battery <b>2008</b> in response to receiving a negative power setpoint from controller <b>2012</b>. Conversely, power inverter <b>2006</b> may be configured to draw power from battery <b>2008</b> and provide the power to POI <b>2010</b> in response to receiving a positive power setpoint from controller <b>2012</b>. The magnitude of the power setpoint may define the amount of power P_supprovided to or from power inverter <b>2006</b>. Controller <b>2012</b> may be configured to generate and provide power setpoints that optimize the value of operating system <b>2000</b> over a time horizon.

In some embodiments, frequency response controller <b>2012</b> uses power inverter <b>2006</b> and battery <b>2008</b> to perform frequency regulation for energy grid <b>2004</b>. Frequency regulation is the process of maintaining the stability of the grid frequency (e.g., 60 Hz in the United States). The grid frequency may remain stable and balanced as long as the total electric supply and demand of energy grid <b>2004</b> are balanced. Any deviation from that balance may result in a deviation of the grid frequency from its desirable value. For example, an increase in demand may cause the grid frequency to decrease, whereas an increase in supply may cause the grid frequency to increase. Frequency response controller <b>2012</b> may be configured to offset a fluctuation in the grid frequency by causing power inverter <b>2006</b> to supply energy from battery <b>2008</b> to energy grid <b>2004</b> (e.g., to offset a decrease in grid frequency) or store energy from energy grid <b>2004</b> in battery <b>2008</b> (e.g., to offset an increase in grid frequency).

In some embodiments, frequency response controller <b>2012</b> uses power inverter <b>2006</b> and battery <b>2008</b> to perform load shifting for campus <b>2002</b>. For example, controller <b>2012</b> may cause power inverter <b>2006</b> to store energy in battery <b>2008</b> when energy prices are low and retrieve energy from battery <b>2008</b> when energy prices are high in order to reduce the cost of electricity required to power campus <b>2002</b>. Load shifting may also allow system <b>2000</b> reduce the demand charge incurred. Demand charge is an additional charge imposed by some utility providers based on the maximum power consumption during an applicable demand charge period. For example, a demand charge rate may be specified 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. Load shifting may allow system <b>2000</b> to smooth momentary spikes in the electric demand of campus <b>2002</b> by drawing energy from battery <b>2008</b> in order to reduce peak power draw from energy grid <b>2004</b>, thereby decreasing the demand charge incurred.

Still referring to <figref idref="DRAWINGS">FIG. 20</figref>, system <b>2000</b> is shown to include an incentive provider <b>2014</b>. Incentive provider <b>2014</b> may be a utility (e.g., an electric utility), a regional transmission organization (RTO), an independent system operator (ISO), or any other entity that provides incentives for performing frequency regulation. For example, incentive provider <b>2014</b> may provide system <b>2000</b> with monetary incentives for participating in a frequency response program. In order to participate in the frequency response program, system <b>2000</b> may maintain a reserve capacity of stored energy (e.g., in battery <b>2008</b>) that can be provided to energy grid <b>2004</b>. System <b>2000</b> may also maintain the capacity to draw energy from energy grid <b>2004</b> and store the energy in battery <b>2008</b>. Reserving both of these capacities may be accomplished by managing the state-of-charge of battery <b>2008</b>.

Frequency response controller <b>2012</b> may provide incentive provider <b>2014</b> with a price bid and a capability bid. The price bid may include a price per unit power (e.g., $/MW) for reserving or storing power that allows system <b>2000</b> to participate in a frequency response program offered by incentive provider <b>2014</b>. The price per unit power bid by frequency response controller <b>2012</b> is referred to herein as the “capability price.” The price bid may also include a price for actual performance, referred to herein as the “performance price.” The capability bid may define an amount of power (e.g., MW) that system <b>2000</b> will reserve or store in battery <b>2008</b> to perform frequency response, referred to herein as the “capability bid.”

Incentive provider <b>2014</b> may provide frequency response controller <b>2012</b> with a capability clearing price CP_cap, a performance clearing price CP_perf, and a regulation award Reg_award, which correspond to the capability price, the performance price, and the capability bid, respectively. In some embodiments, CP_cap, CP_perf, and Reg_awardare the same as the corresponding bids placed by controller <b>2012</b>. In other embodiments, CP_cap, CP_perf, and Reg_awardmay not be the same as the bids placed by controller <b>2012</b>. For example, CP_cap, CP_perf, and Reg_awardmay be generated by incentive provider <b>2014</b> based on bids received from multiple participants in the frequency response program. Controller <b>2012</b> may use CP_cap, CP_perf, and Reg_awardto perform frequency regulation.

Frequency response controller <b>2012</b> is shown receiving a regulation signal from incentive provider <b>2014</b>. The regulation signal may specify a portion of the regulation award Reg_awardthat frequency response controller <b>2012</b> is to add or remove from energy grid <b>2004</b>. In some embodiments, the regulation signal is a normalized signal (e.g., between −1 and 1) specifying a proportion of Reg_award. Positive values of the regulation signal may indicate an amount of power to add to energy grid <b>2004</b>, whereas negative values of the regulation signal may indicate an amount of power to remove from energy grid <b>2004</b>.

Frequency response controller <b>2012</b> may respond to the regulation signal by generating an optimal power setpoint for power inverter <b>2006</b>. The optimal power setpoint may take into account both the potential revenue from participating in the frequency response program and the costs of participation. Costs of participation may include, for example, a monetized cost of battery degradation as well as the energy and demand charges that will be incurred. The optimization may be performed using sequential quadratic programming, dynamic programming, or any other optimization technique.

In some embodiments, controller <b>2012</b> uses a battery life model to quantify and monetize battery degradation as a function of the power setpoints provided to power inverter <b>2006</b>. Advantageously, the battery life model allows controller <b>2012</b> to perform an optimization that weighs the revenue generation potential of participating in the frequency response program against the cost of battery degradation and other costs of participation (e.g., less battery power available for campus <b>2002</b>, increased electricity costs, etc.). An exemplary regulation signal and power response are described in greater detail with reference to <figref idref="DRAWINGS">FIG. 21</figref>.

Referring now to <figref idref="DRAWINGS">FIG. 21</figref>, a pair of frequency response graphs <b>2100</b> and <b>2150</b> are shown, according to an exemplary embodiment. Graph <b>2100</b> illustrates a regulation signal Reg_signal<b>2102</b> as a function of time. Reg_signal<b>2102</b> is shown as a normalized signal ranging from −1 to 1 (i.e., −1≦Reg_signal≦1). Reg_signal<b>2102</b> may be generated by incentive provider <b>2014</b> and provided to frequency response controller <b>2012</b>. Reg_signal<b>2102</b> may define a proportion of the regulation award Reg_award<b>2154</b> that controller <b>2012</b> is to add or remove from energy grid <b>2004</b>, relative to a baseline value referred to as the midpoint b <b>2156</b>. For example, if the value of Reg_award<b>2154</b> is 10 MW, a regulation signal value of 0.5 (i.e., Reg_signal=0.5) may indicate that system <b>2000</b> is requested to add 5 MW of power at POI <b>2010</b> relative to midpoint b (e.g., P=10 MW×0.5+b), whereas a regulation signal value of −0.3 may indicate that system <b>2000</b> is requested to remove 3 MW of power from POI <b>2010</b> relative to midpoint b (e.g., P_POI*=10 MW×−0.3+b).

Graph <b>2150</b> illustrates the desired interconnection power P_POI* <b>2152</b> as a function of time. P_POI* <b>2152</b> may be calculated by frequency response controller <b>2012</b> based on Reg_signal<b>2102</b>, Reg_award<b>2154</b>, and a midpoint b <b>2156</b>. For example, controller <b>2012</b> may calculate P_POI* <b>2152</b> using the following equation:

&lt;br /&gt;<i>P</i>_POI<i>*=Reg</i>_award<i>×Reg</i>_signal<i>+b </i>

where P_POI* represents the desired power at POI <b>2010</b> (e.g., P_POI*=P_sup+P_campus) and b is the midpoint. Midpoint b may be defined (e.g., set or optimized) by controller <b>2012</b> and may represent the midpoint of regulation around which the load is modified in response to Reg_signal<b>2102</b>. Optimal adjustment of midpoint b may allow controller <b>2012</b> to actively participate in the frequency response market while also taking into account the energy and demand charge that will be incurred.

In order to participate in the frequency response market, controller <b>2012</b> may perform several tasks. Controller <b>2012</b> may generate a price bid (e.g., $/MW) that includes the capability price and the performance price. In some embodiments, controller <b>2012</b> sends the price bid to incentive provider <b>2014</b> at approximately 15:30 each day and the price bid remains in effect for the entirety of the next day. Prior to beginning a frequency response period, controller <b>2012</b> may generate the capability bid (e.g., MW) and send the capability bid to incentive provider <b>2014</b>. In some embodiments, controller <b>2012</b> generates and sends the capability bid to incentive provider <b>2014</b> approximately 1.5 hours before a frequency response period begins. In an exemplary embodiment, each frequency response period has a duration of one hour; however, it is contemplated that frequency response periods may have any duration.

At the start of each frequency response period, controller <b>2012</b> may generate the midpoint b around which controller <b>2012</b> plans to perform frequency regulation. In some embodiments, controller <b>2012</b> generates a midpoint b that will maintain battery <b>2008</b> at a constant state-of-charge (SOC) (i.e. a midpoint that will result in battery <b>2008</b> having the same SOC at the beginning and end of the frequency response period). In other embodiments, controller <b>2012</b> generates midpoint b using an optimization procedure that allows the SOC of battery <b>2008</b> to have different values at the beginning and end of the frequency response period. For example, controller <b>2012</b> may use the SOC of battery <b>2008</b> as a constrained variable that depends on midpoint b in order to optimize a value function that takes into account frequency response revenue, energy costs, and the cost of battery degradation. Exemplary processes for calculating and/or optimizing midpoint b under both the constant SOC scenario and the variable SOC scenario are described in detail in U.S. Provisional Patent Application No. 62/239,233 filed Oct. 8, 2015, the entire disclosure of which is incorporated by reference herein.

During each frequency response period, controller <b>2012</b> may periodically generate a power setpoint for power inverter <b>2006</b>. For example, controller <b>2012</b> may generate a power setpoint for each time step in the frequency response period. In some embodiments, controller <b>2012</b> generates the power setpoints using the equation:

&lt;br /&gt;<i>P</i>_POI<i>*=Reg</i>_award<i>×Reg</i>_signal<i>+b </i>

where P_POI*=P_sup+P_campus. Positive values of P_POI* indicate energy flow from POI <b>2010</b> to energy grid <b>2004</b>. Positive values of P_supand P_campusindicate energy flow to POI <b>2010</b> from power inverter <b>2006</b> and campus <b>2002</b>, respectively. In other embodiments, controller <b>2012</b> generates the power setpoints using the equation:

&lt;br /&gt;<i>P</i>_POI<i>*=Reg</i>_award<i>×Res</i>_FR<i>+b </i>

where Res_FRis an optimal frequency response generated by optimizing a value function. Controller <b>2012</b> may subtract P_campusfrom P_POI* to generate the power setpoint for power inverter <b>2006</b> (i.e., P_sup=P_POI*−P_campus). The power setpoint for power inverter <b>2006</b> indicates the amount of power that power inverter <b>2006</b> is to add to POI <b>2010</b> (if the power setpoint is positive) or remove from POI <b>2010</b> (if the power setpoint is negative). Exemplary processes for calculating power inverter setpoints are described in detail in U.S. Provisional Patent Application No. 62/239,233.

Frequency Response Controller

Referring now to <figref idref="DRAWINGS">FIG. 22</figref>, a block diagram illustrating frequency response controller <b>2012</b> in greater detail is shown, according to an exemplary embodiment. Frequency response controller <b>2012</b> may be configured to perform an optimization process to generate values for the bid price, the capability bid, and the midpoint b. In some embodiments, frequency response controller <b>2012</b> generates values for the bids and the midpoint b periodically using a predictive optimization scheme (e.g., once every half hour, once per frequency response period, etc.). Controller <b>2012</b> may also calculate and update power setpoints for power inverter <b>2006</b> periodically during each frequency response period (e.g., once every two seconds).

In some embodiments, the interval at which controller <b>2012</b> generates power setpoints for power inverter <b>2006</b> is significantly shorter than the interval at which controller <b>2012</b> generates the bids and the midpoint b. For example, controller <b>2012</b> may generate values for the bids and the midpoint b every half hour, whereas controller <b>2012</b> may generate a power setpoint for power inverter <b>2006</b> every two seconds. The difference in these time scales allows controller <b>2012</b> to use a cascaded optimization process to generate optimal bids, midpoints b, and power setpoints.

In the cascaded optimization process, a high level controller <b>2212</b> determines optimal values for the bid price, the capability bid, and the midpoint b by performing a high level optimization. High level controller <b>2212</b> may select midpoint b to maintain a constant state-of-charge in battery <b>2008</b> (i.e., the same state-of-charge at the beginning and end of each frequency response period) or to vary the state-of-charge in order to optimize the overall value of operating system <b>2000</b> (e.g., frequency response revenue minus energy costs and battery degradation costs). High level controller <b>2212</b> may also determine filter parameters for a signal filter (e.g., a low pass filter) used by a low level controller <b>2214</b>.

Low level controller <b>2214</b> uses the midpoint b and the filter parameters from high level controller <b>2212</b> to perform a low level optimization in order to generate the power setpoints for power inverter <b>2006</b>. Advantageously, low level controller <b>2214</b> may determine how closely to track the desired power P_POI* at the point of interconnection <b>2010</b>. For example, the low level optimization performed by low level controller <b>2214</b> may consider not only frequency response revenue but also the costs of the power setpoints in terms of energy costs and battery degradation. In some instances, low level controller <b>2214</b> may determine that it is deleterious to battery <b>2008</b> to follow the regulation exactly and may sacrifice a portion of the frequency response revenue in order to preserve the life of battery <b>2008</b>. The cascaded optimization process is described in greater detail below.

Still referring to <figref idref="DRAWINGS">FIG. 22</figref>, frequency response controller <b>2012</b> is shown to include a communications interface <b>2202</b> and a processing circuit <b>2204</b>. Communications interface <b>2202</b> may 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 interface <b>2202</b> may 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 interface <b>2202</b> may 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 interface <b>2202</b> may be a network interface configured to facilitate electronic data communications between frequency response controller <b>2012</b> and various external systems or devices (e.g., campus <b>2002</b>, energy grid <b>2004</b>, power inverter <b>2006</b>, incentive provider <b>2014</b>, utilities <b>2220</b>, weather service <b>2222</b>, etc.). For example, frequency response controller <b>2012</b> may receive inputs from incentive provider <b>2014</b> indicating an incentive event history (e.g., past clearing prices, mileage ratios, participation requirements, etc.) and a regulation signal. Controller <b>2012</b> may receive a campus power signal from campus <b>2002</b>, utility rates from utilities <b>2220</b>, and weather forecasts from weather service <b>2222</b> via communications interface <b>2202</b>. Controller <b>2012</b> may provide a price bid and a capability bid to incentive provider <b>2014</b> and may provide power setpoints to power inverter <b>2006</b> via communications interface <b>2202</b>.

Still referring to <figref idref="DRAWINGS">FIG. 22</figref>, processing circuit <b>2204</b> is shown to include a processor <b>2206</b> and memory <b>2208</b>. Processor <b>2206</b> may 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. Processor <b>2206</b> may be configured to execute computer code or instructions stored in memory <b>2208</b> or received from other computer readable media (e.g., CDROM, network storage, a remote server, etc.).

Memory <b>2208</b> may 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. Memory <b>2208</b> may 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. Memory <b>2208</b> may 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. Memory <b>2208</b> may be communicably connected to processor <b>2206</b> via processing circuit <b>2204</b> and may include computer code for executing (e.g., by processor <b>2206</b>) one or more processes described herein.

Still referring to <figref idref="DRAWINGS">FIG. 22</figref>, frequency response controller <b>2012</b> is shown to include a load/rate predictor <b>2210</b>. Load/rate predictor <b>2210</b> may be configured to predict the electric load of campus <b>2002</b> (i.e., {circumflex over (P)}_campus) for each time step k (e.g., k=1 . . . n) within an optimization window. Load/rate predictor <b>2210</b> is shown receiving weather forecasts from a weather service <b>2222</b>. In some embodiments, load/rate predictor <b>2210</b> predicts {circumflex over (P)}_campusas a function of the weather forecasts. In some embodiments, load/rate predictor <b>2210</b> uses feedback from campus <b>2002</b> to predict {circumflex over (P)}_campus. Feedback from campus <b>2002</b> may include various types of sensory inputs (e.g., temperature, flow, humidity, enthalpy, etc.) or other data relating to buildings <b>2016</b>, central plant <b>2018</b>, and/or energy generation <b>2020</b> (e.g., inputs from a HVAC system, a lighting control system, a security system, a water system, a PV energy system, etc.). Load/rate predictor <b>2210</b> may predict one or more different types of loads for campus <b>2002</b>. For example, load/rate predictor <b>2210</b> may predict a hot water load, a cold water load, and/or an electric load for each time step k within the optimization window.

In some embodiments, load/rate predictor <b>2210</b> receives a measured electric load and/or previous measured load data from campus <b>2002</b>. For example, load/rate predictor <b>2210</b> is shown receiving a campus power signal from campus <b>2002</b>. The campus power signal may indicate the measured electric load of campus <b>2002</b>. Load/rate predictor <b>2210</b> may predict one or more statistics of the campus power signal including, for example, a mean campus power μ_campusand a standard deviation of the campus power σ_campus. Load/rate predictor <b>2210</b> may predict {circumflex over (P)}_campusas a function of a given weather forecast ({circumflex over (φ)}_w), a day type (clay), the time of day (t), and previous measured load data (Y_k−1). Such a relationship is expressed in the following equation:

&lt;br /&gt;<i>{circumflex over (P)}</i>_campus<i>=f</i>({circumflex over (φ)}_w,day,<i>t|Y</i>_k−1)

In some embodiments, load/rate predictor <b>2210</b> uses a deterministic plus stochastic model trained from historical load data to predict {circumflex over (P)}_campus. Load/rate predictor <b>2210</b> may use any of a variety of prediction methods to predict {circumflex over (P)}_campus(e.g., linear regression for the deterministic portion and an AR model for the stochastic portion). In some embodiments, load/rate predictor <b>2210</b> makes load/rate predictions using the techniques described in U.S. patent application Ser. No. 14/717,593.

Load/rate predictor <b>2210</b> is shown receiving utility rates from utilities <b>2220</b>. Utility rates may indicate a cost or price per unit of a resource (e.g., electricity, natural gas, water, etc.) provided by utilities <b>2220</b> at each time step k in the optimization 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 utilities <b>2220</b> or predicted utility rates estimated by load/rate predictor <b>2210</b>.

In some embodiments, the utility rates include demand charges for one or more resources provided by utilities <b>2220</b>. A demand charge may define a separate cost imposed by utilities <b>2220</b> based 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, frequency response controller <b>2012</b> may be configured to account for demand charges in the high level optimization process performed by high level controller <b>2212</b>. Utilities <b>2220</b> may 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 predictor <b>2210</b> may store the predicted campus power {circumflex over (P)}_campusand the utility rates in memory <b>2208</b> and/or provide the predicted campus power {circumflex over (P)}_campusand the utility rates to high level controller <b>2212</b>.

Still referring to <figref idref="DRAWINGS">FIG. 22</figref>, frequency response controller <b>2012</b> is shown to include an energy market predictor <b>2216</b> and a signal statistics predictor <b>2218</b>. Energy market predictor <b>2216</b> may be configured to predict energy market statistics relating to the frequency response program. For example, energy market predictor <b>2216</b> may predict the values of one or more variables that can be used to estimate frequency response revenue. In some embodiments, the frequency response revenue is defined by the following equation:

&lt;br /&gt;<i>Rev=PS</i>(<i>CP</i>_cap<i>+MR·CP</i>_perf)<i>Reg</i>_award

where Rev is the frequency response revenue, CP_capis the capability clearing price, MR is the mileage ratio, and CP_perfis the performance clearing price. PS is a performance score based on how closely the frequency response provided by controller <b>2012</b> tracks the regulation signal. Energy market predictor <b>2216</b> may be configured to predict the capability clearing price CP_cap, the performance clearing price CP_perf, the mileage ratio MR, and/or other energy market statistics that can be used to estimate frequency response revenue. Energy market predictor <b>2216</b> may store the energy market statistics in memory <b>2208</b> and/or provide the energy market statistics to high level controller <b>2212</b>.

Signal statistics predictor <b>2218</b> may be configured to predict one or more statistics of the regulation signal provided by incentive provider <b>2014</b>. For example, signal statistics predictor <b>2218</b> may be configured to predict the mean μ_FR, standard deviation σ_FR, and/or other statistics of the regulation signal. The regulation signal statistics may be based on previous values of the regulation signal (e.g., a historical mean, a historical standard deviation, etc.) or predicted values of the regulation signal (e.g., a predicted mean, a predicted standard deviation, etc.).

In some embodiments, signal statistics predictor <b>2218</b> uses a deterministic plus stochastic model trained from historical regulation signal data to predict future values of the regulation signal. For example, signal statistics predictor <b>2218</b> may use linear regression to predict a deterministic portion of the regulation signal and an AR model to predict a stochastic portion of the regulation signal. In some embodiments, signal statistics predictor <b>2218</b> predicts the regulation signal using the techniques described in U.S. patent application Ser. No. 14/717,593. Signal statistics predictor <b>2218</b> may use the predicted values of the regulation signal to calculate the regulation signal statistics. Signal statistics predictor <b>2218</b> may store the regulation signal statistics in memory <b>2208</b> and/or provide the regulation signal statistics to high level controller <b>2212</b>.

Still referring to <figref idref="DRAWINGS">FIG. 22</figref>, frequency response controller <b>2012</b> is shown to include a high level controller <b>2212</b>. High level controller <b>2212</b> may be configured to generate values for the midpoint b and the capability bid Reg_award. In some embodiments, high level controller <b>2212</b> determines a midpoint b that will cause battery <b>2008</b> to have the same state-of-charge (SOC) at the beginning and end of each frequency response period. In other embodiments, high level controller <b>2212</b> performs an optimization process to generate midpoint b and Reg_award. For example, high level controller <b>2212</b> may generate midpoint b using an optimization procedure that allows the SOC of battery <b>2008</b> to vary and/or have different values at the beginning and end of the frequency response period. High level controller <b>2212</b> may use the SOC of battery <b>2008</b> as a constrained variable that depends on midpoint b in order to optimize a value function that takes into account frequency response revenue, energy costs, and the cost of battery degradation. Both of these embodiments are described in greater detail with reference to <figref idref="DRAWINGS">FIG. 23</figref>.

High level controller <b>2212</b> may determine midpoint b by equating the desired power P_POI* at POI <b>2010</b> with the actual power at POI <b>2010</b> as shown in the following equation:

&lt;br /&gt;<i>Reg</i>_signal)(<i>Reg</i>_award)+<i>b=P</i>_bat<i>P</i>_loss<i>+P</i>_campus

where the left side of the equation (Reg_signal)(Reg_award)+b is the desired power P_POI* at POI and the right side of the equation is the actual power at POI <b>2010</b>. Integrating over the frequency response period results in the following equation:

<maths id="MATH-US-00032" num="00032"><math overflow="scroll"><mrow><mrow><munder><mo>∫</mo><mi>period</mi></munder><mo></mo><mrow><mrow><mo>(</mo><mrow><mrow><mrow><mo>(</mo><msub><mi>Reg</mi><mi>signal</mi></msub><mo>)</mo></mrow><mo></mo><mrow><mo>(</mo><msub><mi>Reg</mi><mi>award</mi></msub><mo>)</mo></mrow></mrow><mo>+</mo><mi>b</mi></mrow><mo>)</mo></mrow><mo></mo><mrow><mo></mo><mi>t</mi></mrow></mrow></mrow><mo>=</mo><mrow><munder><mo>∫</mo><mi>period</mi></munder><mo></mo><mrow><mrow><mo>(</mo><mrow><msub><mi>P</mi><mi>bat</mi></msub><mo>+</mo><msub><mi>P</mi><mi>loss</mi></msub><mo>+</mo><msub><mi>P</mi><mi>campus</mi></msub></mrow><mo>)</mo></mrow><mo></mo><mrow><mo></mo><mi>t</mi></mrow></mrow></mrow></mrow></math></maths>

For embodiments in which the SOC of battery <b>2008</b> is maintained at the same value at the beginning and end of the frequency response period, the integral of the battery power P_batover the frequency response period is zero (i.e., ∫P_batdt=0). Accordingly, the previous equation can be rewritten as follows:

<maths id="MATH-US-00033" num="00033"><math overflow="scroll"><mrow><mi>b</mi><mo>=</mo><mrow><mrow><munder><mo>∫</mo><mi>period</mi></munder><mo></mo><mrow><msub><mi>P</mi><mi>loss</mi></msub><mo></mo><mrow><mo></mo><mi>t</mi></mrow></mrow></mrow><mo>+</mo><mrow><munder><mo>∫</mo><mi>period</mi></munder><mo></mo><mrow><msub><mi>P</mi><mi>campus</mi></msub><mo></mo><mrow><mo></mo><mi>t</mi></mrow></mrow></mrow><mo>-</mo><mrow><msub><mi>Reg</mi><mi>award</mi></msub><mo></mo><mrow><munder><mo>∫</mo><mi>period</mi></munder><mo></mo><mrow><msub><mi>Reg</mi><mi>signal</mi></msub><mo></mo><mrow><mo></mo><mi>t</mi></mrow></mrow></mrow></mrow></mrow></mrow></math></maths>

where the term ∫P_batdt has been omitted because ∫P_batdt=0. This is ideal behavior if the only goal is to maximize frequency response revenue. Keeping the SOC of battery <b>2008</b> at a constant value (and near 50%) will allow system <b>2000</b> to participate in the frequency market during all hours of the day.

High level controller <b>2212</b> may use the estimated values of the campus power signal received from campus <b>2002</b> to predict the value of ∫P_campusdt over the frequency response period. Similarly, high level controller <b>2212</b> may use the estimated values of the regulation signal from incentive provider <b>2014</b> to predict the value of ∫Reg_signaldt over the frequency response period. High level controller <b>2212</b> may estimate the value of ∫P_lossdt using a Thevinin equivalent circuit model of battery <b>2008</b> (described in greater detail with reference to <figref idref="DRAWINGS">FIG. 23</figref>). This allows high level controller <b>2212</b> to estimate the integral ∫P_lossdt as a function of other variables such as Reg_award, Reg_signal, P_campus, and midpoint b.

After substituting known and estimated values, the preceding equation can be rewritten as follows:

<maths id="MATH-US-00034" num="00034"><math overflow="scroll"><mrow><mrow><mrow><mrow><mfrac><mn>1</mn><mrow><mn>4</mn><mo></mo><msub><mi>P</mi><mrow><mi>ma</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>x</mi></mrow></msub></mrow></mfrac><mo></mo><mrow><mo>[</mo><mrow><mrow><mi>E</mi><mo></mo><mrow><mo>{</mo><msubsup><mi>P</mi><mi>campus</mi><mn>2</mn></msubsup><mo>}</mo></mrow></mrow><mo>+</mo><mrow><msubsup><mi>Reg</mi><mi>award</mi><mn>2</mn></msubsup><mo></mo><mi>E</mi><mo></mo><mrow><mo>{</mo><msubsup><mi>Reg</mi><mi>signal</mi><mn>2</mn></msubsup><mo>}</mo></mrow></mrow><mo>-</mo><mrow><mn>2</mn><mo></mo><msub><mi>Reg</mi><mi>award</mi></msub><mo></mo><mi>E</mi><mo></mo><mrow><mo>{</mo><msub><mi>Reg</mi><mi>signal</mi></msub><mo>}</mo></mrow><mo></mo><mi>E</mi><mo></mo><mrow><mo>{</mo><msub><mi>P</mi><mi>campus</mi></msub><mo>}</mo></mrow></mrow></mrow><mo>]</mo></mrow></mrow><mo></mo><mi>Δ</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>t</mi></mrow><mo>+</mo><mrow><mrow><mo>[</mo><mrow><mrow><msub><mi>Reg</mi><mi>award</mi></msub><mo></mo><mi>E</mi><mo></mo><mrow><mo>{</mo><msub><mi>Reg</mi><mi>signal</mi></msub><mo>}</mo></mrow></mrow><mo>-</mo><mrow><mi>E</mi><mo></mo><mrow><mo>{</mo><msub><mi>P</mi><mi>campus</mi></msub><mo>}</mo></mrow></mrow></mrow><mo>]</mo></mrow><mo></mo><mi>Δ</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>t</mi></mrow><mo>+</mo><mrow><mrow><mfrac><mi>b</mi><mrow><mn>2</mn><mo></mo><msub><mi>P</mi><mrow><mi>ma</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>x</mi></mrow></msub></mrow></mfrac><mo></mo><mrow><mo>[</mo><mrow><mrow><msub><mi>Reg</mi><mi>award</mi></msub><mo></mo><mi>E</mi><mo></mo><mrow><mo>{</mo><msub><mi>Reg</mi><mi>signal</mi></msub><mo>}</mo></mrow></mrow><mo>-</mo><mrow><mi>E</mi><mo></mo><mrow><mo>{</mo><msub><mi>P</mi><mi>campus</mi></msub><mo>}</mo></mrow></mrow></mrow><mo>]</mo></mrow></mrow><mo></mo><mi>Δ</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>t</mi></mrow><mo>+</mo><mrow><mi>b</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>Δ</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>t</mi></mrow><mo>+</mo><mrow><mfrac><msup><mi>b</mi><mn>2</mn></msup><mrow><mn>4</mn><mo></mo><msub><mi>P</mi><mrow><mi>ma</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>x</mi></mrow></msub></mrow></mfrac><mo></mo><mi>Δ</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>t</mi></mrow></mrow><mo>=</mo><mn>0</mn></mrow></math></maths>

where the notation E{ } indicates that the variable within the brackets { } is ergodic and can be approximated by the estimated mean of the variable. For example, the term E{Reg_signal} can be approximated by the estimated mean of the regulation signal μ_FRand the term E{P_campus} can be approximated by the estimated mean of the campus power signal μ_campus. High level controller <b>2212</b> may solve the equation for midpoint b to determine the midpoint b that maintains battery <b>2008</b> at a constant state-of-charge.

For embodiments in which the SOC of battery <b>2008</b> is treated as a variable, the SOC of battery <b>2008</b> may be allowed to have different values at the beginning and end of the frequency response period. Accordingly, the integral of the battery power P_batover the frequency response period can be expressed as −ΔSOC·C_desas shown in the following equation:

<maths id="MATH-US-00035" num="00035"><math overflow="scroll"><mrow><mrow><munder><mo>∫</mo><mi>period</mi></munder><mo></mo><mrow><msub><mi>P</mi><mi>bat</mi></msub><mo></mo><mrow><mo></mo><mi>t</mi></mrow></mrow></mrow><mo>=</mo><mrow><mrow><mo>-</mo><mi>Δ</mi></mrow><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mrow><mi>SOC</mi><mo>·</mo><msub><mi>C</mi><mi>des</mi></msub></mrow></mrow></mrow></math></maths>

where ΔSOC is the change in the SOC of battery <b>2008</b> over the frequency response period and C_desis the design capacity of battery <b>2008</b>. The SOC of battery <b>2008</b> may be a normalized variable (i.e., 0≦SOC≦1) such that the term SOC·C_desrepresents the amount of energy stored in battery <b>2008</b> for a given state-of-charge. The SOC is shown as a negative value because drawing energy from battery <b>2008</b> (i.e., a positive P_bat) decreases the SOC of battery <b>2008</b>. The equation for midpoint b becomes:

<maths id="MATH-US-00036" num="00036"><math overflow="scroll"><mrow><mi>b</mi><mo>=</mo><mrow><mrow><munder><mo>∫</mo><mi>period</mi></munder><mo></mo><mrow><msub><mi>P</mi><mi>loss</mi></msub><mo></mo><mrow><mo></mo><mi>t</mi></mrow></mrow></mrow><mo>+</mo><mrow><munder><mo>∫</mo><mi>period</mi></munder><mo></mo><mrow><msub><mi>P</mi><mi>campus</mi></msub><mo></mo><mrow><mo></mo><mi>t</mi></mrow></mrow></mrow><mo>+</mo><mrow><munder><mo>∫</mo><mi>period</mi></munder><mo></mo><mrow><msub><mi>P</mi><mi>bat</mi></msub><mo></mo><mrow><mo></mo><mi>t</mi></mrow></mrow></mrow><mo>-</mo><mrow><msub><mi>Reg</mi><mi>award</mi></msub><mo></mo><mrow><munder><mo>∫</mo><mi>period</mi></munder><mo></mo><mrow><msub><mi>Reg</mi><mi>signal</mi></msub><mo></mo><mrow><mo></mo><mi>t</mi></mrow></mrow></mrow></mrow></mrow></mrow></math></maths>

After substituting known and estimated values, the preceding equation can be rewritten as follows:

<maths id="MATH-US-00037" num="00037"><math overflow="scroll"><mrow><mrow><mrow><mrow><mrow><mfrac><mn>1</mn><mrow><mn>4</mn><mo></mo><msub><mi>P</mi><mi>max</mi></msub></mrow></mfrac><mo></mo><mrow><mo>[</mo><mrow><mrow><mi>E</mi><mo></mo><mrow><mo>{</mo><msubsup><mi>P</mi><mi>campus</mi><mn>2</mn></msubsup><mo>}</mo></mrow></mrow><mo>+</mo><msubsup><mi>Reg</mi><mi>award</mi><mn>2</mn></msubsup><mo>+</mo><mrow><mi>E</mi><mo></mo><mrow><mo>{</mo><msubsup><mi>Reg</mi><mi>signal</mi><mn>2</mn></msubsup><mo>}</mo></mrow></mrow><mo>-</mo><mrow><mn>2</mn><mo></mo><msub><mi>Reg</mi><mi>award</mi></msub><mo></mo><mi>E</mi><mo></mo><mrow><mo>{</mo><msub><mi>Reg</mi><mi>signal</mi></msub><mo>}</mo></mrow><mo></mo><mi>E</mi><mo></mo><mrow><mo>{</mo><msub><mi>P</mi><mi>campus</mi></msub><mo>}</mo></mrow></mrow></mrow><mo>]</mo></mrow></mrow><mo></mo><mi>Δ</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>t</mi></mrow><mo>+</mo></mrow><mo> </mo></mrow><mo></mo><mrow><mo> </mo><mrow><mrow><mrow><mrow><mo>[</mo><mrow><mrow><msub><mi>Reg</mi><mi>award</mi></msub><mo></mo><mi>E</mi><mo></mo><mrow><mo>{</mo><msub><mi>Reg</mi><mi>signal</mi></msub><mo>}</mo></mrow></mrow><mo>+</mo><mrow><mi>E</mi><mo></mo><mrow><mo>{</mo><msub><mi>P</mi><mi>campus</mi></msub><mo>}</mo></mrow></mrow></mrow><mo>]</mo></mrow><mo></mo><mi>Δ</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>t</mi></mrow><mo>+</mo><mrow><mi>Δ</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mrow><mi>SOC</mi><mo>·</mo><msub><mi>C</mi><mi>des</mi></msub></mrow></mrow><mo>+</mo><mrow><mrow><mfrac><mi>b</mi><mrow><mn>2</mn><mo></mo><msub><mi>P</mi><mi>max</mi></msub></mrow></mfrac><mo></mo><mrow><mo>[</mo><mrow><mrow><msub><mi>Reg</mi><mi>award</mi></msub><mo></mo><mi>E</mi><mo></mo><mrow><mo>{</mo><msub><mi>Reg</mi><mi>signal</mi></msub><mo>}</mo></mrow></mrow><mo>-</mo><mrow><mi>E</mi><mo></mo><mrow><mo>{</mo><msub><mi>P</mi><mi>campus</mi></msub><mo>}</mo></mrow></mrow></mrow><mo>]</mo></mrow></mrow><mo></mo><mi>Δ</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>t</mi></mrow><mo>+</mo><mrow><mi>b</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>Δ</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>t</mi></mrow><mo>+</mo><mrow><mfrac><msup><mi>b</mi><mn>2</mn></msup><mrow><mn>4</mn><mo></mo><msub><mi>P</mi><mi>max</mi></msub></mrow></mfrac><mo></mo><mi>Δ</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>t</mi></mrow></mrow><mo>=</mo><mn>0</mn></mrow></mrow></mrow></math></maths>

High level controller <b>2212</b> may solve the equation for midpoint b in terms of ΔSOC.

High level controller <b>2212</b> may perform an optimization to find optimal midpoints b for each frequency response period within an optimization window (e.g., each hour for the next day) given the electrical costs over the optimization window. Optimal midpoints b may be the midpoints that maximize an objective function that includes both frequency response revenue and costs of electricity and battery degradation. For example, an objective function J can be written as:

<maths id="MATH-US-00038" num="00038"><math overflow="scroll"><mrow><mi>J</mi><mo>=</mo><mrow><mrow><munderover><mo>∑</mo><mrow><mi>k</mi><mo>=</mo><mn>1</mn></mrow><mi>h</mi></munderover><mo></mo><mrow><mi>Rev</mi><mo></mo><mrow><mo>(</mo><msub><mi>Reg</mi><mrow><mi>award</mi><mo>,</mo><mi>k</mi></mrow></msub><mo>)</mo></mrow></mrow></mrow><mo>+</mo><mrow><munderover><mo>∑</mo><mrow><mi>k</mi><mo>=</mo><mn>1</mn></mrow><mi>h</mi></munderover><mo></mo><mrow><msub><mi>c</mi><mi>k</mi></msub><mo></mo><msub><mi>b</mi><mi>k</mi></msub></mrow></mrow><mo>+</mo><mrow><munder><mi>min</mi><mi>period</mi></munder><mo></mo><mrow><mo>(</mo><mrow><msub><mi>P</mi><mrow><mi>campus</mi><mo>,</mo><mi>k</mi></mrow></msub><mo>+</mo><msub><mi>b</mi><mi>k</mi></msub></mrow><mo>)</mo></mrow></mrow><mo>-</mo><mrow><munderover><mo>∑</mo><mrow><mi>k</mi><mo>=</mo><mn>1</mn></mrow><mi>h</mi></munderover><mo></mo><msub><mi>λ</mi><mrow><mi>bat</mi><mo>,</mo><mi>k</mi></mrow></msub></mrow></mrow></mrow></math></maths>

where Rev(Reg_award,k) is the frequency response revenue at time step k, c_kb_kis the cost of electricity purchased at time step k, the min( ) term is the demand charge based on the maximum rate of electricity consumption during the applicable demand charge period, and λ_bat,kis the monetized cost battery degradation at time step k. The electricity cost is expressed as a positive value because drawing power from energy grid <b>2004</b> is represented as a negative power and therefore will result in negative value (i.e., a cost) in the objective function. The demand charge is expressed as a minimum for the same reason (i.e., the most negative power value represents maximum power draw from energy grid <b>2004</b>).

High level controller <b>2212</b> may estimate the frequency response revenue Rev(Reg_award,k) as a function of the midpoints b. In some embodiments, high level controller <b>2212</b> estimates frequency response revenue using the following equation:

&lt;br /&gt;<i>Rev</i>(<i>Reg</i>_award)=<i>Reg</i>_award(<i>CP</i>_cap<i>+MR·CP</i>_perf)

where CP_cap, MR, and CP_perfare the energy market statistics received from energy market predictor <b>2216</b> and Reg_awardis a function of the midpoint b. For example, high level controller <b>2212</b> may place a bid that is as large as possible for a given midpoint, as shown in the following equation:

&lt;br /&gt;<i>Reg</i>_award<i>=P</i>_limit<i>−|b|</i>

where P_limitis the power rating of power inverter <b>2006</b>. Advantageously, selecting Reg_awardas a function of midpoint b allows high level controller <b>2212</b> to predict the frequency response revenue that will result from a given midpoint b.

High level controller <b>2212</b> may estimate the cost of battery degradation λ_batas a function of the midpoints b. For example, high level controller <b>2212</b> may use a battery life model to predict a loss in battery capacity that will result from a set of midpoints b, power outputs, and/or other variables that can be manipulated by controller <b>2012</b>. In some embodiments, the battery life model expresses the loss in battery capacity C_loss,addas a sum of multiple piecewise linear functions, as shown in the following equation:

&lt;br /&gt;<i>C</i>_loss,add<i>=f</i>₁(<i>T</i>_cell)+<i>f</i>₂(SOC)+<i>f</i>₃(DOD)+<i>f</i>₄(PR)+<i>f</i>₅(ER)−<i>C</i>_loss,nom

where T_cellis the cell temperature, SOC is the state-of-charge, DOD is the depth of discharge, PR is the average power ratio (e.g.,

<maths id="MATH-US-00039" num="00039"><math overflow="scroll"><mrow><mrow><mrow><mi>PR</mi><mo>=</mo><mrow><mi>avg</mi><mo></mo><mrow><mo>(</mo><mfrac><mi>P</mi><msub><mi>P</mi><mi>des</mi></msub></mfrac><mo>)</mo></mrow></mrow></mrow><mo>)</mo></mrow><mo>,</mo></mrow></math></maths>

and ER is the average effort ratio (e.g.,

<maths id="MATH-US-00040" num="00040"><math overflow="scroll"><mrow><mi>ER</mi><mo>=</mo><mrow><mi>avg</mi><mo></mo><mrow><mo>(</mo><mfrac><mrow><mi>Δ</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>P</mi></mrow><msub><mi>P</mi><mi>des</mi></msub></mfrac><mo>)</mo></mrow></mrow></mrow></math></maths>

of battery <b>2008</b>. Each of these terms is described in greater detail with reference to <figref idref="DRAWINGS">FIG. 23</figref>. Advantageously, several of the terms in the battery life model depend on the midpoints b and power setpoints selected by controller <b>2012</b>. This allows high level controller <b>2212</b> to predict a loss in battery capacity that will result from a given set of control outputs. High level controller <b>2212</b> may monetize the loss in battery capacity and include the monetized cost of battery degradation λ_batin the objective function J.

In some embodiments, high level controller <b>2212</b> generates a set of filter parameters for low level controller <b>2214</b>. The filter parameters may be used by low level controller <b>2214</b> as part of a low-pass filter that removes high frequency components from the regulation signal. In some embodiments, high level controller <b>2212</b> generates a set of filter parameters that transform the regulation signal into an optimal frequency response signal Res_FR. For example, high level controller <b>2212</b> may perform a second optimization process to determine an optimal frequency response Res_FRbased on the optimized values for Reg_awardand midpoint b.

In some embodiments, high level controller <b>2212</b> determines the optimal frequency response Res_FRby optimizing value function J with the frequency response revenue Rev(Reg_award) defined as follows:

&lt;br /&gt;<i>Rev</i>(<i>Reg</i>_award)=<i>PS·Reg</i>_award(<i>CP</i>_cap<i>+MR·CP</i>_perf)

and with the frequency response Res_FRsubstituted for the regulation signal in the battery life model. The performance score PS may be based on several factors that indicate how well the optimal frequency response Res_FRtracks the regulation signal. Closely tracking the regulation signal may result in higher performance scores, thereby increasing the frequency response revenue. However, closely tracking the regulation signal may also increase the cost of battery degradation λ_bat. The optimized frequency response Res_FRrepresents an optimal tradeoff between decreased frequency response revenue and increased battery life. High level controller <b>2212</b> may use the optimized frequency response Res_FRto generate a set of filter parameters for low level controller <b>2214</b>. These and other features of high level controller <b>2212</b> are described in greater detail with reference to <figref idref="DRAWINGS">FIG. 23</figref>.

Still referring to <figref idref="DRAWINGS">FIG. 22</figref>, frequency response controller <b>2012</b> is shown to include a low level controller <b>2214</b>. Low level controller <b>2214</b> is shown receiving the midpoints b and the filter parameters from high level controller <b>2212</b>. Low level controller <b>2214</b> may also receive the campus power signal from campus <b>2002</b> and the regulation signal from incentive provider <b>2014</b>. Low level controller <b>2214</b> may use the regulation signal to predict future values of the regulation signal and may filter the predicted regulation signal using the filter parameters provided by high level controller <b>2212</b>.

Low level controller <b>2214</b> may use the filtered regulation signal to determine optimal power setpoints for power inverter <b>2006</b>. For example, low level controller <b>2214</b> may use the filtered regulation signal to calculate the desired interconnection power P_POI* using the following equation:

&lt;br /&gt;<i>P</i>_POI<i>*=Reg</i>_award<i>·Reg</i>_filter<i>+b </i>

where Reg_filteris the filtered regulation signal. Low level controller <b>2214</b> may subtract the campus power P_campusfrom the desired interconnection power P_POI* to calculate the optimal power setpoints P_SPfor power inverter <b>2006</b>, as shown in the following equation:

&lt;br /&gt;<i>P</i>_SP<i>=P</i>_POI<i>*−P</i>_campus

In some embodiments, low level controller <b>2214</b> performs an optimization to determine how closely to track P_POI*. For example, low level controller <b>2214</b> may determine an optimal frequency response Res_FRby optimizing value function J with the frequency response revenue Rev(Reg_award) defined as follows:

&lt;br /&gt;<i>Rev</i>(<i>Reg</i>_award<i>=PS·Reg</i>_award(<i>CP</i>_cap<i>+MR·CP</i>_perf)

and with the frequency response Res_FRsubstituted for the regulation signal in the battery life model. Low level controller <b>2214</b> may use the optimal frequency response Res_FRin place of the filtered frequency response Reg_filterto calculate the desired interconnection power P_POI* and power setpoints P_SPas previously described. These and other features of low level controller <b>2214</b> are described in greater detail with reference to <figref idref="DRAWINGS">FIG. 24</figref>.

High Level Controller

Referring now to <figref idref="DRAWINGS">FIG. 23</figref>, a block diagram illustrating high level controller <b>2212</b> in greater detail is shown, according to an exemplary embodiment. High level controller <b>2212</b> is shown to include a constant state-of-charge (SOC) controller <b>2302</b> and a variable SOC controller <b>2308</b>. Constant SOC controller <b>2302</b> may be configured to generate a midpoint b that results in battery <b>2008</b> having the same SOC at the beginning and the end of each frequency response period. In other words, constant SOC controller <b>2308</b> may determine a midpoint b that maintains battery <b>2008</b> at a predetermined SOC at the beginning of each frequency response period. Variable SOC controller <b>2308</b> may generate midpoint b using an optimization procedure that allows the SOC of battery <b>2008</b> to have different values at the beginning and end of the frequency response period. In other words, variable SOC controller <b>2308</b> may determine a midpoint b that results in a net change in the SOC of battery <b>2008</b> over the duration of the frequency response period.

Constant State-of-Charge Controller

Constant SOC controller <b>2302</b> may determine midpoint b by equating the desired power P_POI* at POI <b>2010</b> with the actual power at POI <b>2010</b> as shown in the following equation:

&lt;br /&gt;(<i>Reg</i>_signal)(<i>Reg</i>_award)+<i>b=P</i>_bat<i>P</i>_loss<i>+P</i>_campus

where the left side of the equation (Reg_signal) (Reg_award)+b is the desired power P_POI* at POI <b>2010</b> and the right side of the equation is the actual power at POI <b>2010</b>. Integrating over the frequency response period results in the following equation:

<maths id="MATH-US-00041" num="00041"><math overflow="scroll"><mrow><mrow><munder><mo>∫</mo><mi>period</mi></munder><mo></mo><mrow><mrow><mo>(</mo><mrow><mrow><mrow><mo>(</mo><msub><mi>Reg</mi><mi>signal</mi></msub><mo>)</mo></mrow><mo></mo><mrow><mo>(</mo><msub><mi>Reg</mi><mi>award</mi></msub><mo>)</mo></mrow></mrow><mo>+</mo><mi>b</mi></mrow><mo>)</mo></mrow><mo></mo><mrow><mo></mo><mi>t</mi></mrow></mrow></mrow><mo>=</mo><mrow><munder><mo>∫</mo><mi>period</mi></munder><mo></mo><mrow><mrow><mo>(</mo><mrow><msub><mi>P</mi><mi>bat</mi></msub><mo>+</mo><msub><mi>P</mi><mi>loss</mi></msub><mo>+</mo><msub><mi>P</mi><mi>campus</mi></msub></mrow><mo>)</mo></mrow><mo></mo><mrow><mo></mo><mi>t</mi></mrow></mrow></mrow></mrow></math></maths>

Since the SOC of battery <b>2008</b> is maintained at the same value at the beginning and end of the frequency response period, the integral of the battery power P_batover the frequency response period is zero (i.e., ∫P_batdt=0). Accordingly, the previous equation can be rewritten as follows:

<maths id="MATH-US-00042" num="00042"><math overflow="scroll"><mrow><mi>b</mi><mo>=</mo><mrow><mrow><munder><mo>∫</mo><mi>period</mi></munder><mo></mo><mrow><msub><mi>P</mi><mi>loss</mi></msub><mo></mo><mrow><mo></mo><mi>t</mi></mrow></mrow></mrow><mo>+</mo><mrow><munder><mo>∫</mo><mi>period</mi></munder><mo></mo><mrow><msub><mi>P</mi><mi>campus</mi></msub><mo></mo><mrow><mo></mo><mi>t</mi></mrow></mrow></mrow><mo>-</mo><mrow><msub><mi>Reg</mi><mi>award</mi></msub><mo></mo><mrow><munder><mo>∫</mo><mi>period</mi></munder><mo></mo><mrow><msub><mi>Reg</mi><mi>signal</mi></msub><mo></mo><mrow><mo></mo><mi>t</mi></mrow></mrow></mrow></mrow></mrow></mrow></math></maths>

where the term ∫P_batdt has been omitted because ∫P_batdt=0. This is ideal behavior if the only goal is to maximize frequency response revenue. Keeping the SOC of battery <b>2008</b> at a constant value (and near 50%) will allow system <b>2000</b> to participate in the frequency market during all hours of the day.

Constant SOC controller <b>2302</b> may use the estimated values of the campus power signal received from campus <b>2002</b> to predict the value of ∫P_campusdt over the frequency response period. Similarly, constant SOC controller <b>2302</b> may use the estimated values of the regulation signal from incentive provider <b>2014</b> to predict the value of ∫Reg_signaldt over the frequency response period. Reg_awardcan be expressed as a function of midpoint b as previously described (e.g., Reg_award=P_limit−|b|). Therefore, the only remaining term in the equation for midpoint b is the expected battery power loss ∫P_loss.

Constant SOC controller <b>2302</b> is shown to include a battery power loss estimator <b>2304</b>. Battery power loss estimator <b>2304</b> may estimate the value of ∫P_lossdt using a Thevinin equivalent circuit model of battery <b>2008</b>. For example, battery power loss estimator <b>2304</b> may model battery <b>2008</b> as a voltage source in series with a resistor. The voltage source has an open circuit voltage of V_OCand the resistor has a resistance of R_TH. An electric current I flows from the voltage source through the resistor.

To find the battery power loss in terms of the supplied power P_sup, battery power loss estimator <b>2304</b> may identify the supplied power P_supas a function of the current I, the open circuit voltage V_OC, and the resistance R_THas shown in the following equation:

&lt;br /&gt;<i>P</i>_sup<i>=V</i>_OC<i>I−I</i>²<i>R</i>_TH

which can be rewritten as:

<maths id="MATH-US-00043" num="00043"><math overflow="scroll"><mrow><mrow><mfrac><msup><mi>I</mi><mn>2</mn></msup><msub><mi>I</mi><mi>SC</mi></msub></mfrac><mo>-</mo><mi>I</mi><mo>+</mo><mfrac><msup><mi>P</mi><mi>′</mi></msup><mn>4</mn></mfrac></mrow><mo>=</mo><mn>0</mn></mrow></math></maths>

with the following substitutions:

<maths id="MATH-US-00044" num="00044"><math overflow="scroll"><mrow><mrow><msub><mi>I</mi><mi>SC</mi></msub><mo>=</mo><mfrac><msub><mi>V</mi><mi>OC</mi></msub><msub><mi>R</mi><mi>TH</mi></msub></mfrac></mrow><mo>,</mo><mrow><msup><mi>P</mi><mi>′</mi></msup><mo>=</mo><mfrac><mi>P</mi><msub><mi>P</mi><mi>max</mi></msub></mfrac></mrow><mo>,</mo><mrow><msub><mi>P</mi><mi>max</mi></msub><mo>=</mo><mfrac><msubsup><mi>V</mi><mi>OC</mi><mn>2</mn></msubsup><mrow><mn>4</mn><mo></mo><msub><mi>R</mi><mi>TH</mi></msub></mrow></mfrac></mrow></mrow></math></maths>

where P is the supplied power and P_maxis the maximum possible power transfer.

Battery power loss estimator <b>2304</b> may solve for the current I as follows:

<maths id="MATH-US-00045" num="00045"><math overflow="scroll"><mrow><mi>I</mi><mo>=</mo><mrow><mfrac><msub><mi>I</mi><mi>SC</mi></msub><mn>2</mn></mfrac><mo></mo><mrow><mo>(</mo><mrow><mn>1</mn><mo>-</mo><msqrt><mrow><mn>1</mn><mo>-</mo><msup><mi>P</mi><mi>′</mi></msup></mrow></msqrt></mrow><mo>)</mo></mrow></mrow></mrow></math></maths>

which can be converted into an expression for power loss P_lossin terms of the supplied power P and the maximum possible power transfer P_maxas shown in the following equation:

&lt;br /&gt;<i>P</i>_loss<i>=P</i>_max(1−√{square root over (1−<i>P</i>′)})²

Battery power loss estimator <b>2304</b> may simplify the previous equation by approximating the expression (1−√{square root over (1−P′)}) as a linear function about P′=0. This results in the following approximation for P_loss:

<maths id="MATH-US-00046" num="00046"><math overflow="scroll"><mrow><msub><mi>P</mi><mi>loss</mi></msub><mo>≈</mo><msup><mrow><msub><mi>P</mi><mi>max</mi></msub><mo></mo><mrow><mo>(</mo><mfrac><msup><mi>P</mi><mi>′</mi></msup><mn>2</mn></mfrac><mo>)</mo></mrow></mrow><mn>2</mn></msup></mrow></math></maths>

which is a good approximation for powers up to one-fifth of the maximum power.

Battery power loss estimator <b>2304</b> may calculate the expected value of ∫P_lossdt over the frequency response period as follows:

<maths id="MATH-US-00047" num="00047"><math overflow="scroll"><mtable><mtr><mtd><mrow><mrow><munder><mo>∫</mo><mi>period</mi></munder><mo></mo><mrow><msub><mi>P</mi><mi>loss</mi></msub><mo></mo><mrow><mo></mo><mi>t</mi></mrow></mrow></mrow><mo>=</mo>&lt;mi /&gt;<mo></mo><mrow><munder><mo>∫</mo><mi>period</mi></munder><mo></mo><mrow><mrow><mo>-</mo><msup><mrow><msub><mi>P</mi><mi>max</mi></msub><mo></mo><mrow><mo>(</mo><mfrac><mrow><mrow><msub><mi>Reg</mi><mi>award</mi></msub><mo></mo><msub><mi>Reg</mi><mi>signal</mi></msub></mrow><mo>+</mo><mi>b</mi><mo>-</mo><msub><mi>P</mi><mi>campus</mi></msub></mrow><mrow><mn>2</mn><mo></mo><msub><mi>P</mi><mi>max</mi></msub></mrow></mfrac><mo>)</mo></mrow></mrow><mn>2</mn></msup></mrow><mo></mo><mrow><mo></mo><mi>t</mi></mrow></mrow></mrow></mrow></mtd></mtr><mtr><mtd><mrow><mo>=</mo>&lt;mi /&gt;<mo></mo><mrow><mfrac><mn>1</mn><mrow><mn>4</mn><mo></mo><msub><mi>P</mi><mi>max</mi></msub></mrow></mfrac><mo>[</mo><mrow><mrow><mn>2</mn><mo></mo><msub><mi>Reg</mi><mi>award</mi></msub><mo></mo><mrow><munder><mo>∫</mo><mi>period</mi></munder><mo></mo><mrow><msub><mi>P</mi><mi>campus</mi></msub><mo></mo><msub><mi>Reg</mi><mi>signal</mi></msub><mo></mo><mrow><mo></mo><mi>t</mi></mrow></mrow></mrow></mrow><mo>-</mo></mrow></mrow></mrow></mtd></mtr><mtr><mtd><mrow><mrow><mrow>&lt;mi /&gt;<mo></mo><mrow><mrow><munder><mo>∫</mo><mi>period</mi></munder><mo></mo><mrow><msubsup><mi>P</mi><mi>campus</mi><mn>2</mn></msubsup><mo></mo><mrow><mo></mo><mi>t</mi></mrow></mrow></mrow><mo>-</mo><mrow><msubsup><mi>Reg</mi><mi>award</mi><mn>2</mn></msubsup><mo></mo><mrow><munder><mo>∫</mo><mi>period</mi></munder><mo></mo><mrow><msubsup><mi>Reg</mi><mi>signal</mi><mn>2</mn></msubsup><mo></mo><mrow><mo></mo><mi>t</mi></mrow></mrow></mrow></mrow></mrow><mo>]</mo></mrow><mo>+</mo></mrow><mo> </mo></mrow></mtd></mtr><mtr><mtd><mrow>&lt;mi /&gt;<mo></mo><mrow><mo> </mo><mrow><mrow><mfrac><mi>b</mi><mrow><mn>2</mn><mo></mo><msub><mi>P</mi><mi>max</mi></msub></mrow></mfrac><mo></mo><mrow><mo>[</mo><mrow><mrow><munder><mo>∫</mo><mi>period</mi></munder><mo></mo><mrow><msubsup><mi>P</mi><mi>campus</mi><mn>2</mn></msubsup><mo></mo><mrow><mo></mo><mi>t</mi></mrow></mrow></mrow><mo>-</mo><mrow><msub><mi>Reg</mi><mi>award</mi></msub><mo></mo><mrow><munder><mo>∫</mo><mi>period</mi></munder><mo></mo><mrow><msub><mi>Reg</mi><mi>signal</mi></msub><mo></mo><mrow><mo></mo><mi>t</mi></mrow></mrow></mrow></mrow></mrow><mo>]</mo></mrow></mrow><mo>-</mo></mrow></mrow></mrow></mtd></mtr><mtr><mtd><mrow>&lt;mi /&gt;<mo></mo><mrow><mfrac><msup><mi>b</mi><mn>2</mn></msup><mrow><mn>4</mn><mo></mo><msub><mi>P</mi><mi>max</mi></msub></mrow></mfrac><mo></mo><mi>Δ</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>t</mi></mrow></mrow></mtd></mtr><mtr><mtd><mrow><mo>=</mo>&lt;mi /&gt;<mo></mo><mrow><mfrac><mn>1</mn><mrow><mn>4</mn><mo></mo><msub><mi>P</mi><mi>max</mi></msub></mrow></mfrac><mo>[</mo><mrow><mrow><mi>E</mi><mo></mo><mrow><mo>{</mo><msubsup><mi>P</mi><mi>campus</mi><mn>2</mn></msubsup><mo>}</mo></mrow></mrow><mo>+</mo><mrow><msubsup><mi>Reg</mi><mi>award</mi><mn>2</mn></msubsup><mo></mo><mi>E</mi><mo></mo><mrow><mo>{</mo><msubsup><mi>Reg</mi><mi>signal</mi><mn>2</mn></msubsup><mo>}</mo></mrow></mrow><mo>-</mo></mrow></mrow></mrow></mtd></mtr><mtr><mtd><mrow><mrow><mrow><mrow>&lt;mi /&gt;<mo></mo><mrow><mn>2</mn><mo></mo><msub><mi>Reg</mi><mi>award</mi></msub><mo></mo><mi>E</mi><mo></mo><mrow><mo>{</mo><msub><mi>Reg</mi><mi>signal</mi></msub><mo>}</mo></mrow><mo></mo><mi>E</mi><mo></mo><mrow><mo>{</mo><msub><mi>P</mi><mi>campus</mi></msub><mo>}</mo></mrow></mrow><mo>]</mo></mrow><mo></mo><mi>Δ</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>t</mi></mrow><mo>-</mo></mrow><mo> </mo></mrow></mtd></mtr><mtr><mtd><mrow>&lt;mi /&gt;<mo></mo><mrow><mrow><mrow><mfrac><mi>b</mi><mrow><mn>2</mn><mo></mo><msub><mi>P</mi><mi>max</mi></msub></mrow></mfrac><mo></mo><mrow><mo>[</mo><mrow><mrow><msub><mi>Reg</mi><mi>award</mi></msub><mo></mo><mi>E</mi><mo></mo><mrow><mo>{</mo><msub><mi>Reg</mi><mi>signal</mi></msub><mo>}</mo></mrow></mrow><mo>-</mo><mrow><mi>E</mi><mo></mo><mrow><mo>{</mo><msub><mi>P</mi><mi>campus</mi></msub><mo>}</mo></mrow></mrow></mrow><mo>]</mo></mrow></mrow><mo></mo><mi>Δ</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>t</mi></mrow><mo>-</mo><mrow><mfrac><msup><mi>b</mi><mn>2</mn></msup><mrow><mn>4</mn><mo></mo><msub><mi>P</mi><mi>max</mi></msub></mrow></mfrac><mo></mo><mi>Δ</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>t</mi></mrow></mrow></mrow></mtd></mtr></mtable></math></maths>

where the notation E{ } indicates that the variable within the brackets { } is ergodic and can be approximated by the estimated mean of the variable. This formulation allows battery power loss estimator <b>2304</b> to estimate ∫P_lossdt as a function of other variables such as Reg_award, Reg_signal, P_campus, midpoint b, and P_max.

Constant SOC controller <b>2302</b> is shown to include a midpoint calculator <b>2306</b>. Midpoint calculator <b>2306</b> may be configured to calculate midpoint b by substituting the previous expression for ∫P_lossdt into the equation for midpoint b. After substituting known and estimated values, the equation for midpoint b can be rewritten as follows:

<maths id="MATH-US-00048" num="00048"><math overflow="scroll"><mrow><mrow><mrow><mrow><mrow><mfrac><mn>1</mn><mrow><mn>4</mn><mo></mo><msub><mi>P</mi><mi>max</mi></msub></mrow></mfrac><mo></mo><mrow><mo>[</mo><mrow><mrow><mi>E</mi><mo></mo><mrow><mo>{</mo><msubsup><mi>P</mi><mi>campus</mi><mn>2</mn></msubsup><mo>}</mo></mrow></mrow><mo>+</mo><mrow><msubsup><mi>Reg</mi><mi>award</mi><mn>2</mn></msubsup><mo></mo><mi>E</mi><mo></mo><mrow><mo>{</mo><msubsup><mi>Reg</mi><mi>signal</mi><mn>2</mn></msubsup><mo>}</mo></mrow></mrow><mo>-</mo><mrow><mn>2</mn><mo></mo><msub><mi>Reg</mi><mi>award</mi></msub><mo></mo><mi>E</mi><mo></mo><mrow><mo>{</mo><msub><mi>Reg</mi><mi>signal</mi></msub><mo>}</mo></mrow><mo></mo><mi>E</mi><mo></mo><mrow><mo>{</mo><msub><mi>P</mi><mi>campus</mi></msub><mo>}</mo></mrow></mrow></mrow><mo>]</mo></mrow></mrow><mo></mo><mi>Δ</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>t</mi></mrow><mo>+</mo></mrow><mo> </mo></mrow><mo></mo><mrow><mo> </mo><mrow><mrow><mrow><mrow><mo>[</mo><mrow><mrow><msub><mi>Reg</mi><mi>award</mi></msub><mo></mo><mi>E</mi><mo></mo><mrow><mo>{</mo><msub><mi>Reg</mi><mi>signal</mi></msub><mo>}</mo></mrow></mrow><mo>-</mo><mrow><mi>E</mi><mo></mo><mrow><mo>{</mo><msub><mi>P</mi><mi>campus</mi></msub><mo>}</mo></mrow></mrow></mrow><mo>]</mo></mrow><mo></mo><mi>Δ</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>t</mi></mrow><mo>+</mo><mrow><mrow><mfrac><mi>b</mi><mrow><mn>2</mn><mo></mo><msub><mi>P</mi><mi>max</mi></msub></mrow></mfrac><mo></mo><mrow><mo>[</mo><mrow><mrow><msub><mi>Reg</mi><mi>award</mi></msub><mo></mo><mi>E</mi><mo></mo><mrow><mo>{</mo><msub><mi>Reg</mi><mi>signal</mi></msub><mo>}</mo></mrow></mrow><mo>-</mo><mrow><mi>E</mi><mo></mo><mrow><mo>{</mo><msub><mi>P</mi><mi>campus</mi></msub><mo>}</mo></mrow></mrow></mrow><mo>]</mo></mrow></mrow><mo></mo><mi>Δ</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>t</mi></mrow><mo>+</mo><mrow><mi>b</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>Δ</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>t</mi></mrow><mo>+</mo><mrow><mfrac><msup><mi>b</mi><mn>2</mn></msup><mrow><mn>4</mn><mo></mo><msub><mi>P</mi><mi>max</mi></msub></mrow></mfrac><mo></mo><mi>Δ</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>t</mi></mrow></mrow><mo>=</mo><mn>0</mn></mrow></mrow></mrow></math></maths>

Midpoint calculator <b>2306</b> may solve the equation for midpoint b to determine the midpoint b that maintains battery <b>2008</b> at a constant state-of-charge.

Variable State-of-Charge Controller

Variable SOC controller <b>2308</b> may determine optimal midpoints b by allowing the SOC of battery <b>2008</b> to have different values at the beginning and end of a frequency response period. For embodiments in which the SOC of battery <b>2008</b> is allowed to vary, the integral of the battery power P_batover the frequency response period can be expressed as −ΔSOC·C_desas shown in the following equation:

<maths id="MATH-US-00049" num="00049"><math overflow="scroll"><mrow><mrow><munder><mo>∫</mo><mi>period</mi></munder><mo></mo><mrow><msub><mi>P</mi><mi>bat</mi></msub><mo></mo><mrow><mo></mo><mi>t</mi></mrow></mrow></mrow><mo>=</mo><mrow><mrow><mo>-</mo><mi>Δ</mi></mrow><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mrow><mi>SOC</mi><mo>·</mo><msub><mi>C</mi><mi>des</mi></msub></mrow></mrow></mrow></math></maths>

where ΔSOC is the change in the SOC of battery <b>2008</b> over the frequency response period and C_desis the design capacity of battery <b>2008</b>. The SOC of battery <b>2008</b> may be a normalized variable (i.e., 0≦SOC≦1) such that the term SOC·C_desrepresents the amount of energy stored in battery <b>2008</b> for a given state-of-charge. The SOC is shown as a negative value because drawing energy from battery <b>2008</b> (i.e., a positive P_bat) decreases the SOC of battery <b>2008</b>. The equation for midpoint b becomes:

<maths id="MATH-US-00050" num="00050"><math overflow="scroll"><mrow><mi>b</mi><mo>=</mo><mrow><mrow><munder><mo>∫</mo><mi>period</mi></munder><mo></mo><mrow><msub><mi>P</mi><mi>loss</mi></msub><mo></mo><mrow><mo></mo><mi>t</mi></mrow></mrow></mrow><mo>+</mo><mrow><munder><mo>∫</mo><mi>period</mi></munder><mo></mo><mrow><msub><mi>P</mi><mi>campus</mi></msub><mo></mo><mrow><mo></mo><mi>t</mi></mrow></mrow></mrow><mo>+</mo><mrow><munder><mo>∫</mo><mi>period</mi></munder><mo></mo><mrow><msub><mi>P</mi><mi>bat</mi></msub><mo></mo><mrow><mo></mo><mi>t</mi></mrow></mrow></mrow><mo>-</mo><mrow><msub><mi>Reg</mi><mi>award</mi></msub><mo></mo><mrow><munder><mo>∫</mo><mi>period</mi></munder><mo></mo><mrow><msub><mi>Reg</mi><mi>signal</mi></msub><mo></mo><mrow><mo></mo><mi>t</mi></mrow></mrow></mrow></mrow></mrow></mrow></math></maths>

Variable SOC controller <b>2308</b> is shown to include a battery power loss estimator <b>2310</b> and a midpoint optimizer <b>2312</b>. Battery power loss estimator <b>2310</b> may be the same or similar to battery power loss estimator <b>2304</b>. Midpoint optimizer <b>2312</b> may be configured to establish a relationship between the midpoint b and the SOC of battery <b>2008</b>. For example, after substituting known and estimated values, the equation for midpoint b can be written as follows:

<maths id="MATH-US-00051" num="00051"><math overflow="scroll"><mrow><mrow><mrow><mfrac><mn>1</mn><mrow><mn>4</mn><mo></mo><msub><mi>P</mi><mi>max</mi></msub></mrow></mfrac><mo></mo><mrow><mo>[</mo><mrow><mrow><mi>E</mi><mo></mo><mrow><mo>{</mo><msubsup><mi>P</mi><mi>campus</mi><mn>2</mn></msubsup><mo>}</mo></mrow></mrow><mo>+</mo><msubsup><mi>Reg</mi><mi>award</mi><mn>2</mn></msubsup><mo>+</mo><mrow><mi>E</mi><mo></mo><mrow><mo>{</mo><msubsup><mi>Reg</mi><mi>signal</mi><mn>2</mn></msubsup><mo>}</mo></mrow></mrow><mo>-</mo><mrow><mn>2</mn><mo></mo><msub><mi>Reg</mi><mi>award</mi></msub><mo></mo><mi>E</mi><mo></mo><mrow><mo>{</mo><msub><mi>Reg</mi><mi>signal</mi></msub><mo>}</mo></mrow><mo></mo><mi>E</mi><mo></mo><mrow><mo>{</mo><msub><mi>P</mi><mi>campus</mi></msub><mo>}</mo></mrow></mrow></mrow><mo>]</mo></mrow></mrow><mo></mo><mi>Δ</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>t</mi></mrow><mo>+</mo><mrow><mo> </mo><mrow><mrow><mrow><mrow><mo>[</mo><mrow><mrow><msub><mi>Reg</mi><mi>award</mi></msub><mo></mo><mi>E</mi><mo></mo><mrow><mo>{</mo><msub><mi>Reg</mi><mi>signal</mi></msub><mo>}</mo></mrow></mrow><mo>+</mo><mrow><mi>E</mi><mo></mo><mrow><mo>{</mo><msub><mi>P</mi><mi>campus</mi></msub><mo>}</mo></mrow></mrow></mrow><mo>]</mo></mrow><mo></mo><mi>Δ</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>t</mi></mrow><mo>+</mo><mrow><mi>S</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>O</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mrow><mi>C</mi><mo>·</mo><msub><mi>C</mi><mi>des</mi></msub></mrow></mrow><mo>+</mo><mrow><mrow><mfrac><mi>b</mi><mrow><mn>2</mn><mo></mo><msub><mi>P</mi><mi>max</mi></msub></mrow></mfrac><mo></mo><mrow><mo>[</mo><mrow><mrow><msub><mi>Reg</mi><mi>award</mi></msub><mo></mo><mi>E</mi><mo></mo><mrow><mo>{</mo><msub><mi>Reg</mi><mi>signal</mi></msub><mo>}</mo></mrow></mrow><mo>-</mo><mrow><mi>E</mi><mo></mo><mrow><mo>{</mo><msub><mi>P</mi><mi>campus</mi></msub><mo>}</mo></mrow></mrow></mrow><mo>]</mo></mrow></mrow><mo></mo><mi>Δ</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>t</mi></mrow><mo>+</mo><mrow><mi>b</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>Δ</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>t</mi></mrow><mo>+</mo><mrow><mfrac><msup><mi>b</mi><mn>2</mn></msup><mrow><mn>4</mn><mo></mo><msub><mi>P</mi><mi>max</mi></msub></mrow></mfrac><mo></mo><mi>Δ</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>t</mi></mrow></mrow><mo>=</mo><mn>0</mn></mrow></mrow></mrow></math></maths>

Advantageously, the previous equation defines a relationship between midpoint b and the change in SOC of battery <b>2008</b>. Midpoint optimizer <b>2312</b> may use this equation to determine the impact that different values of midpoint b have on the SOC in order to determine optimal midpoints b. This equation can also be used by midpoint optimizer <b>2312</b> during optimization to translate constraints on the SOC in terms of midpoint b. For example, the SOC of battery <b>2008</b> may be constrained between zero and 1 (e.g., 0≦SOC≦1) since battery <b>2008</b> cannot be charged in excess of its maximum capacity or depleted below zero. Midpoint optimizer <b>2312</b> may use the relationship between ΔSOC and midpoint b to constrain the optimization of midpoint b to midpoint values that satisfy the capacity constraint.

Midpoint optimizer <b>2312</b> may perform an optimization to find optimal midpoints b for each frequency response period within the optimization window (e.g., each hour for the next day) given the electrical costs over the optimization window. Optimal midpoints b may be the midpoints that maximize an objective function that includes both frequency response revenue and costs of electricity and battery degradation. For example, an objective function J can be written as:

<maths id="MATH-US-00052" num="00052"><math overflow="scroll"><mrow><mi>J</mi><mo>=</mo><mrow><mrow><munderover><mo>∑</mo><mrow><mi>k</mi><mo>=</mo><mn>1</mn></mrow><mi>h</mi></munderover><mo></mo><mrow><mi>Rev</mi><mo></mo><mrow><mo>(</mo><msub><mi>Reg</mi><mrow><mi>award</mi><mo>,</mo><mi>k</mi></mrow></msub><mo>)</mo></mrow></mrow></mrow><mo>+</mo><mrow><munderover><mo>∑</mo><mrow><mi>k</mi><mo>=</mo><mn>1</mn></mrow><mi>hq</mi></munderover><mo></mo><mrow><msub><mi>c</mi><mi>k</mi></msub><mo></mo><msub><mi>b</mi><mi>k</mi></msub></mrow></mrow><mo>+</mo><mrow><munder><mi>min</mi><mi>period</mi></munder><mo></mo><mrow><mo>(</mo><mrow><msub><mi>P</mi><mrow><mi>campus</mi><mo>,</mo><mi>k</mi></mrow></msub><mo>+</mo><msub><mi>b</mi><mi>k</mi></msub></mrow><mo>)</mo></mrow></mrow><mo>-</mo><mrow><munderover><mo>∑</mo><mrow><mi>k</mi><mo>=</mo><mn>1</mn></mrow><mi>h</mi></munderover><mo></mo><msub><mi>λ</mi><mrow><mi>bat</mi><mo>,</mo><mi>k</mi></mrow></msub></mrow></mrow></mrow></math></maths>

where Rev(Reg_award,k) is the frequency response revenue at time step k, c_kb_kis the cost of electricity purchased at time step k, the min( ) term is the demand charge based on the maximum rate of electricity consumption during the applicable demand charge period, and λ_bat,kis the monetized cost battery degradation at time step k. Midpoint optimizer <b>2312</b> may use input from frequency response revenue estimator <b>2316</b> (e.g., a revenue model) to determine a relationship between midpoint b and Rev(Reg_award,k). Similarly, midpoint optimizer <b>2312</b> may use input from battery degradation estimator <b>2318</b> and/or revenue loss estimator <b>2320</b> to determine a relationship between midpoint b and the monetized cost of battery degradation λ_bat,k.

Still referring to <figref idref="DRAWINGS">FIG. 23</figref>, variable SOC controller <b>2308</b> is shown to include an optimization constraints module <b>2314</b>. Optimization constraints module <b>2314</b> may provide one or more constraints on the optimization performed by midpoint optimizer <b>2312</b>. The optimization constraints may be specified in terms of midpoint b or other variables that are related to midpoint b. For example, optimization constraints module <b>2314</b> may implement an optimization constraint specifying that the expected SOC of battery <b>2008</b> at the end of each frequency response period is between zero and one, as shown in the following equation:

<maths id="MATH-US-00053" num="00053"><math overflow="scroll"><mrow><mrow><mn>0</mn><mo>≤</mo><mrow><mrow><mi>S</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>O</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><msub><mi>C</mi><mn>0</mn></msub></mrow><mo>+</mo><mrow><munderover><mo>∑</mo><mrow><mi>i</mi><mo>=</mo><mn>1</mn></mrow><mi>j</mi></munderover><mo></mo><mrow><mi>Δ</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>S</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>O</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><msub><mi>C</mi><mi>i</mi></msub></mrow></mrow></mrow><mo>≤</mo><mrow><mn>1</mn><mo></mo><mstyle><mspace width="0.8em" height="0.8ex" /></mstyle><mo></mo><mrow><mo>∀</mo><mi>j</mi></mrow></mrow></mrow><mo>=</mo><mrow><mn>1</mn><mo></mo><mstyle><mspace width="0.8em" height="0.8ex" /></mstyle><mo></mo><mi>…</mi><mo></mo><mstyle><mspace width="0.8em" height="0.8ex" /></mstyle><mo></mo><mi>h</mi></mrow></mrow></math></maths>

where SOC₀is the SOC of battery <b>2008</b> at the beginning of the optimization window, ΔSOC_iis the change in SOC during frequency response period i, and h is the total number of frequency response periods within the optimization window.

In some embodiments, optimization constraints module <b>2314</b> implements an optimization constraint on midpoint b so that the power at POI <b>2010</b> does not exceed the power rating of power inverter <b>2006</b>. Such a constraint is shown in the following equation:

&lt;br /&gt;−<i>P</i>_limit<i>≦b</i>_k<i>+P</i>_campus,max^(p)<i>≦P</i>_limit

where P_limitis the power rating of power inverter <b>2006</b> and P_campus,max^(p)is the maximum value of P_campusat confidence level p. This constraint could also be implemented by identifying the probability that the sum of b_kand P_campus,maxexceeds the power inverter power rating (e.g., using a probability density function for P_campus,max) and limiting that probability to less than or equal to 1−p.

In some embodiments, optimization constraints module <b>2314</b> implements an optimization constraint to ensure (with a given probability) that the actual SOC of battery <b>2008</b> remains between zero and one at each time step during the applicable frequency response period. This constraint is different from the first optimization constraint which placed bounds on the expected SOC of battery <b>2008</b> at the end of each optimization period. The expected SOC of battery <b>2008</b> can be determined deterministically, whereas the actual SOC of battery <b>2008</b> is dependent on the campus power P_campusand the actual value of the regulation signal Reg_signalat each time step during the optimization period. In other words, for any value of Reg_award&gt;0, there is a chance that battery <b>2008</b> becomes fully depleted or fully charged while maintaining the desired power P_POI* at POI <b>2010</b>.

Optimization constraints module <b>2314</b> may implement the constraint on the actual SOC of battery <b>2008</b> by approximating the battery power P_bat(a random process) as a wide-sense stationary, correlated normally distributed process. Thus, the SOC of battery <b>2008</b> can be considered as a random walk. Determining if the SOC would violate the constraint is an example of a gambler's ruin problem. For example, consider a random walk described by the following equation:

&lt;br /&gt;<i>y</i>_k+1<i>=y</i>_k<i>+x</i>_k<i>,P</i>(<i>x</i>_k=1)=<i>p,P</i>(<i>x</i>_k=−1)=1−<i>p </i>

The probability P that y_k(starting at state z) will reach zero in less than n moves is given by the following equation:

<maths id="MATH-US-00054" num="00054"><math overflow="scroll"><mrow><mi>P</mi><mo>=</mo><mrow><mn>2</mn><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><msup><mrow><msup><mrow><msup><mi>a</mi><mrow><mo>-</mo><mn>1</mn></mrow></msup><mo></mo><mrow><mo>(</mo><mrow><mn>2</mn><mo></mo><mi>p</mi></mrow><mo>)</mo></mrow></mrow><mfrac><mrow><mi>n</mi><mo>-</mo><mi>z</mi></mrow><mn>2</mn></mfrac></msup><mo></mo><mrow><mo>[</mo><mrow><mn>2</mn><mo></mo><mrow><mo>(</mo><mrow><mn>1</mn><mo>-</mo><mi>p</mi></mrow><mo>)</mo></mrow></mrow><mo>]</mo></mrow></mrow><mfrac><mrow><mi>n</mi><mo>+</mo><mi>z</mi></mrow><mn>2</mn></mfrac></msup><mo></mo><mrow><munderover><mo>∑</mo><mrow><mi>v</mi><mo>=</mo><mn>1</mn></mrow><mfrac><mi>a</mi><mn>2</mn></mfrac></munderover><mo></mo><mrow><mrow><msup><mi>cos</mi><mrow><mi>n</mi><mo>-</mo><mn>1</mn></mrow></msup><mo></mo><mrow><mo>(</mo><mfrac><mrow><mi>π</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>v</mi></mrow><mi>a</mi></mfrac><mo>)</mo></mrow></mrow><mo></mo><mrow><mi>sin</mi><mo></mo><mrow><mo>(</mo><mfrac><mrow><mi>π</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>v</mi></mrow><mi>a</mi></mfrac><mo>)</mo></mrow></mrow><mo></mo><mrow><mi>sin</mi><mo></mo><mrow><mo>(</mo><mfrac><mrow><mi>π</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>zv</mi></mrow><mi>a</mi></mfrac><mo>)</mo></mrow></mrow></mrow></mrow></mrow></mrow></math></maths>

In some embodiments, each frequency response period includes approximately n=1800 time steps (e.g., one time step every two seconds for an hour). Therefore, the central limit theorem applies and it is possible to convert the autocorrelated random process for P_batand the limits on the SOC of battery <b>2008</b> into an uncorrelated random process of 1 or −1 with a limit of zero.

In some embodiments, optimization constraints module <b>2314</b> converts the battery power P_batinto an uncorrelated normal process driven by the regulation signal Reg_signal. For example, consider the original battery power described by the following equation:

&lt;br /&gt;<i>x</i>_k+1<i>=ax</i>_k<i>+e</i>_k<i>,x</i>_k<i>˜N</i>(μ,σ),<i>e</i>_k<i>˜N</i>(μ_e,σ_e)

where the signal x represents the battery power P_bat, α is an autocorrelation parameter, and e is a driving signal. In some embodiments, e represents the regulation signal Reg_signal. If the power of the signal x is known, then the power of signal e is also known, as shown in the following equations:

&lt;br /&gt;μ(1−α)=μ_e

&lt;br /&gt;<i>E{x</i>_k²}(1−α)²−2αμμ_e<i>=E{e</i>_k²}

&lt;br /&gt;<i>E{x</i>_k²}(1−α²)−2μ²α(1−α)=<i>E{e</i>_k²},

Additionally, the impulse response of the difference equation for x_k+1is:

&lt;br /&gt;<i>h</i>_k=α^k<i>k≧</i>0

Using convolution, x_kcan be expressed as follows:

<maths id="MATH-US-00055" num="00055"><math overflow="scroll"><mrow><msub><mi>x</mi><mi>k</mi></msub><mo>=</mo><mrow><munderover><mo>∑</mo><mrow><mi>i</mi><mo>=</mo><mn>1</mn></mrow><mi>k</mi></munderover><mo></mo><mrow><msup><mi>α</mi><mrow><mi>k</mi><mo>-</mo><mi>i</mi></mrow></msup><mo></mo><msub><mi>e</mi><mrow><mi>i</mi><mo>-</mo><mn>1</mn></mrow></msub></mrow></mrow></mrow></math></maths><maths id="MATH-US-00055-2" num="00055.2"><math overflow="scroll"><mrow><msub><mi>x</mi><mn>3</mn></msub><mo>=</mo><mrow><mrow><msup><mi>α</mi><mn>2</mn></msup><mo></mo><msub><mi>e</mi><mn>0</mn></msub></mrow><mo>+</mo><mrow><msup><mi>α</mi><mn>1</mn></msup><mo></mo><msub><mi>e</mi><mn>1</mn></msub></mrow><mo>+</mo><msub><mi>e</mi><mn>2</mn></msub></mrow></mrow></math></maths><maths id="MATH-US-00055-3" num="00055.3"><math overflow="scroll"><mrow><msub><mi>x</mi><mi>q</mi></msub><mo>=</mo><mrow><mrow><msup><mi>α</mi><mrow><mi>q</mi><mo>-</mo><mn>1</mn></mrow></msup><mo></mo><msub><mi>e</mi><mn>0</mn></msub></mrow><mo>+</mo><mrow><msup><mi>α</mi><mrow><mi>q</mi><mo>-</mo><mn>2</mn></mrow></msup><mo></mo><msub><mi>e</mi><mn>1</mn></msub></mrow><mo>+</mo><mi>…</mi><mo>+</mo><mrow><mi>α</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><msub><mi>e</mi><mrow><mi>q</mi><mo>-</mo><mn>2</mn></mrow></msub></mrow><mo>+</mo><msub><mi>e</mi><mrow><mi>q</mi><mo>-</mo><mn>1</mn></mrow></msub></mrow></mrow></math></maths>

A random walk driven by signal x_kcan be defined as follows:

<maths id="MATH-US-00056" num="00056"><math overflow="scroll"><mrow><msub><mi>y</mi><mi>k</mi></msub><mo>=</mo><mrow><mrow><munderover><mo>∑</mo><mrow><mi>j</mi><mo>=</mo><mn>1</mn></mrow><mi>k</mi></munderover><mo></mo><msub><mi>x</mi><mi>j</mi></msub></mrow><mo>=</mo><mrow><munderover><mo>∑</mo><mrow><mi>j</mi><mo>=</mo><mn>1</mn></mrow><mi>k</mi></munderover><mo></mo><mrow><munderover><mo>∑</mo><mrow><mi>i</mi><mo>=</mo><mn>1</mn></mrow><mi>j</mi></munderover><mo></mo><mrow><msup><mi>α</mi><mrow><mi>j</mi><mo>-</mo><mn>1</mn></mrow></msup><mo></mo><msub><mi>e</mi><mrow><mi>i</mi><mo>-</mo><mn>1</mn></mrow></msub></mrow></mrow></mrow></mrow></mrow></math></maths>

which for large values of j can be approximated using the infinite sum of a geometric series in terms of the uncorrelated signal e rather than x:

<maths id="MATH-US-00057" num="00057"><math overflow="scroll"><mrow><mrow><msub><mi>y</mi><mi>k</mi></msub><mo>=</mo><mrow><mrow><mrow><munderover><mo>∑</mo><mrow><mi>j</mi><mo>=</mo><mn>1</mn></mrow><mi>k</mi></munderover><mo></mo><msub><mi>x</mi><mi>j</mi></msub></mrow><mo>≈</mo><mrow><munderover><mo>∑</mo><mrow><mi>j</mi><mo>=</mo><mn>1</mn></mrow><mi>k</mi></munderover><mo></mo><mrow><mfrac><mn>1</mn><mrow><mn>1</mn><mo>-</mo><mi>α</mi></mrow></mfrac><mo></mo><msub><mi>e</mi><mi>j</mi></msub></mrow></mrow></mrow><mo>=</mo><mrow><munderover><mo>∑</mo><mrow><mi>j</mi><mo>=</mo><mn>1</mn></mrow><mi>k</mi></munderover><mo></mo><mrow><msubsup><mi>x</mi><mi>j</mi><mi>′</mi></msubsup><mo></mo><mstyle><mspace width="0.8em" height="0.8ex" /></mstyle><mo></mo><mi>k</mi></mrow></mrow></mrow></mrow><mo>&gt;&gt;</mo><mn>1</mn></mrow></math></maths>

Thus, the autocorrelated driving signal x_kof the random walk can be converted into an uncorrelated driving signal x_k′ with mean and power given by:

<maths id="MATH-US-00058" num="00058"><math overflow="scroll"><mrow><mrow><mrow><mi>E</mi><mo></mo><mrow><mo>{</mo><msubsup><mi>x</mi><mi>k</mi><mi>′</mi></msubsup><mo>}</mo></mrow></mrow><mo>=</mo><mi>μ</mi></mrow><mo>,</mo><mstyle><mspace width="0.6em" height="0.6ex" /></mstyle><mo></mo><mrow><mrow><mi>E</mi><mo></mo><mrow><mo>{</mo><msup><mrow><mo>(</mo><mrow><msubsup><mi>x</mi><mi>k</mi><mi>′</mi></msubsup><mo>-</mo><mi>μ</mi></mrow><mo>)</mo></mrow><mn>2</mn></msup><mo>}</mo></mrow></mrow><mo>=</mo><mrow><mfrac><mrow><mn>1</mn><mo>+</mo><mi>α</mi></mrow><mrow><mn>1</mn><mo>-</mo><mi>α</mi></mrow></mfrac><mo></mo><msup><mi>σ</mi><mn>2</mn></msup></mrow></mrow><mo>,</mo><mstyle><mtext></mtext></mstyle><mo></mo><mrow><mrow><mi>E</mi><mo></mo><mrow><mo>{</mo><msubsup><mi>x</mi><mi>k</mi><mrow><mi>′</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mn>2</mn></mrow></msubsup><mo>}</mo></mrow></mrow><mo>=</mo><mrow><mrow><mfrac><mrow><mn>1</mn><mo>+</mo><mi>α</mi></mrow><mrow><mn>1</mn><mo>-</mo><mi>α</mi></mrow></mfrac><mo></mo><msup><mi>α</mi><mn>2</mn></msup></mrow><mo>+</mo><msup><mi>μ</mi><mn>2</mn></msup></mrow></mrow><mo>,</mo><mstyle><mspace width="0.6em" height="0.6ex" /></mstyle><mo></mo><mrow><msubsup><mi>σ</mi><msup><mi>x</mi><mi>′</mi></msup><mn>2</mn></msubsup><mo>=</mo><mrow><mfrac><mrow><mn>1</mn><mo>+</mo><mi>α</mi></mrow><mrow><mn>1</mn><mo>-</mo><mi>α</mi></mrow></mfrac><mo></mo><msup><mi>σ</mi><mn>2</mn></msup></mrow></mrow></mrow></math></maths>

where x_k′ represents the regulation signal Reg_signal. Advantageously, this allows optimization constraints module <b>2314</b> to define the probability of ruin in terms of the regulation signal Reg_signal.

In some embodiments, optimization constraints module <b>2314</b> determines a probability p that the random walk driven by the sequence of −1 and 1 will take the value of 1. In order to ensure that the random walk driven by the sequence of −1 and 1 will behave the same as the random walk driven by x_k′, optimization constraints module <b>2314</b> may select p such that the ratio of the mean to the standard deviation is the same for both driving functions, as shown in the following equations:

<maths id="MATH-US-00059" num="00059"><math overflow="scroll"><mrow><mfrac><mi>mean</mi><mi>stdev</mi></mfrac><mo>=</mo><mrow><mfrac><mi>μ</mi><msqrt><mrow><mfrac><mrow><mn>1</mn><mo>+</mo><mi>α</mi></mrow><mrow><mn>1</mn><mo>-</mo><mi>α</mi></mrow></mfrac><mo></mo><mi>σ</mi></mrow></msqrt></mfrac><mo>=</mo><mrow><mover><mi>μ</mi><mo>~</mo></mover><mo>=</mo><mfrac><mrow><mrow><mn>2</mn><mo></mo><mi>p</mi></mrow><mo>-</mo><mn>1</mn></mrow><msqrt><mrow><mn>4</mn><mo></mo><mrow><mi>p</mi><mo></mo><mrow><mo>(</mo><mrow><mn>1</mn><mo>-</mo><mi>p</mi></mrow><mo>)</mo></mrow></mrow></mrow></msqrt></mfrac></mrow></mrow></mrow></math></maths><maths id="MATH-US-00059-2" num="00059.2"><math overflow="scroll"><mrow><mi>p</mi><mo>=</mo><mrow><mfrac><mn>1</mn><mn>2</mn></mfrac><mo>±</mo><mrow><mfrac><mn>1</mn><mn>2</mn></mfrac><mo></mo><msqrt><mrow><mn>1</mn><mo>-</mo><mrow><mo>(</mo><mfrac><mn>1</mn><mrow><msup><mover><mi>μ</mi><mo>~</mo></mover><mn>2</mn></msup><mo>+</mo><mn>1</mn></mrow></mfrac><mo>)</mo></mrow></mrow></msqrt></mrow></mrow></mrow></math></maths>

where {tilde over (μ)} is the ratio of the mean to the standard deviation of the driving signal (e.g., Reg_signal) and μ is the change in state-of-charge over the frequency response period divided by the number of time steps within the frequency response period

<maths id="MATH-US-00060" num="00060"><math overflow="scroll"><mrow><mrow><mo>(</mo><mrow><mrow><mi>i</mi><mo>.</mo><mi>e</mi><mo>.</mo></mrow><mo>,</mo><mrow><mi>μ</mi><mo>=</mo><mfrac><mrow><mi>Δ</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>SOC</mi></mrow><mi>n</mi></mfrac></mrow></mrow><mo>)</mo></mrow><mo>.</mo></mrow></math></maths>

For embodiments in which each frequency response period has a duration of one hour (i.e., 3600 seconds) and the interval between time steps is two seconds, the number of time steps per frequency response period is 1800 (i.e., n=1800). In the equation for p, the plus is used when {tilde over (μ)} is greater than zero, whereas the minus is used when {tilde over (μ)} is less than zero. Optimization constraints module <b>2314</b> may also ensure that both driving functions have the same number of standard deviations away from zero (or ruin) to ensure that both random walks have the same behavior, as shown in the following equation:

<maths id="MATH-US-00061" num="00061"><math overflow="scroll"><mrow><mi>z</mi><mo>=</mo><mfrac><mrow><mi>S</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>O</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mrow><mi>C</mi><mo>·</mo><msub><mi>C</mi><mi>des</mi></msub></mrow><mo></mo><msqrt><mrow><mn>4</mn><mo></mo><mrow><mi>p</mi><mo></mo><mrow><mo>(</mo><mrow><mn>1</mn><mo>-</mo><mi>p</mi></mrow><mo>)</mo></mrow></mrow></mrow></msqrt></mrow><msqrt><mrow><mfrac><mrow><mn>1</mn><mo>+</mo><mi>α</mi></mrow><mrow><mn>1</mn><mo>-</mo><mi>α</mi></mrow></mfrac><mo></mo><mi>σ</mi></mrow></msqrt></mfrac></mrow></math></maths>

Advantageously, the equations for p and z allow optimization constraints module <b>2314</b> to define the probability of ruin P (i.e., the probability of battery <b>2008</b> fully depleting or reaching a fully charged state) within N time steps (n=1 . . . N) as a function of variables that are known to high level controller <b>2212</b> and/or manipulated by high level controller <b>2212</b>. For example, the equation for p defines p as a function of the mean and standard deviation of the regulation signal Reg_signal, which may be estimated by signal statistics predictor <b>2218</b>. The equation for z defines z as a function of the SOC of battery <b>2008</b> and the parameters of the regulation signal Reg_signal.

Optimization constraints module <b>2314</b> may use one or more of the previous equations to place constraints on ΔSOC·C_desand Reg_awardgiven the current SOC of battery <b>2008</b>. For example, optimization constraints module <b>2314</b> may use the mean and standard deviation of the regulation signal Reg_signalto calculate p. Optimization constraints module <b>2314</b> may then use p in combination with the SOC of battery <b>2008</b> to calculate z. Optimization constraints module <b>2314</b> may use p and z as inputs to the equation for the probability of ruin P. This allows optimization constraints module <b>2314</b> to define the probability or ruin P as a function of the SOC of battery <b>2008</b> and the estimated statistics of the regulation signal Reg_signal. Optimization constraints module <b>2314</b> may impose constraints on the SOC of battery <b>2008</b> to ensure that the probability of ruin P within N time steps does not exceed a threshold value. These constraints may be expressed as limitations on the variables ΔSOC·C_desand/or Reg_award, which are related to midpoint b as previously described.

In some embodiments, optimization constraints module <b>2314</b> uses the equation for the probability of ruin P to define boundaries on the combination of variables p and z. The boundaries represent thresholds when the probability of ruin P in less than N steps is greater than a critical value P_cr(e.g., P_cr=0.001). For example, optimization constraints module <b>2314</b> may generate boundaries that correspond to a threshold probability of battery <b>2008</b> fully depleting or reaching a fully charged state during a frequency response period (e.g., in N=1800 steps).

In some embodiments, optimization constraints module <b>2314</b> constrains the probability of ruin P to less than the threshold value, which imposes limits on potential combinations of the variables p and z. Since the variables p and z are related to the SOC of battery <b>2008</b> and the statistics of the regulation signal, the constraints may impose limitations on ΔSOC·C_desand Reg_awardgiven the current SOC of battery <b>2008</b>. These constraints may also impose limitations on midpoint b since the variables ΔSOC·C_desand Reg_awardare related to midpoint b. For example, optimization constraints module <b>2314</b> may set constraints on the maximum bid Reg_awardgiven a desired change in the SOC for battery <b>2008</b>. In other embodiments, optimization constraints module <b>2314</b> penalizes the objective function J given the bid Reg_awardand the change in SOC.

Still referring to <figref idref="DRAWINGS">FIG. 23</figref>, variable SOC controller <b>2308</b> is shown to include a frequency response (FR) revenue estimator <b>2316</b>. FR revenue estimator <b>2316</b> may be configured to estimate the frequency response revenue that will result from a given midpoint b (e.g., a midpoint provided by midpoint optimizer <b>2312</b>). The estimated frequency response revenue may be used as the term Rev(Reg_award,k) in the objective function J. Midpoint optimizer <b>2312</b> may use the estimated frequency response revenue along with other terms in the objective function J to determine an optimal midpoint b.

In some embodiments, FR revenue estimator <b>2316</b> uses a revenue model to predict frequency response revenue. An exemplary revenue model which may be used by FR revenue estimator <b>2316</b> is shown in the following equation:

&lt;br /&gt;<i>Rev</i>(<i>Reg</i>_award)=<i>R</i>_award(<i>CP</i>_cap<i>+MR·CP</i>_perf)

where CP_cap, MR, and CP_perfare the energy market statistics received from energy market predictor <b>2216</b> and Reg_awardis a function of the midpoint b. For example, capability bid calculator <b>2322</b> may calculate Reg_awardusing the following equation:

&lt;br /&gt;<i>Reg</i>_award<i>=P</i>_limit<i>−|b|</i>

where P_limitis the power rating of power inverter <b>2006</b>.

As shown above, the equation for frequency response revenue used by FR revenue estimator <b>2316</b> does not include a performance score (or assumes a performance score of 1.0). This results in FR revenue estimator <b>2316</b> estimating a maximum possible frequency response revenue that can be achieved for a given midpoint b (i.e., if the actual frequency response of controller <b>2012</b> were to follow the regulation signal exactly). However, it is contemplated that the actual frequency response may be adjusted by low level controller <b>2214</b> in order to preserve the life of battery <b>2008</b>. When the actual frequency response differs from the regulation signal, the equation for frequency response revenue can be adjusted to include a performance score. The resulting value function J may then be optimized by low level controller <b>2214</b> to determine an optimal frequency response output which considers both frequency response revenue and the costs of battery degradation, as described with reference to <figref idref="DRAWINGS">FIG. 24</figref>.

Still referring to <figref idref="DRAWINGS">FIG. 23</figref>, variable SOC controller <b>2308</b> is shown to include a battery degradation estimator <b>2318</b>. Battery degradation estimator <b>2318</b> may estimate the cost of battery degradation that will result from a given midpoint b (e.g., a midpoint provided by midpoint optimizer <b>2312</b>). The estimated battery degradation may be used as the term λ_batin the objective function J. Midpoint optimizer <b>2312</b> may use the estimated battery degradation along with other terms in the objective function J to determine an optimal midpoint b.

In some embodiments, battery degradation estimator <b>2318</b> uses a battery life model to predict a loss in battery capacity that will result from a set of midpoints b, power outputs, and/or other variables that can be manipulated by controller <b>2012</b>. The battery life model may define the loss in battery capacity C_loss,addas a sum of multiple piecewise linear functions, as shown in the following equation:

&lt;br /&gt;<i>C</i>_loss,add<i>=f</i>₁(<i>T</i>_cell)+<i>f</i>₂(SOC)+<i>f</i>₃(DOD)+<i>f</i>₄(PR)+<i>f</i>₅(ER)−<i>C</i>_loss,nom

where T_cellis the cell temperature, SOC is the state-of-charge, DOD is the depth of discharge, PR is the average power ratio

<maths id="MATH-US-00062" num="00062"><math overflow="scroll"><mrow><mrow><mo>(</mo><mrow><mrow><mi>e</mi><mo>.</mo><mi>g</mi><mo>.</mo></mrow><mo>,</mo><mrow><mrow><mi>P</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>R</mi></mrow><mo>=</mo><mrow><mi>avg</mi><mo></mo><mrow><mo>(</mo><mfrac><msub><mi>P</mi><mi>avg</mi></msub><msub><mi>P</mi><mi>des</mi></msub></mfrac><mo>)</mo></mrow></mrow></mrow></mrow><mo>)</mo></mrow><mo>,</mo></mrow></math></maths>

and ER is the average effort ratio

<maths id="MATH-US-00063" num="00063"><math overflow="scroll"><mrow><mo>(</mo><mrow><mrow><mi>e</mi><mo>.</mo><mi>g</mi><mo>.</mo></mrow><mo>,</mo><mrow><mrow><mi>E</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>R</mi></mrow><mo>=</mo><mrow><mi>avg</mi><mo></mo><mrow><mo>(</mo><mfrac><mrow><mi>Δ</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><msub><mi>P</mi><mi>bat</mi></msub></mrow><msub><mi>P</mi><mi>des</mi></msub></mfrac><mo>)</mo></mrow></mrow></mrow></mrow></mrow></math></maths>

of battery <b>2008</b>. C_loss,nomis the nominal loss in battery capacity that is expected to occur over time. Therefore, C_loss,addrepresents the additional loss in battery capacity degradation in excess of the nominal value C_loss,nom.

Battery degradation estimator <b>2318</b> may define the terms in the battery life model as functions of one or more variables that have known values (e.g., estimated or measured values) and/or variables that can be manipulated by high level controller <b>2212</b>. For example, battery degradation estimator <b>2318</b> may define the terms in the battery life model as functions of the regulation signal statistics (e.g., the mean and standard deviation of Reg_signal), the campus power signal statistics (e.g., the mean and standard deviation of P_campus), Reg_award, midpoint b, the SOC of battery <b>2008</b>, and/or other variables that have known or controlled values.

In some embodiments, battery degradation estimator <b>2318</b> measures the cell temperature T_cellusing a temperature sensor configured to measure the temperature of battery <b>2008</b>. In other embodiments, battery degradation estimator <b>2318</b> estimates or predicts the cell temperature T_cellbased on a history of measured temperature values. For example, battery degradation estimator <b>2318</b> may use a predictive model to estimate the cell temperature T_cellas a function of the battery power P_bat, the ambient temperature, and/or other variables that can be measured, estimated, or controlled by high level controller <b>2212</b>.

Battery degradation estimator <b>2318</b> may define the variable SOC in the battery life model as the SOC of battery <b>2008</b> at the end of the frequency response period. The SOC of battery <b>2008</b> may be measured or estimated based on the control decisions made by controller <b>2012</b>. For example, battery degradation estimator <b>2318</b> may use a predictive model to estimate or predict the SOC of battery <b>2008</b> at the end of the frequency response period as a function of the battery power P_bat, the midpoint b, and/or other variables that can be measured, estimated, or controlled by high level controller <b>2212</b>.

Battery degradation estimator <b>2318</b> may define the average power ratio PR as the ratio of the average power output of battery <b>2008</b> (i.e., P_avg) to the design power P_des

<maths id="MATH-US-00064" num="00064"><math overflow="scroll"><mrow><mrow><mo>(</mo><mrow><mrow><mi>e</mi><mo>.</mo><mi>g</mi><mo>.</mo></mrow><mo>,</mo><mrow><mrow><mi>P</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>R</mi></mrow><mo>=</mo><mrow><mi>avg</mi><mo></mo><mrow><mo>(</mo><mfrac><msub><mi>P</mi><mi>avg</mi></msub><msub><mi>P</mi><mi>des</mi></msub></mfrac><mo>)</mo></mrow></mrow></mrow></mrow><mo>)</mo></mrow><mo>,</mo></mrow></math></maths>

The average power output of battery <b>2008</b> can be defined using the following equation:

&lt;br /&gt;<i>P</i>_avg<i>=E{|Reg</i>_award<i>Reg</i>_signal<i>+b−P</i>_loss<i>−P</i>_campus|}

where the expression (Reg_awardReg_signal+b−P_loss−P_campus) represents the battery power P_bat. The expected value of P_avgis given by:

<maths id="MATH-US-00065" num="00065"><math overflow="scroll"><mrow><msub><mi>P</mi><mi>avg</mi></msub><mo>=</mo><mrow><mrow><msub><mi>σ</mi><mi>bat</mi></msub><mo></mo><msqrt><mfrac><mn>2</mn><mi>π</mi></mfrac></msqrt><mo></mo><mrow><mi>exp</mi><mo></mo><mrow><mo>(</mo><mfrac><mrow><mo>-</mo><msubsup><mi>μ</mi><mi>bat</mi><mn>2</mn></msubsup></mrow><mrow><mn>2</mn><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><msubsup><mi>σ</mi><mi>bat</mi><mn>2</mn></msubsup></mrow></mfrac><mo>)</mo></mrow></mrow></mrow><mo>+</mo><mrow><mi>erf</mi><mo>(</mo><mfrac><mrow><mo>-</mo><msub><mi>μ</mi><mi>bat</mi></msub></mrow><msqrt><mrow><mn>2</mn><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><msubsup><mi>σ</mi><mi>bat</mi><mn>2</mn></msubsup></mrow></msqrt></mfrac><mo>)</mo></mrow></mrow></mrow></math></maths>

where μ_batand σ_bat²are the mean and variance of the battery power P_bat. The variables μ_batand σ_bat²may be defined as follows:

&lt;br /&gt;μ_bat<i>=Reg</i>_award<i>E{Reg</i>_signal<i>}+b−E{P</i>_loss<i>}−E{P</i>_campus}

&lt;br /&gt;σ_bat²<i>=Reg</i>_award²σ_FR²σ_campus²

where σ_FR²is the variance of Reg_signaland the contribution of the battery power loss to the variance σ_bat²is neglected.

Battery degradation estimator <b>2318</b> may define the average effort ratio ER as the ratio of the average change in battery power ΔP_avgto the design power P_des

<maths id="MATH-US-00066" num="00066"><math overflow="scroll"><mrow><mrow><mo>(</mo><mrow><mrow><mi>i</mi><mo>.</mo><mi>e</mi><mo>.</mo></mrow><mo>,</mo><mrow><mi>ER</mi><mo>=</mo><mfrac><mrow><mi>Δ</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><msub><mi>P</mi><mi>avg</mi></msub></mrow><msub><mi>P</mi><mi>des</mi></msub></mfrac></mrow></mrow><mo>)</mo></mrow><mo>.</mo></mrow></math></maths>

The average change in battery power can be defined using the following equation:

&lt;br /&gt;Δ<i>P</i>_avg<i>=E{P</i>_bat,k<i>−P</i>_bat,k−1}

&lt;br /&gt;Δ<i>P</i>_avg<i>=E{|Reg</i>_award(<i>Reg</i>_signal,k<i>−Reg</i>_signal,k−1)−(<i>P</i>_loss,k<i>−P</i>_loss,k−1)−(<i>P</i>_campus,k<i>−P</i>_campus,k−1)|}

To make this calculation more tractable, the contribution due to the battery power loss can be neglected. Additionally, the campus power P_campusand the regulation signal Reg_signalcan be assumed to be uncorrelated, but autocorrelated with first order autocorrelation parameters of α_campusand α, respectively. The argument inside the absolute value in the equation for ΔP_avghas a mean of zero and a variance given by:

<maths id="MATH-US-00067" num="00067"><math overflow="scroll"><mtable><mtr><mtd><mrow><msubsup><mi>σ</mi><mi>diff</mi><mn>2</mn></msubsup><mo>=</mo>&lt;mi /&gt;<mo></mo><mrow><mi>E</mi><mo></mo><mrow><mo>{</mo><msup><mrow><mo>[</mo><mrow><mrow><msub><mi>Reg</mi><mi>award</mi></msub><mo></mo><mrow><mo>(</mo><mrow><msub><mi>Reg</mi><mrow><mi>signal</mi><mo>,</mo><mi>k</mi></mrow></msub><mo>-</mo><msub><mi>Reg</mi><mrow><mi>signal</mi><mo>,</mo><mrow><mi>k</mi><mo>-</mo><mn>1</mn></mrow></mrow></msub></mrow><mo>)</mo></mrow></mrow><mo>-</mo><mrow><mo>(</mo><mrow><msub><mi>P</mi><mrow><mi>campus</mi><mo>,</mo><mi>k</mi></mrow></msub><mo>-</mo><msub><mi>P</mi><mrow><mi>campus</mi><mo>,</mo><mrow><mi>k</mi><mo>-</mo><mn>1</mn></mrow></mrow></msub></mrow><mo>)</mo></mrow></mrow><mo>]</mo></mrow><mn>2</mn></msup><mo>}</mo></mrow></mrow></mrow></mtd></mtr><mtr><mtd><mrow><mo>=</mo>&lt;mi /&gt;<mo></mo><mrow><mi>E</mi><mo></mo><mrow><mo>{</mo><mrow><msup><mrow><msubsup><mi>Reg</mi><mi>award</mi><mn>2</mn></msubsup><mo></mo><mrow><mo>(</mo><mrow><msub><mi>Reg</mi><mrow><mi>signal</mi><mo>,</mo><mi>k</mi></mrow></msub><mo>-</mo><msub><mi>Reg</mi><mrow><mi>signal</mi><mo>,</mo><mrow><mi>k</mi><mo>-</mo><mn>1</mn></mrow></mrow></msub></mrow><mo>)</mo></mrow></mrow><mn>2</mn></msup><mo>-</mo><msup><mrow><mo>(</mo><mrow><msub><mi>P</mi><mrow><mi>campus</mi><mo>,</mo><mi>k</mi></mrow></msub><mo>-</mo><msub><mi>P</mi><mrow><mi>campus</mi><mo>,</mo><mrow><mi>k</mi><mo>-</mo><mn>1</mn></mrow></mrow></msub></mrow><mo>)</mo></mrow><mn>2</mn></msup></mrow><mo>}</mo></mrow></mrow></mrow></mtd></mtr><mtr><mtd><mrow><mo>=</mo>&lt;mi /&gt;<mo></mo><mrow><mrow><mn>2</mn><mo></mo><mrow><msubsup><mi>Reg</mi><mi>award</mi><mn>2</mn></msubsup><mo></mo><mrow><mo>(</mo><mrow><mn>1</mn><mo>-</mo><mi>α</mi></mrow><mo>)</mo></mrow></mrow><mo></mo><msubsup><mi>σ</mi><mi>FR</mi><mn>2</mn></msubsup></mrow><mo>+</mo><mrow><mn>2</mn><mo></mo><mrow><mo>(</mo><mrow><mn>1</mn><mo>-</mo><msub><mi>α</mi><mi>campus</mi></msub></mrow><mo>)</mo></mrow><mo></mo><msubsup><mi>σ</mi><mi>campus</mi><mn>2</mn></msubsup></mrow></mrow></mrow></mtd></mtr></mtable></math></maths>

Battery degradation estimator <b>2318</b> may define the depth of discharge DOD as the maximum state-of-charge minus the minimum state-of-charge of battery <b>2008</b> over the frequency response period, as shown in the following equation:

&lt;br /&gt;DOD=SOC_max−SOC_min

The SOC of battery <b>2008</b> can be viewed as a constant slope with a zero mean random walk added to it, as previously described. An uncorrelated normal random walk with a driving signal that has zero mean has an expected range given by:

<maths id="MATH-US-00068" num="00068"><math overflow="scroll"><mrow><mrow><mi>E</mi><mo></mo><mrow><mo>{</mo><mrow><mi>max</mi><mo>-</mo><mi>min</mi></mrow><mo>}</mo></mrow></mrow><mo>=</mo><mrow><mn>2</mn><mo></mo><mi>σ</mi><mo></mo><msqrt><mfrac><mrow><mn>2</mn><mo></mo><mi>N</mi></mrow><mi>π</mi></mfrac></msqrt></mrow></mrow></math></maths>

where E{max−min} represent the depth of discharge DOD and can be adjusted for the autocorrelation of the driving signal as follows:

<maths id="MATH-US-00069" num="00069"><math overflow="scroll"><mrow><mrow><mi>E</mi><mo></mo><mrow><mo>{</mo><mrow><mi>max</mi><mo>-</mo><mi>min</mi></mrow><mo>}</mo></mrow></mrow><mo>=</mo><mrow><mn>2</mn><mo></mo><mi>σ</mi><mo></mo><msqrt><mfrac><mrow><mn>1</mn><mo>+</mo><msub><mi>α</mi><mi>bat</mi></msub></mrow><mrow><mn>1</mn><mo>-</mo><msub><mi>α</mi><mi>bat</mi></msub></mrow></mfrac></msqrt><mo></mo><msqrt><mfrac><mrow><mn>2</mn><mo></mo><mi>N</mi></mrow><mi>π</mi></mfrac></msqrt></mrow></mrow></math></maths><maths id="MATH-US-00069-2" num="00069.2"><math overflow="scroll"><mrow><msubsup><mi>σ</mi><mi>bat</mi><mn>2</mn></msubsup><mo>=</mo><mrow><mrow><msubsup><mi>Reg</mi><mi>award</mi><mn>2</mn></msubsup><mo></mo><msubsup><mi>σ</mi><mi>FR</mi><mn>2</mn></msubsup></mrow><mo>+</mo><msubsup><mi>σ</mi><mi>campus</mi><mn>2</mn></msubsup></mrow></mrow></math></maths><maths id="MATH-US-00069-3" num="00069.3"><math overflow="scroll"><mrow><msub><mi>α</mi><mi>bat</mi></msub><mo>=</mo><mfrac><mrow><mrow><msubsup><mi>Reg</mi><mi>award</mi><mn>2</mn></msubsup><mo></mo><mi>α</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><msubsup><mi>σ</mi><mi>FR</mi><mn>2</mn></msubsup></mrow><mo>+</mo><mrow><msub><mi>α</mi><mi>campus</mi></msub><mo></mo><msubsup><mi>σ</mi><mi>campus</mi><mn>2</mn></msubsup></mrow></mrow><mrow><mrow><msubsup><mi>Reg</mi><mi>award</mi><mn>2</mn></msubsup><mo></mo><msubsup><mi>σ</mi><mi>FR</mi><mn>2</mn></msubsup></mrow><mo>+</mo><msubsup><mi>σ</mi><mi>campus</mi><mn>2</mn></msubsup></mrow></mfrac></mrow></math></maths>

If the SOC of battery <b>2008</b> is expected to change (i.e., is not zero mean), the following equation may be used to define the depth of discharge:

<maths id="MATH-US-00070" num="00070"><math overflow="scroll"><mrow><mrow><mi>E</mi><mo></mo><mrow><mo>{</mo><mrow><mi>max</mi><mo>-</mo><mi>min</mi></mrow><mo>}</mo></mrow></mrow><mo>=</mo><mrow><mo>{</mo><mtable><mtr><mtd><mrow><msub><mi>R</mi><mn>0</mn></msub><mo>+</mo><mrow><mrow><mi>c</mi><mo>·</mo><mi>Δ</mi></mrow><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mrow><mi>SOC</mi><mo>·</mo><mi>exp</mi></mrow><mo></mo><mrow><mo>{</mo><mrow><mrow><mo>-</mo><mi>α</mi></mrow><mo></mo><mfrac><mrow><msub><mi>R</mi><mn>0</mn></msub><mo>-</mo><mrow><mi>Δ</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>SOC</mi></mrow></mrow><msub><mi>σ</mi><mi>bat</mi></msub></mfrac></mrow><mo>}</mo></mrow></mrow></mrow></mtd><mtd><mrow><mrow><mi>Δ</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>SOC</mi></mrow><mo>&lt;</mo><msub><mi>R</mi><mn>0</mn></msub></mrow></mtd></mtr><mtr><mtd><mrow><mrow><mi>Δ</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>SOC</mi></mrow><mo>+</mo><mrow><mrow><mi>c</mi><mo>·</mo><msub><mi>R</mi><mn>0</mn></msub><mo>·</mo><mi>exp</mi></mrow><mo></mo><mrow><mo>{</mo><mrow><mrow><mo>-</mo><mi>α</mi></mrow><mo></mo><mfrac><mrow><mrow><mi>Δ</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>SOC</mi></mrow><mo>-</mo><msub><mi>R</mi><mn>0</mn></msub></mrow><msub><mi>σ</mi><mi>bat</mi></msub></mfrac></mrow><mo>}</mo></mrow></mrow></mrow></mtd><mtd><mrow><mrow><mi>Δ</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>SOC</mi></mrow><mo>&gt;</mo><msub><mi>R</mi><mn>0</mn></msub></mrow></mtd></mtr></mtable></mrow></mrow></math></maths>

where R₀is the expected range with zero expected change in the state-of-charge. Battery degradation estimator <b>2318</b> may use the previous equations to establish a relationship between the capacity loss C_loss,addand the control outputs provided by controller <b>2012</b>.

Still referring to <figref idref="DRAWINGS">FIG. 23</figref>, variable SOC controller <b>2308</b> is shown to include a revenue loss estimator <b>2320</b>. Revenue loss estimator <b>2320</b> may be configured to estimate an amount of potential revenue that will be lost as a result of the battery capacity loss C_loss,add. In some embodiments, revenue loss estimator <b>2320</b> converts battery capacity loss C_loss,addinto lost revenue using the following equation:

&lt;br /&gt;<i>R</i>_loss=(<i>CP</i>_cap<i>+MR·CP</i>_perf)<i>C</i>_loss,add<i>P</i>_des

where R_lossis the lost revenue over the duration of the frequency response period.

Revenue loss estimator <b>2320</b> may determine a present value of the revenue loss R_lossusing the following equation:

<maths id="MATH-US-00071" num="00071"><math overflow="scroll"><mrow><msub><mi>λ</mi><mi>bat</mi></msub><mo>=</mo><mrow><mrow><mo>[</mo><mfrac><mrow><mn>1</mn><mo>-</mo><msup><mrow><mo>(</mo><mrow><mn>1</mn><mo>+</mo><mfrac><mi>i</mi><mi>n</mi></mfrac></mrow><mo>)</mo></mrow><mrow><mo>-</mo><mi>n</mi></mrow></msup></mrow><mfrac><mi>i</mi><mi>n</mi></mfrac></mfrac><mo>]</mo></mrow><mo></mo><msub><mi>R</mi><mi>loss</mi></msub></mrow></mrow></math></maths>

where n is the total number of frequency response periods (e.g., hours) during which the revenue loss occurs and λ_batis the present value of the revenue loss during the ith frequency response period. In some embodiments, the revenue loss occurs over ten years (e.g., n=87,600 hours). Revenue loss estimator <b>2320</b> may provide the present value of the revenue loss λ_batto midpoint optimizer <b>2312</b> for use in the objective function J.

Midpoint optimizer <b>2312</b> may use the inputs from optimization constraints module <b>2314</b>, FR revenue estimator <b>2316</b>, battery degradation estimator <b>2318</b>, and revenue loss estimator <b>2320</b> to define the terms in objective function J. Midpoint optimizer <b>2312</b> may determine values for midpoint b that optimize objective function J. In various embodiments, midpoint optimizer <b>2312</b> may use sequential quadratic programming, dynamic programming, or any other optimization technique.

Still referring to <figref idref="DRAWINGS">FIG. 23</figref>, high level controller <b>2212</b> is shown to include a capability bid calculator <b>2322</b>. Capability bid calculator <b>2322</b> may be configured to generate a capability bid Reg_awardbased on the midpoint b generated by constant SOC controller <b>2302</b> and/or variable SOC controller <b>2308</b>. In some embodiments, capability bid calculator <b>2322</b> generates a capability bid that is as large as possible for a given midpoint, as shown in the following equation:

&lt;br /&gt;<i>Reg</i>_award<i>=P</i>_limit<i>−|b|</i>

where P_limitis the power rating of power inverter <b>2006</b>. Capability bid calculator <b>2322</b> may provide the capability bid to incentive provider <b>2014</b> and to frequency response optimizer <b>2324</b> for use in generating an optimal frequency response.

Filter Parameters Optimization

Still referring to <figref idref="DRAWINGS">FIG. 23</figref>, high level controller <b>2212</b> is shown to include a frequency response optimizer <b>2324</b> and a filter parameters optimizer <b>2326</b>. Filter parameters optimizer <b>2326</b> may be configured to generate a set of filter parameters for low level controller <b>2214</b>. The filter parameters may be used by low level controller <b>2214</b> as part of a low-pass filter that removes high frequency components from the regulation signal Reg_signal. In some embodiments, filter parameters optimizer <b>2326</b> generates a set of filter parameters that transform the regulation signal Reg_signalinto an optimal frequency response signal Res_FR. Frequency response optimizer <b>2324</b> may perform a second optimization process to determine the optimal frequency response Res_FRbased on the values for Reg_awardand midpoint b. In the second optimization, the values for Reg_awardand midpoint b may be fixed at the values previously determined during the first optimization.

In some embodiments, frequency response optimizer <b>2324</b> determines the optimal frequency response Res_FRby optimizing value function J shown in the following equation:

<maths id="MATH-US-00072" num="00072"><math overflow="scroll"><mrow><mi>J</mi><mo>=</mo><mrow><mrow><munderover><mo>∑</mo><mrow><mi>k</mi><mo>=</mo><mn>1</mn></mrow><mi>h</mi></munderover><mo></mo><mrow><mi>Rev</mi><mo></mo><mrow><mo>(</mo><msub><mi>Reg</mi><mrow><mi>award</mi><mo>,</mo><mi>k</mi></mrow></msub><mo>)</mo></mrow></mrow></mrow><mo>+</mo><mrow><munderover><mo>∑</mo><mrow><mi>k</mi><mo>=</mo><mn>1</mn></mrow><mi>h</mi></munderover><mo></mo><mrow><msub><mi>c</mi><mi>k</mi></msub><mo></mo><msub><mi>b</mi><mi>k</mi></msub></mrow></mrow><mo>+</mo><mrow><munder><mi>min</mi><mi>period</mi></munder><mo></mo><mrow><mo>(</mo><mrow><msub><mi>P</mi><mrow><mi>campus</mi><mo>,</mo><mi>k</mi></mrow></msub><mo>+</mo><msub><mi>b</mi><mi>k</mi></msub></mrow><mo>)</mo></mrow></mrow><mo>-</mo><mrow><munderover><mo>∑</mo><mrow><mi>k</mi><mo>=</mo><mn>1</mn></mrow><mi>h</mi></munderover><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><msub><mi>λ</mi><mrow><mi>bat</mi><mo>,</mo><mi>k</mi></mrow></msub></mrow></mrow></mrow></math></maths>

where the frequency response revenue Rev(Reg_award) is defined as follows:

&lt;br /&gt;<i>Rev</i>(<i>Reg</i>_award)=<i>PS·Reg</i>_award(<i>CP</i>_cap<i>+MR·CP</i>_perf)

and the frequency response Res_FRis substituted for the regulation signal Reg_signalin the battery life model used to calculate λ_bat,k. The performance score PS may be based on several factors that indicate how well the optimal frequency response Res_FRtracks the regulation signal Reg_signal.

The frequency response Res_FRmay affect both Rev(Reg_award) and the monetized cost of battery degradation λ_bat. Closely tracking the regulation signal may result in higher performance scores, thereby increasing the frequency response revenue. However, closely tracking the regulation signal may also increase the cost of battery degradation λ_bat. The optimized frequency response Res_FRrepresents an optimal tradeoff between decreased frequency response revenue and increased battery life (i.e., the frequency response that maximizes value J).

In some embodiments, the performance score PS is a composite weighting of an accuracy score, a delay score, and a precision score. Frequency response optimizer <b>2324</b> may calculate the performance score PS using the performance score model shown in the following equation:

&lt;br /&gt;<i>PS=</i>⅓<i>PS</i>_acc+⅓<i>PS</i>_delay+⅓<i>PS</i>_prec

where PS_accis the accuracy score, PS_delayis the delay score, and PS_precis the precision score. In some embodiments, each term in the precision score is assigned an equal weighting (e.g., ⅓). In other embodiments, some terms may be weighted higher than others.

The accuracy score PS_accmay be the maximum correlation between the regulation signal Reg_signaland the optimal frequency response Res_FR. Frequency response optimizer <b>2324</b> may calculate the accuracy score PS_accusing the following equation:

<maths id="MATH-US-00073" num="00073"><math overflow="scroll"><mrow><msub><mi>PS</mi><mi>acc</mi></msub><mo>=</mo><mrow><munder><mi>max</mi><mi>δ</mi></munder><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><msub><mi>r</mi><mrow><mi>Reg</mi><mo>,</mo><mrow><mi>Res</mi><mo></mo><mrow><mo>(</mo><mi>δ</mi><mo>)</mo></mrow></mrow></mrow></msub></mrow></mrow></math></maths>

where δ is a time delay between zero and δ_max(e.g., between zero and five minutes).

The delay score PS_delaymay be based on the time delay δ between the regulation signal Reg_signaland the optimal frequency response Res_FR. Frequency response optimizer <b>2324</b> may calculate the delay score PS_delayusing the following equation:

<maths id="MATH-US-00074" num="00074"><math overflow="scroll"><mrow><msub><mi>PS</mi><mi>delay</mi></msub><mo>=</mo><mrow><mo></mo><mfrac><mrow><mrow><mi>δ</mi><mo></mo><mrow><mo>[</mo><mi>s</mi><mo>]</mo></mrow></mrow><mo>-</mo><msub><mi>δ</mi><mi>max</mi></msub></mrow><msub><mi>δ</mi><mi>max</mi></msub></mfrac><mo></mo></mrow></mrow></math></maths>

where δ[s] is the time delay of the frequency response Res_FRrelative to the regulation signal Reg_signaland δ_maxis the maximum allowable delay (e.g., 5 minutes or 300 seconds).

The precision score PS_precmay be based on a difference between the frequency response Res_FRand the regulation signal Reg_signal. Frequency response optimizer <b>2324</b> may calculate the precision score PS_precusing the following equation:

<maths id="MATH-US-00075" num="00075"><math overflow="scroll"><mrow><msub><mi>PS</mi><mi>prec</mi></msub><mo>=</mo><mrow><mn>1</mn><mo>-</mo><mfrac><mrow><mo>∑</mo><mrow><mo></mo><mrow><msub><mi>Res</mi><mi>FR</mi></msub><mo>-</mo><msub><mi>Reg</mi><mi>signal</mi></msub></mrow><mo></mo></mrow></mrow><mrow><mo>∑</mo><mrow><mo></mo><msub><mi>Reg</mi><mi>signal</mi></msub><mo></mo></mrow></mrow></mfrac></mrow></mrow></math></maths>

Frequency response optimizer <b>2324</b> may use the estimated performance score and the estimated battery degradation to define the terms in objective function J. Frequency response optimizer <b>2324</b> may determine values for frequency response Res_FRthat optimize objective function J. In various embodiments, frequency response optimizer <b>2324</b> may use sequential quadratic programming, dynamic programming, or any other optimization technique.

Filter parameters optimizer <b>2326</b> may use the optimized frequency response Res_FRto generate a set of filter parameters for low level controller <b>2214</b>. In some embodiments, the filter parameters are used by low level controller <b>2214</b> to translate an incoming regulation signal into a frequency response signal. Low level controller <b>2214</b> is described in greater detail with reference to <figref idref="DRAWINGS">FIG. 24</figref>.

Still referring to <figref idref="DRAWINGS">FIG. 23</figref>, high level controller <b>2212</b> is shown to include a data fusion module <b>2328</b>. Data fusion module <b>2328</b> is configured to aggregate data received from external systems and devices for processing by high level controller <b>2212</b>. For example, data fusion module <b>2328</b> may store and aggregate external data such as the campus power signal, utility rates, incentive event history and/or weather forecasts as shown in <figref idref="DRAWINGS">FIG. 26</figref>. Further, data fusion module <b>2328</b> may store and aggregate data from low level controller <b>2214</b>. For example, data fusion module <b>2328</b> may receive data such as battery SOC, battery temperature, battery system temperature data, security device status data, battery voltage data, battery current data and/or any other data provided by battery system <b>2504</b>. Data fusion module <b>2328</b> is described in greater detail with reference to <figref idref="DRAWINGS">FIG. 26</figref>.

Low Level Controller

Referring now to <figref idref="DRAWINGS">FIG. 24</figref>, a block diagram illustrating low level controller <b>2214</b> in greater detail is shown, according to an exemplary embodiment. Low level controller <b>2214</b> may receive the midpoints b and the filter parameters from high level controller <b>2212</b>. Low level controller <b>2214</b> may also receive the campus power signal from campus <b>2002</b> and the regulation signal Reg_signaland the regulation award Reg_awardfrom incentive provider <b>2014</b>.

Predicting and Filtering the Regulation Signal

Low level controller <b>2214</b> is shown to include a regulation signal predictor <b>2402</b>. Regulation signal predictor <b>2402</b> may use a history of past and current values for the regulation signal Reg_signalto predict future values of the regulation signal. In some embodiments, regulation signal predictor <b>2402</b> uses a deterministic plus stochastic model trained from historical regulation signal data to predict future values of the regulation signal Reg_signal. For example, regulation signal predictor <b>2402</b> may use linear regression to predict a deterministic portion of the regulation signal Reg_signaland an AR model to predict a stochastic portion of the regulation signal Reg_signal. In some embodiments, regulation signal predictor <b>2402</b> predicts the regulation signal Reg_signalusing the techniques described in U.S. patent application Ser. No. 14/717,593.

Low level controller <b>2214</b> is shown to include a regulation signal filter <b>2404</b>. Regulation signal filter <b>2404</b> may filter the incoming regulation signal Reg_signaland/or the predicted regulation signal using the filter parameters provided by high level controller <b>2212</b>. In some embodiments, regulation signal filter <b>2404</b> is a low pass filter configured to remove high frequency components from the regulation signal Reg_signal. Regulation signal filter <b>2404</b> may provide the filtered regulation signal to power setpoint optimizer <b>2406</b>.

Determining Optimal Power Setpoints

Power setpoint optimizer <b>2406</b> may be configured to determine optimal power setpoints for power inverter <b>2006</b> based on the filtered regulation signal. In some embodiments, power setpoint optimizer <b>2406</b> uses the filtered regulation signal as the optimal frequency response. For example, low level controller <b>2214</b> may use the filtered regulation signal to calculate the desired interconnection power P_POI* using the following equation:

&lt;br /&gt;<i>P</i>_POI<i>*=Reg</i>_award<i>−Reg</i>_filter<i>+b </i>

where Reg_filteris the filtered regulation signal. Power setpoint optimizer <b>2406</b> may subtract the campus power P_campusfrom the desired interconnection power P_POI* to calculate the optimal power setpoints P_SPfor power inverter <b>2006</b>, as shown in the following equation:

&lt;br /&gt;<i>P</i>_SP<i>=P</i>_POI<i>*−P</i>_campus

In other embodiments, low level controller <b>2214</b> performs an optimization to determine how closely to track P_POI*. For example, low level controller <b>2214</b> is shown to include a frequency response optimizer <b>2408</b>. Frequency response optimizer <b>2408</b> may determine an optimal frequency response Res_FRby optimizing value function J shown in the following equation:

<maths id="MATH-US-00076" num="00076"><math overflow="scroll"><mrow><mi>J</mi><mo>=</mo><mrow><mrow><munderover><mo>∑</mo><mrow><mi>k</mi><mo>=</mo><mn>1</mn></mrow><mi>h</mi></munderover><mo></mo><mrow><mi>Rev</mi><mo></mo><mrow><mo>(</mo><msub><mi>Reg</mi><mrow><mi>award</mi><mo>,</mo><mi>k</mi></mrow></msub><mo>)</mo></mrow></mrow></mrow><mo>+</mo><mrow><munderover><mo>∑</mo><mrow><mi>k</mi><mo>=</mo><mn>1</mn></mrow><mi>h</mi></munderover><mo></mo><mrow><msub><mi>c</mi><mi>k</mi></msub><mo></mo><msub><mi>b</mi><mi>k</mi></msub></mrow></mrow><mo>+</mo><mrow><munder><mi>min</mi><mi>period</mi></munder><mo></mo><mrow><mo>(</mo><mrow><msub><mi>P</mi><mrow><mi>campus</mi><mo>,</mo><mi>k</mi></mrow></msub><mo>+</mo><msub><mi>b</mi><mi>k</mi></msub></mrow><mo>)</mo></mrow></mrow><mo>-</mo><mrow><munderover><mo>∑</mo><mrow><mi>k</mi><mo>=</mo><mn>1</mn></mrow><mi>h</mi></munderover><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><msub><mi>λ</mi><mrow><mi>bat</mi><mo>,</mo><mi>k</mi></mrow></msub></mrow></mrow></mrow></math></maths>

where the frequency response Res_FRaffects both Rev(Reg_award) and the monetized cost of battery degradation λ_bat. The frequency response Res_FRmay affect both Rev(Reg_award) and the monetized cost of battery degradation λ_bat. The optimized frequency response Res_FRrepresents an optimal tradeoff between decreased frequency response revenue and increased battery life (i.e., the frequency response that maximizes value J). The values of Rev(Reg_award) and λ_bat,kmay be calculated by FR revenue estimator <b>2410</b>, performance score calculator <b>2412</b>, battery degradation estimator <b>2414</b>, and revenue loss estimator <b>2416</b>.

Estimating Frequency Response Revenue

Still referring to <figref idref="DRAWINGS">FIG. 24</figref>, low level controller <b>2214</b> is shown to include a FR revenue estimator <b>2410</b>. FR revenue estimator <b>2410</b> may estimate a frequency response revenue that will result from the frequency response Res_FR. In some embodiments, FR revenue estimator <b>2410</b> estimates the frequency response revenue using the following equation:

&lt;br /&gt;<i>Rev</i>(<i>Reg</i>_award)=<i>PS·Reg</i>_award(<i>CP</i>_cap<i>+MR·CP</i>_perf)

where Reg_award, CP_cap, MR, and CP_perfare provided as known inputs and PS is the performance score.

Low level controller <b>2214</b> is shown to include a performance score calculator <b>2412</b>. Performance score calculator <b>2412</b> may calculate the performance score PS used in the revenue function. The performance score PS may be based on several factors that indicate how well the optimal frequency response Res_FRtracks the regulation signal Reg_signal. In some embodiments, the performance score PS is a composite weighting of an accuracy score, a delay score, and a precision score. Performance score calculator <b>2412</b> may calculate the performance score PS using the performance score model shown in the following equation:

&lt;br /&gt;<i>PS=</i>⅓<i>PS</i>_acc+⅓<i>PS</i>_delay+⅓<i>PS</i>_prec

where PS_accis the accuracy score, PS_delayis the delay score, and PS_precis the precision score. In some embodiments, each term in the precision score is assigned an equal weighting (e.g., ⅓). In other embodiments, some terms may be weighted higher than others. Each of the terms in the performance score model may be calculated as previously described with reference to <figref idref="DRAWINGS">FIG. 23</figref>.

Estimating Battery Degradation

Still referring to <figref idref="DRAWINGS">FIG. 24</figref>, low level controller <b>2214</b> is shown to include a battery degradation estimator <b>2414</b>. Battery degradation estimator <b>2414</b> may be the same or similar to battery degradation estimator <b>2318</b>, with the exception that battery degradation estimator <b>2414</b> predicts the battery degradation that will result from the frequency response Res_FRrather than the original regulation signal Reg_signal. The estimated battery degradation may be used as the term λ_battin the objective function J. Frequency response optimizer <b>2408</b> may use the estimated battery degradation along with other terms in the objective function J to determine an optimal frequency response Res_FR.

In some embodiments, battery degradation estimator <b>2414</b> uses a battery life model to predict a loss in battery capacity that will result from the frequency response Res_FR. The battery life model may define the loss in battery capacity C_loss,addas a sum of multiple piecewise linear functions, as shown in the following equation:

&lt;br /&gt;<i>C</i>_loss,add<i>=f</i>₁(<i>T</i>_cell)+<i>f</i>₂(SOC)+<i>f</i>₃(DOD)+<i>f</i>₄(PR)+<i>f</i>₅(ER)+<i>C</i>_loss,nom

where T_cellis the cell temperature, SOC is the state-of-charge, DOD is the depth of discharge, PR is the average power ratio

<maths id="MATH-US-00077" num="00077"><math overflow="scroll"><mrow><mrow><mo>(</mo><mrow><mrow><mi>e</mi><mo>.</mo><mi>g</mi><mo>.</mo></mrow><mo>,</mo><mrow><mi>PR</mi><mo>=</mo><mrow><mi>avg</mi><mo></mo><mrow><mo>(</mo><mfrac><msub><mi>P</mi><mi>avg</mi></msub><msub><mi>P</mi><mi>des</mi></msub></mfrac><mo>)</mo></mrow></mrow></mrow></mrow><mo>)</mo></mrow><mo>,</mo></mrow></math></maths>

and ER is the average effort ratio

<maths id="MATH-US-00078" num="00078"><math overflow="scroll"><mrow><mo>(</mo><mrow><mrow><mi>e</mi><mo>.</mo><mi>g</mi><mo>.</mo></mrow><mo>,</mo><mrow><mi>ER</mi><mo>=</mo><mrow><mi>avg</mi><mo></mo><mrow><mo>(</mo><mfrac><mrow><mi>Δ</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><msub><mi>P</mi><mrow><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mi>bat</mi></mrow></msub></mrow><msub><mi>P</mi><mi>des</mi></msub></mfrac><mo>)</mo></mrow></mrow></mrow></mrow></mrow></math></maths>

of battery <b>2008</b>. C_loss,nomis the nominal loss in battery capacity that is expected to occur over time. Therefore, C_loss,addrepresents the additional loss in battery capacity degradation in excess of the nominal value C_loss,nom. The terms in the battery life model may be calculated as described with reference to <figref idref="DRAWINGS">FIG. 23</figref>, with the exception that the frequency response Res_FRis used in place of the regulation signal Reg_signal.

Still referring to <figref idref="DRAWINGS">FIG. 24</figref>, low level controller <b>2214</b> is shown to include a revenue loss estimator <b>2416</b>. Revenue loss estimator <b>2416</b> may be the same or similar to revenue loss estimator <b>2320</b>, as described with reference to <figref idref="DRAWINGS">FIG. 23</figref>. For example, revenue loss estimator <b>2416</b> may be configured to estimate an amount of potential revenue that will be lost as a result of the battery capacity loss C_loss,add. In some embodiments, revenue loss estimator <b>2416</b> converts battery capacity loss C_loss,addinto lost revenue using the following equation:

&lt;br /&gt;<i>R</i>_loss=(<i>CP</i>_cap<i>+MR·CP</i>_perf)<i>C</i>_loss,add<i>P</i>_des

where R_lossis the lost revenue over the duration of the frequency response period.

Revenue loss estimator <b>2320</b> may determine a present value of the revenue loss R_lossusing the following equation:

<maths id="MATH-US-00079" num="00079"><math overflow="scroll"><mrow><msub><mi>λ</mi><mi>bat</mi></msub><mo>=</mo><mrow><mrow><mo>[</mo><mfrac><mrow><mn>1</mn><mo>-</mo><msup><mrow><mo>(</mo><mrow><mn>1</mn><mo>+</mo><mfrac><mi>i</mi><mi>n</mi></mfrac></mrow><mo>)</mo></mrow><mrow><mo>-</mo><mi>n</mi></mrow></msup></mrow><mfrac><mi>i</mi><mi>n</mi></mfrac></mfrac><mo>]</mo></mrow><mo></mo><msub><mi>R</mi><mi>loss</mi></msub></mrow></mrow></math></maths>

where n is the total number of frequency response periods (e.g., hours) during which the revenue loss occurs and λ_batis the present value of the revenue loss during the ith frequency response period. In some embodiments, the revenue loss occurs over ten years (e.g., n=87,600 hours). Revenue loss estimator <b>2320</b> may provide the present value of the revenue loss λ_batto frequency response optimizer <b>2408</b> for use in the objective function J.

Frequency response optimizer <b>2408</b> may use the estimated performance score and the estimated battery degradation to define the terms in objective function J. Frequency response optimizer <b>2408</b> may determine values for frequency response Res_FRthat optimize objective function J. In various embodiments, frequency response optimizer <b>2408</b> may use sequential quadratic programming, dynamic programming, or any other optimization technique.

Frequency Response Control System

Referring now to <figref idref="DRAWINGS">FIG. 25</figref>, a block diagram of a frequency response control system <b>2500</b> is shown, according to exemplary embodiment. Control system <b>2500</b> is shown to include frequency response controller <b>2012</b>, which may be the same or similar as previously described. For example, frequency response controller <b>2012</b> may be configured to perform an optimization process to generate values for the bid price, the capability bid, and the midpoint b. In some embodiments, frequency response controller <b>2012</b> generates values for the bids and the midpoint b periodically using a predictive optimization scheme (e.g., once every half hour, once per frequency response period, etc.). Frequency response controller <b>2012</b> may also calculate and update power setpoints for power inverter <b>2006</b> periodically during each frequency response period (e.g., once every two seconds). As shown in <figref idref="DRAWINGS">FIG. 25</figref>, frequency response controller <b>2012</b> is in communication with one or more external systems via communication interface <b>2502</b>. Additionally, frequency response controller <b>2012</b> is also shown as being in communication with a battery system <b>2504</b>.

In some embodiments, the interval at which frequency response controller <b>2012</b> generates power setpoints for power inverter <b>2006</b> is significantly shorter than the interval at which frequency response controller <b>2012</b> generates the bids and the midpoint b. For example, frequency response controller <b>2012</b> may generate values for the bids and the midpoint b every half hour, whereas frequency response controller <b>2012</b> may generate a power setpoint for power inverter <b>2006</b> every two seconds. The difference in these time scales allows frequency response controller <b>2012</b> to use a cascaded optimization process to generate optimal bids, midpoints b, and power setpoints.

In the cascaded optimization process, high level controller <b>2212</b> determines optimal values for the bid price, the capability bid, and the midpoint b by performing a high level optimization. The high level controller <b>2212</b> may be a centralized server within the frequency response controller <b>2012</b>. The high level controller <b>2212</b> may be configured to execute optimization control algorithms, such as those described herein. In one embodiment, the high level controller <b>2212</b> may be configured to run an optimization engine, such as a MATLAB optimization engine.

Further, the cascaded optimization process allows for multiple controllers to process different portions of the optimization process. As will be described below, the high level controller <b>2212</b> may be used to perform optimization functions based on received data, while a low level controller <b>2214</b> may receive optimization data from the high level controller <b>2212</b> and control the battery system <b>2504</b> accordingly. By allowing independent platforms to perform separation portions of the optimization, the individual platforms may be scaled and tuned independently. For example, the controller <b>2012</b> may be able to be scaled up to accommodate a larger battery system <b>2504</b> by adding additional low level controllers to control the battery system <b>2504</b>. Further, the high level controller <b>2212</b> may be modified to provide additional computing power for optimizing battery system <b>2504</b> in more complex systems. Further, modifications to either the high level controller <b>2212</b> or the low level controller <b>2214</b> will not affect the other, thereby increasing overall system stability and availability.

In system <b>2500</b>, high level controller <b>2212</b> may be configured to perform some or all of the functions previously described with reference to <figref idref="DRAWINGS">FIGS. 22-24</figref>. For example, high level controller <b>2212</b> may select midpoint b to maintain a constant state-of-charge in battery <b>2008</b> (i.e., the same state-of-charge at the beginning and end of each frequency response period) or to vary the state-of-charge in order to optimize the overall value of operating system <b>2500</b> (e.g., frequency response revenue minus energy costs and battery degradation costs), as described below. High level controller <b>2212</b> may also determine filter parameters for a signal filter (e.g., a low pass filter) used by a low level controller <b>2214</b>.

The low level controller <b>2214</b> may be a standalone controller. In one embodiment, the low level controller <b>2214</b> is a Network Automation Engine (NAE) controller from Johnson Controls. However, other controllers having the required capabilities are also contemplated. The required capabilities for the low level controller <b>2214</b> may include having sufficient memory and computing power to run the applications, described below, at the required frequencies. For example, certain optimization control loops (described below) may require control loops running at 200 ms intervals. However, intervals of more than 200 ms and less than 200 ms may also be required. These control loops may require reading and writing data to and from the battery inverter. The low level controller <b>2214</b> may also be required to support Ethernet connectivity (or other network connectivity) to connect to a network for receiving both operational data, as well as configuration data. The low level controller <b>2214</b> may be configured to perform some or all of the functions previously described with reference to <figref idref="DRAWINGS">FIGS. 22-24</figref>.

The low level controller <b>2214</b> may be capable of quickly controlling one or more devices around one or more setpoints. For example, low level controller <b>2214</b> uses the midpoint b and the filter parameters from high level controller <b>2212</b> to perform a low level optimization in order to generate the power setpoints for power inverter <b>2006</b>. Advantageously, low level controller <b>2214</b> may determine how closely to track the desired power P_POI* at the point of interconnection <b>2010</b>. For example, the low level optimization performed by low level controller <b>2214</b> may consider not only frequency response revenue but also the costs of the power setpoints in terms of energy costs and battery degradation. In some instances, low level controller <b>2214</b> may determine that it is deleterious to battery <b>2008</b> to follow the regulation exactly and may sacrifice a portion of the frequency response revenue in order to preserve the life of battery <b>2008</b>.

Low level controller <b>2214</b> may also be configured to interface with one or more other devises or systems. For example, the low level controller <b>2214</b> may communicate with the power inverter <b>2006</b> and/or the battery management unit <b>2510</b> via a low level controller communication interface <b>2512</b>. Communications interface <b>2512</b> may 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 interface <b>2512</b> may 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 interface <b>2512</b> may 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, MODBUS, CAN, IP, LON, etc.).

As described above, the low level controller <b>2214</b> may communicate setpoints to the power inverter <b>2006</b>. Furthermore, the low level controller <b>2214</b> may receive data from the battery management unit <b>2510</b> via the communication interface <b>2512</b>. The battery management unit <b>2510</b> may provide data relating to a state of charge (SOC) of the batteries <b>2008</b>. The battery management unit <b>2510</b> may further provide data relating to other parameters of the batteries <b>2008</b>, such as temperature, real time or historical voltage level values, real time or historical current values, etc. The low level controller <b>2214</b> may be configured to perform time critical functions of the frequency response controller <b>2012</b>. For example, the low level controller <b>2214</b> may be able to perform fast loop (PID, PD, PI, etc.) controls in real time.

The low level controller <b>2214</b> may further control a number of other systems or devices associated with the battery system <b>2504</b>. For example, the low level controller may control safety systems <b>2516</b> and/or environmental systems <b>2518</b>. In one embodiment, the low level controller <b>2214</b> may communicate with and control the safety systems <b>2516</b> and/or the environmental systems <b>2518</b> through an input/output module (TOM) <b>2519</b>. In one example, the IOM may be an TOM controller from Johnson Controls. The IOM may be configured to receive data from the low level controller and then output discrete control signals to the safety systems <b>2516</b> and/or environmental systems <b>2518</b>. Further, the IOM <b>2519</b> may receive discrete outputs from the safety systems <b>2516</b> and/or environmental systems <b>2220</b>, and report those values to the low level controller <b>2214</b>. For example, the TOM <b>2519</b> may provide binary outputs to the environmental system <b>2518</b>, such as a temperature setpoint; and in return may receive one or more analog inputs corresponding to temperatures or other parameters associated with the environmental systems <b>2518</b>. Similarly, the safety systems <b>2516</b> may provide binary inputs to the TOM <b>2519</b> indicating the status of one or more safety systems or devices within the battery system <b>2504</b>. The IOM <b>2519</b> may be able to process multiple data points from devices within the battery system <b>2504</b>. Further, the TOM may be configured to receive and output a variety of analog signals (4-20 mA, 0-5V, etc.) as well as binary signals.

The environmental systems <b>2518</b> may include HVAC devices such as roof-top units (RTUs), air handling units (AHUs), etc. The environmental systems <b>2518</b> may be coupled to the battery system <b>2504</b> to provide environmental regulation of the battery system <b>2504</b>. For example, the environmental systems <b>2518</b> may provide cooling for the battery system <b>2504</b>. In one example, the battery system <b>2504</b> may be contained within an environmentally sealed container. The environmental systems <b>2518</b> may then be used to not only provide airflow through the battery system <b>2504</b>, but also to condition the air to provide additional cooling to the batteries <b>2008</b> and/or the power inverter <b>2006</b>. The environmental systems <b>2518</b> may also provide environmental services such as air filtration, liquid cooling, heating, etc. The safety systems <b>2516</b> may provide various safety controls and interlocks associated with the battery system <b>2504</b>. For example, the safety systems <b>2516</b> may monitor one or more contacts associated with access points on the battery system. Where a contact indicates that an access point is being accessed, the safety systems <b>2516</b> may communicate the associated data to the low level controller <b>2214</b> via the IOM <b>2519</b>. The low level controller may then generate and alarm and/or shut down the battery system <b>2504</b> to prevent any injury to a person accessing the battery system <b>2504</b> during operation. Further examples of safety systems can include air quality monitors, smoke detectors, fire suppression systems, etc.

Still referring to <figref idref="DRAWINGS">FIG. 25</figref>, the frequency response controller <b>2012</b> is shown to include the high level controller communications interface <b>2502</b>. Communications interface <b>2502</b> may 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 interface <b>2502</b> may 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 interface <b>2502</b> may 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 interface <b>2502</b> may be a network interface configured to facilitate electronic data communications between frequency response controller <b>2012</b> and various external systems or devices (e.g., campus <b>2002</b>, energy grid <b>2004</b>, incentive provider <b>2014</b>, utilities <b>2220</b>, weather service <b>2222</b>, etc.). For example, frequency response controller <b>2012</b> may receive inputs from incentive provider <b>2014</b> indicating an incentive event history (e.g., past clearing prices, mileage ratios, participation requirements, etc.) and a regulation signal. Further, the incentive provider <b>2014</b> may communicate utility rates provided by utilities <b>2220</b>. Frequency response controller <b>2012</b> may receive a campus power signal from campus <b>2002</b>, and weather forecasts from weather service <b>2222</b> via communications interface <b>2502</b>. Frequency response controller <b>2012</b> may provide a price bid and a capability bid to incentive provider <b>2014</b> and may provide power setpoints to power inverter <b>2006</b> via communications interface <b>2502</b>.

Data Fusion

Turning now to <figref idref="DRAWINGS">FIG. 26</figref>, a block diagram illustrating data flow into the data fusion module <b>2328</b> is shown, according to some embodiments. As shown in <figref idref="DRAWINGS">FIG. 26</figref>, the data fusion module <b>2328</b> may receive data from multiple devices and/or systems. In one embodiment, the data fusion module <b>2328</b> may receive all data received by the high level controller <b>2212</b>. For example, the data fusion module <b>2328</b> may receive campus data from the campus <b>2002</b>. Campus data may include campus power requirements, campus power requests, occupancy planning, historical use data, lighting schedules, HVAC schedules, etc. In a further embodiment, the data fusion module <b>2328</b> may receive weather data from the weather service <b>2222</b>. The weather service <b>2222</b> may include current weather data (temperature, humidity, barometric pressure, etc.), weather forecasts, historical weather data, etc. In a still further embodiment, the data fusion module <b>2328</b> may receive utility data from the utilities <b>2220</b>. In some examples, the data fusion module <b>2328</b> may receive some or all of the utility data via the incentive provider <b>2014</b>. Examples of utility data may include utility rates, future pricing schedules, anticipated loading, historical data, etc. Further, the incentive provider <b>2014</b> may further add data such as capability bid requests, price bid requests, incentive data, etc.

The data fusion module <b>2328</b> may further receive data from the low level controller <b>2214</b>. In some embodiments, the low level controller may receive data from multiple sources, which may be referred to collectively as battery system data. For example, the low level controller <b>2214</b> may receive inverter data from power inverter <b>2006</b>. Example inverter data may include inverter status, feedback points, inverter voltage and current, power consumption, etc. The low level controller <b>2214</b> may further receive battery data from the battery management unit <b>2510</b>. Example battery data may include battery SOC, depth of discharge data, battery temperature, battery cell temperatures, battery voltage, historical battery use data, battery health data, etc. In other embodiment, the low level controller <b>2214</b> may receive environmental data from the environmental systems <b>2518</b>. Examples of environmental data may include battery system temperature, battery system humidity, current HVAC settings, setpoint temperatures, historical HVAC data, etc. Further, the low level controller <b>2214</b> may receive safety system data from the safety systems <b>2516</b>. Safety system data may include access contact information (e.g. open or closed indications), access data (e.g. who has accessed the battery system <b>2504</b> over time), alarm data, etc. In some embodiments, some or all of the data provided to the low level controller <b>2214</b> is via an input/output module, such as TOM <b>2519</b>. For example, the safety system data and the environmental system data may be provided to the low level controller <b>2214</b> via an input/output module, as described in detail in regards to <figref idref="DRAWINGS">FIG. 25</figref>.

The low level controller <b>2214</b> may then communicate the battery system data to the data fusion module <b>2328</b> within the high level controller <b>2212</b>. Additionally, the low level controller <b>2214</b> may provide additional data to the data fusion module <b>2328</b>, such as setpoint data, control parameters, etc.

The data fusion module <b>2328</b> may further receive data from other stationary power systems, such as a photovoltaic system <b>2602</b>. For example, the photovoltaic system <b>2602</b> may include one or more photovoltaic arrays and one or more photovoltaic array power inverters. The photovoltaic system <b>2602</b> may provide data to the data fusion module <b>2328</b> such as photovoltaic array efficiency, photovoltaic array voltage, photovoltaic array inverter output voltage, photovoltaic array inverter output current, photovoltaic array inverter temperature, etc. In some embodiments, the photovoltaic system <b>2602</b> may provide data directly to the data fusion module <b>2328</b> within the high level controller <b>2212</b>. In other embodiments, the photovoltaic system <b>2602</b> may transmit the data to the low level controller <b>2214</b>, which may then provide the data to the data fusion module <b>2328</b> within the high level controller <b>2212</b>.

The data fusion module <b>2328</b> may receive some or all of the data described above, and aggregate the data for use by the high level controller <b>2212</b>. In one embodiment, the data fusion module <b>2328</b> is configured to receive and aggregate all data received by the high level controller <b>2212</b>, and to subsequently parse and distribute the data to one or more modules of the high level controller <b>2212</b>, as described above. Further, the data fusion module <b>2328</b> may be configured to combine disparate heterogeneous data from the multiple sources described above, into a homogeneous data collection for use by the high level controller <b>2212</b>. As described above, data from multiple inputs is required to optimize the battery system <b>2504</b>, and the data fusion module <b>2328</b> can gather and process the data such that it can be provided to the modules of the high level controller <b>2212</b> efficiently and accurately. For example, extending battery lifespan is critical for ensuring proper utilization of the battery system <b>2504</b>. By combining battery data such as temperature and voltage, along with external data such as weather forecasts, remaining battery life may be more accurately determined by the battery degradation estimator <b>2318</b>, described above. Similarly, multiple data points from both external sources and the battery system <b>2504</b> may allow for more accurate midpoint estimations, revenue loss estimations, battery power loss estimation, or other optimization determination, as described above.

Turning now to <figref idref="DRAWINGS">FIG. 27</figref>, a block diagram showing a database schema <b>2700</b> of the system <b>2500</b> is shown, according to some embodiments. The schema <b>2700</b> is shown to include an algorithm run data table <b>2702</b>, a data point data table <b>2704</b>, an algorithm run time series data table <b>2708</b> and a point time series data table <b>2710</b>. The data tables <b>2702</b>, <b>2704</b>, <b>2708</b>, <b>2710</b> may be stored on the memory of the high level controller <b>2212</b>. In other embodiments, the data tables <b>2702</b>, <b>2704</b>, <b>2708</b>, <b>2710</b> may be stored on an external storage device and accessed by the high level controller as required.

As described above, the high level controller performs calculation to generate optimization data for the battery optimization system <b>2500</b>. These calculation operations (e.g. executed algorithms) may be referred to as “runs.” As described above, one such run is the generation of a midpoint b which can subsequently be provided to the low level controller <b>2214</b> to control the battery system <b>2504</b>. However, other types of runs are contemplated. Thus, for the above described run, the midpoint b is the output of the run. The detailed operation of a run, and specifically a run to generate midpoint b is described in detail above.

The algorithm run data table <b>2702</b> may include a number of algorithm run attributes <b>2712</b>. Algorithm run attributes <b>2712</b> are those attributes associated with the high level controller <b>2212</b> executing an algorithm, or “run”, to produce an output. The runs can be performed at selected intervals of time. For example, the run may be performed once every hour. However, in other examples, the run may be performed more than once every hour, or less than once every hour. The run is then performed and by the high level controller <b>2212</b> and a data point is output, for example a midpoint b, as described above. The midpoint b may be provided to the low level controller <b>2214</b> to control the battery system <b>2504</b>, described above in the description of the high level controller <b>2504</b> calculating the midpoint b.

In one embodiment, the algorithm run attributes contain all the information necessary to perform the algorithm or run. In a further embodiment, the algorithm run attributes <b>2712</b> are associated with the high level controller executing an algorithm to generate a midpoint, such as midpoint b described in detail above. Example algorithm run attributes may include an algorithm run key, an algorithm run ID (e.g. “midpoint,” “endpoint,” “temperature_setpoint,” etc.), Associated Run ID (e.g. name of the run), run start time, run stop time, target run time (e.g. when is the next run desired to start), run status, run reason, fail reason, plant object ID (e.g. name of system), customer ID, run creator ID, run creation date, run update ID, and run update date. However, this list is for example only, as it is contemplated that the algorithm run attributes may contain multiple other attributes associated with a given run.

As stated above, the algorithm run data table <b>2702</b> contains attributes associated with a run to be performed by the high level controller <b>2212</b>. In some embodiments, the output of a run, is one or more “points,” such as a midpoint. The data point data table <b>2704</b> contains data point attributes <b>2714</b> associated with various points that may be generated by a run. These data point attributes <b>2714</b> are used to describe the characteristics of the data points. For example, the data point attributes may contain information associated with a midpoint data point. However, other data point types are contemplated. Example attributes may include point name, default precision (e.g. number of significant digits), default unit (e.g. cm, degrees Celsius, voltage, etc.), unit type, category, fully qualified reference (yes or no), attribute reference ID, etc. However, other attributes are further considered.

The algorithm_run time series data table <b>2708</b> may contain time series data <b>2716</b> associated with a run. In one embodiment, the algorithm_run time series data <b>2716</b> includes time series data associated with a particular algorithm run ID. For example, a run associated with determining the midpoint b described above, may have an algorithm run ID of Midpoint_Run. The algorithm_run time series data table <b>2708</b> may therefore include algorithm_run time series data <b>2716</b> for all runs performed under the algorithm ID Midpoint_Run. Additionally, the algorithm_run time series data table <b>2708</b> may also contain run time series data associated with other algorithm IDs as well. The run time series data <b>2716</b> may include past data associated with a run, as well as expected future information. Example run time series data <b>2716</b> may include final values of previous runs, the unit of measure in the previous runs, previous final value reliability values, etc. As an example, a “midpoint” run may be run every hour, as described above. The algorithm_run time series data <b>2716</b> may include data related to the previously performed runs, such as energy prices over time, system data, etc. Additionally, the algorithm_run time series data <b>2716</b> may include point time series data associated with a given point, as described below.

The point time series data table <b>2710</b> may include the point time series data <b>2718</b>. The point time series data <b>2718</b> may include time series data associated with a given data “point.” For example, the above described midpoint b may have a point ID of “Midpoint.” The point time series data table <b>2710</b> may contain point time series data <b>2718</b> associated with the “midpoint” ID, generated over time. For example, previous midpoint values may be stored in the point time series data table <b>2718</b> for each performed run. The point time series data table <b>2710</b> may identify the previous midpoint values by time (e.g. when the midpoint was used by the low level controller <b>2214</b>), and may include information such as the midpoint value, reliability information associated with the midpoint, etc. In one embodiment, the point time series data table <b>2718</b> may be updated with new values each time a new “midpoint” is generated via a run. Further, the point time series data <b>2716</b> for a given point may include information independent of a given run. For example, the high level controller <b>2212</b> may monitor other data associated with the midpoint, such as regulation information from the low level controller, optimization data, etc., which may further be stored in the point time series data table <b>2710</b> as point time series data <b>2718</b>.

The above described data tables may be configured to have an association or relational connection between them. For example, as shown in <figref idref="DRAWINGS">FIG. 27</figref>, the algorithm_run data table <b>2702</b> may have a one-to-many association or relational relationship with the algorithm_run time series association table <b>2708</b>, as there may be many algorithm_run time series data points <b>2716</b> for each individual algorithm run ID. Further, the data point data table <b>2704</b> may have a one-to many relationship with the point time series data table <b>2710</b>, as there may be many point time series data points <b>2718</b> associated with an individual point. Further, the point time series data table <b>2710</b> may have a one to many relationship with the algorithm_run time series data table <b>2708</b>, as there may be multiple different point time series data <b>2718</b> associated with a run. Accordingly, the algorithm_run data table <b>2702</b> has a many-to-many relationship with the data point data table <b>2704</b>, as there may be many points, and/or point time series data <b>2718</b>, associated with may run types; and, there may be multiple run types associated with many points

By using the above mentioned association data tables <b>2702</b>, <b>2704</b>, <b>2708</b>, <b>2710</b>, optimization of storage space required for storing time series data may be achieved. With the addition of additional data used in a battery optimization system, such as battery optimization system <b>2500</b> described above, vast amounts of time series data related to data provided by external sources (weather data, utility data, campus data, building automation systems (BAS) or building management systems (BMS)), and internal sources (battery systems, photovoltaic systems, etc.) is generated. By utilizing association data tables, such as those described above, the data may be optimally stored and accessed.

Configuration of Exemplary Embodiments

The construction and arrangement of the systems and methods as shown in the various exemplary embodiments are illustrative only. Although only a few embodiments have been described in detail in this disclosure, many modifications are possible (e.g., variations in sizes, dimensions, structures, shapes and proportions of the various elements, values of parameters, mounting arrangements, use of materials, orientations, etc.). For example, the position of elements may be reversed or otherwise varied and the nature or number of discrete elements or positions may be altered or varied. Accordingly, all such modifications are intended to be included within the scope of the present disclosure. The order or sequence of any process or method steps may be varied or re-sequenced according to alternative embodiments. Other substitutions, modifications, changes, and omissions may be made in the design, operating conditions and arrangement of the exemplary embodiments without departing from the scope of the present disclosure.

The present disclosure contemplates methods, systems and program products on memory or other machine-readable media for accomplishing various operations. The embodiments of the present disclosure may be implemented using existing computer processors, or by a special purpose computer processor for an appropriate system, incorporated for this or another purpose, or by a hardwired system. Embodiments within the scope of the present disclosure include program products or memory comprising machine-readable media for carrying or having machine-executable instructions or data structures stored thereon. Such machine-readable media can be any available media that can be accessed by a general purpose or special purpose computer or other machine with a processor. By way of example, such machine-readable media can comprise RAM, ROM, EPROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to carry or store desired program code in the form of machine-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer or other machine with a processor. Combinations of the above are also included within the scope of machine-readable media. Machine-executable instructions include, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing machines to perform a certain function or group of functions.

Although the figures may show a specific order of method steps, the order of the steps may differ from what is depicted. Also two or more steps may be performed concurrently or with partial concurrence. Such variation will depend on the software and hardware systems chosen and on designer choice. All such variations are within the scope of the disclosure. Likewise, software implementations could be accomplished with standard programming techniques with rule based logic and other logic to accomplish the various connection steps, processing steps, comparison steps and decision steps.