Expert Talk: Congestion management products or how to fish together in one single pond

There is currently a limited number of flexibility products explicitly designed for congestion management. As grid operators’ needs to manage congestion increase, new products should be developed in an orderly fashion to ensure enough liquidity in the markets for these products.

In 2020, the H2020 EU-Sysflex project indicated that they had not identified any congestion management product but that “resources earmarked for frequency control or voltage control are also being used by some TSOs for congestion management.” For example, in Belgium, aFRR is used to mitigate or manage congestion.[3]

There is, however, significant work in progress to cover this gap. An example is the harmonised products that can be used for congestion management developed in the H2020 OneNet project. The main differences between these products are presented in the table below:

This shows that corrective products are activated to address existing congestion while predictive products are activated as a result of forecast congestion in the network. The difference in the use of these products is reflected into the product attributes. For example, the time that passes from the SO activation request to the corresponding full delivery of concerned product (Full Activation Time) differs between products. Those products that are used to address congestion already in place or expected to arise during the operational timetable (i.e. corrective products as well as short-term predictive products) require a shorter FAT than those that are used to address long term issues (i.e. long-term predictive product). This is a reflection of the time gap the SO has when using these products.

Keeping the number of congestion management products low has advantages. With fewer products, it is easier to coordinate different SOs by, for example, facilitating the exchange of information on the flexibility being activated at different moments in time. Taking the Spanish system as an example, Red Electrica Española needs an information exchange platform linked to 5 large/medium size DSOs (i.e. Endesa, Iberdrola, Gas Natural-Fenosa, HC energy and Viesgo) and over 200 smaller distribution companies², This platform would need to account, as a minimum, for any difference in the definitions of the relevant attributes being used by the different SOs. Therefore, by reducing the number of products used by the SOs, these data exchanges can also be standardised. Furthermore, fewer products also facilitates the operations of FSPs operations across areas served by multiple SOs. These FSPs need to tailore their offers to the requirements of each SOs. Therefore, a smaller number of products across SOs simplifies their operations.

As a result, when considering the possibility of developing new congestion management products, stakeholders (i.e. SOs, Flexibility Services Provider (FSPs), regulators and policy markets) should consider whether any new product would overlap with existing flexibility products (i.e. whether it is efficient to take solutions like the case in Belgium where aFRR is used for congestion management). Furthermore, when different products need to be developed, these stakeholders should consider also whether harmonisation is required or even advisable once that it could reduce the potential for innovation.

When harmonising products, the first question is: what is being harmonised? To define flexibility products, two main components can be harmonised: the definition of the attributes the SO uses (e.g. what the SO understands as FAT) and the values the SO requires from the FSP when delivering this product (e.g. maximum FAT being less than 15 minutes).

The second question is how far should the harmonisation process go. Harmonisation is a spectrum that goes from reducing the differences among the definitions of the different attributes of a product to the full standardisation of the product where all attributes are equally defined and for which there is one single value.

Harmonised congestion management products are studied, for example, in the H2020 OneNet project as well as the H2020 CoordiNet project[4]. In those projects, the attributes and some values of the products are standardised. However, the values of other attributes are still left for SOs to decide. As a result, two SOs could develop “Predictive short term local active products” with different FAT while being below 60 minutes.

To decide how far harmonisation should go, policymakers and SOs need to consider both the benefits and costs of bypassing any barrier to harmonisation.

The key benefits of congestion management products harmonisation are facilitating the coordination between SOs. When considering the potential costs of harmonisation, there are important points both SOs and regulators need to consider when evaluating the potential of harmonisation:

• barriers can make harmonisation limited or even unfeasible – Examples of such barriers are differences in the technical requirements of the network, different approaches to the grid management by the SOs or differences in knowledge on best congestion management in their network. Some of the barriers can be bypassed at a reasonable cost (e.g. by investing in knowledge on future network needs) but bypassing others will have prohibitively high costs (e.g. a need to rebuild the network to a new standard) limiting the harmonisation potential.
• barriers to product harmonisation can vary from case to case and from SO to SO – the harmonisation potential is case-specific and solutions cannot simply be copied from previous experiences. For example, when comparing the Spanish and German market structures both countries have over 200 DSOs. However, while in Spain most consumers are served by 2 very large (more than 10 million customers each) and 3 medium companies (over half a million customer each), Germany’s DSOs are smaller (with only one company surpassing the 4 million consumers)[5]. As a result, solutions that could work in Spain would not necessarily work in Germany.
• the cost of harmonisation can vary over time – product harmonisation is a process instead of a one-off exercise. For example, when the barrier comes from differences in knowledge on congestion management requirements, SOs knowledge would improve over time which would make harmonisation less costly. Therefore, even if harmonisation cannot take place at this moment, it should not be precluded to happen in the future. Furthermore, when possible, the process of harmonisation should set as part of a roadmap to facilitate the management of expectations of the different stakeholders.

After careful consideration (and when possible quantification) of costs and benefits, it is possible to determine the desired degree of harmonisation of congestion management flexibility products between themselves and with other flexibility products. Once products are defined, the most efficient way of procuring them is the next step.

To mitigate the risks that some flexibility is not made available for SOs due to, for example, restrictive attributes (e.g. minimum size required to bid in the market) or characteristics of the markets for congestion management products (e.g. market operating monthly partially excluding wind and solar energies), flexibility supermarkets are introduced. H2020 projects EU-Sysflex and OneNet proposed the option where FSPs would only be required to publish some pre-determined information (e.g. capacity, location, prices) and the SOs use the information to choose those flexibility sources that best match their needs.

However, also less extreme options are considered. In one of them, a supermarket approach would be one where the FSP still needs to comply with pre-set values for some of the attributes but it does not need to comply with requirements for others.

To illustrate the approach, we consider one of the products in the Northern demo of the H2020 OneNet project: “Near Real Time Active Energy”. [9] The product is built on the specification of the mFRR product but it is also used for congestion management. To achieve this, FSPs would need to provide the required information for mFRR in addition to location information.

Therefore, under the current approach of mFRR markets, FSPs would be required to comply with the attributes of an mFRR product as well as include the location of their flexibility. However, this product could also be operated as a supermarket where FSPs choose whether to provide locational information. When an FSP does not provide locational information, its flexibility will only be considered for congestion management.

A supermarket approach would have advantages and drawbacks over the current situation. The table below presents the most relevant but more are available in [9]:

One potential way to mitigate some of the disadvantages in that table is to create a flexibility supermarket that runs in parallel to some of the current markets. Following the example above, FSPs would be able to choose between offering flexibility in the market for a “Near Real Time Active Energy” product or a flexibility supermarket for active power. This would facilitate that the SO has access to a larger amount of flexibility as those FSPs that cannot comply with the requirements of this product would still be able to offer their flexibility in the supermarket.