An Application of Excess Solar and Storage Capacity Optimization for Grid Services

Maxim Rusakov ^1,*, Faraz Farhidi ²

1. Evolution Networks, Israel

2. Department of Economics, Georgia State University, GA, USA

* Correspondence: Maxim Rusakov

Academic Editor: Ethan Mohseni Languri

Special Issue: Sustainable Energy Conservation and Conversion

Received: May 11, 2024 | Accepted: September 10, 2024 | Published: September 20, 2024

Journal of Energy and Power Technology 2024, Volume 6, Issue 3, doi:10.21926/jept.2403017

Recommended citation: Rusakov M, Farhidi F. An Application of Excess Solar and Storage Capacity Optimization for Grid Services. Journal of Energy and Power Technology 2024; 6(3): 017; doi:10.21926/jept.2403017.

© 2024 by the authors. This is an open access article distributed under the conditions of the Creative Commons by Attribution License, which permits unrestricted use, distribution, and reproduction in any medium or format, provided the original work is correctly cited.

1. Introduction

This initiative aims to enhance the efficiency of utility demand response (DR) operations by coordinating and integrating behind-the-meter (BTM) photovoltaic systems (PV) and energy storage (ES) using innovative machine learning software applications embedded in a distributed control architecture (DCA). Recent research discusses that a reduction in the emissions of greenhouse gases is feasible with a widespread adoption of distributed energy resources (DER) that can be utilized as virtual power plant (VPP), in oppose to the devastating impacts of the coal and gas power plants feeding on fossil fuels to the environment [1]. There are several attempts to design a DER system that can efficiently connect to the grid decreasing the possibility of grid failure in an unexpected series of events [2,3,4,5].

The totality of project—where this article is a subset of it—entered the trial phase by creating DER learning agents, Energy Storage-as-a-Service (ESaaS)—for customers who do not possess energy storage, Co-optimization, and Blockchain components—using for auditing purposes in case of a financial dispute between a utility and customers—, within a hierarchical and layered distributed control architecture (DCA). The DCA is comprised of two primary components – the Amazon Web Services (AWS) cloud and the Premise. All DERs within the premise are coordinated through the Premise Gateway on the local area network. The Premise Gateway collects, stores, and transmits DER snapshot and aggregation values. Snapshots are configuration values that do not change over time, while aggregation values are aggregate of telemetry data points that constantly update over time, which is not within the scope of this article. These components work together to leverage aggregated DERs, providing more adaptable and swiftly responsive grid services tailored to a customized grid services set (GSS). They exchange information to facilitate the analysis, optimization, and dispatch of DERs for grid services. This paper outlines the DER Aggregation Model and the functional requirements of the DER Aggregation Engine, which delineates how participating DER assets will be grouped or aggregated for involvement in each grid service. Utilizing DER aggregation models is well-known in the industry, where pioneers investigate its functionality, specifically in the demand response concept [6,7,8,9].

This paper briefly overviews the steps utilized in this project to feed in required information for the optimization. Then, it defines how co-optimized command sets is disaggregated and specifies the algorithms that is translated into functional software components. Co-optimization processes integrated for the distributed energy resources are well-documented in the literature [10,11,12,13,14]. We adopted such approaches for this project, created a comprehensive coordination which leads to lowering PV solar customers bill, as well as enhancing the grid reliability. The Co-optimization engine relies on several day-ahead forecasts, each associated with a level of uncertainty. The optimizer then calculates the setpoints of the DERs, optimizing each grid service function over a 24-hour time horizon to maximize revenue and/or meet distribution reliability requirements.

2. Learning Agent Modeling

2.1 DER Learning Agent Modeling

