Expert Talk: Congestion management products or how to fish together in one single pond
In recent years, the need to manage congestion in electricity networks has gone hand in hand with the growth of renewable (distributed) generation as well an increase in demand due to, for example, electrification of transport and heating. Examples of congestion problems1 have been identified in a number of European countries. An example is Germany where there has been a growing need to curtail renewable (wind) generators as the networks act as a bottleneck to the full use of these energy sources [1] due to lack of capacity in the transmission network. At a DSO level, an interesting example can be found in the Schipol Trade Park in the Netherlands [2] where a virtual grid has been created to mitigate congestion problems.
Different solutions are being considered to manage congestion. This paper focuses on one of them: the development of flexibility products System Operators (SOs) can use to provide efficient and stable grid operation. This paper discusses the possibility to integrate different congestion management products among themselves and with other flexibility products. The challenges for efficient procurement of flexibility for congestion management are also discussed.
This Expert Talk was written by Fernando Dominguez Iniguez, Senior Researcher Energy Markets at EnergyVille/VITO.
Congestion Management Products
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 companies2, 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.
Harmonisation of congestion management products: When and how?
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.
Integrating congestion management products inside the current flexibility market
To ensure congestion is managed efficiently, SOs not only need to define their flexibility products effectively but they also need to procure them efficiently. To ensure this efficiency, SOs need to consider that any markets aimed at procurement of such products interact with the operations of other implicit and explicit markets (e.g. dynamic tariffs aimed at acquiring flexibility from low voltage connections).
These interactions, however, will be case-specific and overarching results are difficult to develop. Examples of studies are:
- H2020 EU-Sysflex project – this paper considers interactions between markets for flexibility products (in that case mFRR) and the day ahead markets. [6] showed that increased procurement frequency of mFRR daily facilitated the participation of RES. These technologies find it difficult to forecast their generation output in advance. Therefore, they will find it easier to participate in an mFRR market that is run closer to real-time. Furthermore, as more technologies can choose between participating in a day ahead and the mFRR markets, the difference in prices between these markets is reduced also.
- H2020 EUniversal project – [7] undertakes a qualitative analysis of the interactions between flexibility and implicit markets such as dynamic tariffs. This project identifies that the interactions should be considered on a case-by-case bases as the effect depends on the product being procured and the specific type of implicit and explicit market under consideration.
- Stawska et al – [8] considers some congestion management mechanisms and their impact on trading in the imbalance markets. It finds that some congestion management mechanisms (including flexibility markets) can provide sufficient incentives to prevent congestion. However, none of them is optimal under all circumstances. Flexibility markets may address congestion but they can have misplaced incentives one of which is that “selling power to the [congestion management] market means that an aggregator has to give up potential profit on the imbalance market. Hence, the DSO has to set the flexibility price high enough to compete with the imbalance market while in fact it could be that both DSO and TSO aim for the same consumer behavior.”
Therefore, when developing a market for congestion management products, SOs must consider the interactions they would have with other markets (implicit and explicit) as it could significantly affect the overall efficiency of the markets.
Actually…do we need products? The supermarket approach
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.
Recommendations
TSOs and DSOs need to avoid a fragmented set of flexibility products to facilitate the coordination of the operations as well as to ensure that the available flexibility does not spread too thin between markets. Therefore, they need to evaluate whether other products (with some limited modifications) could provide those system services.
Furthermore, to ensure their efficient procurement, SOs also need to consider the interactions between the explicit and any implicit flexibility mechanisms. Therefore, when considering these products, they will need to model interactions to ensure the system efficiency.
Finally, it is important to ensure that SOs have access to all flexibility available in the system. One system where a supermarket approach is proposed that could be combined with some products to facilitate the SO access to the necessary flexibility.
Footnote
1 With congestion being defined as any network situation where forecasted or realised power flows violate the thermal limits of the elements of the grid and voltage stability or the angle stability limits of the power system.
2 For a full list of the Spanish DSOs see https://www.eudsoentity.eu/registered-organisations/
References
[1] Bundesnetzagentur, “Monitoringbericht 2020 der Bundesnetzagentur und des Bundeskartellamtes,” no. Vcd. p. 730730, 2021.
[2] “No Title,” [Online]. Available: https://www.sadc.nl/eerste-bedrijven-schiphol-trade-park-aangesloten-op….
[3] EU-SysFlex, “Product definition for innovative system services,” p. 96, 2019, [Online]. Available: https://eu-sysflex.com/.
[4] K. Kessels, A. Delnooz, J. Vanschoenwinkel, E. Rivero, and C. Madina, “CoordiNet Deliverable D1.3: Definition of scenarios and products for the demonstration campaigns,” 2019. [Online]. Available: https://private.coordinet-project.eu//files/documentos/5d72415ced279Coo….
[5] “EU DSO Entity website.” https://www.eudsoentity.eu/registered-organisations/.
[6] EU-SysFlex Project, “EU-SysFlex Deliverable 3.4: Impact analysis of market and regulatory options through advanced power system and market modelling studies,” no. 773505, 2020, [Online]. Available: https://eu-sysflex.com/wp-content/uploads/2020/07/EU-SysFlex-D3.4-publi….
[7] EUniversal, “Deliverable: D5.1 Services, Identification of relevant market mechanisms for the procurement of flexibility needs and grid,” no. 864334, 2020.
[8] A. Stawska, N. Romero, M. de Weerdt, and R. Verzijlbergh, “Demand response: For congestion management or for grid balancing?,” Energy Policy, vol. 148, no. PA, p. 111920, 2021, doi: 10.1016/j.enpol.2020.111920.
[9] ONENET et al., “D2.2 – A set of standardised products for system services in the TSO- DSO-consumer value chain,” 2021.