Use Case: VITO/Automated demand response for intraday RE balancing
Search
Asset Publisher
Description Of The Use Case
Name of use case
Use case identification | ||
ID | System configuration(s) | Name of use case |
UC16 | [List of system configurations which this UC can be applied to] | [start with verb expressing key action] Using automated demand response for wind balancing. |
Version management
Version management |
| |||
Version No. | Date | Author(s) | Changes | Approval status |
[X.Y] | [DD/MM/YYYY] | [List of names] | [Difference to previous version] | [Draft, Work in progress, Review, Final] |
1.0 | 07/07/2017 | Pieter Valkering | First version | Work in progress |
Scope and objectives of use case
Scope and objectives of use case | |
Scope | The Balancing Responsible Parties (BRP) - electricity suppliers, producers, etc. - are expected to balance injection and output in their portfolio on an intra-day basis. The TSO manages the instantaneous imbalances that the BRP are not able to control by making use of power reserves supplied by certain grid users. The costs associated with using these power reserves are transferred to the BRP via an imbalance scheme. As such, imbalance tariffs constitute an incentive for them to optimize their portfolio.
Wind power suffers from two problems: it is an intermittent energy source and, additionally, the predictability of wind power is limited. For this reason, a BRP with wind generation in its portfolio has a higher risk of imbalance and so a greater chance of having to deal with imbalance costs. Residential demand response may compensate for imbalances caused by the difference between predicted and actual wind production and as such decrease the imbalance cost of the balancing responsible parties. Given the small time scales at which this compensation must take place (typically ~15 minutes), this usage of demand response is only feasible in an automated way. |
Objective(s) | [identify specific objectives] O1: Analyse the extent to which imbalance costs of BRPs can be avoided through residential automated demand response. O2: Analyse which type of appliance is most effective for reducing imbalance costs |
Belongs to use case group (if applicable) | [Specify an arbitrary group name here in order to link multiple related UCs together] Demand response, User interaction, Ancillary service |
Narrative of use case
Narrative of use case |
Short description |
This UC implies shifting residential electricity consumption on an intra-day basis to compensate for imbalances in a BRPs portfolio caused by a difference between predicted and actual wind production.
In Linear, this UC was based on a capacity based fee to remunerate households for offering flexibility on the use of their white good appliances (dishwasher, washing machine, tumble dryer) or for charging their electric vehicles. The capacity fee is proportional to the hours of delay configured on the end-users’ smart appliances. For example, programming a dishwasher at 7 pm with 7 am the next morning as a deadline would account for 12 hours of flexibility. The flexible use of the domestic hot water buffer was remunerated with a different scheme.
The intraday balancing setup presumes that demand response is the only source in the BRP’s portfolio to compensate imbalances. Every quarter hour, the following control cycle is run:
|
Complete description |
[More verbose description; include for example details about control domain, requirements towards input signals or applicable system operating modes (normal, emergency, …) ] |
Optimality Criteria
(Directly associated with objectives. E.g. by what metric to 'minimise' something)
Optimality Criteria | |||
ID | Name | Description | Reference to mentioned use case objectives |
|
|
|
|
|
|
|
|
|
|
|
|
Use case conditions
Use case conditions |
Assumptions |
[Assumption; assumed relation to other systems: e.g. higher level controller sends a signal] |
Prerequisites |
[Triggering Event (update of control signal or disturbance ...)]
|
General remarks
General remarks |
[everything which doesn't fit in any of the other categories] … |
Graphical RepresentationS Of Use Case
Graphical representation(s) of use case |
Examples of typical diagram types associated with use cases:
a) UML Use case diagram
b) UML Sequence diagram(s)
|
Technical Details
Actors
Actors | |||
Grouping | Group description | ||
|
| ||
|
| ||
|
| ||
Actor name | Actor type | Actor description | Further information specific to this use case |
|
|
|
|
|
|
|
|
|
|
|
|
Step By Step Analysis Of Use Case Optional
Overview of use case scenarios
Identify all relevant use case scenarios; rel. e.g. to Sequence Diagram or Use Case diagram
Scenario conditions | ||||||
No. | Scenario name | Scenario description | Primary actor | Triggering event | Pre-condition | Post-condition |
1 |
|
|
|
|
|
|
2 |
|
|
|
|
|
|
3 |
|
|
|
|
|
|
Steps – Scenarios
Alternative / complementary to sequence diagrams.
Scenario | ||||||||
Scenario name : |
| |||||||
Step No. | Event | Name of process/ activity | Description of process/ activity | Service
| Information producer (actor) | Information receiver (actor) | Information exchanged (IDs) | Requirements R-ID |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Common Terms And Definitions
Common terms and definitions | |
Term | Definition |
|
|
|
|