Northern Flexibility Market

1. Description of the Use Case

1.1. Name of the Use Case

IDArea /Domain(s)/Zone(s)Name of the Use Case
1Flexibility market, TSO-DSO coordination.
Northern Demonstration Cluster: Finland, Estonia, Latvia, Lithuania,NOCL-01

1.2. Version Management

Version No.DateName of author(s)ChangesApproval status
0.12021-05-10T00:00:00Sirpa Repo,Ch. 1.1-1.4None

1.3. Scope and Objectives of Use Case

ScopeRegional, 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.

1.5. Key Performance Indicatiors (KPI)

IDNameDescriptionReference to mentioned use case objectives

1.6. Use case conditions


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

Relation to other use cases
Level of depth
Generic, regional or national relation
Nature of the use cases
Further keywords for classification

1.8. General remarks

General remarks

2. Diagrams of Use Case

3. Technical Details

3.1. Actors

Actor NameActor TypeActor DescriptionFurther information specific to this Use Case
Consumer/ProducerBusinessConsumer is a party that consumes electricity and Producer is a party that generates electricity.
Balancing responsible party (BRP)BusinessA 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)BusinessA party with reserve-providing units or reserve-providing groups able to provide balancing services to one or more LFC (Load frequency conrol) Operators.
Resource aggregatorBusinessA party that aggregates resources for usage by a service provider for energy market services.
Market operator (MO)BusinessA 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)BusinessA 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)BusinessA 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)BusinessA 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)BusinessA party which offers flexibility services to the Consumer and thus connects these to the flexibility market.
Optimisation operator (OO)BusinessA 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 providerBusinessA party who owns the resource.

3.2. References

No.References TypeReferenceStatusImpact on Use CaseOrganistaor / OrganisationLink

4. Step by Step Analysis of Use Case

4.1. Overview of Scenarios

No.Scenario NameScenario DescriptionPrimary ActorTriggering EventPre-ConditionPost-Condition
1Customer processThis 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
2Prequalification processThis 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
3Trading processThis 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
4Secondary tradingFor 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-6Secondary trading
5ActivationThis 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
6Delivery 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)
7Verification and settlementThis 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


4.2. Steps – Scenarios

Scenario Name:
Customer process
Step No.Event.Name of Process/ ActivityDescription of Process/ Activity.ServiceInformation Producer (Actor)Information Receiver (Actor)Information ExchangedRequirements, R-ID
Scenario Name:
Prequalification process
Step No.Event.Name of Process/ ActivityDescription of Process/ Activity.ServiceInformation Producer (Actor)Information Receiver (Actor)Information ExchangedRequirements, R-ID
Scenario Name:
Trading process
Step No.Event.Name of Process/ ActivityDescription of Process/ Activity.ServiceInformation Producer (Actor)Information Receiver (Actor)Information ExchangedRequirements, R-ID
Scenario Name:
Secondary trading
Step No.Event.Name of Process/ ActivityDescription of Process/ Activity.ServiceInformation Producer (Actor)Information Receiver (Actor)Information ExchangedRequirements, R-ID
Scenario Name:
Step No.Event.Name of Process/ ActivityDescription of Process/ Activity.ServiceInformation Producer (Actor)Information Receiver (Actor)Information ExchangedRequirements, R-ID
Scenario Name:
Delivery and monitoring (real-time)
Step No.Event.Name of Process/ ActivityDescription of Process/ Activity.ServiceInformation Producer (Actor)Information Receiver (Actor)Information ExchangedRequirements, R-ID
Scenario Name:
Verification and settlement
Step No.Event.Name of Process/ ActivityDescription of Process/ Activity.ServiceInformation Producer (Actor)Information Receiver (Actor)Information ExchangedRequirements, R-ID

5. Information Exchanged

Information exchanged IDName of InformationDescription of Information ExchangedRequirement

6. Requirements (optional)

Category IdentifierNameDescriptionmRID
Req_IDReq_Name‘Northern Flexibility Market’
ProdSpecProduct SpecificationThe technical specification of the flexibility product (technical parameters, validation, requirements)ProdSpec
ConsentCustomer ConsentPermission of data owner to use its private data.Consent
FlexNeedFlexibility NeedSystem operator’s future need for flexibilities.FlexNeed
ResInfoResource InformationResInfo
GridInfoGrid InformationThe 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
GridRestGrid RestrictionsConstraints assigned to flexibilities which cannot be (fully or partially) activated without causing congestions in the grid.GridRest
FCTFlexibility Call for TendersFlexibility call specification for a specific productFCT
FlexBidFlexibility BidOffer made by Flexibility Service Provider for selling flexibility.FlexBid
MOLMerit Order ListRank of Flexibility Bids based on predefined criteria.MOL
FlexPurFlexibility Purchase OfferOffer made by System Operator for buying flexibility.FlexPur
OptResOptimisation resultsOptimisation of Merit Order List taking into account the possible synergies of using the same bid for more than one service and/or buyer.OptRes
MarOutMarket Outcomethe results of matching the offers/bid by MOMarOut
FlexActReqFlexibility Activation RequestRequest made by SO to activate required flexibility.FlexActReq
FlexActOrdFlexibility Activation OrderFlexibility Activation Request forwarded to specific FSP.FlexActOrd
ActFlexActivated FlexibilityAmount of flexibility activated according to Flexibility Activation Order.ActFlex
ProdPlanProduction PlanProdPlan
ConsPlanConsumption PlanConsPlan
DelivFlexDelivered FlexibilityDelivFlex
Invoicing dataInvoicing dataInvoicing data
Details on new FSP and asset

7. Common Terms and Definitions

8. Custom Information (optional)

KeyValueRefers to Section