Description Of The Use Case

Graphical RepresentationS Of Use Case

Technical Details

Step By Step Analysis Of Use Case Optional

Search

Asset Publisher

Name of use case

Version management

Scope and objectives of use case

Narrative of use case

Optimality Criteria

Use case conditions

General remarks

Actors

Overview of use case scenarios

Steps – Scenarios

Use Case: VITO/Automated demand response for intraday RE balancing

Use case identification

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 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*	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

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:

Status, user configuration and measurement updates for all appliances in the demand response cluster are collected.
The change in consumption for the demand response cluster for the next quarter hour with respect to a base line are calculated.
If the wind has been underestimated and an increase in consumption is required, then the impact on the base line is calculated for all sources of flexibility that can be switched on. The appliances are then sorted in increasing order of impact and activated based on this order until the imbalance is corrected.
Decreases in consumption can be achieved by switching off the charging of domestic hot water buffers or electric vehicles. If the wind has been overestimated, then these devices are randomly selected and switched off, if the comfort settings allowed, until the imbalance is rectified.

Complete description

[More verbose description; include for example details about control domain, requirements towards input signals or applicable system operating modes (normal, emergency, …) ]

(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

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

[everything which doesn't fit in any of the other categories]

…

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)

*Actors*
*Grouping*		*Group description*



*Actor name*	*Actor type*	*Actor description*	*Further information specific to this use case*

Identify all relevant use case scenarios; rel. e.g. to Sequence Diagram or Use Case diagram

Scenario conditions

Scenario name

Scenario description

Primary actor

Triggering event

Pre-condition

Post-condition

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*