Asset Publisher

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

Description Of The Use Case

Name of use case

Use case identification


System configuration(s)

Name of use case


[List of system configura­tions 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.




Approval status



[List of names]

[Difference to previous version]

[Draft, Work in progress, Review, Final]



Pieter Valkering

First version

Work in progress

Scope and objectives of use case

Scope and objectives of use case


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.


[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:


  • 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, …) ]


Optimality Criteria

(Directly associated with objectives. E.g. by what metric to 'minimise' something)

Optimality Criteria




Reference to mentioned use case objectives













Use case conditions

Use case conditions


[Assumption; assumed relation to other systems: e.g.  higher level controller sends a signal]



[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




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


Scenario name

Scenario description

Primary actor

Triggering event
























Steps – Scenarios

Alternative / complementary to sequence diagrams.


Scenario name :


Step No.


Name of process/ activity

Description of process/ activity



Information producer (actor)

Information receiver (actor)

Information exchanged (IDs)

Requirements R-ID



















Common Terms And Definitions

Common terms and definitions