The questions posed after talks at events are always telling. They often address the wider challenges that the industry is facing around particular topics, such as the deployment of energy flexibility at scale through flexibility market platforms, like ElectronConnect.
At Flexcon 2024, our CCO, Chris Broadhurst, spoke on the role of flexibility alongside electricity network expansion. You can read more on this topic in our blog.
Nick Huntbatch, our Chief Product Officer, delivered a talk delving into how UK distribution system operators (DSOs) are taking flex market platforms to the next level. You can watch his presentation below – and read on for his answers to the questions he was asked at the event.
Read on for the top questions our two Electron speakers answered at Flexcon, from the challenges of data validation to market rules.
The five questions answered:
- What information does the flexibility system need to ensure reliability so networks can trust that they can delay grid reinforcement?
- How do you see interconnections between platforms developing?
- What is the biggest challenge you see when it comes to data validation in market platforms?
- How do you see baselining and reference profiles in the world of flex evolving in the UK?
- Where should market rules come from – the platforms or the DSOs? And can they be reused across DSOs?
What information does the flexibility system need to ensure reliability so networks can trust that they can delay grid reinforcement?
Chris Broadhurst: As the need for flexibility grows, markets can be used to build that trust. You can’t push a button or turn a dial to control distributed energy resources (DERs) in the same way you can a traditional generation asset.
However, you can – using the real-world data from providers responding to locational price signals – build up a reliable and predictable model for how the market will behave.
This market data can factor in asset performance, reliability of providers, carbon impact, network impact, and so on.
How do you see interconnections between platforms developing?
Chris: This is all about reducing friction and barriers to entry for flexibility providers. There are two approaches.
You can build a central data repository: a centrally owned/operated database of assets and/or provider organisations. This is an idea being actively discussed in both the UK and Europe. Whilst that’s a good ambition, it can be difficult to capture all data, particularly when that dataset will be growing and changing rapidly.
The other consideration we think is important is the fact that the data is already held in various places today. We therefore advocate for a more pragmatic approach – building the APIs, the standards, the governance, and trust frameworks, so that the existing data can more easily moved between platforms.
Our work with the UK’s Department for Energy Security and Net Zero (DESNZ) Flex Markets Unlocked project, in partnership with Arup, Energy Systems Catapult, and others, is a perfect example of this. The initiative will build a Universal Market Register (UMR), along with the necessary standards and primacy rules.
This will make it easier for flexibility service providers (FSPs) to participate in markets across platforms, without needing to re-enter registration details each time. The UMR will be developed with an open-ecosystem approach in mind, enabling that easy transfer of data without it needing to be held in a single, central space.
What is the biggest challenge you see when it comes to data validation in market platforms?
Nick Huntbatch: That’s difficult to answer; there are so many different types of data that we need.
For example, for the registration of asset information or network or meter data, we have a technical qualification standard in the UK . This has set, allowable responses in a certain format, that makes it easier as a platform provider.
Yet, this will be a challenge going forward. Meter data is an interesting topic. In the UK, we haven’t got to the point of defining what the meter data should look like, what format it should be, how it should be validated.
Active network management systems are also being rolled out in parallel with the market so we’re collecting data and learning as we go.
The key point is to not set a standard for a certain data set that can’t be updated. That allows platforms to take on learnings and then update standards – or define the standard in the first place.
Once you have that standard – based on learnings – you can start to have a consistent validation.
How do you see baselining and reference profiles in the world of flex evolving in the UK?
Nick: The Energy Networks Association (ENA) has standards in place outlining historic baselining and nomination baselining which we can follow.
However, while flexibility is becoming more common or “business as usual”, every technology type will behave differently.
We’re trying to set up the platform so that we’re not locked into any particular baseline methodology. That means that, per trade and technology type, the baseline is appropriate, and it can be ported in. Every trade that we do can have its own baseline if needed.
Where should market rules come from – the platforms or the DSOs? And can they be reused across DSOs?
Nick: The ENA has five standard market products – but they’re not massively prescriptive. It’s a general framework, including availability and utilisation payments as well as scheduled or operational utilisation. Read more about the standard products in our blog.
The DSOs in the UK signed up to that through the ENA, agreeing to deploy those products. However, the products give us scope to adapt, because it doesn’t say the market has to run six months ahead or day ahead. Market timing is therefore an aspect that can be tailored to flexibility provider needs.
However, some standards are more top down. For example, the technical Pre-Qualification Questionnaire (PPQ), which leaves less room to adapt to provider needs.
So, there’s therefore work to be done there. When we agree to a set of market parameters that everyone’s going to deploy, there should be some mechanism to apply learnings, to help refine them.
