Blog

The third pillar for a Net Zero Grid: A digital infrastructure

Return

In our blog series, we’ve so far established the need for an entity with a whole-system mandate, and an open ecosystem to support it. Now, we’re on to the final pillar: what we should consider when we develop and deploy the ecosystem approach through a digital infrastructure.  

The need for flexibility

This blog focusses on aspects of the What and How associated with future system arrangements and structure, specifically around flexibility. 

But, first, a reminder on the Why. The use of flexibility needs to scale, to help reach the government-set targets for decarbonising the energy system and to manage the increasing number of Low Carbon Technologies (LCTs) being connected. 

Our three pillars are key to achieving this. An entity with a whole system mandate can help push forward flexibility initiatives aligned around an overarching, strategic vision. An open ecosystem can help ensure a coordinated approach to encourage more participation in flex markets. Yet the underlying digital infrastructure – the topic of this blog – is the key to unlocking this scalability.

In the UK, National Grid ESO, as part of their most recent Future Energy Scenarios (FES) analysis, estimates that: “Demand Side Response from residential, industrial and commercial consumers reaches over 13 GW in Consumer Transformation [scenario] in 2050.” 

At Electron, we believe this needs a step change in how flexibility is accessed, and how price signals are used to encourage the uptake of flexible assets and LCTs. 

Again, in the UK, the Energy Networks Association (ENA) shared in August this year: “Electricity network companies tendered a record 4.6GW of capacity on Great Britain’s local flexibility markets last year, with 2GW contracted.” 

This represents a success rate of just over 43%. Figures will likely be considerably worse when looking at the flexibility activated. So, while this shows a strong need for flexibility, it also makes the gap between requirement and delivery startlingly clear. 

There’s a similar pattern across Europe. In July this year, the EU’s Joint Research Council (JRC) stated: “We observe the weekly flexibility requirements to increase by 160% between 2021 and 2030.”​ 

The need is therefore clear: 

  1. The industry must scale up the use of flexibility to enable a decarbonised energy system – a key part of achieving Net Zero.  
  1. The end consumer needs to access the potential benefits associated with the energy transition, specifically around the reward for being flexible. 

The building blocks of an open ecosystem 

In the previous blog, we talked at a high-level about what an ecosystem looks like versus a monolithic architecture. We also discussed the benefits of this in allowing best-in-class solutions at each step. 

An ecosystem enables the optimal solution by driving competition and improvement within some of these steps. It then links up all the platforms and processes that are relevant within a whole-systems approach. Competition is provided by a variety of third-party vendors. These specialise in individual parts of the workflow and are dedicated to improving and supporting those parts over time.  

This competitive landscape of digital platforms sits alongside existing systems. These are tailored to a given market participant, to perform key functions and processes for that actor. For example, system operators will have existing, well-functioning platforms for provider registration, and existing embedded network control and monitoring systems. 

So, how do we tie these together into a cohesive, open ecosystem?  

A digital infrastructure to meet uncertain and evolving needs 

The evolving nature of the flexibility landscape means uncertain requirements for platforms and systems across the end-to-end workflow.  

This is inescapable, but we can develop systems to account for it. It’s not realistic to spec out and deliver a platform in a waterfall manner to capture today and tomorrow’s requirements. Even if it were possible, it couldn’t be delivered within the timeframe to meet Net Zero targets.  

Instead, those systems and platforms should be built in a more agile manner, with ‘extensibility’ in mind. That means a design that allows the addition of new capabilities or functionality as they become apparent.  

An example of this comes from National Grid ESO’s Open Balancing Platform (or OBP). At a high-level, this is designed:

  • to allow multiple services to co-exist
  • for future services to ‘plug’ into the platform
  • to promote ‘competition everywhere’, to enable that optimal overall solution

Achieving agility within the software architecture of individual platforms

The first step is to consider what each grouping of functionality within the software architecture is for i.e. what it allows the platform to do. A common way to conceptualise this is via reference to layers, as outlined in figure 1. 

Figure 1: A layered approach to software architecture. 
  1. The data layer represents the data flows in and out of the platform. 
  2. The platform layer, where cross-market functionality supports the operation and coordination of flexibility markets. 
  3. The business layer, where the logic associated with markets and market products is specified. 
  4. The presentation layer is where end users interact with the platform. It includes not only operation of the market, but data insights and reporting as well. 

