Skip to main content

De Asset Orchestrator: waarom de beste keuze per asset niet altijd de beste is voor je hele site

The smartest call for one asset is not always the smartest call for your site. Sometimes it actively costs money. A battery strategy that optimally discharges on peak prices can push your site over the throttle limit together with your wind turbine. A solar strategy that keeps producing at full power can be loss-making when export costs exceed the market price.

The Asset Orchestrator solves this. Every minute, it decides what every controllable asset on your site should do. It collects advice from each asset's individual strategy and then makes the decision that's optimal for the whole site.

This article focuses on the imbalance orchestrator specifically. We also run separate orchestrators for the day-ahead and intraday markets, using the same logic.

How a site is organised

Every site we manage has three levels:

  • Location: a physical place, like a farm or industrial site.
  • EAN: an energy connection to the grid. A location can have several EANs.
  • Assets: solar panels, wind turbines, batteries, or consumption meters. Each EAN holds one or more.

The orchestrator works across all of these at the same time, not one by one.

What can actually be steered?

Not every asset can be steered, and it doesn't need to be.

Batteries are always controllable: we send them a power setpoint every minute. Solar and wind are usually controllable too (we can curtail them when the market requires it), but some installations are unsteerable. Consumption is never controllable.

That doesn't mean unsteerable assets fall out of the picture. Assets that can't be adjusted, like unsteerable solar, wind, or consumption, still send real-time data to the orchestrator: how much they produce, how much they consume, and how that's expected to develop. That information feeds into every decision. An unsteerable solar park producing 200 kW directly determines how much room is left under the throttle limit for the battery next to it.

Unsteerable assets are therefore not a blind spot for the orchestrator. Their data informs the decisions we make for the controllable assets next to them.

How it works: two steps, every minute

Step 1. Each asset gives advice

Every controllable asset has its own strategy. It looks at imbalance prices, the day-ahead nominations we already submitted, weather forecasts, and production predictions. Based on that, the strategy gives a recommendation: for a battery, a power setpoint; for solar or wind, whether to curtail or keep producing.

The strategy only sees its own asset. It does not know what the other assets on the site are doing.

Step 2. The orchestrator makes the call

Once all the advice is in, the orchestrator combines it with four site-level constraints. Sometimes it follows the strategies exactly. Sometimes it overrides one or more, because the right answer for the whole site is sometimes different from the right answer for one asset.

Four factors at site level

On top of the strategy advice, the orchestrator always weighs four additional factors. Two at EAN level, two at location level:

  • Energy supplier costs (EAN level): for example, export costs that can flip a profitable-looking dispatch decision negative.
  • Energy tax (EAN level): taxes that determine whether injecting or drawing from the grid is the optimal call.
  • Transport costs (location level): variable grid transport costs shared across all EANs at the site.
  • Throttle limits (location level): the maximum contracted power. Combined dispatch from all assets can never exceed this.

A decision that looks optimal for a single asset may look very different once you add the supplier costs on that EAN, or the transport costs shared across the whole location. The orchestrator accounts for all four at once.

Three examples from practice

The scenarios below show what the orchestrator does, and why, when it deviates from what a single strategy would recommend.

Example 1: Solar and consumption on the same EAN

A rooftop solar installation and an office building are on the same EAN. The solar strategy says: keep producing. But the market price is €0.10/MWh, while the energy supplier's export cost is €0.20/MWh.

The orchestrator curtails the solar, even though the strategy says not to.

Exporting earns €0.10 but costs €0.20. The net result is negative. The strategy couldn't see this, because it only looks at its own asset. The orchestrator checks the full EAN position. If the consumption absorbs the production locally, nothing is exported and the cost disappears. If not, curtailing is the right call.

Example 2: Wind and battery hitting the throttle limit

A 600 kW wind turbine and a battery are at the same location, with a throttle limit of 800 kW. Prices spike. The wind strategy says: produce at full 600 kW. The battery strategy says: discharge at 500 kW. Combined, that's 1,100 kW, or 300 kW over the limit.

The orchestrator caps the battery discharge at 200 kW and keeps wind at full production.

Why? Wind is free energy. Curtailing it means losing guaranteed revenue. Reducing battery discharge costs nothing: the energy stays stored for later. The orchestrator picks the cheapest output to lose and stays within the 800 kW limit. Neither strategy could have solved this conflict alone, because neither knew what the other was doing.

Example 3: Solar and battery during regulation state 2

Regulation state 2 is active, meaning imbalance is costly. Both strategies want to fall back to zero individually. That's the safe call at asset level. But the solar field earns SDE subsidy per MWh. Shutting it down means throwing that revenue away unnecessarily.

The orchestrator keeps the solar producing. The battery charges to absorb the output. The EAN-level position stays at zero. No imbalance penalty. The solar keeps earning its subsidy. The battery stores the energy for later.

We can make this call because we are the energy supplier and BRP ourselves. We see the nominations. We know the EAN-level imbalance position. The algorithm just weighs it in.