Introduction

Figuring out the best configuration of energy assets for a given scenario is a tricky problem. The permutations are potentially infinite and every site and scenario is different.

Broadly speaking there are two main aspects of the scenario we need to consider

• The physical aspect, i.e. the shape of any existing site load, site import and export constraints, the shape of any renewable energy generation profile, and the specifications of any hardware.
• The financial aspect, i.e. any energy and demand charges (either from retail and network charges, market prices or some combination of both), DER asset capex and opex costs, and any DER energy on-sell rates.

The interplay between these aspects is complicated and can lead to very different optimal configurations for scenarios that, on the surface, appear quite similar, but manually searching through even a small subset of these possibilities can be a time-consuming task.

Fortunately, this complexity can largely be handled by established optimisation algorithms. The trickiness then shifts to being able to reliably and effectively construct optimisation problems to feed the algorithms with. This is something we’ve got a lot of experience with at Gridcog and we’re excited to have built it into our new auto-sizing feature.

Conceptually the feature is simple. Rather than manually specify a system size for renewable energy generation assets and batteries, we  just configure the objectives and constraints for the scenario then let our optimisation algorithm automatically select the best combination of assets for the user. This can include specifying minimum and maximum sizes for each asset (e.g. it may only be possible to fit 50 kW of solar panels on a site’s roof) and will consider all price signals the assets are exposed to as well as how those price signals are assigned to the different participants in the scenario.

Behind the scenes there are a few other complexities to overcome but, before getting into them, we’ll run through an example.

Example Project

We’ll use a relatively simple project as an example to highlight the auto-sizing feature. Even so, there is still a lot of variety on display. The project has four sites: a data centre, an office, a shopping centre and a water treatment plant. Each site has its own load profile.

We’ll locate each site near Sydney, NSW, Australia and put them all on the same, standard retail and network tariff combination. The retail tariff has peak and off-peak energy charges, the network tariff (Ausgrid EA305) has peak and off-peak energy charges as well as a peak demand charge applicable on weekday afternoons.

Looking at the load profiles we can see that all loads are in the same ball-park size-wise but have significantly different shapes (see Figure 1). The data centre load is basically flat, whereas the water treatment plant load is peaky as big pumps turn on and off.

Now we can add auto-sized solar and battery assets to each site. We’ll keep the solar tilt and orientation fixed for each site and the battery duration fixed at two hours. The battery is allowed to be any size whereas the solar can only be up to 400 kW to simulate a roof-space constraint. Each asset has a capex charge attached. To account for the certificate rebate small solar systems receive in Australia the solar capex has a stepped rate where the $/kW jumps up from $1200/kW to $1700/kW at a system size of 100 kW.

Despite the similarities in the setups for each site the auto-sizing results are very different (see Figures 2 and 3). With its flat, “always on” load the data centre is preferencing the maximum amount of 400 kW of solar and hardly any battery storage. A huge battery would be required to make a dent on the demand charges and it’s just not worth the investment. Meanwhile the water treatment plant is the complete opposite. The solar is capping out at the top of the cheaper, small-system price band at 99 kW and a large battery is chosen to control the peaky load and bring the demand charges down.

The office and shopping centre both sit somewhere in the middle. The main difference is that the shopping centre pushes the solar system size into the higher price band. This is partly because the shopping centre uses more energy but mainly because the shopping centre has high load all week whereas the office shuts down over the weekend. We haven’t assigned any feed-in value to excess solar so the auto-sizing algorithm is motivated to match the solar yield to the existing load shape rather than over-sizing the system.

Swapping Tariffs

To demonstrate how big an effect it can have we re-ran the exact same project but swapped the network tariff to Endeavour N19. This is an equivalent tariff from a neighbouring network service provider in NSW so our site could have just moved over the road! Although the overall pricing is similar it breaks down in a completely different way. We can see how by looking at the office site (see Figure 4).

There is a much larger energy component compared to EA305 and a smaller demand component. However, the N19 billable demand window is narrower and the demand value resets each month, as opposed to EA305 which only resets each year. Both of these factors make it easier for a battery to capture value from the demand price signal.

The auto-sizing results are markedly different with an all-round increase in DER asset sizes (see Figure 5). The solar sizing has increased where possible as it directly captures more value from the increased network energy charges. In particular both the office and water treatment sites have been nudged over the cheaper, small-system threshold at 99 kW and now larger systems are more cost effective. The battery sizing has also increased as the battery is more able to capture value from the N19 demand price signals.

How Does it Work?

The core optimisation process is shared with our general DER asset optimiser. All price signals and how they are assigned to the scenario’s participants are processed into a standardised, interval-by-interval pricing matrix.

This accounts for energy, demand, capacity charges and so on and also accounts for arbitrary time-of-use periods. This pricing matrix is used to construct an objective function for the optimiser. Meanwhile all site load data, physical constraints and DER asset specifications are processed to construct a set of constraints for the optimiser.

For auto sizing we first need to add sizing variables to represent the sizes of the assets we want to optimise then modify the constraints to reference these variables instead of fixed values. For batteries this is simply a case of scaling up and down constraints for things like maximum charge and state of charge. For generation assets like solar and wind we calculate a generic, normalised raw generation profile for each asset and scale this up and down in the constraints. We also need to add capex and opex contributions referencing the sizing variables to the objective function.

The general optimiser breaks up the entire run of interval data into more manageable chunks and optimises each chunk individually. We can’t use this approach for auto sizing as the sizing variables have to be the same across the entire optimisation and the problem would become too large. Instead, we consolidate the interval data into a condensed sample and optimise on this. There is always going to be some art in constructing such a sample!

Our approach is to pick out special days that we expect to have a large impact on the results. These include the days with maximum demand, maximum energy usage and minimum renewable energy generation each month. The special days are included directly in the sample. The remaining days are grouped by month and whether they are a weekday or weekend then averaged up. The averaged days are included in the sample with their corresponding rates weighted by the number of days that went into the average (see Figure 6).

The problem can now be fed directly into the optimiser where it is solved by a linear solver if we can get away with it or a mixed-integer solver if there are discrete constraints we can’t work around.

The output of the optimiser includes optimised sizes for all DER assets we included. However, the sampling process distorts the problem somewhat so, while they ought to be a good starting point, the optimised sizes may not always be the absolute best solution.

To account for this we use the optimiser output as a centre point for a simple grid search, typically varying the optimised asset sizes by ±20%. All variations in the grid search are fed through the full, general DER asset optimiser and the final cashflows are fully calculated. The one with the best overall result is recorded.

An example is shown in Figure 7. For the office site in our example project the result from the optimiser was 99 kW of solar and a 70 kWh battery. A grid search was performed to include 79 and 119 kW solar systems and 56 and 84 kWh batteries. While the solar system size remained the same, dropping to a 56 kWh battery proved to give a better outcome so this was the main result presented.

Future Prospects

This is just the beginning of our auto-sizing feature and a simple example. Several other possibilities that will be immediately available are

• Auto sizing for more general combinations of solar and wind generation assets.
• Including other assets like flexible loads and EV charger in the auto-sizing process.
• Optimising for energy on-sell arrangements in addition to capex and opex.
• Auto sizing for more complicated value flows involving multiple participants.

Future additions we are working on and will hopefully add soon include

• Auto sizing for energy and/or emissions reduction in addition to financial targets.
• Auto sizing to take sites off grid as cheaply as possible.
• Differentiating between on-site and off-site assets while auto-sizing, e.g. for sizing off-site PPAs.