Data is transferred between these layers to support the running of one or more markets on the platform. Access control can be implemented between layers. For example, there can be control over both the operations a given user can undertake and the data they can access. 

For the future, the layer that’s affected, and how it impacts the other layers can be considered. This could be an additional market design configured onto the business layer – or a network data feed that supports coordination across multiple markets. 

At Electron, we build software in a modular manner where discrete groups of functionalities are provided and can be configured in different ways. The easy analogy is to Lego bricks. The core functions are present (groups of brick types) and can be configured to support e.g. a new market or additional reporting requirements.  

Standardisation in the right places 

The process of standardisation can both promote or inhibit an open ecosystem and its digital infrastructure. The key point is to understand why something should be standardised and what that standardisation allows. 

The correct approach is not to aim for universal standardisation – which in its extreme would be the opposite of an ecosystem. Instead, standardisation should focus on where it provides benefits to the system and the various actors within that system.

For example, the ENA recently worked on a way to standardise the Pre-Qualification Questionnaire (PQQ) and service agreement. This is essentially how a flexibility provider gains access to a market product.  

This work didn’t aim to define a single overarching platform for registration. Rather, the PQQ specifies the fields that should be captured across system operators who are deploying DSO flexibility services on any market platform.  

Each system operator can build and deploy their own registration portal to their own requirements, to suit their individual needs. The experience for the provider is therefore more uniform in terms of what is being asked of them. This directly feeds into the ecosystem concept, with multiple registration platforms, yet one ‘ask’ for the provider organisation. 

Data use cases  

When we talk about an ecosystem, we implicitly talk about the flow of data between platforms and between users of those platforms. In turn, when we talk about data flows, we must start by considering data use cases. Specifically, this means Why are we sharing the data, and what do we unlock by sharing it.  

Let’s look at two examples to demonstrate the concept of data use cases: one for the system operators and one for the flexibility providers: 

– Visibility of opportunities for providers

Poor visibility over provider opportunities can be a reason it’s difficult to scale flexibility. Often those opportunities are hosted on various market platforms and systems, in the places best suited to host them.

As per the ecosystem approach, the answer is not to attempt to host all markets on a single monolithic platform, but rather to surface the data regarding those opportunities to flexibility providers in a consistent manner – no matter what market platform hosts those opportunities. 

– Systems integrations  

The second point to consider is how we bring flexibility market actions closer to system needs. It sounds simple, but it’s often not the case in practice. For example, nation-wide demand turn down requested in locations and at times of high wind penetration (leading to potentially increased levels of curtailment of wind generation), or the ‘herding’ seen in EV charging profiles driven by time-of-use tariffs.

The answer is to consider what data can be used to support a flexibility event: the time, location, and volume needed. This can come directly from the network systems data feed directly into the flexibility market platform, but does not typically happen today.  

The next steps

The shift to an ecosystem approach built on a digital infrastructure has already begun. 

Organisations are already recognising the well-documented benefits of distributed systems over monolithic architectures (for example the OBP roadmap).

Standardisation is already taking hold of parts of the workflow that open up the markets for providers. Work has also begun on the mechanism to facilitate data sharing – including the ongoing work on the Digital Sharing Infrastructure (formerly known as the Digital Spine). 

The digital infrastructure underlying the ecosystem is therefore starting to take shape.

Electron has recently been selected to participate in phase 1 of the Department of Energy Security and Net Zero (DESNZ) Flexibility Unlocked program. We’ll be considering and engaging on many aspects of enabling the ecosystem approach, from how data is shared, and why, to how we can lower entry barriers to flexibility markets – no matter where they’re hosted. 

There’s still plenty of work to be done to establish the three pillars for a Net Zero grid through a neutral flexibility marketplace: the digital infrastructure, the open ecosystem, and an entity with a whole system mandate. We therefore need to keep focus on the initiatives already in flight, build on those, and collaborate on new initiatives to fully unlock an optimised, Net Zero grid. 

We’re interested to learn how you see these neutral marketplaces coming into effect in your regions. Please reach out to discuss these concepts further – book a chat.

Right Arrow Down Arrow List Tick Left Arrow