The DER Agents participate in two stages: First, they are responsible for communicating the current and short-term availability forecasts of the specific DER types to the Premise Agent and to the DER Aggregation Engine. Specifically, the following DER Agent types were developed: The customer BTM-ES (behind the meter energy storage) or Virtual ESaaS (energy storage as a service) Block communicates current and forecasted capacity states given control mode expectations, charge/discharge rates, roundtrip efficiency, and battery degradation; The PV system communicates near real-time to day-ahead real and reactive power generation forecasts; The thermostatically controlled loads, namely smart thermostat for air conditioning control (T-Stat) and (Grid Interactive Water Heater (GIWH), communicate their forecasted demand as well as thermal storage availability and load shed availability.

Once the Premise Learning Agent sets an optimal schedule for these DER assets that minimizes the customer’s electricity bill, the DER Learning Agents enter a second stage where they will communicate excess capacity for participation in grid services.

2.2 Premise Learning Agent Modeling

The Premise Agent forecasts the non-controllable portion of the premise load with the total controllable loads modelled into it. It combines the forecasted net load with the energy and demand prices derived from the assigned electric utility rate to determine the optimal way to utilize associated DER Learning Agent forecasts so that the customer’s electric bill is minimized under various electricity rate options, including Time-of-Use (TOU), Daily Demand Pricing (DDP), and Critical Peal Price (CPP), and combinations thereof—such as the TOU + CPP + DDP rate. Dynamic pricing is widely regarded as the most efficient rate, where integrating both customer preferences and market dynamics [15,16]. The main optimization in this project is referred to as customer bill management (CBM), where attempts to reduce customers bill under different rate scenarios. In an iterative fashion, after the CBM optimization is performed, the Premise Agent issues control and set point schedules to the DER Learning Agents for the next 24-hour period. This allows the DER Learning agents to forecast the excess capacity of associated DERs that is available for participation in each of the grid services.

Simultaneously, the forecasted bill reduction is weighted against the revenue generated from participating in grid services, and a combination of the services through co-optimization. If a need arises for DERs to participate in a particular grid service (such as avoiding equipment overload), then the utility takes control of the DER assets, and the Premise Agent calculates the cost impact to the customer of such override for reimbursement to the customer during financial settlement processes. Finally, the Premise Agent must communicate to the Blockchain-enabled financial settlement to process the measured grid services participation parameters. This optimized schedule provides a baseline that can be adjusted based on the output of the co-optimizer and the need to activate one of the grid services. Consequently, the associated minimum bill (MinBill) then is used to determine the compensation to the customer in using his DERs for the utility’s purposes.

2.2.1 Premise Non-Controllable Load Forecast

The historical data (at 15-min interval) of whole house power consumption is collected on a selected premise to investigate the accuracy of Prophet solver—which is the base forecast model in this project—on forecasting day-ahead energy demand. The model is trained with data from January 2018 to July 2021. Best performance is obtained by parsing out that data into seasonal blocks and adding ambient temperature as a regressor. A sample of a day-ahead 15-min forecast is shown in Figure 1, along with the actual load. Note the uncertainty interval (i.e., the random component of the load) is rather significant – a characteristic of sporadic changes in individual customer load. Further simulations is conducted on non-controllable loads of a premise using the same forecast tool. These loads include lighting, kitchen appliances, washer/dryer, etc. Figure 2 shows a sample where the sampling time interval of the data was 5-minutes. As one can expect, the sporadic changes and associated uncertainty interval are more dramatic in this case.

Figure 1 Day-ahead forecast and actual whole house load (15-min interval).

Figure 2 Day-ahead forecast of non-controllable loads (5-min interval).

2.2.2 AI Agent Interaction

Prior to deployment, the DER Agents collect data about the operating status and power consumption of the air conditioning unit and electric water heaters, PV power generation and energy storage charge/discharge cycles. Then they perform self-learning which consists of system identification that determines the values of the coefficients associated with their corresponding mathematical models described at the end of this report, in addition to demand forecasting for the total controllable loads. These models, which are necessary to predict the behavior of controllable loads (shown in Figure 2) following a control command, in turn are used in the optimization process. Simultaneously, the Premise Learning Agent collects data of the premise power consumption including non-controllable loads and performs self-learning for the purpose of short-term load forecasting.

The Premise Agent optimization solver then uses the appliance models, day-ahead forecasted usage and weather forecast to generate optimal solutions of individual DERs that minimize the customer bill (by altering the temperature set points of the T-Stats and GIWH, charging/discharging the ES, or a combination thereof to maximize the load reduction during peak price periods). Excess capacity of each DER then is determined from their availability (in terms of power and energy) after the above optimization take place. Finally, the estimate of the remaining available DER is provided for grid services. The Figure 3 summarizes the sequence of operation among DER and Premise Learning Agents.

Figure 3 Operation among DERs and Premise Agent.

3. Aggregation Model

Development efforts continued to productionize the grid service set and AI agent code as well as build out databases, servers and communication links between the various cloud components. All the cloud components have been deployed and commands/schedules are being sent down to the three test gateways.

The AI Agent pipeline that is responsible for Load, PV, nodal and wholesale price forecasts has been deployed and is actively running. The steps are as follows:

• Historical meter and substation telemetry data for 1+ years gets uploaded to the utility server.
• Development Server picks up these files, runs the FB Prophet training protocol and saves the trained models in the Model Storage bucket.
• Lambda function running CBM picks up these trained models and inferences them to run day - ahead forecasting, results of which are saved in PostgreSQL production database.

For wholesale price forecast, the OASIS API is used to pull historical data for training directly onto Development Server.

The T-Stat and GIWH have been built and deployed. The steps are as follows:

• The e-Gauge API is used to pull historic run-time data for each customer onto development server.
• Thermostat (Ecobee) setpoints are collected from customer gateways and stored in PostgreSQL production database.
• Historic setpoints and run time data points combined with spec sheets (uploaded via s3) are used to train models whose parameters are stored in PostgreSQL production database.
• Setpoints collected via the customer gateways are also used to determine personalized comfort thresholds for offsets.
• The T-Stat and GIWH agents then determine the degree offsets and duration for a curtail event and corresponding kWh setback and snapback values and saves them in PostgreSQL production database.

The grid service set has also been deployed and is actively running. For the co-optimization and CBM the steps are as follows:

• The CBM Lambda function takes as input the forecasts calculated by the AI agents along with real time telemetry readings from the gateways, weather forecast, current TOU rates and T-Stat and GIWH agent output, runs a 24-hr ahead cost based optimization and saves the schedule in the PostgreSQL production database.
• The co-optimization Lambda function then runs a similar optimization to the CBM, using the wholesale price forecasts instead of TOU rates and including phase balancing, peak load management and energy arbitrage constraints and saves its schedule in the PostgreSQL production database.
• The output from the co-optimization is then formatted into gateway and ESaaS commands by the utility Secured production server and sent via MQTT to the DERs through the gateways and via secure file transfer protocol (SFTP) to the ESaaS through Energy Management System (EMS).

The Voltage Support (VS) and Frequency Regulation (FR) grid services have separate process flows in Amazon Web Service (AWS) and they are as follows:

• FR – AGC signal comes in from Energy Management System (EMS) and triggers secondary FR Lambda function.

• VS – Local voltage disturbance (over or under voltage) as reported by telemetry readings from gateways triggers centralized (Level-2) VS Lambda function.

• FR – Optimization determines charge/discharge commands to send to specific resources (BTM batteries/ESaaS).

• VS – Optimization determines which resources (inverters) to switch from autonomous mode to direct reactive power control mode and direct Q values to send.

• commands are formatted and send down in real time via gateways for customer DERs and to EMS for the ESaaS.
• The processes for both VS and FR are repeated at intervals equal to the frequency of telemetry data readings from the gateways and substation until the AGC signal has been met for FR and until the voltage disturbance has been solved for VS.
• The Managed Blockchain service has also been deployed and is ready to receive the four determined bills from the utility Secured production server. These bills will be calculated daily using billing determinants stored in PostgreSQL production database and communicated via REST API calls through AWS API Gateway to the Managed Blockchain service.
• From here billing credits is sent to utility billing department.

Numerous insights have been gleaned from the intricate process of developing the co-optimization engine. Primarily, the amalgamation of frequency regulation, energy arbitrage, and peak load management grid services into a singular objective function presented greater complexities than initially envisaged. Consequently, a pragmatic resolution emerged, wherein the available capacity was bifurcated into reserve and excess through a predetermined percentage, and distinct optimizations were executed for each component. Although this current bifurcation approach is currently adopted due to its streamlined implementation, the possibility of transitioning to a unified, optimized objective function is contemplated pending a thorough evaluation during the preliminary field-testing phase.

An additional discernment pertains to the substantial impact of wholesale price forecast accuracy on the DER schedule generated by the co-optimization engine. To mitigate the emergence of highly variable and unpredictable daily schedules, characterized by an excessive number of charge/discharge cycles for the battery, a strategic reliance on the forecast smoothing feature of FB Prophet is employed. Specifically, by leveraging the "daily seasonality" inherent in wholesale price movements as the $/kWh utility costs in the co-optimization process, we ensure the preservation of stability within the DER schedules. This meticulous consideration of forecast accuracy and the judicious utilization of FB Prophet's capabilities underscore our commitment to refining and optimizing the performance of the co-optimization engine in real-world applications. Figure 4 shows the sample price prediction results utilizing the FB Prophet model, where y-axis represents energy prices $ per MWh.

Figure 4 FB Prophet daily seasonality output (in winter and summer) of wholesale price movements.

3.1 Pre-Steps

Three scripts have been coded and deployed to the AWS to complete the aggregation model which is needed to run the co-optimization.

• Colleting real time energy prices from CAISO were automated and append every day to not only calculate the customers’ credit and wholesale rates, but also, forecasting a day-ahead price for the MinBill and Co-optimization algorithms. 
• Colleting weather projection data was automated which gathered three major factors needed for Premise/PV/Price forecasts: Temperature, humidity, and sky coverage.
• Collecting Phase/Feeder/transformer level data and append it weekly to calibrate grid side load forecast.
• Solar irradiance data was collected on daily bases from NREL website and pass to the AWS to use for the solar generation forecast for the customers.
• All these four datasets are automated from NV Energy platform, send to the secured file transfer protocol (SFTP), and from their automated to be sent to the AWS cloud.

3.2 Data Requirements for Aggregation

The followings are the necessary data points to feed into the aggregation model:

• CAISO real-time energy market price forecasts under uncertainty: LMP-Real time for the ELAP_NVD node.
• Day-ahead nodal load forecasts at the following tiers: Substation (Beltway and Village), feeders, and phase.
• Day-ahead weather forecast: temperature, humidity, cloud coverage which are essential for energy price forecasts, solar generation predictions, and nodal load forecasts.
• NV Energy system marginal cost and avoided costs at the transmission and distribution levels.
• Premises preferences on degree changes and ranges throughout the whole year.
• Premises’ loads and PV generation, BESS kW/kWh, GIWH set points, schedule and used power, # T-Stat per premise, set points, schedule, and used power.

3.3 Aggregation Steps

The followings are the required steps to aggregate the data, and make it ready for the Co-optimization process:

Calculate the day ahead reserve capacity for foundational grid services (peak load management + energy arbitrage).

• BTM ES/ESaaS – Fixed percentage of battery ramp up/down capacity e.g.: 

• $[0.05\times \mathrm{kWh\,capacity},0.95\times \mathrm{kWh\,capacity}]$

• T-Stat/GIWH – kWh corresponding to maximum setpoint deviations within customer’s comfort levels (as determined by studying their collected historical setpoints).

Calculate the day ahead excess capacity for ancillary grid services (frequency regulation).

• BTM ES/ESaaS – Excess battery ramp up/down capacity e.g.:

• $[0,0.05\times\text{ kWh capacity}]\mathrm{~and~}[0.95\times\text{ kWh capacity, kWh capacity}]$

• T-Stat/GIWH – kWh corresponding to setpoint deviations exceeding customer’s comfort levels by minimal predetermined threshold.

The reserve capacity is fed into the co-optimization engine per time period/Premise/DER e.g., 4-5 PM, BTM ES $[-\mathrm{X}_{1} \mathrm{kWh},\mathrm{Y}_{1} \mathrm{kWh}]$ along with the forecasted load/PV generation and wholesale price/nodal load forecasts. The co-optimization engine then determines the optimal 24 hour ahead DER schedules using grid cost minimization under grid reliability constraints (phase balancing/rated capacity at nodal aggregation points).

Then overall excess capacity is offered to the ancillary market as the potential resources for the price. If such recourse has been called, deploy the command, use the excess capacity, and credit the customers’ bill. The frequency regulation optimization engine determines the quantity of each customer DER’s excess capacity that gets called to the ancillary market to meet its demand. If no such event gets called the excess capacity goes unused.

3.4 Data Processing

The Pre-Optimization Data Processing is responsible for preparing data transmitted via DER Gateway interfaces. It ensures data integrity and relevance through the following functions:

• Data Validation: Identifies and corrects incomplete or erroneous data to maintain accuracy.
• Date Sorting: Organizes DER availability forecasts by DER Type, Grid Service, and Managed Aggregation Points to streamline optimization processes.
• Reliability Adjustments: Works with the Reliability Management service to apply reliability discount factors, enhancing data reliability for accurate calculations and optimizations.

4. Matrix Transformation: Converts Time Series Availability Forecast Vectors into Matrices to Meet the Specific Requirements of Grid Service Optimization Engines. Co-Optimization Algorithm and Modeling

4.1 Process Flow for the Co-Optimization Engine

Figure 5 is the process flow for the co-optimization algorithm. The Python code written for the optimization is available upon request:

Figure 5 Co-Optimization Procedure Diagram.

4.2 Algorithm’ Steps for the Co-Optimization

• Calculate the day-ahead hourly reserve and excess capacity per DER per premise (ramp up or down, ultimately it should be a summation of all the DERs at each premise, e.g., 4-5 PM, $[-\mathrm{X}_{1} \mathrm{kWh},\mathrm{Y}_{1} \mathrm{kWh}]$.
• Allocate reserve capacity to foundational grid services (peak load management & energy arbitrage) and excess capacity to ancillary grid services (frequency regulation).

4.2.1 Reserve Capacity

• Define grid reliability constraints (phase balancing and transformer/substation rated capacity) using forecasted loads at nodal aggregation points E.g. phase A – Phase B < 150 Amps, Substation load < 50 MW.
• Run cost reduction optimization using available DER reserve capacity and forecasted LMP-Real time prices for the ELAP_NVD node to output disaggregated day ahead DER schedules (including ESaaS schedule).
• Run MinBill optimization for each customer using TOU-CPP-DDP rates and forecasted loads (taking into account controllable load curtailment) and solar generation.

4.2.2 Excess Capacity

• Sum up all the excess hour-capacity for all the premises enrolled in the program, at three different levels: phase, feeder, substation (bank).
• Package the overall capacity and offer to the ancillary market as the potential resources for the price.
• If such recourse has been called, deploy the command, use the excess capacity, and credit the customers’ bill.

4.2.3 Billing

• Calculate customer bill using co-optimization schedule with TOU rates where proceeds from energy arbitrage (+kWh grid to battery/-kWh battery to grid) split between utility & customer at predefined proportion and called grid service capacity (E.g. frequency regulation) compensated at predefined rate.
• If the difference remains between final consolidated bill and MinBill, compensate customer this difference.

5. Test Cases and Results

The core optimization code was successfully developed, by adapting the CBM logic to a utility side cost reduction format and deployed in an AWS Lambda function where it has been running once every 24 hours and saving the day ahead schedule for all DERs for 3 sample premises in a PostgreSQL database.

To ensure the robustness of the co-optimization engine, it has been split into the following components/test cases that have been validated through daily runs in the cloud over a 10-day period from Dec 17-27, 2023. Success is defined as each component running without errors for all 10 days and as intended through manual spot checks of the outputs.

• Day ahead reserve and excess capacity forecasts for DERs calculated for all sample premises – using imported aggregated data.
• Day ahead weather and market price forecasts calculated.
• Day ahead load forecast and MinBill calculated for all sample premises.
• Phase balancing and rated capacity constraints influencing co-optimization engine output.
• Co-optimization engine saves DER schedules and converts them to commands that are sent down to each premise gateway and DER through dedicated MQTT topics.

5.1 Co-optimization Result

For the ESaaS, a single daily run was performed, in which the battery was treated as a separate premise. The co-optimizer successfully output an optimized day ahead charge/discharge schedule and an automated system was triggered that e-mailed the schedule to the battery operator, as it is shown in Figure 6, where y-axis shows kW charge/discharge and whole sale market prices.

Figure 6 Charge/discharge schedule output from co-optimizer for sample day of July 1, 2022.

Additionally, in order to effectively shift load while minimizing customer compensation, additional test cases were defined in which simulated utility costs were analyzed and simulated customer bills outputted from the co-optimization and MinBill engines were compared. The purpose of these test cases was to determine that wholesale market costs were effectively being reduced using customer load shifting while minimizing the customer compensation. To this end, the co-optimizer and MinBill algorithms were retrospectively run for a 2-month summer period in which TOU-CPP-DDP rates apply for a sample premise whose historic loads and PV generations were known. Additionally, a 5 kW/13.5 kWh BTM battery was included in the back-test in order to simulate the effects of load shifting. The following test cases and their success criteria have been validated and tables with simulation results have been provided for reference (Table 1 & Table 2).

• % difference between MinBill and Co-Opt bill less than 10%.
• Wholesale market costs (w load shifting-w/o load shifting) > 0.

Table 1 Customer bills for a selected for the summer months of 2022.

Table 2 Utility wholesale market costs for a selected premise for the summer months of 2022.

5.2 Customer Bill Management

The Customer Bill Management algorithm takes as input, for each customer, the day ahead load (both non-controllable and controllable loads) and solar generation forecasts, appliance models and rate tariffs and outputs an optimal 15-min day ahead DER schedule. As an illustration, the optimal charge/discharge schedule for a BTM ES for customer under TOU-CPP-DDP for the day of July 1, 2022, is presented in Figure 7. Herein, the battery capacity is 13.5 kWh with 5 kW charging and discharging rates. It must be noted that we used the specifications and parameters of the available battery in the trial; however, any battery can be used in such a process, only the logics of the optimization should be changed accordingly. In this scenario, the battery is only allowed to charge from solar and discharge into the premise. The mathematical model in this context is a cost-based function that represents the customer’s daily electricity costs based on their 15-min kWh consumption and rate structure. The total cost is determined as follows:

\[ \begin{aligned} \mathit{\pmb{Total\,Cost}}& =\mathrm{Bass}_{\mathrm{Rate}}+1.05\times\begin{pmatrix}\mathrm{Rate}_{\mathrm{on~peak}}\times\mathrm{Import}_{\mathrm{on~peak}}\\+\mathrm{Rate}_{\mathrm{off~peak}}\times\mathrm{Import}_{\mathrm{off~peak}}\\+\mathrm{Rate}_{\mathrm{critical~peak}}\times\mathrm{Import}_{\mathrm{critical~peak}}\end{pmatrix} \\ &+\left(\mathrm{Demand}_{\mathrm{Charge}}\times\mathrm{Daily}_{\mathrm{Max}_{\mathrm{Load}}}\right)+\left(\mathrm{Misc}_{\mathrm{Charges}}\times\mathrm{Total}_{\mathrm{Import}}\right) \\ &-(\text{Solar_Export_Credit}+\text{Battery_Export_Credit}) \end{aligned} \tag{Eq 1} \]

where:

\[ \text{Import}=\text{battery charge from grid}+\text{native load} \tag{Eq 2} \]

\[ \begin{aligned} \text{State of Charge}&=\text{battery charge from solar}+\text{battery charge from grid}\\ &-\text{battery discharge to premise}\end{aligned} \tag{Eq 3} \]

\[ 0<\text{State of Charge}<13.5\text{kWh} \tag{Eq 4} \]

\[ \begin{aligned}0&<\text{battery charge from solar}+\text{battery charge from grid}\\&<\min(13.5-\text{State of Charge},5)\text{ kW}\end{aligned} \tag{Eq 5} \]

\[ 0<\text{battery discharge to premise}<\text{min (State of Charge,5) kW} \tag{Eq 6} \]

\[ \text{Solar to premise}+\text{native load}+\text{battery discharge to premise}=\text{demand (forecast)} \tag{Eq 7} \]

\[ \text{Solar to premise}+\text{solar to grid}+\text{battery charge from solar}=\text{solar generation (forecast)} \tag{Eq 8} \]

Figure 7 Sample of BTM battery charging and discharging patterns for sample day of July 1, 2022.

This function is then minimized using Google OR-Tools’ GLOP optimizer to determine the kWh imported and exported every 15-min from the BTM ES in order to minimize the customer’s bill. We see in Figure 7 that this is achieved by first diverting all solar generation to the battery, in the morning off-peak hours, until it reaches maximum charge. Then, in the afternoon on-peak hours, dynamically discharging the battery to both shift load as well as minimize the demand charge, most effectively achieved through an accurate load forecast. Y-axis shows charging/discharging rate in kW.

Additionally, in this project period, simulations were run using historical load and PV data for three example premises, under a flat rate, TOU-CPP-DDP and real time rates to determine the feasibility of participating in the program and the yearly savings associated with switching from a flat to a variable rate. Yearly optimizations were also run using the Google OR-Tools python package to determine the customer MinBill and optimal charge/discharge schedules using a simulated 13.5 kWh Tesla Powerwall battery to shift load away from price peaks.

The simulations/optimizations were run for the entirety of the year 2022 under net metering tariffs (netted monthly) for flat and TOU-CPP-DDP rates. Accurate historical prices, critical peak events and daily demand charges were all provided as inputs into the optimization algorithm. A monthly battery financing fee was also included in the optimization cost function. The results for a selected customer are presented in Table 3.

Table 3 Selected customer’s bill under different scenarios using 2022 rates and prices.

The illustration presented above delineates a customer bill subjected to various rates, including the flat rate, TOU-CPP-DDP, and distinct price structures such as CAISO LMP price and Imbalance market price, both with and without the integration of a battery. In the presence of a behind the meter battery, the customer gains the ability to capitalize on energy arbitrage opportunities within the market. It is imperative to acknowledge that the depicted figures are derived under the assumption of perfect price realization, a scenario unattainable when forecasting loads or prices. Precisely predicting the future instances when prices reach their nadir (facilitating purchases, possibly at negative prices) or zenith (allowing for sales) is inherently elusive. Consequently, the figure serves to elucidate the upper bound potential associated with the utilization of a battery by customers.

6. Conclusion

The analysis of our forecasting tools and conditions provides several key insights. Under clear skies, only one forecasting tool matched the theoretical forecast, with errors below 6%. In contrast, forecasts under partly cloudy or cloudy conditions had larger errors, often exceeding 20%, especially during morning and afternoon hours. Updated forecasts improved performance but only within the first two hours after the update. Without incorporating local measurements with finer time resolutions, such as sky imagery or solar irradiance, significant forecasting errors are expected to persist. Back-tested optimization indicates that customer bills could increase with monthly battery financing costs unless mitigated by HVAC/GIWH curtailing. Appliance models require granular data, including historic set points and kWh usage, necessitating customers to have sub-meters and smart thermostats. However, not all customers have this equipment, requiring simplified models until sufficient data is collected. Accurate estimation of appliance-specific parameters depends on data accuracy and the chosen period, even with sub-meter data.

The development of the DER aggregation engine has yielded several lessons. Dynamic aggregation with optimized disaggregation is easier than summative aggregation and fair utilization disaggregation. Tests show that the optimizer's performance is minimally impacted despite limits on concurrent DERs. Grid reliability constraints at managed aggregation points are expected to remain within operational parameters, easing concerns about constraint breaches. To improve smart thermostat availability forecasts, additional telemetry values, such as mode of operation and distinct heating/cooling setpoints, have been identified. These developments highlight optimization strategies, computational efficiency, and considerations for grid reliability constraints in the DER aggregation engine's development.

Author Contributions

Maxim Rusakov: Conceptualization, software, writing – original draft, writing - review and editing, formal analysis. Faraz Farhidi: Conceptualization, methodology, writing – original draft, writing – review and editing, formal analysis.

Funding

This project is funded by Department of Energy (EE-0009022).

Competing Interests

The authors have declared that no competing interests exist.