UC-GE-4

1. Description of the Use Case

1.1. Name of the Use Case

Use case identification

1.2. Version Management

Version management

1.3. Scope and Objectives of Use Case

Scope and objectives of use case

Notes:

• Scope - describes the aims and boundaries of the use case in a short, precise text.

• Objective(s) - goals of the use case, in form of bullet points and a short headline.

• Realted business case(s) - optional

1.4. Narrative of Use Case

Short description

Local energy communities (LEC, CEC) are likely to emerge in Europe in the near future but will most likely retain an interconnection to the distribution grid. These communities will require a large share of flexibility to enable their primary use case (islanding).
In the absence of sufficient generation and storage, the community is unlikely to be self-sufficient at all times. When generation of surplus occur, they must be exported into the distribution network. Instead of a real time energy export to the connected distribution network, energy surplus could be forecast and exported delayed as an energy package within a defined time, duration and power value for the load exchange at the LV/ MV-grid connection point. The generated energy surplus first shall be stored in local storages located within the community and be exported as an energy package delayed, when the load in the upper grid decreases. Outside of the defined periods of energy export, no power exchange shall take place, according to DE-UC1. This use case enables the DSO to reduce overall network costs, for example by gaining the ability to stagger the export of multiple communities along a single feeder, thusly reducing the factor of coincidence of peak load and peak load level accordingly.
Local energy communities (LEC, CEC) are likely to emerge in Europe in the near future but will most likely retain an interconnection to the distribution grid. These communities will require a large share of flexibility to enable their primary use case (islanding).

In the absence of sufficient generation and storage, the community is unlikely to be self-sufficient at all times. When generation of surplus occur, they must be exported into the distribution network. Instead of a real time energy export to the connected distribution network, energy surplus could be forecast and exported delayed as an energy package within a defined time, duration and power value for the load exchange at the LV/ MV-grid connection point. The generated energy surplus first shall be stored in local storages located within the community and be exported as an energy package delayed, when the load in the upper grid decreases. Outside of the defined periods of energy export, no power exchange shall take place, according to DE-UC1. This use case enables the DSO to reduce overall network costs, for example by gaining the ability to stagger the export of multiple communities along a single feeder, thusly reducing the factor of coincidence of peak load and peak load level accordingly.

Complete description

An operator of Avacon triggers the EMS to apply Use Case 4 and sets a schedule of target value P’Breaker for the period (t+1) for the power exchange at the grid connection point. The schedule can be defined for a duration for the next 1 to 24 hours.
The schedule contains time slots for the export of energy in which P’Breaker ≠ 0 and time slots in which no power shall be exchange along the grid connection point (P’Breaker = 0), following the principle of UC 1. During the application of UC 4 the total amount of exported energy shall meet the total amount of the residual energy surplus that the community will generate. The generated surplus will therefore have to be forecasted by the user. In times P’Breaker = 0 the generated surplus will have to be stored in local battery energy storages systems. In times P’Breaker ≠ 0, local batteries will be triggered to discharge in order to export generated surplus from LV into MV grid. To maintain the given setpoint P’Breaker deficits shall be covered by energy provided by batteries located in the local network whereas generated surplus shall be buffered in available batteries.
After the user input has been confirmed the EMS begins with the application of UC 4. The EMS receives weather forecasts provided by an external service provider and measurement values provided by sensors located at the LV/MV grid connection point, flexible assets such as BESS, household energy storages and flexible loads as well as household grid connection points. Based on the received data and historic measurements values the EMS forecasts the local generation and demands and determines the best strategy to reach and maintain the setpoint schedule by utilizing the available flexibility for the pre-defined duration.
A sensor located at the grid connection will measure the power exchange of all 3 phases with the MV grid PBreaker and provide data to the EMS. Based on the information the EMS determines deviations between PBreaker and P’Breaker and dispatches setpoints to increases or decreases the load in the grid in order to reach P’Breaker. Additionally, sensors located in private customer households will provide measurements of energy consumption and SOC/SOE of storages and provide data to the EMS. With historical measurement data and weather forecast provided by external service providers enable the EMS to predict energy generation and consumption to maximize the duration of time of maintaining P’Breaker.
In cases generation and demand cannot be balanced to reach (P’Breaker) due to a lack of available storage capacity or flexibility, the use case will be terminated.

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

3. Technical Details

3.1. Actors

Notes:

• Actor Type - Device/ Sytem/ Person

3.2. References

OPTIONAL - you can leave it blank

4. Step by Step Analysis of Use Case

4.1. Overview of Scenarios

Notes

This part describes the possible scenarios of the use case. The scenarios should comply with the sequence diagrams in Sect. 2 of the template, so that every step describes one part of a communication or action. Apart from a normal success scenario, different failure scenarios or alternatives can be included to describe situations where preconditions are not satisfied or unwanted states are attained.

• Primary Actor - the first actor appearing in the scenario at the incident causing the scenario to begin.

• Triggering Event - the incident causing the scenario to begin.

• Pre-Condition - indicates which terms have to be fulfilled for the scenario to be executed.

• Post-Condition - indicates which terms should be valid after the scenario. TIt can also specify whether a scenario has been successfully completed or not.

4.2. Steps – Scenarios

Scenario Name: No. 1 - Local generation exceeds consumption

Scenario Name: No. 2 - (name of scenario)

Notes

This part describes the possible scenarios of the use case. The scenarios should comply with the sequence diagrams in Sect. 2 of the template, so that every step describes one part of a communication or action. Apart from a normal success scenario, different failure scenarios or alternatives can be included to describe situations where preconditions are not satisfied or unwanted states are attained.

• Event - Event triggering a step, specific for that use case.

• Name of Process/ Activity - general classification of process/activity (e.g. data aquisition).

• Description of Process/ Activity - more detailed description of the step.

• Service - addresses the nature of the information flow. Possible: GET (The information receiver obtains information from the information producer after an implicit request.), CREATE (The information producer creates an information object.), CHANGE (The information producer performs an update of the information at the information receiver’s.), DELETE (The information producer deletes information of the receiver.), CANCEL/CLOSE (A process is terminated.), EXECUTE (An action or service is performed.), REPORT (The information producer supplies information of its own account.), TIMER (The actor which represents both information producer and receiver has to enforce a waiting period.), REPEAT (A number of steps has to be repeated until a break condition (stated in the field Event) is satisfied. The contemplated steps have to be added in parentheses.).

• Information Producer and Receiver (Actor) - actors from actor list in section 3.1

• Information exchanged (IDs) - ID of the information defined further in section 5

5. Information Exchanged

Notes

• Information exchanged ID - unique number (I-01,I-02…) for identification

• Requirements to information data - optional, defined in section 6

6. Requirements (optional)

7. Common Terms and Definitions

8. Custom Information (optional)

9. Functionalities