UC-IT-2

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

This use case describes the main steps to prevent congestion issues in transmission and distribution systems by exploiting flexibility resources, contemplating all the phases concerned (procurement, activation and settlement) in the day-ahead and real time flexibility market. The DSO can use flexible resources connected to the distribution system and the TSO can use flexible resources connected to distribution systems under the DSO’s approval. The state estimation is assessed and monitored by the DSO in order to keep the electrical quantities within admissible ranges.

Complete description

The Use Case describes the main steps to prevent congestion issues in transmission and distribution systems by exploiting flexibility resources, contemplating all the phases concerned (procurement, activation and settlement) in the day-ahead and real time flexibility market. The DSO can use flexible resources connected to the distribution system and the TSO can use flexible resources connected to distribution systems under the DSO’s approval. The state estimation is assessed and monitored by the DSO in order to keep the electrical quantities within admissible ranges In the day ahead market, the FR Owner sends to Aggregator Platform the list of the resources available for the day after. The list is subsequently transmitted by the Aggregator Platform to the Shared Customer Database (SCD). For each Point of delivery (PODs), the SCD collects quarterly measures and data useful for flexibility and sends them to the DSO Technical Platform, the TSO simulator and the Aggregator Platform.

Other three processes take place parallelly:

• Detection of congestion issues on the distribution grid by the DSO Technical Platform and definition of local flexibility requests, in the event the issue cannot be solved through its own solutions;

• Definition of congestion issues on the transmission network by the TSO simulator and request of flexibility to solve them in HV grid;

• Gathering by the Aggregator Platform of flexibility offers from customers in LV and MV and offering to the Market.

At gate closure, all day ahead requests and offers are stored in the Market Platform, which matches first the offers with the DSO’s requests, and orders them economically; then, it repeats the same procedure with the TSO requests.

The list of awarded offers is sent to DSO TP for evaluating the grid constraints violations. Finally, the market platform receives the list of offers compliant with local grid constraints and sends it to all the stakeholders.

At this step, the Aggregator Platform sends a reservation to the FR Owner for the resources that will be selected for the day-ahead market. The same steps are also followed in the Real Time sessions. Indeed, in these Market sessions, the offers to be matched with DSO and TSO Real Time requests are the ones still valid because not matched in previous market sessions.

The activation phase begins when the DSO and TSO need flexibility. The DSO TP and the TSO simulator communicate to the market Platform to move a specific offer. The Market Platform sends the order to the DSO TP, that divides it for every POD and dispatches the set point to the light nodes. The light nodes make available the set points to the BMS and measures the electrical quantities to be sent to the SCD for evaluate the energy flexibility.

For the settlement phase, the Market Platform acquires data from the SCD and calculates the difference between market baseline, evaluated by BRP, and electrical quantities measured in the same time frame, uploaded in the SCD by Light Nodes. The Market Platform runs the settlement algorithm and finds the outcomes. Settlement outcomes are transmitted to the Aggregator Platform, the DSO and the TSO Simulator.

Finally, the DSO pays the flexibility to the aggregator, that can pay the fee to the FR Owner.

1.5. Key Performance Indicatiors (KPI)

1.6. Use case conditions

Notes:

• Assumptions - general presumptions about conditions or system configurations (e.g. customer’s consent required for some steps; simulation of TSO)

• Prerequisites - specify which requirements have to be met so that the basis scenario use case can be successfully accomplished.

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

OPTIONAL - you can leave it blank

Notes:

• Relation to other use cases - relation to other use cases in the same project or thematic area. Possible relation types are for instance include, extend, invoke, or associate.

• Level of depth - reflects the degree of specialisation of the use case. Although no common notation is settled, descriptions like high level use case, generic, detailed, or specialised use case are often used.

• Prioritisation - helps to rate the use cases in a project from very important to nice-to-have with labels like obligatory/mandatory or optional which have to be agreed upon beforehand.

• Generic, regional or national relation - for the purpose of generalisation if use case is applied to areas where restictions by law or silimiar issues occur.

• Nature of the use cases - describes the viewpoint and field of attention like technical, political, business/market, test, etc.

1.8. General remarks

Notes:

Add any remarks which do not fit in any other category

2. Diagrams of Use Case

Use Case Diagram Congestion: Component

Use Case Diagram Congestion: Function

Sequence Diagram Congestion

3. Technical Details

3.1. Actors

3.2. References

OPTIONAL - you can leave it blank

4. Step by Step Analysis of Use Case

4.1. Overview of Scenarios

4.2. Steps – Scenarios

Scenario Name: No. 1 - Day Ahead

Scenario Name: No. 2 - Real Time

Scenario Name: No. 3 - Activation

Scenario Name: No. 4 - Settlement

5. Information Exchanged

6. Requirements (optional)

7. Common Terms and Definitions

8. Custom Information (optional)