WECL-PT-01

1. Description of the Use Case

1.1. Name of the Use Case

1.2. Version Management

1.3. Scope and Objectives of Use Case

1.4. Narrative of Use Case

Short description

Flexible resources connected to transmission and distribution system can provide flexibility to system operators to eliminate congestions through a market mechanism. This BUC in transmission and/or distribution system, in order to keep power flows within the accepted thermal limits of the lines. These information exchanges of information mechanisms should be adaptable to any future market model or governance issues. Some different time frame markets will be examined: • Day Ahead • Intraday For each time frame, we will approach some of the following process phases of ASM report:

• Prepare/Pre-qualification: The process in which it is checked whether a unit can deliver the product it intends to sell, taking into account the network conditions.
• Plan/Forecast: Planning of grid utilization and identifying potential congestions.
• Market Phase: Bids collection and selection, short-term contracts (capacity products) and short-term products/services (selection of energy products)
• Monitoring and Activation: Grid monitoring and flexibility bids activation to solve the forecasted congestion management
• Measurement and Settlement phase: Validation of delivery Some of the above process phases may be similar for both time frames. In this Business Use Case, the measurement and settlement phase will not be addressed. The developed information exchange mechanisms will be implemented in order to have a verification process.

Complete description

Flexible resources connected to transmission and distribution system can provide flexibility to system operators to eliminate congestions through a market mechanism. This BUC describes the exchanges of information and the processes that should be established for different scenarios: pre-qualification, plan/forecast, market phase and monitoring and activation phase. For each scenario, we will always take into account different timeframes (intraday and day-ahead) and how they are related. Pre-qualification The pre-qualification process should start after a flexibility service provider expresses interest in entering the flexibility market. This process serves to ensure that a particular flexibility service provider is capable of delivering a given product. In order to do that, two types of pre-qualification should be considered: Product Pre-qualification and Grid Pre-qualification. The former ensures that the resource contains the technical requirements to be able to deliver the product and proceed to the market phase and eventually selected by a system operator. These technical requirements are defined by DSO and TSO and after the FSP indicates the attributes of the product it wants to deliver, a pre-qualification test should be performed to verify that all attributes are in compliance with the technical requirements. This test may be repeated on a periodic basis or whenever the characteristics of the product are found to change significantly. The product pre-qualification can be done either by the DSO or TSO, regardless of its location. In case a system operator wants to activate a product already pre-qualified by another system operator, the former should have access to this information in order to make the process more efficient and not to pre-qualify the same product twice. Regarding grid pre-qualification, this process ensures that the product provided by the Flexible Service Provider will not cause constraints in the networks where it is connected. This process can be avoided if the System Operators have already identified the areas where flexibility is always allowed. The grid pre-qualification should be performed by the System Operator of the network to which the product is connected in order to verify if the maximum capacity of the product does not impact the network it is connected to. If the results of the two types of pre-qualification are approved, the entry of the FSP into the flexibility market is allowed. The Pre-qualification scenario is independent of the time-frame, since it is a process that happens before the market phase. Plan/Forecast In this phase the System Operators take into account the utilization of their grid. Based on forecasts the Systems Operators checks the power flows to detect whether or not there will be possible congestion in the network. In case the grid capacity is insufficient to meet the forecasted electricity production or consumption, System Operators may resort to the flexibility market to resolve this type of issue. This phase is done for two different timeframes, day-ahead and intraday. On the one hand, the day-ahead forecasts are made for D-1. On the other hand, the intraday forecasts are made every 4 hours in order to improve the accuracy of the predicted flow of electricity that were made for the day-ahead. The objectives of this phase are to identify possible congestions in the network and to support the procurement in the flexibility markets. Market Phase The market phase starts after the system operators forecast network congestion. In this phase, the system operators are focused on collecting and selecting bids from FSPs. These bids can be in the day-ahead market, which occurs on D-1, in the intraday market, which occurs already inside D every 4 hours, or they can come from the long-term market (BUC-2). The intraday market is a complement to the day-ahead market. The possible failures or unforeseen events that were not covered in the day-ahead should be corrected in the intraday market. In the bid selection process, the SO should pay attention to whether the bid is located in its own network, or in another network. In the latter case, the SO should consult the SO where the bid is located so it can evaluate the constraints that may arise if the bid is accepted and activated. After this phase, the need arises to sort the accepted bids by a merit order list. This Business Use Case will address a multi-level market model. Monitoring and Activation This phase occurs after the list of bids sorted by a merit order is defined. The SO selects the bid it wants to activate, if the bid is located in the network of another SO, the latter should be consulted to validate the activation of this bid. If the SO’s need is not resolved this process is repeated iteratively until the SO needs are solved.

1.5. Key Performance Indicatiors (KPI)

1.6. Use case conditions

1.7. Further information to the use case for classification/mapping

1.8. General remarks

2. Diagrams of Use Case

3. Technical Details

3.1. Actors

3.2. References

4. Step by Step Analysis of Use Case

4.1. Overview of Scenarios

Notes

4.2. Steps – Scenarios

5. Information Exchanged

6. Requirements (optional)

7. Common Terms and Definitions

8. Custom Information (optional)