Hybrid/Storage Model Description
Long-term time domain
The model is built as a full time-domain simulator that runs over the entire 25+ year lifetime of a project. Instead of compressing data into a single 8760 — a simplified year that lacks variability — it steps through every hour (or sub-hour) of operation across decades. Each operational year is simulated with the long-term time series, meaning a project designed for 20-year life with a 25-year data simulation for each year could have 500-years of simulations for one scenario! That's 4.3 million hourly forecast operations!
Interaction between solar, wind, storage, hardware limits, degradation, and market conditions is captured in detail as it actually unfolds over time. This long-term, time-domain approach makes it possible to see not just how a system looks on day one, but how it really performs — and earns — throughout its entire life.
Nodal Busbar simulation
The model includes a completely customizable system representation. Using a nodal configurator, generation, storage and grid conditions are all modeled together — it captures how power flows through transformers, inverters, and shared capacity limits. If multiple assets are competing for the same bus, these constraints are reflected in the results, with power flows prioritized based on design objectives. This level of detail helps developers and investors see the real bottlenecks in hybrid systems, ensuring proper valuation.
BMS Emulation
Cloud Scalable and Fast
Cloud Scalable and Fast
A key part of the model is the battery management system (BMS). Instead of assuming the battery always charges at the lowest price and discharges at the highest — a “perfect arbitrage” assumption you see in many tools — the model uses forecast-aware logic, emulating dispatch decisions for each time step. Hundreds of optimizations are run before considering current state and future conditions before deciding whether to charge, discharge or hold. By capturing these uncertainties and constraints, the model produces dispatch patterns and revenue forecasts that look much closer to real-world performance, giving investors and operators a more reliable picture of how the system will actually behave.
Cloud Scalable and Fast
Cloud Scalable and Fast
Cloud Scalable and Fast
Under the hood, the model is driven by Hendrickson's MUNY-H framework. This data framework was specifically developed to process structured, time-series data in vast quantities at lightning speeds in the cloud. Long before we built our first model, we spent time making sure it was fast. A single year hybrid simulation with hourly forecasting optimization might take a second or two. But, we really begin to flex when the problems get complex - think resource generation regions coupled by DC lines. We can run 100,000's of configuration simulations, optimizing over any desired dimension on the hunt for a solution. And for the really big problems, we can bring out even more tools to solve, like genetic algorithms maximizing a fitness function drawn from your financial model.
Hybrid Optimization Example
What question to ask?
A demo project is configured to ask a simple question — with a standalone, grid connected battery, adjacent to a grid connected PV project, what optimal system will allow for the firm delivery of 300 MW of power during the peak 4 demand hours. Dynamic, hourly demand data is available for the local system.
The model is configured to scale a PV design over a 400 MW range and the BESS system over a 1500 MWh range.
The battery is configured to charge from the grid, whether or not the PV plant is operating. The battery is a 4-hour battery, but is allowed to push power to the top 8-hours.
The PV plant is able to deliver all of it's power, but above the firm target threshold, power is sold at a reduced rate.
Examining the data
After 441 model simulations — just toying around — the range of capacity sizing where the firm target question is answered is achieved. The image above shows this. But, not all solutions are equal.
The image to the right reveals that in some of the solution space, the battery is getting hammered and likely exceeding it's cycle warranty. Whereas, in other parts of the solution space, the battery might be underutilized.
In a real optimization, the many additional battery configuration options might be tested too.
Should I oversize PV?
Since the battery is operated as a standalone, and drawing power from the grid, excess energy is not a function of the battery. Were the battery to be configured on the same medium-voltage bus, it could smartly use both solar and grid power to optimize.
In this example all, PV power up to the firm target is delivered to the virtual POI. Excess energy is lost or delivered. Depending on the value of this, might determine how much we care about oversizing.
Narrowing in on a solution
With this simple example, a solution space might be developed that answers this question — what size of battery which is limited to 4% of 365 cycles per year, will allow delivery of firm target power when combined with a PV project that we don't want to deliver any excess energy.
This is a very simple case that illustrates a process. In a real example, hundreds of thousands of design cases can be iterated which can be coupled with cost models and integrated into dynamic financial models to solve more realistic cases.
We think it's pretty cool.