7 Design Challenges in Behind-The-Meter Orchestration
Nicolas Höning, Co-Founder at Seita Energy Flexibility and Maintainer, LF Energy FlexMeasures
Managing energy “behind-the-meter” (BTM) offers significant benefits. Especially as modern electricity grids face congestion, as well as fluctuating prices and incentives.
Everybody easily agrees with the idea that solar energy, EV charging, batteries, and heat pumps should work together like an orchestra to avoid peaks and reduce costs. However, if your task is to implement such BTM orchestration, you’ll find it is complex. Whether you’re an installer, EMS vendor, or building facility manager, prioritizing what to focus on is crucial.
The open source FlexMeasures community has identified seven key challenges in this area, which we will explore below.
Figure 1: How AI envisions Behind-the-Meter orchestration
1. What is Behind-The-Meter Orchestration?
Behind-the-meter (BTM) orchestration focuses on using flexible energy assets on-site. New energy installations require a “value-stacking” approach to produce a positive business case. Behind the meter, this can involve:
- Increased (solar) self-consumption
- Peak reduction to lower DSO/network costs
- Tax rebates through renewable certificates
- Reducing procurement costs with regard to dynamic tariffs
- DSO/network support
The latter two items blur the lines somewhat, as they optimize based on grid state. Crucially, while before-the-meter approaches focus on the perspective of aggregators and utilities, BTM orchestration means paying attention to details of complex sites and prioritizes their perspectives. Many projects stall due to unclear expectations of what an Energy Management System (EMS) should achieve in a BTM context.
The BTM orchestration challenge is exciting and globally relevant, offering a $4 trillion opportunity. Solutions can scale worldwide, despite market differences. Electrification in sectors like e-mobility and heating/cooling expands the impact of BTM optimization. By focusing on BTM, products can be designed to support the entire project lifetime, from design to operation.
2. The design challenges
Figure 2: The 7 design challenges, summarized
Challenge 1: What stack level are you best at?
BTM orchestration requires a multi-level approach. Here are three functions that directly impact how the orchestration happens:
1. On-site EMS or Gateway
Somebody has to be able to talk to the assets and tell them what to do and when. This often needs a local PC/gateway and integration with brands of inverters, batteries, EV chargers, and heat pumps. Such an on-site EMS should also react fast.
2. Cloud EMS
Higher value from orchestration is possible when you know how the song will continue. Planning ahead, based on forecasts of consumption and weather, as well as prices and other data, is the game of a cloud EMS.
3. Market access
The value stacking usually does need to continue across solar self-consumption and dynamic tariffs. An advanced BTM orchestra can react to opportunities from outside, e.g., to help grid congestion (like in an imbalance market).
Figure 3: Multiple stakeholders are involved in BTM orchestration
Challenge 2: What do you offer, and to whom?
Given these three layers, I posit that it is very hard to be great at all three of them, even if you raise loads of VC capital. They all require serious expertise.
Are you a one-stop shop or a specialist?
And if you are a one-stop shop for end customers, are you implementing all three layers (are you Octopus Energy?) or will you find the right partners?
If you are a specialist, you might like the role of being a partner for a one-stop shop. Or you integrate with other upstream specialists ― for instance, at Seita, our cloud EMS can be the smart backend for gateway makers, who offer it to installers.
Challenge 3: What is your optimization scope?
Optimizing energy usage involves competing goals and requires a two-step approach. First, select the level of optimization:
- Device-level (e.g., an EV or heat pump) aims for usage-specific goals like reaching a target charge or ensuring comfort.
- Site-level (e.g., a building) focuses on staying within capacity limits, maximizing solar power use, and reducing energy costs.
- Fleet-level aims to shape the aggregated energy curve to a desired profile.
This results in varying numbers of goals: one for device-level, x+3 for site-level (where x is the number of devices), and x+3+1 for fleet-level.
Second, rank these goals. Since optimizing all simultaneously is challenging, prioritize them. Consider this example from EV charging: with a limited grid connection, the primary goal is to avoid breaching capacity. However, fairness in charging each vehicle is also crucial. Without considering fairness, some vehicles may bear the brunt of the limitations. A well-rounded model ensures a more even distribution of energy among all vehicles.
Challenge 4: Sector and commodity scope
But wait, there are more competing issues behind the meter!
These sectors, traditionally independent, are now interconnected through electrification (e.g., EVs, heat pumps, etc.), competing for shared resources like grid capacity, local solar power, and low-market price periods. This interconnection is known as sector coupling.
Another key concept is multi-commodity management. Even as the energy system shifts towards all-electric, other energy forms remain crucial. Examples include heat stored in hot water and the use of gas as an input source.
I believe the choice is to focus on simplicity or tackle these hard issues head-on. For instance, only working on smart charging gives you fast time to market. However, as more of your customers’ devices are electrified, you might start to compete with other EMS vendors who also operate behind the same meters. The missed opportunity: orchestrating the whole picture of the customer’s energy contract.
Challenge 5: Design or operation?
Which moment in your energy project’s lifetime is more crucial ― when you decide which assets to buy (design), or when you start running them optimally (operation)?
One is more of a CapEx question (sizing), and the other determines OpEx (running) – both are crucial for your business case.
It also defines the nature of what you do. When you are sizing assets, you are doing analytics and scenario building, which quickly turns to consultancy. When you are actually optimizing assets in real time, you are mixing APIs, data pipelines, and machine learning.
Aim to do both? You might overstretch.
Aim for only one of the two? The customers will need to work with two parties, and there will be switching costs.
Figure 4: Each BTM project has phases, and will even cycle through them
Challenge 6: How fast and understandable is your business logic?
Words are cheap. You are free to label your energy orchestration solution as “smart”, “AI-powered” or whatever you like. What you implement is likely one of these:
- Business rules ― In essence, these are if-else constructs. Fast and robust, and the correct choice for an on-site EMS. Limited in more complex settings (see above) and for planning ahead.
- Algorithm ― Code that is designed to find an optimal solution in a vast search space of possibilities. Could be linear programs (from operations research), dynamic programming, or other. It might take some time to compute a solution, but you can debug what it does.
- Deep learning ― Currently the cool kid on the block. Train a model from a vast amount of input data and optimal outcomes and deploy it. Gives you really fast responses, but managing training and especially finding the right training data might be tough.
Challenge 7: Do you have an open innovation approach?
Solutions in the modern energy world are usually not one-stop shops (see challenge 2), and even those need to integrate with a lot of others. Open innovation approaches make your technology stack more resilient against the high rate of change and creates trust among your stakeholders through transparency.
Of course, you still want to create USPs, moats, and so on. You can still do that while you consider one or more of the following:
- Do you use a known algorithm? Maybe based on academic papers? Can you explain it, or is it magic (see Challenge 6)?
- Are you ensuring interoperability by using open protocols (e.g., OpenADR, Matter, EEBus, S2, modbus, etc)?
- Does your API allow customers to get their own data to work with outside of your system?
- Are you creating vendor lock-in, or do you embrace an open source strategy
3. An open, cloud-based approach
Hopefully, this list helps creators in the exciting world of new energy appliances and renewable energy to consider strategic choices. Behind-the-meter orchestration is an exciting concept, and I’m curious to learn how others will position their approaches.
To close with an example: At Seita Energy Flexibility, we have opted for a Cloud EMS (software-only) approach. We focus on site optimization, employing linear programming. It is generic enough to allow us to model the flexibility across sectors and also some other commodities, as well as different DSO/utility demands. We use both a simulation engine (design) and real-time EMS (operation). We have open-sourced the underlying FlexMeasures platform (with LF Energy), and also are spending efforts on implementing open protocols like S2 and OpenADR.
Figure 5: The design choices we have made at Seita Energy Flexibility
