UC-GR-4

1. Description of the Use Case

1.1. Name of the Use Case

Use case identification

Notes:

• ID - unique identification label: DE-1/GR-3/IT-2

• Area /Domain(s)/Zone(s) - placement of the use case in the SGAM domains and zones. It can be left blank if you are not sure.

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.
• Related business case(s) - optional

1.4. Narrative of Use Case

Short description Various types of flexible loads -aggregated for the scope of the Use Case- react to network tariffs sent by the DSO, so that frequency restoration request from the TSO is adequately handled. More in detail, customers with flexible loads will respond to such requests and the DSO will use flexibility tools to coordinate their response aiming at achieving the frequency support objective while ensuring distribution network operational safety. As in the previous Use Cases the state of the system is provided by the state estimation tool.

Complete description Customers with flexible loads are connected to the distribution network and their loads are considered aggregated for the scope of the UCs regarding their management in the MV level. State of the network is known with a good degree of certainty based on the available measurements and the topology via the AMR, GIS and SCADA data. A frequency support activation request from the TSO arrives at the customers with flexible loads. The request is also communicated to the DSO technical platform via an API and the information is shared with the appropriate tools and services. The DSO calculated and communicated to the customers the appropriate network tariffs that reflect the situation of the network. The flexible loads react to these tariffs and respond to the frequency support request appropriately.

add text - longer narrative from user viewpoint about what happens how, where, when, why and under which assumptions. It has to be written in a way that it can also be understood by non-experts.

1.5. Key Performance Indicatiors (KPI)

Notes: Can be left blank now

1.6. Use case conditions

Customers are rational, Part of the load is flexible, State of the network is known with a good degree of certainty 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 - Frequency support request resolved

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)