WECL-ES-01
Long-term congestion management
1. Description of the Use Case
1.1. Name of the Use Case
ID | Area /Domain(s)/Zone(s) | Name of the Use Case |
---|
1 | Local congestion management, | WECL-ES-01 |
1.2. Version Management
Version No. | Date | Name of author(s) | Changes | Approval status |
---|
0.3 | 2021-06-26T00:00:00 | COMILLAS, i-DE, UFD, OMIE, | Up to section 5 | None |
1.3. Scope and Objectives of Use Case
| |
---|
Scope | This BUC is focused on the long term procurement of congestion management products by the DSO. The main objective of the BUC is to ensure that the DSO can procure flexibility in advance to solve specific local system loading issues on the distribution system thus deferring/eliminating the need for traditional system upgrades |
Objective(s) | 1. To apply market procedures to obtain flexibility services attending DSO requirements. |
2. Demonstrate that long term agreements are suitable amongst different available DERs | |
3. Implement flexibility provision/usage through a market platform. | |
4. Use consumer’s demand-response in efficient flexibility services. | |
Related business case(s) | WECL-ES-02, SUC-ES-01 |
1.4. Narrative of Use Case
Short description
This BUC describes the DSO long term procurement of flexibility services through a market mechanism to avoid congestions at the distribution medium or low voltage networks.
It describes the exchange of information and processes that should be established between DSO, Independent Market Operator (IMO) and Flexibility Provider (FSP). This BUC is divided into five scenarios, namely the five service steps defined in the Active System Management (ASM) report [1] listed below:
· Prepare/Pre-qualification: The process in which it is checked whether a unit can deliver the product it intends to sell.
· Plan/Forecast: Planning of grid utilization and identifying potential congestions.
· Market Phase: Market opening, qualification, bids collection, market clearing and communication of results.
· Monitoring and Activation: Grid monitoring and flexibility bids activation to solve the forecasted congestion management
· Measurement phase: Validation of delivery
Complete description
This BUC will demonstrate the long-term congestion management procurement of local flexibility products by the DSO.
This BUC describes the exchanges of information and the processes that should be established between DSO, IMO and FSP to solve distribution network local congestions.
The objective is to procure products to ensure the network remains secure and does not go beyond its firm capacity at times of peak demand. The products can be procured from weeks to years ahead delivery, and is aimed towards MV/LV flexibility providers.
The DSO procures the product in the long-term (years to weeks ahead delivery). The DSO procures a band of flexibility that will be activated when needed or as scheduled, one or more times during the life of the contract. The flexibility providers receive a payment for the availability during the life of the contract and if activation is needed, the flexibility provider may receive an additional utilisation payment or not (to be defined at the contract) . If the activation is not delivered, penalties may be applied to the flexibility provider. If the flexibility is delivered as contracted, the DSO proceeds with the settlement as agreed at the contract.
Scenarios:
Prepare/Pre-qualification:
The pre-qualification process starts once the 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. This has to be ensured from two perspectives, namely the grid pre-qualification and product pre-qualification.
The former ensures that the resource meets the technical requirements to be able to deliver the product and proceed to the market phase and eventually be selected by a system operator. In principle, the grid pre-qualification will be done by the DSO, as FSPs in this BUC are connected to MV and LV grids. The grid pre-qualification may involve both internal simulations by the DSO and/or specific field tests with the FSP.
The market or product pre-qualification aims at ensuring that the FSP can participate in a particular market and can provide a particular service considering market and product design aspects. In principle, the product pre-qualification should be done by IMO.
If the results of the two types of pre-qualification are approved, the entry of the FSP into the flexibility market is allowed. The validity of the pre-qualification can be indefinite, limited to a certain period of time or conditioned to predefined aspects (e.g. grid conditions).
Considering that this BUC WECL-ES-01 describes the long-term products for the Spanish demonstration, it is also possible that the pre-qualification process starts once a market session is open, considering that a market session can last for weeks or longer.
Whenever possible, the pre-qualification processes (grid and product) will be combined or coordinate, aiming at having the simplest possible process for the FSP. Likewise, the pre-qualification processes of WECL-ES-01 and WECL-ES-02 will also aim at coordination and simplification whenever the requirement allow to.
Plan/Forecast:
In this service phase, the DSO carries internal analysis (e.g. forecasts, power flows) to detect congestions in the grid, which could be solved by the long-term procurement of flexibility. This service phase happens years to weeks ahead.
- Market Phase:
Based on the flexibility needs identified in the previous market phase, the DSO is able to call a market through the market platform (described in SUC-ES-01). This market, operated by the independent market operator, will procure either availability only or availability and activation. The availability means a capacity band (e.g. in kW) with a start and finish times defined, in which the FSP is expected to provide the flexibility upon the DSO’s call. Alternatively, the availability can also mean that the FSP is obliged to bid in the short-term local congestion management markets (defined in WECL-ES-02) activation products, in which capacity and duration of activation are predefined (in kWh). It is also possible to the DSO to procure activation in the long-term, defining weeks/months in advance the day, time, capacity and duration of activations.
This market phase can be classified as a local market model. It is an auction type of market, in which the gate opening time takes place from than more than year-ahead to weeks ahead. The gate closure time takes place a week-ahead delivery. FSPs participating should have resources connected to medium or low voltage levels.
During this phase there is a qualification process to check if the flexibility provider is able to provide the demand service in terms of quality and cost.
The results of the auction will be published.
- Monitoring and Activation:
This service phase takes place close to real-time and in real-time. The DSO will monitor the conditions of the grid in real time and send the activation signals to the FSPs committed in the market phase, in accordance to the type of product procured.
When activating the FSPs, the DSO will consider the actual state of the grid. Emergency states in which the procured flexibility activations cannot be concluded are outside the scope of this BUC WECL-ES-01. Emergency states are situations in which market procedures are no longer appropriate to ensure the security of the system.
- Measurement phase:
In this final service phase, the MO and/or DSO will verify if the flexibility was provided in accordance to the product procured in the market phase. This service phase can take place in the real-time and/or after the real-time. For the measurement of flexibility, a baseline has to be previously defined, to which the actual metered data of the FSP can be compared too. If the FSP is not able to deliver the flexibility in accordance to the predefined market conditions and agreed baseline, penalties may apply, which would decrease the remuneration received by FSP.
ID | Name | Description | Reference to mentioned use case objectives |
---|
1.6. Use case conditions
Relation to other use cases |
---|
|
Level of depth |
Prioritisation |
High priority |
Generic, regional or national relation |
National |
Nature of the use cases |
Business Use Case |
Further keywords for classification |
Local congestion management, Distributed energy resources, flexible providers, traditional investment, long term |
2. Diagrams of Use Case
3. Technical Details
3.1. Actors
Actor Name | Actor Type | Actor Description | Further information specific to this Use Case |
---|
Distribution System Operator (DSO) | Role | According to the Article 2.6 of the Directive: “a natural or legal person responsible for operating, ensuring the maintenance of and, if necessary, developing the distribution system in a given area and, where applicable, its interconnections with other systems and for ensuring the long-term ability of the system to meet reasonable demands for the distribution of electricity”. | |
Independent Market Operator (IMO) | Role | Responsible for calling, clearing, communicating results and possibly settling the provision of distributed flexibility. This role can be taken by an independent market operator, an existing one (e.g. a NEMO), or a system operator. | |
Distributed Energy Resource (DER) | Device | Resources connected at the distribution grid capable of providing active power flexibility, either upward/downward or both. It can comprise several different roles and devices such as demand response (actor/role), distributed generation, electric vehicles, and storage systems. | |
Flexibility Service Provider (FSP) | Role | Generic role which links the role customer and its possibility to provide flexibility to the roles market and grid; generic role that could be taken by many stakeholders, such as an aggregator or individual distributed energy resources. | |
3.2. References
No. | References Type | Reference | Status | Impact on Use Case | Organistaor / Organisation | Link |
---|
4. Step by Step Analysis of Use Case
4.1. Overview of Scenarios
No. | Scenario Name | Scenario Description | Primary Actor | Triggering Event | Pre-Condition | Post-Condition |
---|
1 | Prepare/Pre-qualification | The process in which it is checked whether a unit can deliver the product it intends to sell. | | Prepare/Pre-qualification | | |
2 | Plan/Forecast | Planning of grid utilization and identifying potential congestions. | | Plan/Forecast | | |
3 | Market phase | Market opening, qualification, bids collection, market clearing and communication of results | | Market phase | | |
4 | Monitoring and activation | Grid monitoring and flexibility bids activation to solve the forecasted congestion management | | Monitoring and activation | | |
5 | Measurement phase | Validation of service delivery | | Measurement phase | | |
Notes
4.2. Steps – Scenarios
Scenario Name: |
---|
Prepare/Pre-qualification |
Step No. | Event. | Name of Process/ Activity | Description of Process/ Activity. | Service | Information Producer (Actor) | Information Receiver (Actor) | Information Exchanged | Requirements, R-ID |
---|
1.0 | FSP requests to be pre-qualified | Pre-qualification request | The FSP requests to the IMO to be pre-qualified to offer a certain type of product | CREATE | | | | I.E.01 I.E.02 I.E.03 I.E.04 |
1.1 | IMO processes market prequalification | Product prequalification | The IMO processes the market prequalification. | EXECUTE | | | | |
1.2 | FSP is notified if information provided is incomplete | Notification(missing data) | The IMO requests missing data | GET | | | | I.E.03 I.E.04 |
1.3 | FSP reports back missing data | Missing data | The FSP reports back missing data | REPORT | | | | I.E.03 I.E.04 |
1.4 | IMO notifies the completion of data collection | Notification(complete) | The notifies the completion on data collection process for the purpose of pre-qualification | CLOSE | | | | |
1.5 | IMO forwards pre-qualification request for technical prequalification | Forward req. for grid pre-qualification | The IMO forwards pre-qualification request for technical prequalification | REPORT | | | | I.E.03 I.E.04 |
2.0 | DSO assess the need for a technical validation | Assessment of need for technical validation | The DSO may decide that field tests are necessary to ensure that flexibility can be provided by the applicant FSP. In this step, the DSO assess internally the need for field tests | EXECUTE | | | | |
2.1 | DSO communicates the need for a technical validation | Notification | If a technical validation is necessary, the FSP is communicated on the new requirement, as well as the details for the technical validation. | REPORT | | | | |
2.2 | FSP acknowledges the technical validation need | Confirmation | The FSP acknowledges the technical validation need | REPORT | | | | |
2.3 | Technical validation test | Technical validation test | The DSO may send a setpoint directly to the DER at the moment of the activation. | GET | | | | |
2.4 | DER sends metering data | Metering data | The DER sends metering data regarding the technical pre-qualification directly to the DSO. | REPORT | | | | I.E.06 |
2.5 | DSO processes the results from technical validation | Process technical validation | The DSO internally processes the results of the technical validation test | EXECUTE | | | | |
2.6 | DSO notifies on successful technical validation | Notification(positive) | The DSO notifies the IMO on the result of the technical validation | REPORT | | | | |
2.7 | The IMO registers internally the FSP as pre-qualified | Register information(positive) | The IMO registers internally the FSP as pre-qualified | CREATE | | | | |
2.8 | The FSP is communicated on the successful pre-qualification | Approved prequalification | The FSP is communicated on the successful pre-qualification | GET | | | | |
2.9 | The IMO registers to the Market Platform the successful pre-qualification | Registration of pre-qualified FSP | The IMO registers to the Market Platform the successful pre-qualification | CREATE | | | | |
2.10 | DSO notifies on unsuccessful technical validation | Notification(negative) | The DSO notifies the IMO on the result of the technical validation | REPORT | | | | |
2.11 | The IMO registers internally the FSP as not pre-qualified | Register information(negative) | The IMO registers internally the FSP as not pre-qualified | CREATE | | | | |
2.12 | The FSP is communicated on the unsuccessful pre-qualification | Denied pre-qualification | The FSP is communicated on the unsuccessful pre-qualification | GET | | | | |
2.13 | If no technical validation is necessary, DSO informs no technical pre-qualification result | Notification(positive or negative) | If no technical validation is necessary, DSO informs no technical pre-qualification result | REPORT | | | | |
2.14 | The IMO registers internally the result of the pre-qualification process (positive or negative) | Register information(positive or negative) | The IMO registers internally the result of the pre-qualification process (positive or negative) | CREATE | | | | |
2.15 | The FSP is communicated on the pre-qualification result (positive or negative) | Notification(Approved or Denied) | The FSP is communicated on the pre-qualification result (positive or negative) | REPORT | | | | |
2.16 | The IMO registers to the Market Platform the successful pre-qualification | Registration of pre-qualified FSP(if approved) | The IMO registers to the Market Platform the successful pre-qualification | CREATE | | | | |
Scenario Name: |
---|
Plan/Forecast |
Step No. | Event. | Name of Process/ Activity | Description of Process/ Activity. | Service | Information Producer (Actor) | Information Receiver (Actor) | Information Exchanged | Requirements, R-ID |
---|
1.0 | DSO evaluates the need for a long-term market for flexibility | DSO evaluates the need for a long-term market for flexibility | The DSO evaluates internally the need for a long-term market for flexibility. This step is an internal activity exclusive to the DSO, and therefore no information exchanges with other actors take place. Therefore, the internal steps carried out by the DSO are not modelled in detail. | EXECUTE | | | | |
Scenario Name: |
---|
Market phase |
Step No. | Event. | Name of Process/ Activity | Description of Process/ Activity. | Service | Information Producer (Actor) | Information Receiver (Actor) | Information Exchanged | Requirements, R-ID |
---|
1.0 | DSO requests a long-term market | Call for a long-term market | DSO requests a long-term market based on the results of scenario 2 (plan and forecast). At this request, several parameters will have to be informed by the DSO. These parameters are grouped into (i) generic attributes and (ii) product parameters | CREATE | | | | I.E.07 I.E.08 |
1.1 | Notification of market request | Notification of market request | The IMO is notified that a market request was created by the DSO | REPORT | | | | |
1.2 | IMO validates and prepares a market session | Preparation of market session | The IMO validates the information provided by the DSO (IE07 and IE08). N.B.: Intermediated steps in which the IMO may identify missing information, request completion from the DSO, and final completion by the DSO are omitted for the sake of simplicity. | EXECUTE | | | | |
1.3 | IMO opens call for a long-term market | Open call for a long-term market | The IMO, after validating the market session, opens the market session in the Market Platform | EXECUTE | | | | |
1.4 | FSPs are notified of a market opening | Notification (Open Market) | The Market Platform notifies the FSP about a market opening. | REPORT | | | | I.E.08 |
1.5 | Pre-qualification period ends | Pre-qualification end | Considering that the long-term products can be negotiated for weeks or months, it is possible for the pre-qualification phase to run in parallel with the market phase. Nevertheless, for FSPs to be able to participate in a market session, the pre-qualification process should be concluded at this step no. 1.5 | N/A | | | | |
2.0 | IMO is informed of pre-qualified units | Pre-qualified units | This step market the beginning of the qualification process. The IMO receives a list of pre-qualified units for that market session | GET | | | | I.E.09 |
2.1 | DSO is informed of pre-qualified units | Pre-qualified units | This step market the beginning of the qualification process. The DSO receives a list of pre-qualified units for that market session | GET | | | | I.E.09 |
2.2 | IMO proceeds with the market qualification | Market qualification | The IMO proceeds with the market qualification. The IMO checks the maximum power to bid from FSPs and the existence of financial warranties. | EXECUTE | | | | |
2.3 | IMO registers a list of qualified units (market qualification) | Qualified FSPs (market) | The IMO registers a list of qualified units (market qualification) | REPORT | | | | I.E.10 |
2.4 | DSO proceeds with the technical qualification | Technical qualification | A process by which the DSO verifies the DER capacity to meet the requisites of the specific requirement. All the resources in the specific area will be checked to determine which ones are capable of providing the required service. | EXECUTE | | | | |
2.5 | DSO registers a list of qualified units (technical qualification) | Qualified FSPs (technical) | The DSO registers a list of qualified units (Technical qualification) | REPORT | | | | I.E.10 |
2.6 | The Market Platform crosschecks both qualification lists and produces the consolidated list | Consolidation (qualification) | The Market Platform crosschecks both qualification lists and produces the consolidated list | CREATE | | | | I.E.10 |
3.0 | The Market Platform publishes/notifies qualified FSPs | Publication of qualified FSPs | The Market Platform publishes/notifies qualified FSPs | REPORT | | | | I.E.10 |
3.1 | The Market Platform publishes/notifies qualified FSPs to the DSO | Publication of qualified FSPs | The Market Platform publishes/notifies qualified FSPs to the DSO | REPORT | | | | I.E.10 |
3.2 | FSP bids to market session | Bid | Qualified FSPs may bid to the market session as long as market session is open (before the Gate Closer Time [GCT]) | CREATE | | | | I.E.11 |
4.0;4.1 | Market platform notifies the GCT | Market closure (GCT) | Market platform notifies the GCT | REPORT | | | | |
4.2 | Market Platform clears the market | Market clearing | Market Platform clears the market | EXECUTE | | | | |
4.3;4.4 | Market Platform reports market results | Market results | Market Platform reports market results | REPORT | | | | |
4.5 | IMO validates the market results | Validation of results | The IMO checks the market results for inconsistences. After that, results are validated | EXECUTE | | | | |
4.6 | IMO registers the validated market results | Validated market results | IMO registers the validated market results | REPORT | | | | I.E.12 |
4.7 | DSO validates the market results | Validation of results | The DSO checks the market results for inconsistences (from a technical perspective). | EXECUTE | | | | I.E.12 |
4.8 | DSO registers the validated market results | Validated market results | DSO registers the validated market results | REPORT | | | | I.E.12 |
4.9 | The Market Platform consolidates the market results | Consolidation (market results) | The Market Platform consolidates the market results based on the validation by the IMO and the DSO | CREATE | | | | I.E.12 |
4.10; 4.11; 4.12 | Market participants and IMO are informed of final market results | Notification (market results) | Market participants (DSO, FSPs) and IMO are informed of final market results | REPORT | | | | I.E.12 |
Scenario Name: |
---|
Monitoring and activation |
Step No. | Event. | Name of Process/ Activity | Description of Process/ Activity. | Service | Information Producer (Actor) | Information Receiver (Actor) | Information Exchanged | Requirements, R-ID |
---|
2.0 | The DSO monitors the state of the grid near real-time (activation) | Monitoring conditions near activation | The DSO monitor the sate of the grid near activation in order to ensure the security of the grid | EXECUTE | | | | |
2.1 | If the grid is an emergency state, the DSO starts the emergency protocol and the BUC is terminated | Beginning emergency state | If the grid is an emergency state, the DSO starts the emergency protocol and the BUC is terminated, as this situation lays outside the scope of this BUC. | EXECUTE;CLOSE | | | | |
2.2 | If the grid is an emergency state, the DSO notifies the FSP to proceed according the emergency protocol (outside the scope of the BUC) | Notification | If the grid is an emergency state, the DSO notifies the FSP to proceed according the emergency protocol (outside the scope of the BUC). For example, the FSP may be requested to proceed on a previously agreed way, may be exempted from providing flexibility, or may not be notified at all. This situation is outside the scope of this BUC. | REPORT | | | | |
3.0 | If the state is within normal conditions, the FSP proceeds with the activation in real-time according to the market results. | Activation | If the state is within normal conditions, the FSP proceeds with the activation in real-time according to the market results. | EXECUTE | | | | |
3.1 | DER reports metering data | Metering data | DER reports metering data directly to the DSO | REPORT | | | | I.E.06 |
Scenario Name: |
---|
Measurement phase |
Step No. | Event. | Name of Process/ Activity | Description of Process/ Activity. | Service | Information Producer (Actor) | Information Receiver (Actor) | Information Exchanged | Requirements, R-ID |
---|
1.0 | DSO receives metering data | Metering data | DSO receives metering data (step 3.1 of scenario 4) | GET | | | | I.E.07 |
2.0 | The DSO validates the service provision | Verification of service provision | The DSO validates the service provision. To do so, the DSO compares the metered data with the service procured and the baseline predefined. | EXECUTE | | | | |
2.1 | The DSO notifies the IMO on the service provision | Notification of service provision | The DSO informs the IMO on the level of service provision (e.g. percentage of service provision based on the deviation of the metering data to the agreed flexibility) | REPORT | | | | |
2.2 | IMO proceeds with the settlement processing | Settlement processing | The IMO proceeds with the settlement processing. According to the level of service provision, penalties (reduction of agreed price/payment) may occur. | EXECUTE | | | | |
2.3 | The FSP is notified on the final settlement | Settlement notification | The FSP is notified on the final settlement | REPORT | | | | |
Information exchanged ID | Name of Information | Description of Information Exchanged | Requirement |
---|
6. Requirements (optional)
Category Identifier | Name | Description | mRID |
---|
Req_ID | Req_Name | ‘Long-term congestion management’ | |
Identifier | Name | Description | mRID |
---|
I.E.01 | Basic Participant Information | Register and basic information about the market participant such as username and password | I.E.01 |
I.E.02 | Market participant pre-qualification information | Contact information; Fiscal data; Access contract; bank details; power of representation; confidentiality agreement; declaration of non-collusion | I.E.02 |
I.E.03 | Market resource pre-qualification information | Market participants provide information on the resources they want to prequalify: Facility/resource name; Type of technology; Location; Market participant; etc. | I.E.03 |
I.E.04 | Technical resource pre-qualification information | Verification of the installed capacity to provide the service: Power; CUPS (Universal Supply Point Code acronym in Spanish); Maximum quantity; Response time, Etc | I.E.04 |
I.E.05 | Technical validation for pre-qualification | In case of the need of a technical validation for prequalification, the FSP receives the information on the when and how the test will be conducted: day; time; power to reduce/increase; duration of the test; etc. | I.E.05 |
I.E.06 | Metering data | Metering data from DER | I.E.06 |
I.E.07 | Generic attributes | Composed of generic parameters concerning the market session being requested. E.g.: | |
• Auction identifier | | | |
• Associated DSO | | | |
• Product Type: Flexibility Product | | | |
• Type of negotiation: Auction | | | |
• Area: Basic or aggregated. | I.E.07 | | |
I.E.08 | Product parameters | Composed of product parameters concerning the market session being requested. E.g.: | |
- Service window: Selection of the required date and duration of the service
o Start date: 01/06/2021
o Duration: 2 months
o Selection of days: M, T, W, T, F, S and S.
o Opening time: 8:00 PM
o Closing time: 10:00 PM
- Availability: Selection of the capacity, the direction and the estimated hours of activation.
o Capacity: 4MW
o Direction: Upwards (up for generation, down for consumption)
o Estimated hours of activation: 120h
- Activation window (in case of activation product): Specific subperiod in an activation window when a particular DER could be activated and thus it must be available. Multiple sets of activation windows can be defined. E.g.:
o Day: 01/06/2021
o Hour: 19h
o Duration: 2h
o Capacity to modify: 1MW
o Direction: Upward
- Local area: Selection of the trading area. Choice by postal code, connection point, lines… (to be determined).
o Area: postal code
- Activation Announcement: Time in advance that a DSO informs a DER that its activation is programmed confirmed.
- Form of Remuneration: It establishes form of payment to winner DERs Two different terms are defined availability and activation (depending on the product).
o Type of product: availability/activation
o Availability/Activation cap price: X €/MW or X €/MWh | I.E.08 |
| I.E.09 | List of pre-qualified units | List of pre-qualified units for a given market session | I.E.09 |
| I.E.10 | List of qualified units (market, technical or consolidated) | List of qualified units for a given market session. The list can refer to the market qualification, technical qualification or the consolidated list. | I.E.10 |
| I.E.11 | Bid | Composed of bidding information | I.E.11 |
| I.E.12 | Validate market results | Validated market results by either the IMO (market), the DSO (technical) or the consolidated market results. | I.E.12 |
7. Common Terms and Definitions
Key | Value | Refers to Section |
---|