NOCL-01
Northern Flexibility Market
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 | Flexibility market, TSO-DSO coordination. | |
| Northern Demonstration Cluster: Finland, Estonia, Latvia, Lithuania, | NOCL-01 | |
1.2. Version Management
| Version No. | Date | Name of author(s) | Changes | Approval status |
|---|
| 0.1 | 2021-05-10T00:00:00 | Sirpa Repo, | Ch. 1.1-1.4 | None |
1.3. Scope and Objectives of Use Case
| |
|---|
| Scope | Regional, enabling multiple market operators, coordination of the system operators |
| Objective(s) | Regional, enabling multiple market operators, coordination of the system operators |
| - Develop seamless end-to-end process for market-based flexibility utilization for grid services | |
| - Lower the entry barrier for flexibility by simplifying the process for flexibility service provider | |
| - Ensure availability of short-term flexibility from multiple sources | |
| Related business case(s) | None |
1.4. Narrative of Use Case
Short description
Business Use Case describes the flexibility process starting from FSP contracting the end-customers to prequalification, procurement, activation, delivery and monitoring, verification and settlement. BUC introduces flexibility register for sharing flexibility resource information and TSO&DSO coordination platform for the grid impact assessment and for optimisation.
Complete description
The business use case describes seven scenarios. Scenarios are 1) customer onboarding process, 2) prequalification process of flexibility service providers, resources and network needs, 3) flexibility (energy and capacity) procurement process, 4) conditional secondary trading process. 5) activation process (in case separate activation after the procurement is needed), 6) delivery and monitoring process, 7) verification and settlement process.
The business use case can be applied in provision and procurement of balancing, network congestion management and voltage control services. BUC includes new platforms, flexibility register and TSO&DSO coordination platform. These platforms will have a role in management of flexibility resources and procurement related data and joint TSO/DSO coordination and network impact assessment.
| ID | Name | Description | Reference to mentioned use case objectives |
|---|
1.6. Use case conditions
| Relation to other use cases |
|---|
|
| Level of depth |
| Prioritisation |
|
| Generic, regional or national relation |
|
| Nature of the use cases |
|
| Further keywords for classification |
|
2. Diagrams of Use Case
3. Technical Details
3.1. Actors
| Actor Name | Actor Type | Actor Description | Further information specific to this Use Case |
|---|
| Consumer/Producer | Business | Consumer is a party that consumes electricity and Producer is a party that generates electricity. | |
| Balancing responsible party (BRP) | Business | A Balance Responsible Party is responsible for its imbalances, meaning the difference between the energy volume physically injected to or withdrawn from the system and the final nominated energy volume, including any imbalance adjustment within a given imbalance settlement period. | |
| Balancing service provider (BSP) | Business | A party with reserve-providing units or reserve-providing groups able to provide balancing services to one or more LFC (Load frequency conrol) Operators. | |
| Resource aggregator | Business | A party that aggregates resources for usage by a service provider for energy market services. | |
| Market operator (MO) | Business | A market operator is a party that provides a service whereby the offers to sell electricity are matched with the bids to buy electricity. | |
| System operator (SO) | Business | A party responsible for operating, ensuring the maintenance of and, if necessary, developing the 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 or transmission of electricity. | |
| Imbalance settlement responsible (ISR) | Business | A party that is responsible for settlement of the difference between the contracted quantities with physical delivery and the established quantities of energy products for the Balance Responsible Parties in a Scheduling Area. | |
| Flexibility Register Operator (FRO) | Business | A party that stores information about flexibility assets, results of qualification (both product and grid), market results, grid information as well as perform flexibility verification and settlement, aggregates flexibility information, allocates access rights to the various actors and controls the level of access. | |
| Flexibility Service Provider (FSP) | Business | A party which offers flexibility services to the Consumer and thus connects these to the flexibility market. | |
| Optimisation operator (OO) | Business | A party which is responsible to avoid activating of flexibilities which either do not contribute to solving system needs or even worsen the situation (constraint setting process), through grid impact assessment. OO will find the best value-stack of available flexibilities to be activated by performing optimization process. | |
| Resource Owner (RO) = resource provider | Business | A party who owns the resource. | |
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 | Customer process | This scenario deals with onboarding customer for providing flexibility. It starts from definition of some products, contract format, and information consents for customers, who want to provide flexibility. Also aggregating the customer flexibility, registration in FR, and providing the information of resources for prequalification is part of this scenario. | | Customer process | | |
| 2 | Prequalification process | This scenario focuses on prequalification of 1) Flexibility Service Providers, 2) product prequalification (the technical specification of product), and 3) the grid assessment of the flexibility product (‘grid prequalification’), for example if the flexibilities can cause congestions in the grid (‘grid prequalification’). | | Prequalification process | | |
| 3 | Trading process | This scenario deals with trading of flexibility products, which are previously defined with Market operators (System Operators might have a role of MO) and possibly standardized. Flexibility Service Providers offer flexibilities for these defined flexibility products in parallel markets while System Operators looking for the optimum solutions. In this mechanism, OO takes into account the maximum global benefit and bid qualification (network limits). This means that it may happen that more than one System Operator will be willing to buy same flexibility.Therefore, it is not necessarily the cheapest flexibility which would bring highest socio-economic value. bids. The MO are responsible to clear the bids, therefore, timing and clearing of markets need to be coordinated between the markets, when there are markets running in parallel. | | Trading process | | |
| 4 | Secondary trading | For longer term flexibility products, FSPs may wish to trade their flexibility contracts to another qualified participant if they cannot fullfill the obligations. The scenario is similar but simpler that the original trading, scenario 3. The SO needs to be notified of this trade to continue with scenarios 4-6 | | Secondary trading | | |
| 5 | Activation | This Scenario describes the process of activation of the flexibility, taking into account any grid limitations, and the needed data exchange. Notifying the activation requests to the Flexibility Service Providers (FSPs) must happen in a reliable and timely manner according to the relevant terms and conditions applicable to FSPs. | | Activation | | |
| 6 | Delivery and monitoring (real-time) | This scenario focuses on monitoring the flexibility delivery. Actual flexibility delivered is calculated as the difference between baseline and metered consumption/generation of that resource. In this regard, FSP need to provide the real-time metering data and FRO calculates the amount of flexibility delivered and the possible difference between it and the requested amount. If needed OO can start a new procurement. requested flexibility. | | Delivery and monitoring (real-time) | | |
| 7 | Verification and settlement | This scenario focuses on verification and balance and financial settlement The verification takes place by comparing the actually delivered flexibility and flexibility traded on the markets. FSP is asked for a penalty if actually delivered flexibility is less than requested flexibility. Measured data is sent to Datahub and trades in the markets to ISR for the balance settlement. Market operator financially settles the trades for the market participants. | | Verification and settlement | | |
Notes
4.2. Steps – Scenarios
| Scenario Name: |
|---|
| Customer process |
| Step No. | Event. | Name of Process/ Activity | Description of Process/ Activity. | Service | Information Producer (Actor) | Information Receiver (Actor) | Information Exchanged | Requirements, R-ID |
|---|
| Scenario Name: |
|---|
| Prequalification process |
| Step No. | Event. | Name of Process/ Activity | Description of Process/ Activity. | Service | Information Producer (Actor) | Information Receiver (Actor) | Information Exchanged | Requirements, R-ID |
|---|
| Scenario Name: |
|---|
| Trading process |
| Step No. | Event. | Name of Process/ Activity | Description of Process/ Activity. | Service | Information Producer (Actor) | Information Receiver (Actor) | Information Exchanged | Requirements, R-ID |
|---|
| Scenario Name: |
|---|
| Secondary trading |
| Step No. | Event. | Name of Process/ Activity | Description of Process/ Activity. | Service | Information Producer (Actor) | Information Receiver (Actor) | Information Exchanged | Requirements, R-ID |
|---|
| Step No. | Event. | Name of Process/ Activity | Description of Process/ Activity. | Service | Information Producer (Actor) | Information Receiver (Actor) | Information Exchanged | Requirements, R-ID |
|---|
| Scenario Name: |
|---|
| Delivery and monitoring (real-time) |
| Step No. | Event. | Name of Process/ Activity | Description of Process/ Activity. | Service | Information Producer (Actor) | Information Receiver (Actor) | Information Exchanged | Requirements, R-ID |
|---|
| Scenario Name: |
|---|
| Verification and settlement |
| Step No. | Event. | Name of Process/ Activity | Description of Process/ Activity. | Service | Information Producer (Actor) | Information Receiver (Actor) | Information Exchanged | Requirements, R-ID |
|---|
| Information exchanged ID | Name of Information | Description of Information Exchanged | Requirement |
|---|
6. Requirements (optional)
| Category Identifier | Name | Description | mRID |
|---|
| Req_ID | Req_Name | ‘Northern Flexibility Market’ | |
| Identifier | Name | Description | mRID |
|---|
| ProdSpec | Product Specification | The technical specification of the flexibility product (technical parameters, validation, requirements) | ProdSpec |
| Consent | Customer Consent | Permission of data owner to use its private data. | Consent |
| FlexNeed | Flexibility Need | System operator’s future need for flexibilities. | FlexNeed |
| ResInfo | Resource Information | | ResInfo |
| GridInfo | Grid Information | The depth of Grid Information may be different case-by-case ranging from full grid model to some information about grid topology to simple grid constraints as reported by SOs. | GridInfo |
| GridRest | Grid Restrictions | Constraints assigned to flexibilities which cannot be (fully or partially) activated without causing congestions in the grid. | GridRest |
| FCT | Flexibility Call for Tenders | Flexibility call specification for a specific product | FCT |
| FlexBid | Flexibility Bid | Offer made by Flexibility Service Provider for selling flexibility. | FlexBid |
| MOL | Merit Order List | Rank of Flexibility Bids based on predefined criteria. | MOL |
| FlexPur | Flexibility Purchase Offer | Offer made by System Operator for buying flexibility. | FlexPur |
| OptRes | Optimisation results | Optimisation of Merit Order List taking into account the possible synergies of using the same bid for more than one service and/or buyer. | OptRes |
| MarOut | Market Outcome | the results of matching the offers/bid by MO | MarOut |
| FlexActReq | Flexibility Activation Request | Request made by SO to activate required flexibility. | FlexActReq |
| FlexActOrd | Flexibility Activation Order | Flexibility Activation Request forwarded to specific FSP. | FlexActOrd |
| ActFlex | Activated Flexibility | Amount of flexibility activated according to Flexibility Activation Order. | ActFlex |
| ProdPlan | Production Plan | | ProdPlan |
| ConsPlan | Consumption Plan | | ConsPlan |
| Baseline | Baseline | | Baseline |
| DelivFlex | Delivered Flexibility | | DelivFlex |
| Deviation | Deviation | | Deviation |
| Remuneration | Remuneration | | Remuneration |
| Penalties | Penalties | | Penalties |
| Invoicing data | Invoicing data | | Invoicing data |
| Details on new FSP and asset | | |
7. Common Terms and Definitions
| Key | Value | Refers to Section |
|---|